O FinOps deu aos times um manual de verdade para disciplinar custos de nuvem: marque seus recursos com tags, acompanhe a economia unitária e monte modelos de chargeback que cobrem engenharia e finanças pelos mesmos números. Funciona. Hoje, a maioria das organizações maduras em nuvem opera com alguma versão disso.
A infraestrutura de IA está quebrando esse manual, e a maioria dos times ainda não se deu conta do tamanho do estrago.
O que significa FinOps para IA hoje
FinOps para IA é a extensão natural da disciplina de gestão financeira de nuvem para workloads de machine learning e IA generativa. O objetivo continua o mesmo do FinOps tradicional: conectar o gasto ao time, produto ou cliente que o gerou, para que finanças e engenharia decidam a partir dos mesmos números. O que mudou foi a infraestrutura por baixo, e a mecânica de como um LLM realmente processa uma requisição é um bom ponto de partida se esse cenário ainda não for familiar.
Na prática, o FinOps para IA costuma cobrir um punhado de capacidades essenciais, cada uma emprestada do manual tradicional de FinOps e apontada para um novo tipo de workload.
Alocação de custos. Aplicar tags em instâncias de GPU do mesmo jeito que você faria em uma VM. Mapear chaves de API, modelos e projetos para times, produtos ou clientes. Montar para um cluster de treinamento o mesmo mapa de propriedade que você montaria para um namespace do Kubernetes.
Showback e chargeback. Gerar relatórios que mostrem a um time quanto custou rodar o treinamento de um modelo, ou como ficou o gasto de inferência de uma feature no mês passado, do mesmo jeito que o showback funciona há anos para computação e armazenamento.
Economia unitária. Traduzir o gasto bruto em um número acionável para o negócio: custo por inferência, custo por usuário ativo, custo por feature, aplicando a mesma lógica que sempre existiu para custo por transação ou por requisição.
Orçamentos, alertas e detecção de anomalias. Definir limites por time ou por modelo e ser notificado quando o consumo de tokens ou o tamanho do prompt disparar sem aviso, espelhando as ferramentas de orçamento e anomalia que já são padrão na gestão de custos de nuvem.
Governança e aplicação de políticas. Definir quem pode subir o quê, com qual modelo e sob qual teto de custo, o equivalente em IA às quotas de recursos e às políticas de tagging.
Para boa parte dos workloads de IA, essa abordagem ainda funciona bem. Um cluster de treinamento dedicado com dono claro. Um endpoint de inferência single-tenant servindo um único produto. Um modelo com padrão de chamada previsível e rastreável. Aplique a tag, acompanhe, pronto.
Onde o manual se sustenta, e onde não
O problema começa nos workloads que não se encaixam nesse perfil, e, cada vez mais, esses são a maioria.
Infraestrutura compartilhada quebra o modelo de propriedade
Uma conta de API de modelo gerenciado atende rotineiramente dezenas de times a partir de uma única linha na fatura. Não há fronteira por time na fatura em si, apenas o que você consegue reconstruir depois a partir de metadados que podem ou não ser confiáveis. Um cluster de GPU compartilhado roda inferência para vários produtos ao mesmo tempo, com ciclos de computação intercalados em um nível que nenhuma tag consegue enxergar.
Gateways apagam o sinal do qual o tagging depende
Um gateway de LLM agrega requisições de agentes, pipelines automatizados e usuários humanos em um único fluxo de saída e, ao fazer isso, apaga a identidade do chamador antes que a requisição chegue ao provedor. Quando ela atinge o modelo, o contexto que permitiria atribuí-la de volta a um time ou feature normalmente já se perdeu. Tags aplicadas antes não sobrevivem ao salto.
Workloads agênticos geram custos que nenhum SDK envolveu
Um workload agêntico pode disparar subagentes que provocam custos reais de infraestrutura, computação, memória, rede, carga em banco de dados, sem qualquer relação com a linha original da fatura de IA de onde partiram. Não existe tag ou convenção de nomenclatura ligando nada disso de volta à requisição que iniciou a cadeia, porque a cadeia não estava prevista quando a instrumentação foi construída.
A instrumentação não acompanha a velocidade da infraestrutura de IA
O problema de cobertura é só metade da história. Workloads de IA se movem em um ritmo que a instrumentação não consegue acompanhar. Um agente pode gerar mil subagentes de uma noite para a outra. Quando a engenharia identifica o novo padrão de chamada, envolve tudo em um SDK e faz o deploy da atualização, a fatura já chegou. Isso não é um problema de disciplina de tagging que se resolve com governança melhor ou convenções de nomenclatura mais rígidas. É uma realidade arquitetônica de como a infraestrutura de IA funciona de fato, e vale por mais disciplinada que a prática de FinOps seja.
O problema do gasto órfão
Converse com qualquer profissional de FinOps seis meses depois do início de um programa de custos de IA e você vai ouvir alguma versão da mesma história: uma linha de gasto que cresceu 40% mês a mês, sem dono que ninguém consiga achar. As tags apontam para uma service account compartilhada entre três times. A convenção de nomenclatura que funcionava para VMs nunca chegou aos endpoints de inferência. Alguém montou uma planilha para reconstruir a propriedade na mão, e ela já nasce desatualizada.
Esse gasto não está sem dono. Ele está sem atribuição, porque o método usado para encontrá-lo foi construído para uma infraestrutura que não se move, não compartilha e não gera seus próprios filhos em tempo de execução. A infraestrutura de IA faz as três coisas.
FinOps para IA vs. FinOps de nuvem tradicional
| FinOps de nuvem tradicional | FinOps para IA | |
|---|---|---|
| Método principal de atribuição | Tags, convenções de nomenclatura, estrutura de contas | Tags funcionam até entrar em cena infraestrutura compartilhada ou gateways |
| Estabilidade da infraestrutura | Relativamente estática; a propriedade costuma ser clara | Altamente dinâmica; a propriedade pode mudar no meio de uma requisição |
| Lacunas de cobertura | Sobretudo um problema de disciplina de tagging | Arquitetônico: alguns workloads simplesmente não podem receber tags |
| Velocidade de mudança | Ciclos de mudança previsíveis e governados | Pode mudar da noite para o dia, mais rápido do que a instrumentação consegue ser atualizada |
| Onde falha | Casos de borda, recursos legados | Clusters de GPU compartilhados, gateways de LLM, workloads agênticos e multiagentes |
O que vem depois: medir abaixo da tag
Se a arquitetura dos workloads de IA derrota a instrumentação por design, então a instrumentação é a camada errada para medir. A alternativa é medir a partir de um lugar onde não dá para pular, apagar ou correr mais rápido que ela: o kernel.
Essa é a arquitetura por trás do Attribute™ da DoiT. Ele implanta um sensor eBPF dentro do sistema operacional que observa o consumo real, cada token, cada requisição a modelo, cada ciclo de GPU, na hora em que acontece, e mapeia cada unidade de volta ao processo, contêiner e requisição responsáveis. Sem tags. Sem SDKs. Sem mudanças de código. Em seguida, cruza esses dados com o faturamento dos provedores Anthropic, OpenAI, Google Gemini e AWS Bedrock, separando automaticamente tokens em cache, de raciocínio, de entrada e de saída.
É nessa camada que Tokenomics vira algo operacional: economia no nível do token, atribuída automaticamente, para os workloads que o tagging nunca ia alcançar. Tokenomics sem tags, sem SDKs e sem mudanças de código.
Por que isso importa agora
Nossa pesquisa, um levantamento com 500 líderes financeiros conduzido pela Sapio Research, mostrou que 79% das empresas já enfrentaram estouros de custo com IA e apenas 15% conseguem calcular o ROI de IA sem gargalos significativos. Essa lacuna não é um problema de processo que os times ainda não pararam para resolver. É um problema de medição que exige uma camada diferente para ser solucionado.
A DoiT já gerenciou mais de 8 bilhões de dólares em gastos de nuvem para 4.500 clientes em 27 países, e já vimos esse padrão se repetir em todas as grandes categorias de custo, otimização de computação, gestão de commitments, alocação de custos de Kubernetes. Os times que acertam a base de medição cedo tomam cada decisão seguinte com mais qualidade. Os que esperam passam anos reconstruindo um contexto que poderiam ter tido desde o primeiro dia.
Estamos trabalhando com a Tokenomics Foundation, ao lado de JR Storment e da FinOps Foundation, para ajudar a definir como essa base deve ser para o setor.
FAQ
O que é FinOps para IA?
FinOps para IA é a aplicação das práticas de gestão financeira de nuvem, alocação de custos, showback e chargeback, economia unitária, orçamentos e detecção de anomalias, a workloads de machine learning e IA generativa. Estende a disciplina que já funciona para a infraestrutura de nuvem tradicional a uma nova categoria de gasto.
Por que o tagging não funciona para atribuição de custos de IA?
O tagging depende de uma relação estável e rastreável entre um recurso e seu dono. Clusters de GPU compartilhados, gateways de LLM e workloads agênticos quebram essa relação por design: gateways apagam a identidade do chamador, a infraestrutura compartilhada não tem uma fronteira de propriedade clara, e cadeias agênticas geram custos que nenhuma tag chegou a receber.
Qual a diferença entre FinOps para IA e Tokenomics?
FinOps para IA descreve a prática de aplicar disciplina de gestão de custos a workloads de IA. Tokenomics é a disciplina de medição subjacente, que busca entender quanto vale cada token, quem o consumiu e se o gasto se justificou pelo resultado, independentemente de o workload poder ou não receber tags.
Dá para fazer FinOps para IA sem instrumentação?
Dá. A medição em nível de kernel, com tecnologia como eBPF, observa o consumo no nível do sistema operacional em vez de depender de tags ou SDKs. Isso permite atribuir workloads que a instrumentação tradicional não alcança, incluindo clusters de GPU compartilhados e tráfego roteado por gateways.
Quem é o dono do FinOps para IA dentro de uma organização?
Varia de empresa para empresa, mas o FinOps para IA costuma ficar na intersecção entre o time atual de FinOps ou de custos de nuvem, a engenharia de plataforma ou infraestrutura e, cada vez mais, os times que constroem produtos de IA diretamente. Como o gasto com IA se move mais rápido e envolve mais times do que o gasto tradicional de nuvem, a prática tende a exigir uma colaboração mais próxima entre finanças e engenharia do que o FinOps legado, já que nenhum dos lados tem visibilidade completa sozinho.
Como a alocação de custos de IA difere da alocação de custos de nuvem?
A alocação de custos de nuvem geralmente mapeia o gasto para um recurso com dono relativamente estável: uma instância, um bucket, um namespace. A alocação de custos de IA precisa levar em conta um consumo que atravessa fronteiras de propriedade dentro de uma única requisição, uma GPU compartilhada servindo vários produtos, um gateway roteando tráfego de vários times, um agente gerando custos em serviços que ele nunca tocou diretamente. O objetivo é o mesmo. A mecânica para chegar lá, não.
Quais métricas um programa de FinOps para IA deve acompanhar?
A maioria dos programas acompanha alguma combinação de custo por token, custo por inferência, custo por feature e custo por cliente ou conta, junto com a divisão de tokens de entrada, saída, cache e raciocínio, que varia por provedor. A combinação certa depende do público: engenharia, que costuma querer detalhe no nível do workload, ou finanças, que costuma querer consolidações no nível de conta ou feature amarradas a dados de receita ou renovação.
Pronto para ver o custo real de servir sua IA?
Quinze minutos para instalar. Sem instrumentação. Economia de tokens até o fim do dia.