Um RAG mal montado é a forma mais rápida de fugir dados que jamais deveriam sair. O padrão clássico: indexas «toda a documentação», um utilizador pergunta algo inocente e o sistema devolve-lhe um fragmento de um documento a que essa pessoa não deveria ter acesso. Não é um bug exótico — é a arquitetura por defeito de quase todos os RAG de demo.
Permissões antes de embeddings
O controlo de acesso não é um filtro que se acrescenta no fim: vive na camada de recuperação. Antes de o modelo ver fosse o que for, o sistema já restringiu que fragmentos este utilizador concreto pode recuperar. A identidade manda; o embedding vem depois.
Particiona o índice por permissão
Não metemos tudo num único índice e rezamos. Segmentamos por nível de acesso e anexamos metadados de permissão a cada fragmento, de modo que a consulta só pode tocar no que corresponde a quem pergunta.
- Filtragem por identidade na recuperação, não na resposta.
- Índices ou partições segmentados por nível de acesso.
- Metadados de permissão em cada fragmento indexado.
- Auditoria de consultas: quem perguntou o quê e o que lhe foi devolvido.
Citação ou não serve
Cada resposta liga à sua fonte. Sem citação não há confiança nem rastreabilidade: o utilizador não pode verificar, e tu não podes auditar. Em enterprise, uma resposta sem fonte é uma resposta que não podes defender.
O que medimos
- Precisão de recuperação (traz o que é relevante?).
- Fugas de acesso: o objetivo é zero, e audita-se.
- Cobertura de citação: % de respostas com fonte verificável.
- Uptime e latência do pipeline.
É isto que faz um Senior AI Infrastructure Implementer: não «liga um RAG», faz deploy de um sistema de conhecimento que escala, cita e respeita as permissões — porque em enterprise um dado fugido não é um incidente técnico, é uma crise.