Na primeira fase de adoção de IA dentro da empresa, ninguém pergunta quanto custa. Os pilotos são pequenos, a fatura mensal cabe no orçamento de inovação, e a conversa é sobre se a tecnologia funciona. Seis meses depois, quando cinco times diferentes têm casos de uso em produção e a fatura mensal triplicou, a conversa muda. Inevitavelmente, vira briga: TI quer que cada time pague o que consome; produto quer que TI absorva; ninguém quer ser o primeiro a colocar limite. (A camada técnica disso — como os custos reais de inferência explodem em produção — é tópico complementar.)
Esse é o problema que FinOps de IA resolve. Cobrar inferência de LLM internamente parece simples — divide a fatura — mas é um dos exercícios mais delicados de governança financeira em tecnologia hoje, porque mistura custo variável real, atribuição multi-tenant, e incentivos comportamentais. Esse texto enumera quatro modelos de cobrança interna, quando cada um funciona, e o que evitar.
O problema da fatura única
Sem FinOps, a fatura de OpenAI, Anthropic ou Bedrock chega num único cost center — geralmente TI ou Plataforma de Dados. Três consequências, todas ruins.
A primeira é que o custo fica invisível pros times que decidem. O PM que escolhe usar GPT-4o em produção sem checar volume estimado paga zero do seu orçamento. O CFO que aprova investimento de IA não vê quanto cada caso de uso custa por mês. Decisão sem sinal de custo gera consumo sem teto.
A segunda é que TI vira o vilão. Quando a fatura ultrapassa o limite, a conversa não é "como otimizamos esse caso de uso" — é "TI gastou demais". Conserva-se a centralização de custo enquanto se quebra a centralização de mérito. Time que entrega ROI fica com o crédito; TI fica com a fatura.
A terceira é que não há incentivo pra otimização. PM que sabe que o custo recai em outro cost center não vai investir tempo em prompt engineering, em escolher modelo mais barato, em cache, em avaliar fine-tuning vs RAG vs prompt. Otimização sem dor não acontece.
Custo de inferência absorvido por TI é o jeito mais barato de garantir que ninguém otimize nada. O time que paga é o que pensa em desperdício.
Quatro modelos de FinOps de IA
Quatro arquiteturas de cobrança interna que vimos funcionar. Cada uma é trade-off entre simplicidade contábil e precisão de atribuição.
Modelo 1 — Pool central com showback. A fatura continua chegando em TI, mas todo mês um relatório mostra quanto cada time consumiu (tokens, chamadas, custo em US$ ou R$). Não há débito real, mas há visibilidade. Funciona como ponte: cria consciência sem criar processo financeiro novo. Limitação: showback sem chargeback raramente muda comportamento — é informação sem consequência.
Modelo 2 — Chargeback proporcional baseado em volume. Custo total do mês é dividido entre times proporcionalmente ao volume de tokens consumido. Fácil de implementar (precisa só de logs com tag de team) e dá sinal real. Limitação: time que usa modelo caro (GPT-4o, Claude Opus) paga o mesmo per-token que time que usa modelo barato (GPT-4o-mini, Haiku). Não premia escolha de modelo eficiente.
Modelo 3 — Chargeback por custo real, com markup. Cada chamada é logada com modelo, input tokens, output tokens, e custo calculado em US$. Time é debitado pelo custo real + markup de 10–20% pra cobrir infra e governança (gateway, observabilidade, vault de chaves). É o modelo mais justo e mais caro de operar — exige gateway de inferência centralizado com billing por requisição. Quando funciona, premia time que escolhe modelo certo, otimiza prompts e usa cache.
Modelo 4 — Budget alocado upfront por caso de uso. Cada caso de uso aprovado recebe budget mensal de inferência (ex: USD 2.000/mês pro agente de atendimento, USD 800/mês pro assistente interno de vendas). Time consome livremente dentro do limite; ultrapassou, precisa aprovação ou throttle automático. Funciona bem em empresas com cultura forte de orçamento por iniciativa. Limitação: budget mal calibrado vira ou freio ao crescimento ou cheque em branco.
Como escolher entre os quatro
A escolha não é estética. Depende de três variáveis.
Maturidade da operação de IA. Empresa com 1–3 casos de uso em produção e fatura < USD 10k/mês: modelo 1 (showback) é suficiente. Acima disso, showback vira teatro. Empresa com 10+ casos de uso ou fatura > USD 50k/mês precisa de modelo 3 (custo real) ou 4 (budget) — caso contrário a distorção compensatória cresce.
Cultura financeira da empresa. Empresas com FinOps de cloud já maduro (chargeback por team em AWS/GCP) adaptam mais rápido modelos 2 e 3. Empresas que ainda tratam tudo como CapEx anual de TI absorvem melhor modelo 4 (budget upfront), que parece com o modelo orçamentário tradicional.
Heterogeneidade de uso. Se todos os casos de uso usam o mesmo modelo e padrão similar de tokens (ex: chat com prompts curtos), modelo 2 (proporcional) é OK. Se há mistura grande — alguns casos com input enorme (RAG sobre documentos), outros com saída longa (geração de relatórios), outros usando fine-tuning — modelo 3 (custo real) é o único que evita injustiça gritante.
Três armadilhas comuns
Algumas decisões parecem boas no papel e morrem na execução.
A primeira: incluir custo de inferência sem incluir custo de infra. A fatura visível da OpenAI é só parte do total real. Há gateway, logging, vault de chaves, observabilidade, equipe de governança. Esses custos rateados entre times completam a equação. Cobrar só inferência cria sub-otimização (time investe em pipeline complexo, gateway estoura, e ninguém paga).
A segunda: não taggear chamadas desde o dia zero. Sem tag de team/caso-de-uso em cada requisição, nenhum modelo funciona. Setup técnico (gateway de inferência, hook no SDK, header HTTP) precisa estar em produção desde a primeira chamada — adicionar depois implica retrofit doloroso.
A terceira: debitar exatamente o que o provider cobra. Provider muda preço (OpenAI cortou preço 4 vezes em 2024–2025; pode subir também). Se o chargeback é exatamente custo real, time tem oscilação imprevisível. Estabilize com markup ou snapshot mensal — previsibilidade dentro da empresa importa mais que precisão centavo-a-centavo.
O passo zero é log com tag
Sem log de inferência com tag de team, modelo, input/output tokens e custo calculado, nada disso é executável. Esse é o investimento técnico que destrava tudo o resto.
Em prática, três caminhos: (1) gateway de inferência self-hosted (LiteLLM, Portkey, Helicone), (2) provider-native logging (OpenAI Usage API, Anthropic console com tags), ou (3) wrapper no SDK que loga em data warehouse próprio. O caminho (1) dá maior controle e é o mais comum em operações maduras. O (3) é mais leve mas exige disciplina pra que todo time use o wrapper.
Com log estruturado em warehouse, dashboard de custos reais de inferência por team/caso-de-uso/modelo sai em uma semana. A partir daí, qualquer dos quatro modelos é decisão de política, não de engenharia.
Onde FinOps de IA falha em silêncio
O sinal que indica que o modelo não está funcionando: o time financeiro continua chamando TI quando a fatura sobe. Isso significa que a distribuição de custo não chegou ao nível de visibilidade que muda comportamento. Diagnóstico pra quem está implantando: peça pra cada PM dizer, sem consultar dashboard, quanto o caso de uso dele custou no mês passado. Se ninguém souber, FinOps existe no papel, não na decisão.
O ponto de virada acontece quando PM começa a perguntar "esse modelo mais barato funcionaria pra esse caso?" antes de TI sugerir. Aí o sistema está funcionando. Até lá, está em fase de tradução cultural — e tradução cultural leva mais tempo do que implementação técnica.