Modos de falha de agentes de IA: uma taxonomia para operação

Um agente de IA de negócio costuma falhar de poucas maneiras reconhecíveis: a memória está desatualizada, ele recupera o contexto errado, escolhe a ferramenta errada, repete uma ação que já executou ou continua trabalhando quando deveria parar. Dar nome a esses modos de falha antes de um incidente permite que a equipe de operações identifique qual camada quebrou e quem deve corrigi-la. Este guia lista os tipos mais comuns, explica como cada um aparece do lado de fora e apresenta um método para diagnosticá-los.

Principais pontos

• A maioria das falhas de agentes se concentra em cinco camadas: memória, contexto, ações, processo e transferência para pessoas.
• Identifique o tipo da falha antes de mexer no prompt, no modelo ou nas ferramentas.
• Memória desatualizada e escolha errada de ferramenta podem produzir a mesma resposta visível, mas exigem correções diferentes.
• Toda ação que altera um registro ou envia uma mensagem precisa de uma regra explícita para duplicidades e permissões.
• Cada tipo de falha precisa de um responsável, uma verificação e uma frequência de revisão, ou será redescoberto a cada trimestre.

Por que nomear as falhas antes de corrigi-las

Quando um agente dá uma resposta errada, a reação habitual é reescrever as instruções. Às vezes isso ajuda, mas esconde a causa. Uma nota de serviço desatualizada na memória, uma busca que não encontrou a página certa da política e uma chamada de ferramenta com o identificador do cliente errado podem gerar o mesmo sintoma visível: uma resposta confiante e incorreta. Cada um exige um responsável diferente e um teste diferente.

Um vocabulário comum transforma uma queixa vaga, como “o agente não é confiável”, em um diagnóstico em que um gestor consegue agir. Ele também torna as notas de incidentes comparáveis ao longo do tempo. Se três dos últimos cinco problemas foram causados por memória desatualizada, a solução provavelmente é um processo de revisão da memória, e não um modelo melhor.

A taxonomia abaixo está organizada pelo ponto em que a falha começa. Não é um ranking, e as categorias se sobrepõem na prática. Um agente pode interpretar mal um documento, salvar essa interpretação como memória e depois agir com base nela. Investigue primeiro a camada quebrada mais antiga, porque os sintomas que aparecem depois costumam esconder essa origem.

Falhas de memória: desatualizada, contraditória e ausente

• Memória desatualizada: um fato era verdadeiro quando foi armazenado e já não é, como uma área de entrega, o nome de um fornecedor ou a versão de uma regra de preço.
• Memória contraditória: duas notas salvas divergem, e o agente escolhe uma delas sem indicar que existe conflito.
• Memória ausente: um fato que a equipe conhece nunca foi registrado, então o agente pergunta de novo, chuta ou deixa a resposta em branco.

Falhas de memória são difíceis de notar porque a resposta soa correta. Verifique de onde veio cada fato, quando foi escrito e quem aprovou. Correções feitas pela equipe devem passar por uma etapa de revisão antes de virar memória permanente, pois uma única correção não revisada pode, em silêncio, substituir uma regra correta. O método prático está descrito em Como transformar correções da equipe em memória revisada para agentes de IA.

Falhas de contexto e de entrada

• Falha de recuperação: o documento certo existe, mas a busca devolveu outro trecho ou nenhum.
• Leitura errada da entrada: o agente interpretou incorretamente uma tabela digitalizada, uma nota de rodapé, um formato de data ou um campo de valor.
• Instrução injetada: um texto dentro de um e-mail, de uma página web ou de um documento compartilhado tenta mudar o que o agente faz.

Falhas de recuperação são a falha de contexto mais comum e também a mais fácil de testar. Registre os trechos que o agente de fato recebeu, e não apenas a resposta final. Se o trecho certo nunca esteve na janela de contexto, nenhuma mudança no prompt vai corrigir a resposta. Leituras erradas de entrada exigem outra verificação: compare a extração do agente com uma amostra dos mesmos documentos conferida por uma pessoa.

Instruções injetadas merecem uma categoria própria, porque quem as introduz não precisa ter acesso ao agente. Uma orientação de segurança para LLMs, como as da OWASP, trata conteúdo não confiável como dado, e não como comando. Essa separação deve ser desenhada no fluxo de trabalho: instruções do responsável em um canal, conteúdo de terceiros em outro, e nunca deixe um documento decidir quais ferramentas estão liberadas.

Cenário ilustrativo: uma pequena equipe de administração de imóveis usa um agente para redigir respostas a pedidos de manutenção. A mensagem de um inquilino traz uma linha pedindo ao agente que ignore a etapa de aprovação e marque o pedido como encerrado. O rascunho muda de tom, mas a ação de encerrar é bloqueada, porque as permissões do agente não incluem encerrar pedidos sem confirmação de um membro da equipe. O incidente é registrado como instrução injetada, e a equipe avalia se o filtro de mensagens precisa de uma regra nova.

Falhas de ação: ferramenta errada, argumentos errados, duplicidades e excesso de permissão

• Escolha errada de ferramenta: o agente consulta a base de conhecimento quando a pergunta exige o sistema de reservas, ou chama uma ferramenta de escrita para responder a uma pergunta apenas de leitura.
• Argumentos errados: a ferramenta é a certa, mas o cliente, o valor, a data ou o identificador do registro estão errados.
• Efeito duplicado: um tempo limite provocou uma nova tentativa, e a ação original já tinha dado certo, então a mudança foi executada duas vezes.
• Excesso de permissão: o agente podia executar uma ação que a tarefa nunca exigiu.

A escolha errada de ferramenta costuma vir de descrições pouco claras. Quando duas ferramentas se sobrepõem, o modelo precisa adivinhar, e a adivinhação só é tão boa quanto a descrição. Escreva cada descrição de ferramenta como uma regra: o que ela faz, quando usar e quando não usar. As recomendações da Anthropic sobre como escrever ferramentas para agentes chegam ao mesmo ponto pelo lado da engenharia.

Efeitos duplicados são um problema de desenho, não do modelo. Toda ação que cria um pagamento, envia uma mensagem ou altera um registro precisa de uma chave estável, para que uma nova tentativa não gere um segundo efeito. A abordagem está descrita em ações idempotentes em agentes de IA. Já o excesso de permissão se resolve no início, dando ao agente o menor acesso que o papel exige. Testar as chamadas de ferramentas em um ambiente controlado também ajuda a pegar esse tipo de erro antes de chegar à produção.

Falhas de processo: loops, trabalho parcial silencioso e deriva

• Loop: o agente repete a mesma busca ou mensagem sem avançar, e nenhuma condição de parada encerra a execução.
• Conclusão parcial silenciosa: o agente informa que a tarefa está pronta quando uma de várias etapas falhou ou foi pulada.
• Deriva: a qualidade cai devagar depois de uma atualização do modelo, de uma mudança nos documentos ou de uma mudança na forma como os clientes escrevem seus pedidos.

A conclusão parcial silenciosa é a falha que mais prejudica a confiança, porque o resumo está errado e o log parece limpo. Exija que o agente reporte o resultado de cada etapa separadamente, e só feche a tarefa quando todas as etapas obrigatórias tiverem sucesso. Loops são mais fáceis de conter com condições de parada explícitas, como um número máximo de chamadas de ferramenta e uma regra que envia o caso a uma pessoa depois de falhas repetidas.

A deriva é lenta e, por isso, fácil de deixar passar. Uma amostra mensal das respostas, avaliada com os mesmos critérios, vai mostrar a queda muito antes de os clientes reclamarem. Os sinais estão descritos em sinais de deriva e queda de qualidade. Registros estruturados de cada etapa, seguindo práticas comuns de observabilidade, tornam essas falhas visíveis sem que alguém precise ler cada conversa.

Um método de cinco passos para diagnosticar uma falha

Quando uma falha é reportada, o primeiro objetivo é classificá-la, não corrigi-la. Um método simples funciona para a maioria das equipes:

• Passo 1: reproduza o caso com a entrada exata, a data e o estado do registro, e salve-o como caso de teste.
• Passo 2: leia o rastro na ordem: memória usada, trechos recuperados, ferramentas chamadas, argumentos enviados, resultados devolvidos.
• Passo 3: encontre o primeiro passo que estava errado e enquadre-o em uma das categorias acima.
• Passo 4: escolha a correção mais restrita para essa camada, como corrigir uma entrada de memória, reescrever uma descrição de ferramenta ou acrescentar uma condição de parada.
• Passo 5: rode de novo o caso salvo e um pequeno conjunto de casos relacionados, depois registre o tipo da falha e a correção no registro de mudanças.

O último passo é o que mais importa a longo prazo. Uma equipe que registra os tipos de falha durante um trimestre consegue ver qual categoria continua voltando, e esse padrão aponta a camada que precisa ser redesenhada. Manter o registro legível para quem não é de tecnologia também ajuda, por isso vale ler o registro de mudanças que o dono consegue entender.

Como a Be Human lida com essas falhas na operação gerenciada

A Be Human desenha cada agente com um papel definido, suas fontes de memória, suas permissões de ferramenta e seus limites de aprovação antes de ele entrar em operação. Na operação gerenciada, a mesma taxonomia é usada para classificar cada incidente, de modo que o monitoramento, as revisões de permissão e as avaliações recorrentes sejam relatados por tipo de falha, e não por uma impressão geral de qualidade. Mudanças em memória, ferramentas ou instruções são registradas com responsável e motivo, e os incidentes seguem um caminho de resposta escrito, com opção de reversão. O trabalho contínuo inclui manutenção das integrações e melhorias controladas, para que os tipos de falha que se repetem sejam tratados na origem.

Se você quer descobrir qual é a primeira tarefa que vale a pena entregar a um agente, faça o diagnóstico gratuito de IA da Be Human.

Perguntas frequentes

Qual é a causa mais comum de falha em um agente de IA? Não existe uma causa única, e as falhas mais comuns variam conforme o fluxo de trabalho. Memória desatualizada e falhas de recuperação costumam aparecer primeiro em agentes de negócio, porque a informação muda e a busca não é perfeita. Os logs de rastro são a única forma confiável de saber qual camada quebrou em um caso específico.

Como diferenciar uma falha de memória de uma falha de ferramenta? Observe o que o agente sabia e o que ele fez. Se a ferramenta recebeu os argumentos corretos e devolveu o resultado correto, mas o agente usou um fato antigo para decidir o que perguntar, o problema é de memória. Se os fatos estavam corretos, mas a chamada usou o identificador errado ou a ferramenta errada, o problema está na camada de ação.

Devo corrigir toda falha reescrevendo o prompt? Não. Uma mudança no prompt pode esconder um problema de memória ou de permissão por algumas semanas e depois falhar de novo de outra forma. Use o prompt para instruções que pertencem ao papel do agente, e corrija a camada subjacente quando o tipo da falha apontar para memória, recuperação, ferramentas ou permissões.

Uma empresa pequena consegue gerenciar esses tipos de falha sem uma equipe de TI? Sim, desde que o responsável consiga ler um registro simples e aprovar mudanças em memória, ferramentas e permissões. O trabalho é, sobretudo, revisão e classificação, e as mudanças técnicas podem ser feitas por um parceiro de operação gerenciada. Comece com um fluxo de trabalho, um responsável e uma lista curta de tipos de falha, e amplie depois que o hábito de revisão estiver estabelecido.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.