FinOps de IA: como tornar o custo de IA visível e previsível

Por que o custo de IA é diferente do FinOps tradicional

O custo de IA é diferente porque o FinOps clássico foi feito para unidades estáveis, e a IA cobra por consumo. Em vez de instância, gigabyte e transação — unidades que se pode planejar —, a IA cobra por token, por inferência e por GPU-hora, unidades que variam a cada chamada. Volume de uso, tamanho do prompt e escolha do modelo mudam a conta o tempo todo, e o gasto some no billing consolidado da nuvem sem que ninguém veja de onde veio. O resultado é a fatura que surpreende no fim do mês.

Token, inferência e GPU: as novas unidades de custo

O consumo de IA se mede em unidades que o FinOps de nuvem não previa. O token é a unidade de texto processada — cobra-se pela entrada (o prompt e o contexto) e pela saída (a resposta). A inferência é cada execução do modelo para responder a uma solicitação. A GPU-hora é o tempo de processamento em hardware dedicado, relevante sobretudo quando a empresa hospeda o próprio modelo. Nenhuma delas é estável: a mesma tarefa custa mais ou menos conforme o prompt, o modelo e o volume.

Por que o gasto é imprevisível

O gasto de IA é imprevisível porque depende de variáveis que mudam a cada requisição. Um prompt mais longo consome mais tokens; um caso que ganha usuários multiplica as inferências; uma escolha de modelo mais capaz encarece cada chamada. Diferente de uma instância reservada, cujo custo é conhecido de antemão, o custo de IA só se materializa no uso — e cresce de forma não linear quando um caso de uso engata. Sem medição por caso, esse crescimento é invisível até chegar na fatura.

Por que FinOps para IA deixou de ser opcional

Gerenciar o gasto de IA dentro do FinOps virou norma, não exceção. Segundo o relatório State of FinOps, da FinOps Foundation, 98% das organizações pesquisadas já gerenciam o gasto de IA dentro do escopo de FinOps, contra 31% dois anos antes^[1] — um salto que reflete a velocidade com que o custo de IA passou a pesar no orçamento de TI. O dado é de uma pesquisa com metodologia declarada e deve ser lido como recorte dessa amostra, mas sinaliza uma direção clara: tratar o custo de IA como mais uma linha do FinOps deixou de ser diferencial e virou requisito.

Unit economics: o custo por tarefa, não por token

O número que importa para o negócio não é o custo por token, e sim o custo por tarefa concluída ou por usuário atendido. Amarrar o gasto à unidade de valor — um chamado resolvido, um documento processado, um cliente atendido — mostra se o caso se paga. Olhar só o custo por token esconde a conta real, porque uma tarefa pode consumir muitos tokens em várias chamadas, retries e contexto, e o token barato individualmente vira caro no agregado da tarefa.

Por que o custo por token engana

O custo por token engana porque é uma unidade técnica, não de valor. Um preço baixo por token dá a impressão de barato, mas a tarefa real raramente é uma única chamada curta: envolve contexto grande, histórico da conversa, tentativas repetidas e, às vezes, várias etapas encadeadas. Somados, esses tokens fazem o custo por tarefa ser muito maior do que o preço unitário sugere. Decidir com base no preço por token é como avaliar uma viagem pelo preço do litro de combustível, ignorando a distância.

Como calcular o custo por tarefa

O custo por tarefa é o total de tokens (entrada e saída), somadas todas as chamadas necessárias para concluir a tarefa, multiplicado pelo preço da unidade, mais os custos de camadas de apoio (embeddings, storage, rede). Na prática, mede-se o consumo de um caso real do começo ao fim e divide-se pelo número de tarefas concluídas no período. O resultado é o número que responde à pergunta da diretoria: quanto custa, de fato, cada atendimento que a IA faz — e ele se paga?

Amarrar o gasto à unidade de valor

A unidade de valor certa depende do caso, mas sempre é algo que o negócio reconhece. Em atendimento, é o custo por chamado resolvido; em processamento de documentos, o custo por documento; em um assistente, o custo por usuário atendido no mês. Definir essa unidade antes de escalar é o que permite comparar o gasto de IA com a alternativa (o custo do processo manual) e decidir se o caso vale a pena. Sem unit economics, aprova-se IA no escuro e descobre-se o custo real depois.

Onde o custo de IA se esconde

O modelo costuma responder por apenas uma fração do custo total de IA; o resto se espalha em camadas menos visíveis. Como referência de mercado, em IA generativa em produção o custo do modelo em si é minoritário no total de propriedade, e a maior parte se distribui em outras camadas — contexto, retries, embeddings, storage vetorial, rede e GPU subutilizada^[2]. Enxergar essas camadas é metade do trabalho de FinOps de IA, porque é nelas que o gasto cresce sem aparecer.

Contexto grande e histórico

Prompts longos e histórico de conversa são uma das fontes mais silenciosas de custo. Cada token de contexto enviado ao modelo é cobrado, e sistemas que mandam documentos inteiros, históricos completos ou instruções extensas a cada chamada multiplicam o gasto sem que o usuário perceba. Enxugar o contexto — enviar só o trecho necessário, resumir o histórico, cortar instruções redundantes — costuma ser a economia mais rápida e menos dolorosa, porque não muda o resultado, só reduz o que se paga por ele.

Retries, embeddings e storage vetorial

Chamadas repetidas e as camadas de dados por trás do RAG somam custo que raramente é contabilizado. Retries — repetir a chamada quando a primeira falha ou o resultado não convence — dobram ou triplicam o custo de uma tarefa. Embeddings (a conversão de documentos em vetores para busca) e o storage vetorial que os guarda têm custo próprio de processamento e armazenamento. Em um sistema de RAG, essas camadas de apoio podem pesar tanto quanto as chamadas ao modelo, e passam despercebidas quando só se olha o billing do LLM.

GPU ociosa e tráfego de rede

Quando a empresa hospeda o próprio modelo, a GPU subutilizada é um dos maiores desperdícios. Uma GPU reservada e pouco usada custa igual à usada — o gasto é pela disponibilidade, não pelo uso efetivo. Modelos hospedados com baixa taxa de ocupação queimam orçamento parados. O tráfego de rede entre serviços, muitas vezes esquecido, também entra na conta em volumes altos. Mapear ocupação de GPU e fluxo de rede fecha o quadro das camadas onde o dinheiro se esconde.

Roteamento de modelos: mandar cada tarefa para o modelo certo

Nem toda tarefa precisa do modelo mais caro, e rotear cada workload para o modelo certo é a alavanca de economia mais direta. O princípio é simples: usar o menor modelo que resolve a tarefa com qualidade suficiente, com fallback para o mais capaz só quando necessário. Mandar tudo para o modelo mais potente é como usar um caminhão para entregar uma carta — funciona, mas paga-se muito por capacidade que a tarefa não exige.

Por que o modelo mais caro nem sempre é preciso

A maioria das tarefas de um sistema de IA é simples e não justifica o modelo topo de linha. Classificar um texto, extrair um dado, resumir um parágrafo ou responder a uma pergunta direta são tarefas que um modelo menor e mais barato resolve com qualidade equivalente. Reservar o modelo mais capaz — e mais caro — para o que realmente exige raciocínio complexo evita pagar preço premium por trabalho trivial. A diferença de preço entre modelos é grande o suficiente para que essa escolha mude o orçamento.

Como funciona o roteamento por workload

O roteamento por workload é uma camada que decide, para cada solicitação, qual modelo usar. Tarefas simples vão para o modelo econômico; tarefas complexas, para o mais capaz; e há um fallback que escala para o modelo maior quando o menor não dá conta. Essa decisão pode ser por tipo de tarefa (regra fixa) ou automatizada (o sistema avalia a complexidade e roteia). O ganho é pagar, em média, muito menos, mantendo a qualidade onde ela importa.

Comparar preço por token entre provedores

Os preços por token variam bastante entre provedores e entre modelos de um mesmo provedor, e comparações públicas ajudam a orientar a escolha. Levantamentos de mercado reúnem o preço por token de entrada e de saída dos principais modelos, permitindo estimar o custo de cada workload antes de decidir^[3]. Esses preços mudam com frequência, então servem como ilustração da lógica de comparação, não como tabela definitiva — a régua é sempre confirmar o preço vigente do provedor antes de fechar a arquitetura de roteamento.

Tagging, alertas, caps e chargeback

Tornar o gasto de IA governável exige quatro mecanismos: marcar o consumo (tagging), avisar quando ele foge do padrão (alertas), impor limites (caps) e devolver o custo a quem o gerou (chargeback ou showback). Sem tag, o custo é um bloco cego — não se sabe de onde veio nem quem o causou. Com esses quatro mecanismos, o gasto deixa de ser uma surpresa mensal e passa a ser algo que se acompanha, se limita e se atribui.

Tagging: sem tag, o custo é um bloco cego

Tagging é marcar cada consumo com a área, o caso de uso e o ambiente que o gerou. É o alicerce de todo o resto: sem tag, o billing mostra um total agregado que não diz de onde o gasto veio nem quem o causou, e qualquer análise por área ou por caso é impossível. Marcar o consumo na origem — por chave de API, por projeto, por identificador de caso — transforma o bloco cego em um custo rastreável, que se pode fatiar por área e por caso.

Alertas e caps contra o estouro silencioso

Alertas e caps são a defesa contra a fatura que surpreende. O alerta dispara quando o consumo foge do padrão — um caso que de repente consome muito mais do que o normal, um retry em loop, um pico inesperado — e dá tempo de agir antes do fim do mês. O cap é o limite que impede o estouro: um teto de gasto por caso, por equipe ou global, que barra o consumo (ou exige aprovação) ao ser atingido. Juntos, evitam que um erro de configuração ou um uso descontrolado vire um susto de milhares de reais.

Chargeback e showback: devolver o custo à área

Chargeback e showback devolvem o custo de IA a quem o gerou, e isso muda o comportamento. No chargeback, o custo é cobrado da área — sai do orçamento dela. No showback, o custo é apenas mostrado, sem cobrança formal. Em ambos, a área que enxerga o próprio gasto passa a otimizar: revê prompts longos, questiona casos caros, corta uso supérfluo. É o mecanismo que traz responsabilidade financeira para o consumo de IA, tirando-o do "orçamento de todos e de ninguém".

Atribuição e teto por porte

IA embutida e as métricas que tornam o gasto previsível

Além do gasto direto em API, a TI precisa mapear o custo de IA que chega embutido em software já contratado e definir as métricas que tornam o gasto previsível. Fornecedores estão incorporando IA a produtos já licenciados, com cobrança adicional por uso ou por assento premium — um aumento que entra "por dentro" do que já se paga. E sem um conjunto de métricas, não há como prever nem otimizar: o que não é medido não se governa.

GenAI encarecendo software já licenciado

O custo de IA não vem só da API direta: chega também embutido em ferramentas que a empresa já usa. Fornecedores de software estão adicionando funções de IA a produtos já licenciados e cobrando por isso — um consumo por uso, um assento "premium" com IA, um add-on. Esse aumento passa despercebido porque não aparece como "gasto de IA", e sim como reajuste do software existente. A TI precisa mapear esse crescimento por dentro do que já paga, não só o gasto direto em tokens, para ter o quadro completo do custo de IA.

As métricas de FinOps de IA que importam

Um punhado de métricas resume a saúde financeira do consumo de IA. As principais são: custo por tarefa ou por usuário atendido (a unit economics), custo por token por caso, taxa de uso do modelo caro versus o barato, custo por área, aderência ao cap definido e forecast versus realizado. Cada uma responde a uma pergunta de gestão — o caso se paga? o roteamento está funcionando? a área está dentro do teto? a previsão bateu? O que não entra nesse painel não se prevê nem se otimiza.

Do forecast à otimização contínua

A previsibilidade vem de comparar forecast e realizado e ajustar continuamente. Com o consumo medido por caso, é possível projetar o gasto do próximo período e confrontá-lo com o que de fato ocorreu, refinando a previsão a cada ciclo. A otimização contínua fecha o laço: enxugar contexto, ajustar o roteamento, cortar retries desnecessários e liberar GPU ociosa. FinOps de IA maduro não é um projeto com fim — é um ciclo de medir, prever, otimizar e medir de novo, à medida que os casos de uso crescem.

Otimização por porte