NIS2 e AI Act ridisegnano le priorità di chi governa il cloud: dai sistemi da includere nel perimetro alle responsabilità di CIO, vertici e provider, fino alla gestione degli incidenti e al rischio di sanzioni.
Dal 2 dicembre 2027 i sistemi di intelligenza artificiale ad alto rischio dell’Allegato III dell’AI Act entreranno nella fase di applicazione prevista dal calendario europeo aggiornato nel 2026. Per il CIO che acquista servizi cloud e strumenti AI, la scadenza si affianca agli obblighi NIS2, già operativi. La responsabilità dell’organizzazione resta in capo all’organizzazione.
La decisione pratica riguarda le regole applicabili all’impresa, i responsabili dei controlli e il contributo dei servizi esterni alla conformità. NIS2 disciplina la cybersicurezza dei soggetti inclusi nel proprio perimetro. L’AI Act, invece, considera il ruolo svolto dall’impresa, come fornitore o utilizzatore, e la classe di rischio del sistema.
Prima verifica: perimetro NIS2 e sistemi AI
In Italia la NIS2 è stata recepita con il decreto legislativo 138/2024, in vigore dal 16 ottobre 2024. La verifica parte dal settore e dalle dimensioni dell’impresa. La direttiva comprende 18 settori, tra cui energia, trasporti, sanità, infrastrutture digitali e pubblica amministrazione; in via generale, riguarda le medie e grandi imprese che operano nei comparti elencati.
La dimensione aziendale non esaurisce l’analisi. In casi specifici rientrano anche piccole e microimprese. Può essere incluso, inoltre, un fornitore che abbia un peso sistemico nella catena di fornitura di un soggetto essenziale o importante. Il CIO deve quindi confrontare le attività dell’impresa con la classificazione comunicata dall’Agenzia per la cybersicurezza nazionale (ACN). Dalla comunicazione di inserimento nell’elenco decorrono i termini: 18 mesi per attuare le misure di base e nove mesi per avviare la notifica degli incidenti significativi.
Per l’AI Act occorre costruire una mappa distinta. Chi utilizza un chatbot o un servizio di intelligenza artificiale è normalmente un deployer, cioè un utilizzatore. L’impresa assume il ruolo di provider quando sviluppa il sistema, lo fa sviluppare e lo immette sul mercato a proprio nome. Vanno registrati finalità e contesto d’uso. Selezione del personale, istruzione, credito e altri ambiti dell’Allegato III possono rientrare nella categoria ad alto rischio. Per questi sistemi l’applicazione è prevista dal 2 dicembre 2027; chi li utilizza deve attenersi alle istruzioni, sorvegliarne il funzionamento e conservare i log.
Responsabilità: CIO, vertici e cloud provider
La responsabilità non si ferma al reparto IT. La NIS2 affida agli organi di amministrazione l’approvazione delle misure di sicurezza e la vigilanza sulla loro attuazione. Al CIO spetta tradurre gli obblighi in architetture e procedure, predisporre gli inventari e i controlli e coordinare sicurezza, acquisti, legale e responsabili dei sistemi AI.
Il cloud provider gestisce le componenti previste dal contratto; all’azienda compete il governo del rischio ICT, degli accessi e dei dati caricati sui servizi. Anche la gestione delle chiavi crittografiche richiede attenzione. La rotazione del KMS produce nuovo materiale, mentre la ricifratura dei dati già protetti va pianificata separatamente. Nel piano devono comparire anche la revoca d’emergenza e le relative modalità. Con un modello bring your own key, la chiave può essere utilizzata nell’infrastruttura del fornitore: il contratto deve chiarire la gestione della custodia.
Gli accordi con i provider devono attribuire con precisione i compiti relativi a notifiche, registri e audit. Vanno regolati anche la conservazione dei log, la gestione delle vulnerabilità, la continuità del servizio e la restituzione o cancellazione dei dati. Per i clienti finanziari, DORA prevede un registro degli accordi con i fornitori ICT e richiede clausole adeguate. Gli obblighi contrattuali possono quindi riguardare anche un fornitore cloud che non opera come banca.
Incidenti, controlli e rischio sanzionatorio
La procedura per gli incidenti deve collegare la rilevazione tecnica alla decisione di notifica. In ambito NIS2 il percorso prevede un preallarme entro 24 ore dalla conoscenza dell’incidente significativo, una notifica entro 72 ore e una relazione finale entro un mese. Nei servizi cloud occorrono contatti operativi e accesso tempestivo alle evidenze, insieme a un’escalation che permetta all’azienda di rispettare i propri termini mentre il provider conduce l’analisi.
Per i prodotti digitali coperti dal Cyber Resilience Act, dal settembre 2026 i fabbricanti devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi. Il preallarme è previsto entro 24 ore, la notifica entro 72. L’obbligo riguarda i fabbricanti. Nell’AI Act, gli adempimenti dipendono dal ruolo dell’impresa e dal rischio del sistema; alfabetizzazione e uso conforme sono rilevanti anche per i deployer.
Le violazioni NIS2 possono comportare sanzioni, oltre ai costi di ripristino, alle interruzioni e alle conseguenze contrattuali. Per i soggetti essenziali, il tetto minimo previsto dalla direttiva è di 10 milioni di euro o il 2% del fatturato mondiale annuo; per i soggetti importanti è di 7 milioni o l’1,4%. In entrambi i casi si applica l’importo più alto. La sanzione dipende dalla classificazione dell’organizzazione e dalla violazione accertata.
Per il CIO, il primo passaggio operativo è riunire in una sola mappa servizi cloud e sistemi AI. Per ciascuno vanno indicati un proprietario, il ruolo normativo dell’impresa, i dati trattati, le dipendenze e le scadenze. Su questa base si assegnano le responsabilità a vertici, team e fornitori; si controllano contratti e procedure d’incidente e si registrano le lacune rispetto agli obblighi applicabili.
