Sistemas RAG vazam dados: IA é tarefa de segurança

Um modelo de linguagem que responde sobre os seus documentos internos é, para muitas empresas, o primeiro benefício tangível da IA: propostas, manuais, cláusulas contratuais, tickets – respondidos sob demanda, em vez de procurados em estruturas de pastas. A técnica por trás disso chama-se Retrieval-Augmented Generation (RAG): o modelo recebe, para responder a uma pergunta, os trechos adequados dos seus documentos e formula a resposta a partir deles. O atrativo é evidente. O risco costuma ser negligenciado.

Pois o RAG é, em seu núcleo, um mecanismo de busca com um modelo de formulação à frente. E um mecanismo de busca sobre dados corporativos é apenas tão confiável quanto as permissões que ele aplica. Se um sistema RAG for construído sem carregar consigo os direitos de acesso do sistema de origem, acontece exatamente o que tem de acontecer: um usuário recebe conteúdos que jamais deveria ter visto. Isso não é um caso especial exótico, mas a falha de RAG mais frequente e mais cara.

O erro padrão: as permissões ficam para trás

Em um repositório de arquivos bem operado, uma lista de acesso decide quem pode abrir um documento. O vendedor vê suas propostas, não a folha de salários da diretoria. Na construção de um sistema RAG, porém, esses documentos são fragmentados, convertidos em vetores e armazenados em um banco de dados vetorial – e nesse ponto a permissão frequentemente se perde. O banco de dados vetorial então só conhece conteúdos, não mais direitos de acesso. Quem pergunta recebe como resposta o que combina em termos de conteúdo, não o que tem permissão de ver.

O projeto OWASP valorizou expressamente essa classe de erros em 2025. No atualizado OWASP Top 10 for LLM Applications, “Sensitive Information Disclosure” subiu para a 2ª posição, e com “Vector and Embedding Weaknesses” (LLM08) foi acrescentada uma categoria totalmente nova, que nomeia exatamente essas fraquezas específicas do RAG: busca manipulada, acesso que atravessa fronteiras de tenant e de permissão, a reconstrução de texto claro a partir de embeddings. A mensagem é inequívoca: quem emprega RAG abriu um novo campo autônomo de ataque e vazamento.

Dois padrões reais: o Copilot como objeto de estudo

Como isso se apresenta na prática pode ser estudado no Microsoft 365 Copilot – um dos sistemas RAG mais amplamente implantados que existem.

O primeiro padrão é a simples concessão excessiva de direitos. O Copilot responde com base naquilo a que um usuário pode acessar conforme a permissão. Se essas permissões foram concedidas de forma generosa por anos na empresa – o famigerado compartilhamento SharePoint “para todos na empresa” –, a IA torna esse passivo herdado subitamente visível e pesquisável. A prestadora de análise Concentric constatou que 15 por cento dos recursos críticos para o negócio estavam afetados por concessão excessiva e podiam ser visualizados por pessoas que não deveriam ter acesso. A IA não criou o problema. Ela apenas o tirou da cobertura.

O segundo padrão é o ataque direcionado à cadeia RAG. Sob o nome “EchoLeak” (CVE-2025-32711, CVSS 9.3), a equipe de segurança da Aim Labs descreveu em 2025 um ataque zero-click ao Microsoft 365 Copilot: um único e-mail preparado bastava – sem que o destinatário precisasse abri-lo ou clicar nele – para induzir o Copilot a reunir conteúdos internos do SharePoint, do OneDrive e do Teams e exfiltrá-los para um servidor externo. A Microsoft fechou a falha do lado do servidor e não relatou exploração em ambiente real. O caso permanece instrutivo: entrada não confiável – aqui um e-mail – conseguiu ultrapassar a fronteira para dados internos confiáveis. Um resultado de pesquisa correlato da University of Texas (“ConfusedPilot”, 2024) mostrou, além disso, como documentos infiltrados podem levar um sistema RAG a afirmações falsas, explorando configurações incorretas de controle de acesso.

Multi-tenant: o vazamento mais caro

O mais grave é quando um sistema RAG utiliza o mesmo banco de dados vetorial para vários clientes (tenants) – por exemplo, um prestador que torna conhecimento acessível para vários clientes. Sem uma separação rígida, os documentos de clientes distintos compartilham o mesmo espaço de busca, e a busca por similaridade não conhece fronteiras entre clientes. Uma solicitação do cliente A pode então retornar conteúdos do cliente B – não por causa de um hack espetacular, mas porque o banco de dados nunca aprendeu que existe uma fronteira.

Bancos de dados vetoriais foram, em muitos casos, projetados sem controle de acesso preciso por documento como função central. Praticantes relatam vazamento entre tenants em quase todas as consultas de teste, assim que a busca ocorre sem filtro. E as consequências não são abstratas: uma falha de controle de acesso em um banco de dados vetorial difundido expôs mais de 200.000 registros de dados de saúde. O vazamento cross-tenant, portanto, não é apenas um defeito técnico, mas um evento de proteção de dados, de responsabilidade e de reputação.

A correção não é mágica de IA, mas ofício

A boa notícia: as contramedidas são conhecidas. São os mesmos princípios que também fora da IA constituem uma arquitetura de segurança sólida – aplicados de forma consequente à cadeia RAG.

Arrumar primeiro as permissões. Antes de os dados fluírem para um sistema RAG, o caos de compartilhamentos precisa ser organizado. O RAG torna visíveis os compartilhamentos excessivos existentes; quem não os limpa antes exporta o problema para o modelo.
Levar o controle de acesso até o nível do documento. Cada trecho armazenado no banco de dados vetorial carrega seus metadados de permissão – usuários e grupos autorizados – como parte integrante. No momento da consulta, filtra-se em dois estágios: antes da busca, por meio de metadados; após a busca, por meio de uma verificação real de permissão contra o sistema de origem. Se os direitos mudarem, a nova permissão vale de imediato, não apenas após a próxima reindexação.
Separar os tenants de forma rígida. Em cenários multi-tenant, a fronteira de tenant é imposta no nível do índice vetorial, não apenas na lógica da aplicação acima dele.
Registrar sem lacunas. Cada consulta deixa uma linha: quem, qual solicitação, quais trechos entregues, quais negados. Sem esse registro não se pode nem esclarecer um incidente nem passar em uma auditoria.
Tratar entrada não confiável como tal. E-mails, arquivos carregados, conteúdos web externos não podem ultrapassar de forma descontrolada a fronteira de confiança para dados internos – a lição do EchoLeak.

Isso é, sobriamente considerado, controle de acesso clássico, classificação de dados, registro e segmentação de rede. A capacidade de construir uma arquitetura RAG que sobrevive a uma auditoria não é uma competência de IA. É uma competência de segurança.

Por que isso é uma tarefa de segurança, não uma brincadeira de IA

Quem trata um sistema RAG como um projeto de dados – “jogamos nossos documentos dentro e colocamos um modelo à frente” – constrói, de forma confiável, um vazamento. Quem o trata como um projeto de segurança faz, antes da primeira resposta, as perguntas certas: qual permissão tem quem pergunta? Quais metadados carrega cada trecho? Onde passa a fronteira de tenant? O que consta no registro? Essas perguntas decidem se do ganho de produtividade surge um incidente de proteção de dados.

É justamente aqui que os caminhos se separam. A IA soberana sobre os próprios dados não surge do fato de um modelo ser especialmente capaz, mas do fato de a arquitetura em torno do modelo aplicar as regras de acesso da empresa – de forma sólida, comprovável, auditável.

Como a sector7 apoia

Operamos modelos de linguagem privados protegidos e RAG gerenciado em nosso próprio parque de servidores na Alemanha – os dados não deixam o ambiente por nós controlado. A diferença decisiva está na nossa origem: a sector7 vem da prática de segurança e de redes. Construímos a cadeia RAG do mesmo modo como construímos perímetro e backups – com controle de acesso preciso por documento, separação rígida de tenants, registro sem lacunas e uma arquitetura que resiste a uma verificação. Isso conecta a nossa IA soberana diretamente à nossa prática de cibersegurança existente e à nossa experiência de engenharia certificada pelos fabricantes em Juniper, Cisco, HPE, F5, Fortinet e Palo Alto Networks. Não treinamos modelos base próprios e não prometemos uma força de trabalho de IA autônoma; grande capacidade de GPU obtemos por meio de parceiros soberanos. O que entregamos é aquilo que torna o RAG seguro: ofício de segurança. A partir de uma empresa de gestão própria em Solingen.

IA sobre os seus dados é uma tarefa de segurança: por que sistemas RAG vazam dados