El Module XI (Cost and AI FinOps) contabiliza el gasto en IA desde el provider cost stream y aplica presupuestos. Al alcanzar el tope, un budget gate deniega el gasto. Esto es enforcement en tiempo real, siempre activo en el binario por defecto — no es una funcionalidad bajo demanda que se provisiona después. Si un presupuesto está configurado, el gate está activo.
Budget gates
Un budget gate tiene dos modos de enforcement:
- Throttle — limita la tasa de gasto, degradando de forma gradual. El agente se ralentiza, no se detiene por completo, hasta que el presupuesto se recupera o un operador lo eleva.
- Block — denegación estricta al alcanzar el tope. El agente recibe una señal clara de que su presupuesto está agotado y no se autoriza más gasto.
Ambos modos son deny-closed: si el estado del presupuesto no es legible — un error de almacenamiento, una fila corrupta, un registro inexistente — el gate deniega, nunca permite. Un estado de presupuesto desconocido se trata como agotado, no como ilimitado. Esta es la misma postura que el resto de la plataforma mantiene para los enforcement gates (véase governance).
Cost accounting
El gasto se obtiene del provider cost stream y del reference pricing verificado por el operador, gestionado por el Module X (Model and provider management). Las muestras de coste proceden de la telemetría observada — los tokens, el modelo, el proveedor — no de interceptar llamadas a la API. La plataforma no se sitúa en la ruta de inferencia; lee la señal de coste fuera de banda, del mismo modo que lee cualquier otra observación.
El reference pricing lo verifica el operador, no se fabrica. El Module X permite declarar el precio por token o por petición para cada modelo y proveedor, y el budget enforcement útiliza ese pricing como base contable. Si el precio declarado difiere de lo que el proveedor realmente cobra, el budget gate aplica el enforcement contra el precio declarado — la plataforma no puede conocer la factura del proveedor hasta que este la comúnique.
Configurar un presupuesto
Los presupuestos aplican a tres niveles:
- Per-tenant — un tope para todo el gasto en IA dentro de un tenant.
- Per-agent — un tope para el gasto de un agente individual, dentro de su tenant.
- Per-model — un tope para el gasto en un modelo concreto, dentro de un tenant o agente.
El enforcement es inmediato. Una vez configurado un presupuesto con un tope y un modo de gate (throttle o block), el gate está activo. No hay calentamiento, ni retardo, ni “el enforcement comenzará tras el siguiente ciclo de facturación”. El gate comprueba el gasto acumulado contra el tope en cada evento de coste gobernado.
Los ámbitos de presupuesto componen por intersección: un presupuesto per-agent y un presupuesto per-tenant aplican ambos, y el primer tope alcanzado activa su gate. Un presupuesto per-model dentro de un agente queda además restringido por cualquier presupuesto per-agent y per-tenant que esté por encima.
Qué ocurre al alcanzar el tope
Cuando el gasto acumulado alcanza o supera el tope configurado:
- El budget gate deniega el gasto — throttle o block, según el modo.
- La denegación se registra como un finding en la superficie de findings de la plataforma, con el ámbito del presupuesto, el tope y el gasto acumulado en el momento de la denegación.
- El agente recibe una señal clara de que su presupuesto está agotado. La plataforma no descarta la petición de forma silenciosa ni devuelve un error ambiguo.
- Si hay notificaciónes configuradas, la denegación se encamina a través del Module XV.
Un gasto denegado es un evento gobernado. Se escribe en el audit ledger en la misma transacción que la denegación, de modo que no existe ninguna ventana en la que una denegación de presupuesto quede sin registrar.
Notificaciones
Las alertas de presupuesto se integran con el Module XV (Output integrations and notifications). Cuando un presupuesto se aproxima a su tope o lo alcanza, el finding puede enrutarse a cualquier destino configurado:
- Slack / Teams — notificación a un canal o DM.
- PagerDuty / Opsgenie — escalado de alertas.
- Signed webhook — para integraciones personalizadas.
- SIEM — añadido al audit export stream.
Los destinos de notificación los provisiona el operador. Un budget gate aplica el enforcement independientemente de si hay un destino de notificación configurado — el gate es el enforcement, la notificación es la capa de conocimiento.
La interacción con el kill switch
El kill switch es el deny gate a nivel de estate y anula todo, incluidos los budget gates. Cuando el kill switch está activado:
- Toda la actuación gobernada se deniega, incluido cualquier gasto que los budget gates de otro modo permitirían en throttle o dejarían pasar.
- El modo throttle/block de un budget gate queda sin efecto — el estate está detenido.
- Reactivar el estate requiere la aprobación habitual de dual-control (dos personas distintas, sin break-glass path para la reactivación).
El budget gate y el kill switch son controles independientes. Componen, no compiten: el kill switch es un deny superset que subsume cualquier otro gate.
Model routing y presupuesto
El Module X gestiona el model routing con reference pricing verificado por el operador. El budget enforcement consume este pricing — no mantiene su propia tabla de precios ni fabrica datos de coste. La dependencia es unidireccional:
- El Module X declara el catálogo de modelos y los reference prices.
- El Module XI lee esos precios para contabilizar el gasto y aplicar los budget caps.
Si el Module X no tiene un reference price para un modelo, el Module XI no puede contabilizar el gasto contra un presupuesto. El gasto no gobernado (sin precio, sin presupuesto) se muestra como un finding, no se deja pasar en silencio.
Límites honestos
El budget enforcement está activo y es deny-closed para las superficies que la plataforma gobierna, pero tiene límites que conviene entender antes de depender de él:
- La precisión del coste depende del proveedor. La plataforma contabiliza el gasto usando reference pricing declarado por el operador y recuentos de tokens observados. Si la facturación real del proveedor difiere del precio declarado, el budget gate aplica el enforcement contra el precio declarado, no contra la factura. La plataforma no fabrica datos de coste ni inventa benchmarks.
- La cobertura está limitada por la observación. El budget enforcement aplica al gasto que fluye por canales gobernados — fuentes que la plataforma observa. Un agente que llame a un modelo por una ruta no gobernada (sin source conectado, sin telemetría emitida) es invisible para el budget gate. La plataforma muestra las rutas no gobernadas como findings cuando puede detectarlas, pero no puede aplicar enforcement sobre lo que no puede ver.
- La plataforma es pre-1.0. El budget enforcement se distribuye y está conectado hoy, pero el detalle contable debe considerarse trabajo en curso. Véase honesty and limits para la postura completa.
Relacionado
- Modules catalog — Module XI (Cost and AI FinOps) y Module X (Model and provider management).
- Governance — el modelo de enforcement deny-closed que siguen los budget gates.
- FinOps tour — la página de producto para cost governance.
- Kill switch — el deny gate a nivel de estate que anula el budget enforcement.
- Honesty & limits — qué está activo frente a lo que está en design-toward.