Il 2026 porta con sé un paradosso: mentre l’Europa ha concesso più tempo per adeguare i sistemi di IA ad alto rischio, alle imprese resta meno tempo per capire quale intelligenza artificiale stiano già usando.
Dal 2 agosto l’AI Act è nella fase di enforcement e sono operative le regole di trasparenza dell’art. 50; l’AI Omnibus (Reg. UE 2026/1744) ha però rinviato gli obblighi high-risk al 2 dicembre 2027 e, per i sistemi incorporati nei prodotti regolamentati, al 2 agosto 2028.
Il rischio è leggere il rinvio come una pausa. Una scadenza può essere differita; l’esposizione operativa esiste dal giorno in cui un modello entra in un processo aziendale.
Indice degli argomenti
Governance dell’AI: l’inventario è la prima falla
Molte organizzazioni censiscono l’AI come un software: prodotto, fornitore, licenza, owner. Non basta. L’AI può essere dentro strumenti di produttività, CRM, recruiting, antifrode, analisi documentale, assistenti di coding e piattaforme cloud acquistate senza un progetto formalmente qualificato come “AI”.
Prima ancora di chiedersi se un sistema ricada nell’Allegato III, occorre sapere dove opera, con quali dati, per quale decisione e con quale grado di autonomia. Qui la compliance a silos produce un effetto curioso: la stessa applicazione compare nel registro privacy, nell’asset inventory del CISO, nel vendor register del procurement e, domani, nel registro AI, con descrizioni e owner differenti. Ogni documento può essere corretto; l’insieme può essere managerialmente inutile.
Un record sorgente per le valutazioni specialistiche
La controtesi è seria: AI Act, GDPR e NIS2 hanno perimetri e responsabilità differenti, e fonderli può confondere obblighi distinti. È vero: un registro comune non sostituisce una DPIA, un risk assessment NIS2 o la documentazione prevista dall’AI Act.
Mantenere tre motori di governance indipendenti resta però superfluo. Basta un “record sorgente” del sistema (finalità, provider, versione, dati, API, dipendenze, owner, log, criticità) da cui far discendere le diverse valutazioni specialistiche.
Dalla compliance al rischio reale nella governance dell’AI
L’AI Act offre la grammatica del rischio: per i sistemi high-risk, gli artt. 9, 12 e 14 ruotano attorno a risk management, logging e human oversight; l’art. 26 disciplina obblighi dei deployer. Il GDPR aggiunge accountability, data protection by design, sicurezza e, quando ricorrono i presupposti, DPIA. La NIS2 impone misure proporzionate su incidenti, continuità, supply chain, sviluppo sicuro, vulnerabilità e verifica dell’efficacia dei controlli; l’art. 20 porta l’organo di gestione dentro l’approvazione e la supervisione delle misure.
I failure mode oltre i confini normativi
Nessuna di queste norme, da sola, descrive però il failure mode di un sistema AI inserito in un processo critico. Un modello può essere disponibile ma produrre output manipolati; può rispettare lo SLA e subire prompt injection; può non violare il GDPR e dipendere da una API esterna la cui indisponibilità blocca un servizio.
OWASP colloca tra i rischi specifici prompt injection, disclosure di informazioni sensibili, supply chain e data/model poisoning. ENISA propone da tempo una lettura multilivello: fondazioni cyber, rischi AI-specific e requisiti settoriali. È ciò che manca quando compliance e sicurezza procedono separate.
Governance dell’AI nei processi critici: un caso concreto
Si immagini un’impresa soggetta a NIS2 che introduce un assistente generativo per analizzare ticket, documenti tecnici e procedure. Procurement valida il fornitore, legal negozia il contratto, il DPO esamina il trattamento, IT abilita il servizio. Dopo pochi mesi, l’assistente accede a repository interni e suggerisce remediation, ma nessuno ha definito chi possa sospenderlo, quali log conservare o come reagire a un aggiornamento del modello.
Per fare danni basta molto meno di un incidente spettacolare: un output errato inserito in una modifica infrastrutturale, una risposta costruita su dati obsoleti, la compromissione di un componente esterno. A quel punto “chi era responsabile?” è la domanda tardiva. Quella utile era: chi possedeva il rischio e quali evidenze dimostravano che i controlli funzionavano?
Dai documenti alle evidenze
Qui la documentazione smette di essere burocrazia. Se registro AI, risk assessment, vendor assessment, accessi, logging, incident response e business continuity non sono collegati, l’organizzazione accumula documenti senza costruire evidenza. Una policy priva di tracce verificabili dell’applicazione resta una dichiarazione d’intenti.
Supply chain e dipendenze nel governo dell’AI
Il rischio AI va oltre il modello e investe la dipendenza da provider, dataset, librerie, API, componenti open source, cloud e configurazioni che possono cambiare più velocemente dei cicli di audit. La NIS2 rende la supply chain un oggetto esplicito di gestione del rischio. Nel Threat Landscape 2025, ENISA descrive l’AI sia come moltiplicatore delle capacità offensive sia come nuovo punto di esposizione, includendo attacchi alla supply chain dei modelli e dei componenti.
Il contratto non trasferisce il rischio
Il contratto, quindi, non trasferisce magicamente il rischio. Per un servizio AI contano disponibilità dei log, uso dei dati per training, subfornitori, modifiche del modello, tempi di notifica, supporto forense, cancellazione dei dati ed exit strategy. Se il vendor può cambiare una componente rilevante senza che il cliente riesca a rilevarne l’impatto, la conformità contrattuale può convivere con una governance debole.
AI e cybersecurity nello stesso disegno europeo
La Commissione europea ha reso questa convergenza esplicita con l’Action Plan on Cybersecurity and Artificial Intelligence del 7 luglio 2026: valutazione dei modelli, testing sicuro nei settori critici e uso dell’AI per accelerare detection e gestione delle vulnerabilità entrano nello stesso disegno di resilienza. Per la Commissione, dunque, l’AI entra a pieno titolo nella strategia cyber, come parte della superficie di rischio e, al tempo stesso, degli strumenti di difesa.
Un solo ciclo di governance per AI e cyber resilience
Più che l’ennesimo framework, serve un ciclo comune con output diversi: censire ogni sistema AI come asset socio-tecnico; classificare insieme impatto su diritti, continuità, dati, sicurezza e dipendenza dal fornitore; assegnare un owner di business e responsabilità tecniche; collegare i controlli a evidenze (log, test, versioni, approvazioni, eccezioni, incidenti) e imporre un riesame quando cambiano modello, finalità, dati, provider o autonomia.
Le domande che il board deve porre
Anche il board deve cambiare domanda. Al posto di “siamo conformi?”, conviene chiedersi: quanti sistemi AI operano nei processi critici? Quanti non hanno logging adeguato? Quali dipendenze non hanno alternative? Quanti sistemi non dispongono di una procedura di sospensione testata? È una logica coerente con NIST AI RMF, che struttura il rischio in Govern, Map, Measure e Manage, e con ISO/IEC 42001 come riferimento organizzativo. Nessuno standard, però, sostituisce la decisione su quali rischi accettare e quali controlli dover dimostrare.
Tempo normativo e maturità organizzativa
Il rinvio degli obblighi high-risk offre tempo normativo, non immunità organizzativa. Chi lo userà per produrre documenti arriverà alla scadenza con più carta. Chi lo userà per integrare inventario, risk management, cyber resilience, privacy e vendor governance arriverà con qualcosa di raro: la capacità di spiegare, provare e correggere come l’AI viene governata.
La domanda decisiva non è se l’impresa utilizzi l’AI. È se, quando qualcosa cambia o va storto, sappia dimostrare chi aveva il controllo.
Fonti e note
- Unione europea, Regolamento (UE) 2024/1689 – AI Act, testo consolidato al 27 luglio 2026, in particolare artt. 9, 12, 14, 26, 50 e 113.
- Commissione europea, Commission starts enforcing AI Act rules and new transparency requirements on 2 August, 31 luglio 2026.
- Unione europea, Regolamento (UE) 2026/1744 – Digital Omnibus on AI, 8 luglio 2026, in vigore dal 27 luglio 2026: nuove date di applicazione degli obblighi high-risk (2 dicembre 2027 per l’Allegato III, 2 agosto 2028 per l’Allegato I).
- Unione europea, Direttiva (UE) 2022/2555 – NIS2, artt. 20 e 21, governance, risk management, continuità e supply chain.
- EDPB, Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models, 17 dicembre 2024.
- ENISA, Multilayer Framework for Good Cybersecurity Practices for AI, 7 giugno 2023.
- ENISA, Threat Landscape 2025, 1 ottobre 2025, versione aggiornata gennaio 2026.
- Commissione europea, EU Action Plan on Cybersecurity and Artificial Intelligence, 7 luglio 2026.
- NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0) – NIST AI 100-1, gennaio 2023, e Generative Artificial Intelligence Profile – NIST AI 600-1, luglio 2024.
- OWASP GenAI Security Project, OWASP Top 10 for LLM Applications 2025.
- ISO, ISO/IEC 42001:2023 – Information technology — Artificial intelligence — Management system.
Partecipa alla community