Il rinvio degli obblighi alto rischio previsto dall'AI Act al 2027 tocca direttamente chi si occupa di project management in un PMO. Se il vostro progetto ha già superato lo screening di classificazione e avviato la documentazione di rischio in vista della scadenza del 2 agosto 2026, la notizia del rinvio può sembrare un sollievo. Ma la domanda operativa resta la stessa: fermare, rallentare o proseguire? Il rischio concreto in questa fase non è tecnico, è di lettura. Se il rinvio viene interpretato come una sospensione generale dell'AI Act, un PMO rischia di allentare anche i controlli su obblighi che non sono stati toccati dalla proroga. A partire dalla trasparenza sui contenuti generati dall'AI, che riguarda una platea di progetti molto più ampia di quella coinvolta nella classificazione alto rischio.
Cosa dice davvero il rinvio, e cosa lascia invariato
Il Digital Omnibus non sospende l'impianto dell'AI Act: sposta in avanti due scadenze specifiche, relative a due categorie distinte di sistemi ad alto rischio. Gli obblighi per i sistemi standalone dell'Allegato III — impiego, istruzione, accesso a servizi essenziali — passano dal 2 agosto 2026 al 2 dicembre 2027. Gli obblighi per i sistemi ad alto rischio integrati in prodotti già regolamentati dall'Allegato I — macchinari, dispositivi medici — passano al 2 agosto 2028 (Regolamento (UE) 2026/1744). Tutto il resto dell'impianto normativo resta al suo posto. Gli obblighi di trasparenza dell'articolo 50 sull'etichettatura dei contenuti generati o manipolati dall'AI restano fissati al 2 agosto 2026 (Regolamento (UE) 2024/1689). Il divieto sui sistemi che generano immagini non consensuali e materiale pedopornografico sintetico entra in vigore da subito, come eccezione esplicita rispetto al rinvio generale (Regolamento (UE) 2026/1744).
Due scadenze diverse per sistemi diversi nello stesso progetto
La complicazione pratica per un PMO nasce proprio qui: un progetto che integra più componenti AI può avere scadenze di compliance diverse per moduli diversi. Un sistema di scoring standalone e un dispositivo medico che incorpora un modulo di intelligenza artificiale, all'interno dello stesso programma, non condividono più la stessa milestone. Ribaselinare in blocco l'intero piano sulla data più lontana significherebbe perdere di vista gli obblighi che restano fermi al 2026.
| Categoria di sistema | Riferimento normativo | Scadenza originaria | Nuova scadenza | Fonte |
|---|---|---|---|---|
| Alto rischio standalone (impiego, istruzione, accesso a servizi essenziali) | Allegato III, AI Act | 2 agosto 2026 | 2 dicembre 2027 | Regolamento (UE) 2026/1744 |
| Alto rischio integrato in prodotti regolamentati (macchinari, dispositivi medici) | Allegato I, AI Act | 2 agosto 2026 | 2 agosto 2028 | Regolamento (UE) 2026/1744 |
| Trasparenza — etichettatura contenuti generati o manipolati dall'AI | Articolo 50, AI Act | 2 agosto 2026 | Invariata: 2 agosto 2026 | Regolamento (UE) 2024/1689 |
| Pratiche vietate — immagini non consensuali e materiale pedopornografico sintetico | Pratiche vietate, AI Act | Già in vigore | Invariata: in vigore da subito, eccezione esplicita al rinvio | Regolamento (UE) 2026/1744 |
Il framework: separare lo scope del rinvio dallo scope del piano
Per tradurre questa distinzione in una decisione di ribaselining, un PMO ha bisogno di un criterio semplice prima di toccare qualsiasi milestone. Occorre verificare, per ciascun sistema AI del progetto, a quale delle quattro righe della tabella appartiene. Solo dopo questa verifica ha senso decidere se spostare una data nel piano o lasciarla invariata. Il rinvio riguarda scadenze specifiche su categorie specifiche di sistemi, non l'impianto dell'AI Act nel suo complesso: trattarlo come una pausa generale significa applicare a torto la stessa logica a obblighi che seguono calendari diversi.
- Il sistema AI del progetto rientra nell'Allegato III (impiego, istruzione, servizi essenziali)? La nuova scadenza è il 2 dicembre 2027.
- Il sistema AI è integrato in un prodotto già regolamentato (Allegato I, es. dispositivo medico, macchinario)? La nuova scadenza è il 2 agosto 2028.
- Il progetto genera o manipola contenuti tramite AI destinati a un pubblico? L'obbligo di etichettatura (art. 50) resta al 2 agosto 2026, invariato.
- Il progetto include funzionalità vicine a pratiche vietate (es. generazione di immagini non consensuali)? Il divieto è già in vigore, senza alcun rinvio.
- Prima di ribaselinare qualunque milestone, verificare a quale di queste categorie appartiene ciascun sistema AI del progetto, non il progetto nel suo insieme.
Il meccanismo: ribaselining selettivo, non totale
La tabella della sezione precedente è il punto di partenza, non il punto di arrivo. Il meccanismo operativo per un PMO è semplice nella logica ma richiede disciplina nell'esecuzione: non si ribaselina il progetto, si ribaselina la singola milestone che dipende da una scadenza effettivamente spostata. Un progetto che integra più sistemi AI può contenere contemporaneamente milestone diverse. Alcune restano ferme al 2 agosto 2026 (trasparenza, pratiche vietate), altre si spostano al 2 dicembre 2027 o al 2 agosto 2028, a seconda della categoria del sistema. Spostare in blocco l'intera roadmap di compliance sulla data più lontana è l'errore più comune: libera risorse nel breve periodo, ma lascia scoperti gli obblighi che il rinvio non ha toccato.
Esempio simulato — Scenario simulato
Un PMO gestisce un progetto di screening candidati basato su AI, classificato alto rischio ai sensi dell'Allegato III. Nella pianificazione originaria, uno sprint di documentazione e gestione del rischio era previsto per il terzo trimestre 2026, in vista della scadenza di agosto. Con il rinvio al 2 dicembre 2027, il team ha due opzioni: spostare la milestone di conformità documentale alla nuova data, oppure mantenere il ritmo per non interrompere il lavoro già avviato. Applicando il meccanismo di ribaselining selettivo, il PMO sposta solo la milestone relativa alla documentazione formale di conformità Allegato III. Lascia invece invariata la milestone relativa alla revisione periodica del rischio, già inserita nel piano come attività ricorrente indipendente dalla scadenza normativa.
Passi pratici per aggiornare il piano senza perdere terreno
- Separare, nel piano di progetto, la milestone di classificazione e valutazione del rischio (che può proseguire senza modifiche) dalla milestone di conformità documentale alto rischio (che può slittare in base alla categoria del sistema).
- Aggiornare la data della sola milestone di conformità alto rischio per i sistemi Allegato III (nuova scadenza 2 dicembre 2027) o Allegato I (nuova scadenza 2 agosto 2028). Lasciare invariata la milestone relativa all'etichettatura ex articolo 50.
- Registrare nel piano la motivazione di ogni spostamento di data, con riferimento al Regolamento (UE) 2026/1744 e alla categoria di sistema interessata, così da mantenere tracciabile il perché di ogni ribaselining.
- Mantenere attiva la cadenza di revisione periodica del rischio già stabilita, anche in assenza di una scadenza imminente. Interrompere questa attività per poi doverla ricostruire in emergenza nel 2027 costa più tempo di quanto se ne risparmi ora.
- Verificare, prima di comunicare il rinvio al team, che il messaggio distingua esplicitamente le scadenze spostate da quelle invariate, per evitare che l'intero progetto allenti il presidio su trasparenza e pratiche vietate.
Trade-off
- Beneficio: Ribaselinare solo le milestone effettivamente toccate dal rinvio libera capacità del team nel breve periodo, senza sacrificare il presidio sugli obblighi trasversali già in vigore.
- Costo: Richiede una classificazione preliminare accurata per ciascun sistema AI del progetto: senza questa mappatura, il ribaselining selettivo non è applicabile e si torna alla scelta binaria tra fermare tutto o proseguire tutto invariato.
- Rischio: Se il team interpreta il rinvio come una sospensione generale, rischia di allentare anche i controlli su trasparenza e pratiche vietate, che restano invariati e non godono di alcuna proroga.
- Prerequisito: Il progetto deve avere già distinto, nel piano o nel registro di classificazione, quali sistemi rientrano nell'Allegato III, quali nell'Allegato I e quali generano contenuti soggetti all'obbligo di etichettatura.
- Limite: Questo framework indica come decidere la ricalendarizzazione delle milestone di compliance; non affronta la struttura documentale della tracciabilità decisionale in sé, né i requisiti di certificazione volontaria come ISO 42001, che restano ambiti distinti.
Cosa cambia per la governance di progetto, non solo per il calendario
Il ribaselining selettivo descritto sopra risolve la domanda su quando spostare una data. Resta aperta una domanda diversa: come conservare evidenza del perché quella data è stata spostata, e del perché altre sono rimaste ferme. È qui che entra in gioco lo strumento con cui il PMO gestisce il piano, non come motore di conformità normativa. ControlRoom non calcola né determina lo stato di conformità di un sistema AI rispetto all'AI Act: resta uno strato interpretativo sopra dati deterministici. Serve invece come luogo dove registrare, in modo tracciabile, la classificazione di rischio di ciascun sistema, le revisioni umane effettuate e la motivazione di ogni spostamento di milestone nel decision log del progetto.
Questo articolo si concentra sulla decisione di ribaselining: quali milestone spostare, quali lasciare ferme, in base alle scadenze reali del Regolamento (UE) 2026/1744. La struttura completa di un audit trail delle decisioni AI in un progetto — cosa registrare, con quale granularità, per quanto tempo conservarlo — è un tema distinto, trattato separatamente. Lo stesso vale per l'adozione di schemi di certificazione volontaria come ISO 42001 per la governance AI del PMO, che risponde a una logica organizzativa diversa da quella del rispetto delle scadenze normative qui discusse.
- La motivazione di ogni milestone spostata è registrata con riferimento esplicito al Regolamento (UE) 2026/1744 e alla categoria di sistema (Allegato III o Allegato I)?
- Le milestone relative a trasparenza (art. 50) e pratiche vietate risultano ancora presenti nel piano, non rimosse insieme a quelle effettivamente rinviate?
- Il team di progetto ha ricevuto una comunicazione che distingue esplicitamente scadenze spostate da scadenze invariate, evitando il messaggio generico di "rinvio dell'AI Act"?
- La cadenza di revisione periodica del rischio, indipendente dalla scadenza normativa, resta attiva nel piano operativo?
- In caso di più sistemi AI nello stesso progetto, la classificazione per ciascuno è documentata separatamente, così da poter dimostrare la scadenza corretta applicata a ciascuno?
Il sollievo per il rinvio è legittimo, ma va commisurato alla sua portata reale: due scadenze specifiche spostate, non un'intera normativa sospesa. Per un PMO che aveva già avviato classificazione e documentazione, il tempo guadagnato non è un motivo per fermarsi: è un margine per consolidare ciò che serve comunque. Quando il 2 dicembre 2027 e il 2 agosto 2028 arriveranno, servirà una mappatura chiara dei sistemi per categoria. Servirà anche un piano che distingue le milestone toccate da quelle invariate, con una traccia documentata di ogni decisione presa nel frattempo.