Novo: Eficify One em beta aberto. Crie seu primeiro ambiente sem cartão.Conhecer a plataforma →
Semana passada, recebi o relato de uma empresa que viu uma fatura de cloud saltar 340% em 45 dias. A causa? Um agente de IA que, autônomo e sem limites, começou a fazer chamadas a APIs externas em loop infinito. Não foi um ataque, não foi um bug malicioso. Foi um agente comportando-se conforme projetado, dentro de uma especificação que nunca definiu quanto ele poderia gastar. Esse cenário está se tornando comum, e a maioria das lideranças executivas ainda não percebeu que precisa governar agentes de IA como governa qualquer ativo operacional.
Durante anos, discutimos FinOps para infraestrutura: como limitar gastos com compute, storage e networking. Agora, enfrentamos uma categoria nova. Agentes de IA, especialmente os baseados em LLMs, consomem tokens, chamam tools, executam ações, e cada ciclo de reasoning tem um custo real em dólares e centavos.
O problema não é o agente em si. É a ausência de três controles básicos que qualquer CFO exige de qualquer investimento operacional: teto de gasto, escopo de ação, e prestação de contas.
Um agente de IA autônomo, por definição, toma decisões e executa ações sem intervenção humana em cada passo. Essa autonomia é o valor. É também o perigo.
Três propriedades tornam agentes particularmente arriscados sem governança:
Consumo composto. Cada interação com um LLM gera tokens de input e output. Agentes que usam tools multiplicam chamadas. Um agente mal especificado pode consumir o equivalente a meses de compute tradicional em horas.
Ações de alto impacto. Diferente de uma query analítica, um agente pode disparar transfers, modificar registros, aprovar aprovações, enviar comunicações. A ação tem consequências que vão além do custo computacional.
Comportamento emergente. Agentes podem seguir caminhos que não foram previstos no design. Isso é feature, não bug. Mas sem guardrails, o caminho emergente pode ser financeiramente desastroso.
A solução não é restringir o agente até ele perder a utilidade. É criar uma arquitetura de governança que preserva autonomia dentro de limites claros.
Essa estrutura funciona de fora para dentro. Políticas de negócio definem o que o agente pode fazer em termos de domínio. Orçamentos definem o quanto ele pode consumir. Controles de permissão definem quais ações ele pode executar sem aprovação. E trilhas de auditoria garantem que, quando algo sair do esperado, você tenha dados para investigar.
Orçamento não é simplesmente um número máximo. É uma política com enforcement.
Orçamento por sessão. Cada conversa ou tarefa do agente recebe um teto de tokens. Quando o teto é atingido, o agente para e reporta.
Orçamento por período. Limites agregados diários, semanais ou mensais impedem que múltiplas instâncias consumam além do planejado.
Orçamentos hierárquicos. O agente pode ter autonomia para gastar R$ 50 em uma chamada simples, mas precisa de aprovação humana para operações acima de R$ 500 em compute.
O erro comum é definir o orçamento no nível da API, esperando que o provider cuide disso. Na prática, você precisa implementar budget enforcement no seu middleware, com circuit breakers e alertas antes do limite ser atingido.
Se o orçamento controla quanto o agente pode gastar, os limites de permissão controlam o que ele pode fazer.
Isso vai além de RBAC tradicional. Estamos falando de capabilities específicas que um agente pode invocar.
Tool allowlisting. O agente só pode chamar ferramentas que estão explicitamente autorizadas. Não é porque a API existe que o agente pode usar.
Escopo de dados. O agente pode ler dados de certas tabelas ou namespaces, mas não pode modificar. Ou pode modificar em staging, mas não em produção.
Threshold de ação. Ações acima de certo impacto (modificar config de produção, enviar email externo, criar usuário) exigem confirmação humana explícita.
Humano-in-the-loop não significa humano em cada passo. Significa identificar os pontos onde o impacto justifica a fricção.
Pontos de não-retorno. Ações que não podem ser desfeitas ou cujo rollback é caro devem ter checkpoint de aprovação.
Alterações de estado. Qualquer operação que mude o estado do sistema além do escopo da tarefa original precisa de validação.
Gasto inesperado. Se o agente detecta que o custo acumulado excede um threshold antes de completar a tarefa, ele para e escalona.
A pergunta não é se você vai ter fricção. É se a fricção está nos lugares certos. Colocar aprovação em toda chamada simples destrói a utilidade. Não colocar em nenhuma é receita para desastre.
Quando algo dá errado, você precisa de respostas rápidas: o que aconteceu, quando, qual foi o input que levou à decisão, quanto custou, e quem é o owner do comportamento.
Cada execução de agente deve gerar um log estruturado com:
Esses logs não são apenas para depuração. São para accountability. Quando um agente toma uma decisão que resulta em custo inesperado ou impacto operacional, você precisa de evidência para responder: isso foi comportamento esperado dado o prompt? Foi um caso extremo não previsto? Foi um problema de design?
agent:
name: suporte-tecnico-v2
model: gpt-4o
# Limite financeiro
budget:
session_max: 50.00 # R$ por sessão
daily_max: 500.00 # R$ por dia
alert_threshold: 0.75 # alerta em 75% do limite
# Permissões de ação
permissions:
allowed_tools:
- search_knowledge_base
- create_ticket
- read_customer_record
denied_tools:
- delete_customer_data
- execute_refund
- modify_pricing
# Limite de escalação humana
human_approval:
required_above: 200.00 # R$ em potencial impacto
required_for:
- delete_operations
- refund_requests
- privilege_escalation
# Trilha de auditoria
audit:
log_level: detailed
store_prompts: true
store_outputs: true
retention_days: 90
Esse arquivo é uma referência conceitual. O ponto não é a sintaxe específica, mas o princípio: cada parâmetro desse precisa existir, ser documentado, e ser revisado periodicamente.
Governar agentes de IA não é um projeto de segurança isolado. É uma disciplina operacional que cruza FinOps, segurança, compliance e engenharia de plataforma.
As empresas que estão conseguindo extrair valor de agentes autônomos sem incidentes são as que trataram governança como parte do design do agente, não como uma camada adicionada depois.
Se você está em 2024 e tem agentes em produção sem um documento de política como esse, você não tem controle. Tem esperança. E esperança não é uma estratégia de FinOps.
Se você está deployando agentes de IA em produção sem um framework de governança documentado, esse custo vai aparecer. Vamos em uma conversa de 30 minutos mapear onde o risco está escondido no seu ambiente e o que fazer antes da próxima fatura.
CONTINUE LENDO
Ter um especialista que resolve tudo parece uma vantagem. Quase sempre é um passivo escondido. Os custos que não aparecem no balanço quando a empresa depende de poucas pessoas-chave, e como reduzi-los sem perder talento.
Reli o clássico de Richards e Ford com uma tese provocadora: IA não é ferramenta de produtividade, é sistema de julgamento. E os fundamentos de arquitetura, trade-offs, características, decisões reversíveis, são, no fim, os fundamentos da infraestrutura de julgamento que toda empresa vai precisar.
Não dá para melhorar o que não se mede. Um modelo prático de maturidade do conhecimento, cinco níveis, métricas objetivas e o que observar para sair da dependência de heróis.
VAMOS CONVERSAR
Conte seu cenário e receba uma leitura externa da sua arquitetura e dos próximos passos.
Agendar um assessment