Con l’approvazione definitiva del Digital Omnibus da parte del Consiglio UE, il 29 giugno 2026, le imprese che sviluppano o utilizzano sistemi di AI ad alto rischio hanno ricevuto una nuova data: gli obblighi per i sistemi dell’Allegato III del Regolamento UE 2024/1689 (AI Act) si applicano dal 2 dicembre 2027, non più dal 2 agosto 2026. Diciassette mesi guadagnati. La cronaca della decisione è stata raccontata; questa è invece una guida operativa: quali sistemi rientrano nell’Allegato III, cosa deve fare chi li fornisce e chi li usa, e come distribuire il lavoro di adeguamento su un calendario che sembra largo e non lo è.
Le otto aree dell’Allegato III: chi è dentro
L’Allegato III elenca i casi d’uso che rendono un sistema di AI ad alto rischio non per come è costruito, ma per dove viene impiegato. Le aree sono otto:
- biometria non vietata: identificazione remota, categorizzazione, riconoscimento delle emozioni fuori dai contesti proibiti;
- infrastrutture critiche: componenti di sicurezza di reti energetiche, idriche, di trasporto e digitali;
- istruzione e formazione: sistemi che decidono ammissioni, valutano studenti, sorvegliano esami;
- occupazione e gestione dei lavoratori: selezione del personale, screening dei curricula, decisioni su promozioni, assegnazione dei compiti, monitoraggio delle prestazioni;
- servizi essenziali pubblici e privati: valutazione del merito creditizio, tariffazione di assicurazioni vita e salute, accesso a prestazioni sociali, gestione delle chiamate di emergenza;
- attività di contrasto: strumenti a disposizione delle forze dell’ordine, entro i limiti dei divieti;
- migrazione, asilo e controllo delle frontiere;
- amministrazione della giustizia e processi democratici.
Per un’impresa italiana media le aree calde sono tre: le risorse umane, il credito e l’istruzione. Il gestionale che filtra i curricula prima che li veda un recruiter è un sistema ad alto rischio. Lo scoring che decide un fido lo è. La piattaforma che assegna un punteggio agli studenti di un corso di formazione finanziato lo è.
Molte aziende sono deployer di sistemi ad alto rischio senza saperlo, perché la funzione è annegata dentro un software acquistato per fare altro.
Va chiarito un equivoco diffuso: il Digital Omnibus ha spostato la data, non il contenuto. L’elenco delle otto aree resta quello, gli obblighi restano quelli, e la Commissione conserva il potere di aggiornare l’Allegato aggiungendo casi d’uso man mano che emergono nuovi rischi. Chi spera in un alleggerimento del merito, oltre che del calendario, non lo trova nel testo approvato dal Consiglio.
Fornitore o deployer: due ruoli, due liste di obblighi
L’AI Act distribuisce gli obblighi lungo la catena del valore. Il fornitore, chi sviluppa il sistema o lo fa sviluppare e lo immette sul mercato con il proprio nome, porta il carico più pesante: sistema di gestione del rischio lungo tutto il ciclo di vita, governance dei dati di addestramento, documentazione tecnica, registrazione automatica degli eventi, istruzioni d’uso, progettazione che consenta la sorveglianza umana, livelli adeguati di accuratezza e cybersicurezza, sistema di gestione della qualità, valutazione di conformità, marcatura CE, registrazione nella banca dati europea.
Il deployer, chi usa il sistema sotto la propria autorità in un contesto professionale, ha obblighi più leggeri ma tutt’altro che simbolici: usare il sistema secondo le istruzioni, affidare la sorveglianza umana a persone con competenza, autorità e formazione adeguate, garantire la pertinenza dei dati di input, monitorare il funzionamento, conservare i log, informare i lavoratori quando il sistema li riguarda, sospendere l’uso se emergono rischi.
Attenzione al confine mobile: il deployer che modifica in modo sostanziale un sistema ad alto rischio, o che appone il proprio marchio, diventa fornitore, ereditando l’intera lista di obblighi. È il rischio tipico delle personalizzazioni spinte sui software HR.
Un esempio rende l’idea. Una banca che compra un motore di scoring creditizio e lo usa così com’è resta deployer: deve formare gli analisti, controllare gli input, conservare i log. La stessa banca che riaddestra il motore sui propri dati storici e lo integra con variabili proprietarie ha buone probabilità di aver operato una modifica sostanziale: a quel punto le servono documentazione tecnica, sistema di gestione del rischio e marcatura CE. La differenza tra le due posizioni vale mesi di lavoro e va decisa a tavolino prima di firmare il contratto, non scoperta dopo.
La prima mossa: inventario e classificazione
Nessun piano di adeguamento parte dagli obblighi. Parte dalla mappa.
La domanda giusta non è quali articoli del regolamento ci riguardano, ma quali sistemi abbiamo davvero in casa. Le due domande sembrano uguali e non lo sono: la prima produce un parere legale, la seconda produce un inventario. Solo il secondo si trasforma in un piano.
Il primo blocco di lavoro, realisticamente un trimestre, è il censimento di tutti i sistemi di AI presenti in azienda: quelli comprati, quelli sviluppati, quelli arrivati dentro altri software, quelli che i reparti usano senza averlo mai dichiarato. Per ciascuno vanno registrati funzione, fornitore, dati trattati, decisioni influenzate, persone coinvolte. Poi si classifica: vietato, alto rischio da Allegato III, soggetto ai soli obblighi di trasparenza, o a rischio minimo. La classificazione va motivata per iscritto, perché l’autorità di vigilanza chiederà prima di tutto il criterio, non l’elenco.
Serve anche un proprietario del processo. L’esperienza del GDPR insegna che gli adeguamenti affidati a tutti non li fa nessuno: le imprese che nel 2017 nominarono presto un responsabile con budget e mandato arrivarono al maggio 2018 in ordine, le altre no. Per l’AI Act la figura naturale è un comitato ristretto tra IT, legale, risorse umane e chi possiede i processi di business coinvolti, con un riporto diretto alla direzione. Non è burocrazia: è l’unico modo per far dialogare inventario tecnico e valutazioni giuridiche.
Il Digital Omnibus ha confermato anche la valvola di sfogo dell’articolo 6: un sistema che rientra formalmente nell’Allegato III può non essere considerato ad alto rischio se svolge compiti puramente preparatori o non influenza in modo sostanziale le decisioni. La valutazione va documentata e il sistema va comunque registrato. È una via d’uscita per i casi marginali, non una scappatoia generale: usarla per il sistema che scarta i curricula sarebbe una classificazione indifendibile.
Il cuore tecnico: dati, documentazione, sorveglianza umana
Superata la mappa, il grosso del tempo va su tre cantieri.
La governance dei dati impone che i set di addestramento, convalida e prova siano pertinenti, rappresentativi e per quanto possibile completi e corretti, con un esame specifico dei possibili bias. Per il deployer il compito speculare è garantire la qualità dei dati di input: il sistema di scoring più curato produce risultati distorti se alimentato con dati sporchi. La documentazione tecnica deve permettere a un’autorità di capire come il sistema è stato costruito e come si comporta: per i fornitori significa mettere per iscritto scelte che finora vivevano nelle teste degli sviluppatori. C’è poi la registrazione automatica degli eventi: i sistemi devono generare log capaci di ricostruire chi ha fatto cosa e quando, e i deployer devono conservarli per almeno sei mesi. Sembra un dettaglio tecnico, ma nei contenziosi sarà la prova regina, in un senso o nell’altro.
La sorveglianza umana è il cantiere più sottovalutato. Non basta scrivere che un umano supervisiona: serve individuare chi, con quale formazione, con quali poteri effettivi di ignorare o ribaltare l’output del sistema, e con quali strumenti per accorgersi delle anomalie. Un supervisore che approva il 100 percento delle raccomandazioni della macchina non è sorveglianza, è un timbro. La formazione di queste figure è il punto in cui l’adeguamento all’Allegato III incrocia l’obbligo di alfabetizzazione dell’articolo 4, già in vigore, e programmi strutturati come la formazione aziendale di AIPIA servono esattamente a costruire questa competenza documentabile.
Valutazione di conformità, marcatura CE e FRIA
Per la maggior parte dei sistemi dell’Allegato III la valutazione di conformità è interna: il fornitore verifica se stesso applicando le norme armonizzate in corso di pubblicazione, redige la dichiarazione UE di conformità e appone la marcatura CE. Per la biometria è previsto il coinvolgimento di un organismo notificato. La registrazione nella banca dati europea completa il quadro, rendendo pubblica l’esistenza del sistema.
Sul fronte delle norme armonizzate conviene una parola di realismo. Gli organismi europei di normazione stanno ancora completando gli standard tecnici che daranno presunzione di conformità, e il rinvio al 2027 serve anche a dare loro respiro. Le imprese non devono aspettarli ferme: i requisiti del regolamento sono già scritti, e chi struttura ora il proprio sistema di gestione del rischio dovrà al massimo ritoccarlo quando gli standard arriveranno, non costruirlo da zero.
I deployer pubblici e i privati che erogano servizi essenziali hanno un adempimento in più: la valutazione d’impatto sui diritti (FRIA) prima della messa in uso, che analizza processi, categorie di persone interessate, rischi specifici e misure di mitigazione. Chi ha già una prassi solida di valutazioni d’impatto privacy parte avvantaggiato: metodo e struttura documentale sono in gran parte sovrapponibili, e i due adempimenti possono condividere lo stesso fascicolo.
Un avvertimento sui fornitori extraeuropei: molti software HR e di scoring usati in Italia sono americani. Il rinvio al 2027 vale anche per loro, ma la disponibilità della documentazione di conformità dipenderà dalla loro volontà di servire il mercato europeo. Le imprese farebbero bene a inserire nei rinnovi contrattuali di quest’anno clausole che obbligano il fornitore a consegnare documentazione tecnica, istruzioni d’uso e dichiarazione di conformità in tempo utile. Il contratto firmato nel 2026 è lo strumento di compliance del 2027. Lo stesso vale per gli accordi con gli integratori di sistema: chi personalizza il software per conto del cliente deve sapere, nero su bianco, dove finisce il suo ruolo e dove comincia quello del fornitore.
Perché diciassette mesi sono meno di quel che sembrano
Il conto si fa presto. Un trimestre per l’inventario e la classificazione. Due o tre trimestri per data governance, documentazione e sorveglianza umana, che dipendono da fornitori esterni con tempi propri. Un trimestre per la valutazione di conformità o per la FRIA, con gli inevitabili ritorni indietro. Un trimestre di margine per i test e per gli imprevisti. Sono quindici mesi su diciassette, ipotizzando che tutto fili e che le norme armonizzate arrivino in tempo.
E il rinvio non ha toccato tutto il resto del calendario. Gli obblighi di trasparenza dell’articolo 50 e il regime sanzionatorio pieno partono il 2 agosto 2026; i divieti dell’articolo 5 sono già in vigore; l’alfabetizzazione dell’articolo 4 pure. Chi legge il rinvio come un liberi tutti confonde una proroga selettiva con una sospensione generale. AIPIA mantiene sul punto una guida operativa all’AI Act aggiornata trimestralmente, con il calendario completo degli adempimenti per ruolo e tipo di sistema.
C’è infine un argomento competitivo che i consigli di amministrazione capiscono meglio delle sanzioni. I grandi clienti e le stazioni appaltanti hanno già cominciato a chiedere ai fornitori evidenze di conformità all’AI Act nei questionari di qualifica, senza aspettare il 2027. Chi arriva alla scadenza con il fascicolo pronto vende; chi arriva con le mani vuote esce dalle gare prima ancora che un’autorità lo guardi. I diciassette mesi non sono una pausa: sono il vantaggio concesso a chi li usa sul concorrente che li spreca.
