Controles de gasto de agentes de IA: cinco camadas, e quais delas de fato barram a fatura

Controles de gasto de agentes de IA são os mecanismos que decidem quem é cobrado pelas chamadas de modelo e pelo compute de um agente, quem consegue ver esse gasto e o que acontece quando ele passa de um limite. Eles importam mais para agentes do que para chat porque uma tarefa de agente pode fazer dezenas de chamadas de modelo, tentar de novo por conta própria e rodar de madrugada. Uma comparação de preço por token diz quase nada sobre quanto um agente vai custar.

Este guia agrupa os controles em cinco camadas, seguindo a estrutura que a AWS publicou em 30 de outubro no playbook dela para custos de Bedrock, e acrescenta o que a Databricks e outros já entregam. A coluna mais importante é a que os fornecedores menos mencionam: a velocidade com que cada controle age.

1. 1. Atribuir: quem gastou
2. 2. Observar: para onde foi
3. 3. Impor: o que barra
4. 4. Otimizar: gastar menos por tarefa
5. 5. Revisar: custo por resultado

1. Atribuição: toda chamada precisa de um dono

Gasto que não pode ser atribuído não pode ser controlado. O playbook da AWS atribui o uso de Bedrock por meio de principals do IAM e de tags, de modo que o custo caia sobre um time, uma aplicação ou um usuário. O principal alerta é sobre identidades compartilhadas: quando todo agente chama modelos por um único role de gateway, todo o gasto é atribuído a esse role e a visibilidade por usuário desaparece, a menos que o gateway repasse as sessões de usuário. O Bedrock também não impõe metadados de requisição, então esquemas de tagging derivam se nenhum componente os injetar de forma centralizada.

A Databricks oferece tags de compute serverless para o mesmo fim, atualmente em beta, e um novo identificador de compute nas tabelas de faturamento para atribuir gasto por objeto de compute.

2. Observabilidade: saber antes da fatura

Os relatórios de custo e uso da AWS atrasam cerca de um dia. Logs de invocação e telemetria dão visões quase em tempo real, mas vêm de outra fonte e podem divergir do faturamento. As system tables e os alertas de orçamento da Databricks estão em disponibilidade geral (GA) na AWS, no Azure e no Google Cloud, e a própria Databricks chama o monitoramento de reativo: ele avisa do gasto excessivo no dia seguinte em vez de evitá-lo.

3. Imposição: a camada que de fato barra uma fatura

É aqui que os controles mais diferem, e a diferença é tempo.

• Alertas de orçamento notificam. Não bloqueiam nada.
• Imposição assíncrona via IAM, no desenho da AWS, revoga o acesso depois que um estouro é detectado. A AWS observa que isso leva de segundos a minutos, ou até a próxima renovação de credencial, então parte do gasto entra depois do limite.
• Limites síncronos no gateway verificam cada requisição antes de ela chegar ao modelo e podem recusá-la. São o único hard stop, e acrescentam um componente no caminho da requisição que precisa ser implantado, escalado e passar por revisão de segurança.
• Rate limits no compute, como os novos limites em beta da Databricks para notebooks e jobs serverless, definem um teto de quanto uma carga pode escalar. A Databricks reforça que o tamanho é um máximo, não uma alocação fixa, e que orçamentos compartilhados para trabalho interativo ainda estão por vir.
• Controles de acesso decidem quem pode usar compute caro. Os controles de acesso ao compute serverless da Databricks estão em disponibilidade geral (GA).

Para treinamento e outras cargas de GPU, o AWS Batch agora oferece quota shares para jobs de treinamento do SageMaker: os times podem reservar capacidade, emprestar capacidade ociosa e tomar emprestado de outros, com preempção retomando a capacidade emprestada quando o dono precisa dela. A preempção interrompe jobs em execução, então checkpoint passa a fazer parte do desenho de custo.

4. Otimização: gastar menos pelo mesmo trabalho

As duas grandes alavancas são roteamento de modelos e cache. A AWS traz uma aritmética concreta de cache para modelos Claude no US East, em outubro de 2026: leituras de cache custam um décimo do preço base de entrada em alguns modelos e um vigésimo em outros, enquanto escritas de cache custam 25% a mais com vida de cinco minutos e o dobro com vida de uma hora. Dez chamadas contra um prefixo de prompt estável custam cerca de um quinto do preço sem cache; um cache escrito e nunca relido é custo puro.

O roteamento importa mais para agentes do que para chat. Mostramos como a Databricks cortou custos unitários de IA para programação com atrito progressivo no gateway em vez de tetos rígidos para seus melhores desenvolvedores.

5. Revisão: custo por resultado, não por token

O playbook da AWS termina onde deveria: no custo por resultado de negócio bem-sucedido. Um agente barato por chamada e que precisa de três tentativas por tarefa não é barato. Defendemos o mesmo em precificação de inferência por tarefa concluída. A revisão é também onde as camadas anteriores são corrigidas: um time cujo gasto vive surpreendendo o financeiro normalmente tem um problema de atribuição, não de modelo.

Perguntas para fazer a qualquer plataforma

1. Quais dos seus controles bloqueiam uma requisição, e quais apenas a reportam?
2. Quanto tempo passa entre cruzar um limite e o limite fazer efeito?
3. O gasto pode ser atribuído ao usuário final quando os agentes chamam por um gateway compartilhado?
4. O que acontece com uma tarefa de agente em execução quando o orçamento acaba: para, degrada para um modelo mais barato ou chama uma pessoa?
5. Quem pode aumentar um limite, e essa mudança fica registrada em log?

Para as cotas e tetos que as plataformas de modelo adicionaram neste ano, veja nosso panorama anterior de guardrails de gasto com IA. A versão curta dos dois textos: coloque o hard stop no caminho da requisição, atribua cada chamada a um dono e julgue a fatura pelo que os agentes entregaram.