A maioria das equipas descobre o problema dos orçamentos de agentes quando recebe a fatura. Nessa altura, a decisão de arquitetura mais importante já ficou para trás.

Um orçamento útil para um agente de IA não é apenas um teto de despesa. É uma regra de execução que define o que o sistema pode continuar a fazer quando os recursos começam a escassear. Se o limite for atingido e não existir um comportamento definido para esse momento, a organização tem contabilidade, não governação.

Este é o nono artigo da série em dez partes AI Governance in an AI-Native Software Development Company. A parte 8, O playbook de gestão de mudanças para agentes, tratou alterações de modelos, prompts, competências e ferramentas como deploys de produção. Esta parte aborda a pergunta seguinte: depois de um agente receber autoridade para agir, quanto custo, processamento, capacidade e tempo pode consumir?

Um orçamento não chega

Um único limite mensal em dinheiro é demasiado grosseiro para sistemas com agentes. O mesmo valor total pode esconder falhas muito diferentes: um ciclo que não termina, contexto excessivo, uma superfície de ferramentas que cresce sem controlo ou um workflow que esgota uma dotação partilhada.

Um modelo mais útil acompanha quatro dimensões em conjunto.

Orçamento de custo. O dinheiro continua a ser essencial. Pode ser limitado por pedido, tarefa, workflow, agente, equipa ou janela de faturação. Mas o custo é muitas vezes um sinal tardio: mostra o que foi consumido, sem explicar necessariamente porquê.

Orçamento de tokens. Os tokens estão mais próximos do comportamento do modelo. Crescimento inesperado pode revelar recuperação excessiva de contexto, prompts demasiado grandes, novas tentativas repetidas ou um agente que volta a ler a mesma informação em cada ciclo. A margem de tokens pode, por isso, acionar uma resposta antes de se atingir o limite financeiro.

Orçamento de capacidade. É a dimensão que muitas equipas omitem. Um agente não se torna mais difícil de governar apenas por gastar mais; torna-se também mais difícil quando ganha mais ferramentas, ambientes, tenants e vias de escalamento. A capacidade deve ser tratada como um recurso escasso. Cada nova ferramenta aumenta o esforço de avaliação, a superfície de auditoria e o raio de impacto.

Orçamento de tempo. Tempo real, número de passos e profundidade de ciclos são frequentemente a forma mais rápida de conter comportamento descontrolado. Uma iteração pode ser barata e ainda assim tornar-se perigosa se puder repetir-se indefinidamente. Limites de tempo ou de passos criam um ponto determinístico de paragem antes de a fatura se transformar num relatório de incidente.

As quatro dimensões formam um único controlo operacional: custo, tokens, capacidade e tempo.

O orçamento tem de existir onde a decisão acontece

Um dashboard atualizado depois de a tarefa terminar não consegue governar a tarefa que já está em execução. O estado do orçamento tem de estar disponível na mesma camada de política de runtime que decide se uma ação pode avançar.

Em cada decisão, o avaliador pode receber informação como custo restante, margem de tokens, passos disponíveis, quota ativa de ferramentas e o âmbito a que pertence a dotação. O veredito pode mudar à medida que o orçamento diminui.

Uma síntese cara pode avançar quando a maior parte do orçamento diário ainda está disponível, exigir aprovação perto do limite e ser recusada depois de esgotado. Uma chamada de ferramenta pode ser bloqueada porque o orçamento daquela competência terminou, mesmo que a equipa ainda tenha margem no nível superior.

Há aqui um princípio de contenção importante:

Deve prevalecer o âmbito mais estreito cujo orçamento se esgotou.

Se uma competência gastou a sua dotação, recorrer silenciosamente ao orçamento do nível acima anula a contenção. A hierarquia existe precisamente para impedir que um workflow ruidoso se transforme num incidente à escala da organização.

O que deve acontecer no limite?

A parte mais importante de um orçamento não é o número. É o comportamento associado a esse número.

Um modelo prático pode definir cinco respostas:

  • Recusar. A ação é negada e devolve uma razão estruturada.
  • Degradar. O trabalho continua com um modelo mais barato, menos contexto, menos tentativas ou um plano mais curto.
  • Escalar. A execução fica em pausa e pede autorização explícita para gastar além do limite.
  • Colocar em quarentena. O agente continua a produzir, mas a saída fica fora de produção até ser revista.
  • Parar. O agente ou workflow é suspenso até o orçamento ser reposto ou existir intervenção de um operador.

As respostas não são equivalentes. Degradação só é adequada quando uma qualidade inferior continua a ser segura e útil. A recusa é preferível quando uma resposta parcial pode induzir em erro. O escalamento faz sentido quando um humano pode justificar a despesa adicional. A quarentena é útil quando a ultrapassagem pode indicar comportamento anómalo. A paragem é indicada quando a própria ultrapassagem é um sinal de segurança.

A regra “recusar tudo a 100%” é simples, mas cria um precipício operacional. O comportamento deve ser escolhido por classe de ação e por dimensão do orçamento.

Um exemplo de produção

Imagine um agente de investigação de incidentes. Consulta logs, recolhe traces, analisa deploys recentes e constrói uma hipótese para a causa.

Durante uma indisponibilidade com muito ruído, começa a alargar todas as pesquisas. O custo ainda está em 55% da dotação do incidente e os tokens em 68%, por isso um dashboard financeiro parece saudável. No entanto, o workflow já consumiu 95% do orçamento de passos.

A política de runtime pode reagir antes do fracasso caro: reduzir a janela temporal, impedir novo fan-out, passar resumos de baixo valor para um modelo mais barato e pedir aprovação antes de qualquer pesquisa adicional de grande alcance.

O ponto importante não é apenas tornar o agente mais barato. O sistema reconheceu qual orçamento estava a falhar primeiro e aplicou a resposta previamente definida.

A atribuição transforma orçamento em evidência

Não se pode governar aquilo que não se consegue atribuir.

A unidade útil não é apenas “a conta de IA”. O consumo deve ser atribuível ao agente, à competência, ao workflow, à equipa responsável e, quando aplicável, ao tenant. Estas dimensões devem usar os mesmos identificadores de correlação da cadeia de proveniência e da auditoria.

A conversa muda. Em vez de perguntar por que razão a despesa de IA aumentou 30%, o operador pode identificar que um workflow duplicou a profundidade de recuperação depois de uma alteração de prompt, ou que uma competência passou a chamar uma ferramenta cara três vezes por tarefa.

Cada evento de orçamento também se torna explicável: qual âmbito se esgotou, qual dimensão alterou o veredito, que margem restava e que política escolheu a resposta final.

A capacidade merece um orçamento próprio

Custos e tokens são visíveis porque são faturados. A capacidade costuma chegar como “mais uma funcionalidade” e, por isso, é mais fácil deixá-la crescer sem controlo.

Para cada agente em produção, a organização deve conseguir listar as ferramentas que pode chamar, as competências que pode invocar, os ambientes a que pode chegar, os domínios de dados que pode tocar e as vias de escalamento que pode acionar. Nova capacidade deve ser uma alteração explícita desse inventário, não crescimento ambiente.

Uma regra simples ajuda: cada capacidade adicionada deve ter um responsável, uma obrigação de avaliação e um caminho de remoção.

Sem subtração, agentes partilhados acumulam ferramentas até ninguém conseguir raciocinar sobre toda a superfície de ação. O custo financeiro aumenta, mas o custo de governação tende a aumentar ainda mais depressa.

Sinais de um orçamento apenas nominal

Alguns padrões mostram que o orçamento existe apenas no papel.

O limite é aumentado repetidamente sem se investigar o que o consome. Uma competência esgota a sua dotação local e passa silenciosamente a usar a do nível superior. Um agente entra num ciclo barato de novas tentativas que dura horas. As equipas adicionam ferramentas, mas nunca retiram nenhuma. As ultrapassagens aparecem primeiro nos relatórios financeiros e não nos eventos de runtime. Ou o sistema só conhece dois estados: execução ilimitada e recusa total.

A causa é a mesma: o orçamento está a ser tratado como um número, não como uma entrada de aplicação de política.

Uma ordem prática de implementação

Não é preciso construir uma nova plataforma FinOps para começar. O melhor é partir dos agentes de maior impacto e ampliar a superfície de controlo de forma incremental.

  1. Inventariar os agentes em produção e as respetivas capacidades ativas.
  2. Atribuir custos e tokens ao agente, à competência e ao workflow.
  3. Definir orçamentos explícitos para custo, tokens, capacidade e tempo.
  4. Escolher o comportamento no limite para as classes de ações importantes.
  5. Incluir o orçamento restante na avaliação da política de runtime.
  6. Emitir evidência para recusas, degradações, escalamentos, quarentenas e paragens.
  7. Rever regularmente capacidades sem utilização e remover as que já não justificam o custo operacional.
  8. Testar o esgotamento dos orçamentos antes que a produção o faça por si.

O objetivo não é prever todos os excessos possíveis. É tornar o comportamento perante o excesso determinístico, limitado e observável.

A verdadeira fronteira de governação

O FinOps de agentes é muitas vezes apresentado como um problema financeiro porque a fatura é a parte mais visível. O problema mais profundo é autoridade.

Um orçamento define até onde o sistema está autorizado a consumir um recurso escasso antes de ser obrigado a alterar o comportamento. Dinheiro é um desses recursos. Tokens, ferramentas e tempo também são.

Quando desenhados desta forma, os orçamentos encaixam naturalmente ao lado de permissões, contenção, proveniência e gestão da mudança. Passam a fazer parte do contrato de runtime, em vez de serem um relatório produzido depois dos factos.

Esse é o significado operacional do Modelo dos Quatro Orçamentos: governar custo, tokens, capacidade e tempo em conjunto e decidir antecipadamente o que o sistema fará quando qualquer uma das dimensões se esgotar.

A equipa que apenas explica a fatura está a observar os seus agentes.

A equipa que define o comportamento do orçamento está a governá-los.

Próxima e última parte: O Modelo de Maturidade da Governação AI-Native, que liga os controlos anteriores num modelo operacional por etapas.

Este artigo foi publicado originalmente por Reza Arani no Medium em junho de 2026 e adaptado para a Aipolix como a nona parte da série AI Governance in an AI-Native Software Development Company.