Governança Prática Contra Alucinações de IA: Além da Engenharia de Prompts

A indústria gastou dois anos tentando eliminar alucinações. Não funcionou. Em 2025, a pesquisa MetaRAG confirmou o que engenheiros de produção já suspeitavam: modelos de linguagem são sistemas probabilísticos. Alucinações não são bugs. São propriedades emergentes da arquitetura.

Essa constatação muda a pergunta. De “como eliminar alucinações?” para “como governar sistemas que alucinam?”

A diferença não é semântica. A primeira pergunta pertence a fornecedores de modelos. A segunda pertence a quem opera IA em produção. E é a segunda que determina se a saída do seu sistema merece confiança.

O Que Falha Quando Você Só Confia no Prompt

Engenharia de prompts é necessária. Não é suficiente.

Prompts são instruções. O modelo pode segui-las, ignorá-las ou interpretá-las de forma criativa. Quando um modelo alucina, o circuito interno que deveria acionar a recusa falha. Como analisamos na pesquisa de interpretabilidade, alucinações ocorrem quando features internas falsas suprimem o mecanismo de recusa do modelo. O modelo não alucina por falta de instrução. Alucina porque um sinal interno diz, incorretamente, que a informação existe.

Nenhum prompt resolve isso. Prompts informam. Guardrails impõem.

Cinco Camadas de Defesa Que Funcionam

A arquitetura que reduz alucinações em produção opera em camadas. Cada camada bloqueia uma classe de erro diferente. Nenhuma funciona sozinha.

1. Filtragem semântica de ferramentas

Agentes de IA alucinam mais conforme ganham acesso a mais ferramentas. Isso é contra-intuitivo: mais capacidade deveria significar mais precisão. Na prática, mais ferramentas significam mais oportunidades para o modelo escolher a ferramenta errada e fabricar uma resposta plausível a partir da saída.

A solução é pré-filtrar. Usando FAISS para indexação semântica, um teste com 29 queries de viagem reduziu 31 ferramentas para 3 relevantes por chamada. Resultado: 86,4% menos erros e 89% menos tokens consumidos. Menos contexto irrelevante produz respostas mais precisas.

2. Guardrails neurossimbólicos

O padrão BeforeToolCallEvent (AWS Strands Agents SDK) intercepta chamadas de ferramentas no nível do framework, antes da execução. Quando o hook define cancel_tool, o cancelamento é absoluto. O modelo recebe uma resposta de cancelamento que não pode ser contornada por engenharia de prompt, jailbreak ou qualquer manipulação de contexto.

Em testes controlados, agentes sem guardrails executaram 3 de 3 operações inválidas. Agentes com guardrails bloquearam todas as 3. A diferença entre “o modelo foi instruído a não fazer” e “o framework impede que o modelo faça” é a diferença entre orientação e controle.

3. Graph-RAG para queries computacionais

RAG tradicional funciona bem para perguntas factuais simples. Falha em agregações. Quando você pergunta “quantos hotéis têm piscina?”, o modelo não computa a resposta a partir dos documentos recuperados. Ele gera um número plausível a partir de chunks de texto.

Graph-RAG (Neo4j + Cypher) resolve essa classe de alucinação eliminando a geração. O banco de grafos computa a resposta. Em teste com 300 documentos de FAQ de hotel, RAG fabricou contagens de piscinas. Graph-RAG retornou 133, o número exato. Quando a query estava fora do domínio (acomodações na Antártica), RAG inventou uma resposta. Graph-RAG retornou vazio.

A diferença: RAG recupera contexto e espera que o modelo raciocine corretamente. Graph-RAG computa a resposta e entrega o resultado.

4. Decodificação restrita no nível do token

Ferramentas como LMQL e Outlines impõem restrições estruturais durante a geração, não depois. A distinção importa. Validação pós-geração (verificar se o JSON é válido depois que o modelo terminou) detecta erros. Decodificação restrita previne que tokens impossíveis sejam gerados.

Se a saída esperada é um JSON com três campos obrigatórios, a decodificação restrita garante que o modelo não pode produzir tokens que violem essa estrutura. O custo computacional é marginal. O benefício é que uma classe inteira de alucinações estruturais simplesmente não existe.

5. Avaliação contínua com SLMs especializados

Pontuações de confiança auto-reportadas por modelos são não confiáveis. Pesquisas do NAACL 2024 e JMIR 2025 documentam que modelos são sistematicamente superconfiantes em saídas incorretas. Perguntar ao modelo “você tem certeza?” é inútil.

A alternativa: modelos pequenos especializados em detecção de alucinações. O Galileo Luna-2, com 3B/8B parâmetros, atinge 0,95 F1 para detecção de alucinações, latência abaixo de 200ms e custo aproximado de US$ 0,02 por milhão de tokens. Isso é 98% mais barato que usar um LLM grande como juiz. Torna avaliação de produção em tempo real economicamente viável pela primeira vez.

A Arquitetura de Defesa em Profundidade

Essas cinco camadas se organizam em três estágios:

Entrada. Filtragem semântica de ferramentas e validação de contexto. Reduz a superfície de erro antes que o modelo processe a query. Latência típica: menos de 5ms com Pydantic, 50ms com FAISS.

Comportamento. Guardrails neurossimbólicos e decodificação restrita. Controlam o que o modelo pode fazer durante a geração. Overhead de 50-100ms, aceitável para a maioria dos casos de uso em produção.

Saída. Avaliação por SLMs e filtragem de conteúdo. Verificam o resultado antes da entrega ao usuário. Latência variável: 5ms para validação estrutural, 200ms para avaliação semântica, até 2 segundos para verificação cruzada com LLM.

O overhead total fica entre 50ms e 300ms para a maioria das implementações. A decisão de arquitetura é qual combinação de camadas ativar para cada nível de risco. Uma resposta a uma pergunta de FAQ interna não precisa de verificação cruzada por LLM. Uma resposta que alimenta uma decisão financeira precisa de todas as camadas.

O Que RAG Não Resolve (e Ninguém Conta)

RAG virou sinônimo de “solução para alucinações”. Essa narrativa é incompleta.

RAG muda os tipos de alucinação. Não os elimina. A alucinação mais perigosa em sistemas RAG não é inventar informação. É ignorar o contexto recuperado. O modelo recebe os documentos corretos e ainda assim gera uma resposta baseada em seu treinamento, não no contexto fornecido. A literatura chama isso de “alucinação de fidelidade”.

Plataformas de guardrails detectam esse problema. Não o previnem. A distinção importa porque detecção significa que a resposta errada foi gerada e precisa ser descartada. Prevenção significa que a resposta errada nunca existiu. Em sistemas de alto volume, a diferença entre detectar e prevenir é a diferença entre custo aceitável e custo proibitivo.

Como exploramos em governança de design de saída, guardrails de qualidade precisam ser artefatos de governança, não otimizações de prompt. O mesmo princípio se aplica aqui: controle de alucinações é arquitetura, não configuração.

O Fator Regulatório

O EU AI Act entra em vigência plena em agosto de 2026. Multas de até EUR 35 milhões ou 7% do faturamento global, o que for maior. O Stanford HAI AI Index 2025 registra aumento de 56,4% ano a ano em incidentes de segurança de IA até 2024.

Esses números estabelecem um piso regulatório. Organizações que operam IA sem controles documentados de alucinação não estão apenas assumindo risco técnico. Estão assumindo risco legal.

A “precisão de crença” que discutimos em dívida de design ganha uma dimensão nova: se o usuário confia na saída da IA e a saída está errada, quem é responsável? A resposta regulatória está ficando cada vez mais clara. É a organização que implantou o sistema.

Ferramentas de Referência

Para equipes que precisam implementar, não apenas entender:

Prevenção. NVIDIA NeMo Guardrails (open-source, Colang DSL, Apache 2.0). LMQL e Outlines para decodificação restrita. AWS Strands Agents SDK para guardrails neurossimbólicos.

Detecção. Galileo Luna-2 para avaliação por SLM. Azure AI Content Safety para detecção de fundamentação. RAGAS e DeepEval como frameworks de avaliação open-source.

Infraestrutura. Guardrails AI (Python, Pydantic, mais de 50 validadores pré-construídos). Neo4j para Graph-RAG. FAISS para filtragem semântica de ferramentas.

O Que Fazer na Segunda-Feira

Se você opera IA em produção sem controles de alucinação em camadas, comece com três ações.

Primeiro, classifique suas saídas por nível de risco. Nem toda resposta precisa de verificação cruzada. Saídas que alimentam decisões financeiras, médicas ou legais precisam de todas as camadas. Respostas a perguntas internas de FAQ podem operar com validação estrutural.

Segundo, implemente um guardrail neurossimbólico em pelo menos um fluxo crítico. Não instrua o modelo a não fazer algo. Impeça que o framework permita que ele faça. A diferença em produção é absoluta.

Terceiro, meça. Antes e depois. Sem métricas, você não tem governança. Tem esperança.

Fontes

AWS Community. “Why AI Agents Fail: Hallucinations in Agentic Systems and How to Fix Them.” 2025.
Stanford HAI. “AI Index Report.” 2025.
NVIDIA. “NeMo Guardrails.” Open-source, Apache 2.0.
Guardrails AI. “Guardrails Framework.” Open-source, Python.
AWS. “Sample: Why Agents Fail.” Open-source.

Victorino Group ajuda organizações a construir governança de alucinações em sistemas de IA antes que saídas não confiáveis se acumulem em falhas de confiança. Fale conosco.