Una venditrice chiede al chatbot interno: «Quali sconti applichiamo ai clienti hotel?» Il retrieval trova tre documenti molto pertinenti. Due sono normali linee guida commerciali. Il terzo è un file della direzione con margini d’acquisto e condizioni speciali.
Per la ricerca semantica è un risultato perfetto. Per l’accesso della venditrice non dovrebbe esistere.
Qui un RAG ingenuo può fallire. Il sistema trova i chunk più rilevanti e li inserisce nel contesto del modello. Se i permessi vengono controllati solo dopo, il dato riservato è già stato letto.
Un RAG permission-aware impone una regola: l’assistente può recuperare solo materiale che l’utente corrente è autorizzato a vedere. La rilevanza semantica viene calcolata all’interno di quel perimetro.
I permessi RAG separano “utile” da “autorizzato”
La Zero Trust Architecture non assume che tutto sia permesso perché una persona è dentro la rete aziendale. Identità, risorsa e policy guidano l’accesso.
Ogni query RAG dovrebbe quindi rispondere a due domande: quali contenuti sono rilevanti e quali sono eleggibili per questo utente?
Ruoli, gruppi, ACL e attributi possono alimentare il filtro. La tecnologia concreta varia, ma l’ordine è decisivo: prima autorizzazione, poi ranking.
modelli Zero Trust usano identità e risorse come parte delle decisioni di accesso.
Raccomandazione: non affidare al modello la decisione su un documento confidenziale dopo che il documento è già nel suo contesto. Il controllo deve stare prima.
Il nuovo indice può perdere la sicurezza del vecchio sistema
Il pilota tipico è veloce: esportare SharePoint, Drive, Notion o cartella condivisa, creare embedding e iniziare a fare domande.
Il problema è che il sistema sorgente può avere permessi ereditati che non vengono portati nel vector store. L’indice RAG diventa più piatto dell’archivio originale.
In un hotel potrebbero convivere informazioni pubbliche sulla colazione, turni dei dipendenti, reclami, prezzi dei fornitori e report della direzione. La query “costo colazione” potrebbe recuperare un calcolo interno anziché la tariffa per l’ospite.
Anche la cache va controllata. Un risultato autorizzato per management non dovrebbe diventare contesto globale riutilizzato con altri utenti.
Il confine dei permessi deve quindi attraversare indexing, retrieval, cache e trace della risposta.
Un flusso permission-aware pratico
La prima versione può essere piccola.
- Classificate il corpus. Pubblico, interno, team, confidenziale, altamente ristretto.
- Mantenete metadati ACL durante l’indicizzazione. Documento o chunk resta collegato a ruoli e gruppi.
- Passate identità autenticata. Scrivere “sono il CEO” nel prompt non modifica il profilo.
- Filtrate prima del ranking semantico. I chunk non autorizzati non entrano nella lista dei candidati.
- Registrate fonte e decisione di accesso. In caso di problema bisogna ricostruire cosa è stato usato.
- Fate test di denial. Un utente senza HR chiede salari o valutazioni e il retrieval non deve portare contenuti vietati.
Per una piccola azienda possono bastare all_staff, sales, management. L’importante è non usare “interno” come sinonimo di “accessibile a tutti”.
L’eccezione difficile: inferenze da documenti consentiti
Un utente può avere accesso legittimo a più documenti che, combinati, permettono di dedurre un’informazione sensibile. Nessuna singola ACL è stata violata, ma il risultato può essere problematico.
Un commerciale potrebbe vedere prezzi fornitori e volumi; aggregando molte risposte può inferire un margine che l’azienda considera riservato.
Per aree molto sensibili, corpus separati o policy di risposta aggiuntive possono essere più semplici di un unico bot universale.
Serve handover umano anche quando il documento è accessibile ma l’interpretazione è delicata. Un assistente può citare una policy HR; decidere un caso di licenziamento appartiene a chi ha responsabilità professionale.
Il pilota minimo deve testare soprattutto i rifiuti
Create due gruppi e due classi documentali. Vendite e direzione, con materiale comune e un file sui margini.
Preparate dieci domande normali e dieci vietate, incluse formulazioni indirette e una falsa dichiarazione di ruolo. Controllate il retrieval log, non solo la frase finale.
Misurate retrieval non autorizzati, false denial per utenti corretti, risposte con fonte ricostruibile, tempo di propagazione delle modifiche ACL, handover per accesso ambiguo e copertura dei documenti sensibili nei test.
Un chatbot impressionante sa rispondere. Un chatbot interno affidabile sa anche non prendere la fonte che l’utente non avrebbe potuto aprire da solo.
permission-aware RAG diventa necessario appena l’azienda ha diritti documentali differenti. Se l’AI ignora quella struttura, si crea una nuova porta verso gli stessi dati — senza il controllo d’accesso che l’azienda aveva già costruito.
Un altro punto operativo è la propagazione dei cambi di permesso. Un collaboratore cambia reparto o perde accesso a una cartella, ma l’indice vettoriale e una cache di retrieval possono continuare a servire chunk creati prima della modifica. La policy deve quindi essere valutata al momento della query, non solo al momento dell’ingestione.
Nel pilota misurate il tempo tra modifica ACL e comportamento effettivo del chatbot. Testate anche revoca immediata, documento spostato, gruppo rinominato e utente disattivato. Se un sistema non riesce a garantire una revoca rapida, per il corpus sensibile è meglio restringere l’ambito o non indicizzarlo finché la catena di autorizzazione non è verificabile.
La prompt injection indiretta riguarda il contenuto. L'identità tecnica stabilisce per conto di chi avviene la ricerca.
Fonti
FAQ
Basta non indicizzare le cartelle riservate?
Per un caso semplice può bastare. Con utenti e ruoli diversi serve normalmente più granularità.
Il modello può classificare da solo la sensibilità?
Può aiutare, ma non dovrebbe essere l’unico enforcement dei permessi.
Ogni chunk deve avere una propria ACL?
Dipende dal design. Ogni contenuto recuperabile deve comunque ereditare o avere un permesso applicabile in modo affidabile.
Se l’utente scrive “sono il direttore”?
Il prompt non deve cambiare l’identità. Il ruolo arriva dalla sessione autenticata o dall’identity provider.
HR dovrebbe stare in un RAG separato?
Non sempre necessario, ma per informazioni molto sensibili una separazione più forte semplifica governance e test.