NIS2, DORA e AI Act: un set di controlli, tre regolatori, un problema di prove

Il 2 agosto 2026 una parte dell'AI Act europeo è entrata in vigore, un'altra è scivolata silenziosamente diciotto mesi più in là, e la maggior parte dei team compliance oggi ragiona su un modello mentale sbagliato su entrambi i fronti. Gli obblighi di trasparenza sono scattati. Il regime pesante sull'alto rischio no. E sotto questo rimescolamento c'è un problema che con l'AI c'entra poco: un'organizzazione europea, di qualunque dimensione, oggi risponde contemporaneamente a NIS2, DORA e AI Act, e tutti e tre vogliono vedere più o meno le stesse prove sugli stessi controlli — misurati, testati, registrati e datati.

L'istinto è avviare tre programmi. È così che si finisce per pagare tre audit di una sola rete. Questo articolo spiega cosa è davvero cambiato il 2 agosto, perché i tre regimi convergono su un unico set di controlli, e perché ciò che manda in crisi le aziende non è mai il testo della norma — è dimostrare, il giorno in cui l'auditor lo chiede, che il controllo stava funzionando.

Cosa è davvero scattato il 2 agosto

Sono successe due cose, e tirano in direzioni opposte.

Primo, sono entrati in vigore gli obblighi di trasparenza dell'Articolo 50. Chi fornisce o utilizza AI generativa e interattiva deve ora dichiarare quando una persona sta interagendo con una macchina, e marcare i contenuti generati o manipolati dall'AI (audio, immagini, video, testo sintetici) come artificiali. Sono in vigore adesso, sanzionabili adesso, con penali reali.

Secondo — ed è la parte che quasi tutti i riassunti sbagliano — gli obblighi sull'alto rischio dell'Allegato III sono stati rinviati. Il Digital Omnibus, ora Regolamento (UE) 2026/1744, firmato l'8 luglio ed entrato in vigore il 27 luglio 2026, sposta la data di conformità per i sistemi ad alto rischio dell'Allegato III — biometria, gestione del lavoro, credit scoring, istruzione, componenti di sicurezza delle infrastrutture critiche — dal 2 agosto 2026 al 2 dicembre 2027.

"Siamo a posto fino a dicembre 2027" — la frase che una sala piena di responsabili legali e di sicurezza si è raccontata il mese scorso, poco prima che qualcuno chiedesse chi gestiva la dichiarazione del chatbot sul portale clienti.

Il rinvio è reale, ma è stretto. Sposta il regime più pesante; non crea una vacanza. L'Articolo 50 è in vigore. Gli obblighi sui modelli di AI di uso generale corrono da agosto 2025. Governance, vigilanza di mercato e l'impianto sanzionatorio sono tutti in piedi. Dare per scontati diciotto mesi di nulla-da-fare è il modo in cui una sanzione sulla trasparenza arriva a un'azienda convinta di avere tempo fino al 2027.

E le sanzioni non sono simboliche. L'Articolo 99 fissa tre fasce:

Violazione	Sanzione massima
Pratiche vietate (Articolo 5)	€35M oppure 7% del fatturato annuo globale
Altri obblighi, incl. trasparenza (Art. 50) e doveri dei fornitori di sistemi ad alto rischio	€15M oppure 3% del fatturato annuo globale
Informazioni fuorvianti alle autorità	€7,5M oppure 1% del fatturato annuo globale

Si noti dove sta la trasparenza: nella fascia del 3%. L'obbligo scattato il 2 agosto non è quello economico.

Un set di controlli, tre regolatori

Ecco il fatto strutturale che riformula tutto l'esercizio. NIS2, DORA e AI Act sono stati scritti da direzioni diverse per popolazioni diverse, ma regolano lo stesso piccolo insieme di capacità: gestione del rischio, gestione e notifica degli incidenti, controllo dei fornitori terzi, logging e conservazione dei registri, test di resilienza tecnica. Il vocabolario cambia. Le prove sottostanti no.

Si prenda un controllo — "testiamo i nostri sistemi critici per debolezze sfruttabili e rimediamo a ciò che troviamo" — e lo si mappi sui tre regimi: la sovrapposizione è evidente.

Controllo sottostante	NIS2	DORA	AI Act
Gestione del rischio	Misure Art. 21	Framework rischio ICT Art. 6	Sistema di gestione del rischio Art. 9 (alto rischio)
Notifica incidenti	24h preallarme / 72h / 1 mese finale	4h iniziale / 72h / 1 mese finale	Notifica incidenti gravi Art. 73
Terze parti / supply chain	Sicurezza supply chain Art. 21	Cap. V rischio terzi ICT, Registro delle informazioni	Obblighi fornitore ↔ deployer
Logging & tracciabilità	Prove di rilevamento e gestione	Logging eventi ICT	Registrazione automatica Art. 12 (alto rischio)
Test di resilienza / sicurezza	Aspettativa di test Art. 21	TLPT (threat-led penetration testing)	Test di robustezza e accuratezza (alto rischio)

Per gli enti finanziari il quadro è più pulito di quanto sembri: DORA è lex specialis, quindi dove entrambi si applicano un incidente ICT si notifica sotto DORA, non NIS2. Questo risolve la domanda "24 ore o 4 ore?" — una banca in ambito per entrambi notifica l'incidente ICT con l'orologio di DORA. Ma non fa collassare le prove. Bisogna comunque dimostrare il framework di rischio, il registro dei terzi, i test e — se si utilizza AI in una funzione ad alto rischio — l'ulteriore livello dell'AI Act, tutto a partire dagli stessi fatti sottostanti.

Tre regolatori. In gran parte un solo set di controlli. Lo spreco sta nel dimostrarlo tre volte separate.

Gli orologi non coincidono — ed è la spia

La notifica degli incidenti è il punto in cui la tesi "un solo set di controlli" viene messa alla prova, perché i timer sono deliberatamente diversi:

• NIS2 — preallarme entro 24 ore dalla consapevolezza, notifica più completa entro 72 ore, relazione finale entro un mese.
• DORA — notifica iniziale entro 4 ore dalla classificazione di un incidente come grave (e non oltre 24 ore dalla consapevolezza), relazione intermedia entro 72 ore, relazione finale entro un mese.

Le 4 ore iniziali di DORA sono l'orologio più stretto della regolazione cyber europea. E mettono a nudo il vero problema: la scadenza non è la parte difficile — la classificazione lo è. Non si può notificare un incidente grave in quattro ore se ci vogliono tre giorni per accorgersi dell'anomalia e altri due per decidere se ha superato la soglia di "grave". L'orologio parte solo quando sai che qualcosa non va. La latenza di rilevamento divora l'intero budget prima ancora di aprire il template della notifica.

Ecco perché un obbligo di notifica incidenti è, in pratica, un obbligo di rilevamento travestito da compliance. Il regime che sembra burocrazia in realtà chiede se la tua rete ti dice cosa sta succedendo mentre succede.

È un problema di prove, non di norme

Il testo delle norme è pubblico e, onestamente, non così difficile da leggere. Ciò che affonda le organizzazioni è il divario tra avere un controllo ed essere in grado di provare che funzionava in una data precisa.

La terza valutazione annuale di maturità di ENISA, il rapporto NIS360 2026 pubblicato il 2 giugno 2026, rende il divario concreto. Segnala sette settori in cui la criticità sistemica supera la maturità cyber — sanità, ferrovie, marittimo, gestione dei servizi ICT, spazio, pubblica amministrazione e acqua potabile/reflue. Nel settore idrico, un'entità su tre tra quelle intervistate non aveva mai condotto una valutazione del rischio. Nella pubblica amministrazione, circa un terzo non ha un processo strutturato per garantire competenze cyber a livello dirigenziale, e circa la metà non fornisce alcuna formazione cyber al management. Non sono organizzazioni a corto di regolamenti. Sono a corto di pratica dimostrabile.

La risposta tradizionale — un penetration test annuale, un audit puntuale, un PDF in una cartella condivisa — era pensata per un mondo con un framework e un auditor l'anno. Sotto il nuovo carico fallisce in tre modi:

• È vecchia. Un pentest datato novembre scorso non dice nulla del controllo che si è rotto a marzo. Gli auditor, sotto tutti e tre i regimi, chiedono sempre più prove di assurance continua, non un'istantanea una tantum.
• È a compartimenti. Lo stesso finding viene ri-documentato per l'audit ISO, per il supervisore NIS2 e per l'esaminatore DORA — tre stesure di un solo fatto.
• È indimostrabile a posteriori. "L'abbiamo rimediato ad aprile" è un'affermazione. Senza un registro firmato e datato del finding, della correzione e del re-test, è un'affermazione non verificabile — esattamente quella che trasforma una revisione di routine in un rilievo.

Cosa fare prima che l'auditor lo chieda

Mosse concrete che rendono su tutti e tre i regimi insieme, ordinate per leva:

1. Inventaria una volta, mappa molte. Costruisci un unico inventario dei controlli e mappa ciascun controllo al suo obbligo NIS2 / DORA / AI Act. Un controllo, tre riferimenti — non tre programmi.
2. Risolvi la sovrapposizione in modo esplicito. Per gli enti finanziari, documenta che gli incidenti ICT passano da DORA (lex specialis). Scrivi quale orologio governa, così nessuno improvvisa alla terza ora.
3. Sistema la classificazione prima di ottimizzare la notifica. Il timer di 4 ore di DORA presuppone che tu sappia già che l'incidente è grave. Investi nel rilevamento e nel triage che rendono rapida la classificazione; il template della notifica è il facile 20%.
4. Rendi l'assurance continua, non annuale. Sostituisci il test una-volta-l'anno con validazione schedulata e attivata dai cambiamenti, così la prova che "il controllo ha funzionato" è datata questa settimana, non lo scorso autunno.
5. Firma le tue prove. Un registro datato e a prova di manomissione di finding → remediation → re-test è la differenza tra "ce ne siamo occupati" e un artefatto difendibile da consegnare a un esaminatore, un assicuratore o un legale.
6. Non dare per scontato che il rinvio a dicembre 2027 compri silenzio. La trasparenza dell'Articolo 50 è in vigore adesso. Se utilizzi AI generativa rivolta al cliente, quel controllo di disclosure è in ambito oggi.

Dove le prove continue e firmate cambiano l'audit

Tutto quanto sopra converge su un unico requisito operativo: un flusso di prove datate e verificabili che i tuoi controlli funzionano, mappate su ogni framework che le chiede. È esattamente il problema per cui è costruito il motore di compliance automatica di Zero Hunt. Mappa in continuo ogni scansione, finding e remediation su 32 framework — inclusi NIS2 (con il Titolo 13), DORA (compreso l'RTS TLPT), ISO 27001, SOC 2 e gli altri — con scoring pesato per severità e mappatura cross-framework dei controlli, così un singolo finding validato soddisfa i suoi obblighi NIS2, ISO e DORA contemporaneamente invece di generare tre stesure separate. Una mappatura cross-framework di questo tipo riduce il lavoro di audit ridondante fino al 70%.

Due proprietà contano per gli scenari qui sopra. Ogni report è firmato ECDSA con catena di custodia al momento della scrittura, così l'affermazione "l'abbiamo rimediato ad aprile" diventa un artefatto verificabile e non un'asserzione — l'auditor, l'assicuratore o il team legale possono verificare la firma. E il tutto gira su un'appliance 100% on-prem senza callback verso il cloud, cosa che conta quando i sistemi sotto valutazione sono i carichi di infrastruttura critica e finanziari che questi regimi esistono per proteggere. Il Trust Center trasforma quel flusso continuo in un export pronto per l'auditor con un clic — la risposta a "mostrami la prova che il controllo funzionava in questa data" per quale che sia dei tre regolatori a chiederla.

La scadenza dell'AI Act si è spostata. Il problema delle prove no. Le organizzazioni che trattano NIS2, DORA e AI Act come un solo set di controlli — provato in continuo, firmato una volta, mappato ovunque — sono quelle che ad agosto 2027 produrranno un report invece di ricostruire un anno.