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à.

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

L’AI Act non sostituisce, non deroga e non assorbe il GDPR. Lo dice in modo esplicito 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.

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;
• 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. 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’AI literacy ex art. 4. 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.

Conclusione in sintesi