# El incidente que llega en la factura > Un agente en bucle o un reintento sin tope no tumban el servicio: lo encarecen. Por qué el coste debería medirse como un SLI y quién tiene que responder cuando se dispara. - Autor: José Manuel García Locubiche - Publicado: 2026-09-28 - Original: https://jose-m.net/2026/blog/tech/el-incidente-que-llega-en-la-factura/ ---
## Todo en verde, salvo la cuenta Pongamos un caso. Un viernes por la tarde se despliega un cambio pequeño en un agente que clasifica tickets de soporte: una herramienta nueva que consulta el historial del cliente. La herramienta tiene un fallo y devuelve un error que el agente interpreta como "vuelve a intentarlo". Así que lo vuelve a intentar. Y otra vez. Y en cada vuelta el contexto crece, porque arrastra los intentos anteriores, así que cada llamada al modelo cuesta un poco más que la anterior. Nadie se entera durante el fin de semana. Los tickets se acaban clasificando, la latencia es aceptable, la tasa de errores que ve el usuario es cero y el SLO está en verde. El lunes alguien de finanzas pregunta por qué el consumo del proveedor de IA de tres días equivale al de dos meses. No se ha caído nada. Y sin embargo es un incidente con todas las letras: ha habido un daño, ha crecido cada hora que nadie lo miraba y se habría podido parar en minutos. ## Por qué los dashboards no lo ven Los SLI clásicos miden lo que nota el usuario: si el servicio responde, cuánto tarda y si la respuesta es correcta. Es lo sensato, porque la fiabilidad se define desde fuera. Pero el coste no lo nota el usuario, así que no aparece en ninguno de esos indicadores. Un sistema puede cumplir todos sus objetivos mientras hace diez veces más trabajo del necesario para cumplirlos. La única señal que sí lo refleja es la facturación, y la facturación está diseñada para contabilidad, no para operación: llega con horas de retraso en el mejor de los casos, agregada por servicio y no por funcionalidad, y la mira alguien que no está de guardia. Las alertas de presupuesto de los proveedores cloud ayudan, pero están pensadas para avisar de que el mes va a salir caro, no de que algo concreto se ha roto hace veinte minutos. Hace unas semanas escribí sobre [el tiempo entre que algo falla y que alguien se entera](/2026/blog/tech/el-tiempo-entre-que-algo-falla-y-que-alguien-se-entera/). Los incidentes de coste son el caso extremo de ese hueco: el gap de detección se mide en días, a veces en semanas, porque el primer sitio donde el problema es visible es un informe mensual. ## De dónde salen Los agentes lo han vuelto más frecuente, pero el patrón es anterior. Cualquier componente que convierte un fallo en más trabajo, en vez de en un error, puede producir uno de estos incidentes: - **Bucles de agentes.** Un agente sin límite de iteraciones ante una herramienta que falla, o dos agentes que se delegan tareas entre sí, pueden quemar presupuesto sin producir nada útil y sin devolver ningún error. - **Reintentos sin tope.** Un reintento con backoff pero sin número máximo, sobre una llamada que cuesta dinero, multiplica la factura por cada fallo aguas abajo. - **Autoscaling que obedece.** Si el tráfico abusivo o un cliente mal configurado dispara la carga, el autoscaling hace exactamente lo que se le pidió: escalar. El servicio aguanta y la cuenta también sube. - **Logs y transferencia de datos.** Un nivel de log en `DEBUG` olvidado en producción, o tráfico que empieza a cruzar zonas o a salir por un NAT gateway tras un cambio de red, son partidas que casi nadie vigila hasta que ya pesan. - **Denial of wallet.** Un endpoint público que llama a un modelo o lanza una función serverless por petición es un objetivo cómodo: un atacante no necesita tumbarte el servicio si puede hacer que cada visita te cueste dinero. ## El coste como SLI La propuesta es tratar el coste igual que cualquier otra señal de fiabilidad: medirlo, fijarle un objetivo y alertar sobre él con la misma disciplina. **Medir en origen, no en la factura.** El dato ya existe en tiempo real, en tu propio código. Las APIs de modelos devuelven en cada respuesta cuántos tokens se han consumido; cada invocación, cada reintento y cada llamada a una herramienta se pueden contar en el momento en que ocurren. Emitirlo como una métrica más, etiquetada por funcionalidad, convierte algo que se sabía a fin de mes en algo que se sabe al minuto. **Coste por unidad de trabajo, no total.** El gasto total sube cuando el negocio crece, y eso es bueno. Lo que indica un problema es que suba el coste de cada cosa que el sistema hace: por petición, por ticket clasificado, por tarea completada por un agente. Si clasificar un ticket cuesta normalmente unos céntimos, ese es el número a vigilar, y un objetivo razonable se parece mucho a un SLO de latencia: "el 99 % de las tareas cuesta menos de X". **Alertar por ritmo de gasto.** Los equipos que ya trabajan con presupuestos de error conocen las alertas por burn rate: no se alerta porque haya un error, sino porque, al ritmo actual, el presupuesto del mes se agotaría demasiado pronto. Con el coste funciona igual. Si al ritmo de la última hora el presupuesto mensual de una funcionalidad se acabaría en tres días, eso despierta a alguien. Si se acabaría en tres semanas, basta con un ticket para el lunes. ## Tres controles baratos No hace falta una plataforma de FinOps para cubrir lo básico. Tres controles resuelven la mayoría de los casos, y ninguno es más de una tarde de trabajo: 1. **Topes duros por tarea.** Número máximo de iteraciones de un agente, de tokens por conversación, de llamadas a herramientas y de reintentos. Cuando se alcanza el tope, la tarea falla de forma visible. Un error que alguien ve es mucho mejor que un éxito que cuesta cien veces lo normal. 2. **Alerta de burn rate sobre tus propias métricas.** La del apartado anterior, construida sobre lo que emite la aplicación y no sobre la facturación. Los límites de gasto del proveedor siguen siendo útiles, pero como red de seguridad: cortan cuando el daño ya está hecho. 3. **Un interruptor para degradar.** Una feature flag que permita pasar a un modelo más barato, desactivar el agente y dejar las tareas en cola, o cerrar el endpoint público, sin desplegar nada. Es lo que se usa en los primeros cinco minutos del incidente, antes de entender la causa. ## Quién responde Esta es la parte que más cuesta cambiar. Mientras el coste se vea como un asunto de finanzas, los incidentes de coste los descubrirá finanzas, a fin de mes, y los investigará alguien sin contexto técnico preguntando por Slack a quién le suena este servicio. Si el coste es un SLI, quien responde es la persona de guardia, con el mismo proceso que cualquier otro incidente: parar la hemorragia con el interruptor, diagnosticar después, y un postmortem que incluya la pregunta de siempre: ¿cuánto tiempo estuvo el gasto fuera de lo normal antes de que alguien lo supiera? FinOps sigue teniendo su papel, que es el de planificar, negociar y optimizar a medio plazo. Pero un agente en bucle un sábado por la noche no es un problema de planificación. ## Conclusión Durante años la pregunta de fiabilidad ha sido si el sistema funciona. Con componentes que cobran por cada vez que piensan, hace falta una segunda: si funciona a un coste razonable. Un servicio que cumple su SLO a diez veces su coste normal no está sano, solo está escondiendo el fallo en un sitio que nadie vigila. La buena noticia es que la señal para verlo ya la tienes en tu propio código; solo falta tratarla como a las demás.