Antes de virar Field CTO na DoiT, eu atuava como profissional de FinOps. Já escrevi políticas de tagging. Já saí caçando recursos sem tag na semana da revisão de orçamento. Já montei modelos de chargeback tecnicamente defensáveis que, ainda assim, geravam briga em toda reunião, porque o cluster compartilhado de alguém não se dividia do mesmo jeito que o P&L daquela área.
Por isso, quando lançamos o Attribute™ esta semana, entendi por que a conversa começa pelos tokens: input, output, cached, reasoning. Custo por requisição, por cliente, por feature, por agente. Esse recorte está certo. Só não acho que esteja completo.
Tokens são fáceis de contar. A pergunta difícil é por que eles existiram, para começar. Um cliente adotou uma nova feature de IA? Um workflow interno migrou silenciosamente para um modelo mais caro? Um único prompt está queimando dez vezes mais tokens do que precisaria? Um agente disparou centenas de tarefas downstream que ninguém pediu? Num relatório de custos, esses quatro cenários são praticamente idênticos. Para o negócio, não poderiam ser mais diferentes.
Tagging nunca foi o objetivo
Tem uma coisa que quem atua na área sabe, mas raramente fala em voz alta: ninguém nunca quis tags. O que a gente queria era accountability — as pessoas certas vendo as informações de custo certas a tempo de agir. Tagging era só a melhor forma de implementar accountability na arquitetura que a gente tinha. Quando uma VM servia uma aplicação e uma conta correspondia a um time, propriedade, consumo e accountability se alinhavam naturalmente. As tags funcionavam porque a arquitetura deixava.
Aí a arquitetura mudou. O Kubernetes tornou a infraestrutura compartilhada. Serverless a tornou abstrata. Managed services jogaram o gasto para dentro de requisições, queries e invocações. O Vadim já escreveu sobre por que a instrumentação não se sustenta e o Josh já mostrou exatamente onde o tagging falha, então não vou repetir o argumento aqui. Resumindo: o que é cobrado e o que gera a demanda foram se afastando, e a IA separou os dois de vez. Uma única conta de modelo ou gateway consegue agregar requisições de todos os produtos, times, agentes e funcionários que você tem. Quando a fatura chega, o contexto que explicaria aquele valor já se perdeu.
O mesmo número, quatro decisões diferentes
Essa é a parte que mais me interessa, porque é o que separa reportar de decidir.
Digamos que seu gasto com IA subiu 40% no último mês. Pelos meus anos de prática, posso te garantir o que esse número, sozinho, sustenta: nada. O que você faz a seguir depende inteiramente do porquê.
Se subiu porque uma feature voltada ao cliente está impulsionando adoção e retenção, você investe mais. Não é um problema de custo. É um sinal de crescimento disfarçado de problema de custo.
Se subiu porque um workflow interno está usando um modelo premium para uma tarefa que um modelo menor daria conta, você otimiza. É trabalho de engenharia com retorno mensurável.
Se subiu porque um agente está disparando chamadas downstream desnecessárias, você entra com governança: rate limits, orçamentos, controles.
E se subiu porque um cliente enterprise responde por uma fatia desproporcional do seu custo de inferência, isso nem é mais conversa de FinOps. É precificação, empacotamento e margem — assunto para o seu CFO e o seu time de produto.
Quatro causas. Quatro donos. Quatro ações completamente diferentes. O número do custo não diz qual reunião marcar. O contexto diz.
É isso que o Attribute™ muda de verdade. Como ele mede o consumo real no kernel e cruza com o billing do provedor, o "porquê" chega junto do número: este cliente, esta feature, este agente, este workflow. Não porque contar tokens seja o ponto, mas porque attribution é o que transforma um número em decisão.
O que muda na prática
Na nossa pesquisa com 500 líderes de finanças, 79% já tinham enfrentado estouros de custo com IA, e apenas 15% conseguiam calcular ROI de IA sem gargalos relevantes. Não vejo isso como problema de disciplina. Esses times não estão falhando em FinOps. Estão rodando o playbook antigo contra uma arquitetura que joga contra eles.
O que acredito que vem a seguir, e o que digo aos clientes em campo: FinOps deixa de ser uma função de reporting que reconstrói o contexto depois do fato e passa a estar embarcado no lugar onde as decisões são tomadas. Os Engineers enxergam as implicações de custo enquanto desenham a solução, não trinta dias depois. Times de produto conhecem a economia unitária de uma feature antes da discussão de preço, não depois. Finanças conecta o gasto com IA à margem por cliente em vez de encarar uma linha única e indivisível. Times de plataforma de IA veem não só quais modelos rodaram, mas quais casos de uso geraram valor e quais geraram desperdício.
Nada disso funciona sem attribution. É a camada em que todo o resto do FinOps se apoia, e para workloads de IA é justamente a camada que estava faltando.
Passei anos da minha carreira reconstruindo contexto depois que a fatura chegava. A próxima era do FinOps é ter esse contexto antes de o dinheiro ser gasto. É isso que esse lançamento significa para mim.
Quinze minutos para instalar. Sem instrumentação. Economia de tokens já no fim do dia. Agende uma demo e veja o Attribute™ no seu próprio ambiente.