Como impedir IA de inventar dados (5 passos práticos)

Quando a sua IA inventa um dado de cliente, o problema não é “um erro pontual”. É uma falha estrutural: você perdeu a confiança no sistema e, com ela, a credibilidade do seu processo inteiro. A boa notícia é que dá para bloquear alucinações com uma arquitetura de validação e regras de saída, sem depender de “prompts mais criativos”.

Por que a IA inventa dados: estocástica não é determinismo

Modelos de linguagem não funcionam como bancos de dados. Eles geram texto com base em probabilidades e padrões aprendidos, o que explica por que podem “preencher lacunas” com informações plausíveis, mas falsas. No vídeo, a distinção é direta: estocástico vs determinístico.

Em modo estocástico, o modelo pode escolher entre várias continuidades possíveis para a resposta. Mesmo com instruções, ele continua tentando completar a tarefa com o que “faz sentido” estatisticamente. Isso é especialmente perigoso quando você pede dados objetivos (CPF, endereço, status, valores, datas, histórico) que deveriam vir de uma fonte confiável.

O vídeo também aponta as 3 causas raiz que levam à alucinação em sistemas reais:

• Prompt interpretado como sugestão: o modelo “entende” o que você quer, mas não trata isso como regra absoluta.
• Campo sem contrapeso: se o schema/estrutura permite espaço para “qualquer resposta”, a IA preenche.
• Ausência de validação antes de responder: o sistema não checa se o que foi gerado é compatível com o que você realmente sabe.

O ponto-chave: não basta reduzir a temperatura ou “pedir para não inventar”. Você precisa de um mecanismo que force a resposta a respeitar estrutura, permissões e origem.

Prompt não é regra absoluta: JSON Schema vira a primeira linha de defesa

Uma das armadilhas mais comuns é acreditar que instruções no prompt resolvem tudo. O vídeo usa uma analogia: como se fosse uma “pessoinha” que tenta ajudar. Ela pode até seguir a intenção, mas ainda assim completar com o que acha razoável quando faltam dados.

Por isso, o primeiro pilar prático é JSON Schema corretamente. Em vez de pedir texto livre, você força a IA a devolver um objeto com campos definidos, tipos corretos e restrições. Isso reduz o espaço para “chutes” por inconsistência estrutural.

Na prática, o JSON Schema deve cobrir decisões que a IA costuma improvisar:

• Campos obrigatórios: se um campo é convite para erro, ele precisa ser tratado como obrigatório apenas quando houver fonte confiável.
• Enums: respostas que só podem ser de um conjunto fechado (por exemplo, “status” em ATIVO/INATIVO/PENDENTE).
• Campos nullable: quando a informação pode não existir, você permite null em vez de forçar “inventar um valor”.
• Tipos e formatos: números, strings, datas e padrões (ex.: CPF com estrutura definida, quando aplicável).

Um detalhe que aparece como diferencial no vídeo é tratar “não sei” como resposta válida, não como falha. Se o sistema está estruturado para aceitar ausência de informação, o modelo deixa de ter incentivo para preencher com algo plausível.

Loop validador → correção → validador: no máximo 3 tentativas

O segundo pilar é o que realmente muda o jogo: um fluxo com validador em código que corrige antes de responder. Em vez de confiar na saída final do modelo, o sistema valida o JSON gerado. Se falhar, você não entrega ao cliente; você corrige e tenta novamente.

O vídeo descreve um loop com uma regra simples e eficiente: máx. 3 tentativas. Isso evita que o agente fique “refinando” indefinidamente e também limita custo e tempo.

O fluxo típico fica assim:

• A IA gera um JSON conforme o schema.
• Um validador verifica: tipos, enums, campos obrigatórios, nullable e formatos.
• Se houver erro, você envia um feedback estruturado para a IA corrigir (por exemplo: “o campo X é obrigatório”, “o valor do enum Y não existe”, “data em formato inválido”).
• Valida novamente.
• Se ainda falhar após 3 tentativas, o sistema retorna uma resposta segura (por exemplo, “não sei”/null onde permitido) em vez de inventar.

Esse mecanismo elimina a principal causa operacional de perda de credibilidade: o sistema que “responde mesmo quando não sabe”. Aqui, validador obrigatório antes da resposta deixa de ser uma boa prática e vira requisito.

O vídeo também reforça um ponto direto: campo obrigatório = convite para o chute. Se você marca tudo como obrigatório sem garantir fonte, o modelo tende a preencher. Por isso, a combinação correta é: schema restritivo + nullable onde faz sentido + resposta explícita de “não sei”.

Checklist completo: temperatura baixa, nullable, enums, perguntas de teste e log

Mesmo com JSON Schema e validador, sistemas ainda falham quando faltam controles de qualidade. O vídeo fecha com um checklist que “quase todo mundo esquece”, e é exatamente isso que evita regressões quando você muda prompts, integrações ou fontes.

Itens essenciais do checklist (extraídos dos pilares mencionados):

• Temperatura baixa: reduz variação, mas não substitui validação.
• “Não sei” como resposta válida: trate isso como comportamento esperado quando não houver dados.
• Campos nullable: use null quando a informação não estiver disponível, em vez de forçar um valor.
• Enums: restrinja campos categóricos a valores permitidos.
• Validação de fonte: quando o dado vem de sistemas externos (CRM, ERP, planilhas, APIs), valide se a resposta está alinhada com o que foi buscado.
• Validador antes de responder: nunca entregue JSON inválido ou semanticamente inconsistente.
• Perguntas de teste: inclua cenários onde a resposta não existe e o agente precisa retornar “não sei” corretamente.
• Checklist antes da chamada e antes da resposta: a validação não pode ser só no final.
• Log de saída: registre o JSON gerado e o resultado da validação para depurar e auditar.

Um exemplo prático: se um cliente solicita “qual é o status do pedido?”, mas você não tem acesso ao pedido específico, o agente precisa retornar um objeto válido onde o campo status esteja null (ou um enum específico de “desconhecido”, se você modelar assim). O sistema deve continuar consistente, sem fabricar um status “ATIVO” ou “PENDENTE” só porque é plausível.

Esse tipo de rigor é o que permite construir agentes em N8n, código ou automações com “vibe coding” sem transformar cada interação em um risco de reputação. Você não está apenas reduzindo alucinação: está governando o que pode ser dito.

Se você quer o passo a passo com os 5 pilares no detalhe e a mecânica completa do loop de validação, assista ao vídeo “Como impedir IA de inventar dados (5 passos práticos)”.

---

Sua empresa pode ir mais longe com inteligência artificial.
Na Sincron IA, criamos soluções sob medida em automação e IA para empresas que querem liderar seus mercados.
Vamos conversar → sincronia.digital