Conviene partire da una premessa: AI Act, NIS2 e GDPR hanno smesso da tempo di vivere in compartimenti stagni.
Oggi capire quali obblighi ti riguardano dipende un po’ dalle dimensioni dell’azienda, un po’ dal settore in cui operi e, sempre più spesso, dal ruolo che giochi all’interno delle catene di fornitura.
La buona notizia è che, una volta vista la mappa d’insieme, ci si accorge che molti adempimenti parlano lingue diverse ma chiedono cose simili.
Vediamo dove i tre framework si incontrano davvero.
Risk management: un obbligo, tre linguaggi
L’art. 9 dell’AI Act chiede di gestire il rischio lungo l’intero ciclo di vita dei sistemi ad alto rischio. La NIS2 domanda misure tecniche, operative e organizzative per i rischi sui sistemi informativi. La ISO 27001, per chi ha un ISMS strutturato, prevede controlli analoghi nell’Annex A.
Tre testi, una sola logica di fondo: identificare, valutare, mitigare, documentare.
Se hai già un processo di risk assessment ben impostato per NIS2 o ISO 27001, parti avvantaggiato: hai una base solida su cui appoggiare anche la compliance AI Act. Non si tratta di ripartire da zero, ma piuttosto di allargare il perimetro del tuo risk management fino a comprendere i sistemi di intelligenza artificiale.Sicurezza by design
L’art. 15 dell’AI Act vuole che i sistemi ad alto rischio nascano con livelli adeguati di accuratezza, robustezza e cybersecurity. Il controllo A.8 della ISO 27001 e i requisiti tecnici della NIS2 dicono la stessa cosa con altre parole: la sicurezza va pensata in fase di progettazione, non incollata dopo. Vale la pena ricordarlo perché i sistemi AI portano con sé vettori di rischio nuovi e non sempre intuitivi — prompt injection, data leakage attraverso le integrazioni, accessi poco controllati ai repository, una supply chain che si allunga. In altri termini, può essere utile trattare l’AI come una componente dell’infrastruttura critica, non come un software qualunque.
Documentazione e audit trail
È forse l’area dove la convergenza si sente di più. Il GDPR chiede il registro dei trattamenti e la DPIA per i trattamenti ad alto rischio; la NIS2 impone logging, audit periodici e tracciabilità delle misure adottate; l’AI Act aggiunge la documentazione tecnica del sistema, i registri automatici di logging per l’alto rischio e la tracciabilità delle decisioni. Tre richieste che, se gestite con strumenti separati, rischiano di moltiplicare il lavoro: spesso conviene ragionare su un impianto documentale unico che soddisfi tutti e tre.
Notifica degli incidenti: il punto più delicato
Qui il consiglio è di fare attenzione, perché un singolo incidente può far scattare più obblighi di segnalazione verso autorità diverse. L’art. 73 dell’AI Act prevede la comunicazione degli incidenti gravi alle autorità di vigilanza del mercato; l’art. 33 del GDPR richiede la notifica al Garante (entro 72 ore); a questi si sommano gli obblighi NIS2 verso l’ACN, con tempistiche e soglie di attivazione proprie. Le scadenze non coincidono, e questo è il vero punto critico: chi non ha procedure di escalation integrate e ben documentate rischia di trovarsi a gestire l’emergenza in modo frammentato, con il doppio inconveniente di esporsi a non conformità e di amplificare il danno. Predisporre in anticipo una matrice “quale incidente → quali notifiche → entro quanto” è uno di quegli investimenti che si ripagano al primo evento serio.
Considerazioni aggiuntive sull’AI Act
È bene aggiungere alcune considerazioni che possano ampliare il discorso, specialmente in ambito AI Act.
Le tempistiche dell’art. 73 (regime “a scaglioni”)
Vale la pena essere precisi, perché non esiste un termine unico. La segnalazione va fatta senza indebito ritardo e comunque entro 15 giorni per gli incidenti gravi in generale, entro 10 giorni in caso di decesso di una persona, ed entro 2 giorni in caso di infrazione diffusa o di grave e irreversibile interruzione di un’infrastruttura critica. È inoltre ammessa una prima segnalazione incompleta, da integrare successivamente. Questo aiuta a calibrare le procedure di escalation interne sul caso peggiore.
Classificazione del rischio
Una volta ottenuto l’inventario, ogni sistema va classificato secondo la tassonomia usata dall’AI Act. La classificazione determina quali obblighi si attivano e con quale urgenza
Il possibile alleggerimento della “tripla notifica”
Un dettaglio utile proprio sul tema delle sovrapposizioni: la bozza di linee guida della Commissione europea (pubblicata a settembre 2025 e posta in consultazione fino a novembre 2025) prevede un regime semplificato per i settori già soggetti a obblighi di segnalazione equivalenti. In pratica, per i settori con reporting equivalente già esistente — come le infrastrutture critiche soggette alla NIS2 — l’obbligo dell’art. 73 si applicherebbe solo alle violazioni dei diritti fondamentali, mentre gli altri incidenti andrebbero segnalati secondo le regole settoriali. Trattandosi di una bozza in consultazione, conviene tenerla d’occhio quando si disegnano le procedure, senza darla ancora per definitiva.
La tempistica generale di applicazione
Gli obblighi sui sistemi ad alto rischio, incluso l’art. 73, si applicheranno da agosto 2026. C’è quindi una finestra per preparare l’impianto con calma, ma è anche il momento giusto per farlo, prima che le scadenze diventino vincolanti.
Un ulteriore punto sul quale porre attenzione: la FRIA
Accanto alla DPIA del GDPR, l’AI Act introduce in alcuni casi la valutazione d’impatto sui diritti fondamentali (FRIA, art. 27), prevista in particolare per i deployer che sono organismi pubblici e per alcuni soggetti privati. È un ulteriore punto di possibile sinergia documentale con la DPIA, perché le due valutazioni condividono parte della logica e dei dati di partenza.
Hai dubbi o quesiti riguardo AI Act, NIS 2 e GDPR?
Contattaci e sapremo aiutarti!