No trimestre passado, uma CFO fez uma pergunta simples ao seu líder financeiro: qual cliente está puxando a nossa conta da OpenAI? A líder tinha uma estratégia de tagging, uma ferramenta de FinOps e uma fatura mensal da OpenAI. Ainda assim, não conseguiu responder. A fatura mostrava um único número. O sistema de tagging não tinha em que se apoiar. O código da aplicação chamava a API diretamente e devolvia uma completion. Sem centro de custo. Sem ID de cliente. Sem feature flag. Só tokens entrando, tokens saindo e uma linha na fatura no fim do mês.
Esse é o gap de atribuição que o gasto com IA criou dentro do FinOps Framework. Allocation, enquanto capacidade, foi construída para compute e storage, onde cada recurso tem uma tag, um projeto ou uma conta por trás. Uma chamada de token não tem nada disso. A unidade de gasto — uma requisição de API — não carrega os metadados dos quais o tagging depende. Se os times de FinOps quiserem responder perguntas de custo por cliente, por feature ou por agente, a atribuição precisa sair da camada de billing e migrar para a camada de tráfego.
Por que o tagging não resolve a atribuição de custos de IA?
Tagging falha no gasto com IA porque uma chamada de token não tem rótulo em que uma tag possa ser fixada. A Allocation tradicional na nuvem funciona assim: você marca uma instância EC2 com team=platform e, a cada hora que essa instância roda, o custo flui para o time de plataforma. A tag vive no recurso. O recurso gera o custo. A corrente não se rompe.
Chamadas de API de IA não funcionam assim. Quando sua aplicação chama openai.chat.completions.create(), não existe recurso para marcar. Existe uma requisição, uma resposta e uma contagem de tokens registrada do lado da OpenAI. Seu provedor de nuvem nunca vê isso. Seu sistema de tagging nunca encosta nisso. No fim do mês, a OpenAI te manda uma fatura por organização, às vezes segmentada por modelo, e esse é todo o universo de informação que você tem.
A FinOps Foundation define Allocation como uma capacidade central, mas o framework parte do princípio de que existe uma unidade taggável. Para provedores de IA no formato SaaS, isso não existe. Anthropic e Bedrock têm o mesmo formato. Os dashboards dos provedores dividem o gasto por chave de API ou por modelo, não pelo cliente ou pela feature que disparou a requisição. Mesmo que você separe chaves de API por time, não dá para separá-las por cliente sem criar milhares de chaves e gerenciá-las como um serviço de diretório.
É por isso que quem trabalha com FinOps e tenta aplicar o playbook de tagging do EC2 na OpenAI acaba com a mesma resposta que a CFO já tinha: um total. Sem allocation.
Três times, três perguntas, uma fatura
A mesma conta de IA dispara três perguntas diferentes dentro de uma empresa, e nenhuma delas pode ser respondida só com os dados de billing do provedor.
Finanças quer entender a economia unitária. Quanto custa atender cada cliente? Se um cliente de tier premium gera US$ 40 em chamadas ao Claude por mês e paga US$ 99 pela assinatura, essa é uma história de margem bem diferente da de um cliente que gera US$ 2 em chamadas. Sem atribuição por cliente, o cálculo de margem bruta vira chute.
Produto quer ROI no nível de feature. Quais features valem o gasto em tokens? Uma feature de sumarização pode impulsionar retenção e custar US$ 8 mil por mês. Um agente experimental pode custar US$ 22 mil por mês e ser usado por 40 pessoas. Produto não consegue priorizar sem saber qual feature é dona de qual fatia da fatura.
O CFO quer saber por que o número mexeu. Quando a fatura da Anthropic dobra mês a mês, alguém tem que explicar. Foi um novo cliente? Uma mudança no prompt? Um agente descontrolado entrando em loop? A fatura não diz. Só mostra o total.
Dados brutos de billing ingeridos num dashboard de FinOps não respondem a nenhuma dessas perguntas. Só reapresentam a fatura. Isso é uma camada de reporting, não uma camada de Allocation. O FinOps Framework trata Automation, Tools, & Services como o software que habilita as Capacidades, incluindo Allocation para categorias emergentes de gasto. No caso de IA, essa automação precisa entrar dentro da própria requisição, porque é ali que o contexto de negócio vive.
O que a atribuição no nível do tráfego faz na prática?
A atribuição no nível do tráfego lê cada requisição de IA no momento em que ela acontece e mapeia a contagem de tokens para o cliente, a feature e o agente que a dispararam. Em vez de tentar reconstruir a atribuição a partir de uma fatura agregada, ela captura o contexto no momento da requisição, antes que esse contexto desapareça.
Na prática, funciona assim. Sua aplicação chama o Claude com um prompt. A requisição passa por um gateway ou proxy que inspeciona o payload e o marca com o ID do cliente extraído do token de autenticação, o nome da feature extraído do path da requisição e o identificador do agente extraído do serviço que fez a chamada. A requisição segue para a Anthropic. A resposta volta. O gateway registra as contagens de tokens nas dimensões marcadas. No fim do mês, você não tem um número da Anthropic. Você tem milhares de eventos atribuídos, agrupados por qualquer unidade de negócio que te interesse.
Isso funciona com OpenAI, Anthropic e Bedrock porque o padrão de tráfego é o mesmo. Todo provedor devolve contagem de tokens na resposta. Toda requisição carrega contexto no nível da aplicação. A lógica de atribuição fica entre o seu código e o provedor, então você não precisa reescrever o código da aplicação para adicionar tags. Se você quer custo por cliente, você tem custo por cliente. Se quer custo por agente, tem custo por agente.
Isso está mais perto de como observabilidade funciona do que de como o tagging funciona. E é também por isso que o ferramental parece diferente. Uma ferramenta de FinOps baseada em tag quer ingerir um arquivo CUR. Uma ferramenta de atribuição no nível do tráfego quer ficar no caminho da requisição. Arquitetura diferente, capacidade diferente. Para uma análise mais aprofundada de por que essa mudança importa, veja nosso texto anterior em Why traditional FinOps breaks down with AI workloads.
Onde isso se encaixa no FinOps Framework
A atribuição de custos de IA não é um novo dashboard. É uma nova Capacidade de Allocation para uma categoria de gasto que não se encaixa nas premissas atuais de Enterprise Architecture. O FinOps Framework foi desenhado pensando em recursos taggáveis. Compute, storage, rede, banco de dados — todos têm identificadores pelos quais as ferramentas conseguem agrupar. Gasto com API de IA não. A unidade de consumo é um token, e tokens vivem dentro de requisições, não em recursos.
Isso significa que a atribuição de IA pertence à camada de Automation, Tools, & Services do framework, mas com um padrão de implementação diferente do que a Allocation baseada em tag usa. Em vez de ingerir exports de billing e agrupar por tag, o ferramental lê tráfego ao vivo e gera registros de atribuição que retroalimentam a Capacidade de Allocation. Para o usuário de finanças, o resultado parece o mesmo: custo por time, por cliente, por feature. O mecanismo por baixo é que é diferente.
Isso importa para o modo como quem faz FinOps planeja seu toolchain. Se você está construindo uma prática de FinOps para IA em cima de uma ferramenta baseada em tag, vai bater na mesma parede em que a líder financeira da CFO bateu. Se você está avaliando uma ferramenta para atribuição de IA, a pergunta a fazer não é "ela ingere minha fatura da OpenAI?". Toda ferramenta faz isso. A pergunta é "ela atribui minha fatura da OpenAI?". Isso exige instrumentação no nível do tráfego, não ingestão de billing.
Vale reler a página de Capacidades do FinOps Framework pensando em workloads de IA. Anomaly Management, Allocation e Forecasting partem todos do princípio de que a atribuição existe. Para o gasto com IA, a atribuição é o insumo que está faltando.
Frequently asked
questions
Como atribuo gasto com OpenAI ou Anthropic a um cliente específico?
Você precisa capturar o ID do cliente no momento em que a requisição é feita, porque a fatura do provedor não inclui essa informação. Isso significa instrumentar o tráfego entre sua aplicação e o provedor, seja por meio de um gateway, proxy ou wrapper de SDK, para que cada contagem de tokens possa ser registrada contra um identificador de cliente.
Por que o tagging não resolve a atribuição de custos de IA?
Tagging exige um recurso em que se fixar. Chamadas de token para OpenAI, Anthropic ou Bedrock não criam um recurso taggável na sua conta de nuvem, então não há a que a tag possa se prender. O custo aparece como uma única linha agregada na fatura do provedor.
Qual é o custo por feature de um produto de IA?
É a soma dos custos de token gerados pelas requisições feitas a partir daquela feature, dividida entre os clientes ou sessões que a usaram. Você só consegue calcular isso se estiver capturando o identificador da feature em cada requisição no momento em que ela acontece, já que os dados de billing do provedor não incluem contexto de feature.
Como times de FinOps alocam gasto com LLM entre clientes e features?
Eles movem a atribuição da camada de billing para a camada de tráfego. Em vez de tentar dividir uma fatura agregada depois do fato, capturam contexto por requisição — cliente, feature, agente — no momento da chamada de API e consolidam esses eventos em relatórios de custo.
Como acompanhar o uso de tokens por agente ou workflow?
Você precisa de instrumentação que identifique o agente ou workflow que fez a chamada em cada requisição. Isso pode ser feito com headers de requisição, identificadores de serviço ou um gateway que inspeciona o padrão da chamada e depois atribui as contagens de tokens retornadas pelo provedor ao agente que as disparou.
O gasto com IA quebrou o modelo de tagging porque uma chamada de token não tem nada em que colocar tag. Finanças, produto e o CFO estão todos fazendo perguntas que as faturas dos provedores não conseguem responder, e nenhuma quantidade de ingestão de billing vai mudar isso. A atribuição precisa migrar para a camada de tráfego, onde cada requisição ainda carrega o contexto de cliente, feature e agente que dá sentido ao número.