L’articolo 50 dell’AI Act non chiede soltanto di marcare i contenuti generati dall’intelligenza artificiale. Chiede che qualcuno se ne assuma la responsabilità davanti alle persone. E quel qualcuno, quasi sempre, non è chi sviluppa il modello: è chi lo usa per costruire il proprio prodotto. La marcatura è tecnica; la trasparenza, invece, è una precisa scelta di governance e verso gli individui.
Indice degli argomenti
Fornitori e deployer: le definizioni
Per capire di chi sia l’onere della trasparenza sull’utilizzo dell’intelligenza artificiale conviene partire dai nomi che la norma assegna ai protagonisti. Il Regolamento (UE) 2024/1689 distingue anzitutto due figure.
Il fornitore — il provider — è chi sviluppa un sistema di AI, o un modello per finalità generali, e lo immette sul mercato o lo mette in servizio a proprio nome o marchio, a titolo oneroso o gratuito (art. 3). Il deployer è invece chi utilizza un sistema di AI sotto la propria autorità, nell’esercizio di un’attività professionale. Sono due ruoli, non due specie: la stessa organizzazione può essere l’uno o l’altro a seconda della relazione in cui si trova, e — come vedremo — può passare dall’uno all’altro senza quasi accorgersene.
Gli obblighi di trasparenza dell’AI Act tra fornitore e deployer
Su questa distinzione poggia l’architettura della trasparenza. Le regole si concentrano nell’articolo 50, che diventa applicabile, a seconda dei casi, dal 2 agosto o dal 2 dicembre 2026 e che non impone un generico obbligo di avvertenza per ogni sistema, ma individua fattispecie precise e le assegna in funzione del ruolo.
Il comma 1 riguarda il fornitore: chi immette sul mercato sistemi destinati a interagire direttamente con le persone deve progettarli in modo che l’utente sappia di trovarsi davanti a un’AI, salvo che sia evidente dal contesto.
Il comma 2 riguarda ancora il fornitore, compreso quello di modelli per finalità generali: gli output sintetici — testo, audio, immagini, video — devono essere marcati in un formato leggibile meccanicamente e rilevabili come generati o manipolati artificialmente, con soluzioni efficaci, interoperabili, solide e affidabili. I commi 3 e 4, invece, guardano al deployer: informare le persone esposte a sistemi di riconoscimento delle emozioni o di categorizzazione biometrica; etichettare i deepfake e i testi generati o manipolati destinati a informare il pubblico su temi di interesse generale.
Il comma 5 detta la regola di ingaggio comune: l’informazione va resa in modo chiaro e distinguibile, al più tardi al momento della prima interazione o esposizione, nel rispetto dei requisiti di accessibilità.
Marcatura tecnica e informazione alle persone
Se si legge la norma per commi, la ripartizione appare netta e, a suo modo, elegante. Al fornitore spetta un obbligo tecnico: marcare l’output alla fonte, perché la sua provenienza resti tracciabile ovunque quel contenuto vada. Al deployer spetta un obbligo comunicativo: dire alle persone, nel momento e nel contesto in cui le incontra, che stanno interagendo con una macchina o guardando un contenuto artificiale.
Sono due trasparenze diverse. La prima è rivolta soprattutto alle macchine e ai sistemi di rilevamento; la seconda è rivolta agli esseri umani. E qui si annida l’equivoco che questo articolo vuole disinnescare: credere che la prima basti ad assolvere la seconda.
La responsabilità della trasparenza lungo la catena del valore dell’AI
Prima però occorre chiarire un passaggio che complica la geometria dei ruoli, ma che è decisivo per chi costruisce prodotti sopra tecnologie altrui. L’articolo 25 disciplina la responsabilità lungo la catena del valore dell’AI e stabilisce che un distributore, un importatore, un deployer o un altro terzo diventa fornitore in tre casi: quando appone il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato (salvo diversa ripartizione contrattuale); quando ne apporta una modifica sostanziale[1] mantenendolo ad alto rischio; quando ne muta la finalità prevista fino a farlo diventare ad alto rischio.
Verificatasi una di queste condizioni, il fornitore originario cessa di essere tale per quel sistema, pur dovendo cooperare e trasmettere le informazioni necessarie al nuovo fornitore. È un meccanismo di successione: la responsabilità non si somma, si trasferisce, seguendo chi ha effettivamente in mano il sistema e la sua destinazione.
Quando il deployer diventa fornitore
L’articolo 25 governa esplicitamente i sistemi ad alto rischio, ma il principio che lo anima attraversa l’intero Regolamento e vale già a monte, nella definizione stessa di fornitore: chi mette un sistema in servizio a proprio nome ne assume gli obblighi, inclusi quelli di trasparenza. Ne discende una conseguenza pratica che molte imprese non hanno ancora messo a fuoco.
Chi integra il modello di un terzo dentro il proprio prodotto e lo offre ai propri clienti come soluzione propria non è soltanto un deployer verso il fornitore a monte: rischia di essere, verso i propri utenti, un fornitore a pieno titolo, con l’obbligo di marcare gli output che quel prodotto genera. La linea tra i due ruoli non è una frontiera stabile: è una soglia che si può varcare con un fine-tuning rilevante, un cambio di finalità o semplicemente un logo.
Watermark e marcatura: i limiti della trasparenza tecnica nell’AI
Lo dice, con notevole onestà, chi il modello lo fornisce. Anthropic ha aderito al codice di buone pratiche sulla trasparenza dei contenuti generati dall’AI, previsto dallo stesso articolo 50, in qualità di fornitore sia di modelli sia di sistemi di AI generativa. I suoi modelli più recenti marcano i contenuti “dal primo giorno”: un watermark impercettibile nel testo e metadati di provenienza firmati, secondo lo standard aperto C2PA, nei file.
Eppure, nella pagina in cui spiega tutto questo[2], il fornitore aggiunge un avvertimento che vale più di ogni etichetta: chi costruisce un prodotto sopra Claude deve valutare autonomamente ciò che l’articolo 50 richiede ai propri prodotti e servizi; il compito del fornitore, dichiara, è “supportare” il deployer nell’adempiere ai propri obblighi di trasparenza, non assolverli al suo posto. Tradotto: il fornitore consegna gli strumenti, non consegna la conformità. La responsabilità verso l’utente finale resta, per intero, di chi quell’utente lo ha davanti.
Che cosa dimostra davvero un watermark
C’è di più, e ad ammetterlo è lo stesso fornitore che stiamo prendendo ad esempio (Anthropic). Un marchio, quando è presente, dice molto meno di quanto si creda. Attesta che il contenuto è transitato per un certo sistema, non che quel sistema ne sia l’autore.
E la distinzione è tutt’altro che scolastica: l’AI si usa ogni giorno per correggere una bozza, tradurre un testo, riassumere un documento, convertire un file. In tutti questi casi la filigrana si deposita su un contenuto le cui idee, i cui dati e la cui paternità restano umani, e tuttavia viaggia con esso indistinguibile da quello generato ex novo dalla macchina.
C’è poi il tempo che passa dopo la marcatura: poiché il marchio permane attraverso copie e rimaneggiamenti, può sopravvivere anche quando il testo originario è stato ritagliato, rimontato o fuso con altro materiale, certificando un passaggio ma non l’integrità di ciò che resta. Il marchio, in definitiva, segnala una provenienza tecnica; non certifica la verità del contenuto, né la responsabilità di chi lo diffonde, né la sua genuinità.
E vale il rovescio speculare: la sua assenza non prova nulla, perché il watermark può degradarsi con l’editing, la parafrasi o la traduzione, i metadati possono essere rimossi con una conversione di formato o uno screenshot, e alcuni modelli o formati potrebbero non supportarlo affatto. Il presidio tecnico, insomma, è prezioso ma poroso — in entrambe le direzioni.
Chi si limitasse ad “avere il watermark” per poi diffondere un contenuto ingannevole avrebbe compilato un campo, non reso trasparente alcunché. È la stessa patologia che affligge la c.d. paper compliance: scambiare la compilazione per la valutazione, la traccia per il giudizio.
Spiegabilità e trasparenza tra AI Act e GDPR
Il diritto europeo, del resto, conosce già questa asimmetria e la risolve nello stesso modo. L’articolo 22 del GDPR riconosce alla persona il diritto di non essere sottoposta a decisioni interamente automatizzate che producano effetti giuridici o significativi, e gli articoli 13, 14 e 15 impongono di fornirle informazioni significative sulla logica utilizzata. Qui affiora la seconda metà del titolo: accanto a chi marca c’è chi spiega. E spiegare è tutt’altra impresa che segnalare.
Molti sistemi restano c.d. black box: opachi persino a chi li ha addestrati, con una logica non sempre riducibile a un racconto lineare. Il diritto ne prende atto senza chiedere l’impossibile: non pretende di aprire la scatola e riprodurne i circuiti, ma esige che la decisione sia comprensibile nei suoi effetti e, soprattutto, contestabile.
È la direzione dell’articolo 86 dell’AI Act, che per le decisioni assunte sulla base di sistemi ad alto rischio incidenti in modo pregiudizievole su salute, sicurezza o diritti fondamentali riconosce alla persona il diritto di ottenere — dal deployer — spiegazioni chiare e significative sul ruolo del sistema nella procedura decisionale e sui principali elementi della decisione adottata.
Ancora una volta l’onere segue chi sta davanti all’interessato: la spiegazione la deve il deployer, non chi ha costruito l’algoritmo. La trasparenza dell’AI Act e quella del GDPR convergono su un punto: l’obbligo di rendere comprensibile la macchina segue chi la usa verso le persone, non chi la fabbrica.
Revisione umana e responsabilità editoriale
Nemmeno per il deployer, peraltro, l’etichetta è un automatismo. Il comma 4 prevede un’eccezione significativa: l’obbligo di segnalare i testi generati o manipolati non si applica quando il contenuto è stato sottoposto a revisione umana o a controllo editoriale e una persona, fisica o giuridica, ne detiene la responsabilità editoriale.
È un’eccezione che responsabilizza invece di deresponsabilizzare: chi risponde editorialmente del contenuto sostituisce la propria accountability all’etichetta. Ma è anche un varco che, letto con troppa generosità, può svuotare l’obbligo. E si regge su una sola cosa: la prova che quella revisione umana sia davvero avvenuta. Di nuovo, non un modulo compilato, ma un’evidenza costruita bene e conservata.
Il deployer come baricentro degli obblighi di trasparenza
Qui si chiude il cerchio, e torna il motivo per cui il deployer è il vero baricentro della trasparenza. Se ci si accontentasse della sola marcatura tecnica, la trasparenza rischierebbe di diventare un dialogo tra sistemi: un watermark che parla a un detector, una provenienza firmata che una macchina verifica e un’altra macchina interroga, in un circuito perfettamente tracciabile e perfettamente muto per la persona.
Un ordinamento così avrebbe risolto la trasparenza sul piano ingegneristico e l’avrebbe persa su quello umano. Il deployer è l’anello che deve impedirlo: è colui che ritraduce la tracciabilità della macchina in comprensione dell’uomo, nel momento e nel contesto in cui quell’uomo la incontra. Il fornitore rende il contenuto riconoscibile; solo il deployer può renderlo compreso.
La trasparenza, allora, non è un’etichetta da apporre a valle. È una responsabilità da progettare a monte e da distribuire lungo la catena, dove ciascuno risponde di ciò che effettivamente governa. Chi marca e chi spiega non fanno lo stesso mestiere. E confondere i due significa illudersi che basti una filigrana invisibile per rendere le persone consapevoli. Non basta. Serve qualcuno che, davanti all’utente, si assuma il compito di informare veramente.
Come progettare la trasparenza dell’AI senza ridurla a caselle
Che cosa significa, in definitiva, muoversi bene da deployer? Non spuntare una lista — sarebbe il tradimento dell’intera tesi — ma tenere fermi pochi criteri. Sapere anzitutto che ruolo si ha: censire i punti in cui l’AI incontra le persone o genera contenuti e chiedersi se, apponendo il proprio marchio o mutando la finalità del sistema, non si sia già scivolati nel ruolo di fornitore.
Contrattualizzare la trasparenza a monte, pretendendo dal fornitore strumenti di marcatura e rilevamento e fissando per iscritto chi risponde di cosa — l’articolo 25 fa salvi proprio gli accordi sulla ripartizione degli obblighi. Progettare il come e il quando dell’informazione: non una riga sepolta nelle condizioni d’uso, ma un avviso chiaro e distinguibile al primo contatto, come vuole il comma 5.
Costruire e conservare le evidenze, quelle della revisione editoriale del comma 4, perché è la prova, non il modulo, a reggere l’esenzione. E, dove l’output incide su una persona, non fermarsi all’etichetta: predisporre spiegazione, supervisione umana, possibilità di contestare. In sintesi, criteri, non caselle.
Note
[1] Una modifica di un sistema di AI a seguito della sua immissione sul mercato o della sua messa in servizio che non è prevista o programmata nella valutazione iniziale della conformità effettuata dal Provider e che ha l’effetto di incidere sulla conformità del sistema di AI ai requisiti del sistema ad alto rischio (Capo III, sez. 2) o che comporta una modifica della finalità prevista per la quale il sistema è stato valutato. ↩
[2] Cfr. https://support.claude.com/en/articles/16266773-how-claude-marks-ai-generated-content ↩
Partecipa alla community