L’AI Act pone la trasparenza tra i principi fondamentali della disciplina europea sull’intelligenza artificiale, quale strumento essenziale per garantire consapevolezza, tutela dei diritti e fiducia nell’uso dei sistemi di IA.
I recenti interventi della Commissione Europea hanno rafforzato il quadro applicativo degli obblighi di trasparenza lasciando, tuttavia, aperto il tema del coordinamento con gli obblighi informativi previsti dal GDPR. Questo contributo analizza le principali criticità operative derivanti da tale sovrapposizione e individua le priorità che le organizzazioni dovranno affrontare in attesa di indicazioni interpretative congiunte della Commissione europea e dell’EDPB.
Indice degli argomenti
AI Act e GDPR: la sfida del coordinamento operativo
Il Regolamento (UE) 2024/1689, noto come AI Act, e il Regolamento (UE) 2016/679, noto come GDPR, tutelano la persona con due regimi distinti, costruiti su logiche diverse e affidati a soggetti diversi.
La persona che interagisce con un sistema di intelligenza artificiale è, allo stesso tempo, utente ai sensi dell’AI Act e interessato ai sensi del GDPR. Dispone quindi di un insieme più ampio di diritti rispetto al passato, ma di minori certezze su chi sia concretamente responsabile di garantirne un esercizio coordinato.
Sul versante delle organizzazioni, la medesima duplicazione di regimi si traduce in un crescente rischio di non conformità: AI Act e GDPR non si contraddicono, ma si cumulano senza prevedere un effettivo raccordo operativo. È proprio questa sovrapposizione non governata ad aumentare il rischio sanzionatorio. Le violazioni degli obblighi di trasparenza previsti dall’Art. 50 dell’AI Act, applicabile dal 2 agosto 2026, possono comportare sanzioni amministrative fino a 15 milioni di euro o al 3% del fatturato mondiale annuo, se superiore (Art. 99 par. 4 lett. g)); per le istituzioni e gli organismi dell’Unione, fino a 750.000 euro (Art. 100 par. 3). Per le PMI, comprese le start-up, e – per effetto del Digital Omnibus – per le piccole imprese a media capitalizzazione, si applica invece l’importo o la percentuale inferiore (Art. 99 par. 6 e par. 6 bis).
Il quadro applicativo si è del resto assestato proprio alla vigilia di questa scadenza. Il Regolamento (UE) 2026/1744, cosiddetto Digital Omnibus sull’IA, adottato l’8 luglio 2026, pubblicato in Gazzetta ufficiale il 24 luglio ed entrato in vigore il 27 luglio, ha differito l’applicazione del Capo III, sezioni 1, 2 e 3, dell’AI Act – vale a dire i requisiti e gli obblighi relativi ai sistemi ad alto rischio – al 2 dicembre 2027 per i sistemi classificati ad alto rischio ai sensi dell’Art. 6 par. 2 e dell’Allegato III, e al 2 agosto 2028 per quelli classificati ai sensi dell’Art. 6 par. 1 e dell’Allegato I. L’Art. 50 “Obblighi di trasparenza per i fornitori e i deployer di determinati sistemi di IA” resta invece del tutto impregiudicato e si applica indipendentemente dalla classe di rischio del sistema. Il differimento, quindi, non riguarda la trasparenza.
Il quadro rimane però incompleto proprio nel punto di contatto con la protezione dei dati: le linee guida congiunte della Commissione europea e dell’EDPB sull’interplay tra AI Act e GDPR non sono state ancora pubblicate. Proveremo quindi a mappare questo vuoto attuale, a spiegare perché è strutturalmente difficile da colmare e a individuare le priorità operative più urgenti per le organizzazioni che non possono permettersi di attendere.
In gioco, infatti, non vi è soltanto il coordinamento tra due discipline normative, ma il principio stesso della trasparenza come fondamento della fiducia nell’ecosistema digitale. Le “informative” previste dal GDPR e gli obblighi di “trasparenza” introdotti dall’AI Act rappresentano il principale strumento attraverso cui una persona può comprendere chi tratta i suoi dati, quando sta interagendo con un sistema di intelligenza artificiale, per quali finalità vengono assunte decisioni che la riguardano e quali diritti può esercitare. Solo una trasparenza effettiva e coordinata può rendere il consumatore, l’utente e l’interessato realmente consapevoli del proprio percorso nell’era digitale, trasformando la compliance da mero adempimento formale a concreta garanzia dell’autodeterminazione della persona.
Gli obblighi di trasparenza dell’Art. 50 AI Act e il loro disallineamento con il GDPR
Gli obblighi di trasparenza sono trattati nel Capo IV dell’AI Act. L’Art. 50 articola gli obblighi su quattro paragrafi, distribuiti tra due soggetti responsabili: il fornitore (provider), che risponde della progettazione e della marcatura del sistema, e il deployer, l’utilizzatore professionale che impiega il sistema nella propria organizzazione e che risponde dell’informativa alle persone esposte.
Il primo obbligo riguarda i sistemi che interagiscono direttamente con persone fisiche: il fornitore deve progettare il sistema in modo che l’utente sappia di avere davanti un’IA (Art. 50 par. 1). Il secondo riguarda i sistemi generativi: il fornitore deve marcare gli output in formato leggibile da macchina, con soluzioni efficaci, interoperabili, robuste e affidabili (Art. 50 par. 2). Il terzo riguarda i sistemi di riconoscimento emotivo e di categorizzazione biometrica, per i quali è il deployer a dover informare le persone esposte (Art. 50 par. 3). Il quarto grava anch’esso sul deployer e comprende due fattispecie distinte: la dichiarazione dell’origine artificiale dei deepfake e la dichiarazione relativa al testo generato o manipolato mediante IA e pubblicato allo scopo di informare il pubblico su questioni di interesse pubblico, quest’ultima esclusa quando il contenuto è stato sottoposto a revisione umana o controllo editoriale e una persona fisica o giuridica ne assume la responsabilità editoriale (Art. 50 par. 4). Il par. 5 impone infine che tutte queste informazioni siano fornite in modo chiaro e distinguibile, al più tardi al momento della prima interazione o esposizione, nel rispetto dei requisiti di accessibilità applicabili.
La ragione di questi obblighi è concreta, non burocratica. Chi interagisce con un sistema di IA ben progettato non lo percepisce necessariamente come tale. Il sistema può rispondere con naturalezza, adattarsi al contesto, simulare empatia e competenza. Se la persona non sa di avere davanti una macchina, non può calibrare correttamente il peso da attribuire a ciò che riceve – e questo si traduce in scelte, giudizi e affidamenti fondati su un’informazione incompleta. Il Considerando 132 del Regolamento ricollega l’obbligo ai rischi di impersonificazione o inganno. Sapere se ciò con cui si interagisce proviene da un essere umano o da una macchina è una condizione elementare perché la persona possa valutare, scegliere e partecipare in modo consapevole. Il mancato presidio di questo obbligo non è un’omissione formale: è un vuoto che incide sulla capacità della persona di esercitare i propri diritti fondamentali.
Il problema emerge quando si affianca il GDPR. Le Guideline della Commissione sull’Art. 50, adottate nella versione definitiva il 20 luglio 2026 (C(2026) 5054 final), affermano con precisione che l’obbligo di cui all’Art. 50 par. 1 AI Act “persegue un obiettivo diverso” rispetto agli obblighi informativi verso gli interessati previsti dal diritto dell’Unione sulla protezione dei dati e che, come tale, non li pregiudica (punto 52). Con riguardo all’Art. 50 par. 3, le Guideline aggiungono che i deployer devono adempiere all’obbligo informativo dell’AI Act in aggiunta a qualsiasi requisito informativo applicabile ai sensi del diritto dell’Unione sulla protezione dei dati (punto 110). Un’eventuale integrazione dei due canali informativi – ad esempio inserire la notifica AI Act nell’informativa privacy – è una facoltà (“can consider”), non un obbligo. I due regimi si sommano, non si fondono.
Il risultato pratico: la stessa persona fisica è simultaneamente utente AI ai sensi dell’Art. 50 e interessato ai sensi del GDPR, ma riceve diritti di informazione con finalità diverse, da soggetti responsabili diversi, attraverso canali non coordinati. Il quadro normativo, allo stato attuale, non fornisce indicazioni su come raccordarli.
Se i due regimi si sommano senza fondersi, qualcuno deve costruire il raccordo nella pratica: il deployer come entità obbligata, il DPO come funzione che per prima ne rileva le implicazioni. Le lacune operative che si ravvisano sono almeno tre.
La marcatura tecnica degli output AI genera un trattamento di dati personali privo di base giuridica identificata
L’Art. 50 par. 2 impone ai fornitori di marcare gli output dei sistemi generativi. Le Guideline precisano che le soluzioni di marcatura e rilevazione devono essere conformi al diritto dell’Unione sulla protezione dei dati, inclusi i principi e gli obblighi di protezione dei dati fin dalla progettazione e per impostazione predefinita, di minimizzazione, di sicurezza e riservatezza; aggiungono che le informazioni relative al creatore del contenuto non dovrebbero essere trattate e che gli altri dati personali eventualmente trattati devono essere cancellati non appena esaurita la finalità di rilevazione (punto 94). Su questo terreno interviene il Code of Practice sulla Trasparenza dei Contenuti Generati (di seguito CoP Transparency), strumento ad adesione volontaria previsto dall’Art. 50 par. 7 AI Act e da non confondere con il Code of Practice per i Modelli GPAI, di cui si dirà oltre a proposito della filiera di fornitura. Il Codice si spinge oltre le Guideline: per le soluzioni di rilevazione che richiedono il caricamento di contenuto, i firmatari devono garantire trattamento riservato, zero retention immediata dopo la rilevazione e divieto di riutilizzo per altre finalità (Sub-misura 2.1.3). Il rilievo del Codice è peraltro significativo: l’8 luglio 2026 la Commissione europea ha concluso che esso copre adeguatamente gli obblighi di cui all’Art. 50 par. 2, 4 e 5 e ne agevola l’attuazione effettiva, e il giorno successivo l’AI Board ha adottato la propria valutazione di adeguatezza. Il Codice è divenuto così l’unico strumento pratico riconosciuto a livello dell’Unione attraverso cui fornitori e deployer possono dimostrare la conformità agli obblighi di marcatura ed etichettatura, fermo restando che l’adesione non costituisce prova definitiva della conformità e che chi non aderisce può avvalersi di mezzi alternativi, dei quali dovrà però dimostrare l’adeguatezza alle autorità di vigilanza del mercato.
La marcatura assolve, sul piano sistemico, una funzione ulteriore: è una condizione di verificabilità pubblica del contenuto artificiale, che incide sulla qualità del dibattito democratico abilitando autorità, piattaforme e società civile a distinguere tra documento autentico, simulazione e produzione sintetica (cfr.: Linee guida AI Act, la Commissione affronta il nodo dell’opacità artificiale – Agenda Digitale). Ma è proprio qui che emerge il paradosso. Lo stesso strumento che persegue un obiettivo di equità e interesse pubblico genera un trattamento di dati personali per il quale il quadro normativo non individua con chiarezza la base giuridica né chiarisce se esso costituisca un trattamento autonomo, tale da richiedere, ad esempio, una specifica valutazione d’impatto sulla protezione dei dati (DPIA). Il DPO è quindi chiamato a colmare questo vuoto interpretativo. Tuttavia, per farlo ha bisogno non solo di competenze giuridiche, ma anche di informazioni tecniche dettagliate sul funzionamento del sistema, sulle logiche di trattamento, sui flussi dei dati e sulle misure adottate. Informazioni che, nella maggior parte dei casi, risiedono presso il fornitore della soluzione o nelle funzioni IT dell’organizzazione, piuttosto che nella funzione privacy.
Su questo specifico obbligo il Digital Omnibus ha introdotto l’unica attenuazione temporale. Il nuovo Art. 111 par. 4 dell’AI Act dispone che i fornitori di sistemi di IA, compresi i sistemi per finalità generali, che generano contenuti audio, immagine, video o testuali sintetici e sono stati immessi sul mercato prima del 2 agosto 2026, adottino le misure necessarie per conformarsi all’Art. 50 par. 2 entro il 2 dicembre 2026: un periodo transitorio di quattro mesi, come precisa il Considerando 38. Le Guideline ne danno conto al punto 153, chiarendo che i sistemi in parte interattivi e in parte generativi ne beneficiano soltanto per l’obbligo di marcatura, mentre l’obbligo di informazione per i sistemi che interagiscono direttamente con persone fisiche deve essere assicurato già dal 2 agosto 2026. Si tratta dunque di una finestra di adeguamento tecnico circoscritta, non di una sospensione dell’obbligo: la questione della base giuridica del trattamento che la marcatura e la rilevazione generano resta impregiudicata e va affrontata sin da ora.
La catena di responsabilità ex AI Act non si traduce automaticamente nei ruoli previsti dal GDPR
Il Considerando 101 e l’Art. 53 par. 1 lett. b) dell’AI Act stabiliscono che i fornitori di modelli GPAI devono mettere a disposizione dei fornitori a valle – i soggetti che integrano il modello nei propri sistemi di IA – le informazioni necessarie ad adempiere gli obblighi previsti dal Regolamento. Il Code of Practice per i Modelli GPAI (di seguito CoP GPAI), strumento distinto dal CoP Transparency e riferito agli obblighi che gravano sui fornitori di modelli per finalità generali, traduce questo principio in termini operativi: le informazioni sulla Model Documentation devono essere rese disponibili entro un termine massimo di quattordici giorni dalla richiesta, salvo circostanze eccezionali (Misura 1.2).
Questa architettura distribuisce la responsabilità lungo la filiera in base al ruolo effettivo di ciascun soggetto nella catena del valore: il fornitore risponde della progettazione e dello sviluppo del sistema, il deployer risponde della decisione di impiego e delle modalità concrete di utilizzo. Ma la filiera AI – fornitore del modello, fornitore del sistema, deployer – non trova un corrispondente esplicito nella catena di responsabilità del GDPR, dove titolare, contitolare e responsabile del trattamento rispondono a criteri diversi.
Il punto critico emerge quando l’utilizzo del sistema comporta trattamento di dati personali. In quel caso l’organizzazione deve dimostrare la conformità a entrambi i regimi con informazioni che provengono da un soggetto la cui qualifica GDPR non discende automaticamente dall’accordo di fornitura del modello: quell’accordo disciplina chi sviluppa il modello e chi lo integra ai fini AI Act, mentre il contratto ex Art. 28 GDPR disciplina chi determina le finalità e i mezzi del trattamento e chi tratta dati per conto altrui. Un fornitore di modelli GPAI può occupare la prima posizione senza occupare la seconda – perché mette a disposizione uno strumento che il deployer utilizza in autonomia, senza trattare dati personali per suo conto. Nessuno dei due regimi fornisce la chiave per leggere l’altro: spetta all’organizzazione ricostruire, caso per caso, chi fa cosa e a quale titolo.
La valutazione d’impatto sui diritti fondamentali e la DPIA restano processi non integrati
L’Art. 27 par. 4 dell’AI Act, nel testo modificato dal Digital Omnibus, prevede che, qualora taluni degli obblighi previsti da tale articolo siano già rispettati mediante la valutazione d’impatto sulla protezione dei dati effettuata ai sensi dell’Art. 35 GDPR o dell’Art. 27 della Direttiva (UE) 2016/680, il deployer possa includere nella valutazione d’impatto sui diritti fondamentali (FRIA) – richiesta per determinate categorie di deployer di sistemi ad alto rischio, in particolare soggetti pubblici ed enti privati che forniscono servizi pubblici – rimandi alle sezioni pertinenti della DPIA, oppure parti pertinenti di essa. Il raccordo assume dunque la forma di un’incorporazione per rinvio, non di un metodo valutativo comune: evita duplicazioni documentali, ma lascia intatte le due logiche di analisi, i due perimetri e i due soggetti responsabili. Un primo ausilio operativo è previsto – l’Art. 27 par. 5, anch’esso modificato, incarica l’ufficio per l’IA di elaborare un modello di questionario che dia ai deployer la possibilità di operare tali rinvii – ma si tratta di uno strumento di compilazione della FRIA, non di una metodologia di raccordo tra i due regimi. Il Considerando 69 dell’AI Act riafferma che i principi GDPR – minimizzazione, privacy by design, limitazione della conservazione – si applicano sull’intero ciclo di vita del sistema di IA, ma questa affermazione di principio non si traduce in uno schema operativo condiviso tra le due valutazioni.
Il disallineamento appare duplice. Sul piano sostanziale: la FRIA valuta l’impatto sui diritti fondamentali in senso ampio – quali la libertà, la non discriminazione, l’accesso ai servizi essenziali – secondo il perimetro della Carta dei diritti fondamentali dell’Unione europea, mentre la DPIA si concentra sui rischi specifici per i diritti e le libertà delle persone fisiche derivanti dal trattamento di dati personali. I perimetri si sovrappongono parzialmente, ma non coincidono. Sul piano organizzativo: condurre la FRIA è responsabilità del deployer come entità, con il coinvolgimento delle funzioni aziendali che presidiano i rischi operativi e giuridici; la DPIA è territorio del DPO. Due processi, diversi responsabili, due logiche valutative – senza che nessun documento indichi come farli convergere in un unico strumento coerente. Le due valutazioni restano quindi processi paralleli, il cui raccordo è rimesso alla scelta metodologica di ciascuna organizzazione.
Il Digital Omnibus incide qui in modo indiretto ma significativo. Poiché l’obbligo di FRIA è ancorato ai sistemi ad alto rischio, il differimento della relativa disciplina al 2 dicembre 2027 sposta in avanti anche il momento in cui il raccordo con la DPIA diventerà esigibile. Il risultato è un’asimmetria temporale che merita attenzione: gli obblighi di trasparenza sono già applicabili e generano da subito trattamenti da qualificare, mentre lo strumento valutativo che avrebbe potuto ospitarne l’analisi sistematica arriverà solo tra oltre un anno. La finestra così creata non riduce il problema di coordinamento: lo anticipa sul piano operativo e lo rinvia su quello formale.
Il confronto con altri regimi: dove il raccordo tra discipline è già stato costruito
Il disallineamento tra AI Act e GDPR non è una novità assoluta nell’ordinamento europeo: altri regimi hanno già affrontato il problema della responsabilità distribuita lungo filiere complesse e lo hanno risolto. MiFID II – con l’Art. 24 della Direttiva 2014/65/UE completato dal Regolamento Delegato (UE) 2017/565 – e NIS2 – con l’Art. 21 par. 2 lett. d) della Direttiva 2022/2555 e le linee guida operative ENISA sulle buone pratiche per la cibersicurezza della catena di approvvigionamento – ne sono esempi diretti: in entrambi i casi il legislatore ha prodotto, a valle della norma primaria, strumenti operativi che traducono l’obbligo astratto in regole concrete e verificabili.
Il pattern è riconoscibile anche nell’ordinamento italiano. Il D.Lgs. 33/2013, come modificato dal D.Lgs. 97/2016, ha nominato il Responsabile della Prevenzione della Corruzione e della Trasparenza (RPCT) come presidio interno e ha istituito l’accesso civico come strumento azionabile dall’esterno (Art. 1 e Art. 5). L’Art. 116 del Testo Unico Bancario (D.Lgs. 385/1993) ha completato l’obbligo informativo verso il cliente attraverso le Disposizioni di Vigilanza della Banca d’Italia. L’Art. 21 del Testo Unico della Finanza (D.Lgs. 58/1998) ha costruito la trasparenza come dovere di condotta – prescrivendo agli intermediari di comportarsi con diligenza, correttezza e trasparenza e di operare affinché i clienti siano adeguatamente informati – poi declinato dalla CONSOB nel Regolamento Intermediari. Schema invariato: funzione interna nominata, strumento operativo di secondo livello pubblicato, conformità verificabile dall’esterno.
Il modello di raccordo, del resto, è già stato sperimentato dalle stesse istituzioni competenti in materia di protezione dei dati: il 9 ottobre 2025 l’EDPB e la Commissione europea hanno adottato congiuntamente linee guida volte a chiarire i punti di contatto tra Digital Markets Act e GDPR. Lo strumento esiste e la prassi istituzionale anche.
Nel caso dell’Art. 50 AI Act il ciclo regolatorio si è ormai chiuso: le Linee guida della Commissione, adottate il 20 luglio 2026, e il Code of Practice sulla Trasparenza, pubblicato il 10 giugno 2026 e valutato adeguato dalla Commissione l’8 luglio e dall’AI Board il 9 luglio 2026 – pur senza che l’adesione costituisca prova definitiva della conformità e senza conferire, come precisa il Considerando 41 del Digital Omnibus, alcuna presunzione di conformità – forniscono lo strumento di secondo livello che traduce l’obbligo in regole applicative. È significativo, però, che sia proprio il CoP Transparency a rendere visibile il limite del sistema: nel disciplinare la rilevazione, esso subordina espressamente il trattamento residuo di dati personali all’esistenza di una base giuridica valida, senza tuttavia indicare quale essa sia. Lo strumento che chiude il ciclo dell’AI Act è dunque il medesimo che segnala dove il ciclo resta aperto. Quello che manca non è più la guidance sull’AI Act, ma lo strumento che raccorda l’AI Act al GDPR. Sono le stesse Linee guida a certificarlo: nel rinviare a una spiegazione più dettagliata sull’interplay tra AI Act e diritto della protezione dei dati, indicano le linee guida congiunte della Commissione e dell’EDPB come ancora «in preparazione». Il rapporto annuale 2025 dell’EDPB, pubblicato ad aprile 2026, le colloca «nel corso del 2026» senza data definita.
Nel frattempo, gli obblighi di trasparenza dell’Art. 50 sono già applicabili e pienamente sanzionabili nei termini richiamati in apertura (punto 152 delle Guideline; Art. 99 par. 4 lett. g) e Art. 100 par. 3 AI Act). Le istruzioni per adempiere all’AI Act ci sono. Quelle per adempiervi in modo coerente con il GDPR, non ancora.
Una difficoltà strutturale: due regimi fondati su principi senza strumenti di raccordo comuni
C’è una ragione strutturale per cui questo raccordo è più difficile da costruire rispetto ai precedenti. Il GDPR non prescrive ricette operative, ma introduce principi e obblighi di accountability che richiedono giudizio, valutazione del rischio e assunzione consapevole di responsabilità. L’AI Act segue la stessa impostazione: non prescrive le modalità con cui assicurare la trasparenza, ma si limita a stabilire che essa debba essere garantita in modo efficace, proporzionato e verificabile.
Quando due regimi basati su principi devono raccordarsi senza uno strumento operativo comune, il risultato non è solo un vuoto normativo: è una lacuna che, nelle more della produzione degli strumenti interpretativi attesi, l’organizzazione è chiamata a colmare in autonomia.
Che non si tratti di un ostacolo insormontabile lo dimostra il Digital Omnibus stesso. Nel rivedere l’AI Act il legislatore è intervenuto proprio sull’interfaccia con la disciplina di protezione dei dati, introducendo un nuovo Art. 4 bis che autorizza, in via eccezionale, il trattamento di categorie particolari di dati personali ai fini del rilevamento e della correzione delle distorsioni, subordinandolo a un elenco tassativo di condizioni e garanzie: con uno standard di stretta necessità per i fornitori di sistemi ad alto rischio, e di necessità e proporzionalità per i fornitori e deployer degli altri sistemi e modelli di IA nonché per i deployer di sistemi ad alto rischio. L’intervento è tanto più significativo se si considera che il legislatore ha contestualmente modificato l’Art. 2 par. 7, il quale ora fa espressamente salvi gli Artt. 4 bis e 59 dalla clausola secondo cui il Regolamento lascia impregiudicato il GDPR. Il punto di contatto tra i due regimi, dunque, non è stato soltanto sfiorato: è stato disciplinato in modo esplicito e coordinato. Non lo si è fatto, però, sugli obblighi informativi dell’Art. 50: il disallineamento che qui si documenta non discende da una difficoltà tecnica insuperabile, ma da una priorità di intervento che non è ancora stata assunta.
Implicazioni operative e priorità per le funzioni di controllo nell’attesa delle linee guida
Il vuoto non è solo normativo: è anche di governance interna. L’Art. 50 AI Act attribuisce gli obblighi di trasparenza al deployer come entità, senza indicare quale funzione organizzativa li debba presidiare. Il raccordo tra l’obbligo informativo AI Act e quello GDPR – che le Guideline trattano come cumulativi ma distinti con riguardo specifico all’Art. 50 par. 3 (punto 110), principio estensibile per analogia agli altri paragrafi dell’Art. 50 – chiama in causa almeno tre funzioni: il DPO, che presidia gli obblighi verso l’interessato ai sensi del GDPR e deve identificare la base giuridica del trattamento ancillare generato dalla marcatura; il legal o la compliance AI, che presidia gli obblighi informativi verso la persona fisica utente ai sensi dell’Art. 50 e identifica i ruoli contrattuali nella filiera GPAI; il procurement o il vendor management, che governa il flusso di informazioni dal fornitore upstream necessario per alimentare entrambi gli adempimenti.
La normativa non indica come questi tre piani debbano coordinarsi. Il deployer che opera oggi si trova in una posizione strutturalmente diversa da quella del soggetto obbligato MiFID o NIS2: si trova a costruire il raccordo tra regimi in autonomia, in assenza di uno schema normativo che coordini le funzioni coinvolte.
In attesa delle linee guida congiunte, tre aree operative si prestano quindi ad essere affrontate con anticipo. La prima è l’identificazione della base giuridica del trattamento ancillare generato dalle soluzioni di rilevazione, da compiere prima che vengano adottate. La seconda è la mappatura dei ruoli contrattuali AI Act sui ruoli GDPR nella catena di fornitura, costruendo uno schema interno che la normativa non offre. La terza è il raccordo tra FRIA e DPIA in un unico processo valutativo che copra simmetricamente entrambi i regimi.
Il quadro che emerge non è quello di due discipline in conflitto, ma di due regimi che convergono sulla stessa persona fisica, sugli stessi sistemi e spesso sulle stesse organizzazioni, restando però separati negli strumenti, nei soggetti responsabili e nelle logiche valutative. Non si tratta di una svista, bensì di una scelta che entrambi i testi condividono: disciplinare per principi e accountability anziché per prescrizioni operative. Finché manca uno strumento di raccordo di secondo livello, il lavoro di sintesi ricade sull’organizzazione.
Gli obblighi di trasparenza dell’Art. 50 AI Act sono applicabili dal 2 agosto 2026, mentre gli strumenti interpretativi destinati a chiarirne il rapporto con il GDPR non erano ancora disponibili alla data del presente contributo. Questo disallineamento non è una circostanza transitoria: è la condizione concreta in cui le organizzazioni si trovano a operare oggi.
In questo contesto, costruire un raccordo interno tra AI Act e GDPR sulla trasparenza non è soltanto una risposta a un rischio sanzionatorio: è una scelta di governance. L’organizzazione che affronta oggi le tre priorità sopra indicate non sta eseguendo adempimenti, sta definendo il proprio standard interno in anticipo rispetto al quadro regolatorio che verrà. Si tratta peraltro di priorità esemplificative e non esaustive, che discendono direttamente dalle lacune strutturali documentate in questo contributo.
Altre ne emergeranno con l’evolversi della prassi applicativa, delle prime decisioni delle autorità di vigilanza e degli stessi interventi di revisione del quadro normativo: il Digital Omnibus, sul quale EDPB ed EDPS si erano pronunciati con la Joint Opinion 1/2026, è oggi diritto vigente e ha già ridisegnato il calendario di applicazione dell’AI Act senza toccare gli obblighi di trasparenza. La trasparenza dell’IA è dunque già un obbligo giuridico assistito da sanzioni e, allo stesso tempo, una garanzia per cittadini e stakeholder: attrezzarsi in autonomia, con rigore e consapevolezza dei limiti del quadro disponibile, è la sfida che le organizzazioni non possono permettersi di rinviare.
Esempi pratici per funzione e argomentazione
| Argomentazione | Scenario pratico | Lacuna operativa concreta | Norma di riferimento |
|---|---|---|---|
| 1. Due obblighi informativi paralleli | Un’azienda integra un assistente conversazionale AI nel servizio clienti. Al primo accesso l’utente deve essere informato che interagisce con un’IA. L’azienda ha anche un’informativa GDPR con raccolta del consenso al trattamento. | L’obbligo di notifica AI Act e l’informativa GDPR perseguono finalità diverse e sono rivolti a soggetti responsabili diversi. Inserire la notifica AI Act nell’informativa privacy è una facoltà, non un obbligo. Il deployer decide autonomamente se e come integrarli. | Art. 50 par. 1 AI Act; Art. 50 par. 6 AI Act (gli obblighi di trasparenza lasciano impregiudicati gli altri obblighi di trasparenza del diritto UE); Artt. 13 e 14 GDPR; Guideline C(2026) 5054, punti 52 e 110 |
| 2. Rilevazione e trattamento ancillare | Il responsabile comunicazione carica un comunicato stampa su un servizio di rilevazione online per verificare se è stato generato da un sistema AI. | Il contenuto può includere dati personali. Il CoP Transparency prescrive zero retention e minimizzazione e subordina il trattamento residuo a una base giuridica valida, senza però indicare quale sia. Il DPO deve identificarla prima che il servizio venga adottato. | Art. 50 par. 2 AI Act; Art. 6 GDPR; CoP Transparency, Sub-misura 2.1.3; Guideline C(2026) 5054, punto 94 |
| 3. Filiera GPAI e ruoli GDPR | Un’azienda usa un sistema di customer care basato su un modello GPAI di un fornitore terzo. Richiede la Model Documentation entro 14 giorni (Misura 1.2 CoP GPAI). | Il fornitore ai sensi dell’AI Act non è necessariamente il responsabile del trattamento ai sensi del GDPR. L’azienda deve dimostrare la conformità a entrambi i regimi con informazioni provenienti da un soggetto la cui qualifica GDPR non è automaticamente determinata. | Art. 53 par. 1 lett. b) AI Act; Considerando 101 AI Act; Art. 28 GDPR; CoP GPAI, Misura 1.2 |
| 4. FRIA e DPIA non integrate | Un ente pubblico locale adotta un sistema AI per la gestione delle pratiche di assistenza sociale (sistema ad alto rischio). Deve condurre la FRIA prima dell’utilizzo. Il sistema tratta dati sensibili. | La FRIA è obbligatoria. La DPIA è richiesta dal GDPR quando il trattamento presenta un rischio elevato per i diritti e le libertà delle persone fisiche, condizione che si verifica presuntivamente per sistemi AI ad alto rischio che trattano categorie particolari di dati. L’Art. 27 par. 4, come modificato dal Digital Omnibus, consente al deployer di includere nella FRIA rimandi alle sezioni pertinenti della DPIA o parti di essa: incorporazione per rinvio, non metodo valutativo comune. L’ente costruisce autonomamente lo strumento valutativo. | Art. 27 par. 1 AI Act; Art. 27 par. 4 e 5 AI Act, come modificati dal Reg. (UE) 2026/1744; Allegato III, punto 5 lett. a) AI Act; Art. 35 par. 1 GDPR; Art. 27 Direttiva (UE) 2016/680; Considerando 69 AI Act |
| 5. Governance interna | Una banca italiana usa sistemi AI generativi per comunicazioni alla clientela. Deve adempiere agli obblighi di trasparenza AI Act sulla marcatura degli output, agli obblighi informativi verso gli interessati previsti dal diritto sulla protezione dei dati e alle disposizioni di trasparenza bancaria della Banca d’Italia. | Tre regimi, tre funzioni coinvolte (DPO, compliance AI, comunicazione), nessuno schema di coordinamento normativo. | Art. 50 par. 2 AI Act; Guideline C(2026) 5054, punto 94; Artt. 13 e 14 GDPR; Art. 116 TUB; Banca d’Italia, Disposizioni di vigilanza in materia di trasparenza |
Riferimenti bibliografici e normativi
Normativa europea primaria
Regolamento (UE) 2024/1689 del Parlamento europeo e del Consiglio, del 13 giugno 2024, che stabilisce regole armonizzate sull’intelligenza artificiale (AI Act), GU L del 12.7.2024. Disposizioni richiamate: Art. 6 par. 1 e 2; Art. 27 par. 1, 4 e 5; Art. 50 par. 1, 2, 3, 4, 5, 6 e 7; Art. 53 par. 1 lett. b); Art. 99 par. 4 lett. g) e par. 6; Art. 100 par. 3; Art. 111 par. 4; Art. 113, terzo comma, lett. c); Allegato I; Allegato III, punto 5 lett. a); Considerando 69, 101, 132.
Regolamento (UE) 2026/1744 del Parlamento europeo e del Consiglio, dell’8 luglio 2026, che modifica i regolamenti (UE) 2024/1689, (UE) 2018/1139 e (UE) 2023/1230 per quanto riguarda la semplificazione dell’attuazione di regole armonizzate sull’intelligenza artificiale (Omnibus digitale sull’IA), GU L, 2026/1744, 24.7.2026, in vigore dal 27 luglio 2026. Disposizioni richiamate: Art. 2 par. 7; Art. 4 bis; Art. 27 par. 4 e 5; Art. 50 par. 7; Art. 99 par. 6 bis; Art. 111 par. 4; Art. 113, terzo comma, lett. c); Considerando 38 e 41.
Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali e alla libera circolazione di tali dati (GDPR), GU L 119 del 4.5.2016. Disposizioni richiamate: Art. 6; Artt. 13 e 14; Art. 28; Art. 35 par. 1.
Direttiva (UE) 2016/680 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativa alla protezione delle persone fisiche con riguardo al trattamento dei dati personali da parte delle autorità competenti a fini di prevenzione, indagine, accertamento e perseguimento di reati o esecuzione di sanzioni penali, GU L 119 del 4.5.2016. Disposizione richiamata: Art. 27.
Direttiva 2014/65/UE del Parlamento europeo e del Consiglio, del 15 maggio 2014, relativa ai mercati degli strumenti finanziari (MiFID II), GU L 173 del 12.6.2014. Disposizione richiamata: Art. 24.
Regolamento Delegato (UE) 2017/565 della Commissione, del 25 aprile 2016, che integra la Direttiva 2014/65/UE, GU L 87 del 31.3.2017.
Direttiva (UE) 2022/2555 del Parlamento europeo e del Consiglio, del 14 dicembre 2022, relativa a misure per un livello comune elevato di cibersicurezza nell’Unione (NIS2), GU L 333 del 27.12.2022. Disposizione richiamata: Art. 21 par. 2 lett. d).
Normativa italiana
D.Lgs. 14 marzo 2013, n. 33 – Riordino della disciplina riguardante gli obblighi di pubblicità, trasparenza e diffusione di informazioni da parte delle pubbliche amministrazioni, GU n. 80 del 5.4.2013. Disposizioni richiamate: Art. 1, Art. 5.
D.Lgs. 1° settembre 1993, n. 385 – Testo Unico delle leggi in materia bancaria e creditizia (TUB). Disposizione richiamata: Art. 116.
D.Lgs. 24 febbraio 1998, n. 58 – Testo Unico delle disposizioni in materia di intermediazione finanziaria (TUF). Disposizione richiamata: Art. 21.
Atti regolatori e di indirizzo
Commissione europea, Guidelines on the implementation of the transparency obligations for certain AI systems under Article 50 of Regulation (EU) 2024/1689 (the ‘AI Act’), Bruxelles, 20.7.2026, C(2026) 5054 final, Allegato alla Comunicazione. Punti richiamati: 52; 94; 110; 146; 152; 153; nota 37.
Code of Practice on Transparency of AI-Generated Content, pubblicato il 10 giugno 2026. Copre gli obblighi di cui all’Art. 50 par. 2, 4 e 5 AI Act. Valutato adeguato dalla Commissione europea con Opinion dell’8 luglio 2026 (pubblicata il 9 luglio) e dall’AI Board con Adequacy Assessment del 9 luglio 2026. Disposizione richiamata: Sub-misura 2.1.3.
Code of Practice for General-Purpose AI Models – Transparency Chapter. Disposizione richiamata: Misura 1.2.
Banca d’Italia, Disposizioni di vigilanza in materia di trasparenza delle operazioni e dei servizi bancari e finanziari, Provvedimento del 29 luglio 2009 e successive modifiche.
ENISA, Good Practices for Supply Chain Cybersecurity, linee guida operative a supporto dell’Art. 21 NIS2.
Documenti istituzionali di aggiornamento
EDPB, Relazione annuale 2025, pubblicata il 9 aprile 2026.
EDPB – Comunicato stampa, DMA and GDPR: EDPB and European Commission endorse joint guidelines to clarify common touchpoints, 9 ottobre 2025.
EDPB – EDPS, Joint Opinion 1/2026 on the Proposal for a Regulation as part of the Digital Omnibus on AI, 20 gennaio 2026.
Riferimenti dottrinali e giornalistici
Linee guida AI Act, la Commissione affronta il nodo dell’opacità artificiale, Agenda Digitale, disponibile su: https://www.agendadigitale.eu/sicurezza/linee-guida-ai-act-la-commissione-affronta-il-nodo-dellopacita-artificiale/
















Partecipa alla community