Permissões RAG para Chatbots de Websites: Controlar o Acesso a Documentos em Segurança

Um chatbot de website pode combinar respostas de páginas de FAQ, documentação de produtos e fontes de conhecimento internas. Isso é útil - até que essa mesma base de conhecimento contenha conteúdos que não se destinam a todas as pessoas. Nesses casos, a segurança da resposta não depende apenas da qualidade do modelo de linguagem, mas do passo de recuperação anterior: Que documentos pode esta consulta concreta visualizar?

As permissões RAG relacionam identidades, funções ou grupos verificados com metadados em documentos. O chatbot recebe apenas fontes pré-filtradas. O objetivo é deliberadamente restrito: Não é o modelo que deve decidir com base no prompt se algo é confidencial. A aplicação limita o contexto permitido, documenta essa decisão e escolhe um fallback seguro em caso de incerteza.

Por que as regras de prompt não substituem o controlo de acesso

Uma instrução de sistema como "Não forneças informações internas" é útil, mas não constitui uma camada de permissão. Se um documento não autorizado já entrar no contexto, a resposta pode resumi-lo, revelá-lo indiretamente ou reconstruí-lo mediante insistência. Da mesma forma, uma verificação de texto posterior chega tarde demais e é propensa a erros. A segurança começa, portanto, antes da geração e, idealmente, antes da ordenação dos resultados.

O Azure AI Search descreve o Security Trimming como um padrão de filtro: os documentos contêm valores de identidade ou grupo; a consulta inclui apenas os principais da pessoa que faz o pedido. O Amazon Bedrock indica de forma semelhante que os filtros de recuperação baseados em ACL não substituem a autenticação. A sua aplicação deve primeiro verificar a identidade de forma fiável e transmitir apenas um contexto verificado.

Os quatro pilares de uma solução sólida

1. Verificar a identidade e a sessão no lado do servidor

Uma janela de chat pública normalmente não tem direitos sobre documentos. Só pode aceder a fontes públicas. No entanto, num portal de clientes ou área de colaboradores, a pessoa é identificada através do login existente. Leia a função, organização e grupos relevantes no lado do servidor a partir da sessão ou de um token assinado. Nunca confie num campo enviado livremente pelo navegador, como role=admin, ou numa mensagem de chat que alegue uma filiação.

2. Manter metadados de permissão em cada fonte

Cada fragmento (chunk) precisa, juntamente com o texto, URL e data de atualização, de uma informação de acesso compreensível: como audience=public, um ID de cliente (tenant), uma lista de grupos permitidos ou uma classificação. Estes metadados têm de provir da mesma fonte de negócio que a permissão do documento. Uma folha de cálculo separada que é atualizada apenas ocasionalmente cria divergências perigosas. Para novos documentos e alterações nas permissões de grupo, a sincronização de metadados deve pertencer ao fluxo de trabalho de publicação ou de rastreio (crawl).

3. Filtrar antes do ranking

A consulta constrói um filtro a partir do contexto verificado. Só depois disso são avaliados os resultados semânticos ou híbridos. Desta forma, um manual confidencial não pode sobressair como um resultado altamente relevante para depois ser removido. Em cenários com múltiplos clientes, o ID de cliente é um filtro obrigatório e não um mero sinal de ranking. Para dados pessoais ou especialmente protegidos, recomenda-se adicionalmente uma área de dados dedicada em vez de uma coleção partilhada e apenas logicamente filtrada.

4. Registas fontes e decisões

Para suporte e análise de incidentes, as transcrições do chat não chegam. Por cada pedido, deve ser possível rastrear quais os atributos de identidade não sensíveis usados para construir o filtro, qual a classe de filtro aplicada, quantos resultados restaram após o filtro e quais as fontes que chegaram efetivamente ao prompt. Não armazene conteúdos completos ou tokens desnecessários. Um evento de auditoria com minimização de dados permite identificar erros sem transformar a monitorização numa segunda fuga de informação.

Um fluxo prático para equipas de websites

1. Atribua cada fonte de conhecimento a um público-alvo claro: público, cliente, parceiro, equipa interna ou um cliente específico.
2. Defina quais as alegações de sessão (claims) que comprovam esse público-alvo. Grupos provenientes do sistema de identidade são mais robustos do que dados de formulários livremente preenchidos.
3. Aplique esses claims no lado do servidor ao filtro de recuperação e permita apenas um conjunto reduzido e conhecido de campos de filtro.
4. Execute uma comparação a cada rastreio (crawl): documentos novos, alterados e removidos também precisam de metadados de permissão atualizados.
5. Forneça ao modelo apenas os resultados filtrados, acompanhados de uma instrução clara para não adivinhar informações em falta.
6. Em caso de ausência de resultados, fontes contraditórias ou permissões incertas, reencaminhe para um canal de contacto seguro.

Este fluxo complementa a estruturação descrita no nosso artigo sobre Chunking em RAG: Bons fragmentos melhoram a precisão dos resultados, mas não substituem o controlo de acesso. Da mesma forma, manter as fontes atualizadas continua a ser essencial; um estado de permissões desatualizado representa simultaneamente um problema de qualidade e de segurança.

Erro comum: Filtrar após a recuperação

Uma arquitetura incorreta muito frequente é a seguinte: O sistema recupera os dez melhores resultados, verifica depois os seus rótulos e remove os documentos problemáticos. Isto pode parecer suficiente à primeira vista, mas falha devido a efeitos secundários. O resultado não autorizado pode já surgir em registos (logs), caches ou numa saída de depuração. Além disso, a sua pontuação altera a seleção dos restantes resultados. A melhor abordagem é um filtro no pedido de recuperação que apenas admita como candidatos os documentos autorizados.

Outro erro comum é confiar cegamente na funcionalidade de ACL de um fornecedor. A documentação do fabricante pode indicar claramente que um serviço considera as ACLs na recuperação, mas não verifica por si próprio a autenticidade do contexto do utilizador fornecido. Por isso, verifique com precisão: Quem autentica a pessoa? De onde vêm os grupos? Quando são as permissões sincronizadas com o sistema de recuperação? O que acontece quando faltam metadados?

Fail closed: O que deve acontecer em caso de incerteza

Se faltar um claim, se uma fonte não estiver sincronizada ou se ocorrer um erro na recuperação, o chatbot não deve tentar uma pesquisa mais ampla. Utilize uma resposta neutra: O conteúdo solicitado não está disponível no contexto de acesso atual; um contacto humano pode verificar o acesso. Isto não é uma fraqueza da experiência de conversação (UX), mas sim um limite honesto. O artigo sobre Transição Humana (Human Handoff) mostra como desenhar este reencaminhamento de forma concreta e sem becos sem saída.

Para conteúdos públicos, aplica-se a mesma ideia a uma escala menor: Se as fontes disponíveis não forem suficientes, o bot deve assumir a incerteza, oferecer links verificados ou indicar um canal de contacto - em vez de inventar detalhes plausíveis. Isto reduz as alucinações e impede que uma resposta aparentemente útil solicite autorizações incorretas.

Casos de teste obrigatórios antes do lançamento

Um teste de permissões não é uma verificação pontual de administração. Crie um conjunto de testes de referência (Golden Set) com perguntas idênticas para várias funções: visitante, cliente registado, parceiro autorizado, utilizador bloqueado e administrador. Para cada combinação, defina as fontes esperadas e não apenas o texto de resposta esperado. Teste também mudanças de grupo, sessões expiradas, documentos eliminados, metadados de ACL ausentes e falhas no serviço de recuperação.

Controle pelo menos quatro aspetos nos resultados: Nenhuma URL ou ID de documento não autorizado entra no contexto; as fontes permitidas permanecem acessíveis; a resposta não cita conteúdos de documentos filtrados; e o fallback permanece compreensível. Adicione estas verificações aos seus testes de qualidade de resposta, para que a segurança e a qualidade funcional sejam medidas em conjunto.

Implementar a proteção de dados e a transparência de forma pragmática

Os próprios dados de permissão precisam de proteção. Utilize IDs técnicos estáveis em vez de nomes em texto claro nos metadados de recuperação. Limite os registos de auditoria à finalidade, período de tempo e atributos estritamente necessários. Informe os utilizadores de forma clara quando um chatbot acede à área autenticada e disponibilize um meio humano para questões de acesso. Este artigo não substitui aconselhamento jurídico individual; os prazos de conservação concretos e as bases legais dependem do contexto de aplicação.

A nível técnico, vale a pena ter responsabilidades bem definidas: Os proprietários de conteúdo gerem os públicos-alvo, a equipa de identidade é responsável pelos claims e validação de sessão, e a equipa de produto mantém os filtros e fallbacks testados. Dessa forma, a base de conhecimento não se torna um repositório descontrolado, mas sim uma fonte com alcance rastreável.

Lista de verificação antes de entrar em produção

• Cada fonte não pública está associada a uma função, grupo ou ID de cliente?
• O contexto da consulta provém de uma identidade verificada no lado do servidor?
• O filtro atua antes da recuperação e do ranking?
• As alterações de permissões e os rastreios (crawls) são sincronizados em conjunto?
• Existem testes de regressão baseados em funções com fontes esperadas?
• Qualquer estado desconhecido ou com falha resulta num reencaminhamento seguro?
• Os registos são económicos em dados e suficientes para análise de erros?

Conclusão

Um bom chatbot de website não responde a todas as perguntas para todas as pessoas. Ele exibe apenas fontes que correspondem ao contexto de acesso verificado e mantém-se deliberadamente reservado em caso de dúvida. Comece com uma matriz de fontes reduzida, um filtro no lado do servidor e algumas funções de teste claras. Depois, pode expandir gradualmente os metadados de permissão, auditorias e sincronização - sem delegar a segurança a formulações de prompts.

Fontes

• Microsoft Learn: Security Filter Pattern in Azure AI Search
• Microsoft Learn: Document-level access control in Azure AI Search
• Amazon Bedrock: ACL awareness enablement
• Amazon Bedrock: Document-level access controls