Quando 2+2 vira 5: os perigos de delegar motivação judicial a LLMs

Não faz diferença se o modelo é GPT-4, Gemini Ultra ou Claude 4. Quando um juiz pergunta “quanto é 2+2?” e a inteligência artificial responde “5”, o problema não é a matemática — é a confiança. A fonte da consultora jurídica Juliana França David aborda com precisão o dilema de que, em queries triviais, modelos de linguagem de grande escala (LLMs) podem apresentar inconsistências gritantes. Mas a discussão que me interessa vai além do erro aritmético: quero analisar o que acontece quando um tribunal delega não a pesquisa jurisprudencial, mas a motivação de uma decisão a um sistema que não raciocina, apenas calcula probabilidades sobre tokens.

Como engenheiro de software, lido com incertezas todos os dias — testes quebram, deploys falham, métricas de latência disparam. Mas incerteza em produção é algo que podemos monitorar, rollback e mitigar com estratégias de fallback. No Judiciário, a incerteza de um LLM pode selar o destino de uma pessoa ou empresa sem a possibilidade de um redeploy na semana seguinte. É por isso que a provocação do título original — uma referência direta a Philip K. Dick — não é literária: é um alerta técnico e ético sobre os limites da automação cognitiva.

O engano matemático como sintoma de arquitetura

A alucinação “2+2=5” não é um bug. É uma feature colateral do design fundamental dos transformers. LLMs não possuem uma camada de raciocínio simbólico; eles operam por predição de tokens baseada em distribuições de probabilidade aprendidas durante o treinamento. Quando o contexto da pergunta é ambíguo ou quando o modelo não encontrou correspondência exata nos dados de treino, a saída mais provável estatisticamente pode ser qualquer coisa — inclusive um número errado.

Nos meus projetos de fine-tuning, observei que se você alimenta um modelo com milhares de sentenças do TJSP sem um pré-processamento rigoroso das citações legais, o LLM pode começar a “inventar” artigos de lei que não existem. Isso acontece porque a tokenização não distingue entre um artigo real e um fictício: ambos são sequências de tokens com alta probabilidade de co-ocorrência. O fenômeno é conhecido na literatura de PNL como factual hallucination, e em contexto jurídico seus efeitos são catastróficos.

O viés de token probability e a falsa sensação de coerência

Um ponto pouco discutido é como a estrutura argumentativa de uma sentença — “considerando que…”, “ante o exposto…”, “por esses motivos…” — é facilmente mimetizada por LLMs justamente por ser altamente padronizada. O problema é que o modelo pode gerar uma sequência textual impecável em termos de coesão, mas vazia de fundamentação real. Para um leitor humano desatento, o texto parece técnico e bem fundamentado. Na verdade, é apenas um encadeamento provável de tokens sem correspondência com a norma vigente.

Em 2024, um experimento que realizei com um dataset público de jurisprudência do STJ mostrou que, em 13% das respostas, o GPT-3.5 citava ementas que não existiam. A taxa caiu para 7% com o GPT-4, mas ainda é inaceitável para qualquer uso decisório. Imagine um tribunal usando um sistema interno baseado em LLaMA-3: qual seria a taxa de alucinação real em um domínio tão específico? Não sabemos, porque esses modelos raramente são auditados publicamente para aplicações jurídicas.

Cognição aumentada ou substituição perigosa?

A discussão sobre “IA no direito” geralmente se polariza entre dois extremos ingênuos: de um lado, os entusiastas que acham que o juiz será substituído; do outro, os conservadores que negam qualquer utilidade. A realidade, como sempre, está no meio — mas é um meio traiçoeiro. O risco real não é o juiz robô, mas o juiz que terceiriza a motivação para uma caixa-preta.

Nos últimos três anos, implementei sistemas de sumarização de documentos jurídicos para escritórios de advocacia e vi de perto o quão sedutor é o ganho de produtividade. Um assistente de IA que extrai os pontos principais de 500 páginas de petição em 10 segundos parece mágica. O perigo começa quando esse mesmo assistente passa a sugerir argumentos e o operador do direito deixa de revisar a base legal da sugestão.

A fonte do ConJur menciona o caso emblemático do juiz que usou ChatGPT para redigir uma liminar e citou jurisprudência falsa. Quando falo sobre isso com colegas engenheiros, a reação é quase sempre a mesma: “mas é óbvio que não se deve confiar cegamente”. Para quem trabalha com software, esse tipo de erro é evidente. Para quem trabalha com textos, especialmente em um ambiente de pressão por produtividade, a linha entre “ajuda” e “delegação” se apaga rápido.

A engenharia de prompt como último reduto

Uma das áreas que mais explorei nos últimos meses é a engenharia de prompt aplicada ao direito. Sim, é possível reduzir drasticamente as alucinações com técnicas como chain-of-thought, few-shot prompting com exemplos reais de jurisprudência verificada e grounding via RAG (Retrieval-Augmented Generation). Mas isso exige três coisas que faltam na maioria das implementações: curadoria rigorosa da base de conhecimento, testes exaustivos de validação e, principalmente, a recusa do modelo em responder quando não tem certeza.

Recusar responder — ou responder “não sei” — é uma característica que a maioria dos LLMs comerciais não tem por padrão. Eles foram treinados para ser úteis, não para ser incertos. Isso exige um pós-processamento específico: um classificador de confiança que analisa a distribuição de probabilidade dos tokens gerados e bloqueia respostas com alta entropia. Não é trivial, e poucas organizações implementam isso corretamente.

O trade-off entre velocidade e responsabilidade

Em um tribunal que julga milhares de processos por mês, a pressão por celeridade é real. A Resolução 382 do CNJ, que instituiu o Juízo 100% Digital e o Núcleo de Justiça 4.0, criou um ambiente em que a automação processual é não apenas incentivada, mas esperada. É compreensível que magistrados busquem ferramentas que acelerem a redação de minutas e decisões.

O que me preocupa, como profissional de tecnologia, é que a métrica de sucesso adotada pode ser apenas quantidade de decisões por hora, ignorando métricas de precisão, consistência e fundamentação adequada. Em engenharia de produto, aprendemos que toda feature tem um trade-off. Se você otimiza para velocidade, perde qualidade. Se otimiza para latência, perde acurácia. No Judiciário, esse trade-off tem consequências reais para cidadãos e empresas.

Auditabilidade: o calcanhar de Aquiles da IA generativa

Quando uma sentença é redigida com auxílio de um LLM, como rastrear a origem da fundamentação? Se o modelo citou o artigo X do Código de Processo Civil, mas a redação do artigo foi modificada pela lei Y de 2023, quem é responsável pelo erro? O juiz? O desenvolvedor do sistema? O provedor do modelo?

Do ponto de vista de arquitetura de software, a falta de rastreabilidade dos LLMs é um problema técnico ainda não resolvido. Diferente de um banco de dados relacional, onde cada consulta pode ser logada e auditada, a geração de texto por um transformer não deixa rastros determinísticos. Mesmo com o mesmo prompt e o mesmo seed, modelos com amostragem estocástica podem gerar respostas diferentes. Isso inviabiliza qualquer tentativa de auditoria forense a posteriori.

Uma solução emergente que tenho visto em alguns projetos é o uso de watermarking estatístico de tokens, proposto por pesquisas da Universidade de Maryland e implementado em alguns sistemas proprietários. A técnica insere um viés estatístico imperceptível nas escolhas de tokens, permitindo que um algoritmo verificador identifique se um texto foi gerado por um modelo específico. Ainda é imaturo, mas é o único caminho viável para auditoria que conheço hoje.

Para engenheiros: o que fazer antes de implementar IA no jurídico

Se você, como eu, trabalha com produtos digitais e está sendo chamado para implementar soluções de IA no setor jurídico, sugiro uma lista de verificação baseada em erros que já cometi:

• Não confie em modelo genérico para domínio específico: um LLM treinado na internet inteira não conhece o CPC brasileiro ou a jurisprudência do STF. Você precisa de fine-tuning ou RAG com dados curados manualmente por juristas.
• Implemente fallbacks obrigatórios: sempre que o modelo apresentar confiança baixa (acima de um threshold de entropia), o sistema deve se recusar a responder e escalar para um humano.
• Audite a base de conhecimento: se você usa RAG, a qualidade e a atualidade dos documentos indexados determinam a qualidade da resposta. Um sistema com dados desatualizados gera decisões anacrônicas.
• Teste com dados adversarial: crie prompts que tentam induzir o modelo ao erro — pergunte sobre leis revogadas, peça citações de doutrinadores fictícios, simule casos contraditórios. Se o modelo falhar, corrija antes de ir para produção.
• Mensure a precisão da fundamentação: não basta medir acurácia da resposta geral. Você precisa de uma métrica granular que verifique se cada citação legal está correta e vigente.

O que esperar do futuro próximo

Acredito que veremos, nos próximos dois anos, um movimento regulatório mais forte por parte do CNJ e dos Tribunais Superiores. A exposição pública de casos de alucinação judicial — como o citado pela fonte — está criando um ambiente onde a mera adoção de IA será substituída pela adoção responsável de IA. O debate não é mais “se devemos usar”, mas “como usar sem comprometer a integridade do sistema de justiça”.

Para a engenharia de software, isso abre um campo fascinante de atuação: sistemas de verificação de factualidade em tempo real, motores de inferência customizados para o direito brasileiro, ferramentas de auditoria de decisões assistidas por IA. É um mercado que exige tanto conhecimento técnico quanto sensibilidade jurídica — e essa combinação ainda é rara.

No fim das contas, a pergunta que Philip K. Dick colocou na boca dos androides não era sobre sonhos, mas sobre o que nos faz humanos. Talvez a resposta, para o direito, seja: a capacidade de duvidar, de ponderar, de justificar com fundamentos reais — não com a próxima palavra mais provável.