L’addestramento di sistemi AI con dati personali è la zona dove il GDPR mostra le sue tensioni più forti con le logiche tecniche dell’intelligenza artificiale. I modelli moderni hanno bisogno di enormi quantità di dati per funzionare. Il GDPR impone minimizzazione, finalità predefinite, base giuridica chiara, diritti degli interessati pienamente esercitabili. Conciliare le due esigenze richiede scelte sostanziali che SaaS, web agency e aziende tech devono saper documentare. Questa guida ricostruisce i tre nodi operativi più critici: come si applica il principio di minimizzazione ai pipeline AI, perché il legittimo interesse è di fatto l’unica base giuridica praticabile in fase di sviluppo, come si esercitano realmente i diritti degli interessati su un modello addestrato.

1. Il quadro generale: i tre nodi che determinano la liceità di un sistema AI

Quando un sistema AI tratta dati personali, l’applicazione del GDPR si gioca su tre nodi tra loro collegati.

Il primo è il principio di minimizzazione dei dati ex art. 5, par. 1, lett. c), GDPR: i dati devono essere adeguati, pertinenti e limitati a quanto necessario. In un contesto di addestramento massivo via web scraping il principio è difficile da applicare nella forma ortodossa, e le autorità di controllo stanno spostando l’asticella verso un modello “filtra e cancella” piuttosto che “non raccogliere”.

Il secondo è la base giuridica ex art. 6 GDPR. Nelle fasi di sviluppo e addestramento, di fatto, solo il legittimo interesse è praticabile, ma richiede un triplice test (esistenza dell’interesse, necessità del trattamento, bilanciamento con i diritti degli interessati) che diventa stringente quando entrano in gioco categorie particolari di dati ex art. 9 GDPR.

Il terzo è l’esercizio dei diritti degli interessati ex artt. 15-22 GDPR: informazione, rettifica, cancellazione, opposizione, revoca del consenso. Nel mondo AI questi diritti si scontrano con la natura stessa dei modelli, dove i dati personali “scompaiono” nei parametri dopo l’addestramento ma possono riemergere negli output.

Sotto questi tre nodi opera anche l’AI Act, in particolare con l’art. 10 sulla governance dei dati e con la previsione speciale dell’art. 10, par. 5 sul trattamento di categorie particolari nei sistemi ad alto rischio. La compliance reale si costruisce sull’integrazione tra i principi GDPR e le regole AI Act, non sulla loro applicazione parallela.

2. Minimizzazione dei dati nei sistemi AI: come applicarla davvero

Il principio di minimizzazione dei dati ex art. 5, par. 1, lett. c), GDPR è uno dei sei principi cardine. I dati personali raccolti devono essere adeguati, pertinenti e limitati a quanto necessario in relazione alle finalità.

Nei sistemi AI il principio si traduce in due valutazioni operative: una sulla quantità di dati raccolti e una sul grado di identificabilità mantenuto. Le Linee guida EDPB 4/2019 sull’art. 25 GDPR ricordano che la minimizzazione si valuta caso per caso, tenendo conto dello stato dell’arte tecnologico, e che impone al titolare di verificare se le finalità possono essere raggiunte trattando meno dati, dati aggregati, dati pseudonimizzati o non trattando affatto dati personali.

L’AI Act recepisce questa logica nell’art. 10 Reg. UE 2024/1689, dedicato a dati e governance dei dati per i sistemi ad alto rischio. La norma richiede che i set di addestramento, convalida e test soddisfino specifiche pratiche di governance e criteri di qualità, includendo annotazione, etichettatura, pulizia, arricchimento, aggregazione. I requisiti AI Act sull’art. 10 sono coerenti con la minimizzazione GDPR: non significano divieto di raccolta massiva, ma obbligo di filtrare, cancellare, anonimizzare in modo strutturato lungo il ciclo di vita.

2.1 Fase di sviluppo: il nodo del web scraping

In fase di sviluppo, i dati di addestramento spesso provengono da web scraping massivo. La raccolta indiscriminata di contenuti dal web pone una tensione frontale con il principio di minimizzazione: dati estranei, non pertinenti, talvolta appartenenti a categorie particolari, finiscono nei dataset.

L’autorità francese CNIL, nelle sue raccomandazioni sui sistemi AI dell’8 aprile 2024 e nei fogli successivi sottoposti a consultazione pubblica, ha adottato un approccio pragmatico: accetta che durante l’addestramento una raccolta sostanziale sia inevitabile, purché siano previsti meccanismi di filtraggio successivo che consentano la cancellazione o l’anonimizzazione dei dati non necessari. Le misure obbligatorie includono criteri di raccolta predefiniti, filtri per escludere categorie sensibili (transazioni bancarie, geolocalizzazione, minori, dati sensibili), eliminazione dei dati non pertinenti immediatamente dopo la raccolta, esclusione di siti che contengono per natura dati sensibili.

Per la raccolta accidentale di dati sensibili, la CNIL chiarisce — richiamando CGUE, 24 settembre 2019, causa C-136/17, GC e altri — che il divieto si applica nei limiti delle responsabilità e possibilità del soggetto, e che il trattamento residuale e involontario non è di per sé illecito se sono state adottate misure idonee di filtraggio.

Il Garante per la protezione dei dati personali italiano ha adottato un approccio diverso. Nel Provvedimento del 30 maggio 2024 sulle indicazioni per difendere i dati personali dal web scraping, l’autorità si è rivolta non tanto agli sviluppatori AI quanto ai titolari dei dati pubblicati online (webmaster, gestori di siti), suggerendo misure tecniche per impedire o ostacolare lo scraping: creazione di account privati, clausole anti-scraping nei termini di servizio, monitoraggio del traffico, interventi su file robots.txt, implementazione di CAPTCHA. Si tratta di misure non obbligatorie, da valutare in base al principio di accountability.

Le due posizioni convivono e disegnano il quadro attuale: chi addestra modelli con scraping deve filtrare ex post in modo rigoroso e documentato; chi pubblica dati online può (e per certi versi deve) adottare misure tecniche di protezione contro il riuso non autorizzato.

2.2 Fase di deployment: la responsabilità si sposta sul deployer

Una volta che il sistema AI è operativo, la minimizzazione non riguarda più solo lo sviluppatore ma anche il deployer. Chi usa un sistema AI in azienda, inserendo dati personali nei prompt o nei sistemi di input, deve a sua volta minimizzare quanto trasmette al sistema.

In questa fase le misure tipiche includono valutazione continua dei dati elaborati, tecniche di anonimizzazione “al volo”, privacy differenziale, K-anonymity, elaborazione selettiva. L’AI Act impone inoltre obblighi di conservazione dei log ex art. 12 per garantire la tracciabilità: si tratta di un’eccezione alla minimizzazione che il GDPR conosce bene (la conservazione finalizzata alla compliance) e che non genera conflitto sostanziale tra le due normative.

2.3 Categorie particolari di dati: la previsione speciale dell’art. 10, par. 5 AI Act

Un caso particolare riguarda il trattamento di categorie particolari di dati personali ex art. 9 GDPR (origine razziale o etnica, opinioni politiche, convinzioni religiose, dati genetici, biometrici, sanitari, dati sulla vita o orientamento sessuale).

L’art. 10, par. 5, Reg. UE 2024/1689 ammette espressamente il trattamento di categorie particolari nei sistemi ad alto rischio, nella misura strettamente necessaria a garantire il rilevamento e la correzione delle distorsioni (bias), a condizione che:

• il rilevamento e la correzione delle distorsioni non possano essere realizzati efficacemente trattando altri dati, compresi dati sintetici o anonimizzati, e la motivazione sia inserita nel registro dei trattamenti ex art. 30 GDPR;
• le categorie particolari siano soggette a limitazioni tecniche al riutilizzo e a misure di sicurezza avanzate, inclusa la pseudonimizzazione;
• siano previste garanzie adeguate, controlli rigorosi dell’accesso e documentazione;
• i dati non siano trasmessi a terzi;
• i dati vengano cancellati dopo la correzione del bias o al termine del periodo di conservazione.

È una delle previsioni più rilevanti del Regolamento, perché costruisce un canale autonomo che permette il trattamento di dati sensibili per finalità di equità algoritmica — un’esigenza tecnica reale — senza dover ricorrere alle eccezioni dell’art. 9, par. 2, GDPR, spesso impraticabili nei pipeline AI.

3. Base giuridica del trattamento: perché il legittimo interesse è (quasi) l’unica strada

Sotto il GDPR, ogni trattamento richiede una base giuridica ex art. 6, par. 1. Sei sono le basi disponibili: consenso, contratto, obbligo legale, interessi vitali, interesse pubblico, legittimo interesse. Per i sistemi AI in fase di sviluppo, la maggior parte di esse risulta inapplicabile per ragioni strutturali.

3.1 Perché le altre basi giuridiche non funzionano in fase di sviluppo

In fase di addestramento i dati personali provengono da terzi, sono stati raccolti per finalità diverse, lo sviluppatore non ha rapporto diretto con gli interessati. Di conseguenza:

• il consenso ex art. 6, par. 1, lett. a), GDPR è materialmente impossibile da raccogliere su milioni di interessati i cui dati arrivano via scraping;
• la necessità contrattuale ex lett. b) non si configura, perché non c’è contratto con gli interessati;
• l’obbligo legale ex lett. c) si applica solo se una legge UE o nazionale impone direttamente lo sviluppo di quel modello AI con quei dati, ipotesi rara salvo casi pubblicistici;
• gli interessi vitali ex lett. d) non rilevano salvo applicazioni AI medicali in scenari estremi;
• l’interesse pubblico ex lett. e) si applica solo ad autorità pubbliche o soggetti che svolgono funzioni di interesse pubblico, non a fornitori privati.

Resta il legittimo interesse ex art. 6, par. 1, lett. f), GDPR. È, di fatto, l’unica base giuridica praticabile per l’addestramento di modelli AI da parte di soggetti privati. Lo riconoscono, esplicitamente o implicitamente, autorità di controllo, EDPB nel Report della Taskforce ChatGPT del 23 maggio 2024, e la dottrina prevalente.

3.2 Il triplice test del legittimo interesse

Il legittimo interesse non è una base “comoda”: richiede una valutazione strutturata in tre passaggi.

Esistenza di un interesse legittimo. L’interesse deve essere manifestamente lecito, determinato in modo chiaro e preciso, reale e presente. La CNIL, nelle raccomandazioni citate, considera presuntivamente legittimi interessi come la ricerca scientifica, lo sviluppo di nuovi servizi, il miglioramento di prodotti esistenti, lo sviluppo di chatbot, il rilevamento di contenuti fraudolenti. L’obiettivo commerciale di sviluppare un sistema AI non è di per sé contrario al legittimo interesse. Non possono invece considerarsi legittimi gli interessi connessi allo sviluppo di sistemi vietati dalla legge — per esempio, sistemi che ricadrebbero tra le pratiche vietate dall’art. 5 AI Act, o che violerebbero altri divieti (per esempio l’art. 28 Reg. UE 2022/2065 DSA sulla profilazione dei minori per pubblicità mirata).

Necessità del trattamento. Vanno verificati i requisiti di proporzionalità (l’impatto sugli interessati è proporzionato alle finalità) e sussidiarietà (non sono disponibili mezzi meno invasivi per raggiungere lo stesso scopo). Pseudonimizzazione, aggregazione, privacy differenziale, K-anonymity, quando tecnicamente praticabili, rafforzano la giustificazione. Quando non lo sono — per esempio nei modelli image-based — lo sviluppatore deve documentare puntualmente perché.

Bilanciamento con i diritti degli interessati. È il test più impegnativo. Vanno valutati i benefici attesi (per il titolare, per gli utenti, per la collettività), la natura dei dati (sensibili, altamente personali, di minori), il contesto in cui sono stati originariamente pubblicati, le ragionevoli aspettative degli interessati. Più i benefici sono concreti e diffusi, più precise sono le finalità, più probabile che l’interesse legittimo prevalga. Lo sviluppo open source può pesare positivamente nel bilanciamento per ragioni di trasparenza e contributo alla comunità scientifica.

Il test va documentato in un assessment dedicato, parte integrante del registro dei trattamenti e del fascicolo di compliance. Senza documentazione, l’invocazione del legittimo interesse non regge a un controllo dell’autorità.

3.3 Il problema dei “dati manifestamente pubblici”

Una questione ricorrente riguarda i dati che gli interessati hanno reso pubblici online (post sui social, recensioni, commenti su forum). Il fatto che siano accessibili non significa che siano liberamente trattabili per qualsiasi finalità.

Per le categorie particolari, l’art. 9, par. 2, lett. e), GDPR ammette il trattamento se i dati sono “manifestamente resi pubblici dall’interessato”. La CGUE, nella sentenza Meta Platforms (CGUE, Grande Sezione, 4 luglio 2023, causa C-252/21), ha chiarito che la qualificazione dipende da scelte consapevoli ed espresse dell’interessato sulle impostazioni di visibilità. Se l’utente ha la possibilità di scegliere e sceglie consapevolmente di rendere pubblico il dato, la qualificazione è soddisfatta. Se semplicemente inserisce contenuti senza opzioni chiare, non basta.

Per i dati personali “comuni” pubblicamente accessibili, l’EDPB nel Report Taskforce ChatGPT del 23 maggio 2024 ha ricordato che la valutazione ex art. 6, par. 1, lett. f), GDPR deve considerare:

• se i dati siano stati resi pubblici dall’interessato stesso o da terzi;
• la natura dei dati (immagini, video, contenuti che rivelano opinioni politiche o orientamenti sessuali pongono problemi maggiori di recensioni di prodotti);
• il contesto di pubblicazione (sito web aperto, gruppo chiuso, social network) e i termini d’uso della piattaforma;
• la compatibilità con la finalità originaria: usare commenti pubblicati su un sito per addestrare un chatbot dello stesso sito è più giustificabile che usarli per addestrare un LLM generico.

Il punto è centrale e va affrontato esplicitamente in ogni progetto AI che si nutre di dati web. La regola pratica: pubblicità tecnica ≠ pubblicità giuridica ≠ lecito riutilizzo per finalità ulteriori.

3.4 Categorie particolari: dove il legittimo interesse non basta

L’art. 9 GDPR vieta in linea di principio il trattamento di categorie particolari, salvo le eccezioni tassative del par. 2 (consenso esplicito, obbligo lavoristico, interesse vitale, ricerca scientifica con basi normative, ecc.). Nessuna di queste basi si combina facilmente con l’addestramento AI di soggetti privati.

Per i sistemi ad alto rischio soccorre l’art. 10, par. 5 AI Act, già visto, che consente il trattamento di categorie particolari per il rilevamento e la correzione delle distorsioni. Fuori da questo perimetro specifico, restano applicabili tutti i requisiti del GDPR, con le note difficoltà.

Sul versante italiano, qualche apertura potrebbe arrivare dal disegno di legge sull’intelligenza artificiale (DDL 1146), che all’art. 7 qualifica come di rilevante interesse pubblico i trattamenti per finalità di ricerca e sperimentazione scientifica nello sviluppo di sistemi AI, per finalità terapeutiche e farmacologiche, da parte di soggetti pubblici e privati senza scopo di lucro. La portata della previsione, e la sua coerenza con il GDPR, andranno verificate nella versione definitiva [DA VERIFICARE: stato dell’iter legislativo al momento della pubblicazione].

4. L’esercizio dei diritti degli interessati: tra teoria e realtà tecnica

Gli artt. 15-22 GDPR riconoscono agli interessati diritti che dovrebbero essere esercitabili anche rispetto ai sistemi AI: accesso, rettifica, cancellazione, opposizione, revoca del consenso, limitazione, portabilità. Nella pratica, applicarli a un modello addestrato pone problemi tecnici non banali.

4.1 Diritto di informazione

L’art. 13 GDPR (raccolta diretta) e l’art. 14 GDPR (raccolta indiretta) impongono obblighi informativi puntuali. Nella fase di deployment il rispetto è in linea di principio gestibile: l’utente che inserisce dati nel sistema può ricevere informativa diretta.

Nella fase di sviluppo via scraping la situazione è diversa. L’art. 14 si applica, ma l’art. 14, par. 5, lett. b), prevede l’esenzione dall’informazione individuale quando questa risulta impossibile o richiederebbe uno sforzo sproporzionato. È l’unica via percorribile per modelli addestrati su milioni di interessati: l’informazione si fornisce attraverso avvisi accessibili sul sito dello sviluppatore, integrati con la documentazione richiesta dall’AI Act sulle fonti dei dati.

4.2 Diritto di rettifica e aggiornamento

Il diritto di rettifica ex art. 16 GDPR pone problemi reali nei modelli generativi: come si “corregge” un’informazione che un LLM ha appreso e che può riprodurre in modo non deterministico?

La CNIL suggerisce un approccio operativo: lo sviluppatore può implementare una procedura interna che interroga il modello su dati specifici per verificare cosa abbia memorizzato. L’interessato indica l’URL della pagina di origine e l’area testuale rilevante; lo sviluppatore esegue test mirati e, dove possibile, interviene con tecniche di “machine unlearning” o riaddestramento parziale. Quando il riaddestramento è sproporzionato, può essere offerto in alternativa il diritto all’oblio o l’opposizione, con esclusione dei dati dell’interessato dagli output.

4.3 Diritto di opposizione e di cancellazione

Il diritto di opposizione ex art. 21 GDPR si applica quando la base giuridica è il legittimo interesse — la base più usata nei sistemi AI. La richiesta dell’interessato comporta la cessazione del trattamento salvo che il titolare dimostri motivi legittimi cogenti prevalenti.

Il diritto di cancellazione ex art. 17 GDPR pone la questione più delicata: i parametri del modello, dopo l’addestramento, sono ancora dati personali? Se sì, la cancellazione comporta in teoria il riaddestramento. Se no, la cancellazione si limita ai dataset originali e agli output.

La questione è aperta e sarà la giurisprudenza, probabilmente la CGUE, a stabilire i confini. Le possibili soluzioni intermedie includono filtri di output che impediscano la riproduzione dei dati dell’interessato, riaddestramento parziale dove tecnicamente fattibile, documentazione delle valutazioni di proporzionalità tra diritto dell’interessato e libertà d’impresa del titolare.

Nel frattempo, la regola pratica è: costruire pipeline AI che mantengano la tracciabilità dei dati di addestramento per consentire risposte concrete alle richieste degli interessati, e adottare un approccio caso per caso documentato.

4.4 Revoca del consenso e decisioni automatizzate

La revoca del consenso ex art. 7, par. 3, GDPR rileva nei casi rari in cui il consenso è la base giuridica usata. Più importante, nei sistemi AI ad alto rischio, è l’art. 22 GDPR sul diritto a non essere sottoposti a decisioni esclusivamente automatizzate che producono effetti giuridici o significativamente analoghi. La norma resta pienamente applicabile a fianco dell’AI Act: chi adotta un sistema AI per credit scoring, screening dei CV, decisioni amministrative, deve garantire forme di intervento umano significativo, non un mero “rubber stamping”.

5. Casi pratici: come si costruisce la compliance reale

Tre situazioni dove i tre nodi si intrecciano.

Una startup che sviluppa un modello AI di analisi del linguaggio addestrato su contenuti web pubblici. La base giuridica è il legittimo interesse, va documentata con un assessment dedicato. La minimizzazione si attua filtrando i dataset secondo le raccomandazioni CNIL, escludendo categorie particolari salvo deroga ex art. 10, par. 5 AI Act. L’informazione agli interessati avviene tramite avviso sul sito ex art. 14, par. 5, lett. b), GDPR. I diritti di opposizione e cancellazione sono gestiti con una procedura interna che valuti caso per caso la fattibilità tecnica.

Una web agency che addestra un modello di brand voice usando contenuti dei social di un cliente. Vanno verificate la qualificazione dei dati come “manifestamente pubblici” (raramente lo sono in senso giuridico stretto), la compatibilità della finalità originaria con il riuso AI, le ragionevoli aspettative degli utenti. Spesso la strada più sicura è limitare il dataset ai contenuti pubblicati direttamente dal cliente e dai dipendenti previo loro consenso esplicito.

Un SaaS HR che integra un GPAI per il pre-screening dei CV. Il SaaS è fornitore del proprio sistema, che ricade nell’Allegato III AI Act (sistema ad alto rischio). Il cliente che lo adotta è deployer. La base giuridica del trattamento dei dati dei candidati è di norma il legittimo interesse del datore di lavoro, con DPIA obbligatoria ex art. 35 GDPR. L’art. 22 GDPR impone l’intervento umano significativo nella decisione finale. La FRIA ex art. 27 AI Act non grava sul SaaS, ma le informazioni che il SaaS deve fornire ex art. 13 AI Act sono essenziali per consentire al deployer di adempiere ai propri obblighi GDPR.