La FinOps Foundation no lanzó la Tokenomics Foundation porque la gestión de costos de IA fuera un problema resuelto al que solo le hacía falta un nombre nuevo. Como ha escrito JR Storment, token economics es la disciplina a través de la cual se mide, se atribuye y se conecta el consumo de IA con los resultados de negocio, y la mayoría de las empresas todavía no tiene una forma confiable de hacerlo. Una nueva disciplina no se construye alrededor de un problema que ya está resuelto.
El instinto es resolver esto como los equipos han resuelto siempre los problemas de costos en la nube: etiquetar recursos, envolver llamadas en un SDK, imponer convenciones de nombres. Esa receta funcionó para la infraestructura tradicional. No funciona para la infraestructura de IA, y las razones son arquitectónicas, no de proceso.
Un enfoque más reciente, la medición a nivel de kernel con eBPF, esquiva por completo el problema de la instrumentación al observar el consumo directamente en el sistema operativo, sin tags, sin SDKs y sin cambios de código. A eso se refiere "tokenomics sin tags, SDKs ni cambios de código". A continuación explicamos por qué el enfoque de instrumentación se rompe y cómo la atribución a nivel de kernel funciona de otra manera.
¿Qué es la atribución de costos de IA (y por qué hoy está rota)?
La atribución de costos de IA es la práctica de rastrear el gasto en IA (ciclos de GPU, llamadas a APIs de modelos, consumo de tokens) hasta el cliente, feature, equipo o agente responsable. Es el equivalente en la era de la IA a la asignación de costos en la nube, con una diferencia crítica: la infraestructura que hay que medir no se queda quieta el tiempo suficiente para que los métodos tradicionales la alcancen.
La asignación tradicional de costos depende de la instrumentación. Etiquetas un recurso y ya sabes de quién es. Envuelves una llamada a una API en un SDK y sabes qué equipo la hizo. Ese enfoque es imperfecto incluso en entornos cloud tradicionales (la cobertura de tags es siempre un trabajo en curso), pero alcanza, porque la infraestructura debajo es relativamente estática y la propiedad es relativamente clara.
La infraestructura de IA rompe cada uno de esos supuestos.
Una sola cuenta de API de modelo gestionado atiende a decenas de equipos a la vez. Un cluster de GPU compartido corre workloads de varios productos en simultáneo, sin ninguna frontera de recursos entre ellos. Un gateway de LLM agrupa solicitudes de agentes, pipelines y usuarios humanos en un único flujo saliente, y en el camino borra la identidad de quien llamó. Un workload agéntico puede generar sub-agentes que disparan costos derivados (cómputo, memoria, red) sin ningún vínculo rastreable con la línea que los originó.
No hay tag que sobreviva a un salto por un proxy de LLM. No hay SDK con el que puedas envolver una GPU compartida. Y aun donde la instrumentación podría funcionar en teoría, los workloads de IA se mueven más rápido de lo que se puede desplegar la instrumentación: un agente puede generar mil sub-agentes en una noche, y la factura llega mucho antes de que alguien actualice el código de seguimiento.
La brecha de atribución en el gasto de IA no es un problema de proceso. Es una consecuencia estructural de cómo funciona realmente la infraestructura de IA.
Por qué los enfoques tradicionales chocan contra un techo
Las herramientas creadas para resolver esto suelen encajar en una de tres categorías.
Las herramientas de la capa de facturación trabajan a posteriori, reconciliando las facturas de los proveedores en reportes. Te dicen cuánto se gastó, de forma agregada, mucho después de que el workload que generó el costo terminó de ejecutarse.
Las herramientas con agentes de Kubernetes instrumentan la capa de orquestación y rastrean el uso de recursos a nivel de pod y contenedor. Funcionan mientras el workload se mantenga dentro de Kubernetes y dentro de los límites de un solo cluster. Pierden visibilidad en el momento en que una solicitud cruza una API gestionada, una GPU compartida o un gateway de LLM.
Las herramientas de inferencia por metadatos intentan saltarse por completo el etiquetado manual, deduciendo la propiedad a partir de los metadatos disponibles y proponiendo tags virtuales de forma automática. Es una mejora significativa frente al etiquetado manual, pero hereda el mismo techo: solo puede atribuir aquello que los metadatos alcanzan a describir, y en la capa donde realmente ocurre el consumo de IA, esos metadatos no existen.
Los tres enfoques reconstruyen la atribución a posteriori, a partir de señales que están por encima de la capa donde ocurre el consumo real. Ninguno puede ver dentro de una GPU compartida. Ninguno puede seguir un token a través de un gateway hasta el agente que lo disparó.
Las plataformas que sí pueden son las que miden desde debajo de las tres capas, no al lado: en el kernel, donde el consumo se observa directamente en lugar de inferirse.
Cómo funciona la atribución a nivel de kernel
Un enfoque a nivel de kernel despliega un sensor eBPF directamente dentro del sistema operativo. El despliegue suele tomar unos minutos: sin cambios de código, sin editar manifiestos de Kubernetes y sin ningún SDK que integrar.
Una vez en marcha, el sensor observa el consumo real a medida que ocurre (cada token, cada solicitud a un modelo, cada ciclo de GPU) y asocia cada unidad al proceso, contenedor, pod y solicitud responsable. Esos datos en runtime se pueden cruzar con la facturación de proveedores como Anthropic, OpenAI, Google Gemini y AWS Bedrock, separando de forma automática los tokens en caché, los tokens de razonamiento, los tokens de entrada y los de salida.
El resultado son token economics por cliente, por feature y por agente, generadas de forma continua, sin instrumentación, sin etiquetado y sin cambios de código. Como el sensor opera en el kernel, ve el consumo directamente. No hay nada que inferir, ni nada tras lo que un agente, un gateway o una GPU compartida puedan esconderse.
Qué cambia la atribución a nivel de kernel para cada equipo
Para los equipos de VP of Engineering, la atribución a nivel de kernel significa un chargeback defendible. Los costos de GPU se rastrean hasta el workload que los generó, lo que pone fin a las disputas de facturación entre equipos que comparten infraestructura.
Para los profesionales de FinOps, significa el fin del spreadsheet huérfano. Los tags se degradan. Las convenciones de etiquetado quedan desactualizadas en cuanto sale un servicio nuevo. La medición a nivel de kernel no depende de que nadie se acuerde de etiquetar nada.
Para los CFOs y líderes de Finanzas, significa visibilidad del ROI ligada a features y segmentos de clientes específicos, no a estimaciones a nivel de cuenta. Saber que una feature impulsa la probabilidad de renovación es un tipo de insight muy distinto a saber cuánto gastó la cuenta en agregado el mes pasado.
Por qué esto importa ahora
El patrón se repite en cada categoría anterior de costos en la nube: optimización de cómputo, gestión de commitments, asignación de costos en Kubernetes. Las organizaciones que establecen desde temprano la base de medición correcta toman mejores decisiones en cada paso posterior. Las que posponen la atribución hasta que las facturas ya son grandes se pasan años reconstruyendo un contexto que pudieron haber tenido desde el día uno.
El gasto en IA se mueve más rápido que cualquier categoría anterior, y los datos lo respaldan. Una encuesta de Sapio Research a 500 líderes de Finanzas encontró que el 79% de las empresas ya ha tenido sobrecostos en IA, y solo el 15% puede calcular el ROI de la IA sin cuellos de botella significativos. La ventana para sentar la base correcta es ahora, no después de la próxima factura sorpresa.
Cómo lo aborda DoiT
DoiT gestiona más de 8 mil millones de dólares en gasto cloud de 4,500 clientes en 27 países, y ha visto repetirse este patrón de medición en cada gran categoría de costos en la nube. Attribute™ by DoiT aplica el enfoque a nivel de kernel descrito arriba: un sensor eBPF que se despliega en unos quince minutos, sin tags, sin SDKs y sin cambios de código, y que entrega token economics por cliente, por feature y por agente el mismo día en que se instala.
DoiT también es marketing partner de la Tokenomics Foundation y trabaja junto a JR Storment y la FinOps Foundation para ayudar a definir estándares abiertos de la industria para token economics de IA a medida que la categoría madura.
Reserva una demo para ver Attribute™ en tu propio entorno.