DPIA per Sistemi RAG e AI Generativa: come Documentare Pipeline e Context Window

Fonti: EDPB — Guidelines on AI models and personal data (2025) · Reg. UE 2016/679 (GDPR) Art. 35 · Reg. UE 2024/1689 (AI Act) Art. 26(9) · ICO — Guidance on privacy in AI large language models · AgID — Appendice Linee Guida IA nella PA: valutazione impatto

I sistemi RAG (Retrieval-Augmented Generation) sono diventati l'architettura dominante per le applicazioni enterprise di AI generativa: invece di affidarsi esclusivamente alla conoscenza "memorizzata" nel modello durante il pre-training, i sistemi RAG recuperano in tempo reale informazioni rilevanti da una base documentale aziendale (contratti, email, knowledge base, CRM, ERP) e le includono nel prompt inviato al LLM per generare la risposta. Questa architettura risolve molti dei limiti dei LLM puri (allucinazioni, conoscenza datata, mancanza di contesto specifico) ma introduce nuovi rischi per la privacy che una DPIA standard del 2020 non è attrezzata a gestire. Per il framework complessivo di compliance, si veda la guida alla valutazione integrata DPIA+FRIA per sistemi AI. Per la checklist DPIA per sistemi AI in generale, si veda la guida alla DPIA per sistemi AI checklist e template.

L'anatomia di un sistema RAG e i punti di rischio per la privacy

Un sistema RAG tipico include le seguenti fasi, ciascuna con rischi specifici per il trattamento di dati personali:

Fase 1: Ingestion e indicizzazione. I documenti aziendali (contratti, email, report, note CRM) vengono elaborati, segmentati in chunk e trasformati in embedding vettoriali archiviati in un vector store (Pinecone, Weaviate, Chroma, pgvector). Se i documenti contengono dati personali, questi vengono "iniettati" nel vector store nella forma di embedding: i dati personali non scompaiono nella trasformazione vettoriale, rimangono recuperabili attraverso query simili. La DPIA deve documentare questa fase come trattamento autonomo con la propria base giuridica.

Fase 2: Query processing. L'utente formula una domanda al sistema. La query può contenere dati personali (il nome di un cliente, un numero di contratto, una condizione medica). Questa query viene a sua volta trasformata in embedding e usata per cercare i chunk più simili nel vector store.

Fase 3: Retrieval. Il sistema recupera i chunk più rilevanti per la query. Questo è il punto critico per il rischio di cross-user data leakage: se i controlli di accesso al livello di retrieval non sono implementati, un utente potrebbe recuperare documenti che appartengono a un altro utente o a un altro cliente, attraverso query formulate in modo da massimizzare la similarità con quei documenti.

Fase 4: Context window composition. I chunk recuperati vengono combinati con la query originale e con le istruzioni di sistema (system prompt) per formare il prompt completo inviato al LLM. Questa composizione avviene tipicamente in chiaro: i dati personali contenuti nei documenti recuperati sono visibili nel prompt in forma non pseudonimizzata.

Fase 5: Inferenza e generazione. Il LLM (che può essere un servizio cloud di OpenAI, Anthropic, Google, Azure o un modello self-hosted) riceve il prompt e genera la risposta. Se il LLM è un servizio cloud, in questa fase i dati personali contenuti nella context window vengono trasferiti all'infrastruttura del provider.

Fase 6: Logging. I sistemi RAG enterprise registrano tipicamente i prompt e le risposte per finalità di monitoraggio, debugging e miglioramento del sistema. Questi log contengono dati personali estratti dai documenti aziendali. La DPIA deve documentare la retention di questi log.

I rischi specifici dei sistemi RAG per la privacy

Cross-user data leakage. In un sistema RAG multi-tenant (più utenti o più clienti sullo stesso sistema), l'assenza di controlli di accesso a livello di retrieval consente a un utente di recuperare documenti destinati a un altro. Il vector store non ha il concetto nativo di "permessi": i controlli di accesso devono essere implementati esplicitamente a livello applicativo.

Prompt injection. Un utente malintenzionato può formulare query progettate per estrarre dal sistema informazioni che non dovrebbe vedere, sfruttando la similarità semantica come vettore di attacco. La DPIA deve documentare le misure di protezione contro questo tipo di attacco.

Memorizzazione nei cache del LLM. Alcuni provider LLM cloud implementano meccanismi di caching dei prompt per ridurre la latenza. Se il provider usa prompt caching, parti della context window (che contengono dati personali) potrebbero essere memorizzate temporaneamente nell'infrastruttura del provider.

Model inversion attraverso retrieval. In sistemi RAG in cui l'embedding model è accessibile, attacchi di inversione possono potenzialmente ricostruire il contenuto originale dei chunk dall'embedding vettoriale.

Come strutturare la DPIA per un sistema RAG

Sezione 1: Architettura completa del data flow. Non la descrizione del sistema "come funziona in generale" ma il data flow specifico con i dati personali: quali documenti sono indicizzati, quali categorie di dati personali contengono, in quale formato e su quale infrastruttura sono archiviati gli embedding, chi ha accesso al vector store, in quale paese fisico si trova il vector store.

Sezione 2: Base giuridica per fase. La base giuridica non è unica per tutto il sistema: l'indicizzazione dei contratti dei clienti (per fornire assistenza contrattuale) può avere una base giuridica diversa dall'indicizzazione delle email dei dipendenti (per supporto interno). Documentare la base giuridica per ciascun tipo di documento indicizzato.

Sezione 3: Controlli di accesso a livello di retrieval. Documentare come il sistema implementa i permessi a livello di retrieval: filtri per user_id, tenant_id o ruolo applicati alla query vettoriale prima che i chunk vengano inclusi nella context window. Includere la specifica tecnica dell'implementazione, non una dichiarazione generica di conformità.

Sezione 4: Trasferimenti extra-UE. Se il LLM è un servizio cloud con server negli USA, il trasferimento della context window (che contiene dati personali) a ogni inferenza è un trasferimento extra-UE che richiede le SCC e la TIA. Documentare il provider, la localizzazione dei server, le SCC applicabili e la TIA condotta.

Sezione 5: Logging e retention. Documentare la retention dei log di prompt e risposta: finalità (debugging, audit, miglioramento del sistema), durata, soggetti con accesso, procedure di cancellazione.

Sezione 6: Misure di sicurezza specifiche per RAG. Documentare le misure adottate contro cross-user leakage, prompt injection e accesso non autorizzato al vector store: segregazione dei dati per tenant, rate limiting delle query, monitoraggio delle query anomale, crittografia degli embedding at rest e in transit.

Articolo aggiornato al 27 maggio 2026. Le linee guida EDPB sui modelli AI e i dati personali sono state pubblicate nel 2025. Per supporto specifico, contatta lo studio.