Alucinação de IA: por que acontece e como reduzir na prática [2026]

Em 2023, um advogado de Nova York entregou ao juiz seis precedentes judiciais que nunca existiram. Ele tinha pedido ao ChatGPT uma lista de casos que sustentassem sua tese, recebeu nomes, números de processo e citações formatadas com perfeição, e levou tudo para o tribunal sem conferir uma linha. O tribunal conferiu. A alucinação de IA saiu do campo da curiosidade técnica e virou multa, manchete e material de treinamento para escritórios de advocacia no mundo inteiro.

Três anos depois, os modelos ficaram absurdamente melhores e o problema continua vivo. Ele mudou de forma: em vez de inventar seis processos escancarados, um modelo de 2026 erra um número dentro de um parágrafo correto, cita uma função que a biblioteca descontinuou na versão passada, ou afirma com segurança total um dado de mercado que ninguém consegue rastrear até a fonte. O erro ficou mais raro e mais difícil de enxergar, o que em certos contextos é pior.

Na Marfin, nós rodamos IA em quase tudo: pesquisa, produção de conteúdo, código, automação de processo interno. Aprendemos que reduzir alucinação tem menos a ver com escolher o modelo mais forte do ranking e muito mais a ver com o sistema montado ao redor dele. Este artigo explica o mecanismo por trás do fenômeno, mostra onde ele custa dinheiro de verdade e entrega as táticas que usamos todo dia para manter o índice de erro num patamar aceitável.

Link para esta seçãoO que é alucinação de IA

Alucinação de IA é quando um modelo generativo produz uma informação falsa, inventada ou não sustentada pelas fontes disponíveis, apresentando o resultado com a mesma fluência e a mesma confiança de uma resposta correta. O nome é uma metáfora emprestada da psiquiatria e nem todo mundo gosta dela, porque sugere que a máquina "viu" algo que não estava lá. O termo pegou e hoje é o vocabulário padrão da indústria, de papers acadêmicos a release notes de produto.

A característica que torna o fenômeno perigoso é a ausência de sinal. Quando um software comum falha, ele quebra: joga uma exceção, retorna erro 500, trava a tela. Um modelo de linguagem que alucina entrega um parágrafo bem escrito, no tom certo, com a estrutura esperada. Nada na superfície do texto avisa que aquele trecho específico saiu do nada. O leitor precisa já saber a resposta para perceber que a resposta está errada, o que anula boa parte do motivo de ter perguntado.

Link para esta seçãoOs quatro tipos que mais aparecem no dia a dia

O primeiro tipo é a alucinação factual: datas, números, nomes, estatísticas. O modelo troca 2022 por 2021, atribui uma frase à pessoa errada, arredonda um faturamento para um valor plausível. É o tipo mais comum em pesquisa e produção de conteúdo.

O segundo é a alucinação de fonte. O modelo cita um estudo, um relatório da Gartner, uma reportagem, e a referência simplesmente não existe. Às vezes existe algo parecido com título diferente, às vezes o autor é real e o trabalho é inventado. Foi exatamente esse tipo que derrubou o advogado de Nova York.

O terceiro é a alucinação de código: funções, parâmetros, endpoints e pacotes que nunca foram publicados. Quem programa com IA vê isso toda semana, e a variante mais preocupante ganhou até nome próprio, slopsquatting, quando atacantes registram pacotes com os nomes que os modelos mais inventam e esperam alguém instalar.

O quarto é a alucinação de instrução, mais sutil e bem chata em automação. O modelo recebe um conjunto de regras, ignora uma delas e depois afirma que seguiu todas. Em pipelines automatizados, esse tipo passa direto porque ninguém está lendo cada saída.

Link para esta seçãoPor que os modelos de linguagem alucinam

Para entender a causa, vale voltar ao mecanismo. Um modelo de linguagem grande é um sistema treinado para prever o próximo token de uma sequência a partir de padrões estatísticos aprendidos em um volume gigantesco de texto. Se você nunca mergulhou nessa parte, vale ler nosso guia sobre o que é um LLM e, para o contexto mais amplo, nosso guia de inteligência artificial, que amarra os conceitos que aparecem daqui para frente.

O ponto central: o objetivo de treinamento premia a continuação mais provável, e a verdade não entra nessa conta em nenhum momento. "O CEO da Petrobras é" tem uma continuação estatisticamente forte mesmo quando o modelo não guarda esse dado com precisão. O sistema produz o nome mais plausível dado o padrão, e plausibilidade alta convive perfeitamente bem com falsidade. Alucinação, nessa leitura, é comportamento esperado da arquitetura operando exatamente como foi desenhada.

Link para esta seçãoCompressão, memória e o limite do que cabe nos pesos

Um modelo comprime terabytes de texto em bilhões de parâmetros. Compressão com perda, sempre. Fatos que aparecem milhares de vezes no treino ficam bem representados, fatos raros ficam borrados. O modelo guarda a forma da informação, o formato de um número de processo judicial, a cara de um DOI, a estrutura de uma citação ABNT, mesmo quando não guardou o conteúdo específico. Na hora de responder, ele preenche a forma com o que parece encaixar. É por isso que citações inventadas parecem tão convincentes: o esqueleto está certo.

Some a isso o corte de conhecimento. Todo modelo tem uma data limite de treino e o mundo continua andando depois dela. Perguntas sobre preços, versões de biblioteca, funcionalidades lançadas ontem e mudanças regulatórias caem justamente na zona onde o modelo tem padrão mas não tem dado. Ele completa o padrão.

Link para esta seçãoO incentivo perverso do treinamento por feedback

Existe um segundo motor, comportamental. Modelos passam por ajuste com feedback humano, e humanos avaliando respostas tendem a premiar textos completos, seguros e prestativos. Uma resposta que diz "não tenho essa informação" ganha nota mais baixa do que uma resposta detalhada, mesmo quando a detalhada está errada e o avaliador não percebeu. Ao longo de milhões dessas comparações, o sistema aprende que responder sempre rende mais do que admitir limite. Pesquisadores da OpenAI publicaram em 2025 um trabalho apontando esse desenho de avaliação como um dos culpados: benchmarks que dão zero para abstenção e zero para erro ensinam o modelo a chutar, porque chutar tem valor esperado maior.

Link para esta seçãoContexto longo e atenção diluída

Janelas de contexto passaram de 200 mil tokens e, em alguns modelos, chegam ao milhão. Só que a atenção do modelo não é uniforme ao longo dela. Informação enterrada no meio de um contexto enorme perde peso, e quando o dado correto perde peso, a memória paramétrica volta a preencher a lacuna. Encher o prompt com tudo que existe tende a piorar o resultado, e é aí que entra a disciplina de engenharia de contexto: escolher o que entra, em que ordem e com qual destaque, em vez de despejar arquivos inteiros e torcer.

Link para esta seçãoOnde a alucinação de IA custa dinheiro de verdade

Em brainstorm criativo, um erro factual custa pouco. O custo aparece quando a saída do modelo vira insumo de decisão sem passar por revisão.

Em conteúdo e marketing, alucinação vira dado inventado publicado no blog da marca, com fonte fantasma, indexado pelo Google e depois citado por terceiros. O prejuízo é reputacional e demora meses para aparecer. Nós tratamos qualquer número em artigo como item obrigatório de verificação, sem exceção, e é a razão pela qual todo dado no nosso conteúdo passa por checagem humana antes de subir.

Em atendimento, o chatbot que inventa política de reembolso cria obrigação contratual. A Air Canada perdeu na justiça em 2024 exatamente por isso: o tribunal decidiu que a empresa responde pelo que seu chatbot promete ao cliente, mesmo quando a promessa contradiz a política publicada no site.

Em código, o custo é técnico e de segurança. Um pacote inexistente sugerido por IA e instalado sem conferência abre porta para dependência maliciosa. Uma API imaginária quebra no build, o que é o cenário bom, ou passa em silêncio numa branch pouco testada, o que é o cenário ruim.

Em análise de dados, o erro é o mais insidioso de todos. O modelo lê uma planilha, resume, e no meio do resumo aparece um percentual que ninguém calculou. Como o resto do texto está correto, a linha errada herda a credibilidade das linhas certas.

Link para esta seçãoComo reduzir alucinação de IA na prática

Não existe configuração que zere o problema, e desconfie de qualquer fornecedor que prometa isso. O que existe é um conjunto de camadas que, empilhadas, derrubam a taxa de erro para um nível gerenciável. Elas funcionam melhor combinadas do que isoladas.

Link para esta seçãoGrounding: dar a fonte antes de pedir a resposta

A camada de maior impacto é também a mais óbvia. Um modelo que responde de memória chuta; um modelo que responde a partir de um documento anexado, de um resultado de busca ou de uma consulta ao banco tem onde se apoiar. É o princípio do RAG, a técnica que recupera trechos relevantes de uma base própria e injeta no prompt antes da geração. A qualidade do RAG depende da recuperação, e a recuperação depende de como você indexa: um banco de dados vetorial bem estruturado, com chunks no tamanho certo e metadados úteis, resolve mais alucinação do que trocar de modelo.

Grounding também acontece por ferramenta. Quando o modelo pode chamar uma API, rodar uma query ou buscar na web, ele para de adivinhar o dado e passa a consultá-lo. O MCP, Model Context Protocol, padronizou essa conexão entre modelo e fontes externas, e é hoje a forma mais limpa de plugar um agente nos sistemas reais da empresa. Nossa regra interna é simples: se o dado existe em algum sistema, o modelo consulta o sistema em vez de lembrar.

Link para esta seçãoPrompt: autorizar o "não sei" e exigir citação

Modelos alucinam mais quando o prompt não deixa saída. Uma instrução explícita autorizando a abstenção muda o comportamento de forma mensurável. Nós escrevemos alguma variação de "se a informação não estiver nas fontes fornecidas, responda que não encontrou e liste o que precisaria para responder" em praticamente todo prompt de produção.

A segunda instrução de maior retorno é exigir atribuição por afirmação. Pedir que cada dado venha acompanhado do trecho da fonte que o sustenta força o modelo a percorrer o material em vez de gerar solto, e ainda facilita a revisão: quem confere olha a citação e valida em segundos. Outras técnicas que rendem bem estão detalhadas no nosso guia de prompt engineering, e vale destacar duas: pedir raciocínio antes da resposta, e separar a tarefa de extrair informação da tarefa de escrever o texto final.

Link para esta seçãoVerificação: em camadas, com a máquina fazendo o trabalho chato

Revisão humana não escala sozinha. O que escala é verificação automática antes da humana. Em conteúdo, uma segunda passada do modelo com a única missão de listar afirmações verificáveis e marcar quais têm suporte nas fontes pega uma fatia grande dos erros. Em código, o verificador já existe e é gratuito: o compilador, o linter e a suíte de testes. Um agente que roda o build e lê o erro corrige a API inventada sozinho, sem ninguém olhar.

Para tarefas de alto risco, vale gerar a mesma resposta duas ou três vezes e comparar. Onde as respostas divergem está a região de baixa confiança, e é exatamente ali que a atenção humana rende mais. Consistência entre amostras não prova verdade, porém aponta muito bem onde o modelo está inseguro.

Link para esta seçãoConfiguração: temperatura, effort e escolha de modelo

Temperatura baixa reduz a aleatoriedade da amostragem e ajuda em tarefas factuais, sem resolver nada quando o modelo simplesmente não tem o dado. Modelos com raciocínio estendido erram menos em tarefas que exigem cadeia lógica, ao custo de latência e tokens. O controle de esforço do Claude Opus 4.8 permite calibrar isso por tarefa, gastando raciocínio onde o erro é caro e economizando onde não é. A escolha do modelo importa, mas na nossa experiência ela entra depois do grounding e do prompt na ordem de prioridade, porque um modelo excelente sem fonte ainda inventa.

Link para esta seçãoAlucinação de IA em código: o caso do vibe coding

Programar com IA amplifica e ao mesmo tempo domestica o problema. Amplifica porque o volume de código gerado explodiu e ninguém lê tudo. Domestica porque código tem verificador automático, coisa que texto não tem.

O padrão que mais vemos: o modelo sugere um método que a biblioteca não expõe, ou usa a assinatura de uma versão antiga. Ferramentas que leem o projeto inteiro erram menos nesse ponto, porque o código real está no contexto. É uma das razões pelas quais o Claude Code é a ferramenta que mais usamos na Marfin: ele abre os arquivos, checa a assinatura de verdade antes de escrever, roda o teste e corrige o próprio erro no mesmo ciclo. O Cursor AI, que usamos para building no dia a dia, funciona pela mesma lógica com indexação do repositório. Quem quiser comparar as opções pode olhar nosso comparativo das melhores IDEs com IA.

O risco de segurança merece parágrafo próprio. Pesquisas de 2024 e 2025 mediram que uma fatia relevante das sugestões de dependência geradas por modelos aponta para pacotes inexistentes, e que os nomes inventados se repetem entre execuções. Isso cria um alvo previsível para quem quer registrar o pacote e esperar a instalação. A defesa é chata e funciona: lockfile, revisão de qualquer dependência nova, e desconfiança padrão com nome de pacote que você nunca viu.

Link para esta seçãoComo medir alucinação de IA antes de confiar no sistema

Sem medição, todo mundo acha que seu sistema está bom. Três métricas dão conta da maioria dos casos.

Groundedness mede a fração de afirmações da resposta que encontram suporte no contexto fornecido. É a métrica principal de qualquer sistema com RAG e pode ser calculada com um modelo avaliador comparando resposta e fontes, trecho por trecho.

Taxa de citação válida mede quantas referências apontam para documentos que existem e realmente dizem aquilo. Barata de automatizar e cruel de olhar na primeira vez.

Taxa de abstenção correta mede quantas vezes o sistema disse "não sei" quando de fato não tinha a informação. Um sistema com abstenção zero em um conjunto de perguntas impossíveis está chutando, e você vai descobrir isso em produção se não descobrir antes.

O jeito prático de montar isso é criar um conjunto de avaliação com cinquenta a cem perguntas do seu domínio, incluindo perguntas cuja resposta não está na base, e rodar esse conjunto a cada mudança de prompt, de modelo ou de indexação. Sem esse conjunto, qualquer ajuste vira opinião.

Link para esta seçãoPreços e planos das ferramentas que usamos

Reduzir alucinação custa pouco em licença e bastante em disciplina. O Claude Pro sai por cerca de US$ 20 por mês e resolve o uso individual com anexos e projetos; os planos Max começam na faixa de US$ 100 mensais e liberam volume alto de uso do Claude Code, que vem incluído nas assinaturas. O Cursor AI fica na mesma faixa de US$ 20 mensais no plano Pro.

Para a camada de dados, o Supabase tem plano Free que aguenta protótipo, Pro a US$ 25 por mês, Team a US$ 599 e Enterprise sob consulta. Com pgvector ativado, ele serve como banco vetorial do seu RAG sem precisar contratar um serviço separado, o que simplifica bastante o começo. Nosso tutorial de Supabase cobre o setup.

No GitHub Copilot, as code completions seguem gratuitas no plano básico e a cobrança por AI Credits entrou em vigor a partir de junho de 2026 para uso de agente. O Devin AI cobra US$ 20 mensais no Core mais US$ 2,25 por ACU consumida, e o plano Team sai por US$ 500 com 250 ACUs incluídas. Para uso via API, o modo rápido do Opus 4.8 ficou cerca de três vezes mais barato que a geração anterior, o que muda a conta de rodar verificação automática em cima de cada saída: revisar com IA passou a custar uma fração do que custa gerar.

Link para esta seção10 dicas para reduzir alucinação de IA

1. Nunca peça um dado que você pode fornecer. Se a informação está num PDF, numa planilha ou no seu banco, coloque no contexto ou dê acesso via ferramenta. Memória do modelo é a última opção, sempre.

2. Autorize a abstenção em todo prompt de produção. Uma frase dizendo que "não encontrei" é resposta aceitável muda o comportamento do modelo mais do que qualquer parâmetro de configuração.

3. Exija citação por afirmação, com trecho. Pedir a fonte junto de cada dado força o modelo a se apoiar no material e reduz o custo de revisão a segundos por item.

4. Separe extrair de escrever. Uma chamada para levantar os fatos com fonte, outra para redigir a partir daquela lista. Misturar as duas tarefas aumenta muito a chance de invenção no meio do texto.

5. Verifique número por número. Estabeleça a regra de que nenhum dado numérico sai sem checagem em fonte primária. Percentuais e valores em reais são as duas categorias que mais alucinam.

6. Rode o código antes de acreditar nele. Build, linter e teste pegam API inventada em segundos. Um agente que executa a verificação sozinho fecha o ciclo sem consumir tempo humano.

7. Trate dependência nova como suspeita. Qualquer pacote que a IA sugeriu e você não conhece merece uma busca no registro oficial antes de instalar. Slopsquatting depende exatamente dessa checagem não acontecer.

8. Corte o contexto em vez de encher. Documento inteiro no prompt dilui a atenção. Selecionar os trechos certos entrega mais precisão do que despejar tudo.

9. Monte um conjunto de avaliação do seu domínio. Cinquenta perguntas reais, com gabarito, incluindo perguntas sem resposta na base. Rode a cada mudança e acompanhe a curva.

10. Escale a verificação pelo custo do erro. Post de redes sociais aceita revisão leve. Número em proposta comercial, cláusula contratual e cálculo financeiro pedem dupla checagem humana. Calibrar isso evita tanto o desastre quanto a paranoia que trava o time.

Alucinação de IA é uma propriedade do funcionamento dos modelos generativos, e vai continuar existindo enquanto a arquitetura for baseada em previsão probabilística. A pergunta prática deixou de ser como eliminar e passou a ser como projetar processos que assumem a falha e a capturam antes do dano. Quem trata a saída do modelo como rascunho de especialista, sempre verificável, aproveita a velocidade sem herdar o risco. Quem trata como verdade pronta acaba explicando ao chefe, ou ao juiz, de onde veio aquele número.

A boa notícia é que o custo de verificar despencou. Com modelos rápidos e baratos revisando saídas de modelos caros, dá para colocar duas ou três camadas de checagem em cima de cada geração e ainda sair na frente em produtividade. Foi assim que resolvemos o problema na Marfin, e é o desenho que recomendamos para qualquer time que esteja colocando IA em contato com cliente, com código de produção ou com decisão de negócio.

Leia também:

TL;DR