Casos de alucinação de IA jurídica passam de 2.000: o que construir

Decisões judiciais sobre conteúdo alucinado por IA passam de 2.000. Por que o RAG sozinho não resolveu e padrões de design do meu trabalho em IA para contratos.

Até 14 de setembro de 2026, a base AI Hallucination Cases, de Damien Charlotin, registrava 2.041 decisões de tribunais e outros órgãos julgadores sobre conteúdo alucinado por IA. Na maioria delas, um tribunal constatou, ou deu a entender, que uma parte se apoiou nesse conteúdo; excepcionalmente, a base também inclui algumas em que o uso de IA foi alegado, mas não confirmado. A recuperação (retrieval), sozinha, não resolve: três das principais ferramentas de pesquisa jurídica, testadas em 2024 num estudo liderado por Stanford, alucinaram, cada uma, de 17% a 33% das vezes. O que é preciso construir é uma estrutura que torne a saída verificável, uma pessoa que decida e um conjunto de avaliação montado antes de tudo.

Fui engenheiro de IA no Kartez Contract; aqui está o que eu manteria desse trabalho e o que faria primeiro.

O que a base de casos de alucinação de IA mostra a quem desenvolve, e o que não mostra

A contagem de Charlotin passou de 2.000. Antes que alguém cite esse número num pitch ou num memorando de risco, três pontos importam.

Ela conta decisões, não erros. A base “não acompanha o universo (necessariamente mais amplo) de todas as citações falsas ou de todo uso de IA em peças processuais”. É um registro de falhas que chegaram a um juiz, não uma taxa de alucinação.

Ela não culpa ferramentas. Uma nota da própria base diz que a menção a uma ferramenta “não significa necessariamente que essa ferramenta tenha sido responsável pelas alucinações em questão”; por isso, nada neste texto associa uma decisão da base a uma ferramenta. As ferramentas citadas mais adiante vêm do estudo de Stanford, não da base.

As categorias importam mais que o total. Na base de Charlotin, 1.690 decisões estão classificadas como Fabricated (conteúdo fabricado), 854 como Misrepresented (conteúdo deturpado) e 548 como False Quotes (citações textuais falsas), e uma mesma decisão pode ter mais de uma classificação. Uma verificação de que a fonte citada existe detecta a maior parte do primeiro tipo, as fontes jurídicas inventadas. Essa verificação deixa passar os outros dois sempre que a fonte é real, mas o trecho transcrito foi inventado ou a leitura que se faz dele está errada. Uma ferramenta de contratos pode cometer os dois erros apontando para uma cláusula que existe.

Charlotin também lista 1.174 decisões em que quem usou IA foi uma parte que litigava pro se (em nome próprio, sem advogado) e 811 em que foi um advogado; portanto, uma ferramenta de IA jurídica não pode presumir que haja um advogado envolvido, nem que ele vá detectar os erros dela. Direito contratual (Contract), com 449 decisões, é a maior área jurídica dessa base. São disputas contratuais em que conteúdo alucinado por IA estava em discussão, não contratos redigidos por IA.

O RAG evita as alucinações da IA jurídica?

Não. O estudo de Stanford descrito abaixo conclui que a geração aumentada por recuperação (RAG) aplicada ao direito “pode reduzir as alucinações em comparação com sistemas de IA de uso geral (aqui, o GPT-4), mas as alucinações continuam substanciais, abrangentes e potencialmente insidiosas”. Insidiosas é a palavra certa: uma resposta mal fundamentada chega com uma fonte real anexada. O desenho geral dessas proteções está em guardrails contra alucinação em RAG.

O estudo liderado por Stanford: 17% a 33% de alucinação

Num artigo publicado no arXiv em 30 de maio de 2024, pesquisadores de Stanford e Yale relataram “a primeira avaliação empírica pré-registrada de ferramentas de pesquisa jurídica baseadas em IA”. Pré-registrada significa que o estudo e seu conjunto de mais de 200 consultas jurídicas foram registrados antes de a avaliação ser executada, uma salvaguarda contra a escolha de consultas que se encaixem nos resultados. Alguns fornecedores anunciavam que a recuperação “eliminava” ou “evitava” alucinações. O estudo constatou que Lexis+ AI, Westlaw AI-Assisted Research e Ask Practical Law AI alucinaram, cada uma, de 17% a 33% das vezes, e que “as alegações dos fornecedores são exageradas”.

A definição importa mais que a faixa. Uma resposta conta como alucinada “se for incorreta ou mal fundamentada” (misgrounded), e mal fundamentada significa que proposições-chave são “citadas, mas interpretam mal a fonte ou remetem a uma fonte inaplicável”. As ferramentas foram testadas em 2024, em pesquisa jurídica e não em contratos; portanto, a faixa não é um número que valha para a IA jurídica de hoje. A categoria, porém, vale para contratos: num contrato, uma resposta mal fundamentada soa certa e aponta para a cláusula errada.

A descoberta do Google sobre contexto suficiente: mais contexto, menos abstenções

O artigo “Sufficient Context” separa os erros em que o modelo usa mal um contexto bom dos erros em que o contexto nunca foi suficiente para responder. Os modelos maiores que o artigo testou, do Google, da OpenAI e da Anthropic, “muitas vezes produzem respostas incorretas em vez de se abster quando o contexto não é” suficiente.

O post do Google Research sobre o trabalho (14 de maio de 2025) diz que, embora o RAG “em geral melhore o desempenho global, ele paradoxalmente reduz a capacidade do modelo de se abster de responder quando isso é apropriado”. No exemplo do Google, o Gemma deu respostas incorretas em 10,2% das perguntas sem contexto e em 66,1% com contexto insuficiente.

A recuperação muda o que o modelo vê, não a capacidade dele de saber se o que viu basta. Uma pergunta sobre rescisão pode depender de uma definição ou de uma cláusula de notificação que nunca foi recuperada. O desenho do sistema precisa tornar “preciso de outra seção” uma saída normal, e a avaliação precisa testar isso.

Revisão de contratos com IA: as falhas que importam

Uma cláusula inventada se torna um risco jurídico para quem assina; por isso, um modelo que inventa uma cláusula é pior do que nenhum modelo. Estas são as falhas que eu trataria primeiro ao projetar o sistema. Nenhum dos padrões abaixo prova que uma resposta está certa; a maioria torna uma resposta errada detectável.

Falha

Num contrato

Padrão que a torna verificável

Conteúdo inventado

Uma cláusula ou um prazo que o documento não contém

Respostas baseadas em cláusulas selecionadas; o usuário aceita cada edição

Redação citada incorretamente

Uma correção que edita um texto que não está lá

Toda correção cita literalmente a redação atual

Resposta mal fundamentada

Uma resposta tirada da cláusula errada ou de uma seção nunca mostrada

Seleção de cláusulas; instrução para pedir as seções que faltam

Saída quebrada

Uma lista de riscos cortada exibida como se estivesse completa

Esquemas fixos, nunca exibidos em estado bruto; verificação de completude nas respostas reparadas (recomendada)

Edições parciais

Uma parte renomeada em apenas uma seção

Edições no contrato inteiro planejadas, aplicadas em todos os pontos e destacadas

Valores alterados

Uma quantia, uma data ou um nome modificado numa reescrita

Verificação literal de valores (recomendada mais abaixo)

Padrões de design de IA para contratos no Kartez Contract

De novembro de 2025 a julho de 2026, trabalhei como engenheiro de IA no Kartez Contract, um espaço de trabalho trilíngue para contratos, com escrita da direita para a esquerda, que reunia um assistente de elaboração, uma jornada de revisão e um estúdio de contratos. Reconstruí e ampliei o motor de IA por trás desses fluxos, partindo das primeiras cadeias básicas de IA do cliente, e construí o copiloto que classifica cada solicitação, encontra as cláusulas relevantes e planeja edições em todo o contrato.

Os problemas mais difíceis foram a recuperação e a ancoragem, e a ancoragem foi tratada com estrutura, não com confiança. Nenhum dos seis padrões abaixo é uma garantia medida; os quatro primeiros são as próprias restrições de ancoragem.

Respostas apenas a partir das cláusulas que o copiloto selecionou

O contrato do usuário era dividido segundo sua própria estrutura, incluindo os artigos, cláusulas e notas (ماده، بند، تبصره) que os contratos persas numeram à sua maneira. Só as seções relevantes para uma pergunta eram usadas para respondê-la, e o copiloto era instruído a avisar quando precisasse de seções que não lhe tinham sido mostradas.

A cláusula é uma unidade com a qual o advogado já trabalha; portanto, um conjunto de recuperação feito de cláusulas é algo que um avaliador consegue rotular e conferir. A instrução oferece uma alternativa ao palpite, mas não é uma trava imposta pelo sistema; o conjunto de avaliação precisa, portanto, de perguntas que as cláusulas selecionadas não conseguem responder. A recuperação em persa tem armadilhas próprias, tratadas para outro sistema em busca híbrida para RAG em persa.

Correções que citam o contrato literalmente

Cada correção sugerida precisava citar a redação atual palavra por palavra, para que pudesse ser localizada e substituída, e vinha com texto substituto pronto para uso. É essa exigência que torna possível a validação de citação exata: um programa pode confirmar que o texto citado existe antes de a correção ser aplicada.

Saber se uma reescrita é sensata é um julgamento jurídico. Saber se a frase que ela substitui existe é uma comparação de strings. A OWASP, em sua orientação sobre desinformação em LLMs, formula a regra geral: “validar automaticamente as saídas principais, especialmente as de ambientes de alto risco”. Se eu fosse construir de novo, descartaria qualquer correção cuja citação não fosse encontrada, nunca a aplicaria de forma aproximada e contaria os descartes como um alerta precoce.

Essas correções ficam na jornada de revisão, que não tinha sido totalmente testada quando o trabalho parou; por isso, o padrão se sustenta pela sua lógica, não por uma medição.

Esquemas de saída fixos, nunca exibidos em estado bruto

Toda análise retornava uma estrutura fixa, para que linhas do tempo, registros de riscos e correções fossem dispostos sempre da mesma forma. Uma resposta malformada passava por uma etapa de parsing e reparo em vários estágios, incluindo o reparo de respostas cortadas, e era solicitada de novo com mais espaço quando necessário. Nunca era mostrada ao usuário em estado bruto.

Isso ataca uma falha silenciosa: uma lista de riscos truncada parece completa para quem lê. O reparo, sozinho, não resolve, porque uma lista cortada, depois de fechada, continua passando no parsing; por isso, eu repetiria a solicitação ou sinalizaria a resposta truncada e reparada, em vez de exibi-la como inteira. O esquema também dá às demais verificações um lugar conhecido onde procurar.

Baixa aleatoriedade ao redigir

Na redação, o modelo rodava com baixa aleatoriedade. Isso traz repetibilidade, não exatidão: a mesma entrada tende a gerar a mesma minuta, de modo que as falhas podem ser reproduzidas e as execuções de avaliação, comparadas.

Fluxos guiados, não uma caixa de chat para tudo

Elaborar, revisar e editar são trabalhos diferentes, e cada um precisa do seu próprio fluxo guiado, não de uma única janela de conversa. A revisão, por exemplo, é escrita do ponto de vista do usuário; por isso, sua primeira etapa pergunta qual é o papel dele no negócio.

O texto “Building effective agents”, da Anthropic, usa “workflow” no sentido de orquestração: “sistemas em que LLMs e ferramentas são orquestrados por caminhos de código predefinidos”. Segundo o texto, os workflows “oferecem previsibilidade e consistência para tarefas bem definidas”. Cada etapa fixa tem um formato de entrada e de saída conhecido, que pode ser verificado. Uma caixa de chat em branco aceita qualquer coisa e devolve qualquer coisa.

Edições destacadas que o usuário aceita ou rejeita

A regra nos três fluxos era que a IA propõe e o usuário decide. As edições do copiloto eram destacadas no editor para que o usuário as aceitasse ou rejeitasse. Uma instrução para o contrato inteiro, como renomear uma das partes, era primeiro planejada, depois aplicada a todas as seções afetadas e destacada.

O usuário avalia mudanças marcadas em vez de reler o documento, e uma renomeação aparece destacada em todos os pontos em que foi aplicada, em vez de ser descoberta mais tarde como uma inconsistência.

Um sistema diferente: as travas do assistente deste site

Nada do que é descrito nesta seção fez parte do Kartez Contract. O assistente deste site, que eu construí e mantenho, responde apenas com base no conteúdo do próprio site, atrás de travas determinísticas.

Algumas perguntas são recusadas por correspondência de padrões antes que qualquer coisa seja recuperada: custos e disponibilidade, detalhes privados, especulação, ataques ao prompt de sistema e pedidos de tarefas, como escrever código ou traduzir um texto. Se uma pergunta não for sobre mim e nada do que foi recuperado ficar acima de um piso de pontuação de recuperação, o assistente recusa e o modelo nunca é chamado. Perguntas sobre mim também são reconhecidas por correspondência de padrões, a partir de indícios como meu nome ou um pronome de terceira pessoa, e não são recusadas só porque nenhum trecho ficou acima do piso. Em vez disso, o modelo recebe os registros do próprio site, entradas do currículo, dos estudos de caso, dos artigos e dos serviços, com a instrução de responder com um token fixo se eles não cobrirem a pergunta; o leitor então vê a mesma recusa. Enquanto a resposta chega em streaming, uma trava de frases confere cada frase completa antes de exibi-la:

  • Faixa de citação. Todo marcador de citação aponta para uma fonte que foi entregue ao modelo.

  • Citação obrigatória. Toda frase substantiva traz um marcador.

  • Respaldo dos valores. Todo número, URL e endereço de e-mail está presente em uma fonte que a frase cita.

  • Pessoa gramatical. Nenhuma frase usa pronomes de primeira pessoa (em inglês, I, me, we).

Uma única frase reprovada interrompe a resposta, e essa frase nunca é exibida. Os marcadores de citação são verificados e depois removidos, de modo que os leitores nunca os veem.

O mecanismo está em guardrails de LLM em streaming. A demo RAG vs. sem RAG transmite uma resposta real e fundamentada ao lado de uma coluna sem recuperação que fica vazia de propósito; pergunte algo que não seja sobre mim e que o site não cubra, e a execução para antes de chegar a qualquer modelo. Se eu estivesse construindo uma ferramenta de contratos, acrescentaria o mesmo tipo de verificação para quantias, datas e nomes das partes, exigindo que cada valor correspondesse à fonte palavra por palavra.

Como avaliar IA jurídica: construa primeiro o conjunto de avaliação

A ordem habitual é construir e depois medir. Para IA jurídica, eu inverteria essa ordem.

  1. Uma restrição de projeto é uma hipótese. “As correções devem citar o contrato literalmente” é uma regra. Com que frequência o modelo a quebra é um número, e só um conjunto de avaliação produz esse número.

  2. Toda mudança precisa de um teste de regressão. Sem um conjunto fixo, cada mudança de modelo, de prompt ou de recuperação é julgada por intuição.

  3. O conjunto sobrevive ao projeto. Um conjunto rotulado e sua última execução são evidências que outra pessoa pode usar. Uma lista de princípios de design não é.

O que aconteceu no Kartez Contract

O cliente interrompeu o projeto a um mês da conclusão, quando dificuldades financeiras ligadas à guerra cortaram o financiamento. Foi uma falha de financiamento do cliente, não uma falha de entrega. Até então, o assistente de elaboração, o estúdio de contratos com seu copiloto e a interface trilíngue estavam construídos e integrados de ponta a ponta. A jornada de revisão foi construída em todas as cinco etapas, mas não tinha sido totalmente testada e ainda estava em refinamento quando o trabalho parou.

Não existe nenhum número de acurácia, porque o projeto parou antes que um conjunto formal de avaliação fosse construído. As restrições de projeto eram reais; o número que as teria transformado numa afirmação nunca foi produzido.

Um conjunto de avaliação de IA para contratos, já na primeira semana

Isto é uma recomendação, não a descrição de algo que o Kartez Contract tinha. Cada item tem resultado binário: passa ou falha.

  • Perguntas com resposta no contrato, rotuladas com a cláusula correspondente. A resposta precisa estar certa e se basear nessa cláusula.

  • Perguntas que o contrato não responde. Espere “preciso da seção X” ou “o contrato não trata disso”, não uma resposta.

  • Pedidos de edição. Todo trecho citado numa correção proposta precisa ser encontrado, por comparação de strings, no documento de origem.

  • Edições no contrato inteiro. Renomear uma parte precisa mudar todas as ocorrências e nada mais.

  • Valores que não podem mudar. Quantias, datas, prazos de notificação e nomes das partes, comparados literalmente antes e depois de cada reescrita.

  • Saídas quebradas. Respostas truncadas e malformadas nunca devem chegar à tela em estado bruto, e uma resposta truncada e depois reparada nunca deve ser exibida como completa.

  • Estrutura persa. Numeração por ماده, بند e تبصره, linhas com direção mista e dígitos persas.

  • Os dois lados do negócio. O mesmo contrato revisado a partir da posição de cada parte.

Prazos do AI Act da UE após o Digital Omnibus: uma visão de engenharia

  • O Parlamento aprovou o texto final em 16 de junho de 2026, e o Conselho, em 29 de junho de 2026.

  • A marcação de conteúdo gerado por IA é exigida até 2 de dezembro de 2026 para sistemas colocados no mercado antes de 2 de agosto de 2026.

  • Os demais deveres de transparência do Artigo 50, como informar os usuários de que estão lidando com um sistema de IA, valem a partir de 2 de agosto de 2026.

  • As obrigações de alto risco do Anexo III para sistemas independentes (stand-alone) passam para 2 de dezembro de 2027. Para IA embutida em produtos abrangidos pela legislação de segurança do Anexo I, a data é 2 de agosto de 2028.

O enquadramento é uma questão para a assessoria jurídica. Nenhum dos padrões acima é uma medida de conformidade.

Checklist para construir ou comprar IA jurídica

  • Em que cada resposta se baseia? Numa cláusula ou numa seção, não “no documento”.

  • Cada edição pode ser localizada? Cada mudança cita o texto que substitui, conferido com o documento.

  • Ela consegue dizer que a resposta não está lá? Peça uma demonstração.

  • A saída é validada antes de ser exibida? Respostas quebradas são reparadas ou retidas.

  • Algo muda sem aceitação? Nada deveria mudar.

  • Há um fluxo para cada tarefa? Elaboração, revisão e edição não deveriam dividir a mesma caixa de chat.

  • Os valores são verificados literalmente? Quantias, datas e nomes das partes, comparados com a fonte.

  • Posso ver o conjunto de avaliação? O que há nele, quais itens testam a abstenção e quando ele rodou pela última vez.

Se você está definindo o escopo de um sistema de IA para contratos ou para a área jurídica, o Diagnóstico de projeto transforma cinco perguntas numa primeira arquitetura.

Perguntas frequentes

Quantos casos de alucinação de IA já chegaram aos tribunais?

Até 14 de setembro de 2026, a base AI Hallucination Cases, de Damien Charlotin, registrava 2.041 decisões de tribunais e outros órgãos julgadores sobre conteúdo alucinado por IA. Na maioria delas, um tribunal constatou, ou deu a entender, que uma parte se apoiou nesse conteúdo; excepcionalmente, também são incluídas algumas em que o uso de IA foi alegado, mas não confirmado. A base registra decisões, não toda citação falsa ou todo uso de IA em peças processuais.

O RAG reduz as alucinações na IA jurídica?

Reduz, mas não acaba com elas. Num estudo pré-registrado liderado por Stanford, três ferramentas de pesquisa jurídica baseadas em recuperação alucinaram menos que o GPT-4, mas, testadas em 2024, cada uma ainda alucinou de 17% a 33% das vezes. A pesquisa do Google sobre contexto suficiente constatou que modelos maiores muitas vezes respondem incorretamente em vez de se abster quando o contexto recuperado não basta.

A IA consegue revisar contratos de forma confiável?

Não se a ideia for simplesmente confiar nela. O que é possível construir é uma revisão que torne os erros verificáveis: respostas baseadas em cláusulas selecionadas, correções que citam o contrato literalmente, esquemas de saída fixos e uma pessoa que aceita ou rejeita cada mudança. Saber se uma ferramenta realmente detecta erros é uma questão de medição; portanto, peça o conjunto de avaliação dela.

O que é validação de citação exata?

É uma verificação de que o texto citado por uma correção proposta existe, palavra por palavra, no documento atual, antes de a correção ser aplicada. Ela depende de uma regra que obrigue toda correção a citar a redação que substitui, e transforma parte de uma edição jurídica numa comparação de strings.

Por que não há um número de acurácia para o Kartez Contract?

O cliente interrompeu o projeto a um mês da conclusão, por razões de financiamento ligadas à guerra, antes que um conjunto formal de avaliação fosse construído. Este site não estima números que não mediu. Essa lacuna é o motivo pelo qual este artigo defende construir o conjunto de avaliação primeiro.

Fontes