NIS2 e sistemi AI ad alto rischio: quando cybersecurity e AI governance si incrociano
Una guida pratica per Data Controller, responsabili organizzativi e Data Processor che vogliono capire quando i due perimetri normativi possono sovrapporsi e quali verifiche conviene avviare.
NIS2 e sistemi AI ad alto rischio: quando cybersecurity e AI governance si incrociano
Due perimetri diversi che possono incontrarsi
Prima verifica: siamo un soggetto NIS2?
Seconda verifica: il sistema AI è davvero “ad alto rischio”?
Dove l’incrocio è più probabile
Tabella di incrocio NIS2 – AI Act
Cosa cambia quando i due perimetri si sovrappongono
- La cybersecurity dell’AI entra nel risk management
- Governance e sorveglianza umana diventano operative
- Incidenti: evitare due procedure che non comunicano
Il ruolo dell’organizzazione: spesso deployer, ma non sempre
FRIA e DPIA: attenzione a non confonderle
Fornitori, supply chain e responsabilità
Una checklist operativa per partire
Conclusioni: il vero tema è la convergenza della governance
Nota sulle fonti e sulle tempistiche
Due perimetri diversi che possono incontrarsi
NIS2 e AI Act nascono per governare rischi differenti. La disciplina NIS2 guarda alla sicurezza delle reti e dei sistemi informativi e alla continuità dei servizi di soggetti che operano in settori considerati critici o rilevanti. L’AI Act, invece, costruisce un quadro di regole per i sistemi di Intelligenza Artificiale e prevede obblighi particolarmente rigorosi per quelli classificati ad alto rischio.
L’incrocio nasce quando la stessa organizzazione rientra nel perimetro NIS2 e, contemporaneamente, utilizza o mette in servizio un sistema AI che ricade nelle categorie ad alto rischio. In quel momento non nasce una “terza normativa”: si sovrappongono obblighi diversi, che devono essere letti in modo coordinato.
Per un Data Controller questo passaggio è particolarmente interessante. Molti sistemi AI ad alto rischio incidono infatti su persone fisiche – lavoratori, candidati, clienti, utenti di servizi essenziali – e possono quindi coinvolgere, oltre a NIS2 e AI Act, anche GDPR, sicurezza informatica, gestione dei fornitori e responsabilità organizzative.
Prima verifica: siamo un soggetto NIS2?
Il primo errore da evitare è partire dall’AI. Prima bisogna capire se l’organizzazione rientra effettivamente nel perimetro NIS2 come soggetto essenziale o importante secondo la disciplina applicabile e la relativa identificazione nazionale. La Direttiva distingue le due categorie in funzione del settore, della tipologia di servizio, delle dimensioni e di specifiche ipotesi di inclusione.
Energia, trasporti, sanità, acqua, infrastrutture digitali, pubblica amministrazione e numerosi servizi ICT sono tra gli ambiti più evidenti; l’Allegato II comprende inoltre altri settori, tra cui alcune attività manifatturiere, gestione dei rifiuti, servizi postali e produzione o distribuzione di alimenti.
Essenziale e importante non significa, però, “più o meno obbligato” in senso semplicistico. Le misure di gestione del rischio cyber riguardano entrambe le categorie; cambia soprattutto il regime di supervisione. Per i soggetti essenziali la vigilanza può essere sia ex ante sia ex post, mentre per i soggetti importanti è principalmente reattiva ed ex post.
Seconda verifica: il sistema AI è davvero “ad alto rischio”?
Essere soggetti NIS2 non rende automaticamente ad alto rischio tutti i sistemi AI utilizzati dall’organizzazione. Allo stesso modo, operare in un settore sensibile non basta da solo per classificare un sistema come high-risk.
La classificazione dell’AI Act richiede di verificare lo scopo previsto del sistema e il percorso applicabile. In sintesi, un sistema può essere ad alto rischio perché costituisce un prodotto o una componente di sicurezza di prodotti disciplinati dalla normativa armonizzata richiamata nell’Allegato I, oppure perché ricade in uno degli specifici casi d’uso dell’Allegato III.
L’Allegato III comprende, tra gli altri, determinati utilizzi in biometria, infrastrutture critiche, istruzione e formazione professionale, occupazione e gestione dei lavoratori, accesso a servizi essenziali, attività di contrasto, migrazione e amministrazione della giustizia. Non tutto ciò che contiene AI in questi settori è automaticamente high-risk: occorre verificare lo specifico caso d’uso e le regole di classificazione dell’articolo 6.
Un’ulteriore attenzione è oggi necessaria sulle tempistiche. Il Digital Omnibus on AI del 2026 ha modificato il calendario: le sezioni del Capo III relative ai sistemi high-risk dell’Allegato III si applicheranno dal 2 dicembre 2027; per i sistemi high-risk collegati ai prodotti dell’Allegato I la data è il 2 agosto 2028. Questo non significa aspettare: classificazione, inventario e governance richiedono tempo e conviene prepararli prima.
Dove l’incrocio è più probabile
Il documento di partenza evidenziava correttamente alcuni settori nei quali la sovrapposizione è intuitiva: infrastrutture critiche, salute, servizi digitali, pubblica amministrazione, manifattura e gestione del personale. La verifica delle fonti suggerisce però di evitare equivalenze automatiche. Il punto non è associare un settore NIS2 a una categoria AI, ma individuare il concreto sistema e il suo utilizzo.
Tabella di incrocio NIS2 – AI Act
| Area | Possibile perimetro NIS2 | Esempio AI high-risk | Punto di attenzione |
| Infrastrutture critiche | Energia, trasporti, acqua e altre entità NIS2 pertinenti | AI come componente di sicurezza nella gestione di infrastrutture digitali critiche, traffico stradale, acqua, gas, riscaldamento o elettricità | Incrocio diretto possibile: continuità, resilienza e cybersecurity diventano centrali. |
| Sanità | Ospedali, strutture sanitarie e soggetti della filiera ricompresi nel perimetro | AI per triage/emergenza; AI high-risk incorporata in dispositivi medici quando ricorrono le condizioni dell’art. 6(1) | Oltre alla cybersecurity possono emergere sicurezza del paziente, GDPR e supervisione umana. |
| Servizi digitali e ICT | Cloud, data center, DNS, MSP/MSSP e altri soggetti previsti | Biometria high-risk solo nei casi specifici dell’Allegato III; altri sistemi possono essere high-risk in base allo scopo | Non confondere il fatto di essere provider digitale con la classificazione high-risk dell’AI. |
| Pubblica amministrazione / servizi pubblici | PA e soggetti privati che forniscono servizi pubblici, se rientranti nei rispettivi perimetri | Accesso a prestazioni o servizi essenziali; altri casi dell’Allegato III | Possibile rilevanza della FRIA, oltre a DPIA quando ricorrono i presupposti GDPR. |
| Manifattura | Specifiche attività manifatturiere dell’Allegato II NIS2 | AI come componente di sicurezza di macchine, veicoli, ascensori o altri prodotti dell’Allegato I, se ricorrono le condizioni | Incrocio soprattutto tra sicurezza del prodotto, cybersecurity e gestione del ciclo di vita. |
| Risorse umane – trasversale | Qualunque soggetto NIS2 che impieghi personale | AI per recruiting, selezione, promozione, assegnazione compiti, monitoraggio o cessazione del rapporto nei casi previsti | È uno degli incroci più facili da sottovalutare: il sistema HR può essere high-risk anche se non riguarda il servizio “core” NIS2. |
| Finanza | Alcuni soggetti sono nel quadro NIS2, ma per molte entità finanziarie DORA opera come lex specialis sui requisiti cyber equivalenti | Credit scoring di persone fisiche e pricing/risk assessment in assicurazioni vita e salute | Serve prima verificare il rapporto NIS2-DORA; evitare di applicare meccanicamente la NIS2 dove opera la disciplina settoriale. |
Cosa cambia quando i due perimetri si sovrappongono
1. La cybersecurity dell’AI entra nel risk management
L’articolo 21 NIS2 richiede misure tecniche, operative e organizzative appropriate e proporzionate per gestire i rischi alla sicurezza dei sistemi di rete e informativi utilizzati nelle operazioni o nell’erogazione dei servizi. La logica non si limita al singolo server o al servizio critico: riguarda il sistema di gestione del rischio cyber dell’entità.
Se un sistema AI rilevante entra nell’architettura aziendale, deve quindi essere considerato nella mappatura di asset, dipendenze, accessi, fornitori, vulnerabilità, continuità e risposta agli incidenti. Per i sistemi AI ad alto rischio, l’articolo 15 dell’AI Act aggiunge inoltre requisiti specifici di accuratezza, robustezza e cybersecurity lungo il ciclo di vita.
Il rischio AI presenta anche vettori caratteristici: manipolazione dei dati, attacchi avversari, vulnerabilità dei modelli e degli input, compromissione delle integrazioni, dipendenza da fornitori e alterazione degli output. Non serve creare due mondi separati: la scelta più razionale è integrare questi rischi nel framework cyber già esistente, mantenendo evidenza delle specificità AI.
2. Governance e sorveglianza umana diventano operative
Quando l’organizzazione opera come deployer di un sistema high-risk, l’AI Act richiede misure tecniche e organizzative per utilizzare il sistema secondo le istruzioni, assegnare la sorveglianza umana a persone con competenza, formazione e autorità adeguate, monitorare il funzionamento e conservare i log quando sono sotto il controllo del deployer.
Per un soggetto NIS2 questo si collega naturalmente alla governance della sicurezza: ruoli, escalation, responsabilità e competenze non possono essere lasciati impliciti. Chi controlla il sistema? Chi può sospenderlo? Chi verifica un output anomalo? Chi coinvolge il provider? Chi gestisce l’eventuale incidente cyber e chi valuta gli effetti sulle persone?
3. Incidenti: evitare due procedure che non comunicano
Un incidente che coinvolge un sistema AI potrebbe avere contemporaneamente natura cyber, impatto sul funzionamento del sistema, conseguenze sui diritti delle persone e, se sono coinvolti dati personali, anche rilievo GDPR. I diversi regimi hanno definizioni, soglie, destinatari e tempistiche proprie: non vanno confusi, ma neppure gestiti in silos.
Una buona procedura interna dovrebbe prevedere un unico punto di ingresso dell’evento e poi una classificazione: incidente NIS2? serio incidente AI? data breach GDPR? problema di sicurezza del prodotto? Da questa matrice possono partire flussi distinti ma coordinati.
Il ruolo dell’organizzazione: spesso deployer, ma non sempre
Nel documento di partenza si ipotizzava che i soggetti NIS2 agissero nella maggior parte dei casi come deployer. È una situazione frequente, ma non può essere data per scontata. Un’organizzazione può anche sviluppare un sistema, farlo sviluppare e commercializzarlo con il proprio nome, modificarne sostanzialmente la destinazione d’uso o assumere altri ruoli previsti dall’AI Act.
La prima domanda organizzativa dovrebbe quindi essere: “Qual è il nostro ruolo rispetto a questo specifico sistema?”. Gli obblighi cambiano sensibilmente tra provider e deployer. La classificazione del ruolo deve precedere la checklist di conformità.
FRIA e DPIA: attenzione a non confonderle
Un punto del documento di partenza richiede una correzione importante: la Fundamental Rights Impact Assessment (FRIA) non è obbligatoria per tutti i deployer di sistemi AI ad alto rischio.
L’articolo 27 la richiede, prima del primo utilizzo, per determinate categorie: in particolare organismi di diritto pubblico, soggetti privati che forniscono servizi pubblici e deployer di specifici sistemi dell’Allegato III relativi al credit scoring e alla valutazione del rischio/prezzo nelle assicurazioni vita e salute. Sono inoltre previste eccezioni, tra cui i sistemi high-risk dell’area infrastrutture critiche indicata al punto 2 dell’Allegato III.
La DPIA GDPR segue invece presupposti differenti: diventa necessaria quando un trattamento di dati personali può presentare un rischio elevato per i diritti e le libertà delle persone. AI Act e GDPR prevedono però un raccordo: quando pertinente, le informazioni della documentazione AI possono supportare la DPIA e la FRIA può richiamare o integrare parti della valutazione privacy. L’obiettivo dovrebbe essere evitare duplicazioni senza confondere finalità e basi normative.
Fornitori, supply chain e responsabilità
NIS2 dedica particolare attenzione alla sicurezza della catena di approvvigionamento e ai rapporti con fornitori e prestatori di servizi. L’adozione di AI rende questo punto ancora più concreto: il sistema può dipendere da cloud, API, modelli esterni, database, componenti software e servizi di monitoraggio.
Per il Data Controller il tema non è soltanto sapere chi tratta dati personali come Responsabile ai sensi dell’articolo 28 GDPR. Occorre costruire una vista più ampia: chi fornisce l’AI? dove viene eseguita? quali subfornitori intervengono? quali dati e log transitano? quali dipendenze operative esistono? quali obblighi contrattuali sono previsti per sicurezza, incidenti, aggiornamenti e cooperazione?
La stessa controparte può quindi essere contemporaneamente un fornitore ICT rilevante per NIS2, un Responsabile del trattamento GDPR e un provider o altro operatore della catena AI. Le qualificazioni non si sostituiscono: si sommano quando ne ricorrono i presupposti.
Una checklist operativa per partire
- Confermare formalmente il perimetro NIS2 e la qualifica dell’organizzazione.
- Creare o aggiornare l’inventario dei sistemi AI effettivamente utilizzati, evitando di limitarsi agli strumenti generativi più visibili.
- Per ogni sistema, identificare scopo previsto, processo aziendale, persone coinvolte e ruolo dell’organizzazione ai sensi dell’AI Act.
- Verificare se ricorrono le condizioni dell’articolo 6 e degli Allegati I o III per la classificazione high-risk.
- Mappare il sistema AI nel risk assessment cyber e nella supply chain NIS2, quando pertinente.
- Definire sorveglianza umana, competenze, autorità, monitoraggio e gestione dei log.
- Valutare separatamente la necessità di DPIA GDPR e, nei casi previsti, FRIA AI Act.
- Integrare le procedure di incident management affinché un unico evento possa essere valutato rispetto a NIS2, AI Act e GDPR.
- Rivedere contratti e due diligence dei fornitori considerando contemporaneamente sicurezza, dati personali e ruolo nella catena AI.
- Pianificare formazione e AI Literacy per le persone che utilizzano o sorvegliano i sistemi.
Conclusioni: il vero tema è la convergenza della governance
L’incrocio tra NIS2 e sistemi AI ad alto rischio non dovrebbe essere letto come l’arrivo dell’ennesimo livello di burocrazia. È piuttosto il segnale di una trasformazione: cybersecurity, protezione dei dati e governance dell’Intelligenza Artificiale stanno diventando parti dello stesso sistema di controllo organizzativo.
Per un Data Controller attento alla compliance, il vantaggio consiste nel non costruire tre archivi separati – privacy, cyber e AI – che si incontrano soltanto durante un incidente. Inventari, risk assessment, fornitori, ruoli, formazione e procedure possono essere coordinati, pur mantenendo distinti gli obblighi normativi.
La domanda da portare in azienda diventa quindi molto concreta: siamo in grado di riconoscere quali sistemi AI entrano nei processi rilevanti, quali rischi aggiungono e quali normative si attivano? Se la risposta non è ancora immediata, l’inventario dei sistemi AI e la loro classificazione rappresentano probabilmente il punto da cui partire.
Nota sulle fonti e sulle tempistiche
Il testo è stato verificato alla luce della Direttiva (UE) 2022/2555 (NIS2), del Regolamento (UE) 2024/1689 (AI Act) nel testo consolidato e delle modifiche introdotte dal Regolamento (UE) 2026/1744 (Digital Omnibus on AI). Le date e le classificazioni possono essere interessate da disciplina nazionale, atti settoriali e futuri orientamenti applicativi; per i casi concreti è quindi opportuno verificare sempre il quadro vigente e il ruolo effettivo dell’organizzazione.
