Antes de ser Field CTO en DoiT, trabajé como profesional de FinOps. Redacté políticas de tagging. Perseguí recursos sin etiquetar la semana previa a una revisión de presupuesto. Armé modelos de chargeback técnicamente defendibles que aun así encendían una discusión en cada reunión, porque el cluster compartido de alguien no se dividía como lo hacía su P&L.
Así que cuando lanzamos Attribute™ esta semana, entendí por qué la conversación arranca con los tokens: input, output, cacheados, de razonamiento. Costo por request, por cliente, por feature, por agente. Ese enfoque es correcto. Solo que no lo veo completo.
Contar tokens es fácil. La pregunta difícil es por qué existieron en primer lugar. ¿Un cliente adoptó una nueva feature de IA? ¿Un workflow interno migró en silencio a un modelo más caro? ¿Un prompt está consumiendo diez veces los tokens que necesita? ¿Un agente disparó cientos de tareas derivadas que nadie pidió? En un reporte de costos, esos cuatro escenarios se ven casi idénticos. Para el negocio, no podrían ser más distintos.
El tagging nunca fue el objetivo
Hay algo que quienes trabajamos en esto sabemos y que rara vez se dice en voz alta: nadie quería tags. Lo que se buscaba era accountability: que las personas correctas vieran la información de costo correcta a tiempo para actuar. El tagging era simplemente la mejor forma de implementar esa accountability para la arquitectura que teníamos. Cuando una VM servía a una aplicación y una cuenta correspondía a un equipo, la propiedad, el consumo y la responsabilidad se alineaban. Los tags funcionaban porque la arquitectura los dejaba funcionar.
Después la arquitectura cambió. Kubernetes volvió compartida la infraestructura. Serverless la volvió abstracta. Los servicios administrados movieron el gasto hacia requests, queries e invocaciones. Vadim ya escribió sobre por qué la instrumentación se rompe y Josh cubrió exactamente dónde falla el tagging, así que no lo voy a volver a discutir acá. En pocas palabras: lo que se factura y lo que genera la demanda se distanciaron, y la IA terminó de separarlos. Una sola cuenta de modelo o un gateway puede agregar requests de todos los productos, equipos, agentes y empleados que tengas. Para cuando llega la factura, el contexto que la explica ya se perdió.
El mismo número, cuatro decisiones distintas
Esta es la parte que más me importa, porque marca la diferencia entre reportar y decidir.
Digamos que tu gasto en IA subió un 40% el mes pasado. Por mis años en la trinchera, te puedo decir qué respalda ese número por sí solo: nada. Lo que hagas después depende por completo de por qué pasó.
Si creció porque una feature orientada al cliente está impulsando la adopción y la retención, invertís más. Eso no es un problema de costo. Es una señal de crecimiento disfrazada de problema de costo.
Si creció porque un workflow interno está usando un modelo premium para una tarea que un modelo más chico resuelve bien, optimizás. Es trabajo de engineering con un retorno medible.
Si creció porque un agente está disparando llamadas derivadas innecesarias, gobernás: rate limits, presupuestos, controles.
Y si creció porque un cliente enterprise concentra una porción desproporcionada de tu costo de inferencia, eso ya ni siquiera es una conversación de FinOps. Es de pricing, packaging y margen: una conversación para tu CFO y tu equipo de producto.
Cuatro causas. Cuatro responsables. Cuatro acciones completamente distintas. El número de costo no te dice qué reunión agendar. El contexto sí.
Eso es lo que Attribute™ realmente cambia. Como mide el consumo real en el kernel y lo cruza con la facturación del proveedor, el "por qué" llega junto con el número: este cliente, esta feature, este agente, este workflow. No porque contar tokens sea el punto, sino porque la atribución es lo que convierte un número en una decisión.
Qué cambia en la práctica
En nuestra encuesta a 500 líderes de finanzas, el 79% ya había tenido sobrecostos de IA, y solo el 15% podía calcular el ROI de IA sin cuellos de botella importantes. No lo leo como un problema de disciplina. Esos equipos no están fallando en FinOps. Están aplicando el playbook viejo contra una arquitectura que lo desarma.
Lo que creo que viene, y lo que les digo a los clientes en el campo: FinOps deja de ser una función de reporting que reconstruye el contexto después del hecho y pasa a estar embebida donde se toman las decisiones. Los Engineers ven las implicaciones de costo mientras diseñan, no treinta días después. Los equipos de producto conocen la economía unitaria de una feature antes de la discusión de precios, no después. Finanzas conecta el gasto de IA con el margen por cliente en lugar de quedarse mirando una línea indivisible. Los equipos de plataforma de IA no solo ven qué modelos corrieron, sino qué casos de uso generaron valor y cuáles generaron pérdida.
Nada de eso funciona sin atribución. Es la capa sobre la que se apoya todo lo demás en FinOps, y para los workloads de IA es la capa que nos venía faltando.
Pasé años de mi carrera reconstruyendo el contexto después de que llegaba la factura. La próxima era de FinOps consiste en tenerlo antes de gastar el dinero. Eso es lo que este lanzamiento significa para mí.
Quince minutos de instalación. Sin instrumentación. La economía de tus tokens el mismo día. Agendá una demo para ver Attribute™ en tu propio entorno.