Con il Retrieval-Augmented Generation (RAG) il dato aziendale non deve essere incorporato nel modello per poter essere utilizzato: può infatti rimanere nella fonte originaria ed essere recuperato quando serve per generare una risposta. Di conseguenza non basta più proteggere il modello e i dati utilizzati per addestrarlo, ma occorre garantire che l’intera architettura controlli quali informazioni possono essere recuperate, da chi e per quale finalità. Quando queste informazioni contengono dati personali o riservati, il perimetro da proteggere riguarda quindi non solo l’accesso al dato, ma anche il suo utilizzo e la sua restituzione attraverso il sistema AI.
Fin dall’inizio, la sicurezza dell’AI generativa si è concentrata soprattutto sul modello; anche sul piano della privacy, l’attenzione si è rivolta in larga parte ai dati utilizzati per addestrarlo e alle informazioni che il modello può conservare o restituire. Da qui alcune delle domande che hanno guidato l’analisi dei rischi: quali dati sono stati utilizzati per il training? Il modello può aver memorizzato informazioni riservate o dati personali? I prompt degli utenti vengono utilizzati per addestrarlo? È possibile estrarre dati sensibili dai suoi parametri?
Indice degli argomenti
RAG e privacy: perché cambia il perimetro di sicurezza
Sono tutte domande rilevanti. Ma con la sempre più ampia adozione dell’AI generativa in ambito aziendale e in particolare dei sistemi RAG, il perimetro da proteggere si amplia: la sicurezza e la privacy non riguardano più soltanto il modello, ma anche le fonti informative, i sistemi di autorizzazione, gli indici e i meccanismi di recupero dei dati.
In azienda, infatti, la conoscenza che si vuole rendere disponibile all’AI non proviene da un’unica fonte, ma è distribuita tra sistemi documentali, database, basi di conoscenza, intranet, CRM, applicazioni verticali, repository di codice ed e-mail, spesso con livelli di riservatezza e regole di accesso differenti. Il RAG consente di mantenere queste informazioni nelle loro fonti originarie e di recuperarle quando una richiesta lo richiede. L’AI può quindi utilizzare la conoscenza interna senza che questa debba necessariamente essere incorporata nel training del modello. Queste informazioni, però, arrivano al sistema AI attraverso una catena fatta di identità, autorizzazioni, connettori, indicizzazione e recupero dei contenuti rilevanti. Ed è lungo questa catena che si sposta il perimetro della sicurezza.
Dal modello al dato
Poiché in un sistema RAG il modello può non aver mai incorporato la conoscenza contenuta in un documento aziendale e tuttavia riceverne il contenuto come contesto per formulare una risposta, il rischio di accesso o divulgazione non autorizzata dei dati può nascere molto prima della generazione: da un’ACL configurata male, da un indice che non conserva correttamente le informazioni sui permessi, da un filtro applicato in modo non corretto o da un connettore con privilegi eccessivi. La domanda che dobbiamo farci diventa quindi: quali informazioni può recuperare il sistema per quello specifico utente?
È un passaggio cruciale perché il modello non dovrebbe essere chiamato a decidere chi può accedere a un contenuto. L’autorizzazione deve essere verificata prima che le informazioni entrino nel contesto utilizzato per generare la risposta. Se questo controllo viene meno, un modello perfettamente funzionante può diventare il punto finale attraverso cui un utente ottiene informazioni che non avrebbe dovuto poter consultare. A tal proposito, OWASP sottolinea che i controlli di accesso devono essere mantenuti anche nei sistemi utilizzati per il recupero delle informazioni e applicati prima che il contenuto raggiunga il modello.
Questo cambia anche il modo di guardare alla sicurezza dei dati aziendali. Non basta più verificare che un documento sia protetto nella sua fonte originaria: bisogna verificare che le stesse regole di accesso continuino a valere quando quel documento viene indicizzato, ricercato e utilizzato per costruire una risposta. Il sistema RAG diventa così una nuova modalità di accesso alla conoscenza aziendale, e le sue regole di autorizzazione devono essere coerenti con quelle già applicate ai sistemi da cui la conoscenza proviene.
È proprio questo il punto in cui sicurezza e privacy iniziano a sovrapporsi: se una base di conoscenza contiene informazioni personali o riservate, il problema non è soltanto impedire l’accesso diretto alla fonte, ma anche evitare che quelle informazioni vengano recuperate e restituite a un utente non autorizzato attraverso una domanda in linguaggio naturale. L’EDPS richiama esplicitamente questo rischio e sottolinea la necessità di verificare che i sistemi RAG non divulghino dati personali presenti nella loro base di conoscenza.
Per comprendere il problema è utile introdurre un concetto già presente nei sistemi di ricerca aziendali: il security trimming, cioè il filtraggio dei risultati in base alle autorizzazioni dell’utente. Significa, in sostanza, che il motore di ricerca non deve limitarsi a trovare i contenuti pertinenti a una query, ma deve escludere dai risultati quelli che l’utente che ha effettuato la richiesta non è autorizzato a vedere. È il principio applicato, per esempio, alla ricerca di SharePoint: i risultati vengono filtrati sulla base dei permessi dell’utente, così che un documento a cui non ha accesso non compaia nei risultati.
In un RAG questo principio assume un’importanza particolare. Non basta che il sistema trovi il documento più rilevante per rispondere alla domanda: deve trovare il documento più rilevante tra quelli che quell’utente è autorizzato a utilizzare. Se questo passaggio non funziona correttamente, il modello può diventare il punto finale di una violazione che nasce nel sistema di accesso al dato.
Il dato non è nel training, ma può comunque essere restituito
Ma qui emerge anche una seconda questione, che riguarda direttamente la privacy. Il fatto che un dato personale non sia stato utilizzato per addestrare un LLM non significa che non venga trattato dal sistema: può essere recuperato, elaborato e restituito dal sistema RAG senza essere mai stato incorporato nel modello.
Questa distinzione è stata analizzata anche sperimentalmente. Uno studio pubblicato nei Findings of the Association for Computational Linguistics (ACL) 2024 ha verificato la possibilità di estrarre informazioni private dal database utilizzato da un sistema RAG attraverso interrogazioni al modello, senza accesso diretto ai suoi componenti interni. Gli esperimenti, condotti anche su dataset contenenti e-mail e conversazioni medico-paziente, mostrano che richieste costruite ad hoc possono portare il sistema a riprodurre nella risposta contenuti presenti nei dati recuperati.
Il risultato è rilevante perché mette in evidenza una superficie di esposizione distinta da quella dei dati memorizzati dal modello durante il training: in un sistema RAG il rischio riguarda anche ciò che viene recuperato dalla fonte esterna durante l’elaborazione della richiesta. Lo studio evidenzia inoltre che l’utilizzo dei dati recuperati può ridurre alcuni rischi legati alla riproduzione di dati memorizzati nel training, mostrando come le due superfici di rischio non coincidano.
L’EDPS evidenzia proprio questo rischio: utenti non autorizzati possono cercare di indurre il sistema a rivelare informazioni confidenziali, anche personali, presenti nei repository interrogati dal RAG. Inoltre, una risposta può contenere elementi sufficientemente dettagliati da consentire di inferire l’identità di una persona anche senza fornire direttamente un identificativo. Per questo la domanda non può essere soltanto “chi può accedere al documento?”, ma deve estendersi a “quali dati personali vengono recuperati, per quale richiesta, da quale fonte e per quale finalità vengono utilizzati nella risposta?”
È una distinzione fondamentale: l’autorizzazione all’accesso alla fonte è una condizione necessaria per la sicurezza, ma non esaurisce il problema della protezione dei dati personali.
La privacy segue il dato lungo tutto il suo percorso
Una volta che i dati personali entrano nel percorso del RAG, la privacy deve essere considerata lungo l’intero sistema, in linea con il principio della protezione dei dati fin dalla progettazione (Privacy by Design) previsto dall’articolo 25 del GDPR, dalla fonte in cui sono conservati fino alle informazioni utilizzate per formulare la risposta. I controlli non possono quindi fermarsi alla fonte di provenienza del dato, ma devono riguardare anche il modo in cui le informazioni vengono recuperate, fornite al modello e restituite all’utente. L’EDPS indica la necessità di testare i sistemi RAG per verificare che non divulghino dati personali presenti nella loro base di conoscenza, e richiama anche i requisiti di necessità e proporzionalità del trattamento, oltre alla necessità di garantire sicurezza, riservatezza e integrità delle fonti di dati.
La sicurezza diventa così una condizione necessaria della privacy, ma non coincide con essa. Il security trimming risponde alla domanda: “questo utente può accedere a questa informazione?”. La privacy impone di aggiungere altre domande: “è necessario utilizzare questa informazione per questa finalità? Quali dati personali vengono effettivamente trattati? Il sistema può restituirli in una forma che determini una divulgazione non necessaria?”.
È questa distinzione a rendere insufficiente un controllo basato soltanto sui permessi di accesso. Un utente può essere autorizzato ad accedere a una fonte, ma ciò non esaurisce la valutazione su quali informazioni personali sia necessario recuperare e utilizzare per rispondere a una specifica richiesta.
Il nuovo perimetro della sicurezza dell’AI nelle aziende
Il RAG non rende meno importanti i rischi propri dei modelli generativi: prompt injection, data poisoning e information disclosure restano problemi da valutare e mitigare. Cambia però il contesto nel quale questi rischi devono essere analizzati.
In un sistema RAG, infatti, una risposta dipende non solo dal comportamento del modello, ma anche dalle informazioni recuperate e dalle autorizzazioni applicate lungo il percorso. Per le aziende questo significa valutare la sicurezza non soltanto del modello, ma dell’intero sistema che gli consente di utilizzare la conoscenza interna. Quando quella conoscenza contiene dati personali, la stessa architettura deve essere considerata anche dal punto di vista della protezione dei dati.
Da qui nasce una domanda diversa: quali condizioni devono essere rispettate perché il modello possa utilizzare la conoscenza aziendale in sicurezza e nel rispetto della privacy? È questa la domanda che porta a proporre un nuovo modello di analisi delle minacce per i sistemi RAG.
Verso un nuovo threat model per sicurezza e privacy
Se il rischio non riguarda più soltanto il modello, anche il modo in cui vengono valutate le minacce deve cambiare prospettiva, dal momento che in un sistema RAG bisogna considerare l’intero ciclo di vita del dato.
Controlli di accesso e recupero delle informazioni
Sul versante della sicurezza, occorre verificare che i controlli di accesso siano applicati anche durante il recupero delle informazioni, che dati soggetti a diversi livelli di autorizzazione non siano messi a disposizione dell’utente sbagliato e che i sistemi utilizzati per la ricerca non diventino a loro volta un punto di accesso non autorizzato ai dati. OWASP richiama proprio questi rischi e indica tra le misure di mitigazione controlli di accesso granulari e sistemi di recupero consapevoli delle autorizzazioni.
Dati personali, finalità e divulgazione
Sul versante della privacy, occorre considerare non solo chi può accedere a un dato, ma anche quali dati personali vengono recuperati, se il loro utilizzo è coerente con la finalità del trattamento e se la risposta può determinare una divulgazione non necessaria. L’EDPS richiama questi aspetti nell’analisi dei sistemi RAG e sottolinea la necessità di verificare che non vengano divulgati dati personali presenti nelle basi di conoscenza.
È questa la prospettiva da cui proporre un nuovo threat model per i sistemi RAG: non partire soltanto da ciò che il modello può fare, ma seguire il dato lungo tutto il suo percorso e distinguere ciò che il modello può aver memorizzato da ciò che il sistema recupera dalle fonti esterne. Occorre inoltre verificare, in ogni passaggio, chi può accedervi, come viene utilizzato, quali informazioni vengono rese disponibili al modello e quali possono arrivare nella risposta.
Anche le modalità con cui il sistema recupera le informazioni devono quindi rientrare nell’analisi: la quantità di contenuti recuperati e le modalità di selezione possono incidere sull’esposizione dei dati e devono essere valutate insieme ai controlli di accesso.
L’analisi dovrebbe verificare congiuntamente autorizzazione, riservatezza, integrità, minimizzazione e corretto utilizzo del dato. Il modello rimane un elemento essenziale, ma non esaurisce più l’analisi del rischio: sicurezza e privacy dipendono dall’insieme dei componenti che rendono possibile l’accesso alla conoscenza aziendale e il suo utilizzo nella risposta.
Bibliografia
OWASP GenAI Security Project, LLM 08:2025 – Vector and Embedding Weaknesses, 2025
OWASP Cheat Sheet Series, Retrieval-Augmented Generation (RAG) Security Cheat Sheet,
European Data Protection Supervisor (EDPS), TechSonar Report 2025, 2024, sezione “Retrieval-augmented generation (RAG)”.
European Data Protection Board (EDPB), Parere 28/2024 su taluni aspetti relativi alla protezione dei dati ai fini del trattamento dei dati personali nel contesto dei modelli di IA, 18 dicembre 2024.
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, 2024.
Regolamento (UE) 2016/679 (GDPR), art. 25, “Protezione dei dati fin dalla progettazione e protezione per impostazione predefinita”
Zeng S. et al., The Good and The Bad: Exploring Privacy Issues in Retrieval-Augmented Generation (RAG), Findings of the Association for Computational Linguistics: ACL 2024, pp. 4505–4524, 2024.
Partecipa alla community