La primera vez que un director financiero me preguntó por qué la factura de IA de su empresa había subido un seiscientos por ciento en seis meses, fui yo quien se sorprendió: por un lado, los precios de los modelos frontera habían bajado; por otro, el equipo afirmaba que todo estaba bajo control. La investigación reveló la mezcla habitual: RAG sin caché, un agente mal configurado que se autorecursaba, un bucle de evaluación que lanzaba el modelo más caro disponible para validar respuestas del modelo más barato. La suma de errores pequeños produjo una factura muy grande. En 2026 este tipo de situaciones es regla, no excepción, y por eso conviene hablar de FinOps específico para cargas de IA sin los relatos promocionales habituales.
Por qué el FinOps clásico no basta
FinOps tradicional mira coste por recurso: instancias EC2, almacenamiento S3, transferencia de datos. Funciona bien cuando el consumo es relativamente estable y las unidades son físicas. Para IA, las unidades son tokens, llamadas, embeddings calculados y tiempo de GPU en cargas mixtas. Un solo agente mal diseñado puede gastar en un día lo que cuesta una instancia al mes, y los paneles clásicos de coste por servicio no capturan la causa porque agrupan todo en una línea de gasto de API.
La dificultad añadida es que el gasto en IA suele escalar no linealmente con el uso. Una aplicación con mil usuarios diarios consume tokens de forma relativamente previsible. Añade agentes que razonan varios pasos, dales herramientas que encadenan llamadas entre sí y habrás multiplicado el gasto por diez sin cambiar el número de usuarios. El FinOps específico para IA tiene que modelar este efecto, atribuir coste a funcionalidad concreta y alertar cuando un patrón se sale del presupuesto esperado.
La tercera complicación es la mezcla de costes fijos y variables. Las GPUs reservadas en hiperescalares o en proveedores como CoreWeave o Lambda Labs son coste fijo; los tokens de APIs comerciales son variable puro. Equipos que combinan ambas piezas acaban con zonas opacas donde no saben si les sale más barato usar más GPUs propias o más API.
Los errores caros más comunes en 2026
El primer error que produce facturas desproporcionadas es usar modelos frontera para tareas que no los necesitan. Claude 4.5 Opus y GPT-5 cuestan entre diez y treinta veces más por token que sus hermanos pequeños, y para clasificación básica, resumen corto o extracción estructurada, los modelos pequeños son más que suficientes. La auditoría típica encuentra que entre el cuarenta y el setenta por ciento de las llamadas a modelo frontera podrían haberse hecho con modelo mediano o pequeño sin pérdida perceptible de calidad.
El segundo error es ausencia de caché en RAG. Una aplicación que hace retrieval augmented generation sin cache de embeddings, sin cache de respuestas repetidas y sin prompt caching paga múltiples veces por el mismo trabajo. Los patrones habituales de consulta tienen distribuciones muy sesgadas donde el veinte por ciento superior produce el ochenta por ciento del tráfico, y cachear esas gana mucho.
El tercer error es el bucle de evaluación con modelo caro. El equipo usa un modelo barato para la respuesta primaria y uno caro para validar; parece razonable hasta que sumas que cada respuesta genera dos llamadas. Una validación basada en reglas simples o en un modelo pequeño específico para la clasificación binaria correcto/incorrecto funciona casi igual de bien al cinco por ciento del coste.
Controles que de verdad mueven la factura
Lo primero es etiquetar llamadas por funcionalidad. Todas las llamadas a modelo deberían llevar metadatos de qué parte del producto las dispara, qué usuario las consume y en qué flujo están. Sin esto, no hay forma de saber si la subida de la factura viene de un cambio en producto, un pico de tráfico o un bug. Las APIs comerciales han añadido soporte para metadatos de factura durante 2025, y herramientas como Helicone, LangSmith o LangFuse agregan bien esta información para análisis posterior.
Lo segundo es presupuesto por funcionalidad con alertas automáticas. Cada componente que consume IA debería tener un techo mensual y una alerta cuando pase el setenta por ciento. Cuando el agente mal configurado empieza a autorecursarse, lo descubres a los veinte minutos, no cuando llega la factura. Este control es sencillo de implementar y evita sobrecostes catastróficos; cuesta menos montarlo que el primer incidente que habría evitado.
Lo tercero es el enrutador de modelos por complejidad. Un patrón que funciona muy bien es clasificar cada petición en función de la dificultad antes de enviarla al modelo: consultas triviales al modelo pequeño, complejidad media al mediano, razonamiento multietapa al grande. Una heurística simple basada en longitud y tipo de consulta elimina la mayoría del sobregasto sin afectar calidad percibida. Herramientas como Martian, RouteLLM o el router propio de Anthropic hacen esto automáticamente con poca configuración.
GPUs: el otro frente
Para equipos que operan sus propios modelos, la gestión de GPUs es el segundo frente de FinOps en 2026. Las H200 y B200 reservadas en CoreWeave o Lambda cuestan entre tres y siete dólares por hora. Si la utilización media está por debajo del cincuenta por ciento, estás tirando dinero. La práctica que funciona es medir utilización real por minuto y consolidar cargas en menos GPUs mejor aprovechadas en lugar de repartirlas en muchas instancias pequeñas con holgura.
El complemento es el mercado spot para cargas tolerables a interrupciones: training jobs, inferencia de batch no sensible a latencia, generación periódica de embeddings. Los precios spot bajan entre un cuarenta y un ochenta por ciento respecto a reservados, y con orquestación básica los cortes son absorbibles.
Herramientas útiles en 2026
Para observabilidad de coste IA, OpenCost sigue siendo referencia abierta en Kubernetes e integra métricas de GPU vía DCGM Exporter. Para coste de llamadas a APIs, Helicone, LangSmith y LangFuse compiten por el primer puesto: Helicone más barato y simple, LangSmith con mejor integración LangChain, LangFuse más abierto y auto-alojable.
Mi lectura
El FinOps para IA en 2026 no tiene nada de especialmente complicado, solo requiere hacer los controles habituales que la gente no hace. Etiquetar llamadas, presupuestar por funcionalidad, alertar antes del desastre, enrutar por complejidad, medir utilización de GPUs y usar el mercado spot para lo tolerable. Con estos seis controles, la mayoría de equipos reduce su factura entre un treinta y un sesenta por ciento sin perder calidad.
La resistencia habitual viene de que estos controles parecen burocracia que ralentiza el desarrollo, y en una cultura donde la IA se percibe como magia barata, nadie quiere ser el que pone el freno. Pero la factura llega cada mes, y cuando llega por primera vez con un sobrecoste del doble o del triple, la empresa entera descubre de golpe que necesitaba FinOps. Anticipar este momento con controles suaves desde el principio es mucho menos doloroso que implementarlos en modo crisis. Si todavía no has mirado la factura de IA con lupa, este mes es un buen momento.
