IA jurídica na prática: como classificar petições com LLM local

Quando vi a notícia de que a Stanford escolheu três advogados brasileiros para pesquisar o impacto da IA no Judiciário, meu primeiro instinto foi abrir o terminal e pensar: o que isso significa na prática para quem constrói software? Porque o Brasil não é só o “maior mercado jurídico do mundo” — é também um dos maiores campos de teste do planeta para sistemas de PLN (Processamento de Linguagem Natural) sobre documentação jurídica em português. Segundo o Terra.com.br, Bruno Feigelson, Daniel Marques e Tayná Carneiro vão trabalhar dentro do Center for Legal Informatics (CodeX) da Stanford Law School, e isso abre uma janela rara: vamos exportar referência técnica, não só consumir.

Por que o Brasil virou caso de estudo para IA jurídica

Na minha experiência lidando com datasets jurídicos brasileiros, o que mais impressiona não é o volume — são as inconsistências. São 80 milhões de processos em tramitação, 1,3 milhão de advogados e a maior concentração de cursos de direito do planeta. Isso significa um corpus gigante, bagunçado, com jurisdições sobrepostas, linguagem técnica regional e petições que variam do latim formal ao “português de WhatsApp”.

Para um engenheiro de machine learning, isso é ouro. Modelos treinados em petições brasileiras generalizam mal se você não tratar:

• Variação entre justiça estadual, federal e trabalhista
• Siglas locais (TJSP, TJRJ, JFPR, TRT2…)
• Classes processuais com nomenclatura idêntica mas semânticas distintas
• Documentos digitalizados via OCR com erro humano embutido

Quando Feigelson diz que “o que acontecer no Brasil provavelmente vai influenciar outros países”, no fundo ele está reconhecendo que esse é um dos cenários mais complexos para testar agentes de IA. Quem resolver isso aqui, resolve em qualquer lugar.

O ângulo técnico que a maioria dos artigos ignora

Quase ninguém comenta, mas o CodeX da Stanford é o berço de tecnologias como o Brief Analyzer e ferramentas de predição de resultados judiciais baseadas em grafos de conhecimento. O que esses três advogados brasileiros vão conseguir fazer depende menos de diploma e mais de acesso a:

• Datasets rotulados de jurisprudência (STF, STJ, TRFs)
• Infraestrutura de LLM dedicada a domínio jurídico
• Validação empírica com stakeholders reais (juízes, advogados, partes)

Para nós, devs, a pergunta prática é: como reproduzir parte desse trabalho localmente, com modelos abertos, sem precisar de uma bolsa em Stanford?

Na Prática: montando um classificador de petições iniciais com LLM local

Deixa eu te mostrar um pipeline mínimo que eu uso quando preciso triar petições para um cliente de legal tech. É um classificador de área do direito (cível, trabalhista, criminal, previdenciário) usando embedding + classificador leve. Roda em CPU e serve como base.

# pip install sentence-transformers scikit-learn numpy
from sentence_transformers import SentenceTransformer
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report
import numpy as np

# 1. Embeddings multilíngues (modelo leve, roda em CPU)
model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2')

# 2. Dataset fictício - substitua por petições reais (anonimizadas!)
peticoes = [
    "Reclamação trabalhista por horas extras não pagas",
    "Ação de cobrança de cheque sem fundo",
    "Pedido de aposentadoria por invalidez junto ao INSS",
    "Denúncia por apropriação indébita qualificada",
    "Horas extras e adicional noturno não pagos",
    "Indenização por danos morais em acidente de trânsito",
    "Revisão de benefício previdenciário negado",
    "Estelionato praticado contra pessoa idosa",
]
labels = ["trabalhista", "cível", "previdenciário", "criminal",
          "trabalhista", "cível", "previdenciário", "criminal"]

# 3. Vetorização
X = model.encode(peticoes, normalize_embeddings=True)
y = np.array(labels)

# 4. Hold-out simples
X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.25, random_state=42, stratify=y
)

clf = LogisticRegression(max_iter=1000)
clf.fit(X_train, y_train)

# 5. Inferência em petição nova
nova_peticao = ["Reclamação por adicional de insalubridade e periculosidade"]
embedding = model.encode(nova_peticao, normalize_embeddings=True)
pred = clf.predict(embedding)
print(f"Área prevista: {pred[0]}")
# Saída esperada: Área prevista: trabalhista

Esse é o esqueleto. Em produção eu troco o MiniLM por um modelo treinado em domínio jurídico (ex.: BERTikal, available no Hugging Face) e adiciono um passo de sumarização extractiva antes do embedding, para não estourar o limite de tokens em petições de 50 páginas.

Por que esse padrão funciona melhor que prompt mágico

Tem um erro clássico que eu vejo em times de legal tech: chamar a API da OpenAI para classificar cada petição individualmente. Custou caro no primeiro mês, voltou impreciso no segundo. Embedding + classificador supervisionado barato é mais barato, mais auditável e tem latência de milissegundos — não de segundos.

Comparando abordagens: o trade-off real

A escolha depende do caso. Para triagem massiva, embedding + classificador. Para análise jurídica com argumentação, RAG com citações obrigatórias. Para resumo executivo, LLM local com guardrails. Misturar os três é o padrão sênior.

Erros comuns que eu já vi em projetos de IA jurídica

1. Treinar modelo em petições sem anonimizar

Petições têm CPF, RG, endereço, nome de filhos. Rodar embedding em texto com PII vaza informação via vetor. Solução: regex + NER (spaCy pt_core_news_lg) antes de qualquer embedding, sempre.

2. Confundir “precisão alta” com “modelo bom”

Se o dataset é 90% cível e 10% criminal, um classificador que sempre responde “cível” tem 90% de acurácia e zero utilidade. Use F1 macro, matriz de confusão e, principalmente, teste em classes raras.

3. Ignorar a hierarquia processual

Um acórdão do STJ não tem a mesma “força” que uma sentença de primeira instância. Modelo que trata ambos como documentos equivalentes gera respostas ingênuas. Incorpore metadados (tribunal, data, instância) como features categóricas, não só o texto.

4. Subestimar o custo de OCR de qualidade

Muitos processos brasileiros chegam como PDF escaneado de fax de 1998. Se você passa direto para o embedding, a IA aprende os erros do OCR. Invista em pré-processamento: Tesseract configurado para português + correção ortográfica + verificação humana em amostras.

5. Não ter fallback humano

IA no Judiciário precisa de human-in-the-loop. Sempre. Caso contrário, você automatiza injustiça em escala industrial. O artigo da Stanford menciona “reduzir custos”, mas redução com accountability é o único caminho viável.

O que esse projeto da Stanford pode significar para o ecossistema dev

Quando três doutores brasileiros entram no CodeX, o que mais me interessa não é o resultado acadêmico — é o eventual open-sourcing parcial do que eles produzirem. Se a pesquisa gerar datasets rotulados, benchmarks ou modelos pré-treinados para o português jurídico, isso é material que faltava no ecossistema.

Como dev, eu monitoro três coisas nos próximos meses:

1. Publicação de datasets rotulados no padrão usado pelo CodeX
2. Modelos de sumarização de acórdãos liberados no Hugging Face
3. Padrões de avaliação de fairness no contexto do CNJ e da OAB

Cada um desses três itens é uma oportunidade de projeto open source. Cada um é também uma porta de entrada para times que querem provar IA jurídica em produção sem reinventar a roda.

FAQ — perguntas que devs realmente fazem

Qual o melhor modelo open source para começar em legal tech no Brasil?

Para embedding multilíngue com custo baixo, o paraphrase-multilingual-MiniLM-L12-v2 é o melhor ponto de partida. Para modelos maiores em GPU, o Sabiá-7B (Maritaca AI) é treinado em português brasileiro e tem performance surpreendente em tarefas jurídicas. Para fine-tuning específico, o BERTimbau base é a referência consolidada.

É viável rodar LLM local para análise de petições?

Sim, com quantização 4-bit (bitsandbytes + GPTQ) você roda Llama 3 70B ou Sabiá em uma GPU A100/H100. Para times menores, Llama 3 8B ou Mistral 7B já resolvem sumarização e classificação. O gargalo quase nunca é o modelo — é o pipeline de pré-processamento de PDFs mal formatados.

Como anonimizar petições sem perder contexto semântico?

Use um pipeline de NER (spaCy pt_core_news_lg ou BERTimbau NER) para detectar entidades, substitua por tokens genéricos ([PESSOA_1], [ENDERECO_1]), mantenha um dicionário reverso criptografado e separado dos embeddings. O contexto jurídico (tipo de ação, valor, tese) preservado é o que mantém o modelo útil.

Vale a pena usar RAG para jurisprudência?

Vale, e é onde está o ganho real. Indexe acórdãos do STF/STJ em um vector store (Qdrant, pgvector, Weaviate), use reranker (cross-encoder multilingual) para refinar os top-k, e gere resposta com citações explícitas. Esse padrão, bem feito, reduz o tempo de pesquisa de um advogado de horas para minutos.

Como evitar que a IA “alucine” com jurisprudência inexistente?

Forçando a saída: use function calling para que o LLM só possa citar acórdãos retornados pelo retrieval. Adicione um verificador de similaridade que compara a citação gerada com o documento original. E mostre o snippet original ao usuário — transparência é a única defesa técnica razoável contra alucinação em domínio jurídico.

Checklist final para quem quer entrar em legal tech com IA

• Comece com embedding + classificador supervisionado, não com LLM
• Invista em OCR de qualidade e anonimização antes de qualquer embedding
• Use F1 macro e matriz de confusão, não só acurácia
• Separe pipelines por tribunal/instance, não generalize cegamente
• Mantenha human-in-the-loop em qualquer decisão automatizada
• Documente o pipeline com versionamento de dataset e modelo
• Monitore drift — vocabulário jurídico muda, súmulas mudam

Se o Brasil é mesmo o maior laboratório de direito e inovação do planeta, como afirmou Feigelson, a responsabilidade de construir esse futuro é também nossa, devs. Não só dos três doutores na Stanford. Cada pipeline bem-feito aqui é um tijolo nesse edifício.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.