RAG interno com permissões antes da busca

O problema não é apenas encontrar um trecho relevante

Um sistema de RAG interno combina busca em documentos e geração de texto. A busca semântica pode encontrar conteúdos relacionados mesmo quando as palavras da pergunta não aparecem literalmente. Em implementações baseadas em índices vetoriais, os arquivos são fragmentados, transformados em representações pesquisáveis e associados a metadados que podem ser usados em filtros. Isso resolve a descoberta, mas não resolve sozinho a autorização.

O erro arquitetural mais perigoso é buscar em todo o acervo e tentar remover resultados proibidos depois. A fonte citada não estabelece, por si só, os riscos específicos de registros e respostas intermediárias descritos aqui. Como recomendação de segurança independente, trate a permissão como uma condição da busca, não como uma limpeza posterior, pois informações restritas poderiam entrar no contexto do modelo, em logs, métricas ou respostas intermediárias.

• Identidade: quem está fazendo a pergunta?
• Escopo: quais documentos essa pessoa pode consultar agora?
• Evidência: quais trechos sustentam a resposta?
• Decisão: há base suficiente para responder ou é preciso recusar?

Fontes e referências: [1]

Fluxo proposto: autorização antes da recuperação

O fluxo começa fora do modelo. O sistema de identidade fornece um identificador de usuário ou serviço, grupos, função, região e outros atributos necessários para a decisão. Como recomendação independente de implementação, além do que é estabelecido pela fonte citada, um serviço de autorização pode converter esses dados em um filtro de busca. Por exemplo, ele pode permitir documentos com classificação para uso interno, da área de Recursos Humanos e da região Sul, desde que o usuário pertença ao grupo correspondente.

Só depois dessa etapa o sistema consulta o índice. Cada documento precisa carregar metadados de controle, como proprietário, área, classificação, região, vigência e identificador da política de acesso. O filtro deve ser aplicado no mecanismo de recuperação, antes que os trechos sejam selecionados para o contexto. Se o mecanismo não oferecer esse tipo de restrição, a alternativa é separar índices por domínio de acesso ou interpor uma camada confiável que entregue apenas identificadores autorizados ao buscador.

Depois da busca, a aplicação deve validar novamente os resultados retornados. Como recomendação independente de implementação, além do que é estabelecido pela fonte citada, essa segunda verificação pode detectar documentos mal classificados, permissões alteradas e erros de integração. Se houver qualquer resultado sem autorização confirmada, ele deve ser descartado e o evento registrado para investigação técnica, sem enviar seu conteúdo ao modelo.

• Autenticar o solicitante.
• Calcular permissões no serviço de autorização.
• Traduzir permissões em filtros de atributos ou em um conjunto de índices autorizados.
• Executar a busca semântica e, quando necessário, combinar termos exatos.
• Validar a autorização de cada resultado antes de montar o contexto.

Fontes e referências: [1]

Evidência precisa acompanhar a resposta

O modelo não deve receber apenas texto solto. Cada trecho deve permanecer associado ao arquivo de origem, ao identificador do documento, à seção, à versão, à data de vigência e aos atributos que justificaram sua inclusão. Na resposta final, a aplicação pode apresentar uma indicação legível da fonte, como nome da política, versão e seção. O objetivo não é expor o acervo, mas permitir que o usuário entenda de onde veio a afirmação autorizada.

Também é útil separar duas decisões. A primeira é relevância: o trecho parece responder à pergunta? A segunda é suficiência: os trechos disponíveis sustentam uma resposta completa e atual? Um resultado semanticamente próximo pode mencionar o assunto sem estabelecer a regra solicitada. O sistema deve exigir evidência suficiente para cada afirmação importante, especialmente quando há documentos conflitantes ou versões diferentes.

Recomenda-se definir um formato estruturado para a saída interna, com campos como resposta, fontes, lacunas, conflito detectado e decisão de recusa. Isso reduz a liberdade do modelo para inventar referências ou misturar instruções encontradas nos próprios documentos com regras do sistema.

• Exibir somente fontes que foram usadas e autorizadas.
• Preferir a versão vigente quando a vigência estiver disponível.
• Sinalizar conflito entre políticas, em vez de escolher silenciosamente.
• Não transformar o nome de um arquivo em prova de que seu conteúdo sustenta a resposta.

Fontes e referências: [1][2]

Recusar é uma saída normal do sistema

A recusa deve acontecer quando não há evidência autorizada, quando os trechos são insuficientes, quando a pergunta exige uma interpretação que os documentos não oferecem ou quando existem versões incompatíveis sem critério claro de precedência. Uma resposta curta e específica é melhor que uma formulação plausível sem base. Ela pode informar que não foi encontrada uma política autorizada suficiente e indicar quais dados faltam, sem revelar documentos bloqueados.

O prompt do modelo deve estabelecer que documentos recuperados são dados, não instruções operacionais. Um texto interno pode conter frases que tentam alterar o comportamento do sistema, solicitar dados de outros funcionários ou induzir chamadas a ferramentas. A aplicação deve manter regras de autorização fora do controle do modelo, passar entradas não confiáveis como dados e usar formatos estruturados para limitar o que pode sair de cada etapa. Essas medidas reduzem o risco de injeção indireta, mas não eliminam a necessidade de limitar acessos e testar casos adversariais.

Não use a recusa para mascarar uma falha silenciosa. Diferencie ausência de documentos, ausência de permissão, baixa relevância, conflito de versões e erro técnico. Essas categorias orientam a mensagem ao usuário e aceleram a correção do catálogo.

• Sem trecho autorizado, não afirmar a regra.
• Sem cobertura suficiente, explicar a lacuna.
• Com conflito, apresentar o conflito sem escolher por conta própria.
• Com falha técnica, informar que a consulta não pôde ser concluída.

Fontes e referências: [2]

Exemplo hipotético: consulta a uma política interna

Imagine uma empresa com políticas de viagens separadas por país e nível de cargo. Uma pessoa pergunta: “Posso solicitar reembolso de hospedagem para uma viagem ao Chile no próximo mês?”. O sistema identifica a pessoa, consulta seus grupos e descobre que ela pode acessar políticas de viagens do Brasil e do Chile, mas não documentos de diretoria. O serviço de autorização gera um filtro para área de viagens, país Chile, classificação permitida e documentos vigentes na data da viagem.

A busca encontra a política de hospedagem do Chile e um procedimento geral de prestação de contas. A aplicação envia ao modelo somente os trechos autorizados, junto dos identificadores das fontes e da data de vigência. A resposta pode explicar o limite ou a condição descrita nesses trechos e apontar os nomes das políticas usadas. Ela não deve concluir que um gasto é permitido apenas porque a política menciona hospedagem.

Agora considere que a política encontrada cobre hospedagem, mas não esclarece se a viagem precisa de aprovação prévia. O resultado correto é responder apenas sobre o que está documentado e declarar que a exigência de aprovação não foi localizada na base autorizada. Se houver uma política antiga e uma atual com regras diferentes, o sistema deve sinalizar o conflito ou aplicar uma regra de precedência previamente definida. Esse exemplo é apenas de desenho de produto, não orientação jurídica nem interpretação normativa.

• Pergunta autorizada não significa resposta automaticamente autorizada.
• A fonte deve sustentar a afirmação específica, não apenas o tema geral.
• A resposta deve separar regra encontrada, lacuna e eventual conflito.

Como decidir se o desenho está pronto

Antes de liberar o sistema, construa um conjunto de testes com perguntas comuns, documentos semelhantes, permissões cruzadas, usuários sem acesso, versões antigas, perguntas ambíguas e tentativas de instrução dentro dos arquivos. Meça separadamente recuperação, controle de acesso, fidelidade às fontes e comportamento de recusa. Uma única nota geral pode esconder um vazamento de permissão ou uma resposta sem evidência.

Os testes devem rodar a cada mudança relevante no particionamento, nos metadados, no ranking, no prompt ou no modelo. Como recomendação de desenho independente, registre a consulta, a identidade usada para autorização, os filtros aplicados, os identificadores dos documentos retornados, a decisão de recusa e as fontes apresentadas. Evite registrar conteúdo restrito além do necessário para diagnosticar o sistema.

A avaliação deve refletir o uso real, incluindo perguntas curtas, erros de digitação, múltiplas intenções e tentativas de obter informações de outro grupo. A documentação de avaliação recomenda definir o objetivo, reunir um conjunto representativo, escolher métricas específicas e repetir os testes continuamente, em vez de confiar na impressão de que as respostas parecem boas.

• Teste usuários com permissões diferentes para a mesma pergunta.
• Verifique que documentos revogados deixam de aparecer depois da atualização.
• Teste se cada afirmação importante possui uma fonte autorizada.
• Conte recusas corretas separadamente de erros técnicos.
• Inclua ataques de injeção dentro de documentos e perguntas.

Fontes e referências: [3]