Legora constrói agentes jurídicos sem nunca ver os dados que eles processam

A legaltech sueca Legora tem um problema que a maioria dos times de produto de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → não enfrenta: não pode ler uma única sessão real de uso do próprio agente. Os dados são de clientes de escritórios de advocacia, protegidos por sigilo profissional, e nem o time de engenharia tem acesso a eles. Jacob Lauritzen, CTO da empresa, detalhou como contorna essa restrição numa entrevista de quase uma hora e dez ao podcast Latent Space, publicada em 2 de novembro de 2026.

O contexto importa. A Legora nasceu num porão em Estocolmo com ChatGPT, legislação sueca e uma ferramenta de busca. Hoje um advogado usa o produto para redigir e editar documentos do Word, revisar 10 mil contratos numa única tabela (o recurso Tabular Review, que virou referência tão forte que o nome foi copiado por concorrentes) e rodar due diligence completa. A própria Legora usou o produto para avaliar suas próprias aquisições.

Testar sem poder ver

Se você não pode ler o trace de produção, como sabe se o agente está funcionando? A solução da Legora é não depender da produção para encontrar problema. Um time de três engenheiros e três advogados constrói ambientes de teste modelados no trabalho real dos clientes, algo parecido com os "mundos" simulados usados em reinforcement learning.

Um desses ambientes é uma sala de dados (data room) simulada com 10 mil arquivos, usada para testar cenários de due diligence sem tocar em nenhum documento real. É uma versão jurídica de um padrão que já existe em engenharia de ML: quando o ambiente de produção é caro, perigoso ou, neste caso, legalmente inacessível, você constrói um substituto fiel o bastante para expor as mesmas falhas.

Em resumo: a Legora trocou "observar produção" por "simular produção", e colocou especialistas de domínio (advogados, não só engenheiros) dentro do próprio ciclo de criação dos cenários de teste.

Trace parafraseado: métrica sem conteúdo

A segunda peça do quebra-cabeça é o que Lauritzen chamou de parafrasear traces. Em vez de ler o conteúdo real de uma sessão (o que seria uma violação de sigilo), a equipe trabalha com versões reescritas e despersonalizadas dos registros de execução, o suficiente para classificar o tipo de falha sem expor o dado original.

Foi assim que o time conseguiu reduzir o universo de problemas a algo entre 10 e 20 categorias recorrentes, segundo o relato de Lauritzen no episódio. Para quem constrói observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → de agentes em produção, isso é uma peça de infraestrutura concreta: um pipeline de redação (redaction) e reescrita automática que roda antes de qualquer humano ou dashboard tocar no log, parecido com o que times que lidam com dado sensível no Brasil já fazem com payload de requisição em ferramentas como Sentry ou Datadog para não vazar CPF, prontuário médico ou, no caso jurídico, o teor de um processo sigiloso.

O salto de 70% para 99% que ninguém na Legora causou

Um dos pontos mais reveladores da conversa é um problema de citação (o agente apontando a fonte certa dentro de um contrato ou processo) que vivia em 70% de acerto. Depois de um único release de modelo, sem qualquer mudança no código da Legora, a métrica saltou para 99%.

Esse episódio ilustra um trade-off que todo time construindo produto sobre modelo de terceiro conhece, mas raramente vê quantificado: parte da evolução do seu produto está fora do seu controle, no roteiro do laboratório que treina o modelo. Isso é bom quando o salto é positivo e gratuito. É arriscado quando significa que seu diferencial técnico pode ser absorvido pela próxima versão do modelo base, ponto que o próprio episódio levanta ao discutir se os laboratórios de modelo vão um dia cortar ferramentas jurídicas do mesmo jeito que já restringiram ferramentas de código.

Infraestrutura: Azure, embeddings e a aposta contra o contexto gigante

A Legora roda toda a operação no Azure, decisão descrita como consequência direta das exigências de privacidade de dado dos clientes, os mesmos escritórios de advocacia que não deixam a empresa ler seus traces. É o tipo de restrição que qualquer time brasileiro lidando com LGPD↳LGPD14 conteúdosComo utilizar a LGPD com o objetivo de conformidade e inovação?Gestão Dev & TI · out 2021LGPD coloca pressão inédita nos responsáveis pela tecnologia das empresasData · ago 2021Proteção de dados: LGPD é sancionada e começa a valerData · set 2020Ver tudo em Gestão Dev & TI → em setor regulado (saúde, jurídico, financeiro) reconhece: a escolha de nuvem muitas vezes é ditada por contrato e compliance antes de ser ditada por performance ou custo.

Outro detalhe técnico que vale o tempo de quem constrói RAG: Lauritzen recomenda não usar embeddings padrão (default) para busca em domínio jurídico. A leitura prática é que embedding genérico, treinado para linguagem do dia a dia, perde nuance de terminologia contratual e precedente legal, exigindo ajuste fino ou arquitetura de recuperação mais sofisticada, como late interaction, mencionada no episódio.

Há ainda um debate direto sobre como lidar com contrato de milhão de tokens: colocar tudo numa janela de contexto gigante ou fatiar com MapReduce e agregar depois? A posição discutida no episódio é que redigir um contrato longo é, no fundo, um problema de busca, não um problema de tamanho de janela. Para quem está decidindo arquitetura de um pipeline de documento longo, é um lembrete de que contexto maior não substitui um bom mecanismo de recuperação.

Equipe pequena, API que não existe, e o limite do hype

Lauritzen usou um slide com os 300 espartanos para defender, por anos, que 20 engenheiros bastariam para sempre. A Legora hoje tem 100 engenheiros e, segundo ele, ainda está com o time enxuto demais. É um contraponto útil ao discurso corrente de que agente de IA permite equipe de engenharia minúscula sustentando produto gigante: na prática de quem constrói isso, a demanda de engenharia especializada (os chamados "legal engineers" e os "forward-deployed engineers" descritos no episódio) cresceu junto com a sofisticação do produto, não encolheu.

A empresa também resistiu, por muito tempo, a construir uma API tradicional, chegando a discutir se o próprio agente pode ser a API. Para times de integração que esperam um endpoint REST convencional de produtos agentivos como esse, vale o aviso: a interface pode ser o agente conversando, não um contrato de API no sentido clássico.

O que muda para quem constrói aqui

Nenhuma dessas técnicas é exclusiva do direito. Qualquer produto de IA que processe dado sob sigilo no Brasil (prontuário médico, extrato bancário, processo judicial sob segredo de justiça) esbarra no mesmo limite: você não pode debugar olhando o dado real. As respostas da Legora, ambiente simulado com participação de especialista de domínio, trace anonimizado e parafraseado, e métrica de proxy em vez de conteúdo bruto, formam um padrão de engenharia replicável, mas que tem custo: exige construir e manter pipeline de anonimização, gerar dado sintético representativo e aceitar que parte do seu sinal de qualidade sempre será indireto.

Fonte: Latent Space