Lo scorso 24 luglio è stato pubblicato sulla Gazzetta Ufficiale dell’Unione Europea il Regolamento (UE) 2026/1744 che modifica il Regolamento (UE) 2024/1689 sull’intelligenza artificiale: il cosiddetto “Digital Omnibus sull’IA”, inserito nel pacchetto di norme presentato dalla Commissione Europea al fine di semplificare la legislazione esistente in materia di digitalizzazione. Il nuovo Regolamento non incide sull’impianto generale degli obblighi introdotti dall’AI Act, ma interviene su alcune disposizioni di particolare rilievo giuridico e con significativo impatto operativo per fornitori e deployer.
Il cambiamento più immediato, e forse quello di maggiore impatto pratico, riguarda la ridefinizione del calendario di applicazione del Regolamento. Le nuove scadenze da tenere a mente sono essenzialmente tre:
- il 2 dicembre 2027 scatta la piena applicazione della disciplina sui sistemi ad alto rischio classificati in base al caso d’uso, ossia quelli elencati nell’Allegato III;
- slitta invece al 2 agosto 2028 il termine di applicazione della disciplina sui sistemi di IA utilizzati come componente di sicurezza di un prodotto, o che costituiscono essi stessi un prodotto, sottoposto alla normativa di armonizzazione dell’Unione – cd. sistemi IA “di prodotto” – disciplinati dall’Allegato I;
- il 2 dicembre 2026 diventeranno applicabili i nuovi divieti di cui all’art. 5, par. 1, lett. b-bis) e b ter), sui deepfake sessuali non consensuali e sul materiale di abuso sessuale su minori generato o manipolato dall’IA, e l’obbligo di marcatura dei contenuti sintetici (art. 50, par. 2) posto a carico dei fornitori di sistemi generativi già immessi sul mercato.
Un secondo intervento riguarda i criteri di identificazione dei sistemi di IA ad alto rischio “di prodotto”. La definizione di “componente di sicurezza” viene precisata, ancorandola alla finalità prevista di prevenire o attenuare i rischi per la salute e la sicurezza di persone o beni. L’articolo 6, inoltre, viene integrato con disposizioni finalizzate a chiarire che i sistemi di IA usati esclusivamente per aspetti non di sicurezza — assistenza agli utenti, ottimizzazione delle prestazioni, efficienza dei servizi, automazione o praticità, controllo qualità — non sono considerati componenti di sicurezza. Restano invece tali i sistemi il cui guasto o malfunzionamento metterebbe a rischio salute e sicurezza. Per i fornitori di prodotti IoT, dispositivi embedded, elettrodomestici o macchinari, la distinzione può ridurre in modo significativo gli oneri di compliance; resta tuttavia necessario svolgere un’attenta due diligence per distinguere correttamente le funzioni safety da quelle non safety, perché l’onere della corretta autoqualificazione resta in capo al fornitore.
All’articolo 3 vengono introdotte due nuove definizioni: quella di “PMI”, per rinvio alla raccomandazione 2003/361/CE, e quella di “piccola impresa a media capitalizzazione”, per rinvio alla raccomandazione (UE) 2025/1099. Per queste categorie di imprese, il Regolamento prevede disposizioni di favore, tra cui documentazione semplificata, tetti sanzionatori e accesso prioritario alle sandbox.
Con riferimento al tema della responsabilità lungo la catena del valore dell’IA, il nuovo Regolamento rende più operativo l’obbligo di cooperazione del fornitore iniziale verso i nuovi fornitori. L’articolo 25, paragrafo 2, viene riformulato indicando il contenuto minimo di tale cooperazione: messa a disposizione di documentazione tecnica sufficiente, comunicazione delle limitazioni note e delle modalità di guasto, concessione di un accesso tecnico mirato, anche a fini di sperimentazione e convalida. Il paragrafo 4 chiarisce, inoltre, che gli obblighi scritti di informazione e accesso tecnico riguardano anche i fornitori di modelli di IA, e non soltanto chi fornisce sistemi, strumenti, servizi, componenti o processi. Per i fornitori a valle, inclusi quelli più piccoli che integrano modelli di terzi in sistemi ad alto rischio, questo rafforza il diritto a ricevere informazioni e accesso per test; per i fornitori originari, in particolare di modelli di IA per finalità generali, rende più stringente e verificabile la predisposizione di accordi contrattuali dettagliati.
Particolarmente rilevante per il raccordo con la normativa in materia di protezione dei dati personali è il nuovo articolo 4 bis, che assorbe e amplia la disciplina già contenuta nell’articolo 10, paragrafo 5, sul trattamento di categorie particolari di dati personali per rilevare e correggere le distorsioni dei sistemi di IA. Il testo attualmente vigente dell’AI Act offre già tale possibilità per i fornitori di sistemi di IA ad alto rischio, fornendo una base giuridica che autorizza il trattamento di dati particolari per finalità di debiasing, considerate motivo di interesse pubblico rilevante ai sensi dell’articolo 9, paragrafo 2, lettera g) del GDPR. La novità sostanziale è che questa facoltà eccezionale viene ora estesa anche ai deployer di sistemi ad alto rischio, nonché a fornitori e deployer di sistemi non ad alto rischio. Affinché tale trattamento avvenga, è richiesto il rispetto di garanzie rigorose: stretta necessità, impossibilità di ricorrere a dati sintetici o anonimizzati, limitazioni tecniche e pseudonimizzazione, controlli di accesso rigorosi, divieto di trasmissione a terzi, cancellazione dopo la correzione e tracciamento nei registri delle attività di trattamento. Dal punto di vista degli adempimenti di compliance, l’articolo 4 bis richiede agli operatori che decideranno di avvalersi di tale facoltà di indicare nei registri delle attività di trattamento i motivi per cui il trattamento delle categorie particolari di dati personali è strettamente necessario per rilevare e correggere distorsioni e i motivi per cui tale obiettivo non può essere raggiunto mediante il trattamento di altri dati.
Sul fronte dei divieti, l’articolo 5 si arricchisce di due nuove pratiche vietate: i sistemi di IA che generano o manipolano immagini, video o audio realistici delle parti intime di una persona fisica riconoscibile, o di una persona che compia atti sessualmente espliciti, senza il consenso libero, specifico, informato e inequivocabile della persona (deepfake sessuali non consensuali); e i sistemi che generano o manipolano materiale o spettacoli di abuso sessuale su minori (Child Sexual Abuse Material – CSAM) salvo cause di giustificazione di diritto nazionale. Per i fornitori di sistemi generativi, l’impatto è diretto: occorre implementare misure tecniche di sicurezza ragionevoli e adeguate a prevenire in modo affidabile tali output. Il considerando 12 chiarisce cosa si intenda per misure “ragionevoli e adeguate”, applicabili dai fornitori di sistemi in cui tale generazione o manipolazione è un risultato ragionevolmente prevedibile e riproducibile: pulizia dei dati, addestramento al rifiuto (refusal training), progettazione sicura dei prompt, controlli sull’output, guardrail a runtime prompt e meccanismi di rilevamento e notifica degli abusi. Per altro verso, un fornitore che sviluppi un sistema destinato alla generazione o alla manipolazione di materiale intimo, deve prevedere mezzi idonei a raccogliere e documentare il consenso libero, specifico, informato e inequivocabile della persona ritratta, conformemente al regolamento (UE) 2016/679. I deployer saranno, invece, responsabili solo se utilizzeranno attivamente il sistema per generare o manipolare materiale intimo non consensuale o materiale di abuso sessuale sui minori.
Restando nella prospettiva dei deployer, il Regolamento di modifica si pone nell’ottica di un miglior coordinamento tra la valutazione d’impatto sui diritti fondamentali (Foundamental Right Impact Assessment – FRIA) e la valutazione d’impatto sulla protezione dei dati (Data Protection Impact Assessment – DPIA): l’art. 27, nella sua nuova formulazione, prevede che il deployer possa includere nella FRIA rimandi o parti delle pertinenti sezioni della DPIA, invece di procedere necessariamente a un’integrazione strutturata. Come segnalato in una delle nostre newsletter pubblicata il 22 aprile scorso, l’Ufficio IA della Commissione ha avviato lo sviluppo di un modello di FRIA separato da quello di DPIA elaborato dall’EDPB, ma pensato per esserne complementare: i due enti manterranno un coordinamento costante affinché i rispettivi template siano funzionalmente compatibili e integrabili attraverso reciproci richiami. La modifica dell’articolo 27 è, in un certo senso, la prima traduzione normativa concreta di quella scelta. Per i deployer soggetti a obbligo di FRIA, questo può ridurre duplicazioni documentali e tempi di adempimento, ferma restando la responsabilità sostanziale sulla completezza della valutazione.
Il Regolamento, come detto, ha posticipato alcune scadenze applicative dell’AI Act. Ma un punto, intanto, non dovrebbe essere trascurato: le date possono essere spostate, gli obblighi no. Il tempo aggiuntivo serve a costruire governance che l’AI Act richiede, non a rinviarla. D’altra parte, per un sistema di IA già in produzione o messo in commercio, la scadenza formale diventa una questione secondaria: la vera domanda è se quel sistema è in grado di reggere sotto pressione. Può resistere a tentativi di prompt injection? Riesce a mantenere i dati sensibili entro flussi controllati? Le sue misure di sicurezza restano efficaci quando gli utenti provano a eluderle? E, soprattutto, il team è in grado di mostrare test eseguiti, correzioni adottate e responsabilità assegnate per ciascun presidio? Una scadenza più lontana cambia il momento in cui il regolatore potrà effettuare il controllo ma non cambia il momento in cui un attaccante, un utilizzo improprio o un errore operativo possono mettere alla prova il sistema. Se l’IA è già attiva, l’orologio che conta è già partito.
E nell’attesa di conoscere i futuri scenari, di seguito troverete una tabella comparativa dei due Regolamenti, pensata per comprendere in maniera immediata questa importante novità.
