A alucinação em IA no atendimento deixou de ser apenas um problema técnico relacionado à qualidade das respostas. À medida que empresas aceleram a adoção de agentes de inteligência artificial para substituir ou reduzir o trabalho de equipes de suporte, uma resposta inventada pode se transformar em prejuízo financeiro, conflito com o cliente e até responsabilidade jurídica.
O problema aparece quando uma LLM (Large Language Model) recebe autonomia para conversar com consumidores e executar tarefas sem ter acesso confiável às políticas internas da empresa. Em vez de consultar uma fonte oficial, o modelo pode produzir uma resposta plausível, mas incorreta, como prometer um desconto inexistente, criar uma condição de reembolso ou interpretar de forma errada uma regra comercial.
Um caso emblemático ocorreu com a Air Canada. Um chatbot informou a um passageiro que ele poderia solicitar posteriormente uma tarifa especial para viagem relacionada a luto. A informação estava errada e o tribunal canadense determinou que a companhia deveria responder pelas informações fornecidas pelo chatbot. O episódio mostra que colocar uma IA diante do cliente não transfere automaticamente para o software a responsabilidade pelas suas respostas.
Por que a alucinação em IA no atendimento é tão perigosa?
Modelos de linguagem não funcionam como bancos de dados tradicionais. Uma LLM não consulta necessariamente uma tabela contendo a resposta correta antes de responder. Seu mecanismo central é gerar texto com base em padrões aprendidos durante o treinamento e no contexto fornecido à aplicação.
Isso permite produzir respostas extremamente naturais, mas também cria um problema importante: uma resposta convincente não significa que ela seja verdadeira.
Em um chatbot genérico, a diferença pode parecer pequena. Em um sistema de atendimento, entretanto, ela pode ser crítica. Um cliente não está perguntando apenas para conversar. Ele pode estar tentando cancelar um contrato, solicitar um reembolso, alterar uma assinatura ou descobrir se tem direito a determinado benefício.
Se o agente estiver autorizado a tomar decisões ou acionar sistemas corporativos, o risco aumenta ainda mais.
Promessas indevidas e custos jurídicos
O caso da Air Canada demonstra de maneira concreta como uma resposta incorreta pode sair do ambiente puramente tecnológico e chegar ao campo jurídico.
O passageiro Jake Moffatt consultou o chatbot da companhia sobre tarifas para situações de luto. O sistema informou que seria possível comprar a passagem normalmente e solicitar posteriormente a diferença da tarifa dentro de determinado prazo. Essa orientação não correspondia à política real da empresa.
Moffatt seguiu a orientação recebida e depois solicitou o benefício. A empresa recusou o pedido, argumentando, entre outros pontos, que o cliente poderia ter consultado a política correta.
O tribunal canadense não aceitou a tentativa de tratar o chatbot como uma entidade separada da companhia. A decisão determinou o pagamento de valores relacionados à diferença da tarifa e aos custos do processo.
O caso não significa que toda resposta errada de uma IA automaticamente gere responsabilidade jurídica em qualquer país. Ele demonstra, porém, um princípio importante para empresas: automatizar o atendimento não elimina a responsabilidade sobre as informações apresentadas ao consumidor.
Por isso, sistemas capazes de oferecer descontos, cancelar serviços, aprovar créditos ou iniciar reembolsos precisam ter controles muito mais rígidos do que um simples chatbot informativo.
A ilusão do modelo sem contexto
Outro problema é esperar que um modelo treinado com grandes volumes de informação tenha conhecimento preciso sobre as regras específicas de uma empresa.
Uma LLM pode saber explicar o que é uma garantia, mas isso não significa que conheça a política de garantia de uma determinada loja. Pode saber como funcionam planos de assinatura, mas não necessariamente conhecer os preços, exceções e condições vigentes naquele momento.
Esse é um dos motivos pelos quais conhecimento geral e conhecimento corporativo são coisas diferentes.
Documentos internos também mudam. Contratos são atualizados, preços são alterados, produtos são descontinuados e políticas recebem novas exceções. Mesmo um modelo que tenha produzido uma resposta correta ontem pode não ter acesso à informação mais recente hoje.
A arquitetura precisa, portanto, separar a capacidade de gerar linguagem da fonte que determina qual informação deve ser apresentada.
Como conter a alucinação em IA no atendimento
Uma estratégia importante é utilizar Retrieval-Augmented Generation (RAG), arquitetura que combina um modelo de linguagem com um mecanismo de recuperação de informações.
A ideia foi formalizada em trabalhos de pesquisa sobre modelos que combinam memória paramétrica com uma fonte externa de conhecimento. A abordagem permite recuperar informações relevantes antes da geração da resposta, reduzindo a dependência exclusiva do conhecimento armazenado nos parâmetros do modelo.
Em um sistema de suporte baseado em RAG, o fluxo pode funcionar assim:
- O cliente faz uma pergunta.
- O sistema transforma a pergunta em uma consulta.
- Um mecanismo de busca procura informações relevantes na base corporativa.
- Os documentos recuperados são enviados como contexto para a LLM.
- O modelo formula a resposta utilizando aquele contexto.
- O sistema pode registrar as fontes utilizadas e encaminhar situações de risco para um atendente.
Imagine um cliente perguntando: “Posso cancelar meu plano depois de 30 dias e receber reembolso?”
Em vez de deixar o modelo responder com base em padrões gerais, o sistema consulta a política oficial de cancelamento, recupera a versão aplicável e utiliza esse conteúdo para construir a resposta.
Isso não torna o sistema automaticamente infalível. Um RAG pode recuperar documentos errados, desatualizados ou insuficientes. A própria segurança de aplicações baseadas em RAG precisa considerar problemas relacionados a vetores, embeddings e qualidade das fontes. A OWASP inclui essas questões entre os riscos de aplicações modernas de LLM.
Por isso, RAG deve ser tratado como parte de uma arquitetura de controle, não como uma solução mágica contra alucinações.
O papel das soluções locais e de código aberto
O ecossistema open source também pode desempenhar um papel importante na construção de sistemas de atendimento mais controláveis.
Modelos abertos podem ser executados em infraestrutura própria ou em ambientes sob maior controle da organização. Ferramentas como Ollama, vLLM e diferentes frameworks de RAG permitem montar arquiteturas nas quais documentos, embeddings, modelos e mecanismos de recuperação podem permanecer dentro da infraestrutura da empresa, dependendo da configuração adotada.
Essa abordagem pode trazer vantagens relacionadas à soberania dos dados, governança e previsibilidade de custos. Também permite que equipes técnicas definam com maior precisão quais sistemas podem ser acessados pelo agente e quais informações podem sair da infraestrutura.
Entretanto, open source não significa automaticamente seguro.
Um modelo local continua podendo gerar informações incorretas. Uma base vetorial pode conter dados inadequados. Um agente pode receber permissões excessivas. E uma integração mal configurada pode transformar uma falha de linguagem em uma ação concreta dentro do ambiente corporativo.
A arquitetura de segurança continua sendo determinante.
Guardrails e o princípio do menor privilégio
Um agente de atendimento não deveria ter acesso irrestrito aos sistemas da empresa.
Se sua função é consultar o status de um pedido, por exemplo, talvez ele precise apenas de permissão de leitura no sistema de pedidos. Não existe justificativa técnica para conceder ao mesmo agente autorização para excluir registros, alterar preços ou realizar transferências financeiras.
Esse conceito está diretamente relacionado ao risco de excessive agency, identificado pela OWASP. A organização alerta que agentes podem realizar ações prejudiciais quando recebem funcionalidades, permissões ou autonomia excessivas. O problema pode ser desencadeado inclusive por respostas inesperadas ou manipuladas do próprio modelo.
Os guardrails devem estabelecer limites objetivos.
Entre eles estão validação das respostas, filtros de conteúdo, regras de negócio fora da LLM, limites de valores financeiros, autenticação, registro de auditoria e aprovação humana para operações sensíveis.
Uma regra importante é não permitir que a própria IA seja a autoridade final sobre aquilo que ela está autorizada a fazer.
Supervisão humana continua sendo necessária
O objetivo de um agente de IA seguro não deve ser responder a qualquer pergunta a qualquer custo. Em determinadas situações, a resposta correta é simplesmente “não tenho informação suficiente para responder”.
Esse comportamento é particularmente importante quando a base documental não apresenta uma resposta clara.
O sistema também precisa reconhecer situações que exigem intervenção humana, como reclamações complexas, disputas contratuais, solicitações financeiras de alto valor, problemas de segurança ou casos que envolvam exceções às políticas.
Nesse cenário, a IA funciona melhor como copiloto estruturado do que como substituto completamente autônomo.
Ela pode consultar documentos, resumir conversas, identificar informações relevantes, sugerir respostas e recuperar dados rapidamente. O profissional humano continua responsável pelas decisões que exigem julgamento, autorização ou interpretação de contexto.
Essa abordagem também facilita auditoria. Se uma resposta problemática surgir, a equipe pode investigar qual documento foi recuperado, qual versão da política estava vigente, quais instruções foram utilizadas e quais ferramentas o agente acionou.
O futuro do atendimento depende mais da arquitetura do que do chatbot
A corrida para colocar agentes de IA no atendimento ao cliente não deve ser analisada apenas pela capacidade do modelo de conversar de maneira natural.
O verdadeiro desafio está em construir uma infraestrutura na qual a IA saiba o que pode dizer, o que pode fazer e quando precisa parar.
A alucinação em IA no atendimento é perigosa justamente porque uma resposta falsa pode parecer perfeitamente legítima para o consumidor. Quando essa resposta está conectada a sistemas de pagamentos, contratos, pedidos ou contas, o problema deixa de ser apenas uma imprecisão textual e passa a representar um risco operacional.
RAG, bases documentais atualizadas, guardrails, modelos controlados, menor privilégio, auditoria e human-in-the-loop formam uma combinação mais adequada para aplicações críticas.
A IA pode ser uma excelente aliada das equipes de suporte, mas substituir pessoas sem substituir também os controles, processos e responsabilidades que cercam o atendimento cria uma fragilidade difícil de justificar.
O caminho mais seguro não é fazer o agente responder tudo. É construir um sistema capaz de responder com evidências, recusar quando não houver informação confiável e encaminhar para um humano quando a situação ultrapassar seus limites.
