Permessi RAG per i chatbot del sito web: controllare l'accesso ai documenti in modo sicuro

Un chatbot per siti web può unire risposte provenienti da pagine FAQ, documentazione di prodotto e fonti di conoscenza interne. Questo è utile, finché la stessa base di conoscenza non contiene contenuti non destinati a tutti. In quel caso, non è solo la qualità del modello linguistico a determinare una risposta sicura, ma la fase di retrieval precedente: quali documenti può accedere questa specifica richiesta?

I permessi RAG collegano identità, ruoli o gruppi verificati ai metadati dei documenti. Il chatbot riceve solo fonti già filtrate. L'obiettivo è volutamente circoscritto: non deve essere un modello a decidere, in base al prompt, se un elemento è confidenziale. L'applicazione limita il contesto consentito, documenta questa decisione e sceglie un fallback sicuro in caso di incertezza.

Perché le regole nel prompt non sostituiscono il controllo degli accessi

Un'istruzione di sistema come "Non fornire informazioni interne" è utile, ma non è un livello di autorizzazione. Se un documento non autorizzato entra nel contesto, la risposta può riassumerlo, rivelarlo indirettamente o ricostruirlo su richiesta. Anche una verifica del testo a valle è tardiva e soggetta a errori. La sicurezza inizia prima della generazione e, idealmente, prima dell'ordinamento dei risultati.

Azure AI Search descrive il Security Trimming come un modello di filtro: i documenti recano valori di identità o di gruppo; la query contiene solo i principal della persona richiedente. Allo stesso modo, Amazon Bedrock evidenzia che i filtri di retrieval basati su ACL non sostituiscono l'autenticazione. L'applicazione deve prima verificare l'identità in modo affidabile e passare solo un contesto verificato.

I quattro elementi costitutivi di una soluzione solida

1. Verificare l'identità e la sessione lato server

Una finestra di chat pubblica normalmente non ha diritti sui documenti e può accedere solo a fonti pubbliche. Per un portale clienti o un'area dipendenti, la persona viene invece identificata tramite l'accesso esistente. Leggete ruolo, organizzazione e gruppi rilevanti lato server dalla sessione o da un token firmato. Non affidatevi mai a un campo inviato liberamente dal browser come role=admin o a un messaggio di chat che dichiara un'appartenenza.

2. Gestire i metadati di autorizzazione per ogni fonte

Ogni chunk richiede, oltre a testo, URL e data di aggiornamento, un'informazione di accesso tracciabile: come audience=public, un ID tenant, un elenco di gruppi consentiti o una classificazione. Questi metadati devono provenire dalla stessa fonte tecnica dell'autorizzazione del documento. Un foglio di calcolo separato gestito solo occasionalmente crea pericolosi disallineamenti. In caso di nuovi documenti e modifiche ai diritti di gruppo, la sincronizzazione dei metadati appartiene quindi al workflow di pubblicazione o crawling.

3. Filtrare prima del ranking

La query costruisce un filtro basato sul contesto verificato. Solo successivamente vengono valutati i risultati semantici o ibridi. In questo modo un manuale confidenziale non può emergere come risultato particolarmente pertinente per poi essere rimosso in seguito. In presenza di più tenant, l'ID tenant è un filtro obbligatorio, non un semplice segnale di ranking. Per i dati personali o particolarmente protetti, si raccomanda inoltre un'area dati separata anziché una raccolta comune filtrata solo logicamente.

4. Registrare le fonti e la decisione

Per il supporto e l'analisi degli incidenti, i soli trascritti della chat non bastano. Per ogni richiesta si dovrebbe poter tracciare quali attributi di identità non sensibili sono stati usati per il filtro, quale classe di filtro era attiva, quanti risultati sono rimasti dopo il filtro e quali fonti sono effettivamente entrate nel prompt. Non salvate contenuti completi o token non necessari. Un evento di audit essenziale rende individuabili gli errori senza trasformare il monitoraggio in una seconda perdita di dati.

Un flusso pratico per i team web

1. Assegnate ogni fonte di conoscenza a un pubblico target chiaro: pubblico, cliente, partner, team interno o un tenant specifico.
2. Definite quali session claim dimostrano questo pubblico target. I gruppi del sistema di identità sono più robusti rispetto a campi di modulo liberamente compilabili.
3. Applicate questi claim lato server nel filtro di retrieval e consentite solo un numero ridotto e noto di campi di filtraggio.
4. Eseguite un confronto a ogni crawl: documenti nuovi, modificati o rimossi necessitano anche di metadati di autorizzazione aggiornati.
5. Fornite al modello solo i risultati filtrati, insieme all'istruzione chiara di non indovinare le informazioni mancanti.
6. In assenza di risultati, di fonti contraddittorie o di autorizzazioni non chiare, reindirizzate a un canale di contatto sicuro.

Questo flusso integra la strutturazione descritta nel nostro articolo sul RAG Chunking: buoni frammenti migliorano la pertinenza, ma non sostituiscono il controllo degli accessi. Allo stesso modo, le fonti aggiornate rimangono fondamentali; uno stato dei permessi obsoleto rappresenta un problema sia di qualità sia di sicurezza.

Errore comune: filtraggio dopo il retrieval

Un errore di progettazione frequente consiste nel recuperare i dieci migliori risultati, verificarne le etichette in un secondo momento e rimuovere i documenti problematici. Questo approccio appare inizialmente sufficiente, ma fallisce a causa degli effetti collaterali. Il risultato non autorizzato può apparire nei log, nelle cache o in un output di debug. Inoltre, il suo punteggio altera la selezione degli altri risultati. È preferibile applicare un filtro nella richiesta di retrieval, consentendo solo ai documenti autorizzati di essere candidati.

Un secondo errore consiste nel fidarsi ciecamente della funzionalità ACL di un provider. La documentazione del produttore può specificare chiaramente che un servizio considera le ACL durante il recupero, ma non verifica autonomamente l'autenticità del contesto utente fornito. Verificate quindi con precisione: chi autentica la persona? Da dove provengono i gruppi? Quando vengono sincronizzati i diritti nel sistema di retrieval? Cosa succede se mancano i metadati?

Fail-closed: cosa fare in caso di incertezza

In caso di claim mancante, fonte non sincronizzata o errore di retrieval, il chatbot non dovrebbe tentare una ricerca più ampia. Utilizzate una risposta neutrale: il contenuto richiesto non è disponibile nel contesto di accesso attuale; un operatore umano può verificare l'accesso. Questo non è un limite della Conversational UX, ma un confine trasparente. L'articolo sull'Human Handoff mostra come gestire questo passaggio in modo concreto e senza vicoli ciechi.

Per i contenuti pubblici vale lo stesso principio su scala ridotta: se le fonti non sono sufficienti, il bot dovrebbe esplicitare l'incertezza, offrire link verificati o indicare un canale di contatto, anziché inventare dettagli plausibili. Ciò riduce le allucinazioni ed evita che una risposta apparentemente utile richieda sblocchi errati.

Casi di test fondamentali prima del rilascio

Un test dei permessi non è una verifica una tantum da parte dell'amministratore. Create un piccolo Golden Set con domande identiche per diversi ruoli: ospite, cliente registrato, partner autorizzato, utente bloccato e amministratore. Per ogni combinazione, definite le fonti attese e non solo il testo della risposta. Testate inoltre cambi di gruppo, sessioni scadute, documenti eliminati, metadati ACL mancanti e l'interruzione del servizio di retrieval.

Controllate nei risultati almeno quattro elementi: nessun URL o ID documento non autorizzato deve entrare nel contesto; le fonti consentite devono rimanere accessibili; la risposta non deve citare contenuti di documenti filtrati; e il fallback deve rimanere comprensibile. Integrate queste verifiche nei test sulla qualità delle risposte, affinché sicurezza e qualità tecnica vengano misurate insieme.

Implementare privacy e trasparenza in modo pratico

I dati di autorizzazione sono essi stessi riservati. Utilizzate ID tecnici stabili anziché nomi in chiaro nei metadati di retrieval. Limitate i log di audit alle finalità, al periodo e agli attributi necessari. Informate gli utenti in modo chiaro quando un chatbot accede all'area riservata e offrite un canale umano per domande sull'accesso. Questo articolo non sostituisce una consulenza legale individuale; i periodi di conservazione e le basi giuridiche specifiche dipendono dal contesto di utilizzo.

Dal punto di vista tecnico, è utile una chiara suddivisione delle responsabilità: i Content Owner gestiscono i pubblici target, il team di Identity risponde di claim e verifica sessioni, il team di prodotto mantiene testati filtri e fallback. In questo modo la base di conoscenza non diventa un pool di dati incontrollato, ma una fonte con un raggio d'azione trasparente.

Checklist prima del lancio

• Ogni fonte non pubblica è associata a un ruolo, gruppo o ID tenant?
• Il contesto della query proviene da un'identità verificata lato server?
• Il filtro agisce prima del retrieval e del ranking?
• Le modifiche ai diritti e i crawl vengono sincronizzati insieme?
• Esistono test di regressione basati sui ruoli con le fonti attese?
• Ogni stato sconosciuto o di errore porta a un handoff sicuro?
• I log rispettano la minimizzazione dei dati e bastano per l'analisi degli errori?

Conclusione

Un buon chatbot per siti web non risponde a qualsiasi domanda per chiunque. Mostra solo le fonti adatte al contesto di accesso verificato e mantiene un profilo cauto in caso di incertezza. Iniziate con una piccola matrice delle fonti, un filtro lato server e pochi ruoli di test chiari. Successivamente potrete estendere gradualmente metadati di autorizzazione, audit e sincronizzazione, senza delegare la sicurezza alle formulazioni dei prompt.

Fonti

• 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