A IA Que Inventou um Caso Judicial — E a Arquitetura Que Construímos para Tornar Isso Impossível

Lembro-me do momento exato em que deixei de confiar na maneira como a maioria das pessoas constrói IA jurídica.

Era tarde de uma terça-feira, e eu estava lendo a transcrição do processo de Mata v. Avianca. Não um resumo. Não uma sequência de tuítes. A petição de verdade. Um advogado havia protocolado uma peça citando Varghese v. China Southern Airlines, Shaboon v. Egyptair, e Petersen v. Iran Air — completos com números de processo, datas e trechos de decisões citados. Convincentes o suficiente para que a parte contrária tivesse que ir atrás deles. Os casos não existiam. O ChatGPT os havia inventado. E quando o advogado voltou ao ChatGPT para conferir, o modelo alegremente confirmou suas próprias fabricações: "Sim, esses casos de fato existem e podem ser encontrados em bases de dados jurídicas confiáveis."

Larguei a transcrição e pensei: isto não é um problema de prompt. É um problema de arquitetura. E a maior parte do setor de IA jurídica finge que não.

Aquele incidente — que resultou em uma multa de US$ 5.000, uma reprimenda judicial e uma cratera reputacional — tornou-se o estudo de caso fundador daquilo que minha equipe na Veriprajna constrói hoje: sistemas de GraphRAG com Citação Imposta para IA jurídica. Sistemas em que a IA fisicamente não consegue produzir a citação de um caso que não corresponda a um registro verificado em um Grafo de Conhecimento. Não "provavelmente não vai." Não consegue.

Quero explicar por que essa distinção importa, o que foi preciso para construí-la, e por que acredito que a era de colocar uma interface de chatbot sobre um modelo de fundação e chamar isso de "IA jurídica" acabou.

Por Que o ChatGPT Inventou um Caso Judicial?

Esta é a pergunta que todos fazem, e que quase ninguém responde corretamente.

A explicação comum é "alucinação" — uma palavra que se tornou tão banalizada que perdeu seu valor diagnóstico. O que realmente aconteceu em Mata v. Avianca é mais específico e mais grave. Pediram ao modelo que encontrasse precedentes sobre a responsabilidade de companhias aéreas por lesões a passageiros. Ele não pesquisou em uma base de dados. Ele não tem uma. Ele previu a próxima sequência de palavras estatisticamente mais provável.

"Varghese" é um nome de autor plausível. "China Southern Airlines" é uma ré plausível. Um número de processo como "2017 WL 3245891" segue o padrão sintático de citações reais. O modelo montou esses fragmentos da mesma forma que monta um poema ou um e-mail de marketing — minimizando algo chamado perplexidade, que é essencialmente uma medida de quão "surpreso" o modelo fica com sua própria saída. Pouca surpresa equivale a texto fluente. Texto fluente não é o mesmo que texto verdadeiro.

O modelo é treinado para minimizar a perplexidade — o quanto ele se surpreende com a próxima palavra. Ele não é treinado para otimizar a proveniência — se aquela palavra remonta a algo real.

Esta é a tensão central. Os LLMs otimizam a coerência. O Direito exige proveniência. São objetivos fundamentalmente diferentes, e nenhuma dose de engenharia de prompt supera essa lacuna. Você pode dizer ao GPT-4: "Você é um advogado cuidadoso, cite apenas casos reais." Ele vai concordar e obedecer — até o momento em que seus dados de treinamento não contêm o caso de que você precisa, ponto em que ele vai inventar um que soa certo, porque soar certo é literalmente aquilo para o qual ele foi otimizado.

Pesquisadores de Stanford testaram isso com rigor. Chatbots de uso geral, mesmo aqueles com acesso à internet ou capacidades básicas de recuperação, alucinaram entre 58% e 82% das vezes em consultas jurídicas complexas. Não casos extremos. Perguntas rotineiras de pesquisa jurídica.

A Armadilha do Wrapper

Depois de Mata, comecei a catalogar as ferramentas de IA jurídica no mercado. A maioria delas era o que o setor educadamente chama de "wrappers" — interfaces de usuário superficiais montadas sobre a API da OpenAI ou da Anthropic. Um prompt de sistema dizendo "Você é um assistente jurídico prestativo." Talvez um recurso de upload de PDF. Talvez uma fonte mais bonita.

Tive uma ligação com uma potencial cliente — a diretora jurídica de um escritório de médio porte — que me contou que eles vinham avaliando uma dessas ferramentas. "É rápida", ela disse. "Mas semana passada ela citou um voto vencido como se fosse o entendimento. Meu associado quase protocolou isso." Ela fez uma pausa. "A parte assustadora é que o caso era real. Só o entendimento estava... errado."

É isso que as alucinações jurídicas têm de tirar meu sono. Mata foi dramático porque os casos eram inteiramente fabricados. Mas os erros mais sutis — caso real, entendimento errado; lei válida, mas revogada; precedente vinculante da jurisdição errada — são mais difíceis de detectar e, sem dúvida, mais perigosos. Um caso falso é sinalizado logo na primeira etapa de verificação. Um caso real citado para um entendimento que ele não sustenta? Isso pode sobreviver a várias rodadas de revisão.

A abordagem de wrapper não consegue resolver isso porque não é dona da camada de dados. Ela não sabe quais casos existem. Não sabe quais foram superados. Não entende que uma decisão do Segundo Circuito não vincula um tribunal do Nono Circuito. É uma caixa de texto sofisticada conectada a um mecanismo de probabilidade.

E a economia é brutal. A análise do mercado de wrappers mostra que, embora alguns alcancem receita rapidamente, a grande maioria fracassa porque não tem qualquer tecnologia defensável. À medida que os modelos de fundação melhoram, cada recurso que tornava o wrapper útil — resumo, redação, perguntas e respostas — é absorvido pelo modelo base. Você está construindo em terreno alugado, e o dono é a OpenAI.

O Que Acontece Quando Você Dá à IA um Mapa do Direito?

É aqui que começa a obsessão da minha equipe.

A correção padrão para a alucinação é a Geração Aumentada por Recuperação — RAG. Em vez de depender da memória do modelo, você recupera documentos relevantes de uma base de dados e os fornece como contexto. É uma melhoria de verdade. Mas para o Direito não basta, e quero explicar por quê com um exemplo específico que nos deixou malucos por semanas.

Estávamos testando um pipeline padrão de RAG vetorial em uma pergunta sobre se uma determinada regulação ambiental de 1990 ainda era exigível após uma decisão da Suprema Corte de 2023. O RAG vetorial fez o que faz: encontrou trechos de texto semanticamente similares à consulta. Retornou a regulação. Retornou a decisão da Suprema Corte. Retornou um artigo de revista jurídica que discutia ambos.

O LLM costurou tudo isso em uma resposta confiante e bem escrita que estava completamente errada. Ele tratou o artigo da revista jurídica — um comentário acadêmico persuasivo, mas não vinculante — como se tivesse o mesmo peso da decisão da Suprema Corte. Pior, ele não percebeu que a regulação havia sido efetivamente invalidada, porque a cadeia de autoridade que ligava a regulação à decisão invalidadora passava por um caso intermediário de apelação que a busca vetorial não havia recuperado. A conexão não era semântica. Era estrutural.

Lembro da minha engenheira-chefe, no meio da depuração disso, virando para mim e dizendo: "O problema não é a recuperação. O problema é que os vetores não entendem relações."

Ela tinha razão. E essa é a ideia por trás do GraphRAG — Geração Aumentada por Recuperação Baseada em Grafos.

Em vez de armazenar documentos jurídicos como pontos isolados no espaço vetorial, nós os mapeamos em um Grafo de Conhecimento: uma rede em que cada lei, caso, regulação e doutrina jurídica é um nó, e as relações entre eles — cita, supera, distingue, interpreta, confirma — são arestas explícitas e rotuladas. Escrevi sobre a arquitetura completa na versão interativa da nossa pesquisa.

O RAG vetorial pergunta: "Encontre um texto que se pareça com esta consulta." O GraphRAG pergunta: "Encontre a lei, percorra a aresta 'interpreta' para achar a jurisprudência, e então percorra a aresta 'supera' para garantir que ela ainda é válida."

Essa não é uma diferença sutil. É a diferença entre pesquisar uma biblioteca pela intuição e pesquisá-la pelo fichário, pelo índice de citações e pelo relatório Shepard's ao mesmo tempo.

Como Você Impede uma IA de Inventar uma Citação?

Esta é a parte que mais demorou para acertarmos, e é a parte da qual mais me orgulho.

Ter um Grafo de Conhecimento é necessário, mas não suficiente. O grafo lhe dá estrutura. Mas o LLM ainda está gerando texto token por token, e a qualquer momento pode desviar do grafo e começar a inventar. Precisávamos de um mecanismo que não apenas incentive o modelo a citar casos reais — ele impede fisicamente que ele cite casos falsos.

Chamamos isso de Decodificação Restrita por Grafo, e o mecanismo central é algo chamado KG-Trie.

Veja como funciona em português simples. Pegamos cada entidade válida do nosso Grafo de Conhecimento — cada nome de caso, cada citação de repositório, cada número de processo — e construímos uma árvore de prefixos (uma Trie) a partir desses identificadores. Quando o LLM está gerando texto e chega a um ponto em que está prestes a produzir uma citação, o mecanismo de restrição é ativado. Ele verifica: quais são os próximos tokens válidos de acordo com a Trie?

Se o modelo gerou "Mata v. A" — a Trie permite tokens que completem nomes de casos válidos que comecem com essa sequência. "Avianca" é válido. Todo o resto tem sua probabilidade definida como infinito negativo. Bloqueado.

Se o modelo tenta gerar "Varghese v. Chi" — a Trie não encontra continuação válida. A geração é interrompida. O modelo é forçado a retroceder e ou encontrar uma citação real ou produzir algo como "Nenhum precedente encontrado."

A IA não consegue sonhar com um caso porque fisicamente não consegue produzir a sequência de tokens de um caso que não esteja na base de dados verificada.

Esta é uma garantia estrutural, não probabilística. Não estamos dizendo "o modelo tem 95% menos probabilidade de alucinar." Estamos dizendo que o caminho da fabricação está fechado. A sequência de tokens de uma citação falsa literalmente não pode ser produzida.

Agora, quero ser preciso sobre o que isso faz e não faz. Isso impede a fabricação — inventar um caso que não existe. Não impede a má interpretação — citar um caso real, mas extrair dele a conclusão errada. Isso é um erro de raciocínio, e ainda exige revisão humana. Mas eliminar a fabricação é enorme. Tira de cena, por completo, o modo de falha mais catastrófico — o cenário Mata.

Houve uma noite, no início do desenvolvimento, em que rodamos nosso primeiro teste de ponta a ponta. Alimentamos o sistema com a consulta exata que havia produzido as citações falsas em Mata. O sistema restrito tentou gerar "Varghese," bateu na parede da Trie, retrocedeu e retornou um caso real com uma cadeia de citações válida. Minha engenheira mandou uma captura de tela para o nosso grupo às 1h47 da madrugada. Ninguém respondeu com palavras. Só uma fileira de emojis de fogo.

Por Que os Wrappers Não Conseguem Fazer Isso?

As pessoas me perguntam isso o tempo todo, e a resposta é arquitetural, não comercial.

A Decodificação Restrita por Grafo exige manipular as probabilidades de token do modelo — seus logits — em tempo real durante a geração. Você precisa de acesso ao mecanismo de inferência no nível da decodificação. APIs comerciais padrão como a do GPT-4 não expõem isso. Você pode enviar um prompt e receber uma resposta. Você não pode interceptar o processo de geração no meio de um token e injetar restrições.

É por isso que construímos sobre modelos de pesos abertos — Llama, Mistral — ou implantamos por meio de endpoints corporativos que permitem laços de decodificação personalizados. Nós hospedamos o modelo. Nós controlamos o pipeline de inferência. Injetamos as restrições da KG-Trie diretamente na distribuição de probabilidade de cada token à medida que ele é gerado.

Um wrapper, por definição, não consegue fazer isso. Ele está chamando a API de outra pessoa. Ele é um passageiro, não o piloto.

A Parte Mais Difícil Sobre a Qual Ninguém Fala

Construir o mecanismo de restrição foi intelectualmente satisfatório. Construir o Grafo de Conhecimento por baixo dele foi um esforço penoso.

O texto jurídico é bagunçado de maneiras que fariam um engenheiro de dados chorar. Um único caso pode ser referenciado como "Mata v. Avianca," "Mata," "678 F. Supp. 3d 443," "o caso Avianca," ou simplesmente "Id." — uma abreviação de duas letras que significa "o caso que acabei de mencionar." Tudo isso precisa resolver para um único nó canônico no grafo. Perca um, e você terá uma lacuna na rede de citações.

Passamos meses construindo pipelines de Resolução de Entidades que lidam com deduplicação ("Smith v. Jones, 123 F.3d 456" e "Smith, 123 F.3d at 456" são o mesmo caso), desambiguação ("Smith v. Jones (1995)" versus "Smith v. Jones (2002)" — casos diferentes, mesmo nome), e o inferno particular de resolver referências "Id." usando análise de contexto por janela deslizante.

E então há o tratamento negativo — o sistema de "bandeira vermelha." Um Grafo de Conhecimento jurídico que trata casos superados como autoridade válida é pior do que inútil. Nós ingerimos sinais de citador — expressões como "reformado," "revogado," "superado" — e os codificamos como arestas de bloqueio no grafo. Quando o sistema percorre um caminho e encontra uma aresta OVERRULES, esse caminho é invalidado como autoridade vinculante. Se alguém pergunta sobre Roe v. Wade a respeito de direitos reprodutivos, o grafo imediatamente traz à tona a aresta OVERRULES de Dobbs v. Jackson. Uma busca vetorial ainda poderia, entusiasticamente, citar Roe porque o mero volume de texto histórico que o apoia domina os escores de similaridade.

Para o detalhamento técnico completo do esquema do grafo, do pipeline de resolução de entidades e da arquitetura de restrição, veja nosso artigo de pesquisa.

O Que Isso Realmente Significa para um Escritório de Advocacia?

Tive uma conversa com um sócio-gerente que colocou a coisa de forma direta: "Não ligo para Grafos de Conhecimento. Ligo para saber se meus associados vão me envergonhar diante de um juiz."

Justo. Então deixe-me traduzir.

O custo de Mata v. Avianca não foi de US$ 5.000. Foi a humilhação pública, a exigência de notificar o cliente, a exposição a processos por má prática e o sinal, para todo cliente em potencial, de que este escritório não verifica seu trabalho. Para um grande escritório, uma única petição alucinada é um evento reputacional existencial.

O GraphRAG com Citação Imposta funciona como uma apólice de seguro contra a fabricação. A abordagem de wrapper oferece baixo custo inicial e responsabilidade ilimitada. Nossa abordagem exige investimento real na camada de dados e na arquitetura de restrição, mas reduz a zero o risco de fabricação de citações.

Há também um argumento de eficiência que é menos óbvio. Hoje, se um escritório usa IA para pesquisa, um associado tem que verificar cada uma das citações. Essa etapa de verificação muitas vezes leva mais tempo do que a própria pesquisa, o que anula o propósito. Os benchmarks de GraphRAG mostram uma melhoria de 30% a 35% em relação ao RAG padrão em tarefas de raciocínio multissalto — o tipo de pesquisa complexa, de ligar os pontos, que realmente importa em litígios. Mais importante, porque as citações têm sua validade estruturalmente garantida, o papel humano muda de "verificador de fatos" para "revisor de estratégia." Você não gasta três horas confirmando que os casos existem. Você gasta esse tempo avaliando se o argumento é persuasivo.

Quando cada citação é estruturalmente verificada, o trabalho do advogado deixa de ser conferir os fatos da IA e passa a ser pensar em estratégia. É aí que está a verdadeira alavancagem.

E há uma dimensão de transparência que importa para a conformidade. Um wrapper não consegue explicar por que escolheu um caso. Um sistema de GraphRAG consegue mostrar o caminho exato percorrido: "Selecionei o Caso A porque ele interpreta a Lei B e foi confirmado pelo Tribunal C, que é vinculante na sua jurisdição." Essa trilha de auditoria não é apenas um diferencial desejável — está se tornando uma expectativa regulatória.

Para Onde Isso Vai Agora?

O setor está migrando de chatbots para agentes — sistemas de IA que não apenas respondem perguntas, mas planejam e executam tarefas de múltiplas etapas. Um agente jurídico ao qual se pede que redija uma petição de indeferimento precisa pesquisar o padrão aplicável, encontrar jurisprudência de apoio, verificar se os casos ainda são bons precedentes, checar requisitos processuais e montar o argumento.

Um agente que roda sobre busca vetorial não tem mapa. Tem uma pilha de documentos e um bom palpite. Um agente que roda sobre um Grafo de Conhecimento tem uma estrutura explícita que pode percorrer: lei → casos interpretativos → regras processuais → requisitos específicos da jurisdição. O grafo é a camada de planejamento do agente.

É por isso que acredito que o investimento em infraestrutura de grafos agora rende retornos compostos depois. Os wrappers deixam para trás registros de conversas. Os Grafos de Conhecimento deixam para trás um mapa estruturado, crescente e cada vez mais valioso da autoridade jurídica, que fica mais útil a cada caso adicionado, cada relação codificada, cada sinal de tratamento negativo ingerido.

A Objeção Honesta

As pessoas contestam por dois flancos, e quero abordar ambos diretamente.

Primeiro: "Isso não é só o Westlaw com etapas extras?" Não. O Westlaw é um mecanismo de busca para humanos. Ele retorna documentos que um advogado lê e interpreta. O que nós construímos é uma arquitetura de restrição para IA — um sistema que governa o que a IA pode e não pode dizer. O Westlaw ajuda advogados a encontrar o Direito. O GraphRAG impede a IA de inventá-lo. Eles são complementares, não concorrentes.

Segundo: "Você não pode simplesmente fazer o ajuste fino do modelo para parar de alucinar?" Nós tentamos. No início do nosso trabalho, experimentamos ajuste fino com conjuntos de dados jurídicos verificados. Isso reduziu as taxas de alucinação. Não as eliminou. Um modelo com ajuste fino ainda é um mecanismo de probabilidade. É um mecanismo de probabilidade melhor, mas "melhor" em citação jurídica significa "errado com menos frequência," e "errado com menos frequência" não é um padrão que qualquer tribunal vá aceitar. A única maneira de garantir zero fabricação é tornar a fabricação estruturalmente impossível, o que significa restringir o espaço de saída, não apenas melhorar os dados de entrada.

O Fim do "Bom o Suficiente"

Eis aquilo a que sempre volto. A profissão jurídica se assenta sobre uma premissa simples: quando você cita uma autoridade, essa autoridade tem que ser real. Não provavelmente real. Não geralmente real. Real.

Por dois anos depois de Mata, os tribunais vêm intensificando as sanções, emitindo ordens permanentes sobre a divulgação do uso de IA e deixando claro que "a IA que fez" não é defesa. A profissão está traçando um limite: se você usa IA, sua saída tem que ser verificada. E se verificar a saída leva mais tempo do que fazer o trabalho manualmente, a IA não é uma ferramenta — é um passivo.

A era dos wrappers resolveu o problema errado. Ela tornou a pesquisa jurídica mais rápida. O que ela precisava era tornar a pesquisa jurídica confiável. Velocidade sem confiança é apenas má prática eficiente.

O que construímos na Veriprajna não é um chatbot que por acaso conhece um pouco de Direito. É um sistema de raciocínio restrito em que cada citação é uma travessia verificada por um Grafo de Conhecimento, cada relação é explícita e auditável, e o modelo generativo é fisicamente impedido de cruzar para a ficção.

A profissão que inventou o conceito de precedente vinculante merece uma IA que de fato o respeite.