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.

Due dei riferimenti su cui questa guida era costruita sono cambiati. Il Regolamento (UE) 2026/1744 ha soppresso l’art. 10, par. 5 dell’AI Act e lo ha sostituito con un art. 4 bis più ampio; e il disegno di legge italiano sull’intelligenza artificiale è diventato la legge 23 settembre 2025, n. 132. Entrambi i passaggi sono ricostruiti qui sotto.

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 oggi contenuta nell’art. 4 bis 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: dall’art. 10, par. 5 al nuovo art. 4 bis

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 sull’orientamento sessuale.

Nella versione originaria l’AI Act se ne occupava all’art. 10, par. 5, che ammetteva quel trattamento nei soli sistemi ad alto rischio e in capo ai soli fornitori. Il Regolamento (UE) 2026/1744 ha soppresso quel paragrafo e ha inserito al suo posto un articolo autonomo, l’art. 4 bis, collocato fra le disposizioni generali.

Cosa è cambiato nel perimetro

La sostanza della vecchia norma resta al paragrafo 1, e riguarda ancora i fornitori di sistemi ad alto rischio. La novità è il paragrafo 2, che estende la stessa base giuridica a chi prima ne era escluso:

• i fornitori di altri sistemi e modelli di IA, quindi anche fuori dall’alto rischio;
• i deployer di altri sistemi e modelli di IA;
• i deployer di sistemi ad alto rischio, che restavano scoperti pur essendo quelli che il sistema lo usano davvero.

Per questi soggetti il trattamento è ammesso se strettamente necessario a rilevare e correggere distorsioni suscettibili di incidere sulla salute e sulla sicurezza delle persone, di avere impatto negativo sui diritti fondamentali o di comportare discriminazioni vietate dal diritto dell’Unione. Il testo aggiunge un inciso che vale per chi costruisce pipeline: specie laddove gli output di dati influenzano gli input per operazioni future, cioè nei sistemi che si riaddestrano su ciò che producono.

Le sei condizioni

Sono cumulative, si applicano tanto al paragrafo 1 quanto al paragrafo 2, e vanno soddisfatte oltre a quelle del GDPR, non al posto loro.

• Nessuna alternativa praticabile: il rilevamento e la correzione non sono realizzabili efficacemente trattando altri dati, compresi i dati sintetici o anonimizzati.
• Limitazioni tecniche al riutilizzo, con misure più avanzate di sicurezza e di tutela della vita privata, compresa la pseudonimizzazione.
• Accesso controllato e documentato: controlli e documentazione rigorosi dell’accesso, riservato a persone autorizzate e vincolate a obblighi di riservatezza.
• Nessuna condivisione: i dati non sono trasmessi, trasferiti né altrimenti consultati da terzi.
• Cancellazione quando la distorsione è stata corretta, o alla fine del periodo di conservazione, a seconda di quale delle due arriva prima.
• Motivazione nel registro delle attività di trattamento: perché il trattamento era strettamente necessario, e perché l’obiettivo non poteva essere raggiunto altrimenti.

La prima e l’ultima si tengono insieme e sono quelle che si sottovalutano di più: la disponibilità di dati sintetici o anonimizzati chiude la porta, e chi usa la base giuridica deve poter dimostrare a registro di averli valutati e scartati.

Una precisazione che vale la pena fare

Si legge spesso che l’AI Act avrebbe aperto un canale autonomo, capace di reggere il trattamento di dati sensibili senza passare dalle eccezioni dell’art. 9, par. 2, GDPR. Non è così, e il regolamento del 2026 lo chiarisce: la base giuridica opera dentro l’art. 9, par. 2, lett. g), il motivo di interesse pubblico rilevante, ed è costruita per garantirne il rispetto.

La differenza non è teorica. Vuol dire che l’art. 4 bis specifica un’eccezione che il GDPR già prevede, invece di aggiungerne una nuova, e che tutte le altre regole del GDPR – informativa, minimizzazione, sicurezza, diritti degli interessati – restano dovute per intero.

Il regolamento aggiunge infine una precisazione testuale che chiude ogni dubbio sulla natura della norma: «il presente paragrafo non crea alcun obbligo di rilevare e correggere tali distorsioni». È una facoltà per chi decide di farlo, non un adempimento nuovo.

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, obblighi in materia di lavoro, interesse vitale, ricerca scientifica con basi normative, e poche altre. Nessuna di queste si combina facilmente con l’addestramento di un sistema AI da parte di un soggetto privato, e il legittimo interesse, che pure regge in fase di sviluppo per i dati comuni, qui non è fra le opzioni disponibili.

Soccorre l’art. 4 bis AI Act, già visto al capitolo 2.3, che dal 2026 copre non solo i fornitori di sistemi ad alto rischio ma anche fornitori e deployer di altri sistemi e modelli. Ma il suo perimetro è preciso e stretto: vale solo per il rilevamento e la correzione delle distorsioni, e solo alle sei condizioni cumulative. Non è una base giuridica per addestrare un modello con dati sensibili, e chi la legge in quel modo la sta leggendo male.

Fuori da quel perimetro, restano applicabili tutti i requisiti del GDPR con le note difficoltà.

Il fronte italiano: dal disegno di legge alla legge 132/2025

Il disegno di legge sull’intelligenza artificiale, che nella prima versione di questa guida era ancora in iter parlamentare, è diventato la legge 23 settembre 2025, n. 132, in vigore dal 10 ottobre 2025. L’apertura che ci si attendeva c’è, ed è più stretta di quanto il testo in discussione lasciasse sperare.

L’art. 8 dichiara di rilevante interesse pubblico i trattamenti di dati eseguiti da soggetti pubblici e privati senza scopo di lucro, dagli IRCCS e da soggetti privati operanti nel settore sanitario, per la ricerca e la sperimentazione scientifica nella realizzazione di sistemi di IA in ambito sanitario. La dichiarazione è fatta in attuazione degli artt. 32 e 33 della Costituzione e, di nuovo, nel rispetto dell’art. 9, par. 2, lett. g), GDPR: la stessa architettura dell’art. 4 bis.

Due limiti vanno letti con attenzione da chi spera di appoggiarcisi. Il primo è il perimetro sanitario: la norma copre prevenzione, diagnosi, cura, apparati medicali, salute pubblica e studio della fisiologia e della biomeccanica umana, non la ricerca in generale. Il secondo è il profilo soggettivo: soggetti pubblici, privati senza scopo di lucro, IRCCS e operatori del settore sanitario. Una software house che sviluppa un prodotto commerciale resta fuori.

L’art. 9 rinvia poi a un decreto del Ministro della salute, sentito il Garante, per disciplinare le modalità semplificate del trattamento, anche particolare, per finalità di ricerca e sperimentazione, compreso l’uso secondario dei dati. Al momento della revisione il quadro attuativo va verificato: è il punto su cui conviene tenere l’occhio prima di costruirci sopra un progetto.

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 le categorie particolari salvo la facoltà dell’art. 4 bis AI Act, che dal 2026 copre anche i modelli non ad alto rischio e che vale nei soli limiti visti al capitolo 2.3. 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.

Conclusioni

Chi addestra sistemi AI con dati personali lavora in una zona dove il GDPR non offre risposte comode, e la tentazione ricorrente è cercarne una scorciatoia normativa. Le novità del 2025 e del 2026 sembrano offrirla e in realtà fanno il contrario: l’art. 4 bis dell’AI Act e l’art. 8 della legge 132/2025 passano entrambi per l’art. 9, par. 2, lett. g), GDPR, cioè restano dentro l’impianto europeo invece di aggirarlo. Sono specificazioni, non deroghe.

Il quadro operativo, allora, non cambia nella sostanza. Per i dati comuni in fase di sviluppo il legittimo interesse resta la sola strada praticabile, e regge se il triplice test è documentato prima e non ricostruito dopo. Per le categorie particolari non esiste una base generale: c’è una facoltà stretta per correggere le distorsioni, e c’è una previsione italiana che vale nel solo ambito sanitario e per soggetti che in gran parte non hanno scopo di lucro.

La nostra valutazione, dichiarata come tale: il vero discrimine non è quale base giuridica si sceglie, ma quando la si sceglie. Le condizioni dell’art. 4 bis – la cancellazione legata alla correzione della distorsione, il divieto di condividere con terzi, la motivazione a registro – si soddisfano solo se qualcuno le ha progettate prima che il modello esistesse. Chi arriva a queste norme con il sistema già in produzione scopre in genere di non essere più in condizione di usarle.

E c’è un punto che vale la pena dire per ultimo perché è quello che si dimentica per primo: i diritti degli interessati non si sospendono per difficoltà tecnica. Che rimuovere un dato dai parametri di un modello sia complicato è un problema di chi il modello lo ha costruito, non dell’interessato che chiede la cancellazione.

Punti chiave

Fonti