IA aplicada

RAG com controle de acesso: cada usuário vê só o que pode

Por Audizio Nunes · 8 de outubro de 2026

Num RAG, a busca devolve os trechos mais parecidos com a pergunta, sem saber quem está perguntando. Se a aplicação não aplicar as permissões antes da geração, um trecho que o usuário não poderia abrir no sistema original pode entrar na resposta.

O problema: a busca não conhece o usuário

A busca vetorial mede semelhança, não autorização. Se a informação está indexada, qualquer pergunta parecida com ela pode recuperá-la. Por isso o RAG não cria problemas de permissão, mas pode deixá-los muito mais fáceis de encontrar: um documento mal protegido, que ninguém achava no meio de pastas, passa a aparecer numa resposta.

No Amazon Bedrock Knowledge Bases, a AWS documenta o filtro de metadados como a forma de restringir o que a recuperação entrega ao modelo. A documentação também deixa claro de quem é a responsabilidade: cabe à aplicação enviar, em cada chamada, o filtro correto para o usuário que está perguntando.

Como o filtro de metadados funciona

Cada documento da fonte pode ter um arquivo de metadados ao lado dele no Amazon S3. O arquivo tem o mesmo nome do documento com .metadata.json no final, fica na mesma pasta e não pode passar de 10 KB. Um exemplo com dois atributos de permissão (os nomes dos atributos são escolha sua):

{
  "metadataAttributes": {
    "departamento": {
      "value": { "type": "STRING", "stringValue": "vendas" },
      "includeForEmbedding": false
    },
    "classificacao": {
      "value": { "type": "STRING", "stringValue": "interno" },
      "includeForEmbedding": false
    }
  }
}

O campo includeForEmbedding define se o atributo entra no texto que gera o vetor. Com false, o atributo fica guardado e disponível para filtro, mas não influencia a busca semântica, o que faz sentido para atributos de permissão.

Na consulta, o filtro vai no campo filter, dentro de vectorSearchConfiguration (em retrievalConfiguration), nas operações Retrieve e RetrieveAndGenerate. A AWS documenta operadores como equals e in, e os operadores lógicos andAll e orAll combinam condições, até 5 por grupo. O filtro abaixo devolve apenas trechos de documentos do departamento de vendas classificados como públicos ou internos:

"filter": {
  "andAll": [
    { "equals": { "key": "departamento", "value": "vendas" } },
    { "in": { "key": "classificacao", "value": ["publico", "interno"] } }
  ]
}

De onde vem o filtro

A regra mais segura é montar o filtro no servidor, a partir da identidade autenticada do usuário, e nunca aceitá-lo como parâmetro vindo do navegador. A AWS cita exemplos desse padrão: um identificador de acesso em um chatbot de RH, tokens de usuário em uma plataforma B2B e grupos de trabalho com nível de privilégio vindos de um login único. Na prática, o fluxo tem quatro passos:

1. Autenticar o usuário no sistema da empresa.
2. Traduzir os grupos e papéis dele em valores dos atributos de metadados.
3. Montar o filtro no servidor e enviá-lo na chamada de recuperação.
4. Registrar o resultado, com identificadores e pontuações em vez do conteúdo sensível, para auditoria.

O que o filtro não resolve sozinho

• A permissão de origem continua valendo. O filtro reflete os metadados indexados. Se a permissão de um documento mudou no sistema de origem, o arquivo de metadados precisa ser atualizado e a fonte sincronizada de novo.
• Todo documento precisa dos atributos. Defina antes da indexação o que fazer com documentos sem atributos de permissão, e trate a ausência como erro, não como acesso livre.
• Dados pessoais exigem base legal. A LGPD pede finalidade e base legal para tratar dados pessoais. Alinhe isso com o jurídico antes de indexar reuniões, chamados e outras fontes sensíveis.

Como testar o controle de acesso

A operação Retrieve devolve os trechos recuperados, com documentId, location, metadata e score, sem gerar resposta. Isso permite testar o filtro sem depender do texto do modelo. Monte uma matriz de testes com perfis de usuário e perguntas:

• Positivo: uma pergunta que o perfil deve conseguir responder com documentos que ele pode ver.
• Negativo: uma pergunta cuja resposta só existe em um documento restrito. O esperado é nenhum trecho desse documento e, na aplicação, uma resposta dizendo que a informação não foi encontrada.
• Fronteira: perfis com acesso parcial, como quem vê documentos internos mas não os confidenciais, e documentos que mudaram de classificação.

Repita a matriz a cada mudança no esquema de metadados ou na regra que monta o filtro. Quem constrói o sistema pode depurar pelos identificadores, metadados e pontuações, enquanto as áreas donas dos dados escrevem as perguntas e avaliam as respostas.

Citações: toda resposta aponta a fonte

Na operação RetrieveAndGenerate, a resposta vem com citations, que ligam trechos do texto gerado às fontes recuperadas. Mostre essas referências ao usuário e registre-as: uma afirmação importante sem fonte deve ser tratada como pouco confiável.

Para o fluxo completo, as fontes e o custo, veja RAG com Amazon Bedrock em .NET. Se a aplicação também será levada para a nuvem, veja como migrar uma aplicação .NET para AWS.