La factura que nadie presupuestó
Hace tres años, las cargas de GPU representaban el 4% del gasto cloud promedio de una organización. Hoy representan el 18%. No fue un crecimiento gradual ni planificado. Fue una explosión provocada por la carrera de adopción de IA generativa, donde el mandato fue "desplegar modelos" y la pregunta sobre cuánto iba a costar se dejó para después.
El resultado es predecible: las organizaciones están gastando entre 4 y 5 veces su presupuesto original en cargas de trabajo de IA. No porque la tecnología sea cara por naturaleza, sino porque nadie diseñó la arquitectura con restricciones de costo integradas. Se aprovisionaron instancias GPU sin políticas de escalamiento. Se entrenaron modelos sin métricas de costo por resultado. Se desplegaron pipelines de inferencia sin saber cuánto cuesta cada predicción.
Y ahora, cuando la factura llega, la respuesta más común es: "necesitamos FinOps." Lo que no se dice es que FinOps implementado como auditoría retrospectiva solo puede recuperar una parte del desperdicio. El daño estructural ya está hecho.
El estado real de FinOps en 2026
Los datos del State of FinOps 2026 muestran un cambio radical en el alcance de la disciplina. El 98% de los practicantes de FinOps ahora gestiona gasto en IA. Hace dos años, FinOps era sinónimo de optimización de instancias EC2 y almacenamiento S3. Hoy cubre IA, SaaS, licenciamiento, nube privada y centros de datos propios.
El mercado global de FinOps alcanzó $12.4 mil millones en 2025 y se proyecta en $28 mil millones para 2028. FinOps ya no reporta a un gerente de infraestructura perdido en el organigrama: el 78% de las funciones de FinOps ahora reporta directamente al CTO o CIO, un aumento de 18 puntos respecto a 2023.
Estos números dicen algo claro: la industria reconoce que el gasto cloud y de IA es un problema de dirección, no de operaciones. Pero reconocer el problema no es lo mismo que resolverlo a tiempo.
Por qué FinOps tardío no funciona
Hay una diferencia fundamental entre implementar FinOps como parte del diseño de una carga de trabajo y agregarlo después de que la carga ya está en producción. Los números lo demuestran:
- Sin FinOps: las organizaciones desperdician entre el 32% y 40% de su gasto cloud. En cargas de IA, ese porcentaje puede ser mayor porque las instancias GPU son entre 3 y 10 veces más caras que las instancias de cómputo general.
- Con FinOps maduro: el desperdicio baja a entre 15% y 20%. La reducción promedio después de la implementación es de 25-30%.
Esa reducción de 25-30% suena bien en una presentación. Pero si ya gastaste 4x tu presupuesto original, recuperar un 30% sigue dejándote en casi 3x. El problema no fue la falta de optimización — fue la falta de diseño.
Cuando una organización aprovisiona un clúster de GPUs A100 para fine-tuning sin definir cuántas horas de entrenamiento justifica el caso de negocio, FinOps no puede arreglar la decisión original. Puede sugerir instancias spot, puede identificar recursos ociosos, puede negociar reservas. Pero no puede rediseñar una arquitectura que no tenía restricciones económicas desde el inicio.
El error es tratar la IA como otro workload
Las cargas de trabajo de IA no se comportan como las cargas tradicionales de cloud. Un servidor web escala linealmente con tráfico. Un pipeline de inferencia escala con la complejidad del modelo, el tamaño del contexto, la frecuencia de invocación y la latencia requerida. La relación entre uso y costo no es proporcional — es exponencial en ciertos rangos.
Esto significa que las herramientas clásicas de FinOps — rightsizing, instancias reservadas, savings plans — son necesarias pero insuficientes para cargas de IA. Lo que se necesita es un cambio en la unidad de medición:
La unidad económica de la IA no es costo por token ni costo por hora de GPU. Es costo por resultado de negocio. Si no puedes medir eso, no sabes si tu inversión en IA está generando valor o destruyéndolo.
Costo por ticket resuelto. Costo por lead calificado. Costo por documento procesado. Costo por decisión de crédito automatizada. Esas son las métricas que hacen que la economía de la IA funcione. Y esas métricas solo existen si se diseñan desde la arquitectura, no si se agregan como un dashboard retrospectivo.
Qué hacen las organizaciones que sí controlan su gasto en IA
Las organizaciones que reportan control real sobre su gasto en IA comparten tres características que no tienen nada que ver con la herramienta de FinOps que eligieron:
- Definen presupuesto por caso de uso antes de aprovisionar. No "cuánto cuesta el GPU por hora" sino "cuánto estamos dispuestos a invertir para automatizar este proceso, y cuál es el retorno esperado en 90 días." Si la economía no cierra antes de encender la primera instancia, no se enciende.
- Miden costo por resultado, no costo por recurso. El dashboard no muestra consumo de GPU — muestra costo por transacción procesada, por predicción generada, por caso resuelto. Esto permite comparar el costo de la solución de IA contra el costo del proceso manual o de no hacer nada.
- Integran restricciones de costo en la arquitectura. Límites de auto-scaling con topes económicos. Políticas de apagado automático de entrenamiento cuando el costo supera un umbral. Selección de modelo basada en la relación precisión/costo, no solo en precisión. Circuit breakers financieros que detienen pipelines antes de que el gasto se dispare.
Ninguna de estas tres cosas es responsabilidad exclusiva de un equipo de FinOps. Son decisiones de arquitectura que requieren que el CTO, el equipo de ingeniería y la función financiera estén en la misma mesa desde el diseño.
FinOps es necesario. Pero no es suficiente si llega tarde.
No estamos argumentando contra FinOps. Es una disciplina crítica y su evolución para cubrir IA, SaaS y multi-cloud es exactamente lo que el mercado necesita. Lo que argumentamos es contra el timing.
Implementar FinOps después de que los costos se dispararon es como poner un medidor de agua después de la inundación. Te dice cuánta agua perdiste. No evita la siguiente inundación.
En Ábargon diseñamos arquitecturas de IA con restricciones económicas integradas desde la fase cero. No como un módulo aparte ni como una auditoría trimestral. Como parte del diseño mismo: qué modelo, qué infraestructura, qué métricas de costo por resultado, qué circuit breakers, qué gobernanza financiera. Antes de escribir la primera línea de código.
Porque la pregunta que importa no es "cuánto estamos gastando en cloud." La pregunta que importa es "cuánto valor de negocio estamos generando por cada dólar de cloud que gastamos." Y si no puedes responder eso hoy, cada día que pasa es dinero que no regresa.