Il rapporto tra AI Act e GDPR è la questione che più spesso emerge nei progetti AI di SaaS, web agency e aziende tech. Il Regolamento UE 2024/1689 disciplina sistemi e modelli di intelligenza artificiale; il Regolamento UE 2016/679 disciplina il trattamento dei dati personali. Quando un’azienda sviluppa, integra o usa un sistema AI che tratta dati personali – e quasi sempre li tratta – si trova ad applicare due normative parallele, con logiche diverse, autorità diverse, valutazioni di rischio diverse. Capire come si parlano è il presupposto di qualsiasi strategia di compliance sostenibile. Questa guida ricostruisce l’architettura del rapporto: ambito di applicazione, definizioni, differenze di approccio, intersezione tra DPIA, FRIA e valutazione di conformità.

Il quadro è cambiato nel luglio 2026. Il Regolamento (UE) 2026/1744 ha modificato quarantatré articoli dell’AI Act, e due di quelle modifiche riguardano proprio il punto di contatto con il GDPR: la clausola di salvaguardia dell’art. 2 non è più incondizionata, ed è comparso un art. 4 bis che autorizza, a certe condizioni, il trattamento di categorie particolari di dati personali.

1. Il quadro generale: due normative che si sovrappongono ma non coincidono

L’AI Act non sostituisce e non assorbe il GDPR. Lo dice l’art. 2 Reg. UE 2024/1689 e, ancora più chiaramente, il Considerando 10, secondo cui il Regolamento non pregiudica l’applicazione del diritto dell’Unione in materia di trattamento dei dati personali e lascia impregiudicati gli obblighi di fornitori e deployer nel loro eventuale ruolo di titolari o responsabili del trattamento. Gli interessati continuano a godere di tutti i diritti del GDPR, inclusi quelli connessi al processo decisionale automatizzato e alla profilazione.

Su un punto, però, la formula va aggiornata. Il Regolamento (UE) 2026/1744 ha riscritto il paragrafo 7 dell’art. 2, e la clausola di salvaguardia oggi ha due eccezioni espresse: il regolamento lascia impregiudicati il GDPR, il Reg. (UE) 2018/1725, la direttiva ePrivacy e la direttiva (UE) 2016/680 «fatti salvi gli articoli 4 bis e 59».

Sono poche parole e cambiano l’architettura. Fino al luglio 2026 l’AI Act non toccava mai la disciplina della protezione dei dati: rinviava, si affiancava, non derogava. Da quel momento l’AI Act contiene due norme che sul trattamento dei dati personali dicono qualcosa di proprio: l’art. 59, che riguarda il riutilizzo dei dati dentro gli spazi di sperimentazione normativa, e l’art. 4 bis, che è la novità e a cui dedichiamo il capitolo 5.

Non è una prevalenza dell’AI Act sul GDPR, ed è bene dirlo per non generare equivoci: entrambe le disposizioni si muovono dentro lo spazio che il GDPR stesso lascia al diritto dell’Unione. Ma chi fa la mappa delle basi giuridiche del proprio progetto AI oggi ha una casella in più da considerare, e non sta nel GDPR.

Il punto di partenza, quindi, è semplice: per ogni progetto AI vanno fatte due verifiche, non una sola. Si verifica se l’AI Act si applica (sistema o modello di IA, ruolo del soggetto, classificazione del rischio) e, parallelamente, se il trattamento di dati personali ricade nel GDPR (cosa è dato personale, chi è il titolare, qual è la base giuridica, quali sono i diritti degli interessati). I due perimetri si sovrappongono per buona parte, ma non coincidono. Un sistema AI può non trattare dati personali – e allora si applica solo l’AI Act. Un trattamento di dati personali può non riguardare un sistema AI – e allora si applica solo il GDPR. Nei moltissimi casi intermedi, entrambe le normative concorrono.

Il Regolamento si inserisce d’altronde in una strategia europea più ampia (Data Act, Data Governance Act, Digital Services Act, Digital Markets Act, European Health Data Space) che mantiene il GDPR come normativa primaria di riferimento per la protezione dei dati personali, attraverso clausole di salvaguardia. La gerarchia delle fonti non si pone in termini di prevalenza, ma di complementarità: la protezione dei dati personali, sancita dall’art. 8 della Carta dei diritti fondamentali UE, è un diritto fondamentale che opera come parametro trasversale rispetto a tutte le altre normative digitali.

2. Ambito di applicazione: dove finisce un perimetro e inizia l’altro

Per capire quando si applicano entrambe le normative, servono due definizioni: cosa è “dato personale” ai sensi del GDPR e cosa è “sistema di IA” ai sensi dell’AI Act.

2.1 Cosa è dato personale (e perché nei sistemi AI è più complicato del solito)

L’art. 4(1) GDPR definisce dato personale qualsiasi informazione riguardante una persona fisica identificata o identificabile. La definizione è ampia e ricomprende identificativi diretti (nome, codice fiscale), indiretti (un identificativo online), e qualsiasi elemento caratteristico dell’identità fisica, fisiologica, genetica, psichica, economica, culturale o sociale.

L’art. 4(5) GDPR introduce la nozione di pseudonimizzazione: un trattamento che separa i dati personali dalle informazioni aggiuntive necessarie per ricondurli all’interessato. I dati pseudonimizzati restano dati personali a tutti gli effetti – la pseudonimizzazione è una misura di sicurezza, non una via d’uscita dal GDPR.

Diverso il caso dei dati anonimi, che non si riferiscono ad alcuna persona fisica identificata o identificabile e ai quali il GDPR non si applica. Ma il confine è incerto. La Corte di Giustizia UE, nella sentenza Breyer (CGUE, 19 ottobre 2016, causa C-582/14), ha chiarito che un indirizzo IP dinamico è dato personale quando il fornitore di servizi può, con mezzi ragionevolmente disponibili e l’eventuale cooperazione di terzi, ricondurlo a una persona. Il riferimento operativo per valutare l’anonimizzazione resta il Parere 5/2014 del WP29, che individua tre rischi (individuazione, collegabilità, inferenza), in attesa delle attese linee guida EDPB sulle tecniche di anonimizzazione.

Più di recente, il Tribunale UE (sentenza 26 aprile 2023, causa T-557/20, SRB c. EDPS, attualmente in appello davanti alla CGUE) ha aperto a un’interpretazione “relativistica” dell’anonimizzazione: la valutazione se un dato sia personale può variare dal punto di vista del destinatario, sulla base dei mezzi che questi ha effettivamente per identificare l’interessato. Se la posizione fosse confermata, si aprirebbe uno spazio importante per la circolazione dei dati nei pipeline AI.

Tutto questo è cruciale nei sistemi AI per una ragione tecnica precisa: la tokenizzazione. I modelli linguistici trasformano i testi in token, unità minime che alimentano gli algoritmi. Dal punto di vista privacy, il token funziona in modo analogo a un identificativo pseudonimizzato. La domanda – se i parametri di un modello addestrato su dati personali siano essi stessi dati personali – è ancora aperta, e influenza in modo decisivo l’applicabilità del GDPR ai modelli post-training.

2.2 Cosa è sistema di IA secondo l’AI Act

L’art. 3(1) Reg. UE 2024/1689 definisce sistema di IA un sistema automatizzato progettato per funzionare con livelli di autonomia variabili, con possibile adattabilità dopo la diffusione, che per obiettivi espliciti o impliciti deduce dagli input come generare output (previsioni, contenuti, raccomandazioni, decisioni) capaci di influenzare ambienti fisici o virtuali. I modelli di IA (GPT, Claude, Gemini) sono invece componenti dei sistemi: addestrati su grandi quantità di dati, diventano operativi quando integrati in un sistema.

La conseguenza è importante. Lo stesso progetto può richiedere valutazioni distinte per modello e sistema, e può coinvolgere soggetti diversi (provider del modello, provider del sistema, deployer). Lungo il ciclo di vita di un sistema AI che usa dati personali, distinguiamo classicamente:

• dati di addestramento, raccolti per addestrare il modello attraverso l’adattamento dei suoi parametri;
• dati di convalida, usati per regolare i parametri non apprendibili;
• dati di test, usati per validare le prestazioni prima del lancio;
• dati di input, forniti al sistema in fase operativa;
• dati di output, prodotti dal sistema, che possono rientrare nei nuovi cicli di addestramento.

In ognuna di queste fasi possono comparire dati personali. E in ognuna possono cambiare il titolare del trattamento, la finalità, la base giuridica.

3. Due approcci diversi alla stessa realtà: accountability vs risk-based prodotto

Qui sta la differenza concettuale più importante, quella che spiega perché AI Act e GDPR sembrano spesso “parlarsi addosso” senza incontrarsi.

Il GDPR si fonda sul principio di accountability (art. 5, par. 2, GDPR). Il titolare del trattamento valuta autonomamente i rischi del trattamento, sceglie la base giuridica, individua le misure tecniche e organizzative adeguate, documenta tutto. È un self-assessment continuo, calibrato sui principi cardine dell’art. 5 GDPR (liceità, correttezza, trasparenza, finalità, minimizzazione, esattezza, limitazione della conservazione, integrità e riservatezza). L’autorità di controllo interviene ex post, in caso di violazione o segnalazione.

L’AI Act adotta invece un approccio risk-based prodotto, modellato sulle normative di product compliance (dispositivi medici, veicoli, macchine). Non è l’operatore a valutare se un sistema AI sia rischioso: è la legge stessa a classificarlo ex ante. Le pratiche vietate dell’art. 5 sono vietate sempre. I sistemi ad alto rischio elencati nell’Allegato III sono presunti tali per legge. Per uscire dalla presunzione bisogna documentare la deroga ex art. 6, par. 3. Per immettere sul mercato un sistema ad alto rischio servono valutazione di conformità, marcatura CE, dichiarazione di conformità UE, registrazione nella banca dati UE. Senza, il sistema si presume non conforme.

Il cambio di paradigma ha conseguenze pratiche enormi. Sotto il GDPR un trattamento è lecito se il titolare ha fatto bene le sue valutazioni e può dimostrarlo. Sotto l’AI Act un sistema ad alto rischio è lecito se ha i marchi, le certificazioni e la documentazione tecnica previsti. Per le aziende AI questo significa doppia compliance: una di tipo organizzativo (GDPR), una di tipo prodotto (AI Act). Le due si sovrappongono ma seguono logiche diverse e, in alcune giurisdizioni, autorità diverse.

4. Valutazioni di rischio: DPIA, FRIA e valutazione di conformità

Entrambe le normative impongono valutazioni di rischio, ma con scopi e contenuti differenti. È l’area dove la doppia compliance produce più confusione, e dove serve maggiore disciplina metodologica.

4.1 Le valutazioni richieste dal GDPR

Sotto il GDPR, il titolare deve effettuare diverse valutazioni a seconda dello scenario:

• per i principi di minimizzazione e limitazione, verifica se esistono modalità di trattamento meno invasive per raggiungere la finalità;
• per la base giuridica del legittimo interesse ex art. 6, par. 1, lett. f), GDPR, conduce il test di bilanciamento tra l’interesse perseguito e i diritti e libertà degli interessati;
• per i trattamenti che possono comportare un rischio elevato per i diritti degli interessati, redige la DPIA ex art. 35 GDPR, considerando origine e natura dei dati, finalità, strumenti, gravità del rischio;
• in caso di incertezza residua sulle misure di sicurezza, può attivare la consultazione preventiva dell’autorità di controllo ex art. 36 GDPR.

La DPIA, nella prassi consolidata, ha assunto spesso un taglio prevalentemente tecnico-organizzativo, concentrato sulle misure di sicurezza contro il data breach. Meno frequenti, ma non meno importanti, le valutazioni sostanziali su finalità, proporzionalità, effetti della profilazione (discriminazione, pregiudizi, esclusione).

4.2 Le valutazioni richieste dall’AI Act

L’AI Act introduce un sistema di valutazioni proprio:

• la valutazione di conformità ex art. 43 Reg. UE 2024/1689 per i sistemi ad alto rischio, che porta alla marcatura CE e alla dichiarazione di conformità UE;
• il sistema di gestione dei rischi ex art. 9, attività iterativa continua lungo tutto il ciclo di vita del sistema;
• le pratiche di governance dei dati ex art. 10 per i dati di addestramento, convalida e test, che dal 2026 rinviano anche all’art. 4 bis, par. 1;
• la FRIA (Fundamental Rights Impact Assessment) ex art. 27, valutazione preventiva sui diritti fondamentali, dovuta da alcuni deployer per alcuni sistemi ad alto rischio.

Gli scenari di rischio sono in larga parte predeterminati dalla legge. Le valutazioni non riguardano solo la protezione dei dati ma anche pregiudizi, discriminazione, sicurezza, violazioni dei diritti fondamentali in senso ampio.

4.3 Come si intersecano in pratica

L’art. 26, par. 9, Reg. UE 2024/1689 prevede espressamente che i deployer di sistemi AI ad alto rischio usino le informazioni fornite dal provider ex art. 13 per adempiere all’obbligo di DPIA ex art. 35 GDPR. L’art. 27 stabilisce che la FRIA si affianca alla DPIA quando entrambe sono dovute, integrandola.

L’intersezione più interessante è di metodo. La FRIA spinge la valutazione oltre la dimensione sicurezza-data breach, verso un’analisi sostanziale dei diritti fondamentali impattati: discriminazione, pregiudizi algoritmici, effetti della profilazione, accesso ai servizi. È plausibile che, nel tempo, questa impostazione retroagisca sulle DPIA, spostandone il baricentro verso una valutazione più ampia dei rischi sui diritti, in linea con quanto già richiede formalmente l’art. 35 GDPR.

Per le aziende, la conseguenza operativa è una sola: dove DPIA e FRIA sono entrambe dovute, vanno costruite come documenti integrati. Tenere due valutazioni separate, scritte da team diversi, con metodologie incompatibili, è la ricetta perfetta per inefficienze, contraddizioni e contestazioni. Le valutazioni d’impatto combinate AI Act + GDPR saranno una delle aree di lavoro più rilevanti per i prossimi anni.

5. L’art. 4 bis: quando l’AI Act consente di trattare dati sensibili

È la modifica che cambia di più il rapporto fra le due normative, e vale la pena ricostruirla dall’inizio perché è facile fraintenderla in entrambe le direzioni.

5.1 Il problema che risolve

Un sistema di IA può produrre risultati distorti, e la distorsione può tradursi in discriminazione. Per accorgersene e correggerla bisogna misurarla, e per misurarla serve sapere a quali gruppi appartengono le persone su cui il sistema decide: origine etnica, convinzioni religiose, orientamento sessuale, stato di salute. Cioè proprio le categorie particolari di dati personali che l’art. 9 GDPR vieta di trattare, salvo le eccezioni del paragrafo 2.

È il paradosso che chi lavora su fairness algoritmica conosce bene: per non discriminare bisognerebbe trattare i dati che non si possono trattare. L’AI Act nella versione del 2024 lo aveva risolto solo a metà, con l’art. 10, par. 5, che copriva i soli fornitori di sistemi ad alto rischio.

5.2 Cosa fa il nuovo articolo

Il Regolamento (UE) 2026/1744 ha soppresso l’art. 10, par. 5 e ha inserito al suo posto un art. 4 bis autonomo, collocato fra le disposizioni generali. La sostanza della vecchia norma resta al paragrafo 1; la novità è il paragrafo 2, che estende la stessa base giuridica a tre categorie di soggetti che prima ne erano fuori:

• i fornitori di altri sistemi e modelli di IA, quindi anche non ad alto rischio;
• i deployer di altri sistemi e modelli di IA;
• i deployer di sistemi ad alto rischio, che prima non erano coperti pur essendo quelli che il sistema lo usano davvero.

Per questi soggetti il trattamento è ammesso nella misura in cui è strettamente necessario a rilevare e correggere possibili 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 regolamento aggiunge una precisazione tecnica che merita attenzione: specie laddove gli output di dati influenzano gli input per operazioni future, cioè nei sistemi che si riaddestrano su quello che producono.

5.3 Le sei condizioni, che sono cumulative

Il punto più importante di tutti, e quello che rende la norma meno generosa di come sembra: le condizioni del paragrafo 1 si applicano tutte, e valgono anche per il paragrafo 2. Vanno soddisfatte oltre a quelle del GDPR, non al posto loro.

Le condizioni sono sei e vanno lette una per una.

• Nessuna alternativa praticabile. Il rilevamento e la correzione non possono essere realizzati efficacemente trattando altri dati, compresi i dati sintetici o anonimizzati.
• Limitazioni tecniche al riutilizzo. I dati sono soggetti a limiti tecnici sul riutilizzo e a misure più avanzate di sicurezza e di tutela della vita privata, compresa la pseudonimizzazione.
• Accesso controllato e documentato. I dati sono resi sicuri e protetti, con controlli e documentazione rigorosi dell’accesso, affinché solo persone autorizzate e vincolate a obblighi di riservatezza possano arrivarci.
• Nessuna condivisione. I dati non sono trasmessi, trasferiti né altrimenti consultati da terzi.
• Cancellazione legata all’evento. Si cancellano quando la distorsione è stata corretta, oppure alla fine del periodo di conservazione, a seconda di quale delle due condizioni si verifica per prima.
• Motivazione nel registro. Il registro delle attività di trattamento deve contenere i motivi per cui il trattamento era strettamente necessario e i motivi per cui l’obiettivo non poteva essere raggiunto trattando altri dati.

La prima condizione è quella che si sottovaluta più spesso: la disponibilità di dati sintetici o anonimizzati chiude la porta. Chi vuole usare la base giuridica deve poter dimostrare di averli valutati e scartati, e l’ultima condizione impone di scriverlo nel registro.

Il divieto di condivisione è quello che pesa di più sull’organizzazione del lavoro, perché esclude di girare quei dati a un fornitore esterno di analisi di fairness. E la cancellazione chiede una regola di cancellazione legata a un evento, la correzione della distorsione, non solo a un termine.

5.4 Cosa non fa

Tre cose, e tutte e tre contano.

Non crea un obbligo. Il paragrafo 2 lo dice testualmente: «Il presente paragrafo non crea alcun obbligo di rilevare e correggere tali distorsioni.» È una facoltà per chi decide di farlo, non un adempimento nuovo. Restano naturalmente gli obblighi che vengono da altrove, a partire dall’art. 10 per i sistemi ad alto rischio.

Non sostituisce il GDPR. Il trattamento deve rispettare le condizioni dell’art. 4 bis in aggiunta a quelle del GDPR, del Reg. (UE) 2018/1725 e della direttiva (UE) 2016/680. Informativa, minimizzazione, sicurezza, diritti degli interessati restano tutti dovuti.

Non legittima la raccolta iniziale. L’articolo autorizza il trattamento per una finalità precisa; non dice che quei dati si possono raccogliere, e chi non li ha già legittimamente non trova qui la base per procurarseli.

5.5 Da quando

Qui c’è un dato utile a chi sta pianificando. La base giuridica sta nel capo I dell’AI Act, non nel capo III, e non è toccata dai rinvii che hanno spostato l’alto rischio al dicembre 2027. È quindi già utilizzabile.

La scelta è dichiarata: il regolamento spiega che serve a consentire ai fornitori di sistemi ad alto rischio di svolgere legittimamente le attività di rilevamento e correzione in preparazione della conformità ai requisiti che arriveranno. Chi deve farsi trovare pronto nel 2027 può iniziare adesso a lavorare sui dati che servono, purchè rispetti le sei condizioni.

Il fondamento nel GDPR è l’art. 9, par. 2, lett. g), il motivo di interesse pubblico rilevante: il regolamento afferma che il rilevamento e la correzione delle distorsioni costituiscono un interesse pubblico rilevante, in quanto proteggono le persone fisiche dagli effetti negativi delle distorsioni, compresa la discriminazione.

6. Casi pratici: come si configura la doppia compliance

Tre situazioni reali per chi lavora con AI nel digitale.

Un SaaS che sviluppa un assistente AI per il customer service e lo addestra usando trascrizioni di conversazioni reali con i clienti. Sotto l’AI Act, lo strumento non è ad alto rischio, ma è soggetto agli obblighi di trasparenza ex art. 50 e all’alfabetizzazione in materia di IA ex art. 4, riscritto nel 2026 in senso più morbido: la norma chiede di adottare misure volte a sostenere lo sviluppo delle competenze, e precisa che non impone di garantire un livello specifico di alfabetizzazione per alcuna persona. Sempre sull’art. 50, una scadenza che riguarda proprio questo caso: i fornitori di sistemi generativi immessi sul mercato prima del 2 agosto 2026 devono conformarsi all’obbligo di marcatura del paragrafo 2 entro il 2 dicembre 2026. Sotto il GDPR, il SaaS è titolare del trattamento delle trascrizioni: deve identificare base giuridica, finalità, misure di pseudonimizzazione, informativa agli interessati (i clienti che hanno chiamato il customer service). La doppia compliance non si esaurisce in un solo documento.

Una banca che adotta un sistema di credit scoring sviluppato da un vendor. Sotto l’AI Act, è deployer di un sistema ad alto rischio (Allegato III, n. 5, lett. b): deve condurre la FRIA ex art. 27, garantire sorveglianza umana, monitorare il funzionamento. Sotto il GDPR, è titolare del trattamento dei dati dei clienti valutati: deve fare la DPIA ex art. 35 (il credit scoring è prassi consolidata come trattamento ad alto rischio), garantire i diritti degli interessati ex art. 22 sul processo decisionale automatizzato. DPIA e FRIA convergono e vanno costruite insieme, sfruttando le informazioni che il vendor deve fornire ex art. 13 AI Act.

Una web agency che addestra un modello AI proprietario di brand voice usando contenuti pubblici dei social media di un cliente. Sotto l’AI Act, il modello potrebbe ricadere nelle definizioni di GPAI a seconda della generalità e della scala. Sotto il GDPR, va verificata la natura dei dati (commenti di terzi, immagini di volti, dati “manifestamente pubblici”?), la base giuridica del trattamento (di norma il legittimo interesse), le ragionevoli aspettative degli interessati. Il fatto che i dati siano accessibili pubblicamente non equivale a lecito utilizzo per qualsiasi finalità: la CGUE (Meta Platforms, 4 luglio 2023, causa C-252/21) ha chiarito che la pubblicità del dato dipende da scelte consapevoli dell’interessato, non dalla mera accessibilità tecnica. Il tema è approfondito nella nostra guida dedicata a minimizzazione e base giuridica nei sistemi AI.

Conclusioni

Per due anni la risposta alla domanda «come si coordinano AI Act e GDPR» è stata una sola: non si sovrappongono, si sommano. L’AI Act disciplinava sistemi e prodotti, il GDPR disciplinava trattamenti, e ognuno restava a casa propria.

Quella risposta oggi va corretta su un punto. Con la riscrittura dell’art. 2, par. 7 e con l’introduzione dell’art. 4 bis, l’AI Act è entrato per la prima volta nel merito di che cosa si può trattare e a quali condizioni. Non è una rivoluzione, ed è anzi una norma prudente, con sei condizioni cumulative e nessun obbligo nuovo. Ma segna un cambio di ruolo: la mappa delle basi giuridiche di un progetto AI non si disegna più guardando solo il GDPR.

La nostra valutazione, e qui si tratta di opinione dichiarata come tale: l’art. 4 bis sarà usato molto meno di quanto meriti, e per una ragione pratica. Le sue condizioni si soddisfano solo se qualcuno le ha progettate prima – la cancellazione legata alla correzione della distorsione, il divieto di condivisione con terzi, la motivazione a registro – e chi si accorge della norma quando il modello è già in produzione scopre che non è più in condizione di usarla.

Il consiglio che diamo è allora sempre lo stesso, ed è il contrario di come si affronta di solito la conformità: le due verifiche vanno fatte insieme e all’inizio. Il progetto che nasce con una sola mappa – quella privacy o quella AI Act – è il progetto che poi va rifatto.

Punti chiave

Fonti