> GDPR e AI: cosa verificare davvero prima di usare un LLM in azienda

La domanda che ricevo più spesso dai team che vogliono integrare un LLM in un processo aziendale è: "Possiamo farlo senza violare il GDPR?".

La risposta onesta è: dipende da cosa state facendo, con quali dati, e con quale provider. Non esiste una risposta binaria. Quello che c'è è una checklist di verifiche concrete che ogni azienda deve fare prima di andare live, indipendentemente dalla scala.

# Il problema reale: dati personali e LLM non sono amici per caso

Un LLM è uno strumento di elaborazione dati. Se gli date in pasto dati personali (nomi, email, numeri di cliente, conversazioni, IP, cookie ID), quei dati diventano input di un sistema che potrebbe usarli per addestramento, logging, o generazione di output che contiene tracce identitarie.

Il GDPR non vieta di usare LLM, ma pone responsabilità precise su chi li usa:

• Chi è il titolare del trattamento (solitamente voi, l'azienda)
• Chi è il responsabile esterno (OpenAI, Anthropic, Groq, etc.)
• Che base giuridica avete per dare quei dati a quel provider
• Come state trattando i dati durante il processo
• Come li state tracciando e cancellando dopo

La checklist che segue vale che usiate GPT-4, Claude, Llama via Replicate, o un modello locale.

# 1. Quale tipo di dato state passando al modello?

Non tutti i dati sono uguali davanti al GDPR. La domanda base è: state passando dati che permettono di identificare una persona, direttamente o indirettamente?

• Dati chiaramente personali: nome, cognome, email, numero di telefono, indirizzo, numero di cliente, username. Se passate questi a un LLM remoto, state comunicando dati personali a un terzo.
• Dati anonimizzati (davvero): se avete tolto OGNI elemento identificativo e il dato non può essere re-linkato neanche teoricamente, non è più "personale" ai sensi GDPR. Esempio: "quale colore scelgono più spesso i clienti?" (statistiche aggregate senza identità). Se invece è "cliente ABC ha scelto il colore blu", è personale.
• Dati pseudonimizzati: avete sostituito il nome con un codice univoco, ma conservate la corrispondenza altrove. Rimane comunque "personale" per il GDPR, perché è re-identificabile. Passare pseudonimi a un LLM è comunque trattamento di dati personali.

# 2. Chi è il vostro responsabile del trattamento (Data Processor)?

Se usate un LLM fornito da terzi (OpenAI, Anthropic, Azure OpenAI, etc.), quella azienda diventa vostro "responsabile del trattamento" (Data Processor) secondo il GDPR Articolo 28.

Cosa significa in pratica:

• Deve esserci un contratto di elaborazione dati (Data Processing Agreement, DPA) tra voi e il provider. Non è opzionale. OpenAI fornisce un DPA se siete su un piano business. Molti provider low-cost non ce l'hanno: lì il rischio legale è tutto su di voi.
• Il provider deve garantire che i vostri dati rimangono vostri e non vengono usati per altri scopi (es., per addestrare il modello pubblico).
• Il provider deve descrivere dove risiedono fisicamente i dati, per quanto tempo vengono conservati, chi può accedervi.
• Deve permettervi di fare richieste di accesso, cancellazione, portabilità per conto dei vostri utenti.

Prima di scegliere un provider LLM, chiedete esplicitamente: "Avete un DPA? I nostri dati vengono usati per fine-tuning del modello pubblico? Dove risiedono i dati?".

Provider	DPA disponibile?	Dati per training pubblico?	Note
OpenAI (Business)	Sì	No (se Business+DPA)	Richiede contratto commerciale
Azure OpenAI	Sì	No	Coperto da Microsoft Enterprise Agreement
Anthropic (Claude)	Sì	No (se enterprise)	Contattare sales per DPA
Groq	Da verificare	Da verificare	Chiedere direttamente
Llama (self-hosted)	N/A	No	Modello open, voi siete responsabili dell'hosting

# 3. Dove fisicamente risiedono i dati?

Il GDPR ha regole specifiche sui trasferimenti di dati al di fuori dell'UE/SEE. Se passate dati personali di cittadini UE a un provider con server negli USA (OpenAI, Anthropic, Groq), state facendo un trasferimento internazionale.

A novembre 2023, la Commissione UE ha approvato il "Data Privacy Framework" (DPF) che permette trasferimenti negli USA verso provider certificati. OpenAI, Google, Microsoft sono nella lista. Ma:

• Non è automatico: il vostro provider deve essere certificato e deve essere nella lista DPF ufficiale.
• Se usate un provider non certificato o con server in paesi non coperti da DPF o Adequacy Decision, potete comunque procedere ma dovete documentare "misure supplementari" (es., contratti con clausole di protezione, cifratura end-to-end).
• Se usate un'istanza locale di un modello open (es., Llama self-hosted), i dati rimangono in UE/vostro data center: zero problemi di trasferimento.

# 4. Come gestite i prompt e gli output?

Questo spesso viene sottovalutato: i prompt e le risposte dell'LLM sono "dati in movimento" che vanno trattati con cura.

Che cosa può contenere un prompt: il testo che inviate all'LLM potrebbe contenere dati personali (nomi, email, conversazioni di cliente, risultati medici, etc.). Questi rimangono dati personali anche mentre sono "in transito" verso il modello.

Che cosa può contenere un output: l'LLM potrebbe generare testo che contiene dati personali inferiti (es., la risposta include il nome di un cliente) o tracce di dati di addestramento che contengono identità riconoscibili.

Cosa fare concretamente:

• Loggare minimamente: non salvate interi prompt+output di un LLM "per debugging" senza una ragione specifica. Se lo fate, quei log contengono dati personali e dovete gestirli come tali (retention policy, accesso ristretto, crittografia).
• Non passate dati non necessari: se l'LLM ha bisogno del testo di una mail di cliente, ma non del suo nome, non passategli il nome. Anonimizzate quello che potete.
• Pulite gli output prima di usarli: se l'LLM genera una raccomandazione che contiene un'identità, decidete se tenerla nel record finale o eliminarla.
• Definite una retention policy: quanto tempo tenete i log di un'interazione LLM? Se è "forever", dovete documentare la ragione giuridica. Se è "90 giorni", documentate anche quello.

# 5. Come gestite le richieste di accesso, cancellazione, portabilità?

Se un utente esercita il diritto di accesso (art. 15 GDPR) o di cancellazione (art. 17), dovete essere in grado di rispondere. Con un LLM esterno, diventa più complesso.

Accesso (Right of Access): se un cliente vi chiede "quali dati avete su di me?", dovete essere capaci di mostrare tutti i dati, compreso ciò che è stato passato a un LLM esterno per elaborazione. Se usate OpenAI e non avete un sistema di tracking, come rispondete?

Cancellazione (Right to be Forgotten): se un cliente chiede di essere cancellato, dovete cancellare i dati dal vostro sistema e richiedere al provider LLM di cancellare tutti i log che lo contengono. Documentate che l'avete fatto.

Portabilità (Right to Data Portability): se un cliente chiede i suoi dati in formato strutturato, dovete fornire anche ciò che è stato elaborato da un LLM (es., le conversazioni, i risultati generati).

Implementate un sistema per tracciare quale dato è stato inviato a quale LLM e quando. Non è complesso, ma non è neanche invisibile: una semplice tabella nel vostro DB (user_id, timestamp, provider, data_type) vi salva da rischi legali enormi.

# 6. Base giuridica: perché potete davvero fare quello che fate?

Il GDPR richiede una "base giuridica" per ogni trattamento di dati personali. Non potete usare un LLM "perché vi va": dovete avere una ragione legale.

Le basi più comuni sono:

• Consenso: l'utente ha accettato esplicitamente che usiate un LLM per elaborare i suoi dati. Raro in practice perché la gente non consente specificamente questo.
• Contratto: usare un LLM è necessario per eseguire un servizio che l'utente ha richiesto (es., il cliente chiede una risposta automatizzata, voi la generate con un LLM). È la base più solida.
• Interesse legittimo: usate un LLM per migliorare l'efficienza interna, ridurre costi, etc. È valida ma meno solida di "contratto". Dovete documentare che avete bilanciato il vostro interesse contro i diritti dell'utente.
• Obbligo legale: usate un LLM per conformarsi a leggi (raro).

Nel vostro Registro dei trattamenti (art. 30), annotate esplicitamente quale base giuridica avete per ogni uso di LLM. "Interesse legittimo a automatizzare il customer service" è accettabile, ma dovete aver fatto un "Legitimate Interest Assessment" (LIA) per dimostrare che i benefici superano i rischi per l'utente.

# Quando NON dovete usare un LLM esterno (e quando potete considerare alternative)

Ci sono casi dove l'uso di un LLM remoto con dati personali è legalmente fattibile ma comunque rischioso o inefficiente:

• Dati molto sensibili (salute, finanza, procure legali): una soluzione self-hosted (Llama, Mistral locale) riduce drasticamente il rischio di data leak e trasferimenti internazionali. Costa di più in infrastruttura, ma vi toglie una classe intera di rischi compliance.
• Aziende con politiche di data residency rigide: se la vostra azienda o il vostro cliente richiede che i dati restino in UE a prescindere, un provider con data center in EU (Mistral, Aleph Alpha, alcune istanze di Anthropic) è obbligatorio. OpenAI USA rimane fuori.
• Volumi altissimi ma dati non sensibili: se passate milioni di record non personali a un LLM, il costo di un provider esterno cresce linearmente. Un modello locale ammortizza l'investimento infrastrutturale.
• Decisioni deterministiche critiche (approvazione crediti, diagnosi mediche, controllo di sicurezza): un LLM non dovrebbe mai essere l'unica base decisionale, ma se il GDPR vi richiede "non automated decision making senza supervisione umana", dovete avere un loop di approvazione manuale. Questo vale sia per LLM remoti che locali.

# La checklist finale prima di andare live

1. Identificare tutti i dati personali che l'LLM elaborerà. Documentarli.
2. Verificare se il vostro provider LLM ha un DPA valido. Se no, valutate provider alternativi o soluzione self-hosted.
3. Controllare dove risiedono i dati (UE? USA? Altrove?) e se la giurisdizione ha una decisione di adequacy o DPF con l'UE.
4. Definire una retention policy per prompt, output, e log.
5. Implementare un sistema di tracking: quale dato → quale LLM → quando.
6. Documentare la base giuridica per il trattamento. Se è "interesse legittimo", fare un LIA scritto.
7. Aggiornare il vostro Registro dei trattamenti (art. 30) con il nuovo flusso LLM.
8. Preparare una procedura di risposta per richieste di accesso, cancellazione, portabilità che includano dati elaborati da LLM.
9. Se raccogliete consenso, aggiornate la Privacy Policy e il consenso stesso per menzionare l'uso di LLM e il provider specifico.
10. Se l'LLM prende decisioni rilevanti per l'utente (es., assegna priorità a ticket), assicuratevi di avere override manuale e di comunicare all'utente che è coinvolto un sistema automatizzato.

Nessuno di questi punti è complicato singolarmente, ma insieme formano un sistema. Saltare uno perché "sembra poco importante" è come non documentare una dipendenza critica in produzione: non importa finché non importa.

Se siete una startup o PMI senza legal interno: considerate di fare una revisione GDPR con uno studio legale specializzato prima di implementare un LLM in un processo critico. Il costo iniziale (1.000-3.000 euro indicativi per una revisione leggera) è nulla rispetto al costo di una multa GDPR, che parte da 10.000 euro e può andare fino al 4% del fatturato globale annuale.