RAG corporativo: filtre permissões antes da busca vetorial

Quando uma empresa monta um RAG para consultar contratos, políticas internas ou históricos de clientes, ela quase sempre discute o modelo errado de risco. A conversa gira em torno de alucinação — a resposta inventada. Mas o risco que deveria tirar o sono de qualquer gestor é anterior à resposta: é a recuperação indevida. Se o sistema busca no índice vetorial antes de checar quem está perguntando, o dado confidencial já saiu do cofre. O que a interface esconde depois é maquiagem.

A tese é simples: permissão não é feature de interface — é decisão de arquitetura na camada de recuperação. E boa parte dos projetos corporativos de RAG no Brasil está tomando essa decisão errado, ou pior, nem sabe que ela existe.

O índice vetorial é uma cópia do seu acervo — e quase ninguém o trata assim

O pipeline canônico de RAG é conhecido: ingestão, chunking, embeddings, indexação vetorial, retrieval e geração. O que passa despercebido é o que acontece na terceira e quarta etapas. Ao transformar contratos e políticas em embeddings e indexá-los em ferramentas como Pinecone, Weaviate, Milvus ou FAISS, a empresa cria uma réplica semântica do acervo inteiro em um novo repositório.

Esse repositório raramente herda os controles do original. O contrato que vivia em uma pasta restrita do jurídico, com acesso de cinco pessoas, agora existe como centenas de vetores em um índice que o sistema de RAG consulta livremente. Se a governança de acesso não foi replicada na indexação — via metadados, papéis e escopos —, qualquer pergunta bem formulada pode puxar aquele conteúdo para dentro do prompt.

E aqui está o detalhe que muda tudo: o vazamento não acontece quando o usuário lê a resposta. Acontece quando o trecho entra no contexto do LLM. A partir dali, o conteúdo confidencial já circulou por logs, caches e, dependendo da arquitetura, por APIs de terceiros.

Pré-filtro ou pós-filtro: a decisão de uma linha de código que vale um incidente de LGPD

Existem dois jeitos de aplicar permissão em busca vetorial. No pós-filtro, o sistema busca os trechos mais similares no índice inteiro e depois descarta o que o usuário não pode ver. No pré-filtro, a busca já nasce restrita: só compara vetores dentro do escopo autorizado daquele usuário.

Parece detalhe de implementação. Não é. No pós-filtro, o conteúdo restrito participa da recuperação — foi lido, ranqueado e, em muitas arquiteturas, chegou a compor o contexto antes de ser cortado. A Unified, em sua documentação de busca de contratos com RAG, mostra o caminho correto: filtros por connection_id e permissions[] aplicados antes de o contexto ser montado, restringindo o que retorna para cada usuário autorizado. É governança na camada de retrieval, não na tela.

A diferença prática é brutal. Com pré-filtro, o analista comercial que pergunta "quais contratos têm cláusula de exclusividade?" recebe resposta apenas sobre os contratos da carteira dele. Com pós-filtro mal implementado, o sistema pode raciocinar sobre o contrato sigiloso da fusão em andamento — e mesmo que não cite o documento, a resposta carrega a informação. É o vazamento por inferência: ninguém abriu o arquivo, mas o segredo saiu.

Chunking: onde a cláusula vira confete

O segundo problema estrutural é a fragmentação. Guias técnicos consolidados recomendam chunks de cerca de 200 palavras, com recuperação de 3 a 5 trechos por consulta. Funciona bem para FAQ e documentação técnica. Para contratos, é uma armadilha.

Uma cláusula de multa que remete a uma exceção definida três páginas antes, um aditivo que altera o prazo do instrumento principal, uma condição suspensiva espalhada em dois anexos: nada disso sobrevive intacto a um chunking agressivo. O sistema recupera o pedaço que "parece" responder — e a resposta sai tecnicamente errada com aparência de precisa.

A arquitetura descrita pela DIO para automação contratual aponta a mitigação correta: não confiar apenas na similaridade semântica. O pipeline usa FAISS na recuperação, mas adiciona validações determinísticas antes de registrar qualquer dado — coerência de CNPJs, conferência de prazos, somatória de valores. É a lição que vale para qualquer setor: em documento com estrutura lógica, similaridade vetorial encontra o trecho; quem valida a informação é regra de negócio, não o LLM.

Rastreabilidade não é mostrar a fonte. É provar a versão

Há uma falsa sensação de auditabilidade no mercado. Muitos sistemas exibem os trechos que embasaram a resposta e vendem isso como rastreabilidade. Mas retornar trechos parecidos não garante que a resposta esteja correta, completa ou atualizada. Se a base indexada não tem versionamento e metadados robustos, o RAG pode responder com a política de compliance de dois anos atrás, com a mesma confiança de sempre — e com citação de fonte para parecer confiável.

A DocuSign, ao posicionar RAG para busca em repositórios de contratos e bases jurídicas, toca no ponto certo do caso de uso: o valor está em responder sobre o acervo real. Mas acervo real muda. Contrato é aditado, política é revisada, cliente atualiza cadastro. Sem um processo de reindexação com controle de versão, o índice vetorial vira um retrato envelhecido que o LLM trata como presente.

Os números justificam o investimento em fazer direito: materiais técnicos do setor relatam redução de 40% a 60% no tempo de revisão legal com automação contratual, com payback de 3 a 6 meses. O ROI existe. Mas ele pressupõe que a resposta seja confiável — e confiabilidade, em RAG corporativo, se constrói na infraestrutura invisível: permissões, versionamento, validação.

O que isso significa para empresas brasileiras

No Brasil, esse debate tem um agravante regulatório: contratos e históricos de clientes quase sempre contêm dados pessoais, e a LGPD exige minimização, controle de acesso e rastreabilidade de tratamento. Um índice vetorial sem governança é, na prática, uma nova base de dados pessoais criada sem os controles da original — algo difícil de sustentar em qualquer auditoria de conformidade.

Para quem vai contratar ou construir um RAG interno, três perguntas separam projeto sério de risco embalado como inovação:

Onde o filtro de permissão é aplicado? Se a resposta for "na interface" ou "depois da busca", o conteúdo restrito já está circulando pelo pipeline. Exija pré-filtro por metadados e papéis na consulta vetorial, no padrão que a Unified documenta com permissions[].
O que acontece quando o documento muda? Sem reindexação versionada, o sistema responde com o passado. Peça para ver o processo de atualização do índice, não o demo do chat.
O que valida a resposta além da similaridade? Em contratos e dados financeiros, checagens determinísticas — como as validações de CNPJ e valores do pipeline da DIO — são o que transforma trecho recuperado em informação confiável.

A realidade do mercado brasileiro, com múltiplas áreas, escritórios regionais e bases documentais heterogêneas, torna esse desenho ainda mais crítico: os níveis de sigilo variam por unidade, por cliente e por contrato. Um RAG que trata o acervo como um bloco único vai, cedo ou tarde, responder para a pessoa errada com o documento certo.

O modelo de linguagem é a parte visível e a menos importante dessa equação. Quem decide se o seu RAG é uma vantagem competitiva ou um incidente esperando data é a camada que ninguém mostra no demo: a recuperação. Filtre antes de buscar. Depois é tarde.

Filtrar depois da busca é filtrar depois do vazamento: o erro de arquitetura que mata o RAG corporativo