RAG corporativo com permissões: quem pode ler o quê

RAG corporativo com permissões é uma arquitetura em que o assistente de IA só recupera e resume documentos que a pessoa que perguntou já tem direito de ver na origem. RAG (retrieval-augmented generation) é a técnica que conecta um modelo de linguagem à base de conhecimento da empresa — políticas, contratos, planilhas, e-mails — para responder com dados internos. Sem controle de acesso deliberado, ele vira um atalho: o modelo encontra e cita material que o colaborador nunca poderia abrir diretamente. Este artigo explica onde aplicar o controle, quais falhas aparecem na prática e quais decisões cabem à diretoria. É para quem responde pelo risco de dados e pelo investimento em IA — se você precisa de uma visão mais ampla, comece pelo guia de governança de IA na prática.

O problema: a IA ignora as permissões que o seu sistema respeita

Um sistema de arquivos corporativo tem permissões: o financeiro vê a folha de pagamento, o jurídico vê o contencioso, o RH vê avaliações. Um RAG ingênuo copia tudo para um índice único e responde a qualquer pergunta com o melhor trecho encontrado, sem saber quem perguntou.

O resultado é um desvio de acesso: o colaborador não abre o arquivo da diretoria, mas pergunta ao assistente "qual foi a meta de remuneração variável deste ano?" e recebe a resposta. Não houve invasão — o sistema fez exatamente o que foi projetado a fazer. A falha é de governança: o controle que existia na origem não acompanhou o dado até a camada de IA.

A OWASP lista esse risco como Vector and Embedding Weaknesses (LLM08:2025) em seu Top 10 para aplicações com LLM. O texto destaca que, em ambientes em que várias classes de usuários ou aplicações compartilham o mesmo banco vetorial, há risco de vazamento de contexto entre usuários ou consultas, e recomenda controles de acesso granulares, armazenamento de vetores sensível a permissões, partição lógica dos dados e logs imutáveis das recuperações.

O que significa "RAG com permissões" na prática

Em RAG com permissões (permission-aware RAG), a recuperação aplica os direitos de acesso de cada usuário no momento da consulta. A Tarento define como a abordagem em que o sistema "aplica os direitos de acesso de cada usuário durante a recuperação, de modo que o modelo só vê e resume conteúdo que a pessoa já está autorizada a ver".

Isso exige três coisas:

1. Identidade propagada. O assistente precisa saber quem está perguntando — o mesmo login (SSO) usado nos sistemas de origem —, e não rodar com uma conta de serviço onipotente.
2. Permissão associada ao conteúdo. Cada trecho indexado carrega metadados de quem pode lê-lo (grupo, área, classificação).
3. Filtro aplicado antes de o modelo ver o texto. O que o usuário não pode ver nunca entra no contexto da resposta.

O ponto que a diretoria precisa reter: o controle não pode ficar dentro do modelo. Pedir ao modelo, no prompt, para "não revelar dados confidenciais" não é controle de acesso — é uma instrução que pode falhar e que a injeção de prompt pode contornar. O controle fica na camada de recuperação e na origem.

Onde aplicar o controle: antes ou depois da busca

A decisão de arquitetura mais importante é em que ponto o filtro de permissão acontece.

Abordagem	Como funciona	Risco	Quando usar
Filtro após a busca (pós-filtro)	A busca traz os trechos mais relevantes de toda a base; depois a aplicação remove os que o usuário não pode ver	Dado restrito já circulou pelo pipeline; uma falha no filtro, um log ou um caminho de erro pode expor	Protótipos e dados de baixa sensibilidade
Filtro durante a busca (pré-filtro)	Os metadados de acesso entram na própria consulta vetorial; trechos não autorizados nunca são recuperados	Exige indexar metadados de permissão com qualidade	Dados sensíveis e regulados
Índices separados por grupo	Cada área ou nível tem seu índice	Duplicação de dados e custo; difícil com permissões individuais	Poucos grupos bem definidos
Permissão validada na origem em tempo real	Antes de responder, o sistema checa o direito do usuário no sistema de identidade de origem	Mais latência e dependência das integrações	Dados críticos e permissões que mudam com frequência

A Tarento observa, na mesma análise, que o filtro aplicado depois da recuperação deixa o dado confidencial entrar no pipeline antes da filtragem, enquanto o controle na camada de recuperação evita que passagens não autorizadas sejam recuperadas — daí a preferência por esse desenho para dados regulados. A Guru descreve uma lógica semelhante: validar as permissões do usuário contra o provedor de identidade em mais de um ponto — herança dos controles da origem na indexação, verificação de identidade antes da recuperação e filtragem final antes da geração da resposta.

As seis falhas mais comuns em RAG corporativo

1. Conta de serviço com acesso total. O conector que alimenta o índice lê tudo e o assistente responde a todos com esse acesso.
2. Permissões copiadas e desatualizadas. A permissão é copiada para o índice na carga inicial; quando a pessoa muda de área ou sai da empresa, o índice não acompanha. A Tarento aponta esse desvio (drift) como modo de falha.
3. Metadados errados por falta de estrutura. A mesma análise cita a estimativa, amplamente repetida mas sem fonte primária atribuída, de que cerca de 80% dos dados corporativos são não estruturados; sem classificação e parsing corretos, o sistema anexa a permissão errada ao conteúdo errado. Trate o número como ordem de grandeza.
4. Documentos com permissão "aberta demais" na origem. O RAG não cria o problema, mas o revela: pastas compartilhadas com a empresa toda passam a ser encontráveis por pergunta em linguagem natural. A própria documentação da Microsoft sobre o Copilot é explícita: o Copilot só apresenta dados aos quais o usuário tem pelo menos permissão de visualização, e por isso é importante usar corretamente os modelos de permissão do SharePoint e de outros serviços. Ou seja: a higiene de permissões é pré-requisito, nem a melhor ferramenta a dispensa.
5. Logs e caches que guardam o texto restrito. O trecho foi filtrado da resposta, mas ficou registrado em log de depuração ou em cache compartilhado.
6. Ausência de trilha de auditoria. Sem registro de quem perguntou, o que foi recuperado e quais permissões foram aplicadas, não há como investigar um incidente nem provar conformidade.

Dados pessoais, LGPD e sigilo

Quando a base inclui dados pessoais — folha, avaliações, atendimento ao cliente, prontuário — o RAG passa a ser tratamento de dados pessoais, com as obrigações de segurança da LGPD (art. 46: medidas técnicas e administrativas para proteger os dados contra acessos não autorizados). O guia de LGPD e IA generativa detalha as bases legais; aqui o ponto é arquitetural: permissão por usuário no RAG é a forma operacional de cumprir o princípio da necessidade — cada pessoa acessa só o que precisa.

Além da LGPD, há sigilos contratuais e profissionais (acordos de confidencialidade, sigilo jurídico, informação privilegiada em empresas abertas) que não dependem de lei de dados e que um índice único tende a violar sem alarde.

Decisões da diretoria

Quem decide o investimento em IA precisa responder cinco perguntas antes de aprovar uma base de conhecimento corporativa:

1. Qual é a fonte da verdade das permissões? Diretório de identidade e sistemas de origem — não o índice de IA.
2. Quais classes de dado ficam fora do RAG, por ora? Em geral: remuneração individual, dados sensíveis, M&A e material sob sigilo, até haver controle comprovado.
3. Quem é o dono do índice? Alguém precisa responder por sincronização, retenção e auditoria — veja o papel descrito em controle de acesso a ferramentas de IA por perfil.
4. Como o acesso do assistente aparece no inventário? O assistente é um sistema de IA como outro e deve constar na gestão de identidade e no inventário de sistemas.
5. Qual a prova de funcionamento? Teste de adversário: usuários de diferentes perfis tentam extrair dados que não deveriam ver, com resultado registrado e guardrails de IA como camada complementar.

Checklist de implantação em cinco passos

1. Classifique e limpe as fontes. Antes de indexar, revise permissões abertas demais. A governança de dados para IA define a classificação.
2. Escolha o ponto de filtro. Pré-filtro com metadados de acesso para dados sensíveis; pós-filtro só como camada adicional.
3. Sincronize permissões continuamente. Mudanças de cargo, grupo e desligamentos devem refletir no índice em prazo definido, e esse prazo deve ser medido.
4. Registre tudo. Usuário, consulta, documentos recuperados e filtros aplicados, em log protegido — base para uma eventual auditoria de IA.
5. Teste antes de ampliar. Rode um piloto em uma área e um conjunto de dados, com teste de acesso indevido, e só então expanda.

Esse roteiro é parte da capacitação de times de tecnologia e de dados nos programas da Jetpacks. No método Flight Plan, o diagnóstico (Launchpad) mapeia onde a empresa pretende conectar IA à base de conhecimento, e o acompanhamento (Mission Control) mede se o uso respeita as regras. Veja o método.

Limitações

Este artigo descreve padrões de arquitetura, não uma implementação específica. Plataformas diferem na forma como herdam permissões da origem, e as fontes citadas incluem fornecedores com interesse comercial no tema. Os documentos citados são orientações públicas e não equivalem a teste de penetração do seu ambiente. A decisão final deve passar pelo time de segurança da informação.

A mesma lógica vale para o que o agente guarda entre sessões: veja memória de agentes de IA.

FAQ

O que é RAG corporativo?

É a técnica que conecta um modelo de linguagem a bases internas da empresa — documentos, wikis, e-mails, sistemas — para que ele responda com base nesse conteúdo em vez de depender só do que aprendeu no treinamento.

O RAG pode vazar documentos confidenciais?

Pode, se as permissões da origem não forem aplicadas na recuperação. O modelo responde com o que o sistema de busca entrega; se o índice é único e sem controle por usuário, qualquer pessoa pode receber trechos que não poderia abrir diretamente.

O que é permission-aware RAG?

É o RAG que aplica os direitos de acesso de cada usuário durante a recuperação, de modo que o modelo só veja conteúdo que a pessoa já está autorizada a ver. Também aparece como RAG com controle de acesso.

Basta pedir ao modelo, no prompt, para não revelar dados confidenciais?

Não. Instrução no prompt não é controle de acesso e pode ser contornada por injeção de prompt. O controle precisa ser aplicado na recuperação e na origem dos dados.

Onde o controle de acesso deve ser aplicado?

De preferência na camada de recuperação, com metadados de permissão associados a cada trecho e validação contra o sistema de identidade. O filtro apenas depois da busca deixa o dado restrito circular pelo pipeline e é mais frágil.

Preciso arrumar as permissões antes de implantar RAG?

Sim. O assistente expõe o que as permissões atuais já permitem. Pastas abertas à empresa toda se tornam fáceis de encontrar por perguntas em linguagem natural. A revisão de permissões é pré-requisito.

Como provar que o RAG respeita as permissões?

Com testes de acesso por perfil (tentativa de extrair dados restritos), trilha de auditoria das recuperações e revisões periódicas. Sem prova registrada, a conformidade é apenas uma suposição.

Conclusão: a IA deve herdar as regras, não contorná-las

O risco central de um RAG corporativo não é o modelo errar, e sim acertar demais — entregar a quem não deveria o que a empresa sempre protegeu. A resposta é arquitetural: identidade propagada, permissão no momento da busca, trilha de auditoria e higiene das fontes. Para entender o que sua empresa precisa ajustar antes de conectar IA à base de conhecimento, comece pelo diagnóstico gratuito da Jetpacks.