EDPB Joint Opinion 28/2024: il three-step test per training AI su dati personali sotto GDPR

Il 21 gennaio 2026 l'European Data Protection Board ha pubblicato un chiarimento sull'Opinion 28/2024 specificando l'applicazione del three-step test del legitimate interest (GDPR Art. 6(1)(f)) al training di modelli AI su dati personali. Sul mio Hetzner CCX33 (8 vCPU AMD EPYC 9454P, 32 GB RAM DDR5) ho passato un pomeriggio a leggere il documento integrale e a costruire il template di Legitimate Interest Assessment (LIA) che applico nei progetti consulenziali quando il cliente fa fine-tuning su corpus aziendale che include dati di clienti, dipendenti o terze parti. La parte controversa del documento è specifica: l'EDPB sostiene che un modello AI può essere considerato "anonimo" solo se l'estrazione di dati personali identificabili dal modello stesso è "insignificante". Tradotto in pratica: un modello fine-tuned su dataset che includeva nomi e indirizzi di clienti, anche se il modello non rigurgita esattamente quei nomi quando interrogato, non è automaticamente "anonimo" per il GDPR. Resta sotto la disciplina del regolamento, e l'azienda che lo ha trainato è titolare del trattamento per la durata della vita del modello.

Il pattern operativo che il three-step test impone alla PMI italiana che fa fine-tuning o RAG su dati clienti è strutturato in modo logico ma esigente nei dettagli. Tre fasi sequenziali: purpose test (l'interesse legitimate è chiaro, specifico, attuale), necessity test (il trattamento è necessario per perseguire quell'interesse, non c'è alternativa meno invasiva), balancing test (l'interesse del titolare prevale sui diritti e interessi del data subject, considerando aspettative ragionevoli, misure tecniche di mitigation, possibilità di opt-out). L'EDPB nel chiarimento gennaio 2026 ha sottolineato che il balancing test va rifatto con criteri specifici per l'AI: la stessa attività che sarebbe lecita per CRM tradizionale può non esserlo per training di modelli AI con potenziale di memorization e generalization fuori controllo.

Le tre fasi del three-step test in pratica

Fase uno: Purpose Test. La domanda centrale è "qual è l'interesse legitimate del titolare e perché serve trattare dati personali per perseguirlo?". Per training AI aziendale, gli interessi legitimate tipicamente riconosciuti includono: miglioramento del servizio offerto ai propri clienti, automazione di processi interni con beneficio operativo misurabile, ricerca e sviluppo di nuovi prodotti basati su AI, analisi di feedback per qualità del prodotto. L'interesse va dichiarato con specificità: non basta "miglioriamo l'AI", serve "ottimizziamo il sistema di customer support per ridurre i tempi di risposta del 30%" o equivalente concreto. La purpose dichiarata diventa il vincolo per le fasi successive: il trattamento è lecito solo per quello scopo, non per altri usi che emergano successivamente.

Fase due: Necessity Test. La domanda è "il trattamento di dati personali è davvero necessario per quell'interesse, o esistono alternative meno invasive?". Per training AI, le alternative tipiche da valutare sono: dataset sintetico generato senza dati reali, dataset pubblico già anonimizzato, fine-tuning su sottoinsieme ridotto e accuratamente selezionato, uso di tecniche di privacy-preserving learning (federated learning, differential privacy, secure multi-party computation). Se una di queste alternative produce risultato equivalente al training su dati reali, il trattamento di dati reali NON è necessario e il legitimate interest fallisce qui. La PMI deve documentare di aver valutato e scartato le alternative con motivazione.

Fase tre: Balancing Test. La domanda è "l'interesse legitimate del titolare prevale sui diritti e gli interessi del data subject in questo caso specifico?". È la fase più complessa perché richiede valutazione di multiple variabili: aspettative ragionevoli del data subject (un cliente di e-commerce si aspetta che i suoi dati siano usati per training AI? probabilmente no), categoria del dato (dati sensibili Art. 9 sono categoria particolare e tipicamente non passano il balancing), misure tecniche di mitigation applicate (differential privacy, output filter), possibilità reale di opt-out (esiste meccanismo accessibile e effettivo per il data subject?), conseguenze potenziali in caso di breach o memorization (un modello che ha memorizzato dati e può rivelarli su prompt malicioso è una superficie di rischio). L'EDPB nel chiarimento ha sottolineato che il balancing va fatto valutando il modello come sistema dinamico, non come snapshot al momento del training: l'evoluzione successiva via prompting può estrarre dati che al momento del training sembravano "anonimi".

Se devi pianificare un fine-tuning o un RAG su dati clienti

Nel mio hub dedicato all'AI per aziende, sezione security raccolgo articoli su compliance e governance AI applicate al perimetro italiano. La pianificazione corretta del three-step test è prerequisito non opzionale per qualunque training AI che tocchi dati personali, e va fatta prima del progetto, non dopo. Il consulente serio porta sul tavolo del cliente PMI italiana questa documentazione come deliverable strutturato.

Misure tecniche che spostano il balancing test

Il balancing test ha un meccanismo di compensazione: misure tecniche di mitigation aumentano il peso del titolare e possono spostare l'equilibrio verso la liceità. Le quattro misure più rilevanti per training AI nel 2026 sono le seguenti.

Differential Privacy applicata in fase di training (DP-SGD, Differentially Private Stochastic Gradient Descent) inietta rumore calibrato durante la backpropagation in modo che l'influenza di un singolo data point sul modello finale sia matematicamente bounded. Il parametro epsilon controlla il trade-off privacy/utility; epsilon basso (1-3) garantisce forte privacy con qualche perdita di accuracy, epsilon alto (10+) preserva accuracy ma offre privacy meno garantita. Per fine-tuning su dataset aziendali, epsilon 4-8 è il sweet spot tipico nel 2026 con modelli moderni.

Filtraggio output al modello per impedire la rivelazione di dati personali memorizzati. Il pattern operativo è un layer di post-processing che scansiona la response per pattern di dati personali (nomi, codici fiscali, indirizzi, IBAN, numeri di telefono italiani) e li redact prima di mostrare all'utente. Il pattern non è perfetto (un attaccante motivato può ottenere data via prompting tortuoso) ma è una difesa di profondità che il balancing test apprezza.

Opt-out effettivo per il data subject che chiede di non essere incluso nel training futuro. Il pattern richiede UI dedicata, processo automatizzato, evidence di applicazione (se il data subject ha optato out a settembre, il fine-tuning di novembre deve effettivamente escludere i suoi dati). Per il pubblico italiano, il diritto di opposizione ex GDPR Art. 21 va presidiato esplicitamente.

Riduzione del perimetro di dati al minimo necessario. Anche con legitimate interest valido, il principio di minimizzazione (GDPR Art. 5(1)(c)) impone di trattare solo quei dati strettamente necessari. Per training AI questo significa selezione esplicita dei field rilevanti, esclusione preventiva di dati sensibili, anonimizzazione strutturata dove possibile dei field meno critici. Il pattern di tokenizzazione che ho descritto nell'articolo sulla tassa nascosta della tokenizzazione italiana ha anche un beneficio collaterale di compliance: meno token significa minore esposizione di dati al provider esterno.

Template LIA per fine-tuning e RAG su dati clienti

Riporto qui sotto la struttura del template LIA che applico nei progetti, adattabile al perimetro specifico del cliente.

Legitimate Interest Assessment - Training AI su dati personali

1. IDENTIFICAZIONE DEL TRATTAMENTO
   - Titolare: [Nome azienda + sede + DPO ref]
   - Tipo trattamento: [fine-tuning | RAG ingestion | embedding generation]
   - Modello: [es. Claude Opus 4.7 fine-tuned via Anthropic API]
   - Data inizio: [YYYY-MM-DD] - Durata stimata: [N mesi]

2. PURPOSE TEST
   - Interesse legitimate: [descrizione specifica dell'interesse del titolare]
   - Beneficio atteso: [misurabile, p.es. -30% tempo risposta customer support]
   - Alternative al training su dati reali considerate e scartate: [elenco con motivazione]

3. NECESSITY TEST
   - Categoria dati personali coinvolti: [Art. 4(1) GDPR + eventuale Art. 9]
   - Field specifici: [elenco esplicito, principio di minimizzazione]
   - Volume: [N record stimati]
   - Provenienza: [propri clienti / fornitori / pubblico]

4. BALANCING TEST
   - Aspettative ragionevoli del data subject: [valutazione]
   - Misure tecniche di mitigation applicate:
     [ ] Differential Privacy (epsilon: ___)
     [ ] Output filtering personalizzato
     [ ] Opt-out effettivo via [meccanismo]
     [ ] Minimizzazione dei field
     [ ] Audit trail tamper-evident
   - Bilanciamento: [pro titolare vs pro data subject, motivato]

5. INFORMATIVA E COMUNICAZIONE
   - Aggiornamento privacy policy: [data + contenuto specifico]
   - Comunicazione al data subject: [canale e tempistica]
   - Diritto di opposizione: [come esercitabile, tempi di risposta]

6. DOCUMENTAZIONE TECNICA
   - DPIA (se richiesta da Art. 35 GDPR): [riferimento]
   - Audit interno periodico: [tipologia + frequenza]
   - Incident response: [procedura specifica per data leakage AI]

7. APPROVAZIONE
   - DPO: [nome + data + firma]
   - Senior Management: [nome + data + firma]
   - Revisione prevista: [YYYY-MM-DD, tipicamente 12 mesi]

Il template va contestualizzato sul caso specifico. La parte spesso sottovalutata è la sezione 5 (informativa e comunicazione): troppe PMI italiane fanno fine-tuning su dati clienti senza aggiornare la privacy policy con menzione esplicita dell'uso AI, e questo da solo invalida il legitimate interest. La sezione 6 (audit periodico) è altrettanto importante: il training AI è un processo che evolve, e il LIA del giorno uno potrebbe non essere più valido al sesto mese se le condizioni operative cambiano.

Casi limite del three-step test specifici per il mercato italiano

Tre casi limite ricorrenti che ho incontrato nei progetti italiani vale la pena nominare specificatamente, perché ognuno richiede modulazione del template generale.

Caso uno: dati di clienti business-to-business che includono nominativi di referenti aziendali con email professionale. Il three-step test si applica anche se il dato è "professionale" e non "personale" in senso stretto, perché il referente è una persona fisica con propri diritti GDPR. La PMI italiana che fa training su CRM B2B contenente "Mario Rossi, responsabile acquisti, [email protected]" deve trattare quei dati come dati personali, non come "dati aziendali". Il pattern di adoption italiano sottovaluta sistematicamente questo punto, e quando emerge in audit del Garante diventa il motivo più frequente di sanzione su training AI in contesto B2B.

Caso due: dati storici di archivio che includono persone deceduti o non più rintracciabili. Il GDPR si applica solo a persone fisiche viventi, ma il principio di minimizzazione resta valido e il LIA deve documentare i criteri di esclusione di dati di soggetti decuduti. Il pattern operativo è un filtro pre-training che rimuove record con flag "deceduto" se presente nel CRM, oppure record con ultimo aggiornamento oltre soglia temporale (tipicamente 10+ anni) come proxy.

Caso tre: dati raccolti via legitimate interest per una purpose originaria diversa dal training AI. Esempio: indirizzi email raccolti per newsletter commerciale, ora usati per training su contesto di customer service. Il GDPR Art. 6(4) impone compatibility test fra purpose originaria e nuova purpose: se incompatibili, serve nuovo legitimate interest assessment o nuova base giuridica (consenso esplicito). Il pattern di compatibilità è raramente automatico e va valutato caso per caso.

Differenza fra LIA per training e LIA per inference

Una distinzione operativa importante che il consulente deve fare al cliente: il LIA per la fase di training è diverso dal LIA per la fase di inference su un modello già trainato. Il primo riguarda il trattamento di dati personali in fase di learning del modello; il secondo riguarda il trattamento di dati personali quando il modello viene interrogato in produzione. I due hanno purpose, necessity e balancing distinti. Esempio: addestrare un modello sui propri dati di clienti per migliorare il servizio (LIA training) è diverso dall'usare il modello in produzione per rispondere alle domande di nuovi clienti (LIA inference).

Per il LIA inference le variabili tipiche sono: il modello memorizza i dati delle conversazioni? il provider del modello backbone (Anthropic, OpenAI, Google) ha contratti DPA validi? i log delle conversazioni vengono usati dal provider per loro training (opt-out attivato?)? Il caso Anthropic, che a metà 2024 ha cambiato il default privacy policy verso "non usiamo i dati API per training se non opt-in esplicito", è un buon esempio di provider che ha gestito proattivamente questa preoccupazione. Per OpenAI, lo stesso pattern è stato implementato per le richieste API enterprise con contratto DPA dedicato. Per provider meno maturi sul fronte privacy o per modelli self-hosted con orchestrator interno, il rischio è significativo e va presidiato esplicitamente nel LIA inference dedicato.

L'integrazione con il framework ISO 42001 che ho descritto in dettaglio nel pezzo dedicato all'implementazione 90 giorni è naturale: il LIA per training AI è uno dei deliverable del controllo A.6.2 (AI Impact Assessment), e archiviarlo nello stesso repository di compliance produce sinergia documentale. Per le PMI italiane che stanno strutturando il programma AI nel 2026, il pacchetto "ISO 42001 + LIA per ogni training + privacy policy aggiornata + audit trail" è il setup minimo difendibile davanti a un'ispezione del Garante. Se vuoi una conversazione tecnica per fare un audit del tuo training AI attuale alla luce dell'EDPB Opinion 28/2024, oppure se devi predisporre il LIA per un nuovo progetto di fine-tuning o RAG su dati clienti italiani, il modulo di preventivo gratuito è il punto da cui inquadrare la richiesta in due minuti, sette domande, prima della prossima ispezione del Garante o della prossima richiesta di accesso del data subject.