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 a pedido, 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 excertos adequados dos seus documentos e formula a resposta a partir deles. O atrativo é evidente. O risco costuma ser negligenciado.

Pois o RAG é, no seu núcleo, um motor de pesquisa com um modelo de formulação à frente. E um motor de pesquisa sobre dados empresariais é apenas tão fiável quanto as permissões que aplica. Se um sistema RAG for construído sem levar consigo os direitos de acesso do sistema de origem, acontece exatamente o que tem de acontecer: um utilizador 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

Num repositório de ficheiros bem gerido, uma lista de acesso decide quem pode abrir um documento. O comercial vê as suas propostas, não a folha de salários da administração. Na construção de um sistema RAG, porém, esses documentos são fragmentados, convertidos em vetores e armazenados numa base de dados vetorial – e nesse ponto a permissão perde-se frequentemente. A base de dados vetorial passa então a conhecer apenas conteúdos, já não direitos de acesso. Quem pergunta recebe como resposta o que corresponde em termos de conteúdo, não o que tem permissão para ver.

O projeto OWASP valorizou expressamente esta 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 estas fraquezas específicas do RAG: pesquisa 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 utiliza RAG abriu um novo campo autónomo de ataque e de fuga de dados.

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

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

O primeiro padrão é a simples concessão excessiva de direitos. O Copilot responde com base naquilo a que um utilizador pode aceder conforme a permissão. Se essas permissões foram concedidas de forma generosa durante anos na empresa – a famigerada partilha SharePoint «para todos na empresa» –, a IA torna esse passivo herdado subitamente visível e pesquisável. A empresa 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. Apenas o tirou da sombra.

O segundo padrão é o ataque direcionado à cadeia RAG. Sob o nome «EchoLeak» (CVE-2025-32711, CVSS 9.3), a equipa de segurança da Aim Labs descreveu em 2025 um ataque zero-click ao Microsoft 365 Copilot: bastava um único e-mail preparado – sem que o destinatário precisasse de o abrir ou de 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: uma entrada não fiável – aqui um e-mail – conseguiu ultrapassar a fronteira para dados internos fiáveis. Um resultado de investigação relacionado 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 controlo de acesso.

Multi-tenant: a fuga de dados mais cara

O mais grave é quando um sistema RAG utiliza a mesma base de dados vetorial para vários clientes (tenants) – por exemplo, um prestador que torna conhecimento acessível a vários clientes. Sem uma separação rigorosa, os documentos de clientes distintos partilham o mesmo espaço de pesquisa, e a pesquisa por semelhança não conhece fronteiras entre clientes. Um pedido do cliente A pode então devolver conteúdos do cliente B – não por causa de um hack espetacular, mas porque a base de dados nunca aprendeu que existe uma fronteira.

As bases de dados vetoriais foram, em muitos casos, concebidas sem controlo de acesso preciso por documento como função central. Profissionais da área relatam fugas entre tenants em quase todas as consultas de teste, assim que a pesquisa ocorre sem filtro. E as consequências não são abstratas: uma falha de controlo de acesso numa base de dados vetorial muito difundida expôs mais de 200.000 registos de dados de saúde. A fuga 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 é magia 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 partilhas tem de ser organizado. O RAG torna visíveis as partilhas excessivas existentes; quem não as limpa antes exporta o problema para o modelo.
Levar o controlo de acesso até ao nível do documento. Cada excerto armazenado na base de dados vetorial transporta os seus metadados de permissão – utilizadores e grupos autorizados – como parte integrante. No momento da consulta, filtra-se em duas fases: antes da pesquisa, por meio de metadados; após a pesquisa, 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 rigorosa. Em cenários multi-tenant, a fronteira de tenant é imposta ao nível do índice vetorial, não apenas na lógica da aplicação acima dele.
Registar sem lacunas. Cada consulta deixa uma linha: quem, que pedido, que excertos entregues, quais negados. Sem esse registo não se pode nem esclarecer um incidente nem passar numa auditoria.
Tratar entradas não fiáveis como tal. E-mails, ficheiros 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.

Isto é, sobriamente considerado, controlo de acesso clássico, classificação de dados, registo 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.

Porque é que isto é uma tarefa de segurança, não uma brincadeira de IA

Quem trata um sistema RAG como um projeto de dados – «metemos lá os nossos documentos e pomos um modelo à frente» – constrói, com toda a certeza, uma fuga de dados. Quem o trata como um projeto de segurança faz, antes da primeira resposta, as perguntas certas: que permissão tem quem pergunta? Que metadados transporta cada excerto? Por onde passa a fronteira de tenant? O que consta no registo? Estas perguntas decidem se do ganho de produtividade resulta um incidente de proteção de dados.

É precisamente aqui que os caminhos se separam. A IA soberana sobre os próprios dados não resulta do facto de um modelo ser especialmente capaz, mas do facto 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 gerido no nosso próprio parque de servidores na Alemanha – os dados não saem do 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 que construímos perímetro e backups – com controlo de acesso preciso por documento, separação rigorosa de tenants, registo sem lacunas e uma arquitetura que resiste a uma verificação. Isso liga 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 obtemo-la através de parceiros soberanos. O que entregamos é aquilo que torna o RAG seguro: ofício de segurança. A partir de uma empresa gerida pelo proprietário em Solingen.

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