Blog

Nossas últimas novidades

Tempo de Leitura

min

Dados sensíveis em RAG: como evitar vazamento de informação em chatbots e buscadores com IA

Como proteger dados sensíveis em soluções com RAG: classificação, filtragem por permissões, redaction de PII, logs seguros e checklist de segurança para chatbots e assistentes.

25 de fevereiro de 2026

O maior risco de um RAG não é “errar a resposta”.
É responder certo para a pessoa errada.

Quando você conecta um LLM a documentos internos (políticas, contratos, planilhas, tickets, wikis), você ganha produtividade — e também abre uma porta para um risco clássico: divulgação indevida de informação.

A boa notícia é que dá para reduzir esse risco bastante com engenharia e processo. Este artigo resume um conjunto de práticas que funcionam bem em produtos reais, sem depender de “magia” no prompt.

O que você vai ver aqui

Onde vazamentos acontecem em soluções de RAG (mesmo quando “parece seguro”)
Controles que dão mais resultado: permissões, minimização e redaction
Como tratar embeddings e vetores como dados sensíveis
Boas práticas de logs e observabilidade sem expor PII
Checklist final de segurança

Se você ainda não tem uma visão clara do pipeline de RAG, vale ler antes: RAG na prática.

Onde o vazamento realmente acontece

Em geral, o vazamento não acontece porque “o modelo é malvado”. Acontece porque o sistema:

indexa mais dados do que deveria
recupera dados sem respeitar permissões
loga ou armazena dados sensíveis em lugares inesperados
permite que o LLM “faça coisas” demais (agência excessiva)

A OWASP coloca riscos de divulgação de informação sensível e fraquezas em vetores/embeddings como pontos importantes em aplicações com LLM (especialmente quando há RAG).

Princípios simples que evitam a maioria dos problemas

1) Minimize: nem tudo precisa virar embedding

A primeira pergunta é sempre: “isso precisa estar no RAG?”

Conteúdos que normalmente não deveriam ir para a base de conhecimento do chatbot:

segredos (tokens, chaves, senhas, certificados)
dados pessoais desnecessários (CPF, telefone, endereço completo)
informações que exigem autorização forte (salários, avaliações, dados médicos)
qualquer coisa que você não quer ver em um print

Se a informação é necessária para uma tarefa específica, prefira expor por ferramentas (tool calling) com controle de acesso e auditoria, em vez de “jogar no embedding”. (Veja: Tool calling: integração segura.)

2) Classifique dados antes de indexar

Mesmo uma classificação simples já ajuda:

Público
Interno
Confidencial
Restrito

Use essa classificação como metadado e aplique políticas:

“Restrito não entra em RAG”
“Confidencial entra com ACL e redaction”
“Interno entra, mas só para usuários autenticados”

3) ACL no retrieval: a autorização acontece na busca, não no prompt

Um erro comum é tentar resolver permissão no prompt (“não mostre X”).
Isso é frágil.

O padrão mais robusto:

cada chunk indexado carrega um metadado de permissão (por grupo, papel, usuário, tenant)
na busca, você filtra por ACL antes de montar o contexto

Assim, o LLM nunca vê o que não deveria ver.

Exemplo (conceitual) de filtro por metadados:

{
  "query": "Qual é a política de reembolso?",
  "filters": {
    "language": "pt-BR",
    "tenant_id": "empresa-123",
    "roles_any": ["financeiro", "gestor"]
  }
}

4) Redaction: remova PII do conteúdo e também do log

Redaction (ou mascaramento) é remover/anonimizar partes sensíveis.

Você pode aplicar em dois lugares:

Antes de indexar: remove PII do texto que vai virar chunk/embedding
Antes de responder/logar: se algum dado sensível entrou no contexto, evita que apareça na resposta ou nos logs

Dica prática: comece com regras simples (regex + listas) e evolua para ferramentas de DLP quando fizer sentido.

5) Trate embeddings como sensíveis

Embeddings não “guardam texto” de forma trivial, mas representam o conteúdo e podem vazar contexto (além de permitir recuperação do conteúdo por busca). Em ambientes com compliance, é razoável considerar:

criptografia em repouso
controle de acesso forte ao banco vetorial
segregação por tenant/ambiente
retenção e política de descarte

6) Logs e observabilidade sem vazamento

Você precisa de telemetria para melhorar o RAG, mas sem capturar PII:

Boas práticas:

logar IDs (documentid, chunkid) em vez de texto completo
redigir/mascarar antes de salvar prompt/contexto
separar “logs de depuração” (curta retenção, acesso restrito) de “logs de operação”
nunca logar tokens/segredos

Atenção extra: prompt injection via documentos (injeção indireta)

Em RAG, o conteúdo recuperado vira “entrada” para o LLM.
Se um documento contiver instruções maliciosas (ou apenas erradas), o modelo pode ser induzido a: