Puedes ver tu factura de IA. Incluso puedes explicarla en parte. Pero no logras atribuir ese gasto a tus clientes, equipos o usuarios. Y por eso mismo, tampoco puedes afirmar si estás fijando precios con márgenes sanos. Esa brecha - entre lo que gastas y lo que puedes justificar - es el problema que resolvemos con Attribute™.
La atribución de costos en la nube nunca ha sido sencilla, y menos con recursos compartidos. Llevamos quince años ayudando a más de 4000 clientes a desenredar infraestructura compartida, aplicar políticas de tagging y armar modelos de chargeback que aguantan cualquier auditoría. Siempre ha sido un problema difícil. La IA lo complicó todavía más.
La infraestructura sobre la que corre la IA se construyó para velocidad y escala, no para atribución. Los enfoques de atribución con los que la industria se conformó en la nube (tags) no se trasladan bien. Es una realidad arquitectónica - y exigía una respuesta distinta.
La trampa de la instrumentación
La respuesta estándar a la atribución de costos siempre ha sido la instrumentación. Etiqueta tus recursos. Envuelve tus llamadas de API en un SDK. Impón estándares de nomenclatura. Arma un pipeline que agregue esas señales en un dashboard.
Para la infraestructura tradicional en la nube, el enfoque funciona, aunque no de forma perfecta. La infraestructura compartida subyacente es relativamente estática. El modelo de ownership es relativamente claro. Se puede llegar a un "suficientemente bueno" haciendo algunas concesiones.
La infraestructura de IA rompe todos los supuestos sobre los que se apoya ese enfoque.
Un único modelo gestionado atiende a varios clientes al mismo tiempo. Un cluster de GPU compartido corre modelos de varios productos a la vez. Un gateway de LLM agrupa solicitudes de agentes, harnesses y humanos en un solo flujo saliente. Por no hablar de que un workload agéntico puede generar sub-agentes que disparan costos de infraestructura sin ninguna relación visible con la línea de la factura de IA que los originó.
No existe un SDK con el que envolver una GPU compartida. No existe un tag que sobreviva al salto por un proxy de LLM. Y los workloads de IA no se mueven a un ritmo que la instrumentación pueda seguir. Un agente puede generar mil sub-agentes de la noche a la mañana. Para cuando envolviste los nuevos patrones de llamada en un SDK y desplegaste la actualización, la factura ya cayó.
La brecha de atribución en el gasto de IA no es un problema de proceso que se resuelva instrumentando más. Es una realidad arquitectónica de cómo funciona la infraestructura de IA.
"La brecha de atribución en el gasto de IA no es un problema de proceso que se resuelva instrumentando más. Es una realidad arquitectónica de cómo funciona la infraestructura de IA."
Esa es la idea que nos llevó a Attribute™. Si la arquitectura de los workloads de IA derrota a la instrumentación por diseño, entonces la instrumentación es la respuesta equivocada. Hay que medir desde una capa que lo vea todo - antes de cualquier abstracción, antes de cualquier proxy, antes de cualquier frontera de ownership. Hay que medir en el kernel del sistema operativo.
Un enfoque distinto
Attribute™ despliega un sensor eBPF que opera dentro del sistema operativo. Observa el consumo real - cada token, cada solicitud a un modelo, cada ciclo de GPU - a medida que ocurre, y asocia cada unidad al proceso, contenedor, pod y solicitud responsables. Después cruza esos datos con la facturación de los proveedores - Anthropic, OpenAI, Google Gemini y AWS Bedrock - separando de forma automática los cached tokens, reasoning tokens, input tokens y output tokens.
El resultado es una economía de tokens por cliente, por feature y por agente: generada de forma continua, sin instrumentación, sin tagging y sin cambios de código.
Las herramientas que hay hoy (y hay algunas decentes) caen en dos campos: 1. Las que piden a los Engineers definir la lógica de asignación en código, y 2. Las que usan inferencia de metadata para proponer tags virtuales de forma automática.
Ambas son mejoras notables frente al tagging manual. Pero ninguna puede ver dentro de una GPU compartida. Ninguna puede seguir un token a través de un gateway de LLM hasta el cliente o usuario que lo originó. El obstáculo no es la herramienta. Es el método.
Cualquier enfoque que dependa de la metadata para reconstruir la atribución va a chocar con la misma pared, porque la metadata no existe en la capa donde de verdad ocurre el consumo.
La medición a nivel de kernel no es un detalle técnico. Es la única arquitectura que produce atribución completa en toda la superficie de la infraestructura moderna de IA.
Por qué Tokenomics es el marco correcto
Con este nuevo enfoque, estamos ayudando activamente a construir la categoría de Tokenomics, y es algo muy específico. No es gestión de costos de IA - la industria está llena de esa conversación, y la mayor parte es solo vocabulario de FinOps de la nube aplicado a una nueva línea de factura.
Tokenomics es la disciplina de entender cuánto vale realmente cada token para tu negocio: quién lo consumió, qué produjo y si el gasto se justificó con el resultado.
Eso exige atribución a nivel de token. No a nivel de cuenta. No a nivel de equipo. A nivel de token. Necesitas saber que una sesión específica de un cliente consumió 47.000 tokens repartidos en tres modelos, que 31.000 de ellos se usaron en una feature que impulsa el 80% de la probabilidad de renovación, y que los 16.000 restantes se gastaron en una feature experimental que aún no llega a producción. Ese es el dato que te permite decidir con criterio dónde invertir y dónde recortar.
A ese dato no se llega con tagging. Tampoco con SDKs. Solo se llega si mides en la capa donde ocurre el consumo real.
La Linux Foundation anunció recientemente la intención de lanzar la Tokenomics Foundation, en alianza con la FinOps Foundation, para establecer estándares abiertos de industria para la economía de tokens de IA. JR Storment, Executive Director de la FinOps Foundation y un socio cercano de DoiT, lo dijo sin rodeos: ponerle nombre al problema no es resolverlo.
Y tiene toda la razón. La categoría ya tiene nombre y un hogar institucional. Attribute™ es la capa de medición que la vuelve operativa.
¿Por qué DoiT y por qué ahora?
DoiT ha gestionado más de 20 mil millones de dólares en gasto de nube para 4.500 clientes en 27 países. Hemos visto surgir todas las grandes categorías de costos de nube: optimización de compute, gestión de commitments, asignación de costos de Kubernetes. Los equipos que sientan pronto una base de medición sólida toman mejores decisiones en cada paso posterior. Los que aplazan la atribución hasta que las facturas ya son grandes pasan años reconstruyendo un contexto que podrían haber tenido desde el día uno.
El gasto en IA se mueve más rápido que cualquier categoría anterior. Nuestra propia investigación - una encuesta a 500 líderes de finanzas - arrojó que el 79% de las empresas ya han sufrido sobrecostos en IA, y solo el 15% dice poder calcular con precisión el ROI de la IA sin cuellos de botella importantes. La ventana para adoptar el toolset correcto es ahora, no después de la próxima factura sorpresa.
Hay una segunda señal que vale la pena mencionar. A medida que la IA pasa de la experimentación a ser infraestructura de producción, las preguntas cambian. Ya no es "cuánto estamos gastando" - sino "cuánto cuesta atender a cada cliente", "qué features de IA nos están comprimiendo los márgenes" y "qué agentes están consumiendo gasto sin resultados que mostrar". Tu directorio hace estas preguntas. Tu CFO también. Los datos de gasto a nivel de cuenta producen respuestas a nivel de cuenta. La atribución a nivel de kernel - por cliente, por agente, por feature - produce respuestas que sí cambian decisiones.
Por eso construimos esto. Y por eso lo lanzamos en DoiT ahora.
Sobre Attribute™
Quince minutos para instalarlo. Sin instrumentación. Economía de tokens el mismo día. Si quieres ver cómo funciona Attribute™ en tu propio entorno, agenda una demo aquí.