Alucinação em Agente de IA não é bug. É risco a governar.

Quando um LLM "alucina" em texto, o pior cenário é uma informação errada.

Quando um AGENTE alucina, o pior cenário é uma ação irreversível: uma API chamada com parâmetro inventado, uma etapa que contamina todas as seguintes, uma decisão tomada sem ninguém revisando o passo intermediário.

Alucinação em Agentes de IA: por que é mais grave e como mitigar

Você está certo em separar isso do chat comum — em agentes, a alucinação deixa de ser "um texto errado" e vira erro de sistema com consequências reais: um plano errado, uma chamada de API errada, uma ação de negócio executada incorretamente. Um agente jurídico que "alucina" uma citação processual não é o mesmo risco que um chatbot que erra um fato histórico.

1. Por que é pior em agentes (o que muda estruturalmente)

• Composição de erros — um agente executa múltiplos passos em sequência (raciocinar → chamar ferramenta → interpretar resultado → decidir próximo passo). Uma alucinação no passo 2 se propaga e contamina os passos 3, 4, 5 — o erro não fica isolado, ele cresce.

• "Tool call hallucination" — o modelo pode inventar parâmetros de uma ferramenta, interpretar mal o retorno de uma API, ou até "alucinar" que uma ferramenta retornou algo que na verdade não retornou. Isso é considerado, na literatura mais recente, o modo de falha mais perigoso em sistemas agentic — porque a consequência não fica confinada ao texto, ela vira ação.

• Menos supervisão humana por passo — no chat, o usuário lê cada resposta. No agente, muitas etapas intermediárias não são revisadas por ninguém até a ação final já ter sido tomada.

2. Como detectar (técnicas concretas)

Nível de resposta única:

• Verificação em cadeia de raciocínio (chain-of-thought verification) — peça para o agente explicar seu raciocínio passo a passo antes de agir; isso expõe premissas falhas antes da execução.
• Best-of-N — rodar o mesmo prompt/etapa múltiplas vezes e comparar; inconsistência entre execuções é sinal de alucinação, não de fato consolidado.

Nível de sistema (produção):

• Observabilidade/tracing por span — rastrear cada chamada de ferramenta individualmente (não só a resposta final), permitindo auditar em qual etapa exata o erro entrou.
• LLM-as-a-judge — usar um segundo modelo (ou uma segunda chamada) para avaliar se a saída de uma etapa está de fato fundamentada no que a ferramenta retornou, ou se o agente "preencheu a lacuna".
• Feedback visual/de estado — em tarefas com saída verificável (UI, código, arquivos), fazer o agente capturar evidência do resultado real (ex: screenshot) e comparar com o que foi pedido, em vez de assumir que a ação funcionou.

3. Como prevenir (arquitetura, não só prompt)

A própria documentação de engenharia da Anthropic para o Agent SDK resume o ciclo recomendado em três fases: reunir contexto → agir → verificar o trabalho. Na prática:

1. Fundamentar antes de agir — restringir o agente a usar apenas informação recuperada de fontes verificadas (RAG, documentos, resultado real de ferramenta), nunca conhecimento geral do modelo, para decisões que viram ação.
2. Permitir e recompensar "não sei" / "não posso confirmar" — mesmo princípio do chat, mas aqui o custo de não aplicar é maior: um agente que prefere "chutar" a parar e perguntar propaga erro.
3. Verificação estrutural (não estilística) — exigir que o output de cada etapa crítica seja auditável (citação de qual ferramenta/fonte gerou aquele dado), não apenas plausível.
4. Human-in-the-loop em pontos de não-retorno — qualquer ação irreversível (enviar, deletar, pagar, publicar) deve ter um ponto de confirmação humana explícito antes de executar — isso já está no padrão de comportamento do Claude para ações externas, mas vale reforçar na sua arquitetura de agente.
5. Guardrails + gate de release — antes de colocar o agente em produção, rodar suítes de teste com casos-armadilha (situações onde a resposta certa é "não sei" ou "não posso fazer isso") e bloquear deploy se a taxa de alucinação regredir.
6. Sandboxing de permissões — limitar o que o agente pode fazer tecnicamente (escopo de ferramentas, sistema de arquivos, comandos) reduz o dano de uma alucinação mesmo quando ela não é detectada a tempo.

4. Aplicação direta ao seu contexto de GRC

Do ponto de vista de controle (que é sua área de foco no MBA), o ponto-chave é: trate alucinação em agente como risco operacional, com controles compensatórios formais — não como algo que "melhora sozinho com a próxima versão do modelo". Isso sugere, em termos de framework GRC:

• Segregação de funções entre "agente que decide" e "agente/processo que verifica" (nunca deixar o mesmo agente auto-validar sua própria ação de alto risco)
• Trilha de auditoria obrigatória por etapa (não só resultado final)
• Aprovação humana como controle compensatório em ações irreversíveis — isso conecta diretamente com o modelo SoD que você já vem trabalhando no seu projeto de graph model.

5- A regra de ouro e a arquitetura de verificação em agentes multi-IA

5.1 - A regra de ouro

Nunca deixe o mesmo sistema que gerou uma afirmação ser a única fonte que a confirma. Toda alucinação, em qualquer topologia, tem uma característica comum: uma afirmação não fundamentada é aceita como fato só porque soa coerente com o que veio antes. A defesa estrutural, portanto, não é "pedir para o agente ter mais cuidado" — é forçar toda afirmação de alto risco a passar por uma fonte independente da que a gerou antes de virar ação. Independente pode ser: dado bruto de ferramenta, regra determinística, outro modelo, ou humano — mas tem que ser desacoplado do raciocínio original. Isso é o pano de fundo para tudo abaixo.

5.2 Análise por topologia

Serial / sequencial (pipeline)

• Risco característico: propagação e amplificação. Uma alucinação na etapa 1 vira premissa "verdadeira" na etapa 2, que vira premissa na etapa 3 — cada etapa seguinte confia cegamente na anterior.
• Mitigação: checkpoint de verificação entre cada etapa, não só no fim. Cada etapa deve receber apenas dado verificado da anterior, nunca a conclusão bruta sem validação.

Hierárquico (orquestrador → subagentes)

• Risco característico: o orquestrador pode alucinar ao interpretar os resultados dos subagentes — mesmo que cada subagente individualmente tenha acertado, o agregador pode resumir errado, misturar resultados, ou "preencher" uma lacuna entre eles.
• Mitigação: subagentes retornam dado estruturado (não prosa livre) sempre que possível — isso reduz a superfície de interpretação errada pelo orquestrador. O orquestrador deve citar de qual subagente veio cada afirmação antes de agregar.

Paralelo (múltiplos agentes independentes na mesma tarefa)

• Risco característico: alucinações não correlacionadas entre agentes podem, paradoxalmente, ser detectadas por divergência — mas alucinações correlacionadas (o mesmo viés de treinamento levando todos a errar igual) passam despercebidas mesmo com consenso.
• Mitigação: aqui o "best-of-N" ganha força real — comparar respostas independentes e tratar divergência como sinal de alerta. Mas só funciona bem se os agentes tiverem alguma diversidade real (modelos diferentes, prompts diferentes, ou fontes de dados diferentes) — N cópias idênticas do mesmo modelo com o mesmo prompt tendem a errar juntas.

Malha / swarm (agentes com handoff dinâmico, sem hierarquia fixa)

• Risco característico: é o pior caso para rastreabilidade — quando um erro aparece, é difícil dizer qual agente o introduziu, porque o contexto passa de mão em mão informalmente.
• Mitigação: rastreamento de estado explícito por agente (status estruturado, não texto livre) e handoffs com assinatura de origem — cada agente declara explicitamente o que fez e com que confiança, nunca apenas "concluído".

5.3 - Como configurar guardrails — princípio central

A pesquisa recente aponta uma distinção crucial: guardrail baseado só em prompt ("nunca confirme sem verificar pagamento") é ele mesmo vulnerável a alucinação — porque o LLM decide a cada chamada se vai obedecer a instrução, e pode "alucinar conformidade" (relatar que verificou quando não verificou).

A solução que a literatura chama de neurosimbólica é: regras críticas de negócio devem ser aplicadas fora do LLM, em código determinístico que intercepta a ação antes da execução — não como instrução de prompt, mas como trava estrutural que o modelo não consegue contornar por interpretação. Exemplo prático: se a regra é "nunca reservar sem pagamento confirmado", isso não deve estar só no system prompt — deve estar num hook/validador de código que barra a chamada da ferramenta de reserva se o campo payment_confirmed não vier true de uma fonte real.

Resumo da hierarquia de confiabilidade dos guardrails (do mais fraco ao mais forte):

1. Instrução em prompt ("por favor verifique X") — mais fraco, pode ser ignorado/alucinado
2. Outro agente/LLM revisando a saída — melhor, mas ainda falível (ver abaixo)
3. Regra determinística/código que bloqueia a ação — mais forte, não depende de interpretação
4. Aprovação humana no ponto de não-retorno — mais forte ainda para ações irreversíveis

5.4 - Sempre deve existir um agente verificador?

Não necessariamente um agente — mas sempre deve existir uma camada de verificação desacoplada. A diferença importa muito: um segundo LLM revisando o primeiro é uma opção, mas não é a única, nem a mais robusta.

Pesquisa dedicada a esse padrão (Executor → Validator → Critic) mostra que sistemas de agente único, por definição, não têm mecanismo de autocorreção — a alucinação passa despercebida por design, porque não existe nenhum ponto no fluxo em que a afirmação é confrontada com algo externo. Introduzir uma segunda camada de validação cruzada já reduz isso estruturalmente. Mas — e aqui chegamos no seu ponto seguinte — qual tipo de verificador importa mais do que ter um verificador.

5.5 - O verificador também pode alucinar — como quebrar essa regressão

Você identificou o problema real: se o verificador é só "mais um LLM", você não eliminou o risco, só adicionou uma segunda chance de erro correlacionado — especialmente se o verificador for o mesmo modelo, ou um modelo com viés de treinamento parecido. Isso é análogo ao problema filosófico de "quem vigia os vigilantes" (quis custodiet ipsos custodes).

A saída não é empilhar mais LLMs — é diversificar o tipo de verificação, não só o número de verificadores:

1. Verificação determinística/simbólica sempre que possível — se a afirmação pode ser checada por regra, cálculo, schema, ou consulta a banco de dados, isso deve substituir o LLM verificador, não competir com ele. Código não alucina.
2. Verificação contra fonte primária, não contra outro output gerado — o verificador deve comparar a afirmação com o dado bruto da ferramenta/documento original, não com a "opinião" de outro modelo sobre se aquilo parece certo.
3. Diversidade real entre gerador e verificador — se usar LLM como juiz, use modelo diferente, com prompt/instrução diferente, idealmente de fornecedor diferente, para reduzir correlação de erro. Mesmo modelo julgando a si mesmo é o cenário mais fraco.
4. Verificador restrito a uma tarefa estreita e auditável — um verificador que só checa "esse número bate com o que está no documento X?" tem muito menos superfície para alucinar do que um verificador que precisa julgar "essa resposta está correta?" de forma aberta.
5. A cadeia de verificação sempre termina em algo não-LLM — em algum ponto da hierarquia (não necessariamente todo passo), a validação final de uma ação de alto risco deve tocar em algo determinístico ou humano. Nunca é "LLM valida LLM valida LLM" até o infinito — isso não converge para verdade, só dilui a responsabilidade.

5.6 -Síntese para sua aplicação em GRC

Isso mapeia diretamente para o princípio de segregação de funções (SoD) que você já trabalha: o papel de "executor" e o papel de "verificador" precisam ter fontes de autoridade e vieses estruturalmente diferentes — exatamente como você não aceitaria que a mesma pessoa que aprova uma despesa também a audite. Em termos de controle: trate "verificador é o mesmo tipo de LLM que o executor" como uma violação de SoD, não como uma solução de segurança — porque o mecanismo de falha (o próprio LLM) é compartilhado entre as duas funções.

LINK: Artigo publicado primeiro no LINKEDIN:

https://www.linkedin.com/feed/update/urn:li:activity:7499817587976056832/

HASG TAGS:

hashtag#IAAgentic hashtag#InteligenciaArtificial hashtag#GRC hashtag#GovernancaDeIA hashtag#SegurancaDaInformacao hashtag#AridioSilva hashtag#AIGovernance hashtag#OWASP hashtag#NIST hashtag#GestaoDeRiscos hashtag#Cibersegurança hashtag#AIRisk hashtag#ResponsibleAI hashtag#AgenticAI hashtag#LLM hashtag#DataScience