Análise de falhas de agentes de IA: alucinação ou política?

Análise de falhas de agentes de IA significa classificar cada conversa com IA que falhou pela sua causa antes que alguém a corrija. A maioria das falhas chamadas de “alucinação” é outra coisa: um artigo que falta, uma política desatualizada ou ambígua, uma falha de recuperação, uma ferramenta quebrada ou um transbordo ruim. Cada causa tem um responsável e uma correção diferentes, então o rótulo decide se a correção funciona.

Em resumo

• “Alucinação” descreve um sintoma (uma resposta errada dita com confiança), não uma causa. Trate-a como a última explicação, não a primeira.
• Dez causas cobrem quase todas as conversas com IA que falham no suporte, de lacunas de conhecimento a confusões do lado do cliente.
• Uma pergunta resolve a maioria dos casos: havia uma fonte aprovada que respondia a isso, e o agente a usou?
• As causas de conteúdo vão para o dono do conhecimento ou da política, as de ferramentas para a engenharia, e só as falhas de raciocínio para a equipe que ajusta o agente de IA.
• Acompanhe toda semana a composição por causa a cada 1.000 conversas. Só os percentuais enganam, porque uma causa pode crescer em percentual enquanto diminui em quantidade.

Por que as equipes chamam toda falha de agente de IA de alucinação?

As equipes chamam toda falha de alucinação porque a transcrição só mostra a saída: uma resposta errada, dita com confiança. A causa está antes, no conteúdo, na política, na etapa de recuperação, em uma ferramenta ou nas regras de transbordo. Sem uma etapa que classifique a causa, vence a palavra mais conhecida, e a correção cai no prompt.

A palavra tem um significado preciso. O perfil de risco de IA generativa do NIST define confabulação, “coloquialmente também chamada de alucinações”, como sistemas que “geram e apresentam com confiança conteúdo errôneo ou falso” (NIST AI 600-1, seção 2.2, em inglês). Isso cobre o modelo inventando algo. Não cobre um agente que repetiu fielmente um artigo de reembolso desatualizado, nem um que seguiu uma política que ninguém escreveu.

A diferença importa porque o rótulo errado manda o trabalho para a equipe errada. Uma mudança no prompt não corrige um artigo que não existe. Quando a empresa de ferramentas de suporte Pylon classificou cerca de 200 tickets que o seu agente de IA escalonou em uma semana da sua própria fila, as lacunas de conhecimento “representaram mais da metade dos escalonamentos” e os pedidos de funcionalidade foram 15% (Pylon, setembro de 2026, em inglês). São os dados de uma única empresa, não um benchmark, mas nenhuma das duas causas é um problema do modelo.

Este guia faz parte do nosso guia central sobre gestão de políticas para agentes de IA, que mostra como as políticas são escritas, têm dono e recebem versões. Aqui o foco é a etapa anterior à correção: nomear a causa corretamente.

Quais são as dez razões pelas quais as conversas com IA falham?

No suporte, as conversas com IA falham por dez razões principais: uma lacuna de conhecimento, conhecimento desatualizado ou conflitante, uma política ausente ou ambígua, uma falha de recuperação, um erro de raciocínio ou alucinação, uma falha de ação ou de ferramenta, uma falha de transbordo, uma falha de escopo, um bug de produto ou pedido de funcionalidade e um problema do lado do cliente. Cada uma deixa um rastro diferente na transcrição.

A tabela abaixo é a taxonomia para copiar. Use-a como lista de opções no seu formulário de revisão, uma causa por critério reprovado.

Marque o critério reprovado, não a conversa inteira, porque uma conversa pode falhar por duas causas. As causas 6 e 7 muitas vezes se escondem nos números de retenção; o nosso guia sobre falhas silenciosas de agentes de IA mostra como expô-las. Para atendentes humanos, a divisão equivalente está no nosso guia sobre erro do atendente ou erro de processo (em inglês).

Como distinguir uma alucinação de uma política ausente?

Você distingue uma alucinação de uma política ausente verificando a fonte. Se uma fonte aprovada e atual respondia à pergunta e o agente se afastou dela, é uma alucinação ou um erro de raciocínio. Se nenhuma fonte cobria o caso, ou se a regra existe só na cabeça dos atendentes seniores, é uma política ausente, e nenhuma mudança no modelo vai corrigi-la.

Os quatro pares confundidos com mais frequência:

• Alucinação ou política ausente. O teste é: “um atendente novo, lendo só as suas fontes escritas, teria respondido corretamente?” Se não, o agente de IA não tinha nada a que ser fiel.
• Alucinação ou conhecimento desatualizado. Se o fato errado aparece palavra por palavra em um artigo, o agente fez o trabalho dele. A falha é do artigo.
• Alucinação ou falha de recuperação. Se o artigo certo existe, mas a resposta serve a um tema vizinho, o agente respondeu fielmente a partir da página errada. A geração aumentada por recuperação (RAG), o método que muitos agentes de IA de suporte usam, combina um modelo com uma busca no seu conteúdo (Lewis et al., 2020, em inglês), então a etapa de busca pode falhar sozinha.
• Ação alucinada ou falha de ferramenta. “O seu reembolso está a caminho” sem reembolso no sistema é ou o agente afirmando uma ação que nunca executou, ou uma chamada de ferramenta que falhou em silêncio. O log da ferramenta diz qual dos dois. O nosso guia sobre a auditoria da taxa de resolução de agentes de IA mostra como conferir as ações declaradas com os registros do backend.

O nosso guia para pegar alucinações de agentes de IA traz a rotina para as alucinações verdadeiras depois que você as isolou. Esta página é o filtro que decide quais são verdadeiras.

A árvore de triagem: dez perguntas em ordem

A forma mais rápida de classificar uma conversa com IA que falhou é responder a uma lista fixa de perguntas em uma ordem fixa e parar no primeiro “sim” ou “não” que nomeie uma causa. A ordem importa: ela descarta as causas do cliente, do produto e do sistema antes de culpar o conteúdo, e culpa o conteúdo antes de culpar o modelo.

Copie isto para o seu formulário de revisão. Responda para um critério reprovado de cada vez.

1. Uma pessoa teria entendido o que o cliente queria a partir do que ele escreveu? Não: lado do cliente (causa 10). Sim: continue.
2. O pedido era algo que o agente de IA deveria tratar? Não, e ele tratou mesmo assim: falha de escopo (causa 8). Sim: continue.
3. O problema de fundo era um defeito, ou algo que o produto não faz? Sim: bug de produto ou pedido de funcionalidade (causa 9). Não: continue.
4. O agente precisava executar ou verificar uma ação (consulta, reembolso, cancelamento, atualização), e essa chamada falhou, deu timeout ou foi recusada? Sim: falha de ação ou de ferramenta (causa 6). Não: continue.
5. A conversa deveria ter ido para uma pessoa, em outro momento, ou com um contexto melhor? Sim: falha de transbordo (causa 7). Não: continue.
6. Uma fonte aprovada responde a esta pergunta? Não, e a regra está clara para todos: lacuna de conhecimento (causa 1). Não, e a regra depende de a quem você pergunta: política ausente ou ambígua (causa 3). Sim: continue.
7. Essa fonte está atualizada, e é a única fonte sobre o tema? Não: conhecimento desatualizado ou conflitante (causa 2). Sim: continue.
8. O agente usou essa fonte para esta resposta? Não: falha de recuperação (causa 4). Sim: continue.
9. A resposta corresponde à fonte? Não: erro de raciocínio ou alucinação (causa 5). Sim: continue.
10. O próprio critério está certo? Se o agente seguiu fielmente uma fonte atual e aprovada e ainda assim falhou, o critério do formulário de monitoria pode estar errado. Mande-o para o responsável de QA para calibração, em vez de forçar uma causa.

A pergunta 10 é a válvula de segurança: uma taxonomia que não consegue dizer “o nosso critério estava errado” culpa quem sobrar. Conte quantas vezes você chega à pergunta 9. É o único caminho que termina em “alucinação”.

Quem corrige cada causa, e como encaminhar?

Cada causa tem um responsável, definido pelo lugar onde a correção precisa acontecer: o conteúdo vai para o dono do conhecimento ou da política, os sistemas para a engenharia, o produto para a equipe de produto, e só as instruções e o raciocínio para o responsável pela IA. Encaminhe a conversa com a evidência anexada, nunca só uma contagem.

Nomeie cada responsável como uma pessoa, não como uma equipe. Uma nota de encaminhamento precisa de quatro coisas: a causa, duas ou três conversas de exemplo com as linhas que falharam marcadas, a intenção afetada com o volume semanal e a data em que você vai avaliar de novo. Sem os exemplos, a equipe que recebe discute a classificação em vez de corrigir.

Corrigir um agente de IA não é fazer coaching de uma pessoa: a correção precisa mudar o conteúdo ou a configuração que o agente lê. O nosso texto sobre coaching de humanos vs corrigir agentes de IA trata dessa divisão. Para as causas 6 e 8, a correção certa às vezes é um limite, não uma resposta melhor. A OWASP lista “funcionalidade excessiva”, “permissões excessivas” e “autonomia excessiva” como causas de fundo de ações danosas de agentes (OWASP LLM06, em inglês), e é aí que entram os nossos guias sobre guardrails para agentes de IA e níveis de autonomia de agentes de IA.

Como fazer uma triagem semanal das falhas de IA?

Faça a triagem das falhas de IA como uma sessão semanal de 45 a 60 minutos: levante as conversas que falharam, agrupe-as por intenção, classifique os principais grupos com a árvore de decisão, encaminhe cada causa ao seu responsável com exemplos e verifique se as correções da semana passada se mantiveram. Classifique grupos, não conversas isoladas, para que a sessão acompanhe o volume.

Uma rotina que funciona:

1. Segunda-feira: levante as falhas. Pegue todas as conversas com IA que reprovaram em um critério crítico na semana passada (precisão, política, ação, escalonamento). Se você avalia só uma amostra, acrescente todas as conversas com reabertura, reclamação ou novo contato em 7 dias.
2. Agrupe por intenção. Reembolsos, mudanças de endereço, problemas de login. Comece pelas cinco principais intenções por número de falhas.
3. Classifique de três a cinco conversas por grupo. Passe pelas dez perguntas. Se elas concordam, marque o grupo. Se divergem, o grupo são dois problemas: divida-o.
4. Encaminhe. Um ticket por causa por intenção, para um responsável nomeado, com os exemplos e uma data de nova avaliação.
5. Confira a semana passada. Para cada correção entregue, compare o número de falhas da intenção antes e depois. Uma correção que não mexeu no número foi a correção errada ou a causa errada.
6. Registre. Uma linha por grupo: semana, intenção, causa, quantidade, responsável, correção, resultado. Esse registro é a sua composição de falhas ao longo do tempo.

O responsável de QA conduz a sessão com o responsável pela IA, o dono do conhecimento e um líder de operações de suporte. Política, engenharia e produto entram só quando um item deles está na lista. As falhas de transbordo muitas vezes só aparecem entre conversas, e é aí que o QA da jornada do cliente ajuda.

Como medir a composição das falhas de IA ao longo do tempo?

Meça a composição das falhas como falhas a cada 1.000 conversas com IA, por causa, toda semana, ao lado do percentual de cada causa. As quantidades a cada 1.000 mostram se uma causa está diminuindo. Os percentuais mostram onde está o trabalho restante. Leia os dois, porque corrigir uma causa faz as outras parecerem maiores em percentual mesmo quando nada mudou.

A Pylon viu isso nos próprios dados: à medida que as lacunas de conhecimento caíram, os relatos de bugs “subiram de 8,5% dos escalonamentos para 19%” (Pylon, em inglês). Um percentual em alta não significa por si só mais bugs: as outras fatias ficaram menores.

Um exemplo calculado (ilustração, números inventados para mostrar a conta)

Pense em um agente de IA que atende 12.000 conversas por semana. Na semana 1, 480 reprovam em um critério crítico: 40 a cada 1.000. A equipe corrige os principais grupos de conhecimento e de política ao longo de quatro semanas. Na semana 5, o volume é o mesmo e 290 falham: 24,2 a cada 1.000.

Três leituras. As três causas de conteúdo caíram de 260 para 95 falhas, de 54,2% para 32,8% da composição. As alucinações foram de 7,3% para 11,4% das falhas enquanto a quantidade caiu de 35 para 33: uma liderança que lê só percentuais concluiria que o modelo piorou. E as falhas de ferramenta quase não se mexeram (de 40 para 38), o que mostra que a engenharia ainda não entregou a correção.

As métricas para manter no dashboard:

• Falhas a cada 1.000 conversas com IA, no total e por causa.
• Percentual por causa, para decidir para onde vai o esforço da próxima semana.
• Recorrência: falhas em uma intenção e causa marcadas como corrigidas. Acima de zero depois de duas semanas significa que a correção não se manteve.
• Tempo até a correção por responsável, do ticket encaminhado à nova avaliação.
• Taxa de não classificadas: falhas que ninguém conseguiu enquadrar. Se ela passa de uma parcela pequena, a taxonomia ou os critérios precisam de ajuste.

Quando esta taxonomia não é para você?

Uma taxonomia de dez causas não é para você, ou ainda não é, quando o seu agente de IA responde a algumas centenas de perguntas por mês a partir de uma central de ajuda pequena e não executa ações. Nesse caso, três grupos bastam: conteúdo (causas 1 a 3), agente de IA (4, 5, 8, 10) e todo o resto. Passe para a lista completa quando responsáveis de fora do suporte começarem a receber o trabalho.

Sinais de que três grupos já não bastam: o agente executa ações em outros sistemas, você tem mais de um agente de IA ou plataforma respondendo a clientes, as políticas mudam mais de uma vez por trimestre, ou duas equipes discordam toda semana sobre de quem é o problema. Se a mesma intenção continua falhando depois das correções, faça uma análise de causa raiz mais profunda nesse grupo em vez de criar mais categorias.

Onde a Kaizo entra

A Kaizo é QA e supervisão de governança para equipes de suporte em que pessoas e agentes de IA dividem o trabalho. Ela cobre o lado da evidência na análise de falhas: avaliar as conversas, revelar as causas raiz e avaliar de novo depois de uma correção. Ela não escreve os seus artigos nem as suas políticas.

O AutoPilot avalia cada conversa resolvida com base no seu próprio formulário de monitoria e, no lado do QA de agentes de IA, você acrescenta os critérios em que um agente de IA falha e conecta a sua base de conhecimento para que ele avalie com base no seu conteúdo. Cada nota leva à evidência na transcrição. O Insights transforma essas notas em causas raiz (o processo quebrado, o atrito no produto, a lacuna de habilidade), o que dá à triagem semanal os seus grupos iniciais e os exemplos.

Veja isso nas suas próprias conversas. Agende uma demo e traga uma intenção que a sua equipe chama de problema de alucinação.

Como começar esta semana

Comece pelas piores conversas com IA da semana passada, não por uma ferramenta nova. Acrescente as dez causas ao seu formulário de revisão, classifique um pequeno lote com a árvore de decisão, nomeie um responsável por causa e corrija primeiro o maior grupo de conteúdo.

1. Cole a tabela das dez causas no seu formulário de revisão como lista de opções obrigatória em cada critério reprovado.
2. Pegue as 30 piores conversas com IA da semana passada e passe as dez perguntas em cada uma. Conte quantas chegam à pergunta 9.
3. Nomeie um responsável por causa, como pessoas, e combine o formato da nota de encaminhamento.
4. Reserve um horário recorrente de 45 minutos para a triagem e comece o registro com os grupos desta semana.
5. Escolha o maior grupo de conteúdo e corrija-o primeiro. Avalie a intenção de novo na semana que vem. O lado completo das políticas no ciclo está no nosso guia de gestão de políticas para agentes de IA.

Perguntas frequentes

Toda resposta errada de um agente de IA é uma alucinação?

Não. Uma alucinação é um conteúdo que o modelo gera sem apoio nas suas fontes ou na conversa. Uma resposta errada copiada de um artigo desatualizado, ou um chute em um caso que nenhuma política cobre, é uma falha de conteúdo. O teste é se existia uma fonte correta e aprovada e o agente se afastou dela.

Basear um agente de IA no seu próprio conteúdo acaba com as alucinações?

Basear o agente no seu conteúdo reduz as respostas inventadas, mas não as elimina, e acrescenta novos pontos de falha. O agente pode recuperar o artigo errado, citar um desatualizado ou ainda assim se afastar do certo. É por isso que a recuperação e o conhecimento desatualizado têm causas próprias na taxonomia, separadas da alucinação.

Quem deve ser dono da análise de falhas de agentes de IA?

O responsável de QA costuma ser dono da classificação e da triagem semanal, porque o formulário de monitoria e as evidências das revisões ficam com o QA. As correções pertencem aos responsáveis de cada causa: conhecimento, política, configuração da IA, engenharia, operações de suporte e produto. Uma única pessoa dona da classificação mantém as marcações consistentes de uma semana para a outra.

Quantas conversas com IA que falharam você deve classificar por semana?

Classifique grupos, não todas as conversas. De três a cinco conversas por grupo, nas cinco principais intenções por número de falhas, dão de 15 a 25 leituras por semana e costumam cobrir a maior parte das falhas. Leia mais conversas de um grupo quando elas divergem sobre a causa.

Pedidos de funcionalidade devem contar como falhas do agente de IA?

Conte-os, mas reporte-os separados das falhas do próprio agente. Um pedido de funcionalidade falha com o cliente, não com o agente, e nenhuma mudança de conteúdo ou de prompt o resolve. Contá-los mostra ao produto com que frequência os clientes pedem e evita que inflem a taxa de erro do agente de IA.