The Compliance Triple Threat: navigare la regulatory collision tra DORA, NIS2 e AI Act

C’è un momento preciso in cui la complessità regolatoria smette di essere un problema dei legal team e diventa un rischio operativo di primo livello. Quel momento è adesso, e la sua geometria è più sottile di quanto molti abbiano compreso.

Con DORA pienamente applicabile dal 17 gennaio 2025, NIS2 recepita negli ordinamenti nazionali con diversi gradi di completezza e l’EU AI Act che ha già reso cogenti il divieto delle pratiche AI inaccettabili (dal 2 febbraio 2025) e gli obblighi sui modelli GPAI (dal 2 agosto 2025), mentre la scadenza principale per i sistemi AI ad alto rischio standalone si avvicina al 2 agosto 2026, le organizzazioni operanti nel mercato unico europeo navigano un paesaggio normativo di complessità inedita.

Regulatory Collision: il nuovo rischio sistemico che i board non hanno ancora prezzato

Il termine “regulatory collision” cattura con precisione la dinamica in gioco: non si tratta di tre obblighi che coesistono ordinatamente in compartimenti separati, ma di tre sistemi normativi che convergono sugli stessi asset, gli stessi processi e gli stessi momenti di crisi, generando regimi di compliance sovrapposti, governati però da logiche di interazione giuridicamente precise e, per molti CISO e board, ancora mal comprese.

Questa imprecisione non è accademica. Costa denaro, tempo e, nei casi peggiori, esposizione personale dei vertici aziendali.

La geometria della sovrapposizione: tre regimi, tre logiche

Per comprendere dove e come le tre normative si intersecano, è necessario mapparne le architetture concettuali fondamentali.

NIS2 (Direttiva 2022/2555) opera su una logica di protezione dell’infrastruttura critica e della continuità dei servizi essenziali e importanti. Il suo baricentro è la resilienza sistemica del tessuto digitale europeo: chi eroga servizi critici deve gestire il rischio cyber in modo strutturato, notificare gli incidenti significativi e rispondere della propria postura di sicurezza lungo tutta la supply chain.

La direttiva estende il perimetro in modo radicale rispetto a NIS1, coprendo in Europa oltre 100.000 entità, e introduce con questa cogenza la responsabilità personale dei vertici aziendali per le violazioni degli obblighi di cybersecurity governance. I settori finanziari figurano esplicitamente nell’Allegato I come entità essenziali. Ma qui entra in gioco un principio giuridico fondamentale che l’analisi non può eludere, come approfondito anche nell’analisi sulla convergenza normativa pubblicata su queste pagine.

DORA (Regolamento 2022/2554) opera su una logica di resilienza operativa digitale specifica per il settore finanziario. È un regolamento, non una direttiva, il che significa applicazione diretta e uniforme in tutti gli Stati membri. Copre 20 categorie di entità finanziarie e stabilisce per ognuna un framework articolato su cinque pilastri: ICT risk management, incident reporting, resilience testing (inclusi i TLPT, i Threat-Led Penetration Testing), gestione del rischio di terze parti ICT e information sharing. Crucialmente, il Considerando 16 di DORA stabilisce: “This Regulation constitutes lex specialis with regard to Directive (EU) 2022/2555.” Questo non è un dettaglio tecnico-giuridico marginale: è la chiave di volta dell’intera architettura di compliance per le entità finanziarie.

L’EU AI Act (Regolamento 2024/1689) opera su una logica di gestione del rischio proporzionale alla pericolosità dei sistemi AI. La classificazione per livelli, pratiche inaccettabili, alto rischio, rischio limitato e rischio minimo, determina gli obblighi applicabili.

Per i sistemi AI ad alto rischio elencati nell’Allegato III, gli obblighi includono: conformità a standard tecnici armonizzati, registrazione in database europei, valutazioni di conformità pre-market, trasparenza e monitoraggio post-mercato (Art. 72) e notifica dei serious incident alle autorità di sorveglianza (Art. 73). Nel settore finanziario, i sistemi AI usati per credit scoring, fraud detection, valutazione del merito creditizio e gestione del rischio ricadono tipicamente nella categoria ad alto rischio dell’Allegato III. La scadenza per conformarsi a questi obblighi è il 2 agosto 2026, a soli quattro mesi dalla presente pubblicazione.

Il principio lex specialis: cosa cambia davvero per le entità finanziarie

Comprendere con esattezza come questi tre framework si intersecano è la competenza più critica che un CISO o un membro del board debbano sviluppare oggi. Ed è qui che molte analisi, anche autorevoli, peccano di imprecisione.

Per le entità finanziarie coperte da DORA, il quadro è il seguente: DORA è lex specialis rispetto a NIS2. Ciò significa che gli obblighi NIS2 in materia di ICT risk management, incident reporting, supervisione e enforcement sono sostituiti da quelli DORA, non cumulabili con essi. Una banca che subisce un incidente ICT grave non è tenuta a effettuare una doppia notifica, una a Banca d’Italia o BCE sotto DORA e una ad ACN/CSIRT Italia sotto NIS2 per il medesimo evento. Notifica sotto DORA all’autorità competente e adempie agli obblighi del Regolamento. La Commissione Europea ha pubblicato nel settembre 2023 apposite linee guida (Decisione C(2023) 6373) sull’applicazione dell’articolo 4(1) e (2) di NIS2, che chiariscono questa interfaccia.

Questo non significa che NIS2 sia irrilevante per le entità finanziarie. La direttiva può ancora applicarsi in aree non coperte da DORA, inclusi alcuni aspetti della supply chain security che esulano dall’ICT, elementi di sicurezza fisica e obblighi di registrazione. Rimane inoltre pienamente applicabile ai fornitori di servizi ICT non designati come Critical Third-Party Providers (CTPP) sotto DORA: la banca può essere esente da certe obbligazioni NIS2, ma il suo cloud provider può esservi pienamente soggetto.

La vera regulatory collision per le entità finanziarie non è dunque DORA contro NIS2 per le stesse obbligazioni: è DORA contro EU AI Act. Due regolamenti, entrambi direttamente applicabili, che convergono sugli stessi asset quando questi sono sistemi AI integrati nelle operazioni finanziarie. Questa sovrapposizione non è risolta da alcun principio di lex specialis: i due regolamenti sono distinti per oggetto e si cumulano, come analizzato in dettaglio anche nella guida alla DORA compliance operativa.

Per i fornitori ICT che servono sia entità finanziarie sia altri settori, e per le entità essenziali non finanziarie come energia, sanità e infrastrutture digitali, la situazione è invece quella del classico schema triple threat: NIS2 si applica interamente e si cumula con l’AI Act se l’entità utilizza sistemi AI nell’erogazione dei servizi critici, e con DORA se fornisce ICT a soggetti finanziari.

Lo scenario del singolo incidente: la collisione reale

Con questa mappa corretta in mente, è possibile seguire la traiettoria di un incidente reale attraverso i framework applicabili.

Si consideri un istituto di credito medio-grande che subisce un attacco alla supply chain, con compromissione di un componente software di un fornitore ICT critico. Il componente è integrato nel sistema di fraud detection basato su machine learning, classificato come sistema AI ad alto rischio ai sensi dell’Allegato III dell’AI Act. L’incidente provoca un’interruzione parziale del servizio di pagamento per quattro ore, con impatto su circa 80.000 clienti.

Sotto DORA, l’entità deve classificare l’incidente come grave se supera le soglie degli RTS adottati dalle ESA, in questo scenario quasi certamente sì, visto l’impatto su clienti, l’interruzione di una funzione critica e il vettore supply chain. La struttura di notifica è articolata in tre fasi: notifica iniziale entro quattro ore dalla classificazione come grave, e comunque entro 24 ore dal rilevamento; report intermedio entro 72 ore dall’invio della notifica iniziale; report finale entro un mese dalla classificazione. Parallelamente, l’entità avvia la procedura di gestione del rischio verso il fornitore ICT compromesso, verificando la conformità contrattuale ai sensi dell’Art. 30 e valutando le strategie di exit.

Sotto l’EU AI Act, il provider e/o il deployer del sistema di fraud detection devono valutare se l’incidente configura un serious incident ai sensi dell’Art. 3(49), ossia un malfunzionamento che ha causato o poteva causare danni significativi. In caso affermativo, la notifica alle autorità di sorveglianza del mercato è obbligatoria ai sensi dell’Art. 73. Il processo di monitoraggio post-mercato (Art. 72) deve documentare l’evento nel registro tecnico del sistema. Devono essere valutati eventuali impatti sulla conformità tecnica del modello: compromissione dei dati di training, alterazione dei parametri, degradazione della performance decisionale.

Sotto NIS2, come chiarito, l’entità finanziaria coperta da DORA è esente dagli obblighi di incident reporting NIS2 per lo stesso evento. La direttiva rimane però rilevante per il fornitore ICT compromesso, che è probabilmente soggetto a NIS2 come entità essenziale o importante nel settore delle infrastrutture digitali, e deve notificare ad ACN/CSIRT Italia entro 24 ore (notifica preliminare), entro 72 ore (notifica completa con valutazione iniziale dell’incidente) e produrre il report finale entro un mese dall’invio della notifica completa.

Questo scenario rivela la complessità reale: non tre notifiche obbligatorie parallele per la stessa entità finanziaria sullo stesso incidente, ma due regimi che si cumulano genuinamente per quell’entità (DORA e AI Act) e un terzo che si applica in modo asimmetrico lungo la supply chain (NIS2 per il fornitore). La gestione di questa asimmetria, sapere esattamente chi deve notificare cosa a chi, in quale sequenza temporale e con quali contenuti, è già sufficientemente complessa da richiedere processi di incident response radicalmente ripensati.

La liability personale: il cambio di paradigma che i board devono metabolizzare

Fino a pochi anni fa, la non conformità normativa in ambito cyber era essenzialmente un rischio organizzativo: sanzioni all’entità, danni reputazionali, contenziosi. I dirigenti potevano mantenere una distanza gestibile tra la propria responsabilità personale e le violazioni tecniche avvenute nelle funzioni operative. Tutti e tre i framework regolatori convergono nel disfare questa distanza.

NIS2, all’Art. 20, stabilisce che gli organi di gestione delle entità essenziali e importanti devono approvare le misure di gestione dei rischi cyber, supervisionarne l’attuazione e seguire una formazione specifica. La responsabilità personale dei membri degli organi di gestione è esplicitamente prevista: l’Art. 32(5) consente alle autorità nazionali di sospendere temporaneamente dirigenti apicali delle entità essenziali e di vietare loro di ricoprire funzioni manageriali nella stessa entità in caso di violazioni gravi. Per le entità importanti, previsioni analoghe sono contenute nell’Art. 33(5). L’Italia ha recepito questa impostazione nel D.Lgs. 138/2024, come documentato nell’analisi sugli adempimenti NIS2 e scadenze 2026.

DORA, all’Art. 5, assegna all’organo di gestione la piena responsabilità del framework di ICT risk management: definirlo, approvarlo, supervisionarne l’attuazione e risponderne. Il Considerando 45 chiarisce che i management body devono mantenere un “ruolo pivotale e attivo” nel guidare il framework di ICT risk management e la strategia di resilienza digitale. L’Art. 5(4) specifica che i membri del management body devono attivamente mantenersi aggiornati con conoscenze e competenze sufficienti per comprendere e valutare il rischio ICT. Non è una buona pratica: è un obbligo giuridico.

L’AI Act, agli Artt. 9 e 17, richiede che i sistemi ad alto rischio siano dotati di sistemi di risk management e quality management supervisionati da persone con la necessaria autorità e responsabilità organizzativa.

Le sanzioni previste dall’Art. 99 si articolano su tre livelli: fino a 35 milioni di euro o il 7% del fatturato globale per le violazioni delle pratiche AI vietate (Art. 5, le fattispecie più gravi, come il social scoring e la sorveglianza biometrica di massa); fino a 15 milioni di euro o il 3% del fatturato globale per le violazioni degli obblighi relativi ai sistemi AI ad alto rischio, che è la fattispecie rilevante per entità finanziarie che utilizzano sistemi di fraud detection o credit scoring; fino a 7,5 milioni di euro o l’1% per le informazioni inesatte o fuorvianti alle autorità.

I singoli dirigenti non sono destinatari diretti delle sanzioni pecuniarie dell’AI Act, ma l’attribuzione di responsabilità organizzativa è sufficientemente specifica da generare esposizioni personali significative nei regimi di responsabilità civile e, in taluni ordinamenti nazionali, penale.

Il CISO che cerca di “portare il rischio cyber al board” non sta più perseguendo una best practice: sta adempiendo a obblighi normativi la cui inosservanza espone i singoli amministratori a conseguenze personali dirette sotto tre distinti framework.

Perché i framework GRC tradizionali non reggono

La risposta istintiva di molte organizzazioni alla complessità regolatoria è stata la costruzione di silo di compliance paralleli. Ogni silo produce la propria documentazione, i propri processi, i propri report. Questo approccio era già subottimale nella fase precedente. Nell’attuale configurazione normativa è strutturalmente inadeguato, per tre ragioni.

La prima è la duplicazione cognitiva del rischio. Un fornitore di servizi cloud che serve entità finanziarie ed è contemporaneamente provider di un sistema AI ad alto rischio è soggetto a DORA (contrattualmente, come fornitore ICT), a NIS2 (direttamente, come entità essenziale nell’infrastruttura digitale) e all’AI Act (come provider di sistemi AI ad alto rischio). Le valutazioni di rischio che alimentano questi tre framework traggono dati dagli stessi asset sottostanti: frammentarle produce incoerenze, contraddizioni documentali e lacune che nessun silo individuale è attrezzato a vedere.

La seconda è la crisi di coordinamento in incidente. Un incidente grave attiva procedure parallele sotto regimi diversi, con scadenze temporali ravvicinate e parzialmente divergenti. Se i team responsabili non sono integrati e non sanno esattamente a chi notificare cosa, l’organizzazione rischia di perdere scadenze, produrre comunicazioni incoerenti verso autorità diverse e creare documentazione post-incidente che potrebbe essere usata contro di essa in sede di enforcement.

La terza è la cecità sistemica sui rischi compositi emergenti. Il punto di intersezione più pericoloso non è negli scenari già noti, ma in quelli non ancora immaginati. Un sistema AI che ottimizza la gestione della liquidità, alimentato da dati provenienti da un fornitore ICT critico, operante su infrastruttura cloud soggetta a NIS2: la compromissione parziale di questo sistema attraversa simultaneamente il perimetro DORA (rischio ICT per un’entità finanziaria), il perimetro AI Act (sistema ad alto rischio compromesso) e il perimetro NIS2 (fornitore infrastrutturale). I GRC tradizionali non sono costruiti per vedere questi rischi compositi prima che si materializzino.

La risposta architetturale necessaria è quella che la letteratura emergente chiama Unified GRC: una struttura in cui il rischio viene valutato una sola volta rispetto a tutti i regimi applicabili, le soglie di escalation sono armonizzate, i processi di notifica coordinati e la documentazione progettata per soddisfare requisiti multipli con il minimo di ridondanza.

L’intelligenza artificiale come moltiplicatore ricorsivo di complessità

C’è un’ironia strutturale nella situazione attuale: le organizzazioni usano sistemi AI per gestire la complessità operativa e di compliance, mentre l’AI Act introduce nuovi obblighi che riguardano, tra le altre cose, proprio i sistemi AI usati nelle funzioni critiche.

Uno strumento di GRC basato su AI che supporta la gestione del rischio operativo di un’entità finanziaria è potenzialmente un sistema ad alto rischio ai sensi dell’AI Act, se supporta decisioni relative alla gestione del rischio o al credito (fattispecie previste nell’Allegato III), e un asset ICT critico ai sensi di DORA, se integrato nei processi operativi dell’entità. Lo strumento usato per gestire la compliance è esso stesso soggetto a compliance multipla. La ricorsività è reale e richiede che le organizzazioni adottino un approccio esplicito alla governance dei sistemi AI interni, non soltanto di quelli esposti verso i clienti.

Più in generale, l’integrazione di AI nelle operazioni critiche amplia la superficie di rischio attraverso vettori nuovi: adversarial attacks sui modelli, data poisoning non rilevato, model drift silenzioso. Crea inoltre dipendenze da fornitori di modelli che rientrano nel perimetro di sorveglianza DORA se classificati come fornitori ICT di terze parti, e nell’oversight diretto delle ESA se designati CTPP. L’AI Act richiede che questi rischi siano documentati e mitigati nel registro tecnico; DORA richiede che le dipendenze contrattuali siano strutturate secondo clausole minime specifiche; NIS2 richiede che la supply chain sia valutata sistematicamente dal fornitore ICT soggetto alla direttiva. Tre framework, tre angolature sul medesimo rischio sottostante, come approfondito anche nell’analisi sull’EU AI Act GPAI.

Un’agenda pratica per CISO e board

Mappatura precisa dei regimi applicabili per tipologia di entità. Il primo passo, prima di qualsiasi gap analysis, è determinare con precisione giuridica quale combinazione di framework si applica alla propria organizzazione: DORA primario con AI Act addizionale per le entità finanziarie che usano AI; NIS2 con AI Act per le entità essenziali non finanziarie che utilizzano sistemi AI; NIS2 e DORA per i fornitori ICT che servono sia financial entities sia altri settori. Questa mappatura non può essere delegata a logica di default: richiede competenza giuridico-regolatoria specifica, tenendo presente che, come illustrato nell’analisi sull’implementazione NIS2 in Europa, la trasposizione nei diversi ordinamenti nazionali introduce ulteriori variabili.

Ridisegno dei piani di incident response per la complessità composita. I playbook di risposta agli incidenti devono essere aggiornati per gestire scenari di rischio composito, identificando per ciascun tipo di evento le obbligazioni di notifica applicabili, le scadenze precise, le autorità destinatarie e le responsabilità assegnate. Per le entità finanziarie: chi notifica sotto DORA, e quali aspetti dell’evento richiedono attivazione parallela degli obblighi AI Act nel caso in cui un sistema AI ad alto rischio sia coinvolto?

Priorità assoluta all’AI Act entro agosto 2026. Per tutte le organizzazioni che utilizzano sistemi AI ad alto rischio (Allegato III), e il settore finanziario è tra i più esposti, la scadenza del 2 agosto 2026 per la piena compliance con gli obblighi di risk management, documentazione tecnica, conformity assessment e monitoraggio post-mercato non è più un orizzonte lontano: al momento della pubblicazione di questo articolo mancano meno di quattro mesi. Le organizzazioni non ancora a regime devono considerarlo una priorità critica e urgente.

Revisione delle clausole contrattuali con fornitori ICT e AI. DORA prescrive requisiti minimi stringenti per i contratti con fornitori ICT critici (Art. 30). L’AI Act aggiunge obblighi specifici nella catena di responsabilità tra provider e deployer. NIS2 richiede valutazioni della supply chain per i fornitori soggetti alla direttiva. Le clausole contrattuali esistenti devono essere revisionate per soddisfare tutti i framework pertinenti alla specifica relazione contrattuale.

Formazione del board come sostanza, non adempimento. NIS2 (Art. 20) e DORA (Art. 5 e Considerando 45) richiedono che i vertici abbiano una comprensione genuina dei rischi ICT e AI. I programmi di board education che si limitano a una sessione annuale superficiale non sono adeguati né normativamente né operativamente. Il board deve comprendere la logica delle tre normative, la natura della loro interazione e le implicazioni della propria liability personale con profondità sufficiente a prendere decisioni informate e a supervisionare attivamente i rischi.

Conclusione: la maturità regolatoria come vantaggio competitivo

La regulatory collision tra DORA, NIS2 e EU AI Act non è un problema temporaneo. È una caratteristica strutturale del nuovo paesaggio normativo europeo, che riflette la complessità genuina dei sistemi tecnologici moderni: sistemi che sono contemporaneamente infrastruttura critica, asset operativo finanziario e sistema intelligente decisionale, non governabili da un solo framework senza perdere pezzi fondamentali del quadro di rischio.

La complessità reale, tuttavia, è diversa da come spesso viene rappresentata. Non è una sovrapposizione caotica e indifferenziata di obblighi identici, ma una struttura di interazioni giuridicamente precise: lex specialis dove applicabile, cumulo genuino dove necessario. Questa struttura richiede competenza per essere navigata, non semplificazione. Confondere le due cose produce compliance costosa e inutilmente ridondante in alcuni punti e pericolosamente lacunosa in altri.

Le organizzazioni che investiranno in una visione integrata e giuridicamente precisa del rischio regolatorio, costruendo le capacità di governance, i processi e le architetture tecniche necessarie a vedere il rischio nella sua dimensione composita reale, trasformeranno la compliance in qualcosa di più di un obbligo: in un segnale di maturità organizzativa che il mercato, i regolatori e i propri clienti sanno sempre meglio leggere.

La convergenza regolatoria non è la fine del problema. È l’inizio di una nuova concezione della resilienza.

L’analisi riflette una prospettiva editoriale indipendente basata sull’analisi dei testi normativi ufficiali, degli RTS e ITS adottati dalle Autorità di Vigilanza Europee e della letteratura giuridica disponibile alla data di pubblicazione. Le indicazioni non costituiscono parere legale.