La Commissione Ue ha pubblicato due giorni fa la versione finale del Code of Practice on Transparency of AI-Generated Content, relativo alla trasparenza dell’AI generativa in relazione a marcatura ed etichettatura dei contenuti generati o manipolati dall’intelligenza artificiale.
Il Codice, di volontaria applicazione, è previsto dall’art. 50, par. 7, del Regolamento (UE) 2024/1689 (AI Act) ed è stato redatto da sei esperti indipendenti nominati dall’AI Office, con il contributo di oltre 180 stakeholder: provider e deployer di sistemi generativi, associazioni di categoria, PMI, mondo accademico, settore pubblico e società civile.
Il Codice arriva accompagnato da un vero e proprio pacchetto documentale: il modulo di adesione (Signatory Form), tre studi tecnici sullo stato dell’arte delle soluzioni di marcatura e rilevazione (uno per l’audio, uno per immagini e video, uno per il testo) e il set ufficiale delle icone europee di etichettatura, scaricabili liberamente in formato vettoriale.
La Commissione ha inoltre annunciato linee guida che chiariranno l’ambito degli obblighi e gli aspetti che non sono coperti dal Codice stesso.
Vediamo allora cosa prevede il testo finale – e perché devono leggerlo tutti, anche chi non intende firmarlo.
Indice degli argomenti
Code of Practice per trasparenza AI: obblighi vincolanti e adesione volontaria
L’art. 50 AI Act stabilisce l’obbligo di trasparenza per i contenuti generati dalla AI e costruisce tale obbligo su due pilastri.
Il primo (art. 50, par. 2) riguarda i provider: i sistemi di AI che generano audio, immagini, video o testo sintetici devono marcare gli output in formato leggibile dalla macchina e renderli rilevabili come generati o manipolati artificialmente, con soluzioni tecniche “effective, interoperable, robust and reliable” (così nella norma).
Il secondo (art. 50, par. 4) riguarda i deployer: chi genera o manipola un deep fake deve dichiararne l’origine artificiale; chi pubblica testi generati o manipolati dall’AI per informare il pubblico su questioni di interesse pubblico deve etichettarli, salvo che vi sia una revisione umana e una responsabilità editoriale.
Su entrambi i pilastri si innesta l’art. 50, par. 5: l’informazione va fornita in modo chiaro e distinguibile, al più tardi al momento della prima interazione o esposizione.
Il Codice appena approvato si pone l’obiettivo di fornire indicazioni pratiche per rendere operativi gli obblighi legislativi sopra riportati. La base giuridica per l’emanazione del Codice è l’art. 50, par. 7, AI Act, che incarica l’Ufficio per l’IA di incoraggiare e facilitare codici di buone pratiche per l’attuazione effettiva degli obblighi di rilevazione ed etichettatura, e consente altresì alla Commissione di approvarli mediante atti di esecuzione. Lo stesso paragrafo prevede poi una strada alternativa: se il codice non viene ritenuto adeguato, la Commissione può adottare un atto di esecuzione che specifichi norme comuni di attuazione.
Importante precisare che il Codice – obbligatorio solo per chi decide di sottoscriverlo – classifica le proprie prescrizioni con una tassonomia lessicale che merita attenzione (e che il Codice stesso esplicita nella sezione Commitments di entrambe le Sezioni): “will” indica le misure obbligatorie per chi firma, quelle che le autorità di vigilanza del mercato monitoreranno; “encouraged” e “may” indicano misure volontarie o comunque con margini di flessibilità attuativa. Chi aderisce, dunque, sottoscrive un perimetro di adempimenti verificabili, alcuni obbligatori altri indicativi.
Seppure poi il Codice chiarisca che l’adesione non costituisce presunzione assoluta di conformità all’art. 50 (Sezione 2, Objectives, lett. a), è del tutto innegabile che lo stesso è destinato a diventare il benchmark di fatto per il mercato, per i fornitori di tecnologia e soprattutto per le autorità di vigilanza, che dovranno valutare la conformità in modo coerente e uniforme in tutta l’Unione.
Ne discende che senza dubbio non è obbligatorio sottoscrivere il Codice, ma è altrettanto certo che la sottoscrizione è molto conveniente sotto il profilo della prova.
Se poi si decide di non aderire, l’alternativa è strutturarsi per poter dare prova circa il rispetto dell’art. 50.
Provider e marcatura nel Code of Practice sulla trasparenza AI
La Sezione 1 del Codice attua l’art. 50, par. 2 e 5, AI Act e si rivolge ai provider.
Conviene partire da un chiarimento di vocabolario, perché qui il Codice usa termini tecnici che è bene maneggiare con precisione.
Marcare un contenuto significa inserirvi un segno che ne attesti l’origine artificiale. Il Codice (Measure 1.1) lavora con due tecniche di marcatura, che il provider deve applicare insieme.
La prima sono i metadati firmati digitalmente (Sub-measure 1.1.1). I metadati sono le informazioni che “viaggiano” insieme al file ma non si vedono guardando il contenuto: per una foto, ad esempio, sono i dati che indicano data, dispositivo, software di scatto. Il Codice chiede che, quando il formato lo consente, in questi metadati venga registrato che il contenuto è generato o manipolato dall’AI, e che l’informazione sia firmata in modo crittografico e datata, così da renderla verificabile e da rendere evidente ogni manomissione (come un sigillo che, se rotto, si nota). Il limite, dichiarato dagli stessi studi tecnici, è che i metadati si rimuovono con facilità: basta un salvataggio in un formato diverso o uno screenshot e spariscono.
La seconda tecnica è il watermarking impercettibile (Sub-measure 1.1.2). Qui il segno non sta “accanto” al contenuto ma viene incorporato dentro il contenuto stesso – nei pixel di un’immagine, nel segnale di un audio, nella sequenza di parole di un testo – in modo invisibile o non udibile per la persona, ma riconoscibile da un software. A differenza dei metadati, il watermark sopravvive a molte trasformazioni: per questo il Codice lo chiede come secondo strato, complementare al primo.
Il cuore della Sezione 1 è proprio questo doppio livello. Come infatti confermano i tre studi tecnici commissionati dall’AI Office, pubblicati sulla stessa pagina del Codice – allo stato dell’arte nessuna singola tecnica garantisce da sola i quattro requisiti di efficacia, interoperabilità, robustezza e affidabilità (soprattutto per i contenuti destinati a circolare online): ne consegue che il provider deve marcare i propri output con almeno due strati leggibili dalla macchina: metadati firmati + watermarking (Measure 1.1).
Due le eccezioni a questo doppio livello.
- La prima riguarda i sistemi generativi integrati in prodotti fisici che operano in ambiente tecnicamente chiuso e controllato, con misure che impediscono l’esportazione dell’output: in questo caso basta un livello (Measure 1.1). Si pensi a un sistema che genera contenuti destinati a restare all’interno di un dispositivo, senza possibilità di essere esportati e diffusi all’esterno.
- La seconda riguarda il testo libero (free-form text), cioè il testo “nudo” senza un formato che lo contenga – ad esempio quello che appare in una chat o su una pagina web. Non potendo trasportare metadati, è marcabile solo tramite watermarking (Measure 1.1). E qui il Codice introduce una soglia destinata a far discutere: il testo molto breve – che il glossario identifica, allo stato dell’arte, in quello inferiore a 200 token (all’incirca 150 parole) – non è watermarkabile con un livello di affidabilità neppure basilare, e resta quindi fuori; oltre i 200 token il watermarking va applicato, pur con un’affidabilità ridotta rispetto ai testi lunghi (Sub-measure 1.1.2). Lo studio tecnico dedicato al testo fotografa del resto un trade-off ancora irrisolto: le tecniche più robuste alle modifiche sono vulnerabili agli attacchi di falsificazione (un terzo che appone il marchio “AI” a un testo che AI non è), mentre quelle più affidabili – come i metadati firmati – sono facilmente rimovibili.
Accanto alle due tecniche obbligatorie, il Codice ne prevede una terza, opzionale e supplementare: il fingerprinting o il logging (Sub-measure 1.1.3). Più esattamente: il fingerprinting genera una sorta di “impronta digitale” del contenuto – un codice sintetico che lo identifica anche se viene leggermente modificato, in modo simile a come Shazam riconosce una canzone da pochi secondi di registrazione; il logging, invece, è la registrazione del contenuto prodotto in un archivio interrogabile, così da poter poi verificare se un certo testo proviene dal sistema.
Sono misure che possono aiutare la rilevazione, seppure il Codice chiarisca che non bastano mai da sole a soddisfare i requisiti di qualità (Sub-measure 1.1.3), e che vanno comunque usate con garanzie precise – controllo del deployer sulle policy di logging, conservazione limitata nel tempo, cancellazione sicura.
Completa il quadro la Measure 1.2 sulla non rimozione: i firmatari dovranno fare il possibile per conservare le marcature presenti nei contenuti usati come input; inseriranno nelle condizioni d’uso il divieto di rimozione o manomissione delle marcature da parte di deployer e terzi (Measure 1.2, lett. b); e – disposizione netta – non immetteranno sul mercato né promuoveranno strumenti finalizzati a eludere le marcature (Measure 1.2).
Da segnalare, infine, la logica di filiera: anche i provider di modelli generativi immessi sul mercato separatamente dai sistemi e i fornitori terzi di soluzioni di marcatura e detection possono aderire volontariamente alla Sezione 1, per facilitare la compliance dei provider a valle (Sezione 1, Commitments). In sostanza si riconosce esplicitamente che la trasparenza non si costruisce nel singolo sistema, ma lungo la catena del valore.
Rilevazione gratuita e accesso a geometria variabile
Restiamo sugli obblighi del provider.
Marcare un contenuto non serve a nulla se poi nessuno può “leggere” la marcatura: per questo, accanto all’obbligo di marcare (Commitment 1), il Codice pone l’obbligo speculare di mettere a disposizione lo strumento che rileva la marcatura (Commitment 2). Le due cose vanno insieme: chi marca deve anche fornire il rilevatore.
Più precisamente, il Commitment 2 impone ai soggetti che decidono di sottoscrivere il Codice di rendere disponibile una soluzione di detection – cioè di rilevazione – per ciascuna tecnica di marcatura implementata (Measure 2.1). La soluzione può assumere una o più forme (Sub-measure 2.1.1): una specifica pubblica che chiunque può implementare; un software eseguibile in locale sul proprio computer; oppure un servizio in cloud accessibile via API (l’interfaccia che permette a due programmi di “parlarsi”, cioè di inviare il contenuto al rilevatore e ricevere l’esito).
La soluzione messa a disposizione deve essere gratuita, con una eccezione: i provider con meno di 1.000.000 di utenti mensili e la cui soluzione comporti costi operativi sostanziali, possono applicare una tariffa ragionevole e proporzionata oltre soglie di volume elevate (Sub-measure 2.1.1).
Deve sempre e comunque restare gratuito, senza limiti di volume, l’accesso per autorità di vigilanza e regolatori, forze dell’ordine, media, fact-checker, trusted flagger, ricercatori indipendenti, istituzioni educative e di ricerca, organizzazioni della società civile (Sub-measure 2.1.1).
In relazione alla detection il punto più delicato riguarda – ancora una volta – il testo.
Poiché la detection del watermarking su testo libero ha affidabilità ridotta e può produrre risultati fuorvianti o a bassa confidenza, i firmatari possono riservarne l’accesso a utenti esperti verificati con un legittimo bisogno: autorità, media, fact-checker, ricercatori (Sub-measure 2.1.2).
In altre parole: chiunque potrà caricare un’immagine o un audio sospetti e sapere se sono stati generati dall’AI; per un testo, invece, il rilevatore potrebbe non essere accessibile al singolo cittadino, ma solo a un giornalista o a un ricercatore che ne facciano richiesta motivata. La scelta poggia su una considerazione pragmatica: un detector inaffidabile in mano al pubblico generale produce più disinformazione di quanta ne prevenga. È innegabile però che la trasparenza funzioni dunque a due velocità: il cittadino potrà direttamente verificare immagini, audio e video, mentre per il testo dovrà affidarsi all’ecosistema professionale della verifica.
Sul fronte privacy, la Sub-measure 2.1.3 fissa uno standard rigoroso per le soluzioni che richiedono il caricamento del contenuto: trattamento del dato come sensibile sotto il profilo della riservatezza, finalità limitata alla sola rilevazione, minimizzazione e politica di zero retention – il contenuto si cancella subito dopo la verifica, senza conservazione di copie verbatim (Sub-measure 2.1.3, lett. a-e).
I risultati della detection devono poi essere chiari e comprensibili, indicare la tecnica utilizzata (metadati, watermark, analisi forense), essere scaricabili su richiesta in formato firmato digitalmente (Sub-measure 2.1.2 e Measure 2.3), e rispettare i requisiti di accessibilità della Direttiva (UE) 2019/882 e della Direttiva (UE) 2016/2102 (Measure 2.3).
Qualità tecnica e interoperabilità entro il 2 febbraio 2027
Sempre in capo al provider, il Commitment 3 traduce in misure operative i quattro requisiti che l’art. 50, par. 2, AI Act pretende dalle soluzioni tecniche: efficacia, interoperabilità, robustezza e affidabilità.
Più precisamente il Codice stabilisce che:
– l’efficacia si valuta dal punto di vista dell’utente (user-based): la soluzione è efficace se le persone riescono ad accedere all’esito della verifica e a capirlo. Non conta che il marchio ci sia: conta che chi lo incontra comprenda cosa significa (Measure 3.1).
– l’affidabilità è la capacità di distinguere correttamente il contenuto AI da quello che AI non è, riducendo gli errori. Si misura con metriche di errore – ad esempio quante volte il rilevatore segnala come “AI” un contenuto che non lo è (falso positivo) – testate su campioni di varia lunghezza, dimensione e semantica (Measure 3.2).
– la robustezza è la resistenza del marchio alle alterazioni. Va dimostrata sia rispetto alle operazioni di trattamento ordinarie – compressione di un file, screenshot, stampa e nuova scansione (print-and-scan), sostituzione di qualche parola, parafrasi, traduzione e ritraduzione – sia rispetto agli attacchi deliberati volti a copiare, rimuovere, rigenerare o modificare la marcatura (Measure 3.3). In altri termini: il marchio deve “tenere” anche se qualcuno, per errore o di proposito, manipola il contenuto.
– l’interoperabilità è la capacità dei diversi sistemi di “leggersi” a vicenda: l’esito della verifica non deve dipendere da quale azienda ha prodotto il contenuto. È l’unico requisito con una scadenza interna precisa: entro il 2 febbraio 2027 i firmatari dovranno implementare una soluzione di interoperabilità per i propri meccanismi di detection, scegliendo tra un metodo di accesso standardizzato via API, un signpost (un “cartello” leggibile pubblicamente che indica quale rilevatore usare, evitando di provarli tutti), una soluzione condivisa consortile aperta anche alle PMI, o una soluzione equivalente (Measure 3.4, lett. c).
Chiude la Sezione 1 il Commitment 4 su testing e compliance, anch’esso a carico del provider: verifica delle soluzioni prima dell’immissione sul mercato e periodicamente, in condizioni rappresentative dell’uso reale (Measure 4.2); documentazione del processo di conformità, con semplificazioni proporzionate per PMI e small mid-cap (Measure 4.1); formazione del personale (Measure 4.3); cooperazione con le autorità di vigilanza del mercato ai sensi dell’art. 74 AI Act e dell’art. 7 del Regolamento (UE) 2019/1020 (Measure 4.4).
Deployer, deep fake e icona nel Code of Practice sulla trasparenza AI
Passiamo ora agli obblighi di trasparenza del deployer (art. 50, par. 4 e 5), disciplinati dalla Sezione 2 del Codice.
La Sezione 2 si rivolge più precisamente ai deployer per due fattispecie (Sezione 2, Commitments): i deep fake (come definiti dall’art. 3, punto 60, AI Act) ed il testo generato o manipolato dall’AI pubblicato per informare il pubblico su questioni di interesse pubblico, quando manca un processo di revisione umana o controllo editoriale e nessuna persona fisica o giuridica assume la responsabilità editoriale della pubblicazione.
La novità più visibile è l’icona europea (Commitment 1, Sezione 2, e Annex 1), allegata al Codice e pubblicata dall’AI Office come set ufficiale liberamente utilizzabile, senza obbligo di attribuzione, in formato vettoriale e raster.
Le varianti principali sono tre: “AI GENERATED” per i contenuti interamente generati,
“AI MODIFIED” per i contenuti parzialmente modificati,
e una versione base con il solo acronimo “AI”, predisposta per essere integrata con un secondo livello informativo interattivo o con etichette testuali alternative.
Ciascuna etichetta è fornita in versione nera e bianca, su fondo pieno e semitrasparente, per adattarsi a qualunque sfondo. Il design è stato sottoposto a user-testing empirico in più Stati membri: le varianti con etichetta testuale esplicita sono risultate significativamente più chiare per gli utenti, perché riducono l’ambiguità sulla natura del contenuto (Annex 1).
L’icona europea non è obbligatoria: i deployer possono adottare etichette equivalenti, purché conformi alle specifiche di design e posizionamento del Codice (Commitment 1, Sezione 2).
Verrebbe da dire che, dopo trent’anni di marcatura CE, l’Europa inaugura la marcatura AI – con una differenza sostanziale: qui non si attesta la conformità del prodotto, ma l’origine artificiale del contenuto.
Per quanto attiene poi alle specifiche di design (Measure 1.1, Sezione 2) le stesse richiedono l’acronimo “AI” capitalizzato come elemento visivo principale (in inglese, salvo incompatibilità con le leggi nazionali sull’uso delle lingue), con proporzioni preservate e stili adattabili purché l’etichetta resti chiara, accessibile e distinguibile.
Le specifiche di posizionamento (Measure 1.2, Sezione 2) ruotano attorno al principio della percepibilità immediata, senza richiedere azioni dell’utente, al più tardi alla prima esposizione. Qualche esempio concreto tratto dal Codice: per i video, l’etichetta va mostrata all’inizio e, ove possibile, a intervalli regolari, e comunque dopo le interruzioni – pensando a screenshot e clip estratte (Sub-measure 1.2.2, lett. b); per l’audio puro, un disclaimer udibile all’inizio (ad esempio una breve frase parlata che avverte che la voce è sintetica), con richiami a intervalli per i contenuti lunghi; se è disponibile uno schermo – in auto, su uno smartphone – si aggiunge la disclosure visiva (Sub-measure 1.2.2, lett. e; Sub-measure 1.2.3); per il testo pubblicato, l’icona va collocata in apertura, vicino al titolo o nel colophon; per i testi brevissimi è ammessa una notice contestuale nell’interfaccia, ad esempio un indicatore accanto all’output (Sub-measure 1.2.2, lett. f).
Il tutto però con requisiti di accessibilità (Measure 1.1, Sezione 2): segnali tattili o aptici – come una vibrazione che precede un audio deep fake –, alto contrasto, compatibilità con gli screen reader.
Il sistema presenta peraltro una importante coerenza interna con la Sezione 1: la Measure 1.4 (Sezione 1) incoraggia infatti i provider a integrare nell’interfaccia dei propri sistemi una funzionalità che consenta al deployer di applicare l’etichetta direttamente al momento della generazione dell’output.
La misura è opzionale, ma se i provider la implementeranno, per i deployer l’adempimento diventerà – letteralmente – un click.
Responsabilità editoriale, opere creative e contesti professionali chiusi
Restando sul versante del deployer, l’obbligo di etichettatura presenta delle eccezioni, previste dall’art. 50 par. 4 AI Act e declinate nel Codice.
La prima, e più rilevante per chi pubblica contenuti, è quella editoriale.
Il testo sottoposto a revisione umana o controllo editoriale, con una persona fisica o giuridica che ne assume la responsabilità, non va etichettato (art. 50, par. 4, secondo comma, AI Act).
Il Commitment 4 della Sezione 2 distingue due situazioni:
- i media service provider ai sensi dell’art. 2, punto 2), del Regolamento (UE) 2024/1083 (European Media Freedom Act), già soggetti a standard editoriali e a quadri di autoregolamentazione, possono fare affidamento sulle procedure esistenti.
- tutti gli altri deployer devono dotarsi di policy interne che identifichino la persona con responsabilità editoriale – nome, ruolo e contatti, da rendere pubblici ove non già disponibili – e descrivano le misure organizzative e le risorse umane dedicate alla revisione, senza obbligo di documentare ogni singola pubblicazione (Commitment 4, Sezione 2).
E qui un punto che merita attenzione.
La fattispecie del “testo pubblicato per informare il pubblico” non riguarda solo l’editoria: riguarda qualunque organizzazione che pubblichi contenuti informativi generati con l’AI: la pubblica amministrazione che genera comunicati e schede informative, la struttura sanitaria che produce materiali destinati ai pazienti, l’impresa che pubblica approfondimenti su temi di interesse pubblico. Per tutti questi soggetti la via maestra non è l’etichetta: è strutturare un controllo editoriale effettivo, con responsabilità chiaramente allocata. Il che, a bene vedere, è esattamente ciò che una governance seria dell’AI in azienda dovrebbe già prevedere.
La seconda eccezione riguarda le opere evidentemente artistiche, creative, satiriche o di finzione: per i deep fake che ne fanno parte, la disclosure va resa in modo da non ostacolare la fruizione dell’opera (Commitment 3, Sezione 2) – nei crediti, nelle note di accompagnamento, oppure, per i contesti non digitali come mostre, festival e sale cinematografiche, nelle informazioni al punto di accesso o di vendita.
La terza riguarda i deep fake usati esclusivamente in contesti professionali chiusi – l’esempio del Codice è la formazione interna del personale: la disclosure può essere collocata nell’interfaccia utente o nel contesto fisico, purché le persone esposte ne siano informate prima dell’esposizione (Sub-measure 1.2.2, lett. c).
Road map del Code of Practice trasparenza AI verso il 2 agosto 2026
Il tempo utile è poco e gli adempimenti non sono banali.
Per i provider di sistemi generativi il percorso minimo è questo:
- censire i sistemi in scope (audio, immagini, video, testo) e confrontare le tecniche di marcatura già implementate con lo standard a due livelli del Codice – metadati firmati più watermarking (Measure 1.1) – verificando le eccezioni applicabili;
- predisporre o procurarsi, anche da fornitori terzi o dal model provider a monte, la soluzione di detection e i relativi canali di accesso, con le garanzie privacy richieste, zero retention inclusa (Commitment 2, Sub-measure 2.1.3);
- aggiornare condizioni d’uso, acceptable use policy e documentazione di accompagnamento con il divieto di rimozione delle marcature (Measure 1.2);
- documentare processo di compliance e testing (Commitment 4), e pianificare fin d’ora la soluzione di interoperabilità da implementare entro il 2 febbraio 2027 (Measure 3.4).
Per i deployer il punto di partenza è una mappatura di quali usi aziendali generano deep fake o testi informativi destinati al pubblico. Da lì, due strade:
- l’etichettatura, con l’icona UE o un’etichetta equivalente conforme alle specifiche di design e posizionamento (Commitment 1, Sezione 2), oppure, per i testi,
- un controllo editoriale strutturato con responsabile identificato e policy documentata (Commitment 4, Sezione 2). In entrambi i casi servono formazione del personale coinvolto e procedure per correggere etichette mancanti o errate (Measure 2.2 e 2.3, Sezione 2).
Occorre infine decidere se aderire o meno al Codice.
Per chi opera nel mercato europeo dei sistemi generativi la convenienza è evidente: il Codice offre un percorso di conformità predefinito e una presunzione di affidabilità davanti alle autorità di vigilanza; ovviamente chi decide di non sottoscrivere il Codice dovrà comunque rispettare l’art. 50 e dimostrare con mezzi propri un livello di conformità equivalente.
Trasparenza dei contenuti AI e governance di filiera
Un’ultima considerazione, che va oltre l’adempimento.
L’art. 50 è la disposizione dell’AI Act con la platea più ampia: non tocca solo i provider di frontiera o i sistemi ad alto rischio, ma chiunque produca o pubblichi contenuti sintetici – imprese, amministrazioni, strutture sanitarie, professionisti.
La trasparenza dei contenuti non è un’etichetta da apporre: è l’infrastruttura di fiducia dell’ecosistema informativo, quella su cui poggiano mercati, istituzioni e dibattito pubblico. Ed è, contemporaneamente, un problema di governance di filiera: modelli, sistemi, deployer e piattaforme devono parlarsi, tecnicamente e contrattualmente.
