A los proyectos de IA empresarial les pasa algo extraño en el viaje del piloto a producción: la factura no crece linealmente. Crece 30 veces, 60 veces, en algunos casos 200 veces, según la propia FinOps Foundation. Y no es porque el sistema haga 30 veces más trabajo. Es porque el sistema empieza a hacer cosas que en el piloto no se medían — y para cuando alguien las mira, ya están en el contrato anual.
Hay un patrón que llevamos viendo en cliente tras cliente: el piloto pasa todos los KPIs técnicos, alguien firma producción, llega la primera factura del trimestre y la conversación cambia de tono. El CFO no pregunta por accuracy. Pregunta por qué un proceso que costaba 200 € al mes ahora cuesta 12.000.
Este post es la versión que un CTO le enseña a su equipo el lunes siguiente. No es un manifiesto sobre FinOps. Es un inventario de los 7 anti-patrones concretos que multiplican tu factura, una métrica que importa más que coste/token, y un conjunto de circuit breakers que cualquier equipo puede instrumentar antes de firmar el siguiente roadmap.
El coste de IA empresarial en cifras
Datos públicos FinOps Foundation, Gartner y State of FinOps 2026
1. Por qué el coste de IA no se parece al coste de cloud tradicional
El cloud tradicional tiene una propiedad que sus operadores tardaron diez años en interiorizar pero que hoy todos conocen: el coste es proporcional al uso, y el uso es proporcional al trabajo útil. Si una API recibe 10x más peticiones, factura 10x más. Si un cluster sirve 10x más usuarios, paga 10x más en cómputo. Existen brechas (egress de datos, costes ocultos de bases de datos managed) pero el principio de proporcionalidad sigue siendo razonable.
La IA empresarial no se comporta así. El uso útil y el uso facturado se desacoplan en cuanto el sistema sale del piloto, por tres razones estructurales:
- El input no es la unidad facturable. Cuando un usuario hace una pregunta de 12 palabras a un asistente RAG, lo que se factura no son 12 palabras: son los 8.000 tokens de contexto recuperado más el system prompt de 1.200 tokens más el output de 600 tokens. Una petición pequeña puede facturar 20.000 tokens. Lo invisible al usuario es lo único que el proveedor cobra.
- Los reintentos no son del usuario, son del sistema. Una llamada a un agente con tool use puede generar 5-10 llamadas internas al modelo antes de devolver una respuesta. Si una de esas llamadas falla, hay reintentos. Si el agente está mal calibrado, hay bucles. La factura crece exponencialmente, no proporcionalmente.
- El "context bloat" es la deuda técnica más cara que existe hoy. Cada vez que un equipo añade una nueva fuente al RAG, una nueva tool al agente o una nueva instrucción al system prompt, el coste por petición sube de forma permanente. No hay nada en la observabilidad estándar que avise de eso.
Resultado: la curva de coste tiene una discontinuidad en el paso a producción que las herramientas de FinOps tradicionales no detectan porque están pensadas para VMs, no para tokens.
2. Los 7 anti-patrones que multiplican tu factura
Inventario, en orden aproximado de impacto observado en mid/large enterprise. Ningún anti-patrón es exótico. Cada uno es defendible la primera vez que se introduce. El problema no es ninguno individualmente; es la acumulación silenciosa.
El system prompt empieza siendo 200 tokens. Cada vez que algo sale mal en producción, alguien añade una instrucción defensiva ("nunca devuelvas X", "siempre pregunta antes de Y"). En seis meses son 4.500 tokens. Cada petición paga ese impuesto. Un asistente con 1M de peticiones/mes paga 45 millones de tokens adicionales al mes sólo en el system prompt — sin cambiar una línea del producto.
La hipótesis de que "más contexto siempre es mejor" lleva a equipos a recuperar 10-20 chunks por petición cuando con 3-5 sería suficiente. La accuracy mejora marginalmente; la factura crece linealmente con los chunks recuperados. Los chunks que no se usan son pago puro sin valor.
Patrón clásico: un agente "supervisor" llama a un agente "researcher" que llama a un agente "writer" que devuelve al supervisor para validar. Tres llamadas al modelo donde una bien diseñada bastaría. En workloads agentic mal escritos, el 60-80% del coste son llamadas internas que el usuario nunca ve.
Una llamada falla, el código reintenta hasta tres veces. La validación post-llamada falla, se vuelve a llamar al modelo. El usuario no nota la latencia porque hay caché de respuesta intermedia, pero la factura cuenta cada intento. Sin retry caps explícitos, una petición puede facturar 5-15x lo que debería.
Activar "thinking" o "reasoning extended" en modelos que lo soportan dispara los tokens de output. En modelos con razonamiento extendido (Claude Opus, GPT con o1-style reasoning, Gemini Deep Think), una petición con CoT puede facturar 8-15x los tokens de una respuesta directa. A veces vale la pena; muchas veces no, y nadie lo audita.
El equipo despliega una nueva versión del servicio RAG. El pipeline reconstruye los embeddings de los 200.000 documentos del corpus. La factura de embeddings de ese mes se multiplica por el número de despliegues. Equipos que despliegan 4-5 veces al mes pagan 4-5 facturas de embeddings cuando deberían pagar una.
Anthropic, OpenAI y Google llevan más de un año ofreciendo descuentos del 50-90% sobre tokens cacheados. Equipos que envían el mismo system prompt en cada petición sin marcar el cache_control están pagando la tarifa completa por información estática. El descuento no se aplica solo: hay que activarlo.
La buena noticia: los siete son evitables con instrumentación básica. La mala: ninguno se detecta con dashboards de proveedor estándar — hay que medirlos al nivel de aplicación, no de billing. Es la misma diferencia que hay entre arquitecturar RAG bien o mal: los errores no son técnicamente imposibles de evitar, son los que nadie está mirando.
3. La métrica que importa: coste por tarea útil completada
Coste/token es una métrica de proveedor, no de negocio. Mirarla es como mirar el coste por miligramo de combustible al hablar del coste de un viaje.
La métrica que importa para un CTO o CFO es coste por tarea útil completada. Una "tarea útil completada" se define a nivel de producto: una respuesta correcta del asistente, un documento extraído sin errores, una decisión de scoring entregada con confianza por encima del umbral, un código generado que pasó los tests.
Esta métrica tiene dos propiedades que coste/token no tiene:
- Captura el problema de los reintentos y bucles. Si tu agente necesita 8 llamadas al modelo para entregar una tarea útil, el coste por tarea es 8x el coste por llamada. El KPI lo refleja; el KPI de tokens no.
- Hace explícita la calidad como variable económica. Si bajas accuracy del 95% al 70%, el coste por tarea útil sube — porque las tareas no útiles son pago puro sin valor de negocio. Un sistema barato por petición pero con 30% de tareas no útiles es un sistema caro a nivel de unidad de negocio.
Dos casos ilustrativos: la matemática del antes y después
Para hacer el coste por tarea útil concreto en lugar de abstracto, dos escenarios compuestos basados en patrones que vemos repetidamente en mid-large enterprise. Los números son ilustrativos pero la aritmética cuadra con los multiplicadores citados arriba — están construidos para que cualquier CTO pueda reproducir el cálculo en su propio caso.
Antes (sin instrumentación)
- 200.000 peticiones/mes sobre Claude Sonnet
- System prompt acumulado: 4.500 tokens (context bloat)
- RAG con
top_k=15(~9.000 tokens recuperados) - Reasoning extended activo en 30% de peticiones
- Sin
cache_controlconfigurado - Input medio: ~14.000 tokens · output medio: ~1.330 tokens
- Coste/petición: ≈ $0,062
≈ 12.000 €/mes
Después (5 fixes en 2-3 sprints)
- Auditoría system prompt → 1.500 tokens (CB1)
- Cap de tokens explícito (CB2)
- Gating de CoT al 5% de peticiones (CB5)
- Caché de prompts activada (anti-patrón 7)
top_k=5con reranker (anti-patrón 2)- Input medio: ~5.000 tokens (4.500 cacheados al 25%) · output: ~555 tokens
- Coste/petición: ≈ $0,013
≈ 2.800 €/mes
Reducción: −77% sobre la factura mensual sin tocar accuracy. ROI primer mes.
Antes (sin instrumentación)
- 50.000 tareas/mes con tool use sin cap de iteraciones
- Promedio: 8 llamadas al modelo por tarea (bucles entre sub-agentes)
- Retry agresivo sin distinguir error transitorio vs. semántico
- Sin caché
- Tasa de tareas con output útil: ~60%
- Coste/llamada al modelo: ≈ $0,030
- Coste/tarea bruta: ≈ $0,24
≈ 0,38 €/tarea útil
Después (1-2 sprints + alineación)
- Instrumentación
task_outcomeen observabilidad - Cap de iteraciones a 5 (CB3)
- Retry policy diferenciada por error class (CB4)
- Caché sobre system + tool definitions
- Tasa de tareas útiles sube a ~85% por reducción de bucles fallidos
- Coste/llamada: ≈ $0,020
- Coste/tarea bruta: ≈ $0,10
≈ 0,11 €/tarea útil
Reducción: −71% sobre el coste por unidad económica útil. La accuracy sube — no baja — porque los bucles infinitos eran el síntoma, no la cura.
Estos dos casos no son los más extremos que hemos visto. Son los más ilustrativos del patrón.
4. Circuit breakers de coste: 5 controles que bloquean el daño
Los circuit breakers son al coste de IA lo que los rate limits son a las APIs: protección operativa pre-incidente, no análisis post-mortem.
Budget por feature
Cada feature de producto que usa IA tiene un budget mensual asignado en euros. La instrumentación lo trackea en tiempo real. Cuando el consumo cruza el 80%, alerta al equipo dueño. Cuando cruza el 100%, el feature degrada a un fallback determinista hasta el siguiente periodo. No hay sorpresas a fin de mes porque es estructuralmente imposible que las haya.
Cap de tokens por petición
Cada llamada al modelo tiene un max_tokens explícito tanto en input como en output. Si una petición está a punto de superarlo, se rechaza antes de llegar al proveedor. Esto bloquea el escenario más caro: una petición patológica con 200K tokens de contexto y una respuesta sin límite. Cap input + cap output, no negociable.
Cap de llamadas por sesión agentic
Cualquier agente con tool use tiene un máximo de N iteraciones por sesión (típicamente 8-15 según el caso). Al llegar al cap, el agente devuelve la mejor respuesta parcial disponible y registra la sesión como partial. Esto bloquea bucles infinitos antes de que se conviertan en facturas infinitas.
Sampling de retry agresivo
Si una llamada falla, máximo 1 retry — y solo si el error es transitorio (timeout, 429, 5xx). Errores semánticos (validación post-llamada falla) no se reintentan automáticamente: se registran y trazan para observabilidad. Reintentar errores semánticos es la forma más cara de no resolver un bug.
Modo "auditoría de coste" en CI
Antes de mergear cualquier cambio que toque prompts, RAG, agentes o tool use, un test ejecuta un set de peticiones representativo y compara coste y latencia con la baseline. Si el coste sube >15% sin que el PR lo justifique, el merge se bloquea. El coste como variable de calidad — igual que tests de regresión, igual que tests de seguridad.
Los cinco son baratos de implementar (1-3 semanas para un equipo que ya tiene observabilidad básica). Lo caro es no tenerlos cuando llega la primera factura inesperada del trimestre.
5. Cuándo elegir modelo pequeño, grande u on-prem: tabla de umbrales
La decisión modelo grande vs. modelo pequeño vs. inferencia local no es ideológica. Es económica, y depende de tres variables: volumen de peticiones/mes, criticidad de la accuracy y sensibilidad de los datos.
| Escenario | Volumen | Accuracy crítica | Datos sensibles | Recomendación práctica |
|---|---|---|---|---|
| Asistente conversacional cliente final | >5M/mes | media | baja | Modelo pequeño + fine-tuning (Haiku, GPT-4o-mini, Gemini Flash). Coste/petición 10-30x menor que el flagship a la misma accuracy en dominio acotado. |
| Análisis legal / compliance | <100K/mes | muy alta | alta | Modelo grande managed con BAA + zero retention (Claude Sonnet/Opus en Bedrock o Vertex). El coste/petición no domina; el riesgo de error sí. |
| Agente autónomo de operaciones | 50K-1M/mes | alta + multi-step | media | Router pattern: modelo grande para razonamiento + modelo pequeño para tool calling. Reduce coste 40-60% vs. usar grande para todo. |
| Procesamiento batch documental | >10M docs/mes | media | variable | Modelo pequeño + caché agresivo de embeddings + alternativo open-source (Llama, Mistral) on-prem si la sensibilidad lo justifica. |
| Copiloto interno de desarrollo | 200-500 devs | media | alta (código) | Mezcla managed + open-source local según sensibilidad del repo. Razonable: 30-80 €/dev/mes. Por encima de 150 €/dev/mes hay que auditar uso. |
Ninguna fila es definitiva. El punto de la tabla es que la decisión del modelo es una decisión de coste tanto como una de capacidad — y casi nadie la trata así. El framework completo de selección, con TCO y eje de exit cost, lo desarrollamos en cómo elegir LLM en 2026.
6. La deuda invisible
El State of FinOps 2026 coloca el coste de IA como prioridad #1 del CFO. Gartner predice que >40% de los proyectos de IA agentic serán cancelados antes del fin de 2027 — y la razón principal no es que la tecnología no funcione, sino que la economía no cuadra.
No cuadra porque hay una deuda invisible que se acumula desde el día 1 del piloto: cada token no auditado, cada chunk RAG sobreincluido, cada agente que llama a otro agente sin presupuesto, cada despliegue que regenera embeddings sin necesidad. Ninguna de esas decisiones es individualmente sospechosa. Todas juntas son la diferencia entre 200 € y 12.000 € al mes para el mismo trabajo.
El CTO que instrumente token economics, defina coste por tarea útil como KPI y despliegue circuit breakers desde la fase piloto construye sobre cimientos auditables. El que no lo haga estará explicando a su CFO en seis meses por qué el ROI estimado del proyecto no aparece en el P&L — y por qué no se puede arreglar sin rediseñar partes del sistema.
El test de los lunes: abre la última factura del proveedor de LLM. ¿Sabes qué feature consumió cada partida? ¿Sabes qué porcentaje son llamadas internas no visibles al usuario? ¿Sabes cuál es tu coste por tarea útil? Si la respuesta a alguna es "no", ya tienes el punto de entrada.
En onext acompañamos a equipos de ingeniería a construir esa instrumentación desde el día uno, no desde la primera factura inesperada. Si quieres comparar tu setup actual contra los 7 anti-patrones de este post, hablemos.
Fuentes citadas
- FinOps Foundation — FinOps for AI Overview
- FinOps Foundation — State of FinOps 2026
- Aretove — The 2026 FinOps Frontier: governing LLM costs
- Finout — FinOps in the Age of AI: CPO's guide
- arXiv — Beyond Accuracy: CLEAR framework enterprise agentic AI
- Gartner via Joget — >40% de proyectos agentic AI serán cancelados antes 2027