La specifica si basa sui requisiti EN 304 223 e su cinque misure contro i contenuti sintetici
«Contenuti deepfake dannosi, ingannevoli e illegali, come immagini abusive o siti di prodotti fraudolenti, possono essere creati dall’uso scorretto di software legale e disponibile in commercio». La frase è di Alex Cadzow, rapporteur e segretario del comitato tecnico ETSI TC SAI. Accompagna la nuova specifica tecnica ETSI TS 104 275, pubblicata nei giorni scorsi dall’ente europeo di normazione per le telecomunicazioni. Lo scopo dichiarato è ridurre il rischio che i sistemi di intelligenza artificiale generativa producano deepfake dannosi.
Software legale, output illecito: lo scenario che ETSI mette nero su bianco
Lo scenario descritto da Cadzow ha un tratto preciso. Non ci sono malware, strumenti clandestini o codice manomesso. La “macchina” è lecita, regolarmente commercializzata, e funziona esattamente come è stata progettata. Eppure l’output è un’immagine abusiva o la vetrina di un sito truffaldino. Chi si occupa di ingegneria forense riconosce subito questa configurazione: è l’uso scorretto ragionevolmente prevedibile. In quel caso l’attenzione non si ferma all’utilizzatore, ma risale a chi ha progettato il sistema e a cosa ha fatto per prevenire l’abuso.
La TS 104 275 è stata sviluppata dal Technical Committee on Securing Artificial Intelligence (TC SAI), il comitato ETSI dedicato alla messa in sicurezza dell’IA. Il documento sposta la domanda. Prima ci si chiedeva se un software potesse essere abusato, e per l’IA generativa la risposta è quasi sempre sì. Ora conta se chi lo sviluppa o lo integra è in grado di dimostrare di aver valutato e mitigato quell’abuso prima del rilascio. Resta da capire a chi si chiede conto di un deepfake prodotto da uno strumento lecito. La prima risposta arriva da Bruxelles, prima ancora che dagli standard.
Dalla norma alla specifica: Articolo 50, EN 304 223 e il catalogo delle misure
Sul piano regolatorio il riferimento è l’Articolo 50 del regolamento europeo sull’intelligenza artificiale (AI Act). Come chiarisce la Commissione europea nelle sue FAQ sugli obblighi di trasparenza, le regole dell’Articolo 50 impongono ai fornitori di marcare gli output dei sistemi di IA con marcature leggibili da macchina, così che i deepfake possano essere rilevati. Il punto va letto con attenzione. La norma non si accontenta di buone intenzioni o di dichiarazioni d’uso responsabile. Chiede un segno tecnico che un altro sistema possa riconoscere automaticamente.
La TS 104 275 traduce questa esigenza in un insieme di misure. Non parte da zero: si appoggia ai requisiti di cybersicurezza di base fissati dallo standard ETSI EN 304 223 per modelli e sistemi di IA, applicandoli al rischio specifico dei contenuti sintetici. Il catalogo comprende cinque misure:
- valutazioni del rischio prima del rilascio, cioè identificare i possibili usi impropri del sistema generativo e predisporre le salvaguardie prima che venga messo in circolazione;
- supervisione umana;
- filtri sui contenuti;
- etichettatura dei contenuti generati dall’IA;
- monitoraggio continuo.
Chi conosce la sicurezza del prodotto ritrova una sequenza familiare: analisi del rischio, misure di protezione, informazione all’utente, sorveglianza nel tempo.
Il lavoro non si chiude qui. ETSI ha già annunciato, nella comunicazione con cui presentava lo standard per la sicurezza dell’IA, un rapporto tecnico in arrivo, l’ETSI TR 104 159. Applicherà i principi della EN 304 223 all’IA generativa come dominio specifico. Si concentrerà su deepfake, misinformazione, disinformazione, rischi per la riservatezza e questioni di copyright e proprietà intellettuale. Il quadro, quindi, è destinato ad allargarsi. Il catalogo c’è, ma un perito porrà sempre la stessa domanda: dove sono le evidenze? E con quali strumenti si marca davvero un contenuto?
Tre lezioni operative: costruttore, integratore, gestore
Conviene rispondere ruolo per ruolo, come si farebbe dopo un sopralluogo. La prima lezione riguarda il fornitore del modello. La valutazione del rischio prima del rilascio deve esistere come documento, non come intenzione. Deve indicare quali usi impropri sono stati ipotizzati, con quale criterio sono stati giudicati prevedibili e quali salvaguardie ne sono derivate. È l’equivalente del fascicolo tecnico di una macchina, cioè la raccolta documentale che dimostra come il costruttore ha analizzato e ridotto i rischi. Se manca, in sede di contestazione andrà ricostruito a posteriori, con molta meno credibilità.
La seconda lezione riguarda chi integra il sistema in un prodotto o in un servizio. Filtri sui contenuti e supervisione umana vanno configurati, e la configurazione va tracciata: quali soglie, quali categorie bloccate, chi interviene e quando. Per la marcatura degli output non serve inventare un formato proprietario. Si può fare leva su schemi già adottati dal mercato come lo standard C2PA / Content Credentials, sostenuto da Adobe, da grandi aziende tecnologiche e da produttori di fotocamere. L’adeguamento ha un costo di integrazione. Appoggiarsi a uno schema diffuso, però, riduce il rischio che la marcatura non venga riconosciuta a valle.
La terza lezione riguarda chi gestisce il sistema in esercizio. Il monitoraggio continuo previsto dalla specifica deve lasciare traccia, esattamente come un registro di manutenzione. Servono segnalazioni ricevute, anomalie rilevate, aggiornamenti dei filtri e date degli interventi. Un controllo che non lascia evidenza, davanti a un’autorità, vale quanto un controllo mai fatto.
Il deepfake dannoso va trattato come l’uso scorretto prevedibile di una macchina. Non si elimina del tutto, ma si progetta contro di esso e se ne conserva la prova. L’azione concreta da avviare subito è semplice: prendere le cinque misure della TS 104 275 e sovrapporle al proprio sistema, annotando per ciascuna cosa esiste già, cosa è documentato e cosa manca. Chi documenta fin d’ora valutazione del rischio, filtri, marcatura e monitoraggio non dovrà ricostruirli in fretta davanti a un’autorità o a un giudice.
