Como tornar agentes de IA mais previsíveis

Agentes de IA podem responder de formas diferentes, escolher a ferramenta errada, repetir chamadas ou executar uma ação que ninguém autorizou. Para quem trabalha com dados, produto ou engenharia, isso pode transformar um excelente recurso em um problema operacional. O caminho para evitar isso passa por combinar arquitetura, contratos de ferramentas, avaliações e observabilidade, como já discutimos no guia sobre agentes de IA do Data Hackers.

Previsibilidade não significa eliminar a natureza probabilística dos modelos generativos. Significa limitar o espaço de decisões, definir o que pode acontecer e detectar rapidamente quando o agente sai desse espaço. Ao longo deste artigo, você verá como controlar permissões, instruções, memória, custos, chamadas de ferramentas, critérios de parada, testes, monitoramento e aprovação humana.

Agentes de IA são imprevisíveis porque decidem em um ambiente variável. O modelo pode interpretar uma instrução de outra forma, receber dados diferentes, escolher uma ferramenta inadequada ou não encontrar uma condição clara para encerrar. A Anthropic separa workflows, guiados por caminhos definidos, de agentes, que dirigem dinamicamente seus processos e ferramentas. Essa diferença explica boa parte da variação. A distinção é detalhada pela Anthropic.

O primeiro problema costuma ser a ambiguidade do objetivo. “Resolva o problema do cliente” permite muitas estratégias. O agente pode consultar o CRM, buscar uma política, fazer uma alteração ou pedir esclarecimentos. Se a ordem das prioridades não estiver explícita, cada execução poderá explorar um caminho diferente.

O contexto também muda. Uma resposta de API pode vir vazia, atrasada, duplicada ou com um campo inesperado. Um banco de dados pode receber novos registros entre duas chamadas. Até uma instrução correta pode produzir um resultado diferente quando a memória contém uma conversa longa ou uma informação conflitante.

A aleatoriedade do modelo é apenas uma camada. Temperatura, amostragem e versão do modelo afetam a saída, mas não explicam tudo. O agente também depende do estado externo, das permissões disponíveis e da qualidade das descrições das ferramentas. Reduzir a temperatura não corrige uma arquitetura com acesso amplo demais.

Outro ponto crítico são os loops. Sem limite de turnos, orçamento de chamadas ou critério de sucesso, o agente pode consultar a mesma fonte repetidamente. Ele também pode alternar entre duas ferramentas incompatíveis, tentar corrigir uma resposta já correta ou insistir diante de um erro que exige intervenção humana. Que evento encerra a tarefa precisa estar definido antes da execução.

Segundo a Anthropic, agentes costumam trocar custo e latência por flexibilidade e desempenho em tarefas complexas. A recomendação é começar pela solução mais simples e aumentar a autonomia apenas quando ela for necessária, como explica a empresa em seu guia de sistemas agentic. Isso ajuda a distinguir um problema de prompt de um problema de arquitetura.

Se um modelo escolhe o campo errado em uma ferramenta, talvez falte um schema. Se ele pode enviar um pagamento sem validação, falta controle de acesso. Se a tarefa exige uma sequência fixa, talvez um workflow determinístico seja mais adequado. Melhorar o texto do prompt nesses casos apenas disfarça uma falha de desenho.

Permissões, formatos, regras de negócio, estado, limites e condições de parada devem ser impostos pelo sistema, não apenas descritos ao modelo. A orientação da AWS é restringir a estocasticidade com tarefas atômicas, permissões de menor privilégio e protocolos claros de instrução. Assim, uma decisão inesperada afeta somente o que o agente está autorizado a acessar, segundo o Agentic AI Lens da AWS.

Comece pelas permissões. Uma ferramenta de consulta pode acessar dados sensíveis sem poder alterá-los. Uma ferramenta de escrita deve operar em recursos específicos, com identidade própria e escopo limitado. O agente de suporte não precisa de credenciais para excluir clientes, emitir pagamentos ou alterar regras de preço.

Depois, transforme regras de negócio em validações executáveis. “Não conceda descontos fora da política” é uma instrução útil, mas insuficiente. O serviço que aplica o desconto deve verificar percentual, perfil, prazo e aprovação exigida. Se a regra estiver apenas no prompt, uma interpretação errada pode produzir uma alteração real.

O estado também merece contrato. Registre o que já foi tentado, qual ferramenta respondeu, qual versão da política estava ativa e quais pré-condições foram satisfeitas. Antes de uma chamada de escrita, confirme se o registro ainda está no estado esperado. Essa checagem evita que uma decisão antiga seja aplicada sobre dados que mudaram.

Defina limites objetivos para tempo, custo, tokens, turnos e chamadas por ferramenta. Um limite global encerra a execução. Limites por etapa evitam que uma busca consuma todo o orçamento. Quando o limite for atingido, o sistema deve retornar um estado conhecido, explicar o motivo e encaminhar o caso, em vez de improvisar.

A AWS descreve cinco níveis de maturidade para execução previsível. Entre as práticas citadas estão agentes atômicos, schemas estruturados, papéis de IAM por agente, telemetria específica, prompts versionados e níveis de supervisão humana. A página também recomenda alertas baseados em comportamento e contratos adversariais contra injeção de prompt, na documentação de arquitetura bem projetada.

A aprovação humana entra quando a ação é cara, sensível, irreversível ou difícil de contestar. Um agente pode preparar um reembolso, mas não executá-lo sem revisão. Pode sugerir uma mudança em produção, mas exigir aprovação para aplicá-la. O desenho ideal separa trabalho preparatório de ação efetiva.

Esse modelo evita dois extremos. Autonomia aberta cria impacto difícil de controlar. Aprovação para tudo transforma o agente em uma interface lenta. Classifique ações como automáticas, notificáveis ou dependentes de aprovação. A decisão deve considerar valor financeiro, dados pessoais, risco regulatório, reversibilidade e confiança no contexto disponível.

Ferramentas previsíveis têm um propósito único, entradas estruturadas, saídas verificáveis e limites explícitos. Instruções previsíveis transformam objetivos vagos em ações observáveis, incluindo exceções, critérios de parada e situações que exigem ajuda. A OpenAI resume a base de um agente em modelo, ferramentas e instruções, no guia prático de construção de agentes.

Dê a cada ferramenta um verbo e um escopo claros. “Consultar pedido” é melhor que “gerenciar pedidos”. Separe leitura, simulação e escrita. Uma função que busca dados não deve também atualizar o cadastro. Quanto menor a superfície de cada operação, mais fácil fica testar parâmetros, autorizações e efeitos colaterais.

Use schemas com tipos, campos obrigatórios, enums e limites de tamanho. Valide a entrada antes da chamada e a saída antes de entregá-la ao próximo passo. Se o sistema espera uma data ISO, não aceite texto livre sem conversão. Se a API devolve um status desconhecido, interrompa a cadeia e registre o erro.

Operações com efeitos colaterais precisam ser idempotentes. Uma nova tentativa não pode gerar dois pagamentos, duas mensagens ou dois tickets. Inclua uma chave de idempotência, registre o resultado e defina quais erros permitem retry. Falhas de autenticação, validações rejeitadas e indisponibilidade temporária não devem seguir a mesma política.

Também vale separar planejamento, execução e verificação quando isso reduzir risco. O agente pode propor um plano estruturado. Um componente determinístico valida o plano. Só depois uma ferramenta autorizada executa a ação. Em tarefas simples, essa separação pode ser excesso. Em operações financeiras, mudanças em produção e fluxos com dados sensíveis, ela costuma pagar o custo adicional.

A OpenAI recomenda dividir rotinas densas em passos menores, definir ações específicas e capturar casos de borda. Em seus exemplos, uma execução pode terminar quando há uma saída estruturada, quando não existem novas chamadas ou quando o limite de turnos é alcançado, conforme o guia de construção de agentes.

Inclua exemplos do que fazer e do que recusar. Mostre como agir com dado ausente, resposta contraditória, permissão insuficiente, usuário fora do escopo e falha de ferramenta. A instrução “peça ajuda quando não souber” fica mais útil quando define o que conta como dúvida e qual informação precisa acompanhar o encaminhamento.

Por fim, bloqueie chamadas incompatíveis com o estado. Não permita cancelar um pedido já faturado sem uma ferramenta específica. Não permita enviar uma resposta antes de verificar a identidade do cliente. Não permita executar um plano antigo depois que o registro foi alterado. O código precisa ser a última barreira, não o prompt.

Avaliar um agente exige medir o resultado e a trajetória. A saída final pode parecer correta mesmo quando o sistema consultou uma fonte proibida, chamou ferramentas demais ou ignorou uma regra. A Anthropic recomenda combinar avaliadores baseados em código, modelos e humanos. A Microsoft também sugere rubricas para pontuar qualidade, política, intenção e uso de ferramentas, em sua documentação de avaliação de agentes.

Monte um conjunto de casos reais, casos-limite e falhas conhecidas. Inclua pedidos incompletos, dados conflitantes, respostas vazias, usuários mal-intencionados, tentativas de prompt injection e ferramentas indisponíveis. Um conjunto pequeno, mas representativo, é mais útil que centenas de exemplos artificiais sem relação com o trabalho cotidiano.

Crie um baseline antes de trocar modelo, prompt ou ferramenta. Registre taxa de conclusão, correção, aderência à política, latência, custo, chamadas e intervenções humanas. Sem essa fotografia inicial, uma melhora em qualidade pode esconder aumento de custo ou uma queda em segurança.

Avalie a trajetória em cada execução. Verifique ferramentas escolhidas, parâmetros enviados, ordem das chamadas, número de turnos, uso de memória e motivo do encerramento. Uma resposta correta obtida por uma consulta indevida deve falhar. Um agente que resolve a tarefa depois de 30 chamadas talvez também esteja falhando operacionalmente.

Use testes determinísticos quando houver uma condição objetiva. Código pode conferir schema, status, permissões, presença de campos, limites e efeitos no banco. Avaliadores baseados em modelo ajudam em critérios abertos, como clareza e adequação. Revisores humanos calibram a rubrica e encontram falhas que os dois métodos não capturam.

A Anthropic diferencia avaliações de capacidade e de regressão. As primeiras medem tarefas que o agente ainda precisa aprender. As segundas protegem comportamentos já conquistados e devem manter uma taxa de aprovação muito alta. A empresa também lista verificações de chamadas, análise de transcript, consumo de tokens e resultado final entre os sinais úteis, no guia sobre evals de agentes.

Repita os testes. O mesmo caso deve rodar várias vezes para revelar variação, principalmente quando a tarefa permite múltiplos caminhos. Compare versões do modelo, prompt, ferramentas, memória e orquestração. Mude uma variável por vez quando possível. Caso contrário, você não saberá o que produziu a melhora ou introduziu a regressão.

A avaliação precisa incluir critérios de não ação. O agente sabe recusar? Pede confirmação antes de uma ação de alto risco? Para diante de dados insuficientes? Um sistema confiável não é aquele que sempre executa. É aquele que sabe quando não tem base para continuar.

Monitorar agentes em produção significa registrar a execução completa e comparar o comportamento observado com uma linha de base. Prompts, respostas, ferramentas, parâmetros, memória acessada, custo, latência, erros e decisões intermediárias precisam ser correlacionados por execução. A Databricks coloca tracing, datasets, avaliação e feedback humano em um ciclo contínuo de melhoria, no ciclo de desenvolvimento de agentes.

Um log de “requisição concluída” não explica por que o agente falhou. Trace cada etapa: entrada normalizada, contexto recuperado, versão do prompt, modelo usado, chamada de ferramenta, retorno, validação e saída. Proteja dados pessoais com mascaramento e controles de acesso, mas preserve informação suficiente para reproduzir o caminho.

Acompanhe métricas técnicas e comportamentais. Latência e disponibilidade continuam necessárias, mas não bastam. Observe custo por tarefa, tokens, número de turnos, chamadas por ferramenta, taxa de erro, loops, abandono, intervenção humana, recusa e conclusão. Mudanças pequenas nesses indicadores podem aparecer antes de um incidente visível.

Defina alertas para desvios. Um agente de atendimento que normalmente faz duas consultas e passa a fazer oito merece investigação. Uma ferramenta de escrita chamada fora do horário esperado também. Baselines podem ser segmentados por versão, tipo de tarefa, cliente, idioma ou nível de risco. Comparar tudo em uma média única esconde anomalias.

A Databricks recomenda instrumentar o agente desde o protótipo, usando traces para observar seleção errada de ferramentas, contexto ausente e alucinações. Esses mesmos traces podem virar dados de avaliação. O ciclo reúne validação inicial, revisão de especialistas, feedback de usuários e juízes automatizados, conforme a documentação da plataforma.

Faça avaliação online com amostragem. Separe execuções para revisão humana, priorizando ações críticas, reclamações, casos de baixa confiança e trajetórias longas. Transforme falhas confirmadas em novos testes. Assim, o incidente deixa de ser apenas um registro e passa a proteger versões futuras.

Mudanças devem avançar gradualmente. Rode uma versão nova em tráfego controlado, compare métricas com a anterior e mantenha rollback pronto. Para ações críticas, use kill switch, filas de aprovação e possibilidade de revogar credenciais. O tempo necessário para interromper o agente precisa ser menor que o tempo necessário para investigar a falha.

Não de forma absoluta quando o sistema usa um modelo generativo e depende de dados ou APIs variáveis. É possível, porém, tornar o comportamento muito mais previsível: reduzir o espaço de decisão, controlar ferramentas, validar estados, repetir avaliações e exigir aprovação em ações de alto risco. A Anthropic recomenda escolher workflows para tarefas bem definidas e agentes quando a flexibilidade é necessária, em sua comparação arquitetural.

Temperatura baixa e parâmetros de amostragem ajudam, mas não resolvem mudanças no contexto, no modelo, na memória, na recuperação de documentos ou no ambiente externo. O mesmo pedido pode receber dados diferentes amanhã. Por isso, determinismo de geração não equivale a determinismo da aplicação.

Use workflows determinísticos quando a sequência já é conhecida. Um processo de validar cadastro, consultar limite, gerar contrato e enviar para assinatura pode ter etapas fixas, com modelos apenas nos pontos que exigem interpretação. Reserve autonomia para exceções, classificação ambígua, investigação e decisões que realmente dependem de contexto.

O objetivo prático é previsibilidade controlada. Quanto maior o risco, menor deve ser a liberdade operacional. Contratos, políticas, schemas, testes, observabilidade e aprovação humana formam um conjunto. Nenhum deles substitui os demais, e baixar a temperatura não compensa permissões amplas ou ausência de critérios de parada.

Ambiguidade, contexto mutável, respostas probabilísticas, APIs instáveis, permissões amplas, memória inconsistente e ausência de critérios de parada tornam agentes imprevisíveis. A Anthropic diferencia workflows com caminhos predefinidos de agentes que escolhem dinamicamente processos e ferramentas. Essa escolha arquitetural afeta custo, latência, flexibilidade e consistência, como explica a Anthropic.

Combine resultado e trajetória. Meça correção, políticas, uso de ferramentas, custo, latência, chamadas, turnos, falhas e intervenção humana. Use testes baseados em código, rubricas avaliadas por modelos e revisão humana. A Anthropic recomenda separar avaliações de capacidade e regressão, no guia de avaliação de agentes.

Guardrails são controles que limitam entradas, saídas, ferramentas e ações do agente. Podem incluir regras, filtros de dados pessoais, validações de schema, limites de custo, permissões, detecção de injeção e aprovação humana. A OpenAI recomenda combinar camadas de proteção com autenticação, autorização e segurança tradicional, em seu guia prático.

Crie um dataset com casos reais, limites, dados incompletos, falhas de ferramenta e tentativas de abuso. Rode cada caso várias vezes, estabeleça um baseline e compare versões de prompt, modelo e orquestração. A Microsoft permite avaliar respostas completas, incluindo chamadas de ferramentas, e recomenda rubricas para critérios específicos, na documentação do Foundry.

Não quando o sistema depende de um modelo generativo e de um ambiente externo variável. Você pode tornar a execução controlada com workflows fixos, ferramentas limitadas, schemas, validações, limites e aprovações. Para tarefas bem definidas, a Anthropic recomenda preferir workflows, que oferecem mais previsibilidade e consistência, na comparação entre workflows e agentes.

Agentes confiáveis não são os que recebem mais liberdade. São os que têm autonomia compatível com o risco da tarefa. Um agente que consulta documentos pode operar com mais independência. Um agente que altera pagamentos, dados pessoais ou produção precisa de contratos mais estreitos, validações e supervisão.

Essa disciplina começa antes do primeiro incidente. Defina o que significa sucesso, quais ações são proibidas, que dados podem ser acessados, como erros serão tratados e quando a execução deve parar. Transforme esses critérios em testes, políticas e métricas. O produto fica mais fácil de evoluir quando o comportamento esperado está explícito.

A confiabilidade de agentes de IA também depende de operação contínua. Prompts mudam, modelos são atualizados, ferramentas ganham campos e os dados de entrada se transformam. Por isso, avaliações repetíveis, traces completos, alertas e rollback precisam fazer parte do ciclo normal de desenvolvimento, não de um plano de emergência.

Quer acompanhar discussões práticas sobre dados, inteligência artificial e engenharia? Inscreva-se na newsletter do Data Hackers para receber os próximos conteúdos. E, se o próximo passo for colocar um agente para rodar, vale aprofundar também em casos de uso de agentes de IA, sempre começando pelo risco que o sistema precisa controlar.