RAG per aziende e Privacy

Nota preliminare: Il presente articolo ha finalità puramente informative e divulgative. Non costituisce consulenza legale né parere professionale specifico. Per valutazioni relative a situazioni concrete, si raccomanda di consultare un professionista qualificato in materia di protezione dati. Le informazioni qui riportate sono aggiornate a ottobre 2025 e riflettono lo stato della normativa e delle prassi alla data indicata.

Introduzione: Privacy e RAG per aziende

Le soluzioni basate su Retrieval-Augmented Generation (RAG) stanno diventando uno strumento fondamentale per le aziende che desiderano valorizzare la propria documentazione interna attraverso interfacce AI personalizzate. Tuttavia, il tema della privacy riveste un ruolo centrale, in particolare quando i dati trattati appartengono a clienti, collaboratori oppure utenti finali. In questo articolo analizziamo i ruoli dei soggetti coinvolti, le implicazioni giuridiche e le configurazioni architetturali e contrattuali ottimali per garantire la conformità normativa.

Ruoli coinvolti nel trattamento dati

All'interno di un ecosistema RAG tipico, possiamo distinguere tre soggetti principali:

• Fornitore del servizio RAG: l'azienda che implementa la tecnologia, fornisce l'infrastruttura AI, gestisce gli aggiornamenti e supporta i processi di embedding e consultazione documentale.
• Cliente aziendale: l'impresa che integra l'interfaccia RAG nel proprio flusso operativo o pubblico, caricando documenti e contenuti proprietari.
• Fruitore finale: l'utente che interagge con l'interfaccia (dipendente, cliente, partner o visitatore) per ottenere risposte basate sui documenti indicizzati.

Responsabilità del fornitore del servizio

Un fornitore di servizi RAG agisce generalmente come Responsabile del trattamento (art. 28 GDPR), poiché tratta i dati (documenti indicizzati, prompt, log) per conto del cliente. Un fornitore conforme deve garantire:

• Sicurezza adeguata dell'infrastruttura hardware e software.
• Processi di logging e audit proporzionati e non invasivi.
• Cifratura dei dati in transito e a riposo.
• Misure di prevenzione contro accessi non autorizzati e segregazione dei dati tra i clienti (multi-tenant).

È fondamentale che il fornitore operi esclusivamente sulle istruzioni documentate del cliente, come previsto dal GDPR.

Responsabilità del cliente aziendale

Il cliente che utilizza la soluzione RAG è tipicamente considerato Titolare del trattamento, decidendo finalità e mezzi del trattamento dati. È responsabile per:

• Informare correttamente gli utenti finali sulle modalità di trattamento.
• Configurare correttamente i permessi di accesso ai documenti.
• Individuare categorie speciali di dati (art. 9 GDPR) e limitarne l'indicizzazione o l'accesso ove necessario.
• Richiedere ove necessario il consenso espresso e definire la corretta base giuridica per ogni trattamento.

Ruolo dell'utente finale

L'utente finale non partecipa alle decisioni sul trattamento dei dati, ma deve essere informato in modo chiaro circa finalità, rischi e limiti. Se l'interfaccia RAG registra input personali, è necessario rendere disponibile una privacy policy trasparente e aggiornata, fornita dal Titolare (il cliente aziendale).

Basi giuridiche del trattamento

Il GDPR stabilisce diverse basi giuridiche applicabili, a scelta del Titolare:

• Consenso per i dati forniti volontariamente nell'interfaccia RAG (es. un chatbot pubblico).
• Esecuzione di un contratto o misure precontrattuali (es. supporto clienti).
• Legittimo interesse del Titolare (es. per funzionalità interne all'azienda), da bilanciare tramite valutazione documentata (Legitimate Interest Assessment).

È fondamentale evitare l'elaborazione di dati appartenenti alle categorie particolari (art. 9 GDPR) senza adeguate garanzie e una base giuridica specifica.

Tutele contrattuali tra fornitore e cliente

Il rapporto tra un fornitore di servizi RAG e il Cliente deve essere regolato da un Accordo di Nomina a Responsabile del Trattamento (Data Processing Addendum - DPA, art. 28 GDPR), che includa almeno:

• Oggetto, durata, natura e finalità del trattamento.
• Obblighi e diritti del Titolare e responsabilità del Responsabile.
• Clausole di riservatezza per il personale autorizzato.
• Tempi e modalità di cancellazione dei dati al termine del contratto.
• Responsabilità in caso di data breach e obbligo di notifica tempestiva.
• Service Level Agreement (SLA) su disponibilità del servizio e misure di sicurezza implementate.

Per clienti particolarmente esigenti, come gli studi legali, è raccomandabile integrare clausole rafforzate relative a segreto professionale e minimizzazione dei dati.

Configurazioni API ottimali per piattaforme RAG

Dal punto di vista tecnico, le configurazioni ottimali per le API di una piattaforma RAG conforme al GDPR dovrebbero prevedere:

• Token di accesso con validità temporale limitata e associati al singolo cliente.
• Scoping dei permessi per separare logicamente progetti e basi documentali.
• Limiti di rate (rate limiting) per prevenire abusi o attività anomale.
• Registro degli accessi (log) per finalità di sicurezza e audit, nel rispetto dei principi di minimizzazione e conservazione limitata. I log dovrebbero conservare esclusivamente metadati tecnici (timestamp, identificativi di sessione, codici di stato HTTP, indirizzi IP ove strettamente necessario per sicurezza) e non dovrebbero includere i contenuti dei documenti né i prompt degli utenti, riducendo al minimo i rischi di profilazione o utilizzo improprio.

Data retention e diritto all'oblio

Il GDPR prevede il principio di conservazione limitata. Il Cliente (Titolare) definisce le policy di retention applicabili. Una piattaforma RAG conforme dovrebbe supportare tecnicamente queste policy, consentendo al Cliente di:

• Definire il periodo massimo di mantenimento dei documenti indicizzati.
• Attivare procedure di rimozione di contenuti (su richiesta dell'interessato o per scadenza programmata).
• Gestire la policy di conservazione dei log di utilizzo, nel rispetto dei principi di proporzionalità.

Il fornitore dovrebbe supportare tecnicamente questi processi e documentare ogni operazione di eliminazione richiesta dal Cliente.

Hosting e localizzazione dati: configurazioni ottimali

Un aspetto fondamentale per la conformità al GDPR è la localizzazione dei dati. Le configurazioni ottimali prevedono che l'infrastruttura del fornitore RAG (database vettoriali, server applicativi, cache dei documenti) risieda su server localizzati all'interno dell'Unione Europea.

Questa scelta architetturale riduce significativamente le complessità relative ai trasferimenti di dati extra-UE per tutto ciò che concerne l'indicizzazione, la memorizzazione e il recupero dei documenti (la fase di "Retrieval" del RAG).

Trattamento degli embedding: I dati vettoriali (embedding) generati dal processo di indicizzazione sono considerati, secondo le indicazioni dell'European Data Protection Board (EDPB), dati personali pseudonimizzati quando derivano da contenuti che identificano o rendono identificabili persone fisiche. Pertanto, sono soggetti ai principi di minimizzazione, conservazione limitata e sicurezza previsti dal GDPR. In una configurazione ottimale, tutti gli embedding dovrebbero essere conservati esclusivamente in server UE e trattati con le medesime garanzie di sicurezza applicate ai documenti originali.

Gestione dei modelli LLM esterni: il modello BYOK

La generazione delle risposte (la "G" di RAG) richiede l'uso di un modello linguistico (LLM), spesso fornito da provider terzi (es. OpenAI, Anthropic, Google). Gestire questa chiamata esterna rappresenta un punto critico per la compliance.

Per massimizzare la tutela legale del Cliente e delineare chiaramente le responsabilità, una configurazione ottimale può adottare un modello "Bring Your Own Key" (BYOK):

• Il Cliente stipula un accordo commerciale e un DPA (Data Processing Addendum) direttamente con il fornitore di LLM prescelto (es. OpenAI, Anthropic, o altro provider).
• Il Cliente fornisce al fornitore RAG la propria chiave API per quel servizio.
• La piattaforma RAG agisce come intermediario tecnico: riceve il prompt dell'utente, lo arricchisce con i documenti recuperati dal database, e inoltra il prompt finale al provider LLM utilizzando la chiave API del Cliente.

I vantaggi legali del modello BYOK

Questo approccio, particolarmente indicato per clienti esigenti come gli studi legali, offre tutele decisive:

• Assenza di catena di sub-trattamento (Art. 28, comma 2 e 4, GDPR): Nel modello BYOK, il fornitore RAG non nomina né designa il provider LLM come "sub-responsabile" o "altro responsabile" ai sensi dell'art. 28 GDPR. Non si configura alcuna catena di sub-trattamento: il Cliente stipula un rapporto contrattuale diretto e autonomo con il provider LLM. Il fornitore RAG agisce esclusivamente come intermediario tecnico per l'inoltro delle chiamate API, senza assumere responsabilità sul trattamento effettuato dal provider LLM. Il ruolo di Responsabile del trattamento del fornitore RAG resta limitato alla piattaforma RAG (hosting, embedding, retrieval).
• Pieno controllo del Cliente: Il Cliente mantiene il pieno controllo contrattuale ed economico sul provider LLM. Può negoziare direttamente condizioni contrattuali specifiche, come policy di retention dei dati particolarmente stringenti (ad esempio la "Zero Data Retention" - ZDR, ove disponibile e applicabile previo accordo specifico con il provider).
• Trasparenza sui trasferimenti extra-UE: L'eventuale gestione di trasferimenti di dati extra-UE (es. verso gli USA per l'uso di alcuni provider) è disciplinata dal DPA che il Cliente ha stipulato direttamente con tale provider, senza intermediazione da parte del fornitore RAG. Il Cliente è quindi direttamente responsabile della valutazione di conformità di tali trasferimenti.

Nota importante: Policy come la "Zero Data Retention" (ZDR) non sono normalmente attivabili tramite semplici configurazioni, ma richiedono tipicamente un accordo specifico con il provider LLM. Il Cliente che adotta il modello BYOK può richiedere tali policy direttamente al proprio provider, secondo i termini e le condizioni da questi stabiliti. Un fornitore RAG che adotta il modello BYOK non può garantire né influenzare la disponibilità o l'applicazione di tali policy da parte di provider terzi.

Conclusione

L'adozione di sistemi RAG offre vantaggi competitivi significativi, ma richiede una gestione della privacy matura e consapevole. Definire con precisione ruoli, responsabilità e tutele contrattuali è essenziale. Una corretta architettura tecnica — come la localizzazione dell'hosting in ambiente UE e l'adozione del modello BYOK per le API di generazione esterne — permette di costruire interfacce affidabili e aderenti ai principi del GDPR, proteggendo l'azienda cliente, i suoi dati e i suoi utenti finali.

Ogni organizzazione dovrebbe valutare attentamente, con il supporto di consulenti legali qualificati, la configurazione più adatta alle proprie esigenze specifiche e al proprio profilo di rischio, tenendo conto delle specificità del proprio settore e delle categorie di dati trattati. La scelta di un fornitore di servizi RAG dovrebbe sempre essere preceduta da una verifica approfondita della conformità delle sue configurazioni tecniche e contrattuali ai requisiti del GDPR.