Agentes de IA em produção: guardrails, modos de falha e um checklist real

Agentes de IA em produção não são chatbots com uma chamada de ferramenta pendurada. Uma demo prova que o modelo consegue completar um caminho feliz. Um agente em produção prova que o sistema ao redor consegue restringir, observar e recuperar o modelo quando a realidade fica bagunçada.

Se você está planejando agentes de IA em produção, a pergunta certa não é "o modelo consegue agir?". É "o sistema consegue agir com segurança, de forma repetível e visível o suficiente para um time confiar nele em produção?". Isso exige contratos de ferramentas, limites de execução, revisão humana, evals e uma forma de interromper comportamento ruim cedo.

Um agente é um sistema capaz de interpretar um objetivo, decidir se usa ferramentas, observar o resultado e ajustar o próximo passo. É isso que o diferencia de um workflow determinístico com saída de modelo no meio.

A distinção importa:

• um workflow segue um caminho predefinido
• um agente escolhe entre caminhos com base em observações intermediárias
• um agente em produção adiciona autonomia limitada, não improviso ilimitado

Se o caminho é fixo e o modelo só preenche um slot nesse caminho, você talvez nem precise de um agente. Em muitos casos, um workflow bem desenhado somado a uma avaliação consistente é o padrão mais seguro. É exatamente por isso que avaliação antes da orquestração deve vir antes do design do agente.

Demos escondem as partes que a produção expõe:

• entradas incompletas ou contraditórias
• ferramentas instáveis e APIs downstream falhando
• timeouts, retries e limites de orçamento
• usuários pedindo ações arriscadas ou ambíguas
• conteúdo recuperado que pode estar desatualizado ou malicioso

É por isso que sistemas de agentes precisam de um modelo operacional ao redor do modelo. A orientação pública da Anthropic sobre como construir agentes eficazes é útil aqui porque enfatiza uso delimitado de ferramentas, estado explícito e autonomia restrita, em vez de improviso aberto (Anthropic: Building effective agents).

A maioria das falhas de agentes não é espetacular. Elas são pequenas, repetidas e caras.

O agente escolhe a ferramenta errada, envia parâmetros errados ou inventa um estado do sistema que não existe. Se o sistema de registro diz uma coisa e o modelo diz outra, o sistema de registro vence.

O agente fica replanejando, refazendo consultas ou retentando sem progredir. Orçamentos de execução e limites de passos existem para isso não virar dívida silenciosa de custo e latência.

O agente reporta sucesso mesmo com uma etapa downstream tendo falhado. Isso é comum quando a orquestração atravessa múltiplas ferramentas, jobs em background ou sistemas assíncronos.

Qualquer entrada não confiável pode se tornar fonte de instrução se o sistema for desleixado. A OWASP hoje trata prompt injection como risco de primeira linha em GenAI porque documentos recuperados, e-mails, tickets e páginas web podem alterar o comportamento se forem tratados como autoridade em vez de dado (OWASP LLM01).

O modelo é só uma parte do sistema. O restante do sistema decide se o agente é operável.

Toda ferramenta deve definir:

• schema estrito de entrada
• schema estrito de saída
• semântica de erro explícita
• timeouts
• política de retry
• fronteira de autorização

Se o contrato da ferramenta é vago, o agente vai adivinhar. Isso não é autonomia. É comportamento indefinido.

Algumas ações nunca deveriam ser autônomas. Outras devem exigir revisão com base em custo, risco ou nível de confiança.

Fronteiras úteis incluem:

• somente ferramentas de uma allowlist
• aprovação por limiar para ações arriscadas
• restrições de ambiente entre staging e produção
• classes de efeito colateral que sempre exigem revisão humana

Agentes precisam de limites:

• máximo de passos por execução
• máximo de retries por ferramenta
• orçamento máximo de custo
• tempo máximo de execução (wall-clock)

Se o agente pode disparar efeitos colaterais, torne essas ações idempotentes. O mesmo princípio de idempotência para webhooks vale aqui: retries são normais, efeitos duplicados não.

Revisão humana não é sinal de que o agente é fraco. É sinal de que o produto respeita o risco.

Exija aprovação quando a ação é:

• irreversível
• voltada ao cliente
• financeiramente sensível
• juridicamente sensível
• difícil de desfazer
• baseada em evidência de baixa confiança

Uma boa revisão humana deve mostrar:

• a ação proposta
• a evidência usada
• o sinal de confiança ou de incerteza
• o caminho exato de aprovação ou rejeição

Se você não consegue rastrear o que o agente viu, decidiu e fez, você não consegue operá-lo.

No mínimo, registre:

• a requisição da tarefa
• a versão do modelo
• as chamadas de ferramenta
• entradas e saídas das ferramentas
• eventos de aprovação
• retries e falhas
• o resultado final
• latência e custo

Para sistemas de múltiplas etapas, a inspeção de traces importa porque a resposta final costuma esconder onde a falha começou. É por isso que a operação de agentes conecta diretamente com observabilidade para engenheiros de produto e com a disciplina de avaliação antes de mais autonomia.

Use isto como a régua mínima de produção:

Se várias linhas ainda estão vagas, o sistema não está pronto para produção.

Evite agentes quando:

• a ação é determinística e baseada em regras
• o workflow é fácil de codificar diretamente
• o custo de uma ação errada é alto
• o sistema já tem um caminho de implementação claro e explícito

Nesses casos, um workflow orientado a ferramentas ou lógica de aplicação padrão costuma ser melhor. Aplique a lente de arquitetura de quando RAG é a resposta errada antes de adicionar autonomia por hábito.