GDPR e RAG: cosa verificare prima di partire
Se sta costruendo un sistema RAG che interroga documenti aziendali, il GDPR entra in gioco ogni volta che quei documenti contengono dati personali, non solo quando trattano esplicitamente categorie particolari. Prima di indicizzare contratti, email, cartelle cliniche o curriculum, deve verificare base giuridica, ruoli (titolare, responsabile, sub-responsabile), luogo di hosting e tempi di conservazione. Questo articolo propone una checklist pratica, utile anche come riferimento per le varianti nazionali europee come lo UK GDPR o la disciplina tedesca e francese equivalenti.
Perché il RAG pone domande specifiche di protezione dati
Un sistema RAG (retrieval augmented generation) non si limita a far leggere un documento a un modello: lo spezzetta in frammenti (chunk), ne calcola una rappresentazione numerica (embedding), la salva in un indice e, a ogni domanda, recupera i passaggi più pertinenti per generare una risposta con fonti citate. Questo significa che i dati personali contenuti nei documenti originali vengono copiati, trasformati e duplicati in più punti: nel testo estratto, nell'indice vettoriale, nei log delle domande poste e, a volte, nella cache delle risposte. Ogni copia è un trattamento ai sensi dell'articolo 4 del Regolamento (UE) 2016/679, e va gestita come tale.
Il rischio tipico non è la malafede, ma la disattenzione: si carica un'intera cartella di contratti o CV per «far rispondere l'IA più in fretta», senza chiedersi se quei documenti dovevano finire in un indice persistente, chi potrà interrogarlo e per quanto tempo resteranno lì i dati.
Dati personali nei documenti: individuarli prima di indicizzare
Il primo passo, spesso saltato, è una mappatura rapida di cosa sta per caricare. Alcuni tipi di documento contengono quasi sempre dati personali:
- Curriculum e lettere di candidatura (dati identificativi, percorso professionale, a volte dati sulla salute o l'appartenenza sindacale)
- Contratti di lavoro, buste paga, verbali disciplinari
- Cartelle cliniche, referti, consensi informati in ambito sanitario
- Email e verbali di riunione con nomi, ruoli e giudizi su persone
- Ticket di assistenza clienti con nome, indirizzo, numero di telefono
Se il suo caso d'uso riguarda solo documentazione tecnica, normative o contenuti già pubblici (manuali, policy generiche, norme di settore), il rischio è molto più basso e il discorso GDPR si semplifica parecchio. La distinzione conta anche per chi vuole pubblicare una base a pagamento: lo spieghiamo meglio più avanti.
Dati particolari (ex categorie sensibili)
Se tra i documenti compaiono dati sulla salute, l'origine etnica, le opinioni politiche o religiose, l'orientamento sessuale o dati biometrici, si applica l'articolo 9 del GDPR: il trattamento è vietato salvo eccezioni specifiche (consenso esplicito, obblighi di legge, finalità di medicina del lavoro, eccetera). In un progetto RAG, questo significa valutare con più attenzione se quei documenti devono finire nell'indice tal quali o se vanno prima pseudonimizzati, rimuovendo o mascherando i riferimenti diretti alla persona.
Base giuridica e finalità del trattamento
Ogni trattamento ha bisogno di una base giuridica tra quelle elencate all'articolo 6 del GDPR. Per un sistema RAG interno, le più frequenti sono tre:
Basi giuridiche più comuni per un progetto RAG
| Base giuridica | Quando si applica | Esempio pratico |
|---|---|---|
| Esecuzione di un contratto | Il trattamento serve a eseguire un servizio richiesto dall'interessato | Un assistente che risponde ai ticket di supporto di un cliente usando lo storico degli scambi |
| Obbligo legale | Una norma impone di conservare e rendere consultabili certi documenti | Archiviazione e ricerca su documenti di sicurezza sul lavoro o fiscali |
| Legittimo interesse | L'organizzazione ha un interesse concreto, bilanciato con i diritti degli interessati | Un motore di ricerca interno su email e verbali aziendali per i dipendenti |
| Consenso | Serve quando non si applica nessuna delle basi precedenti | Un chatbot pubblico che risponde su dati personali forniti volontariamente dall'utente |
La finalità va definita prima di caricare i documenti, non dopo: «rispondere alle domande dei dipendenti sulle policy HR» è una finalità precisa, «migliorare l'efficienza con l'IA» non lo è e non reggerebbe un controllo del Garante per la protezione dei dati personali.
Titolare, responsabile del trattamento e sub-responsabili
Quando usa una piattaforma esterna per creare e interrogare una base di conoscenza, Lei resta titolare del trattamento per i dati che carica, mentre la piattaforma agisce come responsabile del trattamento ai sensi dell'articolo 28 del GDPR. Questo comporta alcuni obblighi concreti: deve esistere un accordo di trattamento dati (DPA) che elenchi finalità, categorie di dati, misure di sicurezza e durata; il responsabile può nominare sub-responsabili (hosting, fornitori di modelli linguistici) solo con autorizzazione, generale o specifica, e deve garantirne un livello di protezione equivalente.
Se sta creando una base privata su un marketplace come Kopik per interrogare solo i propri documenti tramite API o server MCP, verifichi che il fornitore metta a disposizione un DPA firmabile, documenti chi sono i sub-responsabili coinvolti (hosting, eventuale fornitore del modello linguistico) e specifichi dove risiedono i dati. Lo stesso principio vale se integra la base in un prodotto rivolto ai clienti: ne parliamo con un approccio operativo in Un ChatGPT privato per i documenti aziendali: cosa significa davvero «privato» e nella checklist di Creare un chatbot conforme al GDPR sui propri documenti.
Hosting in UE, trasferimenti extra-UE e sub-responsabili
Dove vengono fisicamente salvati documenti, chunk ed embedding incide direttamente sulla conformità. Se il fornitore ospita i dati su server situati nell'Unione Europea e i sub-responsabili (incluso l'eventuale fornitore del modello linguistico usato per generare le risposte) operano anch'essi in UE o offrono garanzie equivalenti, il discorso dei trasferimenti extra-UE non si pone. Se invece parte dell'infrastruttura è fuori dall'UE, servono clausole contrattuali standard (SCC) aggiornate e, dopo la sentenza Schrems II della Corte di giustizia UE, una valutazione supplementare (transfer impact assessment) sul livello di protezione effettivo nel paese di destinazione.
Chieda sempre una mappa dei sub-responsabili
Prima di firmare con qualsiasi fornitore RAG, chieda l'elenco aggiornato dei sub-responsabili e il paese di hosting di ciascuno. Un fornitore serio lo mette a disposizione senza difficoltà, spesso nella pagina legale o nel DPA stesso.
Conservazione, cancellazione e diritto all'oblio
Il GDPR impone di conservare i dati solo per il tempo necessario alla finalità dichiarata (principio di limitazione della conservazione, articolo 5). In un sistema RAG questo riguarda tre livelli distinti, spesso dimenticati: i documenti sorgente caricati, l'indice di ricerca (chunk e vettori) e i log delle domande/risposte. Definisca una policy di retention per ciascuno, ad esempio: documenti e indice cancellati automaticamente dopo la fine del contratto o dopo un certo numero di mesi di inattività, log delle conversazioni conservati per un periodo più breve (es. 30-90 giorni) utile solo per diagnosi tecnica.
Il diritto alla cancellazione (articolo 17) è tecnicamente più delicato in un sistema RAG rispetto a un semplice archivio file: cancellare «il documento» non basta se i suoi chunk restano nell'indice vettoriale o nella cache delle risposte già generate. Verifichi con il fornitore che la cancellazione di un documento rimuova anche i frammenti indicizzati e, se previsto, forzi un nuovo calcolo dell'indice. Per capire cosa succede concretamente dietro le quinte quando elimina o aggiorna un documento, può essere utile leggere anche Come funziona il RAG, passo dopo passo.
Basi pubbliche e basi private: cosa cambia per il GDPR
Su un marketplace come Kopik, una base di conoscenza può essere pubblica (comparirà nel catalogo, chiunque può porre domande a pagamento e il creatore incassa una quota) oppure privata (interrogabile solo dal proprietario tramite API key o server MCP). Dal punto di vista GDPR la differenza è sostanziale: una base pubblica dovrebbe contenere solo contenuti che Lei ha il diritto di diffondere a chiunque paghi, cioè materiale proprio, pubblico o reso anonimo, mai dati personali di terzi raccolti per altre finalità. Una base privata, invece, è lo strumento corretto per documenti interni con dati personali di dipendenti o clienti, perché l'accesso resta limitato a chi Lei autorizza esplicitamente.
Se vende la propria competenza professionale (pareri, giurisprudenza commentata, procedure interne) sotto forma di base interrogabile, l'approccio corretto è anonimizzare o generalizzare i casi concreti prima di pubblicarli: l'argomento è trattato in dettaglio in Vendere la propria competenza agli agenti IA. Può esplorare le basi già pubblicate nel catalogo per farsi un'idea di come altri hanno impostato questa distinzione, oppure partire direttamente creando una base privata da /dashboard/bases/new.
Checklist pratica prima di lanciare un progetto RAG
- Ha mappato quali documenti contengono dati personali e, tra questi, quali rientrano nelle categorie particolari dell'articolo 9?
- Ha individuato una base giuridica precisa (contratto, obbligo legale, legittimo interesse o consenso) per ogni finalità distinta?
- Ha verificato se serve una valutazione d'impatto (DPIA) ai sensi dell'articolo 35, obbligatoria in caso di trattamento su larga scala o di categorie particolari di dati?
- Ha un accordo di trattamento dati (DPA) firmato con il fornitore della piattaforma RAG, con elenco dei sub-responsabili?
- Sa dove sono ospitati fisicamente documenti, indice e log (UE o extra-UE) e, se extra-UE, ha le clausole contrattuali standard aggiornate?
- Ha definito tempi di conservazione distinti per documenti sorgente, indice e log delle domande?
- Ha previsto una procedura per cancellare un documento e i suoi chunk dall'indice su richiesta dell'interessato?
- Se la base sarà pubblica su un marketplace, ha escluso dati personali di terzi non autorizzati alla diffusione?
- Ha informato gli interessati (dipendenti, clienti) tramite un'informativa privacy aggiornata che menzioni l'uso di sistemi di IA generativa?
- Ha verificato che le risposte generate citino le fonti, così da poter controllare rapidamente cosa viene effettivamente mostrato agli utenti?
Quest'ultimo punto non è solo una buona pratica di qualità: poter risalire al passaggio esatto da cui proviene un'informazione rende molto più semplice rispondere a una richiesta di accesso o rettifica da parte di un interessato. Abbiamo approfondito il tema della verifica delle fonti in Risposte dell'IA con citazioni: come verificare una risposta sui propri documenti.
Metta alla prova una base privata conforme
Crei una base di conoscenza privata, interrogabile solo con le Sue API key o via MCP, e verifichi hosting, DPA e retention prima di caricare documenti con dati personali.
Oltre il GDPR: l'AI Act e il buon senso operativo
Dal 2026 anche il Regolamento europeo sull'intelligenza artificiale (AI Act) entra progressivamente in vigore e si affianca al GDPR per alcuni usi, in particolare quando il sistema RAG supporta decisioni che riguardano persone (selezione del personale, accesso a servizi, valutazioni creditizie). In questi casi, oltre alla checklist privacy, va valutato se il sistema rientra tra quelli ad alto rischio secondo l'AI Act, con obblighi aggiuntivi di documentazione e supervisione umana. Per la maggior parte dei progetti RAG interni (ricerca documentale, supporto clienti, knowledge base tecniche) il rischio resta basso, ma vale la pena fare questa verifica una volta, all'inizio del progetto, invece di scoprirlo dopo il lancio.
Chi integra la base di conoscenza in un'applicazione tramite API, infine, dovrebbe applicare gli stessi principi anche lato sviluppo: non loggare in chiaro dati personali nelle chiamate di debug, limitare le API key per ambito e scadenza, e documentare nel proprio sistema quali endpoint toccano dati personali. La guida API base di conoscenza e la documentazione su /developers sono un buon punto di partenza per impostare questi controlli fin dall'architettura.
In sintesi
Un progetto RAG conforme al GDPR non richiede burocrazia infinita, richiede ordine: sapere cosa c'è nei documenti, su quale base giuridica li tratta, chi altro li tocca (hosting, sub-responsabili), per quanto tempo restano e come cancellarli davvero quando serve. Fatto questo lavoro una volta, all'inizio, il resto (scegliere base pubblica o privata, decidere se usare un marketplace o un'infrastruttura interna) diventa una scelta tecnica, non un rischio legale.
Il principio di responsabilizzazione (accountability) del GDPR non chiede di evitare l'innovazione, chiede di poter dimostrare, in ogni momento, le scelte fatte sui dati personali.Regolamento (UE) 2016/679, considerando 74-79
Domande frequenti
Un sistema RAG richiede sempre una valutazione d'impatto (DPIA)?
No. La DPIA è obbligatoria solo quando il trattamento presenta un rischio elevato per i diritti delle persone, ad esempio su larga scala, con categorie particolari di dati, o con valutazione sistematica di persone. Per una base di conoscenza interna su documentazione tecnica il rischio è generalmente basso; per un sistema che tratta cartelle cliniche o dati HR su larga scala, la DPIA va fatta.
Posso caricare dati personali di terzi in una base pubblica su un marketplace?
In generale no, salvo che abbia una base giuridica che Le permetta di renderli accessibili a chiunque paghi per interrogarli, cosa rara. Per contenuti con dati personali di clienti o dipendenti la scelta corretta è una base privata, interrogabile solo con le Sue credenziali.
Gli embedding sono considerati dati personali secondo il GDPR?
Se derivano da un testo che contiene dati personali e permettono, anche indirettamente, di risalire a una persona identificabile, sì: vanno trattati come dati personali e seguono le stesse regole di conservazione e cancellazione del testo originale.
Come gestisco una richiesta di cancellazione su un indice RAG già costruito?
Deve rimuovere sia il documento sorgente sia i chunk e gli embedding corrispondenti nell'indice, e verificare che non restino copie nella cache delle risposte già generate. Un buon fornitore offre un'operazione di cancellazione che agisce su tutti questi livelli contemporaneamente.
Serve obbligatoriamente l'hosting in UE per essere conformi al GDPR?
Non è un obbligo assoluto, ma semplifica molto le cose. Se i dati restano in UE non servono clausole contrattuali standard né valutazioni sui trasferimenti extra-UE. Se l'hosting è fuori dall'UE, servono garanzie contrattuali aggiuntive e, dopo la sentenza Schrems II, una valutazione del livello di protezione nel paese terzo.
Chi è responsabile se una risposta generata dall'IA espone dati personali in modo scorretto?
La responsabilità principale resta del titolare del trattamento, cioè di chi ha caricato i documenti e definito le finalità d'uso. Per questo è importante scegliere un sistema che citi le fonti delle risposte: permette di verificare rapidamente cosa è stato mostrato e di correggere l'indice o le autorizzazioni di accesso.
Riceva la newsletter di Kopik
Nuove basi di conoscenza, guide sul RAG e novità del prodotto. Un'email ogni una o due settimane, disiscrizione con un clic.
Iscrivendosi accetta di ricevere la nostra newsletter. Il Suo indirizzo non viene mai condiviso.