Quando l’applicazione generale dell’AI Act scatterà il 2 agosto 2026, il cuore operativo del Regolamento per la maggior parte delle aziende italiane sarà la Sezione 2 del Capo III: i sette requisiti sostanziali per i sistemi di IA ad alto rischio, contenuti negli articoli da 8 a 15 del Regolamento (UE) 2024/1689. A questi si affiancano gli obblighi operativi dell’articolo 16 per i fornitori e, separatamente, gli obblighi dell’articolo 26 per i deployer — due ruoli distinti, con responsabilità diverse.
L’inquadramento dell’articolo 8
L’articolo 8, paragrafo 1, stabilisce il principio generale: «I sistemi di IA ad alto rischio rispettano i requisiti stabiliti nella presente sezione, tenendo conto delle loro previste finalità nonché dello stato dell’arte generalmente riconosciuto in materia di IA e di tecnologie correlate all’IA». La misura di questi requisiti è dunque lo stato dell’arte, e la conformità si valuta in relazione alla finalità prevista.
Il paragrafo 2 introduce un coordinamento importante: quando un prodotto contiene un sistema di IA disciplinato anche dalla normativa di armonizzazione dell’Unione (Allegato I, sezione A — macchine, dispositivi medici, ascensori, veicoli ecc.), i fornitori possono integrare le procedure di prova e la documentazione richieste dall’AI Act nelle procedure di conformità già esistenti, per evitare duplicazioni.
Articolo 9 — Sistema di gestione dei rischi
L’articolo 9 impone di istituire, attuare, documentare e mantenere un sistema di gestione dei rischi, descritto come «un processo iterativo continuo pianificato ed eseguito nel corso dell’intero ciclo di vita di un sistema di IA ad alto rischio». Non è una valutazione una tantum pre-lancio. Le fasi sono quattro: identificazione e analisi dei rischi noti e ragionevolmente prevedibili per salute, sicurezza e diritti fondamentali; stima e valutazione dei rischi nell’uso previsto e nell’uso improprio ragionevolmente prevedibile; valutazione di altri rischi emersi dal monitoraggio post-market (articolo 72); adozione di misure di gestione opportune e mirate.
I rischi da gestire sono solo quelli «ragionevolmente attenuati o eliminati attraverso lo sviluppo o la progettazione del sistema di IA ad alto rischio o la fornitura di informazioni tecniche adeguate». L’obiettivo non è azzerare il rischio, ma ridurlo a un livello residuo accettabile, dando priorità all’eliminazione tecnica quando possibile, poi a misure di attenuazione, infine alla formazione e informazione del deployer. Il paragrafo 9 prevede una considerazione specifica dell’impatto dei sistemi sui minori quando è probabile che siano usati da o che possano incidere su persone di età inferiore ai 18 anni.
Articolo 10 — Dati e governance dei dati
L’articolo 10 copre il ciclo dei dati di addestramento, convalida e prova. I set di dati devono essere «pertinenti, sufficientemente rappresentativi e, nella misura del possibile, esenti da errori e completi nell’ottica della finalità prevista». Sono soggetti a pratiche di governance che comprendono, fra l’altro, scelte progettuali, processi e origine dei dati (inclusa la finalità originaria della raccolta nel caso di dati personali), operazioni di preparazione, ipotesi di misura, valutazione della disponibilità e adeguatezza, esame delle possibili distorsioni suscettibili di avere un impatto negativo sui diritti fondamentali o di comportare discriminazioni vietate, e misure per prevenirle.
È l’articolo più delicato sotto il profilo del rapporto con il GDPR. Il paragrafo 5 ammette il trattamento di categorie particolari di dati personali, ma solo quando strettamente necessario per rilevare e correggere distorsioni, e solo se l’obiettivo non poteva essere raggiunto con altri dati. I registri delle attività di trattamento ai sensi del GDPR devono contenere anche i motivi di questa necessità.
Articolo 11 — Documentazione tecnica
La documentazione tecnica è redatta «prima dell’immissione sul mercato o della messa in servizio» e tenuta aggiornata. Lo scopo: dimostrare la conformità ai requisiti della Sezione 2 e fornire alle autorità nazionali competenti e agli organismi notificati, in forma chiara e comprensibile, le informazioni necessarie per valutare la conformità del sistema. Il contenuto minimo è dettagliato nell’Allegato IV del Regolamento.
Articolo 12 — Conservazione delle registrazioni (log)
I sistemi di IA ad alto rischio devono consentire a livello tecnico la «registrazione automatica degli eventi (log) per la durata del ciclo di vita del sistema». La tracciabilità serve a tre scopi: individuare situazioni in cui il sistema pone un rischio, agevolare il monitoraggio post-market, consentire il monitoraggio da parte del deployer ai sensi dell’articolo 26 paragrafo 5.
Per i sistemi dell’Allegato III punto 1 lettera a) — identificazione biometrica remota — i log devono registrare almeno il periodo di ciascun uso, la banca dati di riferimento utilizzata, i dati di input per cui la ricerca ha portato a un riscontro, l’identificazione delle persone fisiche coinvolte nella verifica dei risultati.
Articolo 13 — Trasparenza e informazioni ai deployer
I sistemi devono essere progettati e sviluppati in modo che il loro funzionamento sia «sufficientemente trasparente da consentire ai deployer di interpretare l’output del sistema e utilizzarlo adeguatamente». Sono accompagnati da istruzioni per l’uso che contengono almeno: identità e contatti del fornitore; caratteristiche, capacità e limiti delle prestazioni, con livello atteso di accuratezza, robustezza e cibersicurezza (con metriche e metodi di prova); circostanze che possono incidere su tali livelli; eventuali rischi di uso improprio ragionevolmente prevedibile; informazioni tecniche rilevanti per permettere ai deployer di attuare la sorveglianza umana.
Articolo 14 — Sorveglianza umana
I sistemi devono poter essere «efficacemente supervisionati da persone fisiche durante il periodo in cui sono in uso». Le misure di sorveglianza sono commisurate ai rischi, al livello di autonomia e al contesto di utilizzo, e si attuano attraverso misure integrate dal fornitore (by design) o misure individuate dal fornitore ma attuate dal deployer. Le persone fisiche che esercitano la sorveglianza devono essere messe in condizione, ove opportuno e proporzionato, di comprendere le capacità e i limiti del sistema, restare consapevoli del rischio di automation bias, interpretare correttamente l’output, decidere di non usare il sistema o di ignorarne l’output, interrompere il funzionamento.
Articolo 15 — Accuratezza, robustezza e cibersicurezza
L’articolo 15 è quello più rilevante per chi si occupa di sicurezza informatica. I sistemi devono conseguire e mantenere «un adeguato livello di accuratezza, robustezza e cibersicurezza» per tutto il ciclo di vita, con i livelli di accuratezza dichiarati nelle istruzioni per l’uso. La robustezza è la resilienza a errori, guasti e incongruenze, perseguibile con misure tecniche e organizzative, compresa la ridondanza (piani di backup o fail-safe). I sistemi che proseguono l’apprendimento dopo l’immissione sul mercato devono essere sviluppati in modo da eliminare o ridurre il rischio di output distorti.
Il paragrafo 5 dell’articolo 15 entra nel dettaglio tecnico delle minacce. Le misure tecniche di cibersicurezza devono affrontare, tra l’altro, «gli attacchi che cercano di manipolare il set di dati di addestramento (data poisoning), i componenti preaddestrati utilizzati nell’addestramento (model poisoning), gli input progettati in modo da far sì che il modello di IA commetta un errore (adversarial examples, o model evasion), gli attacchi alla riservatezza o i difetti del modello». È l’unico punto del Regolamento in cui si nominano testualmente queste specifiche categorie di attacco. Il richiamo ha rilevanza normativa: la conformità all’articolo 15 non è dimostrabile senza aver predisposto misure esplicite contro questi vettori.
Articolo 16 — Gli obblighi operativi del fornitore
L’articolo 16 condensa in dodici lettere gli obblighi a carico del fornitore del sistema di IA ad alto rischio. Li riporto in sintesi perché è la checklist operativa più vicina alla pratica: conformità ai requisiti della Sezione 2 (lettera a); indicazione sul sistema del nome, della denominazione commerciale e dell’indirizzo di contatto (lettera b); sistema di gestione della qualità ai sensi dell’articolo 17 (lettera c); conservazione della documentazione (art. 18, lettera d); conservazione dei log generati automaticamente, per quanto sotto il loro controllo (art. 19, lettera e); svolgimento della procedura di valutazione della conformità ai sensi dell’articolo 43 prima dell’immissione sul mercato (lettera f); dichiarazione di conformità UE (art. 47, lettera g); marcatura CE (art. 48, lettera h); obblighi di registrazione nella banca dati UE (art. 49 paragrafo 1, lettera i); misure correttive quando necessario (art. 20, lettera j); dimostrazione della conformità su richiesta motivata delle autorità nazionali competenti (lettera k); conformità ai requisiti di accessibilità delle direttive (UE) 2016/2102 e (UE) 2019/882 (lettera l).
Il dettaglio della marcatura CE è importante: un sistema di IA ad alto rischio ai sensi del Regolamento sarà immesso sul mercato dell’Unione con una marcatura CE del tutto analoga a quella prevista per altri prodotti armonizzati, a valle di una procedura di valutazione della conformità che, a seconda del caso, richiede un organismo notificato.
Articolo 26 — Il pacchetto separato per i deployer
L’articolo 26 non è accessorio. È il pacchetto di obblighi che ricade su chi utilizza un sistema di IA ad alto rischio nell’ambito di un’attività professionale — tipicamente una banca, un’assicurazione, una pubblica amministrazione, un’azienda HR, una scuola, un ospedale. Il deployer non fabbrica il sistema, ma il Regolamento non lo considera un semplice utilizzatore passivo.
- Uso conforme alle istruzioni (paragrafo 1) — idonee misure tecniche e organizzative per garantire un uso conforme alle istruzioni del fornitore.
- Sorveglianza umana con persone competenti (paragrafo 2) — affidata a persone fisiche «che dispongono della competenza, della formazione e dell’autorità necessarie nonché del sostegno necessario».
- Controllo sui dati di input (paragrafo 4) — nella misura in cui il deployer esercita controllo, garantisce che i dati di input siano pertinenti e sufficientemente rappresentativi.
- Monitoraggio del funzionamento e notifica (paragrafo 5) — monitoraggio del funzionamento del sistema sulla base delle istruzioni per l’uso e informazione al fornitore. Qualora il deployer abbia motivo di ritenere che l’uso comporti un rischio ai sensi dell’articolo 79 paragrafo 1, ne informa senza indebito ritardo il fornitore (o il distributore) e la pertinente autorità di vigilanza del mercato e «sospende l’uso di tale sistema». In caso di incidente grave, notifica immediata al fornitore, agli importatori/distributori e alle autorità di vigilanza del mercato.
- Conservazione dei log (paragrafo 6) — per almeno sei mesi, nella misura in cui i log sono sotto il controllo del deployer, salvo diverse disposizioni di legge.
- Informazione ai lavoratori (paragrafo 7) — prima di mettere in servizio un sistema di IA ad alto rischio sul luogo di lavoro, il datore di lavoro informa i rappresentanti dei lavoratori e i lavoratori interessati che saranno soggetti all’uso del sistema.
- Registrazione nella banca dati UE (paragrafo 8) — per i deployer che sono autorità pubbliche o istituzioni, organi e organismi dell’Unione. Se il sistema non risulta registrato, il deployer non può utilizzarlo e ne informa il fornitore o il distributore.
- Coordinamento con la DPIA (paragrafo 9) — il deployer utilizza le informazioni ricevute ai sensi dell’articolo 13 per adempiere all’obbligo di valutazione d’impatto sulla protezione dei dati (articolo 35 GDPR o articolo 27 della direttiva 2016/680).
- Autorizzazione giudiziaria per la biometria remota a posteriori (paragrafo 10) — nelle indagini, autorizzazione preventiva o entro 48 ore, con effetti di interruzione dell’uso e cancellazione dei dati in caso di rigetto.
A queste si somma, per i deployer pubblici e per alcuni soggetti privati che erogano servizi pubblici essenziali, la valutazione d’impatto sui diritti fondamentali (FRIA) prevista dall’articolo 27 come adempimento aggiuntivo.
Dove si gioca la compliance reale
La distinzione tra fornitore e deployer è il punto in cui cade molta compliance di facciata. Un’organizzazione italiana che acquista un sistema di IA ad alto rischio da un vendor estero, in teoria, non è fornitore: gli obblighi dell’articolo 16 non la riguardano. Ma l’articolo 25 prevede casi in cui un deployer si trasforma in fornitore — in particolare quando appone il proprio marchio, apporta una modifica sostanziale a un sistema già immesso sul mercato, o cambia la finalità prevista di un sistema in modo che rientri nell’alto rischio. In questi casi scattano tutti gli obblighi del fornitore, inclusa la marcatura CE e la valutazione di conformità.
Il lavoro utile, da qui al 2 agosto 2026, non è firmare policy generiche: è qualificare il ruolo (fornitore o deployer), mappare quali sistemi ricadono nell’Allegato III, verificare che il fornitore a monte sia in grado di consegnare la documentazione dell’articolo 13, predisporre la sorveglianza umana dell’articolo 14, avviare la valutazione delle distorsioni dei dati di input di cui all’articolo 26 paragrafo 4, e — se si è una pubblica amministrazione — iniziare a lavorare sulla FRIA dell’articolo 27. Ogni passaggio è ancorato a un obbligo testuale del Regolamento, non a una best practice di compliance.
Fonte
Regolamento (UE) 2024/1689 del Parlamento europeo e del Consiglio del 13 giugno 2024 che stabilisce regole armonizzate sull’intelligenza artificiale, pubblicato nella Gazzetta Ufficiale dell’Unione Europea, Serie L, del 12 luglio 2024. Articoli 8, 9, 10, 11, 12, 13, 14, 15, 16, 25, 26 e 27. Testo ufficiale disponibile su EUR-Lex: eur-lex.europa.eu/eli/reg/2024/1689/oj.
