Gli obblighi di trasparenza dell'articolo 50 del regolamento UE sull'IA, il regolamento (UE) 2024/1689, si applicano dal 2 agosto 2026. Quasi tutto quello che è stato scritto sull'argomento è o un riassunto dell'intero regolamento o un'analisi giuridica rivolta a chi il regolamento lo conosce già. Questo testo non è nessuna delle due cose. È una lettura semplice di che cosa l'articolo 50 chiede a un team che pubblica.
Che cosa cambia, e quando
Il regolamento sull'IA è entrato in vigore nel 2024. I suoi obblighi non partono tutti insieme. Entrano in applicazione per fasi, secondo un calendario stabilito dal regolamento stesso, e il 2 agosto 2026 è la data in cui iniziano ad applicarsi gli obblighi di trasparenza dell'articolo 50.
Quella mattina non c'è nulla di nuovo nella regola. Il testo è pubblico dal 2024. Cambia il fatto che l'obbligo è ora operativo, quindi la domanda si sposta da che cosa dirà la regola a che cosa potete dimostrare sui vostri contenuti.
Chi vincola l'articolo 50
L'articolo divide gli obblighi fra due ruoli, e la divisione conta, perché la maggior parte dei team rientra chiaramente in uno dei due.
I fornitori sono coloro che immettono il sistema di IA sul mercato. Chi sviluppa o fornisce un modello generativo o un prodotto costruito su di esso ha l'obbligo di marcatura: l'output deve essere leggibile dalle macchine come generato o manipolato artificialmente.
I deployer sono coloro che usano un sistema del genere e pubblicano il risultato. Un team marketing che fa passare i testi di campagna attraverso un modello è un deployer. Lo sono anche un'agenzia che produce materiali per i clienti, un editore che genera illustrazioni e una redazione interna che scrive con assistenza. Se pubblicate l'output, l'obbligo di informativa è vostro.
In pratica quasi ogni funzione contenuti o marketing è deployer e non fornitore. Vale la pena chiarirlo internamente, perché i team spesso presumono che l'obbligo spetti al fornitore dello strumento che stanno usando.
Che cosa conta come contenuto generato dall'IA
Più di quanto ci si aspetti. L'articolo 50 riguarda contenuti audio, immagine, video e testo sintetici. Non si limita all'illustrazione palesemente generata.
Due categorie sono nominate espressamente. I deep fake, cioè contenuti immagine, audio o video generati o manipolati in modo da assomigliare a persone, luoghi o eventi reali, fanno scattare un obbligo di informativa in capo al deployer. Lo stesso vale per i testi generati o manipolati dall'IA pubblicati per informare il pubblico su questioni di interesse pubblico.
Quest'ultima categoria comprende più pubblicazioni aziendali di quanto sembri. Un commento di mercato, un articolo su un cambiamento normativo, una spiegazione su un tema di salute pubblica o di sicurezza dei consumatori: non è evidentemente giornalismo, e può comunque ricadere in un obbligo scritto attorno all'informazione del pubblico.
Che cosa significa davvero etichettare
Qui si confondono due cose, e distinguerle è gran parte del lavoro.
La prima è la marcatura leggibile dalle macchine. Vive nel file. Un sistema a valle, una piattaforma, uno strumento di verifica, un altro modello, deve poter leggere il file e stabilire che è stato generato o manipolato artificialmente. Questo obbligo riguarda i fornitori.
La seconda è l'informativa visibile a una persona. È l'avviso nel punto in cui qualcuno incontra il contenuto. Deve raggiungerlo lì, non trovarsi in un documento di policy a tre clic di distanza. Questo obbligo riguarda i deployer.
Un avviso visibile non soddisfa il requisito di leggibilità automatica, e una marcatura leggibile dalle macchine da sola non dice nulla a un lettore. Sono obblighi diversi, rivolti a destinatari diversi, e un team che ne ha assolto uno non ha automaticamente assolto l'altro.
Il punto che quasi tutti mancano
Un'etichetta è un'affermazione sul contenuto. Non è un registro di che cosa è stato prodotto, da chi e quando.
Questa distinzione resta invisibile finché qualcuno non ha motivo di verificare l'affermazione, e quel qualcuno raramente è un regolatore. Molto più spesso è un cliente con un questionario di qualifica fornitori, una controparte in una controversia contrattuale, o una piattaforma che vi chiede di sostenere una dichiarazione fatta mesi prima.
A quel punto l'etichetta non è più la risposta. È ciò che viene messo in discussione. Quello che viene chiesto dopo sono prove: quale versione è stata pubblicata, che cosa vi ha messo mano fra bozza e pubblicazione, e a che data ciò era vero. A queste domande risponde un registro, non un avviso che controllate e potete modificare.
La maggior parte dei team ricorre a ciò che ha già: date di modifica dei file, un thread di email, la cronologia del project management, la cronologia delle versioni nel cloud. Ognuno di questi elementi è nelle mani della parte che fa l'affermazione e ognuno può essere modificato da quella parte. Internamente sono utili. Sono deboli nel momento in cui il loro valore dipende dal fatto che qualcun altro ci creda.
Che cosa sistemare entro lunedì
Tre domande, in quest'ordine. Nessuna richiede un parere legale per iniziare.
Che cosa abbiamo pubblicato? Non quello che oggi sta sulla pagina. Quello che è effettivamente uscito, in quale versione, in quale data. Se nessuno sa rispondere per un contenuto di tre mesi fa, quella è la prima lacuna.
Che cosa vi ha messo mano? Quali parti sono state generate, quali modificate da un modello, quali scritte da una persona. Nella maggior parte dei team la risposta onesta è che un modello ha aiutato da qualche parte e una persona ha firmato il risultato, il che è perfettamente rispettabile da dichiarare.
Possiamo dimostrarlo? Non affermarlo. Dimostrarlo, a qualcuno che non ha motivo di credervi sulla parola e non ha accesso ai vostri sistemi.
Se la risposta alla terza domanda è no, conviene rimediare prima che la domanda arrivi, non dopo. Un registro datato e verificabile in modo indipendente di che cosa è stato pubblicato e di come è stato prodotto colma il divario, ed è molto più facile crearlo al momento della pubblicazione che ricostruirlo un anno dopo.
