In sintesi
- L’Omnibus digitale ha rinviato al 2 dicembre 2027 gli obblighi sui sistemi ad alto rischio autonomi, ma alfabetizzazione all’IA, pratiche vietate, trasparenza e doveri sui modelli per finalità generali sono già esigibili.
- La maggior parte delle sfide della governance dell’IA è di natura organizzativa e non tecnica: responsabilità non assegnata, inventario incompleto, prove irreperibili nel momento in cui vengono richieste.
- Il 78 per cento dei dirigenti non si dichiara fiducioso di superare un audit indipendente di governance dell’IA entro 90 giorni.
- La responsabilità si disperde perché gli obblighi si distribuiscono fra fornitore del modello, fornitore del sistema e deployer, senza che nessuno registri chi porta cosa.
- Ciascuno dei sette blocchi che seguono si chiude su un obbligo nominato, un controllo e un artefatto che un revisore chiederà di vedere.
Cosa è cambiato nel 2026: la scadenza si è spostata, gli obblighi no
La più pesante fra le attuali sfide della governance dell’IA riguarda un calendario che gran parte delle pubblicazioni non ha ancora recepito. Il regolamento (UE) 2026/1744, noto come Omnibus digitale sull’IA, è stato pubblicato in Gazzetta ufficiale il 24 luglio 2026 ed è entrato in vigore il 27 luglio 2026, nove giorni prima della scadenza originaria. Il Parlamento europeo lo aveva approvato il 16 giugno 2026 con 423 voti favorevoli, 57 contrari e 174 astensioni, mentre il Consiglio ha dato il via libera definitivo il 29 giugno 2026. Cosa si è spostato: gli obblighi per i sistemi ad alto rischio autonomi dell’allegato III si applicano ora dal 2 dicembre 2027, quelli per l’IA incorporata nei prodotti regolamentati dell’allegato I dal 2 agosto 2028. Cosa non si è spostato: il divieto delle pratiche inaccettabili, applicabile dal 2 febbraio 2025. Il dovere di alfabetizzazione all’IA dell’articolo 4, applicabile dalla stessa data. Gli obblighi sui modelli per finalità generali del capo V, applicabili dal 2 agosto 2025. I doveri di trasparenza dell’articolo 50. Proprio questa asimmetria costituisce la prima trappola. In sede di budget, un rinvio di sedici mesi viene letto come autorizzazione a sospendere il programma. Non lo è. Gli obblighi che mordono oggi sono quelli che richiedono un modello operativo anziché una modifica di prodotto, ed è proprio da questi che la maggior parte delle organizzazioni non ha ancora iniziato. Il nostro approfondimento sulla normativa in materia di intelligenza artificiale ordina gli obblighi per ruolo e per data.
Blocco 1: nessuno risponde della governance
Chiedete chi è responsabile e otterrete un comitato, non un nome. L’indagine Grant Thornton 2026, condotta su 950 dirigenti, rileva che solo il 48 per cento dei consigli ha formulato aspettative in materia di governance dell’IA e che il 46 per cento ha integrato il rischio IA nella supervisione ordinaria, mentre il 73 per cento dei dirigenti indica la governance come l’area prioritaria. L’indagine annuale Kiteworks 2026, su 459 professionisti di sicurezza e conformità, è ancora più netta: il 39 per cento tratta la governance dell’IA come un incarico aggiuntivo anziché come una funzione dedicata. Un comitato non può essere chiamato a rispondere. Può solo essere convocato. Quando si verifica un incidente, l’autorità chiede chi abbia autorizzato la messa in servizio, e un regolamento interno non costituisce una risposta. Il controllo: un responsabile nominativo per ciascun sistema, un organo decisionale con potere documentato di sospendere un rilascio, e una matrice di responsabilità che sopravviva a un avvicendamento. Il responsabile non deve essere un tecnico. Deve avere l’autorità di dire no e il budget per darvi seguito. È l’elemento portante di qualsiasi framework di governance dell’IA e la meno costosa delle sette correzioni. L’artefatto: una decisione di autorizzazione firmata per ciascun sistema, con il nome del responsabile e la data di approvazione.
Blocco 2: non si inventaria ciò che non si vede
Ogni obbligo del regolamento si aggancia a un sistema. Se non potete elencare i vostri sistemi, nessun altro controllo trova applicazione, perché gli manca l’oggetto. Questa dipendenza colloca l’inventario alla radice della maggior parte delle sfide della governance dell’IA. L’ampiezza del divario è ormai misurata. Kiteworks rileva che il 65 per cento delle organizzazioni ha scoperto un uso di IA ombra nell’ultimo anno. Un’indagine Gartner su 302 responsabili della cybersicurezza, condotta fra marzo e maggio 2025, stabilisce che il 69 per cento sospetta o ha prova diretta che i dipendenti usino strumenti pubblici di IA generativa espressamente vietati. Quasi nessuno di questi strumenti è mai passato da una verifica di governance. La difficoltà è strutturale. L’IA arriva incorporata in software già acquistato, attraverso API di terzi e tramite acquisti individuali che non transitano mai da un ufficio acquisti. I sistemi agentici peggiorano il quadro: un agente che invoca altri modelli e opera su più applicazioni non ha un punto di registrazione unico. Il nostro articolo sull’IA ombra descrive le tecniche di individuazione. Il controllo: individuazione continua abbinata a un registro indicizzato per caso d’uso, titolare aziendale, ruolo regolamentare, classe di rischio e fase del ciclo di vita. I dati di acquisto e le note spese sono una prima fonte migliore di una scansione di rete, perché l’IA ombra si compra più di quanto si installi. L’artefatto: un estratto datato dell’inventario, consegnabile senza ritocchi.
Blocco 3: la responsabilità si frammenta lungo la catena del valore
Qui sta il meccanismo che produce il blocco 1, ed è quello che quasi nessuna pubblicazione affronta. Gli obblighi non gravano su una sola impresa. Si distribuiscono fra il fornitore del modello per finalità generali, il fornitore del sistema che vi costruisce sopra e il deployer che lo utilizza in un contesto determinato. The Future Society chiama questo il problema delle molte mani: la responsabilità si offusca proprio perché i tre attori differiscono per risorse, competenze e informazioni contestuali, e nessuno ne possiede abbastanza per assolvere da solo il dovere. Il regolamento è esplicito sull’attribuzione dei ruoli. L’articolo 3, punto 4 definisce il deployer come la persona fisica o giuridica che utilizza un sistema di IA sotto la propria autorità, al di fuori di un’attività personale non professionale. L’articolo 2, paragrafo 1, lettera a) raggiunge i fornitori che immettono sistemi sul mercato dell’Unione a prescindere dal luogo di stabilimento, e la lettera b) i deployer stabiliti o situati nell’Unione. L’articolo 25 trasforma poi un deployer in fornitore quando appone il proprio nome o marchio su un sistema ad alto rischio, oppure lo modifica sostanzialmente. È su quest’ultimo punto che le organizzazioni restano impigliate. Una messa a punto del modello, un cambio di finalità prevista o l’adozione del proprio marchio possono farvi passare da deployer a fornitore, con un carico di obblighi assai più gravoso. I team che costruiscono su modelli di IA varcano spesso quella linea senza annotarlo. Il controllo: una qualificazione scritta del ruolo per ciascun sistema, rifatta a ogni modifica sostanziale, con ripartizione contrattuale dei doveri a monte anziché presunta. L’artefatto: la scheda di qualificazione del ruolo, motivata e datata.
Blocco 4: la sorveglianza umana si progetta, non si dichiara
Quasi tutti i programmi rivendicano un essere umano nel ciclo. Pochi sanno descrivere cosa quella persona possa davvero fare, il che colloca la sorveglianza fra le sfide della governance dell’IA che emergono soltanto in sede di audit. Il regolamento non si accontenta della dichiarazione. L’articolo 14, paragrafo 1 impone che i sistemi ad alto rischio siano progettati e sviluppati in modo da poter essere «efficacemente supervisionati da persone fisiche» durante il periodo di utilizzo, anche mediante interfacce uomo-macchina adeguate. La parola che conta è efficacemente. Il paragrafo 3 scinde poi il dovere: le misure di sorveglianza sono integrate nel sistema dal fornitore prima dell’immissione sul mercato, oppure individuate dal fornitore e attuate dal deployer. I programmi raccolgono sistematicamente il primo ramo e non eseguono mai il secondo. Il fornitore consegna un pulsante di arresto, il deployer non attribuisce ad alcuno il potere di premerlo, e la sorveglianza esiste solo nello schema architetturale. La distinzione fra human-in-the-loop e human-on-the-loop rileva qui, poiché le due configurazioni comportano requisiti diversi di competenza e di organico. Il controllo: una scheda di progettazione della sorveglianza che indichi il ruolo, la competenza richiesta, il potere di intervenire o arrestare, il tempo entro cui la persona deve poter agire e il registro che documenta ogni intervento. L’artefatto: registri di intervento che attestino almeno un’attivazione, oppure la spiegazione documentata del perché non ve ne sia stato bisogno.
Blocco 5: l’alfabetizzazione all’IA è già un obbligo
Di tutte le sfide della governance dell’IA, questa è quella che più spesso viene rinviata all’anno successivo. A torto. L’articolo 4 si applica dal 2 febbraio 2025 e l’Omnibus digitale non lo ha toccato. Il testo è breve e il perimetro ampio. Fornitori e deployer «adottano misure per garantire, nella misura del possibile, un livello sufficiente di alfabetizzazione in materia di IA del loro personale e delle altre persone che si occupano del funzionamento e dell’utilizzo dei sistemi di IA per loro conto», tenendo conto delle conoscenze tecniche, dell’esperienza, della formazione, del contesto d’uso e delle persone sulle quali i sistemi sono impiegati. L’articolo 3, punto 56 definisce tale alfabetizzazione come le competenze, le conoscenze e la comprensione che consentono un impiego informato e la consapevolezza dei rischi. Osservate ciò che la norma non dice. Non riguarda soltanto i sistemi ad alto rischio, né i soli profili tecnici. Raggiunge chiunque utilizzi o faccia funzionare IA per vostro conto, appaltatori compresi. Le risorse non seguono. Grant Thornton rileva che il 34 per cento dei responsabili finanziari giudica insufficienti i fondi destinati alla formazione, e che il personale operativo (37 per cento) e i quadri intermedi (30 per cento) sono le popolazioni con maggiore bisogno di supporto, esattamente quelle coperte dall’articolo. Il controllo: formazione per ruolo, mappata sui sistemi che ciascun ruolo tocca davvero, aggiornata quando il sistema cambia anziché una volta l’anno. L’artefatto: registri di partecipazione e di apprendimento legati a persone nominate e a sistemi nominati.
Blocco 6: la prova non è recuperabile
Un’organizzazione può possedere ogni controllo e non superare un audit, perché possedere un controllo e dimostrarlo sono attività distinte. Il recupero delle prove è il meno discusso dei sette blocchi e quello che con maggiore probabilità verrà messo alla prova per primo. I numeri del 2026 sono severi. Il 78 per cento dei dirigenti non si dichiara fiducioso di superare un audit indipendente di governance dell’IA entro 90 giorni. La metà delle organizzazioni interpellate da Kiteworks non riesce a produrre un registro completo degli accessi all’IA entro un giorno lavorativo. Solo il 33 per cento mantiene piste di controllo inalterabili, e il 63 per cento ha subito conseguenze di conformità legate a lacune di governance nell’arco di dodici mesi. Merita un nome anche uno schema affine: il 61 per cento colloca la sovranità dei dati in cima alle proprie sfide di conformità, ma solo il 29 per cento la impone con un meccanismo tecnico. Una politica dichiarata senza punto di applicazione non produce alcuna prova. Il tempo di recupero è la misura che conta. Una prova che richiede tre settimane di assemblaggio è, dal punto di vista di una richiesta dell’autorità, una prova che non avete. Le nostre guide all’audit dell’IA e alla documentazione dei sistemi di IA descrivono ciò che le autorità di vigilanza del mercato chiedono davvero; in Italia concorrono AgID, l’Agenzia per la cybersicurezza nazionale e il Garante per la protezione dei dati personali, secondo l’uso considerato. Il controllo: legare ogni prova al controllo specifico che dimostra nel momento in cui viene generata, e congelare istantanee immodificabili della configurazione a ogni variazione di un parametro rilevante. L’artefatto: un registro controllo-prova con un tempo di recupero misurato.
Blocco 7: la governance procede più lentamente dell’adozione
L’ultimo dei sette blocchi è quello che, in silenzio, genera gli altri sei. Quando il percorso di governance richiede otto settimane e il business attende una risposta in cinque giorni, i team lo aggirano, e ogni aggiramento diventa l’IA ombra di domani. Non è un costo soltanto teorico. Grant Thornton stabilisce che il 46 per cento delle organizzazioni indica le carenze di governance e conformità fra le cause principali di sottoperformance o fallimento dell’IA, davanti alla formazione insufficiente (31 per cento) e alla scarsa maturità dei dati (23 per cento). L’attrito di governance è il maggior contributo nominato al mancato funzionamento dell’IA. La risposta abituale, aggiungere revisori, peggiora la situazione. La soluzione si chiama proporzionalità. Il controllo: uno sportello d’ingresso a più livelli, in cui un caso d’uso a basso rischio documentato viene deciso in pochi giorni a fronte di un insieme ridotto di requisiti, e in cui solo i sistemi che superano una soglia di classificazione entrano nella valutazione completa. Affiancate una libreria di controlli riutilizzabili, perché il decimo sistema erediti il lavoro fatto sul primo. La nostra guida al rischio dell’IA spiega come tarare i livelli. L’artefatto: il tempo che intercorre fra deposito e decisione, tracciato per livello e riportato accanto agli indicatori di conformità.
Affrontare le sfide della governance dell’IA in 90 giorni
Volerle affrontare tutte insieme è il modo più sicuro di far arenare un programma. Le dipendenze corrono in una sola direzione. Giorni 1-30. Vedere. Costruite l’inventario e qualificate i ruoli dei sistemi già in produzione. Nulla a valle è possibile senza questi due mattoni, e gran parte del lavoro si svolge sui documenti, a partire dai dati di acquisto e dalle note spese. Giorni 31-60. Rispondere. Nominate un responsabile per ciascun sistema, insediate l’organo decisionale con potere di arresto e chiudete i due obblighi già esigibili: la formazione all’IA per i ruoli coinvolti e le schede di progettazione della sorveglianza per ogni sistema che decide o orienta una decisione riguardante una persona. Giorni 61-90. Dimostrare. Collegate i controlli alle prove, misurate il tempo di recupero rispetto a un obiettivo di un giorno lavorativo e provate un audit simulato sui tre sistemi più esposti. Tarate poi i livelli dello sportello sulla base di ciò che la prova ha rivelato sull’attrito reale. I riferimenti normativi servono a questo punto, non in partenza. La ISO/IEC 42001 fornisce la forma del sistema di gestione e il NIST AI RMF il vocabolario del rischio, ma nessuno dei due sostituisce il sapere che cosa avete in esercizio e chi ne risponde.
Domande frequenti
Qual è la principale sfida della governance dell’IA? La responsabilità non assegnata. La maggior parte delle organizzazioni dispone di un comitato di indirizzo ma di nessuna persona nominativamente responsabile di un dato sistema, sicché nessuno ha l’autorità di fermare un rilascio. L’indagine Grant Thornton 2026 mostra che solo il 48 per cento dei consigli ha formulato aspettative in materia. Un comitato si riunisce, non risponde. La scadenza del regolamento sull’IA per l’alto rischio è stata davvero rinviata? Sì. Il regolamento (UE) 2026/1744, l’Omnibus digitale sull’IA, è entrato in vigore il 27 luglio 2026 e ha rinviato al 2 dicembre 2027 gli obblighi sui sistemi ad alto rischio autonomi dell’allegato III e al 2 agosto 2028 quelli sull’IA incorporata nei prodotti dell’allegato I. Le pratiche vietate, l’alfabetizzazione dell’articolo 4, i doveri sui modelli per finalità generali e la trasparenza dell’articolo 50 non sono stati rinviati. Da quali sfide della governance dell’IA conviene iniziare? Dall’inventario e poi dalla responsabilità, in quest’ordine, perché le altre cinque vi si appoggiano. Non si assegna un responsabile a un sistema non censito, non si qualifica un ruolo regolamentare senza un responsabile che decida, e non si produce una prova per un controllo mai assegnato. Distorsioni e spiegabilità contano, ma sono problemi a valle. Chi risponde, il fornitore o il deployer? Entrambi, con doveri distinti. Il fornitore porta gli obblighi di progettazione, fra cui l’integrazione delle capacità di sorveglianza e la fornitura delle istruzioni per l’uso. Il deployer porta i doveri operativi. L’articolo 25 trasforma un deployer in fornitore se appone il proprio marchio su un sistema ad alto rischio o lo modifica sostanzialmente, cosa che una semplice messa a punto può innescare. Come si costruisce un inventario se nessuno dichiara i propri strumenti? Partite dalla spesa, non dalla rete. Dati di acquisto, note spese e abbonamenti SaaS fanno emergere più IA ombra di una scansione, perché essa si compra più di quanto si installi. Incrociate con i registri di identità e di gateway, poi subordinate il mantenimento dell’accesso alla registrazione. Kiteworks riporta il 65 per cento di scoperte in dodici mesi: date per assodato il divario anziché verificarne l’esistenza. La formazione all’IA è davvero obbligatoria? Sì, ai sensi dell’articolo 4 del regolamento sull’IA, applicabile dal 2 febbraio 2025. Riguarda fornitori e deployer, non si limita ai sistemi ad alto rischio e copre il personale così come chiunque faccia funzionare IA per vostro conto, appaltatori inclusi. La misura è proporzionata al ruolo, alle conoscenze tecniche e al contesto, sicché un modulo online annuale e uniforme difficilmente vi soddisferà.
Conclusione
Le sfide della governance dell’IA che fanno arenare i programmi nel 2026 non sono quelle di cui parla il mercato. Non sono l’accuratezza dei modelli né le distorsioni algoritmiche prese in astratto. Sono una decisione senza titolare, un sistema non censito, un ruolo non qualificato, una sorveglianza che nessuno può esercitare, un obbligo di formazione già in vigore, una prova che richiede tre settimane per essere ricomposta e un processo tanto lento che il business lo evita. Ciascuna richiede un controllo, e ogni controllo un artefatto. L’Omnibus digitale ha regalato sedici mesi sull’alto rischio e nulla su ciò che si applica già. Trattare questa finestra come tempo di preparazione anziché come una pausa fa tutta la differenza. Partite da ciò che avete in esercizio e da chi ne risponde, poi costruite da lì la catena di prova della conformità dell’IA.