Por que a maioria dos projetos de RAG jurídico falha no primeiro semestre

---

Existe um padrão que se repete em projetos de RAG jurídico que travam. O escritório ou departamento jurídico monta um piloto com um conjunto pequeno de peças, jurisprudência e contratos. A demonstração funciona. Alguns meses depois, o sistema está disponível, mas a equipe não confia nele. As respostas às vezes estão corretas, às vezes atribuem um fundamento ao documento errado, às vezes apresentam uma citação jurisprudencial sem fonte verificável. O time técnico troca o modelo de embedding, testa outro banco vetorial e aumenta o contexto. Nada resolve de forma consistente.

O diagnóstico costuma ser técnico: "nossa recuperação está ruim". A conclusão costuma ser adquirir mais tecnologia. É justamente aí que o projeto entra no ciclo que compromete sua confiabilidade.

Este artigo defende uma tese que contraria o senso comum: o RAG jurídico raramente falha apenas por causa do modelo. Ele falha porque o acervo que alimenta o sistema não foi tratado como uma base governada, com critérios de autoridade, vigência e rastreabilidade. Essa leitura é compatível com a pesquisa acadêmica sobre pontos de falha e com os dados de mercado de 2025 e 2026.

Primeiro, o tamanho do problema

Antes de entrar no mecanismo técnico, vale estabelecer a escala. A taxa de fracasso de projetos de IA em organizações não é anedota, é um dado apontado por múltiplas fontes independentes.

A RAND Corporation, em análise divulgada no fim de 2025, documentou que mais de 80% dos projetos de IA corporativa não entregam o valor prometido, aproximadamente o dobro da taxa de fracasso de projetos de TI que não envolvem IA. O estudo do MIT, no relatório Project NANDA (The GenAI Divide, julho de 2025), foi ainda mais duro: cobrindo mais de 300 iniciativas e 150 entrevistas com executivos, encontrou que apenas 5% dos pilotos integrados de IA generativa extraem valor mensurável. Os outros 95% ficam presos sem impacto documentado no resultado.

A pergunta que importa é: por quê. E aqui a convergência das fontes é o que dá força ao argumento. A Gartner reporta que a qualidade e a disponibilidade de dados é o obstáculo técnico mais citado, e projeta que, ao longo de 2026, 60% dos projetos de IA sem dados prontos para IA (AI-ready data) serão abandonados. A pesquisa da Gartner do terceiro trimestre de 2024, com 248 líderes de gestão de dados, encontrou que 63% das organizações não têm ou não sabem se têm as práticas de gestão de dados adequadas para IA. A CDO Insights 2025, da Informatica, coloca qualidade e prontidão de dados como o obstáculo número um, citado por 43% dos respondentes, e registra que apenas 12% das organizações reportam ter dados de qualidade e acessibilidade suficientes para aplicações de IA.

O padrão é inequívoco. O gargalo dominante não é o modelo. É o dado que alimenta o modelo. No RAG jurídico, isso se manifesta diretamente na qualidade, vigência e rastreabilidade do acervo.

O que a demo esconde

Uma demonstração de RAG é montada em condições artificiais. Selecionam-se poucos documentos limpos, formulam-se perguntas que já se sabe que o acervo responde e mostra-se o sistema acertando. O sistema funciona naquelas condições. O problema é que essas condições não representam a rotina jurídica.

Em produção, a base contém peças longas e muito parecidas entre si, ementas com vocabulário repetitivo, contratos com várias versões, anexos escaneados e documentos sem identificação consistente. Uma petição inicial pode ser semanticamente semelhante a dezenas de outras, embora trate de fatos, pedidos e processos diferentes. Uma cláusula vigente pode conviver com sua versão anterior. A semelhança textual ajuda a localizar conteúdo, mas não substitui controle de versão nem autoridade documental.

Essa distância entre piloto e operação não é uma percepção minha. É a primeira das duas grandes conclusões do trabalho acadêmico de referência sobre o tema. Barnett e colegas, no artigo Seven Failure Points When Engineering a Retrieval Augmented Generation System (arXiv 2401.05856, 2024), conduziram uma investigação empírica com 15.000 documentos e 1.000 perguntas em três domínios distintos (pesquisa, educação e biomedicina). As duas lições centrais do estudo são diretas: primeiro, a validação de um sistema de RAG só é viável durante a operação, não no projeto; segundo, a robustez de um sistema de RAG evolui com o tempo, não é projetada de uma vez no início. Em outras palavras, o que funciona na demo não diz quase nada sobre o que vai funcionar em produção.

O modelo de embedding não sabe qual fonte conflitante deve prevalecer. Ele mede similaridade semântica, não autoridade jurídica. Em uma pergunta sobre uma tese, pode recuperar ementas semelhantes de casos distintos, um trecho de peça sem o contexto dos fatos e uma referência desatualizada. Sem metadados e fonte rastreável em cada trecho, o sistema pode combinar conteúdos incompatíveis ou apresentar jurisprudência que o profissional não consegue conferir. Recuperar com precisão uma base desorganizada não torna a resposta confiável.

O ponto onde as falhas realmente acontecem

A engenharia de RAG tem uma sequência de estágios: ingestão, parsing, chunking, indexação, recuperação e geração. A intuição da maioria dos times é que a falha está nos estágios finais, na recuperação ou na geração, porque é ali que o erro aparece. A análise de quem estuda o pipeline inteiro diz o contrário.

A Unstructured, empresa especializada em preparação de dados para IA, resume o achado de forma cirúrgica em sua documentação técnica sobre desafios de RAG em produção: a maioria das falhas de RAG parece falha de modelo, mas começa mais cedo no pipeline. Se ingestão, parsing, chunking, indexação ou recuperação estão instáveis, o modelo recebe contexto fraco e produz resposta com alto risco de alucinação. A conclusão deles é a tese deste artigo em uma frase: um RAG é tão forte quanto a camada de dados que monta o contexto, e corrigir a geração primeiro é quase sempre a ordem errada, porque a qualidade da recuperação define o teto.

Quando um RAG jurídico produz respostas não confiáveis, a causa costuma estar em uma destas quatro origens. Nenhuma delas se resolve apenas com a troca do modelo.

1. Duplicação e versionamento invisível

A mesma informação existe em múltiplas versões, e o sistema não sabe qual está vigente. Minutas sucessivas de um contrato, peças reaproveitadas e versões diferentes de um parecer coexistem na base. Quando o usuário pergunta, a recuperação pode trazer a versão semanticamente mais próxima, mesmo que ela não seja a aprovada ou aplicável ao caso.

Nenhum reranking resolve isso sozinho, porque o problema não é apenas ordenação por relevância. Os documentos podem ser igualmente próximos da pergunta, mas um deles não deveria ser apresentado como fonte vigente.

2. Ausência de metadado de autoridade

Cada trecho recuperado deveria responder a perguntas básicas: de qual arquivo veio, a qual processo ou contrato pertence, quando foi validado, quem é responsável por ele e onde a fonte pode ser conferida. Em muitas bases jurídicas, o documento entra como texto puro, sem número de processo, tribunal, órgão julgador, data, versão, status ou vínculo com o original.

É exatamente aqui que entra a definição operacional que a Gartner consolidou em fevereiro de 2025 para o conceito de AI-ready data. Dados prontos para IA são alinhados a casos de uso específicos, governados no nível do ativo, sustentados por pipelines com controles de qualidade, gerenciados por metadados vivos e continuamente submetidos a verificação. A definição é quase inteiramente sobre governança e metadado, não sobre o modelo. Uma base sem autoridade documental não filtra o que está superado, não sustenta citação verificável e não sinaliza informação expirada. No contexto jurídico, a fonte rastreável em cada trecho é uma barreira essencial contra a apresentação de jurisprudência inexistente ou atribuída ao processo errado.

3. Chunking que quebra a unidade de sentido

A forma como documentos jurídicos são fatiados para indexação é tratada como detalhe técnico, quando é uma decisão de conteúdo. Cortar uma peça a cada quinhentos caracteres, sem respeitar onde terminam a narrativa dos fatos, o fundamento e o pedido, cria fragmentos ambíguos. Em contratos, a exceção pode ficar separada da cláusula principal. Em decisões e ementas, a tese pode ser recuperada sem o contexto processual que limita sua aplicação.

Isso é quantificável. Análises de benchmark de estratégias de chunking mostram que a diferença de recall entre a melhor e a pior abordagem para um mesmo corpus pode chegar a cerca de 9 pontos percentuais. É a diferença entre um sistema que encontra a informação certa e um que a deixa de fora, decidida antes de qualquer embedding ser gerado. E o custo de errar aqui é alto por um motivo estrutural: o chunking acontece antes da geração dos embeddings, então mudar a estratégia depois exige reprocessar o corpus inteiro.

O resultado de um chunking ruim é um trecho que, isolado, parece sustentar algo que o documento inteiro, lido em contexto, não sustenta. O modelo pode estar reproduzindo fielmente um fragmento cortado no lugar errado.

4. Ingestão sem controle de entrada

A base cresce sem controle de entrada. Peças, jurisprudência e contratos são indexados sem critério comum. Não há revisão do que já está lá nem processo para retirar versões vencidas, documentos duplicados ou arquivos que não deveriam ser reutilizados. O acervo vira um depósito, e um depósito não é uma fonte jurídica confiável.

Esse problema se agrava com o tempo, e por isso o primeiro semestre é um ponto de virada. No começo, a base é pequena e relativamente limpa. Conforme novos documentos são adicionados sem governança, a proporção de ruído sobe e a confiabilidade cai. A equipe conclui que o sistema "piorou", quando foi o acervo que se degradou. Isso se conecta ao segundo achado de Barnett e colegas: a robustez evolui, para melhor ou para pior, e sem governança de ingestão ela evolui para pior.

Por que trocar o modelo dá a falsa sensação de progresso

Quando o time troca o embedding ou o vector store, geralmente há uma melhora pequena e mensurável em alguma métrica de recuperação. Isso reforça a crença de que o caminho é técnico. Mas essa melhora é marginal e tem teto baixo, porque o gargalo não estava ali.

Há uma forma concreta de diagnosticar isso, e ela vale mais que qualquer intuição. Meça o sistema com uma métrica de recuperação como Recall@K, que verifica se a resposta correta está entre os K primeiros trechos recuperados. Se o Recall já está alto, digamos que a resposta certa aparece entre os vinte primeiros na grande maioria das perguntas de um conjunto de avaliação, então a informação está sendo encontrada. O problema não é busca. Se, com Recall alto, a resposta final ainda é ruim, o problema está em qual trecho, entre os corretos e os incorretos que foram recuperados, o sistema escolheu usar. E isso depende da qualidade e da governança da base, não da capacidade de busca.

Investir mais no modelo quando o Recall já está alto é otimizar a parte que não está quebrada. É o equivalente a comprar uma câmera melhor para fotografar um ambiente mal iluminado. A lente não é o problema. A diferença entre um acervo jurídico limpo, rastreável e vigente e uma base caótica continua maior do que o ganho marginal obtido com muitas trocas de embedding.

O que fazer antes de tocar em qualquer componente técnico

A sequência correta inverte a ordem intuitiva. Antes de escolher modelo, antes de escolher vector store, antes de ajustar prompt, o trabalho é de governança de dados. Na prática, quatro frentes.

Primeiro, auditar o acervo de origem. Levantar peças, jurisprudência e contratos, identificar duplicatas, versões concorrentes e documentos sem responsável. O que não pode ser validado ou não deveria ser reutilizado precisa ficar fora da recuperação.

Segundo, atribuir metadados de autoridade a cada fonte, seguindo o padrão de AI-ready data: origem, data, versão, responsável e status de validação. Isso permite filtrar por recência, citar a fonte de forma verificável e sinalizar informação expirada. A rastreabilidade deve chegar ao trecho recuperado, para que o profissional possa abrir o documento original e conferir o fundamento antes do uso.

Terceiro, definir chunking por unidade de sentido, não por simples contagem de caracteres. O corte deve respeitar a estrutura jurídica: cláusula e exceção, fundamento e conclusão, narrativa fática e pedido. Uma técnica útil é o parent-document retrieval: indexar trechos menores para obter precisão, mas entregar ao modelo a seção maior que preserva o contexto. Para peças longas, contratos, pareceres e decisões, isso pode superar estratégias de nível único.

Quarto, instituir controle de ingestão. É necessário definir o que entra, revisar periodicamente o que está indexado e remover o que saiu de vigência. Também é preciso manter uma avaliação com perguntas jurídicas representativas e registrar falhas reais da operação. A base deve ser tratada como um sistema vivo, com manutenção contínua.

O reenquadramento que muda o projeto

O erro estratégico que compromete o RAG jurídico é enquadrá-lo apenas como projeto de tecnologia. Na maior parte, ele é um projeto de governança da informação jurídica. A camada difícil, que determina se o sistema será confiável, é a curadoria do acervo que o alimenta.

Vale notar que esse mesmo princípio aparece nos dados sobre o que distingue os projetos que dão certo. A McKinsey, em sua pesquisa State of AI de 2025, encontrou que organizações que reportam retornos significativos com IA têm cerca do dobro de probabilidade de terem redesenhado os fluxos de trabalho de ponta a ponta antes de escolher a técnica de modelagem. Ou seja, os que ganham tratam o problema de processo e dado antes do problema de modelo. É o mesmo padrão, visto do lado do sucesso.

Isso tem uma implicação prática direta. Se o seu escritório de advocacia ou departamento jurídico avalia um projeto de RAG, ou tem um piloto que travou, a pergunta central não é "qual modelo devemos usar". A pergunta é "quem responde pelo acervo e qual processo garante que ele está limpo, vigente e rastreável". Sem essa resposta, a troca de modelo não interrompe o ciclo de degradação.

O RAG que funciona no segundo ano não é apenas o que tem o melhor embedding. É o que foi construído sobre uma base governada desde o primeiro dia, apresenta a fonte de cada trecho relevante e mantém revisão obrigatória por profissional habilitado antes de qualquer uso jurídico.

---

Referências

• Barnett, S. et al. Seven Failure Points When Engineering a Retrieval Augmented Generation System. arXiv:2401.05856, 2024. Investigação empírica com 15.000 documentos e 1.000 perguntas em três domínios.
• MIT Project NANDA. The GenAI Divide: State of AI in Business 2025. Julho de 2025. Cobertura de mais de 300 iniciativas e 150 entrevistas com executivos.
• RAND Corporation. Why AI Projects Fail. 2025. Meta-análise de casos documentados de projetos de IA corporativa.
• Gartner. Lack of AI-Ready Data Puts AI Projects at Risk. Fevereiro de 2025, e definição operacional de AI-ready data. Pesquisa com 248 líderes de gestão de dados (Q3 2024).
• Informatica. CDO Insights 2025. Qualidade e prontidão de dados como obstáculo número um à IA.
• McKinsey. The State of AI 2025. Correlação entre redesenho de fluxos e retorno financeiro com IA.
• Unstructured. Common Challenges in RAG and How to Solve Them in Production. Análise de falhas por estágio do pipeline.

As estatísticas de mercado citadas são consolidadas por múltiplas fontes de análise setorial e podem variar conforme metodologia e recorte. Recomenda-se consultar os relatórios originais para os números exatos e suas condições de medição.

---

Thiago Azeredo Rodrigues é advogado e consultor de IA aplicada ao Direito, especializado em agentes jurídicos, RAG em produção e automações em operações jurídicas. Constrói e opera sistemas com foco em confiabilidade, auditabilidade e revisão humana obrigatória.