Hay un patrón que aparece repetidamente en equipos que llevan meses ejecutando IA en producción: configuran dashboards para monitorizar el gasto en LLM, crean alertas para cuando los costes se disparan, y revisan las facturas cuidadosamente a posteriori.
Todo eso es útil. Nada de eso evita que el pico ocurra.
Validar costes después de llamar al modelo es el error más caro en operaciones de IA. Para cuando tu alerta se dispara, ya has gastado el dinero.
Por qué fallan las comprobaciones post-ejecución
La mayoría de equipos recurre al tracking de costes post-ejecución porque es fácil. Tu proveedor de LLM te da un endpoint de uso. Puedes registrar conteos de tokens. Puedes construir un dashboard en una tarde.
Pero la comprobación post-ejecución tiene un problema fundamental: la llamada ya ocurrió.
El bucle descontrolado. Un job de background procesa documentos a través de un LLM. Un bug hace que procese el mismo documento diez mil veces. Tu alerta se dispara después de dos horas y varios miles de euros de gasto. Matas el job. El daño está hecho.
El usuario adversarial. Un usuario descubre que tu asistente de IA genera respuestas largas cuando se le pide que "explique en detalle." Envía quinientas requests en una hora. Tu comprobación de rate limit se ejecuta en el servidor, después de la llamada al LLM. Cada request se factura.
La sorpresa de fin de mes. Las requests individuales parecen bien. Pero un tenant está consistentemente al 90% de su presupuesto para el día 15. Nadie lo nota hasta que llega la factura. No hay mecanismo para limitar o avisar a mitad de ciclo.
En cada caso, la comprobación llegó demasiado tarde.
El modelo correcto: aplicar límites pre-ejecución
La solución es arquitectónica. El enforcement de límites de coste y rate debe ocurrir en el pipeline de requests, antes de que la llamada salga hacia cualquier proveedor.
Comprobaciones de presupuesto a nivel de request
Antes de reenviar la request, calcula el coste estimado basado en el conteo de tokens de input y el precio del modelo. Compáralo con el presupuesto restante del tenant. Si la llamada superaría el límite, bloquéala y devuelve un error estructurado. La fórmula es directa:
coste_request = (tokens_input / 1.000 × precio_input)
+ (tokens_output / 1.000 × precio_output)
Añade una banda de seguridad del 10-15% para cubrir variación en la longitud del output. El resultado es una estimación que puedes comparar contra el presupuesto restante antes de hacer la llamada.
Enforcement de RPM en el gateway
Registra requests por minuto por tenant y por modelo. Cuando un tenant alcanza su límite de RPM, rechaza la request inmediatamente, antes de que llegue al proveedor. Sin llamada, sin coste. Este control es el que detiene los bucles descontrolados en el primer ciclo, no después de horas de gasto acumulado.
Caps por proveedor y por modelo
Algunos proveedores son más baratos que otros. Algunos modelos cuestan diez veces más por token. Los caps deben ser configurables en ambos niveles para que puedas aplicar diferentes límites a distintas partes de tu stack y evitar que una ruta de alto coste consuma el presupuesto diseñado para otra.
Límites estrictos vs. políticas de overage
Los límites estrictos bloquean la request completamente. Las políticas de overage permiten que la request continúe pero marcan el exceso para facturación adicional, algo útil para clientes enterprise que necesitan garantías de continuidad. Ambos necesitan aplicarse pre-ejecución; la diferencia es solo el resultado.
Cómo se ve el pipeline
Un pipeline de control de costes pre-ejecución tiene esta estructura básica:
Llega la request
→ Autenticar tenant
→ Comprobar límite de RPM (rechazar si se supera)
→ Estimar coste en tokens
→ Comprobar presupuesto restante
→ Si se supera: rechazar o marcar para overage
→ Enrutar al proveedor
→ Ejecutar
→ Registrar coste real
La clave es que la comprobación de presupuesto se sitúa antes del paso de ejecución. Es una puerta, no un monitor. La diferencia no es solo semántica: un monitor te dice qué pasó, una puerta decide si puede pasar.
Ejemplo mensual rápido
Supón un tenant con 1.200.000 requests al mes y un coste medio estimado de 0,0042€ por request. El presupuesto mensual asignado es de 4.500€.
La estimación en semana 1 da: 1.200.000 × 0,0042€ = 5.040€. Ya sabes que el presupuesto no cuadra. Puedes actuar antes del problema: bajar el modelo en rutas de baja complejidad, reducir el output máximo por request, o aplicar un cap por caso de uso para las rutas más caras.
Si no haces este cálculo al principio del ciclo, el ajuste siempre llega tarde. Y cuando llega tarde, llega después de gastar el dinero que no tenías.
Los beneficios operativos más allá del control de costes
Cuando pasas a enforcement pre-ejecución obtienes tres cosas que el monitoring post-ejecución no puede darte.
Predictibilidad. Los tenants no pueden superar sus límites. Los presupuestos se convierten en restricciones rígidas, no en objetivos blandos que se incumplen de vez en cuando.
Prevención de incidentes. Los bucles descontrolados se detienen después del primer lote que supera el límite, no tras horas de gasto sin control. El daño es acotado por diseño, no por suerte.
Confianza. Los clientes enterprise pueden comprometerse con un cap de coste y saber que se aplicará. Eso es un diferenciador comercial real, especialmente en sectores donde el presupuesto de IA está auditado o es parte de un contrato.
La sorpresa en la factura es opcional. El enforcement pre-ejecución la hace evitable.