Inteligência Artificial

FinOps de IA

Quando o controle de custo vira problema de arquitetura

13 de jul. de 2026·Ricardo Coelho

A pesquisa Stat e of FinOps 2026 da FinOps Foundation registra que 98% dos praticantes já gerenciam gasto com IA, contra 31% em 2024. A Flexera, que publica o relatório anual State of the Cloud, confirma o efeito: o desperdício estimado em nuvem subiu pra 29%, revertendo cinco anos de queda, com cargas de trabalho de IA como principal fator. O custo de inferência, o que a empresa paga cada vez que um sistema faz uma chamada a um modelo de IA, deixou de ser problema de equipe de plataforma e virou preocupação de toda a organização.

O primeiro passo operacional é colocar limites. Por desenvolvedor, por ferramenta, por projeto, por semana. Sem teto, o consumo cresce por inércia. A Uber é um caso emblemático: liberou o Claude Code pra toda a engenharia sem limites nem atribuição de custo e criou rankings internos de quem consumia mais tokens (as unidades de texto que os modelos processam e cobram). Até abril de 2026, quatro meses depois, o orçamento anual inteiro de IA tinha acabado. Cerca de cinco mil engenheiros usavam a ferramenta, com custo médio entre 150 e 250 dólares por mês cada. Os mais intensivos chegavam a 500 e até 2.000, montando fluxos de agentes que disparavam dezenas de chamadas por tarefa. Em junho, a resposta veio: teto de 1.500 dólares mensais por pessoa em cada ferramenta de código agêntico. A cobrança por token varia demais com o uso real pra funcionar sem controle granular, e o que aconteceu na Uber acontece em escala menor em qualquer time que adota agentes de código sem governança.

O controle de custo que funciona tem três camadas: teto financeiro rígido (a fatura não ultrapassa X por semana por desenvolvedor, com alerta em 80%), roteamento de modelo por complexidade da tarefa (tarefas simples vão pra modelos compactos que custam frações de centavo por chamada, geração complexa vai pra modelos maiores) e telemetria granular por fluxo de trabalho. A fatura mensal de 12 mil dólares em API não diz quase nada. Saber que cada revisão de código custa 0,04 dólar e cada relatório de conformidade custa 0,12 é o que permite precificar e decidir.

A parte que separa FinOps de IA de teatro de planilha é a medição de valor. Tenho visto times que constroem painéis sofisticados de consumo de tokens sem conseguir responder uma pergunta simples: esse gasto está produzindo resultado? Alex Karp, CEO da Palantir, resumiu o sentimento em entrevista à CNBC: as empresas estão pagando por tokens que não geram valor algum. Se os modelos fossem de fato transformadores, disse Karp, OpenAI e Anthropic cobrariam uma fatia do valor gerado em vez de cobrar por uso. A provocação é exagerada, mas acerta no ponto de fundo. As métricas que respondem a essa pergunta já existem: tempo de ciclo entre commit e deploy, bugs por sprint, volume de tickets em atraso, deploys por semana. O trabalho de FinOps é correlacionar o gasto com a movimentação desses indicadores. Se o gasto subiu e nenhum indicador de entrega se moveu, a IA está gerando atividade sem produzir valor, e cortar o orçamento não vai prejudicar nada.

A classificação dos dados determina onde o modelo roda, e essa decisão tem consequência direta no custo e no risco. Dados estratégicos, sigilosos, sensíveis ou sob LGPD vão pra modelos auto-hospedados, rodando em infraestrutura própria. Karp reforçou o mesmo ponto pelo ângulo da propriedade intelectual: manter dados em plataformas fechadas é ceder vantagem competitiva. O ferramental pra auto-hospedagem amadureceu. Modelos abertos como o Llama 4 Scout rodam numa única GPU de alto desempenho com custo que se amortiza pelo volume. Em regime sustentado, o ponto de equilíbrio contra APIs de faixa média (na casa de 2 a 3 dólares por milhão de tokens) fica em torno de 500 milhões de tokens por mês. Tudo que é commodity vai pra API com preços que continuam caindo: o Sonnet 4.6 custa 3 dólares por milhão de tokens de entrada, o Haiku 4.5 custa 1, e o o3 da OpenAI é precificado a 2 depois de cortes de 87% sobre o modelo anterior. A decisão de roteamento não é fixa, e sim determinada pela classificação do dado em cada chamada.

Um ponto que encontro ignorado com frequência é o risco de lock-in, a dependência de um único fornecedor. Prototipar com uma API é rápido e barato, até o momento em que a arquitetura inteira assume os padrões, os formatos e as particularidades daquele modelo. A migração que custaria uma semana no protótipo passa a custar um trimestre quando o sistema depende de chamadas de ferramenta proprietárias e instruções de sistema calibradas pra um modelo específico. Projetar a camada de inferência como uma peça substituível é fundamental. Contratos de entrada e saída normalizados, modelos intercambiáveis atrás de uma interface, testes que validam o comportamento com modelos diferentes. Quando o Sonnet 4.6 resolve 90% das chamadas mas o o3 resolve os outros 10%, a arquitetura precisa suportar esse roteamento sem exigir reescrita.

Para funcionar adequadamente, FinOps de IA precisam medir custo e valor juntos, classificar os dados antes de escolher onde rodar, distribuir e garantir limites granulares por quem consome e projetar a camada de inferência pra trocar de provedor sem trauma. Se não for assim, é só jogo de planilhas.