Governança RAG: Segurança e Conformidade em Bases Vetoriais

O Paradoxo do RAG: Acesso Inteligente vs. Risco de Segurança

Quando uma empresa implementa um sistema de Geração Aumentada por Recuperação (RAG) para consultar contratos, políticas internas ou históricos de clientes, enfrenta um dilema arquitetural: quanto mais dados forem indexados em vetores para tornar as buscas semânticas poderosas, maior a exposição de informações sensíveis a um sistema que funciona como uma "caixa preta" de recuperação.

O RAG promete eficiência operacional extraordinária. Um assistente alimentado por RAG pode responder a perguntas sobre cláusulas contratuais, políticas de crédito ou protocolos médicos sem exigir que o usuário navegue manualmente por arquivos desorganizados. Mas essa conveniência traz uma questão crítica: quem acessa quais dados, por quê, quando e com que autorização?

Diferentemente de um banco de dados relacional tradicional, onde permissões são granulares e auditáveis no nível da linha ou coluna, um banco de dados vetorial foi historicamente projetado para velocidade de busca semântica, não para governança de dados em tempo real. Essa lacuna é exatamente onde muitas empresas fracassam ao tentar escalar RAG em produção.

O Que Muda Quando Você Vetoriza Dados Sensíveis

Antes do RAG, um documento sensível era um arquivo em um servidor de compartilhamento com controle de acesso baseado em identidade (quem pode abrir a pasta). Agora, esse documento é fragmentado em chunks, convertido em embeddings (representações numéricas multidimensionais), armazenado em um banco vetorial e recuperado por similaridade semântica.

Cada etapa dessa transformação cria novos pontos de risco:

1. Perda de Contexto de Origem Quando um embedding é gerado, a conexão entre o vetor e o documento original se torna opaca. Um chunk de um contrato confidencial é apenas um ponto em um espaço de 1.536 dimensões. Se alguém conseguir acesso ao banco vetorial, pode recuperar trechos sensíveis sem que o sistema rastreie de onde vieram.

2. Vazamento Semântico Buscas semânticas recuperam informações relacionadas, não apenas correspondências exatas. Uma consulta aparentemente inocente — "quais são nossas condições de reembolso?" — pode retornar trechos de contratos confidenciais com clientes específicos que contêm essa informação. O usuário nunca deveria ter visto aquele documento.

3. Auditoria Fragmentada Sistemas RAG tradicionais registram "busca executada" e "resultado retornado", mas não registram qual documento específico foi consultado, se o acesso estava autorizado para aquele usuário naquele contexto, ou se a informação foi usada conforme esperado.

Estruturando Governança em Camadas: Do Embedding até o Resultado

Empresas que implementaram RAG com sucesso em ambientes regulados (setor financeiro, saúde, jurídico) adotam uma abordagem de governança em múltiplas camadas:

Camada 1: Classificação Antes da Vetorização

Antes de converter um documento em vetores, ele deve ser classificado quanto ao nível de sensibilidade. Isso não é novo, mas é essencial:

Público: documentações gerais, guias de produto
Interno: políticas operacionais, manuais de processo
Confidencial: contratos com clientes, dados financeiros, históricos médicos
Restrito: informações de segurança, credenciais, dados PII não-agregados

Cada classificação determina quem pode consultar embeddings daquele documento e sob quais circunstâncias.

Camada 2: Metadados Imutáveis Acoplados aos Vetores

Bancos de dados vetoriais modernos (Qdrant, Weaviate, Milvus) suportam armazenamento de metadados estruturados junto aos pontos vetoriais. Esses metadados devem incluir:

ID do documento de origem (não apenas nome, mas hash ou referência única)
Classificação de sensibilidade
Proprietário ou departamento responsável
Data de última atualização
Período de retenção (se aplicável por conformidade)
Permissões de acesso (lista de grupos ou papéis autorizados)

Esses metadados não são recuperados pelo usuário final, mas são consultados pelo middleware de autorização antes de retornar qualquer resultado.

Camada 3: Filtros de Autorização em Tempo de Consulta

Quando um usuário submete uma busca semântica, o sistema RAG deve interceptar a consulta e aplicar filtros de autorização antes de recuperar os embeddings mais próximos:

1. Identificar o usuário (autenticação)
2. Determinar seus papéis/grupos (autorização)
3. Filtrar o espaço de busca para incluir apenas documentos onde:
   - A classificação é <= ao nível de acesso do usuário
   - O usuário (ou seu grupo) está na lista de permissões
4. Executar a busca semântica apenas dentro desse subconjunto filtrado
5. Retornar resultados com rastreabilidade completa

Empresa de consultoria financeira com RAG para análise de contratos implementou isso com Qdrant usando filtros estruturados:

query_filter = {
  "must": [
    {"key": "doc_classification", "match": {"value": "confidencial"}},
    {"key": "authorized_groups", "match": {"value": user_group}},
    {"key": "created_after", "range": {"gte": audit_period_start}}
  ]
}

results = vector_db.search(
  collection="contratos",
  query_vector=query_embedding,
  query_filter=query_filter,
  limit=5
)

Camada 4: Rastreabilidade e Auditoria Imutável

Cada consulta a um sistema RAG deve gerar um registro de auditoria imutável que inclua:

Quem: ID do usuário, IP, dispositivo
Quando: timestamp preciso da consulta
O quê: texto original da pergunta + embedding gerado
Resultado: IDs dos documentos recuperados, relevância de cada um
Autorização: se a consulta foi bloqueada (e por quê), se passou nos filtros
Ação subsequente: se o usuário visualizou o resultado, copiou, compartilhou

Em setores regulados, esses logs devem ser imutáveis e armazenados em um sistema separado (não apenas no banco vetorial), com retenção definida por política.

Casos de Uso Reais: Onde a Governança Falha e Como Corrigir

Caso 1: Banco com RAG para Análise de Políticas de Crédito

Problema: Gerentes de diferentes regiões usavam RAG para consultar políticas de crédito. O sistema retornava políticas de outras regiões com taxas e condições diferentes. Um gerente da região A acidentalmente ofereceu ao cliente uma taxa que era válida apenas na região B, gerando litígio.

Solução: Adicionar metadado "região_válida" a cada chunk de política. Filtrar consultas por região do usuário antes da busca semântica. Registrar cada consulta com a região consultada e o resultado retornado.

Caso 2: Clínica com RAG para Históricos de Pacientes

Problema: Médicos usavam RAG para consultar históricos de pacientes. O sistema retornava informações de pacientes similares (mesmos sintomas, mesma faixa etária) que não deveriam ser visíveis. Violação de LGPD.

Solução: Acoplar o ID do paciente e a relação médico-paciente aos embeddings. Antes de retornar qualquer resultado, verificar se o médico autenticado é responsável por aquele paciente. Se não, bloquear a recuperação. Registrar todas as consultas com intent do médico.

Caso 3: Empresa Jurídica com RAG para Busca em Contratos

Problema: Paralegais usavam RAG para buscar cláusulas em contratos. O sistema retornava trechos de contratos confidenciais de clientes concorrentes. Confidencialidade quebrada.

Solução: Classificar contratos por cliente. Filtrar busca por cliente autorizado. Adicionar camada de detecção de anomalia: se um usuário busca frequentemente por contratos de clientes concorrentes, alertar compliance.

Implementação Prática: Stack de Governança em RAG

Empresa brasileira de fintech implementou RAG com governança robusta usando:

Qdrant como banco vetorial (suporta metadados estruturados e filtros complexos)
Middleware de autorização customizado que intercepta consultas e aplica filtros
PostgreSQL para armazenar mapeamento de usuários → permissões → documentos
Elasticsearch para logs de auditoria (imutáveis, com retenção de 2 anos)
LangChain como orquestrador, com hooks de segurança antes/depois de cada busca

O fluxo:

Usuário submete pergunta
  ↓
Middleware valida autenticação e autorização
  ↓
Se bloqueado: registra em auditoria, retorna erro
  ↓
Se autorizado: cria embedding da pergunta
  ↓
Busca semântica com filtros de autorização aplicados
  ↓
Resultados retornados com rastreabilidade
  ↓
Registro imutável criado em Elasticsearch
  ↓
Dashboard de conformidade consolida logs diários

Custo inicial: ~3-4 meses de desenvolvimento. Custo de manutenção: ~1 engenheiro senior part-time. Benefício: zero incidentes de vazamento, auditoria completa, conformidade garantida.

O Que Isso Significa para Empresas Brasileiras

Empresas brasileiras que operam em setores regulados (financeiro com Banco Central, saúde com ANS/ANVISA, jurídico com OAB, seguro com SUSEP) não podem mais ignorar governança em RAG. A LGPD consolidou a responsabilidade: dados pessoais, mesmo em embeddings, são seu dever proteger.

O diferencial competitivo não está mais em ter RAG, mas em ter RAG que é simultaneamente poderoso e seguro. Empresas que conseguem oferecer assistentes de IA que consultam bases internas sem risco de vazamento, com auditoria completa e conformidade garantida, ganham confiança de clientes, reguladores e equipes.

Comece pequeno: escolha um caso de uso crítico (contratos, políticas, dados de clientes), implemente governança em camadas, valide em produção com auditoria robusta, depois expanda. RAG sem governança é uma bomba-relógio regulatória. RAG com governança é um ativo estratégico.

Governança de Dados em RAG: Como Manter Controle, Conformidade e Confiança Ao Escalar Consultas de IA