RAG seguro: governança em contratos e bases internas

Por que RAG sozinho não resolve o problema de governança

RAG (Retrieval-Augmented Generation) virou o caminho padrão para conectar LLMs a bases internas de conhecimento: contratos, políticas, históricos de clientes, manuais técnicos. Mas, em uma empresa com dados sensíveis, o risco não está só na qualidade da resposta — está em quem vê o quê.

Um sistema de RAG simples ("joga tudo no banco vetorial e pergunta") costuma ignorar:

permissões por área, cargo e papel;
sigilo contratual (NDA, cláusulas específicas, dados pessoais);
trilha de auditoria sobre o que foi consultado;
consistência com políticas já existentes de segurança da informação e LGPD.

O resultado é previsível: o jurídico veta, o compliance trava e o projeto morre antes de ir para produção.

O ponto central: usar RAG, embeddings e busca vetorial em contratos e documentos internos exige que a governança venha junto do desenho técnico — não depois.

Conceitos técnicos que importam para a governança

Antes de discutir arquitetura, vale alinhar três conceitos que são a base desse tipo de solução.

Embeddings: o DNA matemático dos seus documentos

Embeddings são representações numéricas densas de textos (ou imagens, áudio etc.), em forma de vetores de alta dimensionalidade, geradas por modelos de machine learning. Eles preservam proximidade semântica: conteúdos parecidos ficam perto no “espaço vetorial”.

Em termos práticos:

um parágrafo de contrato vira uma lista de centenas ou milhares de números que capturam seu significado;
perguntas como “qual o prazo de renovação automática?” são convertidas em vetores para buscar trechos de contrato semanticamente relacionados;
isso permite encontrar conteúdo relevante mesmo sem repetir palavras exatas.

Busca vetorial: procurar por significado, não por palavra-chave

Um banco de dados vetorial é otimizado para armazenar e buscar esses vetores de alta dimensionalidade. Em vez de buscar "renovação" como string, o sistema busca vetores próximos do vetor da pergunta (técnicas de Approximate Nearest Neighbor – ANN).

A consequência é poderosa: a IA consegue “entender” que “renovação automática” se relaciona com “prorrogação tácita” ou “continuidade do contrato”, mesmo sem coincidência literal de termos.

RAG: o cérebro não sabe dos seus contratos — você precisa alimentá-lo

Modelos de linguagem grandes não conhecem, por padrão, seus contratos internos nem suas políticas. O papel do RAG é:

receber a pergunta do usuário;
gerar embeddings da pergunta;
buscar, no banco vetorial, os trechos de documentos mais relevantes;
enviar esses trechos como contexto para o modelo gerar a resposta;
opcionalmente, devolver também as referências (documento, cláusula, data).

Isso resolve dois problemas clássicos:

o modelo passa a responder com base em dados reais da empresa;
alucinações diminuem porque o modelo é ancorado em contexto específico.

Mas nada disso, por si só, garante que um analista júnior não veja um contrato estratégico do board. É aí que entra o desenho de segurança.

O problema invisível: embeddings também carregam informação sensível

Há um equívoco comum em times técnicos: “se eu só armazeno embeddings, não tem dado sensível”. Não é bem assim.

Embeddings são numéricos, mas são derivados diretamente do texto original.
Com acesso ao texto original indexado junto do vetor (o que é padrão em bancos vetoriais), qualquer trecho pode ser reconstituído.
Mesmo quando só o vetor é armazenado, pesquisas mostram que é possível inferir informações sensíveis de embeddings em alguns cenários, principalmente se o atacante controla as consultas.

Por isso, controle de acesso precisa existir na camada de busca e na camada de contexto, não apenas na UI ou no banco de documentos bruto.

Arquitetura de RAG com segurança e governança desde o dia zero

Em vez de pensar "um banco vetorial para tudo", faz mais sentido pensar em camadas de compartimentação.

1. Segmentar o conhecimento em domínios e níveis de sigilo

Antes de falar em ferramenta, defina uma matriz simples:

Domínios: contratos comerciais, contratos trabalhistas, políticas internas, histórico de clientes, documentação técnica etc.
Níveis de sigilo: público interno, restrito à diretoria, restrito ao jurídico, restrito a determinados times/projetos.

Cada combinação domínio × sigilo pode virar:

um índice vetorial separado; ou
um único índice com metadados fortes de controle de acesso (por exemplo, dominio=juridico, sigilo=alto, cliente=ABC).

O importante é: a política de acesso não pode depender só da aplicação. Ela precisa estar presente na estrutura de índices e metadados.

2. Embeddings + metadados: o par inseparável

Um bom desenho de armazenamento geralmente inclui, em cada registro do banco vetorial:

o vetor (embedding);
o texto original ou o ID do trecho no repositório de origem;
metadados de negócio: tipo de documento, área, cliente, produto, data de vigência;
metadados de governança: nível de sigilo, dono do documento, classificação LGPD (se contém dado pessoal ou sensível).

Esses metadados são críticos para:

filtrar o que pode ser buscado (ex.: sigilo <= permissao_usuario);
auditar depois o que foi acessado;
aplicar regras de retenção e descarte.

3. Controle de acesso aplicado na query vetorial

Na prática, uma busca de RAG segura não é apenas:

“me traga os 10 vetores mais próximos dessa pergunta”

Ela é algo como:

“me traga os 10 vetores mais próximos dentro dos documentos cujo nível de sigilo é permitido para esse usuário e que pertençam ao conjunto de clientes aos quais ele tem acesso”.

Isso significa:

sempre associar a sessão do usuário (perfis, grupos, papéis) à query vetorial;
aplicar filtros de metadados na própria chamada ao banco vetorial, não só depois;
evitar arquiteturas em que um serviço interno sem controle robusto faça consultas “ilimitadas” e só filtre na camada de apresentação.

4. Trilhas de auditoria: cada pergunta deixa um rastro

Para empresas dos setores jurídico, saúde e financeiro, auditoria não é opcional.

Um serviço de RAG bem desenhado registra, a cada requisição:

quem perguntou (usuário, papel, sistema);
o que foi perguntado (com eventuais técnicas de anonimização/parcialização se houver dados pessoais na query);
quais documentos/trechos foram retornados pela busca vetorial (IDs, não necessariamente o conteúdo completo);
qual resposta foi gerada e entregue.

Isso permite:

investigar vazamentos ou acessos indevidos;
provar para auditorias internas e externas como a informação é usada;
ajustar regras de autorização com base em uso real.

5. Evitar "contexto demais" na montagem do prompt

Mesmo com filtro de acesso, outro ponto de risco é o tamanho do contexto enviado ao modelo:

juntar trechos de documentos demais aumenta a chance de expor informações além do necessário;
em dados de clientes, isso pode gerar exposição cruzada (trechos de clientes diferentes em uma mesma resposta).

Boas práticas incluem:

limitar o número de trechos por resposta e por fonte (ex.: máximo de X trechos por cliente);
priorizar trechos mais recentes e mais relevantes;
mascarar ou truncar campos extremamente sensíveis nos próprios documentos indexados (ex.: CPF completo, número de conta), dependendo do caso de uso.

Padrões práticos para contratos, políticas, clientes e documentos técnicos

A partir dos princípios acima, alguns padrões se repetem em projetos bem-sucedidos.

Contratos (comerciais, fornecedores, trabalhistas)

Indexação por cláusula em vez de documento completo, com metadados de tipo de cláusula (prazo, multa, SLA, confidencialidade etc.).
Sigilo definido por tipo de contrato e fase (negociação, assinado, encerrado).
Consulta com foco em perguntas padronizadas: prazos, renovações, responsabilidades, garantias.
Usuário consegue navegar da resposta da IA para a cláusula original, mantendo rastreabilidade.

Políticas internas e compliance

Base preferencialmente "pública interna", mas com versões vigentes e histórico, para evitar respostas com base em política revogada.
Metadados de versão e data de vigência fundamentais na busca.
RAG usado para explicar a política em linguagem simples, com link para o texto oficial.

Histórico de clientes

Separação rígida entre dados operacionais (atendimento, tickets, interações) e dados altamente sensíveis.
Índices vetoriais segmentados por cliente ou grupo de clientes, com regras claras de quem pode consultar o quê.
Foco em resumo contextual ("histórico dos últimos 90 dias") sem expor detalhes desnecessários.

Documentação técnica

Indexação por seções ou "blocos lógicos" (módulos, APIs, procedimentos).
Metadados sobre ambiente (produção, homologação, legado), evitando instruções erradas.
RAG usado para: troubleshooting, onboarding de novos times e explicação de impacto de mudanças.

Em todos os casos, a ideia é a mesma: granularidade certa + metadados ricos + filtros de acesso na busca vetorial.

Armadilhas comuns ao implementar RAG em bases internas

Alguns problemas aparecem com frequência em empresas que começam a experimentar RAG:

Um único índice para tudo: mistura jurídico, financeiro, clientes e RH no mesmo banco vetorial, com metadados pobres e sem segmentação.
Permissões só na interface: a API interna enxerga tudo; se outro sistema reutiliza essa API sem cuidado, expõe dados sensíveis.
Ausência de política de atualização: contratos rescindidos e políticas revogadas continuam pesando na resposta; sem controle de versão, o modelo pode responder com base em regra antiga.
“Privacidade por embedding”: acreditar que transformar em vetores elimina obrigações de LGPD e controles de segurança.

A forma de evitar isso é tratar RAG como parte da arquitetura de dados e de segurança, não como um widget plugado depois.

O que isso significa para empresas brasileiras

Para gestores e donos de empresas no Brasil, especialmente em setores regulados, o recado é direto:

RAG não é só tecnologia, é desenho de acesso à informação. O mesmo sistema que destrava produtividade pode, se mal desenhado, violar sigilo contratual, LGPD e políticas internas.
Segurança e governança precisam entrar no escopo desde o início. Ao contratar ou desenvolver soluções com RAG, exija respostas claras para: segmentação de índices, metadados de sigilo, logs de auditoria, filtros de acesso na busca vetorial.
O jurídico e o time de segurança não podem ser convidados só no fim. Eles precisam participar da definição de domínios, níveis de sigilo e trilhas de auditoria que vão ser implementados na prática.
Terceirizar o modelo não terceiriza a responsabilidade. Mesmo usando APIs de modelos externos, a responsabilidade sobre quais documentos entram no contexto, quem pode consultar e o que é logado continua sendo da empresa.

Empresas que conseguirem combinar RAG, embeddings e busca vetorial com um desenho sério de governança vão sair na frente em um ponto decisivo: permitir que pessoas e times usem informações sensíveis com rapidez, sem abrir mão de controle. É esse equilíbrio que separa experimentos de IA de soluções realmente prontas para o conselho, o regulador e o mercado.

RAG com Governaça: Como Não Transformar sua Base de Contratos em um Chatbot Fora de Controle