Art. 55 Reg. (UE) 2024/1689 — Obblighi dei fornitori di modelli di IA per finalità generali con rischio sistemico

Commento

Il livello apicale della piramide GPAI: il rischio sistemico

L'articolo 55 del Regolamento (UE) 2024/1689 rappresenta l'apice regolatorio per i modelli di IA per finalità generali (GPAI). La norma si applica a quei modelli che non solo soddisfano la definizione di GPAI di cui all'art. 3 e gli obblighi di base degli artt. 53-54, ma superano anche la soglia che — ai sensi dell'art. 51, par. 1 — determina la qualificazione come modelli con rischio sistemico. Al momento dell'entrata in vigore del Regolamento, la soglia era individuata in una capacità di calcolo cumulata utilizzata per l'addestramento superiore a 10²⁵ floating point operations (FLOP), parametro che la Commissione può aggiornare con atti delegati per tenere il passo con l'evoluzione tecnologica.

Si tratta, in termini concreti, dei modelli di IA a più ampia diffusione e potenza: i grandi modelli linguistici e multimodali capaci di influenzare in modo pervasivo l'accesso all'informazione, i processi decisionali e le infrastrutture critiche a livello dell'intera Unione. Per questi modelli il Regolamento adotta una logica precauzionale rafforzata: poiché il rischio non è solo per il singolo utente o deployer, ma potenzialmente per l'intera società digitale europea, gli obblighi devono essere di conseguenza più intensi.

Le regole del Capo V, e dunque quelle dell'art. 55, trovano applicazione a partire dal 2 agosto 2025 ai sensi dell'art. 113, par. 2 del Regolamento, con anticipo rispetto alla piena entrata in vigore degli obblighi per i sistemi ad alto rischio.

La valutazione del modello e il test contraddittorio (adversarial testing)

Il primo obbligo aggiuntivo riguarda la valutazione sistematica del modello: il fornitore deve effettuarla seguendo protocolli e strumenti standardizzati che rispecchino lo stato dell'arte. L'elemento più caratteristico di questo requisito è l'obbligo esplicito di svolgere e documentare il test contraddittorio (adversarial testing, o «red teaming» nel gergo dell'industria).

Il test contraddittorio consiste nel simulare attivamente comportamenti malevoli, attacchi o utilizzi impropri del modello — da parte di terzi esperti che assumono intenzionalmente il ruolo di «avversari» — per individuare vulnerabilità, comportamenti inattesi o capacità pericolose non emerse durante i normali test di sviluppo. Nel contesto dei grandi modelli linguistici, questo tipo di valutazione ha permesso di identificare rischi come la generazione facilitata di contenuti dannosi, le tecniche di «jailbreak», la produzione di disinformazione sofisticata o l'assist ad attività illecite.

L'obbligo di documentare il test contraddittorio è centrale: il fornitore non solo deve effettuarlo, ma deve conservare prova delle metodologie usate, dei rischi identificati, delle misure di attenuazione adottate e dell'esito finale. Questa documentazione confluirà nell'ambito delle verifiche dell'Ufficio per l'IA e potrà essere richiesta dalla Commissione nell'esercizio dei propri poteri di controllo.

Valutazione e attenuazione dei rischi sistemici

Il secondo obbligo — valutare e attenuare i possibili rischi sistemici a livello dell'Unione — è al tempo stesso il più importante e il meno facilmente operazionalizzabile. La norma si riferisce ai rischi che possono derivare dallo sviluppo, dall'immissione sul mercato o dall'uso del modello: si pensi all'impatto sulla sicurezza informatica di un modello che faciliti attacchi sofisticati, all'influenza sull'informazione pubblica, ai rischi per infrastrutture critiche, o all'amplificazione di vulnerabilità sistemiche nei settori finanziario, energetico o sanitario.

L'art. 55 non prescrive una metodologia specifica per questa valutazione, ma rinvia ai codici di buone pratiche (art. 56) e alle norme armonizzate come strumenti di attuazione. Il Regolamento attribuisce all'Ufficio per l'IA — organo della Commissione istituito dall'art. 64 — il compito di supervisionare l'adempimento di questi obblighi e di sviluppare metodologie di valutazione comuni.

La segnalazione degli incidenti gravi

L'art. 55, par. 1, lett. c) introduce un obbligo di notifica degli incidenti gravi: il fornitore deve tenere traccia, documentare e riferire «senza indebito ritardo» all'Ufficio per l'IA — e se del caso alle autorità nazionali competenti — le informazioni pertinenti su incidenti gravi ed eventuali misure correttive adottate per porvi rimedio.

Il Regolamento non definisce nell'art. 55 la nozione di «incidente grave», ma si può ricavare in via sistematica dal contesto del Regolamento: si tratta di eventi in cui il funzionamento del modello produce o rischia di produrre effetti negativi significativi, inclusi danni a diritti fondamentali, rischi per la salute o la sicurezza, o compromissione di infrastrutture critiche. L'analogia con gli obblighi di notifica previsti dalla direttiva NIS2 per gli incidenti di sicurezza informatica è evidente e intenzionale.

Per il fornitore questo obbligo richiede di istituire un sistema di monitoraggio continuo del comportamento del modello in produzione — una capacità di «incident detection» non diversa da quanto già richiesto in campo fintech dalla vigilanza bancaria — e di predisporre procedure interne di escalation e notifica.

Cibersicurezza del modello e dell'infrastruttura

Il quarto obbligo aggiuntivo riguarda la cibersicurezza: il fornitore deve garantire un livello adeguato di protezione sia per il modello GPAI in sé sia per la sua infrastruttura fisica. Questo obbligo riflette la consapevolezza che i modelli di IA con rischio sistemico sono infrastrutture critiche digitali: compromettere un grande modello linguistico ampiamente diffuso — attraverso attacchi di data poisoning, model stealing o adversarial inputs — avrebbe conseguenze che vanno ben oltre il danno al singolo fornitore.

Il Regolamento non dettaglia i requisiti tecnici specifici, ma il coordinamento con la direttiva (UE) 2022/2555 (NIS2) e con il Cybersecurity Act è esplicito nell'impianto generale del Regolamento. I fornitori di modelli GPAI con rischio sistemico che operano come operatori di servizi essenziali ai sensi della NIS2 dovranno in ogni caso rispettare gli obblighi di sicurezza previsti da entrambi i regimi.

I codici di buone pratiche come strumento di compliance

Il paragrafo 2 offre ai fornitori un percorso pragmatico verso la conformità: possono aderire ai codici di buone pratiche previsti dall'art. 56 per dimostrare il rispetto degli obblighi del paragrafo 1, almeno fino alla pubblicazione di norme armonizzate. L'adesione al codice crea una presunzione di conformità per gli obblighi da esso contemplati.

I fornitori che scelgono di non aderire a nessun codice di buone pratiche approvato e di non seguire le norme armonizzate devono dimostrare con mezzi alternativi adeguati la propria conformità, ai fini della valutazione della Commissione. Questa terza via è percorribile ma comporta un onere probatorio più elevato: il fornitore dovrà costruire una documentazione solida che dimostri come i propri processi interni raggiungano gli stessi obiettivi di sicurezza e controllo del rischio dei codici o delle norme.

Riservatezza delle informazioni e coordinamento istituzionale

Il paragrafo 3 garantisce che le informazioni e la documentazione ottenute dall'Ufficio per l'IA o dalla Commissione nell'esercizio delle funzioni di cui all'art. 55 siano trattate nel rispetto degli obblighi di riservatezza previsti dall'art. 78 del Regolamento. Questa tutela è essenziale per i fornitori di modelli che devono divulgare dati tecnici sensibili, incluse architetture, dati di addestramento, risultati dei test contraddittori e vulnerabilità identificate: informazioni che potrebbero essere sfruttate da soggetti terzi se non adeguatamente protette.

La norma crea così un equilibrio tra la necessità di trasparenza regolatoria e la legittima protezione degli interessi commerciali e della sicurezza dei fornitori. Questo equilibrio è peraltro già noto in altri contesti di vigilanza, come la supervisione bancaria o la vigilanza farmaceutica, dove l'autorità di controllo accede a informazioni altamente sensibili con obbligo di riservatezza.