A FinOps Foundation não lançou a Tokenomics Foundation porque a gestão de custos de IA fosse um problema resolvido só esperando um nome novo. Como JR Storment já escreveu, a economia de tokens é a disciplina pela qual o consumo de IA é medido, atribuído e conectado aos resultados de negócio — e a maioria das empresas ainda não tem uma forma confiável de fazer isso. Ninguém cria uma nova disciplina em torno de um problema que já está sob controle.
O instinto é resolver isso como as equipes sempre resolveram problemas de custo em nuvem: colocar tags nos recursos, envolver chamadas em um SDK, aplicar convenções de nomenclatura. Esse manual funcionou para a infraestrutura tradicional. Mas não funciona para a infraestrutura de IA, e os motivos são arquiteturais, não de processo.
Uma categoria mais recente de abordagem, a medição em nível de kernel com eBPF, contorna totalmente o problema de instrumentação ao observar o consumo diretamente no sistema operacional, sem tags, sem SDKs e sem mudanças no código. É a isso que "tokenomics sem tags, SDKs ou mudanças no código" se refere. A seguir, veja por que a abordagem de instrumentação não se sustenta e como a atribuição em nível de kernel funciona de outro jeito.
O que é atribuição de custos de IA (e por que ela está quebrada hoje)?
Atribuição de custos de IA é a prática de rastrear gastos com IA — ciclos de GPU, chamadas de API de modelos, consumo de tokens — até o cliente, feature, time ou agente específico responsável por eles. É o equivalente, na era da IA, da alocação de custos em nuvem, com uma diferença crítica: a infraestrutura que precisa ser medida não fica parada tempo suficiente para os métodos tradicionais darem conta.
A alocação tradicional de custos depende de instrumentação. Você coloca uma tag em um recurso e sabe de quem ele é. Envolve uma chamada de API em um SDK e sabe qual time a fez. Essa abordagem é imperfeita mesmo em ambientes de nuvem tradicionais — cobertura de tags é um trabalho em andamento eterno —, mas é boa o suficiente, porque a infraestrutura por baixo é relativamente estática e a propriedade, relativamente clara.
A infraestrutura de IA quebra cada uma dessas premissas.
Uma única conta de API de modelo gerenciado atende dezenas de times ao mesmo tempo. Um cluster de GPU compartilhado roda workloads de vários produtos simultaneamente, sem fronteira em nível de recurso entre eles. Um gateway de LLM agrega requisições de agentes, pipelines e usuários humanos em um único fluxo de saída, apagando a identidade de quem fez a chamada no caminho. Um workload agêntico pode gerar sub-agentes que disparam custos downstream — compute, memória, rede — sem um vínculo rastreável até o item de linha que os originou.
Não existe tag que sobreviva a um salto por um proxy de LLM. Não existe SDK que dê para envolver em uma GPU compartilhada. E mesmo onde a instrumentação teoricamente funcionaria, os workloads de IA se movem mais rápido do que ela consegue ser implantada: um agente pode gerar mil sub-agentes de uma noite para a outra, e a conta chega muito antes de alguém atualizar o código de rastreamento.
A lacuna de atribuição nos gastos com IA não é um problema de processo. É uma consequência estrutural de como a infraestrutura de IA realmente funciona.
Por que as abordagens tradicionais esbarram em um teto
As ferramentas criadas para resolver isso geralmente caem em uma de três categorias.
Ferramentas de camada de billing atuam depois do fato, reconciliando faturas dos provedores em relatórios. Elas dizem o que foi gasto, no agregado, bem depois de o workload que gerou o custo já ter terminado de rodar.
Ferramentas com agente em Kubernetes instrumentam a camada de orquestração, acompanhando o uso de recursos em nível de pod e container. Elas funcionam enquanto o workload permanecer dentro do Kubernetes e dentro dos limites de um único cluster. Perdem visibilidade no instante em que uma requisição cruza uma API gerenciada, uma GPU compartilhada ou um gateway de LLM.
Ferramentas de inferência por metadados tentam pular totalmente o uso manual de tags, deduzindo a propriedade a partir dos metadados disponíveis e propondo tags virtuais automaticamente. É uma melhoria relevante em relação às tags manuais, mas herda o mesmo teto: só consegue atribuir o que existe em metadado para descrever — e, na camada onde o consumo de IA de fato acontece, esse metadado não existe.
As três abordagens estão reconstruindo a atribuição depois do fato, a partir de sinais que ficam acima da camada onde o consumo real ocorre. Nenhuma delas consegue enxergar dentro de uma GPU compartilhada. Nenhuma consegue seguir um token através de um gateway até o agente que o disparou.
As plataformas que conseguem são as que medem por baixo das três camadas, e não ao lado delas: no kernel, onde o consumo é observado diretamente, em vez de inferido.
Como funciona a atribuição em nível de kernel
A abordagem em nível de kernel implanta um sensor eBPF diretamente dentro do sistema operacional. A implantação costuma levar minutos: sem mudanças no código, sem editar manifests do Kubernetes, sem SDK para integrar.
Em execução, o sensor observa o consumo real conforme ele acontece — cada token, cada requisição a modelo, cada ciclo de GPU — e mapeia cada unidade de volta ao processo, container, pod e requisição responsável. Esses dados de runtime podem então ser cruzados com o billing dos provedores em fontes como Anthropic, OpenAI, Google Gemini e AWS Bedrock, separando automaticamente cached tokens, reasoning tokens, input tokens e output tokens.
O resultado é economia de tokens por cliente, por feature e por agente, produzida continuamente, sem instrumentação, sem tags e sem mudanças no código. Como o sensor opera no kernel, ele enxerga o consumo diretamente. Não há o que inferir, e não há onde um agente, um gateway ou uma GPU compartilhada possa se esconder.
O que a atribuição em nível de kernel muda para cada time
Para times de VP de Engenharia, atribuição em nível de kernel significa chargeback defensável. Custos de GPU são rastreados até o workload que os gerou, o que representa o fim das disputas de cobrança entre times que compartilham infraestrutura.
Para profissionais de FinOps, significa o fim da planilha órfã. Tags decaem. Convenções de tagging ficam desatualizadas no instante em que um novo serviço entra em produção. A medição em nível de kernel não depende de ninguém lembrar de colocar tag em nada.
Para CFOs e líderes de Finanças, significa visibilidade de ROI vinculada a features específicas e segmentos de clientes, em vez de estimativas em nível de conta. Saber que uma feature aumenta a probabilidade de renovação é um tipo de insight muito diferente de saber quanto a conta gastou no agregado no mês passado.
Por que isso importa agora
O padrão se repete em toda categoria anterior de custo em nuvem: otimização de compute, gestão de commitments, alocação de custos em Kubernetes. As organizações que estabelecem cedo a base de medição certa tomam decisões melhores dali em diante. As que adiam a atribuição até que as contas já estejam altas passam anos reconstruindo um contexto que poderiam ter tido desde o primeiro dia.
O gasto com IA está se movendo mais rápido do que qualquer categoria anterior, e os dados confirmam isso. Uma pesquisa da Sapio Research com 500 líderes de Finanças mostrou que 79% das empresas já tiveram estouros de custo com IA, e apenas 15% conseguem calcular o ROI de IA sem gargalos significativos. A janela para estabelecer a base certa é agora, não depois da próxima conta surpresa.
Como a DoiT trata isso
A DoiT gerencia mais de US$ 8 bilhões em gastos com nuvem de 4.500 clientes em 27 países, e viu esse padrão de medição se repetir em toda grande categoria de custo em nuvem. O Attribute™ da DoiT aplica a abordagem em nível de kernel descrita acima: um sensor eBPF que é implantado em cerca de quinze minutos, sem tags, sem SDKs e sem mudanças no código, produzindo economia de tokens por cliente, por feature e por agente até o fim do dia em que é instalado.
A DoiT também é parceira de marketing da Tokenomics Foundation, trabalhando ao lado de JR Storment e da FinOps Foundation para ajudar a definir padrões abertos do setor para a economia de tokens de IA à medida que a categoria amadurece.
Agende uma demo para ver o Attribute™ no seu próprio ambiente.