AI Act: governare il portafoglio, non il registro

Dal 2 agosto 2026 l'AI Act è entrato nella fase generale di applicazione. L'AI Omnibus, Regolamento (UE) 2026/1744, in vigore dal 27 luglio 2026, ha spostato al 2 dicembre 2027 le scadenze per i sistemi high-risk standalone dell'Allegato III, e al 2 agosto 2028 quelle per i sistemi incorporati in prodotti già coperti da normativa di sicurezza di prodotto. Il rinvio riduce una pressione temporale reale, ma non risolve da solo tre problemi che restano interamente a carico dell'organizzazione: costruire un inventario completo dei sistemi in uso, classificarli correttamente, e assegnare responsabilità chiare su ciascuno.

Aspettare la pubblicazione di tutte le linee guida definitive prima di agire produce un rischio prevedibile e concreto: scoprire tardi che sistemi già integrati in processi critici non generano le evidenze richieste, o che i contratti in essere con i fornitori non prevedono clausole di audit, logging e notifica delle modifiche al modello. A quel punto, correggere il contratto è molto più costoso che averlo scritto correttamente all'origine.

Un inventario tecnologico tradizionale elenca modelli, versioni e piattaforme installate. Un portafoglio di governance descrive invece quale decisione concreta viene influenzata da ciascun sistema, su chi quella decisione produce effetti, quali dati il sistema utilizza, quale livello di supervisione umana esiste realmente — non solo sulla carta — e cosa accade operativamente in caso di errore. È questa unità di analisi, la decisione influenzata e non il modello in sé, che permette di distinguere fra sperimentazione interna, automazione a basso impatto e sistemi potenzialmente high-risk, categorie che un semplice elenco tecnologico non riesce a separare.

In mobilità questa distinzione è particolarmente concreta. Lo stesso motore predittivo può stimare guasti su un asset, assegnare priorità operative a una squadra di manutenzione, o contribuire indirettamente a decisioni sulla sicurezza del traffico — e cambiando intended purpose può cambiare anche, nello stesso momento, la lettura regolatoria applicabile e il livello di controllo richiesto, senza che il codice del sistema sia stato modificato di una sola riga.

Data quality, logging, robustezza, human oversight e monitoraggio continuo non sono documenti da produrre a fine progetto per completare un fascicolo di conformità. Devono essere proprietà verificabili del ciclo di vita del sistema, osservate mentre il sistema opera, non ricostruite a posteriori quando qualcuno le richiede. Ogni use case dovrebbe avere un evidence pack proporzionato al proprio livello di rischio: finalità approvata esplicitamente, owner nominato, valutazioni condotte, test eseguiti, limitazioni note e dichiarate, incidenti registrati, performance drift monitorato nel tempo, e decisioni di change tracciate una per una.

Il fornitore detiene spesso una parte rilevante di queste evidenze, in particolare quelle relative all'addestramento e alla validazione del modello. Il procurement deve quindi negoziare esplicitamente accesso a queste informazioni, tempi di notifica in caso di modifiche sostanziali, supporto operativo alle valutazioni di conformità, portabilità dei log verso i sistemi dell'organizzazione acquirente, e conseguenze contrattuali chiare quando il fornitore modifica il modello senza preavviso adeguato.

Una governance efficace richiede gate comuni applicati lungo l'intero ciclo di vita, dall'idea fino al ritiro del sistema: ammissione, valutazione dei dati, classificazione del rischio, procurement, go-live, monitoraggio continuo e retirement pianificato.

Il rinvio delle scadenze high-risk diventa utile solo se l'organizzazione lo converte in capacità organizzativa reale nel frattempo. Il deliverable finale non è un registro più lungo e più dettagliato di sistemi censiti. È un portafoglio in cui nessun sistema classificato come critico può cambiare finalità operativa senza che cambino, nello stesso momento, anche le evidenze richieste e le responsabilità assegnate su di esso.