Como evitar alucinação de IA no atendimento: guia prático

Como evitar alucinação de IA no atendimento: guia prático

Medidas práticas de fonte, limites e verificação para reduzir respostas inventadas por um agente de IA no atendimento, com checklist e plano de piloto.

••

Quer aplicar isso na sua empresa?

Agendar conversa com o Juan →

Como evitar alucinação de IA no atendimento: guia prático

Para evitar alucinação de IA no atendimento, faça o agente responder apenas com base em fontes aprovadas e atualizadas, limite o que ele pode afirmar ou executar e verifique a resposta antes de ela chegar ao cliente. Quando a fonte não cobre a pergunta, o comportamento correto é admitir isso e transferir para uma pessoa. Nenhuma configuração zera o erro, então o objetivo realista é reduzir a frequência e tornar cada falha visível e corrigível.

Principais pontos

  • O agente erra menos quando consulta documentos e sistemas aprovados no momento da pergunta, em vez de depender da memória do modelo.
  • Fonte ruim gera resposta ruim: documentos desatualizados, duplicados ou contraditórios precisam ser corrigidos antes de qualquer ajuste de prompt.
  • Escopo escrito, permissão para dizer não sei e regras de transferência para humano valem mais do que instruções genéricas como seja preciso.
  • Verificação antes do envio (checagem contra a fonte e contra o sistema) pega erros que o prompt sozinho não evita.
  • Redução de erro se prova com um conjunto de perguntas de teste e revisão de conversas reais, não com a impressão de quem configurou.

Por que um agente de IA inventa respostas no atendimento?

Um modelo de linguagem produz texto plausível a partir de padrões aprendidos. Por padrão, ele não consulta a política da sua empresa nem o status do pedido do cliente. Quando falta informação, o texto continua soando seguro, e é aí que nasce a resposta inventada.

Na prática de implementação, as causas mais comuns são previsíveis:

  • A fonte não existe: a pergunta é legítima, mas ninguém documentou a resposta.
  • A fonte está velha ou contraditória: dois documentos dizem coisas diferentes sobre o mesmo prazo ou regra.
  • A instrução empurra para ajudar a qualquer custo, sem dar ao agente uma saída honesta.
  • O dado é dinâmico (pedido, agenda, estoque) e foi tratado como texto fixo.
  • A ferramenta devolve um resultado ambíguo ou vazio e o agente preenche a lacuna por conta própria.

Repare que quase todas as causas são problemas de processo e de dados, não de modelo. Por isso a solução começa fora do prompt.

Que fontes o agente deve consultar para responder?

A abordagem mais usada é a geração aumentada por recuperação, conhecida como RAG: o sistema busca trechos relevantes em uma base de conhecimento confiável e entrega esses trechos ao modelo junto com a pergunta. A documentação da AWS e a arquitetura de referência do Google Cloud descrevem esse padrão. Isso é documentação oficial. Como cada empresa organiza sua base é experiência de implementação, e funciona melhor com disciplina editorial.

Antes de ligar o agente, prepare a base:

  • Defina um responsável por documento e uma data de revisão visível.
  • Mantenha uma única versão de cada regra. Se há duas, o agente vai escolher uma delas sem avisar.
  • Separe o que é política (trocas, cancelamento, garantia) do que é conversa comercial.
  • Escreva as exceções junto da regra, não em um arquivo à parte que ninguém recupera.
  • Retire da base tudo o que o agente não deve usar: rascunhos, promoções encerradas, procedimentos internos.
  • Para dados que mudam, como andamento de pedido ou horário disponível, consulte o sistema por uma ferramenta em vez de copiar o dado para um documento.

Se a empresa ainda não sabe quais perguntas aparecem com mais frequência, comece pelo histórico de atendimento. O texto sobre SAC com inteligência artificial: o que automatizar e o que manter ajuda a separar o que cabe ao agente do que deve continuar com pessoas.

Como limitar o que o agente pode responder e fazer?

Limitar é reduzir a superfície de erro. Um agente que pode falar de qualquer assunto vai errar em assuntos que ninguém revisou. Um agente com escopo claro erra menos e, quando erra, o erro é mais fácil de achar.

O escopo deve estar escrito e ser verificável:

  • Temas permitidos: lista curta, ligada às fontes aprovadas.
  • Temas proibidos: aconselhamento jurídico, exceções de reembolso, diagnósticos, qualquer promessa não prevista em política.
  • Resposta de recusa: um texto neutro que explica que o assunto será encaminhado a uma pessoa.
  • Regra explícita de que não saber é uma resposta aceitável, e de que é melhor transferir do que completar com suposição.
  • Ferramentas somente de leitura no início. Ações que alteram dados (cancelar, remarcar, reembolsar) entram depois, com confirmação.

Para a redação das instruções, vale ver como escrever prompt para atendimento ao cliente com IA. Um ponto de atenção: instrução em linguagem natural orienta o modelo, mas não garante obediência. Por isso ela precisa vir acompanhada de verificação.

Como verificar a resposta antes de enviar ao cliente?

A verificação é a camada que separa um agente de demonstração de um agente em operação. Ela pode ser simples e deve ser proporcional ao risco do assunto.

  • Checagem de ancoragem: uma segunda passagem confere se cada afirmação da resposta está sustentada pelos trechos recuperados. Se não está, a resposta é bloqueada ou reescrita.
  • Checagem contra o sistema: números de pedido, datas, nomes de produto e status são comparados com o que a ferramenta devolveu, e não com o que o modelo redigiu.
  • Regras determinísticas: um filtro simples bloqueia termos de promessa, como garantia de prazo ou de resultado, quando não existe política que os autorize.
  • Limiar de segurança: se a busca não encontra trecho relevante, o agente não improvisa; ele transfere.
  • Registro: cada resposta guarda a pergunta, as fontes usadas e a decisão tomada, para auditoria posterior.

O artigo sobre guardrails para agentes de IA, com validação de entrada, saída e ação detalha como organizar essas camadas. A lista OWASP de riscos para aplicações com modelos de linguagem também trata respostas incorretas e confiança excessiva no modelo como riscos a serem gerenciados, o que reforça a ideia de que a checagem não deve ficar só no prompt.

Plano passo a passo para reduzir respostas erradas

Este é um roteiro enxuto para um primeiro fluxo, por exemplo dúvidas de prazo e troca no WhatsApp.

  • Passo um: levante as perguntas reais mais frequentes e anote como a equipe responde hoje. Esse é o ponto de partida para comparar.
  • Passo dois: para cada pergunta, localize a fonte oficial. Onde não há fonte, escreva uma ou retire a pergunta do escopo.
  • Passo três: resolva contradições entre documentos e registre dono e data de revisão.
  • Passo quatro: defina o escopo, os temas proibidos e a resposta de recusa.
  • Passo cinco: conecte as fontes por recuperação e os dados dinâmicos por ferramentas de leitura.
  • Passo seis: adicione as verificações (ancoragem, comparação com o sistema, regras de bloqueio).
  • Passo sete: defina quando o agente transfere e o que passa para a pessoa: resumo da conversa, pergunta original e fontes consultadas.
  • Passo oito: monte um conjunto de perguntas de teste, incluindo perguntas armadilha fora do escopo e perguntas com regra ambígua.
  • Passo nove: rode um piloto restrito, com registro completo e revisão frequente das conversas.
  • Passo dez: com base nos registros, decida se amplia, ajusta ou interrompe.

Cenário ilustrativo: troca de produto aberto

Cenário ilustrativo: uma loja virtual recebe no WhatsApp a pergunta de um cliente que quer trocar um produto cuja embalagem já foi aberta. A política da loja permite a troca em geral, mas tem uma exceção para determinada categoria de produto.

Sem controles, o agente responde com base no que parece razoável e confirma a troca, porque a instrução pede simpatia e ninguém disse que ele pode recusar. O cliente se compromete com algo que a loja não vai cumprir.

Com os controles descritos acima, o fluxo muda. O agente recupera o trecho da política e o trecho da exceção. Consulta o pedido por uma ferramenta de leitura e confirma a categoria do produto. A verificação de ancoragem confere se a resposta cita a condição correta. Se o produto cai na exceção, o agente explica a regra e oferece o encaminhamento para uma pessoa avaliar o caso. Se a busca não trouxer a política, ele não responde por conta própria e transfere com o resumo da conversa. O erro não desapareceu como possibilidade, mas ficou improvável e rastreável.

Como medir se as respostas erradas realmente diminuíram?

Sem medição, qualquer melhoria é impressão. Há três práticas que funcionam juntas.

A primeira é o conjunto de testes. Ele reúne perguntas conhecidas, com a resposta esperada ou o comportamento esperado (responder, recusar ou transferir). Toda mudança em fonte, prompt ou modelo é testada contra ele antes de ir ao ar. O guia da Anthropic sobre avaliações de agentes e o guia de avaliações da OpenAI descrevem essa lógica de testes repetíveis.

A segunda é a revisão de conversas reais por amostragem. Alguém da operação lê as conversas, marca o que estava errado e identifica a causa: fonte ausente, fonte conflitante, escopo mal definido ou falha de verificação. Essa classificação direciona o conserto.

A terceira é a avaliação assistida por outro modelo, útil para ampliar a cobertura, desde que calibrada contra revisão humana. O texto sobre LLM como juiz para avaliar respostas de agentes explica como usar esse método sem confiar nele cegamente.

Defina com a empresa o que conta como resposta errada e qual nível é aceitável para cada tipo de assunto. Um erro sobre horário de funcionamento e um erro sobre condição contratual não pesam igual.

Como o método mapear, limitar, pilotar e transferir se aplica

No trabalho de Juan Carlo, a redução de respostas erradas segue a mesma sequência de qualquer projeto de agente. Mapear significa entender o processo atual, as perguntas reais e a linha de base de qualidade antes de automatizar. Limitar significa restringir dados, fontes e ações, com ferramentas de leitura no início. Pilotar significa rodar um fluxo real com registros e uma métrica de sucesso combinada previamente. Transferir significa definir quando a conversa passa para uma pessoa e entregar a operação documentada, para que a empresa decida se amplia, ajusta ou para.

Se o atendimento envolve dados pessoais, vale tratar o tema com cuidado desde o desenho: a LGPD exige atenção à finalidade e à minimização, e a ANPD é a referência oficial para orientações no Brasil.

Perguntas frequentes

É possível eliminar totalmente a alucinação de um agente de IA? Não há garantia de eliminação. O que se consegue é reduzir a frequência com fontes aprovadas, escopo limitado e verificação, e tratar o erro restante com transferência para humano e revisão contínua. Quem promete erro zero está prometendo mais do que a tecnologia sustenta.

Basta escrever um bom prompt para o agente não inventar? Não basta. O prompt orienta o comportamento, mas o modelo pode ignorá-lo em casos de borda. A combinação de fonte confiável, ferramentas para dados dinâmicos, verificação da saída e regras de transferência é o que dá robustez.

RAG resolve o problema de respostas erradas? Ajuda bastante, porque dá ao agente material confiável para consultar, mas não resolve sozinho. Se a base está desatualizada, contraditória ou incompleta, o agente recupera e repete o erro. A qualidade da base e a checagem da resposta continuam necessárias.

Por onde começar se a empresa ainda não tem documentação organizada? Comece por poucas perguntas frequentes e de baixo risco, escreva as respostas oficiais com dono e data de revisão e use isso como base do piloto. Deixe fora do escopo o que ainda não tem fonte e encaminhe esses casos para a equipe. A base cresce conforme o piloto mostra quais lacunas mais aparecem.

Fontes

alucinação de IAatendimento ao clienteagentes de IARAGguardrails