Finops Ia Custo por Execução: Como Controlar o Gasto

Um agente de IA autônomo não gasta como um chatbot. Ele pode abrir um loop de raciocínio, chamar três ferramentas externas, errar uma vez, tentar de novo e só então entregar o resultado. Cada uma dessas etapas tem custo próprio, e a soma final raramente se parece com a estimativa feita a partir do preço por token.

Esse descompasso é o motivo pelo qual times de engenharia recebem faturas de API acima do previsto mesmo tendo calculado “direitinho” o custo médio por chamada. O problema não é o cálculo errado. É a unidade de medida errada.

Segundo a Gartner, em comunicado amplamente citado de 2024/2025, estima-se que até 2027 mais de 40% dos projetos de agentes de IA sejam descontinuados por custo imprevisível, baixo valor percebido ou controle de risco inadequado, recomenda-se buscar o press release original no site da Gartner antes de citar o percentual em contextos que exijam precisão factual.. Isso não é um detalhe técnico. É um risco de orçamento que chega à mesa do CFO.

Este artigo apresenta um framework de FinOps de IA centrado na execução completa do agente, não no token isolado, com fórmula de cálculo, pontos de instrumentação e um modelo de governança de orçamento aplicável em um único sprint.

Resumo

• Custo por token é insuficiente para agentes autônomos porque não captura loops de raciocínio, retries e chamadas a ferramentas dentro de uma mesma tarefa.
• A unidade correta de análise é o custo por execução: soma de custo de modelo, ferramentas e infraestrutura, dividida pelas execuções concluídas com sucesso.
• Instrumentação exige um ID único de execução que correlacione cada evento de custo, desde a primeira chamada de modelo até a entrega final.
• A ausência de tagging por centro de custo é generalizada: segundo edições recentes do State of FinOps Report da FinOps Foundation, uma parcela significativa das organizações relata dificuldade em atribuir gastos de nuvem a projetos específicos, problema que se agrava com cargas de trabalho de IA (consulte a edição mais recente do relatório para o percentual atualizado).
• Orçamento de IA funciona melhor como faixa de custo aceitável por tipo de tarefa, com alertas automáticos e circuit breakers para interromper execuções fora do padrão.

O que é FinOps de IA e por que o custo por token não basta?

FinOps de IA é a prática de atribuir, prever e governar o custo de cargas de trabalho de IA generativa ao longo de todo o ciclo de execução, não apenas no momento da chamada ao modelo. O custo por token falha porque não captura loops de raciocínio, retries e chamadas a ferramentas que um agente faz dentro de uma única tarefa.

No FinOps tradicional de cloud, a unidade de análise é relativamente estável: uma instância, um bucket de armazenamento, uma hora de computação. Em IA generativa agêntica, a unidade de trabalho não é fixa. Um agente pode resolver a mesma classe de tarefa com 1 chamada de modelo em um dia e 15 chamadas no dia seguinte, dependendo da ambiguidade da entrada, da qualidade do contexto recuperado ou de uma falha intermediária que dispara nova tentativa.

É comum observar, em implantações que usam ferramentas e etapas de verificação, que tarefas complexas envolvem múltiplas chamadas de API por execução, um padrão também discutido na documentação de observabilidade do LangSmith, embora sem um número médio padronizado e validado publicamente.. Isso significa que duas execuções aparentemente idênticas, do ponto de vista do usuário, podem ter estruturas de custo completamente diferentes por dentro.

Um exemplo simplificado ilustra o problema. Uma tarefa de triagem de e-mail pode custar R$ 0,02 quando o agente classifica o conteúdo em uma única chamada. A mesma tarefa, para um e-mail ambíguo, pode acionar duas chamadas de refinamento, uma busca em base de conhecimento e uma validação final, chegando a R$ 0,18. Multiplicado por milhares de execuções mensais, a diferença deixa de ser irrelevante e passa a ser uma linha orçamentária que ninguém sabia que existia.

Na prática de implantação de agentes que observamos, o salto de custo mais perigoso não acontece entre tarefas simples e médias, acontece na transição de “tarefa média” para “tarefa com retry”. É esse degrau que corrói a previsibilidade orçamentária, porque ele depende de taxa de erro do agente, não do volume de uso.

Como calcular o custo real de uma execução de agente?

O custo por execução é a soma de todas as chamadas de modelo, ferramentas externas e infraestrutura consumidas do início ao fim de uma tarefa do agente, dividida pelo número de execuções concluídas com sucesso. Essa é a fórmula central do FinOps de IA aplicado a agentes autônomos, e ela substitui o cálculo simplificado de “preço por token vezes volume”.

A fórmula prática pode ser escrita assim:

Custo por execução = (Custo de modelo + Custo de ferramentas + Custo de infraestrutura) / Execuções bem-sucedidas

Onde:

• Custo de modelo é a soma de tokens de entrada e saída de todas as chamadas feitas durante a execução, multiplicada pelo preço vigente do provedor (os preços da OpenAI e da Anthropic variam por modelo e são atualizados periodicamente, conforme suas páginas oficiais de pricing da OpenAI e pricing da Anthropic).
• Custo de ferramentas inclui chamadas a APIs de terceiros, buscas vetoriais, consultas a bancos de dados externos e qualquer serviço pago acionado pelo agente.
• Custo de infraestrutura cobre computação, armazenamento de contexto e orquestração que sustentam a execução.
• Execuções bem-sucedidas são apenas as que completaram a tarefa com o resultado esperado, não o total de tentativas disparadas.

Um exemplo numérico simplificado: um agente de atendimento processa 1.000 tickets em um dia. O custo total de modelo foi R$ 420, o de ferramentas (busca em base de conhecimento e CRM) foi R$ 95, e o de infraestrutura foi R$ 35. Desses 1.000 tickets, 920 foram resolvidos com sucesso na primeira tentativa e 80 precisaram de reprocessamento humano após falha do agente. Em um exemplo hipotético para fins didáticos: o custo por execução bem-sucedida seria (420 + 95 + 35) / 920 = R$ 0,598 por ticket resolvido, não R$ 0,55 por ticket processado, valores ilustrativos, não benchmark de mercado. A diferença parece pequena, mas se amplifica em escala e, principalmente, esconde o “custo de fracasso”: os 80 tickets que consumiram tokens e não geraram valor, e que exigiram intervenção humana, um cuidado alinhado ao espírito do art. 20 da LGPD, que trata do direito de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais, ainda que a extensão exata dessa revisão (humana ou não) seja objeto de debate jurídico desde a alteração promovida pela MP 1.124/2022. Esse direito de revisão deve ser desenhado como parte do fluxo, não como custo residual.

Esse custo de fracasso é um dos pontos mais negligenciados em relatórios de FinOps de IA, porque a maioria dos dashboards de billing de provedor de LLM mostra gasto total, não gasto por resultado entregue.

Quais pontos do pipeline devem ser instrumentados?

Todo ponto onde o agente toma uma decisão de chamar um modelo, uma API externa ou repetir uma etapa deve gerar um evento de custo rastreável, vinculado a um ID único de execução. Sem esse ID, é impossível reconstruir depois quanto custou, de fato, uma tarefa específica que falhou ou que custou fora da média.

Na prática, isso significa instrumentar quatro camadas:

1. Chamadas a LLM: registrar tokens de entrada e saída por etapa, não apenas o total agregado da sessão.
2. Chamadas a ferramentas e APIs externas: cada acionamento de busca, scraping, CRM ou serviço pago precisa de timestamp, custo unitário e resultado (sucesso ou falha).
3. Correlação por trace ID: todo evento de custo deve carregar o mesmo identificador de execução, permitindo reconstruir a árvore completa de decisões de um único run do agente.
4. Tags de custo: cada execução recebe metadados de agente, caso de uso e, quando aplicável, cliente ou departamento solicitante, esses registros devem ter controle de acesso baseado em função (RBAC), retenção definida, mascaramento ou tokenização de dados pessoais presentes em prompts/contexto antes de chegarem a dashboards de FinOps, e tratamento conforme a LGPD, evitando que dados sensíveis fiquem visíveis a times sem necessidade de acesso.

A analogia mais próxima do mercado de observabilidade tradicional é o tracing distribuído em microsserviços: assim como uma requisição HTTP atravessa vários serviços e precisa de um trace ID para ser reconstruída, uma execução de agente atravessa várias chamadas de modelo e ferramentas e precisa do mesmo tipo de correlação. Ferramentas como o LangSmith nasceram justamente para preencher essa lacuna em pipelines baseados em LangChain e frameworks similares.

Um ponto prático de ganho é vincular a instrumentação de custo à mesma infraestrutura de observabilidade usada para depuração de agentes. Isso evita manter dois sistemas paralelos, um para debugging técnico e outro para FinOps, que normalmente divergem e geram retrabalho.

Como atribuir custo de IA a centros de custo e departamentos?

Atribuição de custo exige tagging consistente desde o design do agente, vinculando cada execução a um centro de custo, projeto ou cliente final antes mesmo de ir para produção. Segundo a FinOps Foundation, a incapacidade de atribuir gastos de nuvem a centros de custo específicos é apontada, em edições recentes do State of FinOps Report, como uma lacuna recorrente relatada por organizações que praticam FinOps, recomenda-se consultar a edição mais atual para o percentual exato, e o problema se agrava quando a carga de trabalho é de IA generativa com múltiplos agentes compartilhando a mesma infraestrutura (FinOps Foundation, State of FinOps Report).

O modelo de tagging recomendado segue três eixos:

Eixo de tag	Exemplo de valor	Finalidade
Departamento	Atendimento, Jurídico, Financeiro	Chargeback por área de negócio
Caso de uso	Triagem de ticket, análise de contrato	Comparação de custo entre agentes
Ambiente	Produção, homologação, sandbox	Isolar custo de teste do custo real

A diferença entre chargeback e showback importa aqui. No chargeback, o custo de IA é efetivamente debitado do orçamento da área que o gerou, criando incentivo direto para otimização. No showback, o custo é apenas reportado para visibilidade, sem transferência orçamentária formal. Empresas em estágio inicial de FinOps de IA tendem a começar com showback, migrando para chargeback conforme a maturidade de instrumentação aumenta.

Relatórios periódicos para times financeiros não técnicos devem evitar jargão de engenharia. Em vez de “tokens consumidos por chamada”, o relatório para o CFO deve mostrar “custo por ticket resolvido” ou “custo por contrato analisado”, acompanhado de indicadores de qualidade e taxa de revisão humana, não como KPI de eficiência a ser minimizado, mas como garantia legal que não pode ser reduzida por pressão de custo. O direito do titular dos dados a correções e revisões adequadas (art. 20 LGPD) é inegociável diante de metas orçamentárias: métricas de custo isoladas, sem contexto de qualidade e sem salvaguarda explícita desse direito, tendem a incentivar reduções indevidas de supervisão humana, o que pode configurar não conformidade legal, não apenas risco técnico. Esse alinhamento também fortalece a camada de governança de IA generativa para empresas brasileiras, que deve considerar, à medida que avança a tramitação do PL 2338/2023 (Marco Legal da IA) no Brasil, a eventual classificação de risco de agentes autônomos que afetem direitos de titulares de dados, com exigências adicionais de documentação e supervisão humana, já que custo mal atribuído costuma andar junto com controle frouxo sobre quais dados o agente está processando e para quem.

Por que o mesmo agente pode ter custos muito diferentes entre execuções?

Variações decorrem de complexidade da tarefa, número de iterações de raciocínio, falhas que geram retry e uso de ferramentas externas com custo variável, fatores que não aparecem numa estimativa baseada só em tokens médios. Dois tickets de atendimento aparentemente parecidos podem gerar execuções com diferenças de custo significativas, em casos observados na prática, de várias vezes o valor da execução mais simples, dependendo de quantas vezes o agente precisou repetir etapas de raciocínio (estimativa qualitativa, sem benchmark quantitativo validado publicamente).

Três causas concentram a maior parte dessa variação:

• Loops de auto-correção e re-planejamento: quando o fluxo do agente inclui uma etapa de verificação que, com base em critérios predefinidos, aciona uma nova chamada ao modelo para refazer um passo, cada ciclo adicional consome tokens de entrada e saída novamente, muitas vezes incluindo todo o histórico de contexto anterior.
• Prompts mal otimizados: contextos excessivamente longos ou mal estruturados aumentam o custo de entrada em cada chamada, mesmo quando a tarefa em si é simples.
• Runaway agents: execuções que entram em loop sem convergir para uma resposta final, consumindo chamadas indefinidamente até um limite de segurança (quando existe) interrompê-las.

É um problema frequentemente relatado por praticantes de observabilidade de agentes, e também discutido na documentação do LangSmith, fornecedor com interesse comercial no tema, que loops não controlados (‘runaway agents’) podem causar picos de custo inesperados em produção, reforçando a necessidade de limites automáticos de iteração por execução.

Um padrão que vemos se repetir em implantações reais: o custo de um agente tende a cair nos primeiros dois ou três meses de produção, não porque o modelo ficou mais barato, mas porque o time ajusta prompts e corrige casos de borda que geravam retry. Isso significa que medir custo por execução desde o primeiro dia é também uma forma de medir a curva de aprendizado da própria engenharia do agente.

Esse tipo de instabilidade também é um sinal de alerta para compliance e para proteção de dados: agentes que fazem chamadas repetidas a ferramentas externas sem controle claro podem estar enviando dados pessoais a terceiros mais vezes do que o necessário, por isso cada chamada a ferramenta externa que processe dados pessoais deve ser registrada em log de auditoria com controle de acesso restrito e sem exposição de dados pessoais em texto claro no corpo do log, aplicar minimização de dados (enviar apenas os campos estritamente necessários) e usar criptografia em trânsito (TLS) e em repouso, além de controle de acesso (autenticação e autorização) na integração, o que pode configurar risco de violação ao princípio da minimização (art. 6º, III, LGPD), caso os dados enviados excedam o estritamente necessário para a finalidade da chamada. Toda execução que processe dados pessoais deve ter finalidade específica documentada, base legal identificada e mecanismo de revisão humana para decisões que afetem o titular dos dados, não apenas rastreamento de custo.

Como estabelecer orçamento e alertas de custo para agentes de IA?

Orçamento de IA deve ser definido por faixa de custo por execução aceitável, com alertas automáticos quando uma execução ou um agregado diário ultrapassa o limiar definido. Esse modelo é diferente do orçamento de cloud tradicional, que geralmente trabalha com teto mensal fixo, porque o custo de IA agêntica varia por tarefa e precisa de controle no nível da execução individual, não só no nível agregado.

Um SLA de custo por tipo de tarefa pode ser definido assim: tarefas simples devem custar entre R$ 0,01 e R$ 0,05, tarefas médias entre R$ 0,05 e R$ 0,30, e tarefas complexas até R$ 1,00. Qualquer execução que ultrapasse esse teto dispara um alerta e, em casos críticos, um circuit breaker que interrompe o agente antes de completar mais uma iteração custosa. Esse mecanismo também deve ser tratado como controle de segurança contra ataques de negação de serviço financeira (‘denial of wallet’), incluindo cenários de prompt injection que induzam loops custosos deliberadamente, e deve gerar evento correlacionável para a equipe de segurança, não apenas para FinOps.

A revisão periódica desse orçamento é necessária porque o comportamento do agente muda com o tempo: novos tipos de tarefa aparecem, o volume cresce, e otimizações de prompt reduzem custo médio. Um orçamento definido no piloto e nunca revisado tende a ficar obsoleto rapidamente, seja por ficar frouxo demais (permitindo desperdício) ou rígido demais (bloqueando execuções legítimas mais complexas).

Quais ferramentas apoiam FinOps de IA na prática?

Existem desde plataformas de observabilidade de LLM dedicadas até adaptações de ferramentas de FinOps tradicionais, mas o essencial é garantir rastreabilidade ponta a ponta por execução, não apenas a escolha da ferramenta em si. A decisão entre comprar uma solução pronta ou construir instrumentação própria depende do volume de agentes em produção e da complexidade dos pipelines.

As categorias principais são:

• Observabilidade de LLM: ferramentas como LangSmith, focadas em tracing de chamadas de modelo e ferramentas dentro de um mesmo fluxo de agente.
• APM tradicional adaptado: plataformas de monitoramento de aplicação que incorporaram suporte a métricas de LLM, úteis quando o agente já roda sobre infraestrutura já monitorada por essas ferramentas.
• Dashboards de custo em cloud: painéis nativos de provedores de nuvem, que mostram gasto agregado mas raramente descem ao nível de execução individual sem instrumentação adicional.

Os critérios práticos para decidir entre comprar e construir incluem: número de agentes diferentes em produção, necessidade de integração com sistemas financeiros internos já existentes, e exigência de auditoria detalhada para fins de compliance. Empresas com poucos agentes e alto rigor de compliance frequentemente optam por instrumentação própria integrada ao pipeline de CI/CD, garantindo que todo novo agente nasça com tagging e rastreamento de custo desde o primeiro deploy. Esse tipo de decisão se conecta com o planejamento geral de automação de processos com IA e por onde começar, já que FinOps de IA funciona melhor quando desenhado junto com a arquitetura do agente, não como camada adicionada depois.

Vale lembrar que agentes instrumentados de forma incompleta também são uma porta de entrada para shadow AI, quando times criam seus próprios agentes fora da governança central justamente porque o processo formal é lento. Esse risco é detalhado em riscos de shadow AI e como mitigá-los.

Perguntas Frequentes

Como calcular o custo de um agente de IA?
O custo de uma execução de agente é a soma do custo de modelo (tokens de entrada e saída em todas as chamadas), custo de ferramentas externas acionadas e custo de infraestrutura, dividida pelo número de execuções concluídas com sucesso. Esse cálculo deve ser feito por execução individual, não por média geral de tokens consumidos no período.

O que é FinOps aplicado à inteligência artificial?
FinOps de IA é a prática de atribuir, prever e governar o custo de cargas de trabalho de IA generativa, estendendo princípios de FinOps de cloud (visibilidade, otimização, governança) para a unidade específica de agentes: a execução completa de uma tarefa, não apenas o consumo de tokens ou de infraestrutura.

Por que o custo de agentes de IA varia tanto entre execuções?
A variação decorre da complexidade da tarefa, do número de iterações de raciocínio que o agente executa, de falhas que geram retry e do uso de ferramentas externas com custo variável. Duas execuções da mesma tarefa podem ter estruturas internas de decisão muito diferentes, mesmo com entrada e saída aparentemente similares.

Como prever o gasto mensal com IA generativa em produção?
A previsão exige histórico de custo por execução segmentado por tipo de tarefa, multiplicado pela projeção de volume esperado para cada tipo. Modelos que usam apenas custo médio por token tendem a subestimar o gasto real, porque ignoram a cauda de execuções complexas com retry, que concentra parte desproporcional do custo total.

Qual a diferença entre custo por token e custo por execução?
Custo por token mede apenas o preço cobrado pelo provedor de modelo por unidade de texto processada. Custo por execução soma todas as chamadas de modelo, ferramentas e infraestrutura usadas para completar uma tarefa inteira do agente, do início ao resultado final, incluindo retries e chamadas intermediárias.

Fontes:

• FinOps Foundation, State of FinOps Report
• OpenAI, Página oficial de preços de API
• Anthropic, Página oficial de preços de API
• CGI.br, Pesquisa TIC Empresas
• McKinsey, The State of AI
• LangChain / LangSmith, Documentação sobre observabilidade de agentes