FinOps le dio a los equipos un manual real para ordenar los costos en la nube: etiqueta tus recursos, mide la unit economics y arma modelos de chargeback que responsabilicen a Engineering y a Finanzas por los mismos números. Funciona. Hoy la mayoría de las organizaciones cloud maduras opera con alguna versión de esto.
La infraestructura de IA está rompiendo ese manual, y la mayoría de los equipos todavía no dimensiona qué tan a fondo es la ruptura.
Qué significa hoy FinOps para IA
FinOps para IA es la extensión natural de la disciplina de gestión financiera cloud hacia los workloads de machine learning e IA generativa. El objetivo no cambió respecto del FinOps tradicional: conectar el gasto con el equipo, producto o cliente que lo genera, para que Finanzas e Engineering decidan a partir de los mismos números. Lo que cambió es la infraestructura por debajo, y la mecánica de cómo un LLM procesa realmente un request es un buen punto de partida si esa infraestructura te resulta poco familiar.
En la práctica, FinOps para IA suele cubrir un puñado de capacidades centrales, cada una heredada del manual clásico de FinOps y aplicada a un nuevo tipo de workload.
Asignación de costos. Etiquetar instancias de GPU como lo harías con una VM. Mapear API keys, modelos y proyectos a equipos, productos o clientes. Armar el mismo mapa de ownership para un cluster de entrenamiento que armarías para un namespace de Kubernetes.
Showback y chargeback. Generar reportes que le digan a un equipo cuánto costó su corrida de entrenamiento, o cómo se comportó el gasto de inferencia de una feature el mes pasado, del mismo modo en que el showback viene funcionando hace años para compute y storage.
Unit economics. Traducir el gasto en bruto a un número accionable para el negocio: costo por inferencia, costo por usuario activo, costo por feature, aplicando la misma lógica que ya existe hace tiempo para costo por transacción o costo por request.
Presupuestos, alertas y detección de anomalías. Definir umbrales por equipo o por modelo y recibir avisos cuando el consumo de tokens o la longitud de los prompts se dispara de forma inesperada, replicando las herramientas de presupuesto y anomalías que ya son estándar en cloud cost management.
Gobierno y enforcement de políticas. Definir quién puede levantar qué, con qué modelo y con qué techo de costo: el equivalente en IA a las cuotas de recursos y las políticas de tagging.
Para un conjunto relevante de workloads de IA, este enfoque todavía funciona bien. Un cluster de entrenamiento dedicado con un owner claro. Un endpoint de inferencia single-tenant que sirve a un solo producto. Un modelo con un patrón de llamadas predecible y trazable. Lo etiquetas, lo mides, listo.
Dónde funciona el manual y dónde no
El problema empieza con los workloads que no se parecen a eso, y cada vez son la mayoría.
La infraestructura compartida rompe el modelo de ownership
Una cuenta de API de modelo administrado suele servir a decenas de equipos desde una sola línea de facturación. En la factura no hay ningún límite por equipo, solo lo que puedas reconstruir después a partir de metadata que puede ser confiable o no. Un cluster de GPU compartido corre inferencia para varios productos en simultáneo, con ciclos de compute entrelazados a un nivel al que ningún tag puede llegar.
Los gateways borran la señal de la que depende el tagging
Un LLM gateway agrupa requests de agentes, pipelines automatizados y usuarios humanos en un único flujo saliente y, al hacerlo, borra la identidad del caller antes de que llegue al proveedor. Para cuando el request llega al modelo, el contexto que te permitiría atribuirlo a un equipo o feature normalmente ya se perdió. Los tags aplicados aguas arriba no sobreviven al salto.
Los workloads agénticos disparan costos que ningún SDK envolvió
Un workload agéntico puede lanzar sub-agentes que disparan costos reales de infraestructura —compute, memoria, red, carga sobre la base de datos— sin ninguna relación con la línea original de la factura de IA de la que provienen. No hay tag ni convención de nombres que conecte nada de eso con el request que inició la cadena, porque la cadena no estaba prevista cuando se construyó la instrumentación.
La instrumentación no puede ir a la velocidad de la infraestructura de IA
El problema de cobertura es solo la mitad. Los workloads de IA se mueven a un ritmo al que la instrumentación no le puede seguir el paso. Un agente puede lanzar mil sub-agentes de un día para el otro. Para cuando Engineering identificó el nuevo patrón de llamadas, lo envolvió en un SDK y publicó el update, la factura ya llegó. Esto no es un problema de disciplina de tagging que se resuelva con mejor gobierno o convenciones de nombres más estrictas. Es una realidad arquitectónica de cómo corre la infraestructura de IA, y aplica sin importar qué tan disciplinada sea la práctica de FinOps.
El problema del gasto huérfano
Habla con cualquier practitioner de FinOps a seis meses de arrancar un programa de costos de IA y vas a escuchar alguna versión de la misma historia: una línea que creció 40 por ciento mes a mes, sin un owner que nadie logra identificar. Los tags apuntan a una cuenta de servicio que comparten tres equipos. La convención de nombres que funcionaba para VMs nunca se aplicó a los endpoints de inferencia. Alguien armó una planilla para reconstruir el ownership a mano y ya quedó desactualizada antes de terminarla.
Ese gasto no está sin dueño. Está sin atribuir, porque el método con el que se buscó identificarlo se construyó para infraestructura que no se mueve, no se comparte y no genera sus propios hijos en tiempo de ejecución. La infraestructura de IA hace las tres cosas.
FinOps para IA vs. FinOps cloud tradicional
| FinOps cloud tradicional | FinOps para IA | |
|---|---|---|
| Método principal de atribución | Tags, convenciones de nombres, estructura de cuentas | Los tags funcionan hasta que aparecen la infraestructura compartida o los gateways |
| Estabilidad de la infraestructura | Relativamente estática; el ownership suele ser claro | Altamente dinámica; el ownership puede cambiar dentro de un mismo request |
| Brechas de cobertura | Mayormente un problema de disciplina de tagging | Arquitectónicas: hay workloads que directamente no se pueden etiquetar |
| Velocidad de cambio | Ciclos de cambio predecibles y gobernados | Puede cambiar de un día para el otro, más rápido de lo que se puede actualizar la instrumentación |
| Dónde se rompe | Edge cases, recursos legacy | Clusters de GPU compartidos, LLM gateways, workloads agénticos y multi-agente |
Qué viene después: medir por debajo del tag
Si la arquitectura de los workloads de IA vence a la instrumentación por diseño, entonces la instrumentación es la capa equivocada desde donde medir. La alternativa es medir desde un lugar donde la instrumentación no se pueda saltear, filtrar ni desbordar: el kernel.
Esa es la arquitectura detrás de Attribute™ by DoiT. Despliega un sensor eBPF dentro del sistema operativo que observa el consumo real —cada token, cada request al modelo, cada ciclo de GPU— a medida que ocurre, y mapea cada unidad de vuelta al proceso, contenedor y request responsable. Sin tags. Sin SDKs. Sin cambios de código. Después cruza esa data con la facturación de proveedores como Anthropic, OpenAI, Google Gemini y AWS Bedrock, separando de forma automática los tokens cacheados, de razonamiento, de entrada y de salida.
Esta es la capa donde la Tokenomics se vuelve operativa: economía a nivel de token, atribuida de forma automática, para los workloads a los que el tagging nunca iba a llegar. Tokenomics sin tags, sin SDKs y sin cambios de código.
Por qué esto importa ahora
Nuestra investigación —una encuesta a 500 líderes de finanzas realizada por Sapio Research— encontró que el 79 por ciento de las empresas ya sufrió sobrecostos en IA, y solo el 15 por ciento puede calcular el ROI de IA sin cuellos de botella significativos. La brecha no es un problema de proceso que los equipos todavía no llegaron a resolver. Es un problema de medición que se resuelve en otra capa.
DoiT gestionó más de 8 mil millones de dólares en gasto cloud para 4.500 clientes en 27 países, y ya vimos este mismo patrón antes en cada gran categoría de costos: optimización de compute, gestión de commitments, asignación de costos en Kubernetes. Los equipos que resuelven bien la base de medición desde temprano toman mejores decisiones en todo lo que viene después. Los que esperan pasan años reconstruyendo un contexto que podrían haber tenido desde el día uno.
Estamos trabajando con la Tokenomics Foundation, junto con JR Storment y la FinOps Foundation, para ayudar a definir cómo debería ser esa base para toda la industria.
FAQ
¿Qué es FinOps para IA?
FinOps para IA es la aplicación de las prácticas de gestión financiera cloud —asignación de costos, showback y chargeback, unit economics, presupuestos y detección de anomalías— a los workloads de machine learning e IA generativa. Extiende la disciplina que funcionó para la infraestructura cloud tradicional hacia una nueva categoría de gasto.
¿Por qué el tagging no funciona para atribuir costos de IA?
El tagging depende de una relación estable y trazable entre un recurso y su owner. Los clusters de GPU compartidos, los LLM gateways y los workloads agénticos rompen esa relación por diseño: los gateways borran la identidad del caller, la infraestructura compartida no tiene un límite claro de ownership y las cadenas agénticas disparan costos a los que nunca se les aplicó un tag.
¿Cuál es la diferencia entre FinOps para IA y Tokenomics?
FinOps para IA describe la práctica de aplicar disciplina de gestión de costos a los workloads de IA. Tokenomics es la disciplina de medición subyacente: entender cuánto vale cada token, quién lo consumió y si el gasto se justifica por el resultado, más allá de que el workload se pueda etiquetar o no.
¿Se puede hacer FinOps para IA sin instrumentación?
Sí. La medición a nivel de kernel, usando tecnología como eBPF, observa el consumo a nivel del sistema operativo en lugar de depender de tags o SDKs. Esto permite atribuir workloads a los que la instrumentación tradicional no llega, incluidos los clusters de GPU compartidos y el tráfico enrutado por gateways.
¿Quién es dueño de FinOps para IA dentro de una organización?
Varía según la empresa, pero FinOps para IA suele ubicarse en la intersección entre el equipo actual de FinOps o cloud cost, la ingeniería de plataforma o infraestructura y, cada vez más, los equipos que construyen productos de IA directamente. Como el gasto en IA se mueve más rápido y toca a más equipos que el gasto cloud tradicional, la práctica suele requerir una colaboración más estrecha entre Finanzas y Engineering que el FinOps legacy, ya que ninguna de las dos partes tiene visibilidad completa por sí sola.
¿En qué se diferencia la asignación de costos de IA de la asignación de costos cloud?
La asignación de costos cloud suele mapear el gasto a un recurso con un owner relativamente estable: una instancia, un bucket, un namespace. La asignación de costos de IA tiene que contemplar consumo que cruza límites de ownership dentro de un mismo request: una GPU compartida sirviendo a varios productos, un gateway enrutando tráfico de varios equipos, un agente disparando costos en servicios que nunca tocó directamente. El objetivo de fondo es el mismo. La mecánica para llegar ahí, no.
¿Qué métricas debería medir un programa de FinOps para IA?
La mayoría de los programas mide alguna combinación de costo por token, costo por inferencia, costo por feature y costo por cliente o cuenta, junto con los splits de tokens de entrada, salida, cacheados y de razonamiento que varían según el proveedor. El mix adecuado depende de si la audiencia es Engineering —que suele querer detalle a nivel de workload— o Finanzas, que suele querer rollups a nivel de cuenta o feature atados a datos de ingresos o renovación.
¿Listo para ver tu verdadero costo real de IA por servicio?
Quince minutos para instalar. Sin instrumentación. Economía de tokens el mismo día.