NIS2 e AI Act alla prova del cloud: la guida operativa per i CIO

La progressiva convergenza tra architetture multi-cloud e adozione distribuita di modelli di intelligenza artificiale generativa ha definitivamente superato il tradizionale perimetro logico della sicurezza informatica.

I dipartimenti IT guidati dai Chief Information Officer (CIO) operano ormai in un ecosistema nel quale infrastrutture computazionali, piattaforme di orchestrazione, servizi applicativi e componenti dei modelli di intelligenza artificiale possono appartenere a fornitori terzi.

Il tradizionale modello di responsabilità condivisa adottato dai grandi cloud provider non elimina, per l’organizzazione utilizzatrice, gli obblighi di governo del rischio, sicurezza, controllo della catena di fornitura e gestione degli incidenti.

Governance NIS2 e AI Act: responsabilità e filiera cloud

Con il decreto legislativo 4 settembre 2024, n. 138, che ha recepito nell’ordinamento italiano la direttiva (UE) 2022/2555 (NIS2), la cybersicurezza assume una dimensione di governance che coinvolge direttamente gli organi di amministrazione e gli organi direttivi dei soggetti rientranti nel relativo perimetro. Il CIO non è quindi più chiamato soltanto a garantire la sicurezza tecnica dell’infrastruttura, ma deve operare all’interno di un sistema di responsabilità organizzative, decisionali e contrattuali.

Il decreto attribuisce all’Agenzia per la cybersicurezza nazionale (ACN) un ruolo centrale nel sistema nazionale di cybersicurezza e prevede specifici obblighi in materia di gestione del rischio, sicurezza della catena di approvvigionamento, formazione, gestione degli incidenti e cooperazione con le autorità competenti.

Particolare rilievo assume la supply chain. La sicurezza dei fornitori di servizi cloud, software, piattaforme e componenti tecnologiche deve essere considerata parte integrante della gestione del rischio dell’organizzazione. L’esternalizzazione di una componente dell’architettura non determina infatti l’esternalizzazione della responsabilità di governo del rischio.

Il principio è particolarmente rilevante nel caso della GenAI: il CIO deve conoscere non soltanto il servizio acquistato, ma anche la destinazione dei dati, le modalità di trattamento dei prompt, la conservazione dei log, le modalità di gestione degli accessi, la dipendenza da ulteriori subfornitori e le procedure applicabili in caso di incidente.

Responsabilità e sanzioni nel perimetro NIS2

Il quadro sanzionatorio previsto dal decreto legislativo n. 138/2024 introduce, per i soggetti rientranti nel perimetro NIS2, sanzioni amministrative pecuniarie e ulteriori misure di vigilanza e di enforcement.

La rilevanza del sistema sanzionatorio non deve tuttavia portare a una lettura esclusivamente repressiva della disciplina. Per il CIO il dato più significativo è che la cybersicurezza diventa una componente della governance aziendale: le decisioni relative a rischio, continuità operativa, sicurezza dei fornitori e gestione degli incidenti devono poter essere dimostrate, documentate e ricondotte a responsabilità organizzative definite.

La sicurezza della filiera cloud deve quindi essere trattata come un elemento della continuità operativa e non come una semplice clausola tecnica del contratto IT.

Shadow AI e AI Act: inventario, ruoli e responsabilità

La diffusione incontrollata di strumenti basati su modelli linguistici di grandi dimensioni e di applicazioni di intelligenza artificiale generativa all’interno delle organizzazioni costituisce una nuova area di rischio.

Dipendenti e collaboratori possono utilizzare chatbot pubblici, estensioni browser, servizi SaaS o API non censiti per riassumere documenti, elaborare informazioni riservate, analizzare contratti o generare codice sorgente.

Questa Shadow AI può produrre contemporaneamente rischi di sicurezza informatica, protezione dei dati personali, riservatezza commerciale, proprietà intellettuale e conformità alle policy aziendali.

La prima risposta del CIO non dovrebbe essere necessariamente il blocco indiscriminato degli strumenti di IA. L’obiettivo deve essere piuttosto quello di conoscere e governare l’utilizzo effettivo dell’IA all’interno dell’organizzazione.

Deployer, provider e modifiche ai sistemi di IA

Nel sistema dell’AI Act, l’organizzazione che utilizza professionalmente un sistema di IA sotto la propria autorità può assumere, in relazione alla specifica attività, il ruolo di deployer.

La qualificazione deve però essere verificata caso per caso. L’articolo 25 dell’AI Act prevede specifiche ipotesi nelle quali un distributore, importatore, deployer o altro soggetto terzo è considerato provider di un sistema di IA ad alto rischio. Tra queste rientrano l’apposizione del proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato o messo in servizio, la modifica sostanziale di un sistema ad alto rischio e la modifica della destinazione d’uso di un sistema tale da determinarne la qualificazione come sistema ad alto rischio.

Non è quindi corretto considerare qualsiasi attività di personalizzazione o fine-tuning come automaticamente idonea a determinare la trasformazione del deployer in provider.

Il CIO deve invece introdurre un processo di valutazione preventiva delle modifiche apportate ai sistemi di IA, verificando se l’intervento possa incidere sulla qualificazione del sistema, sulla sua destinazione d’uso o sulla conformità ai requisiti applicabili.

Nel caso dei modelli di IA per finalità generali (GPAI), deve inoltre essere distinta la disciplina specifica prevista dall’AI Act per i provider di tali modelli da quella applicabile ai soggetti che li integrano o li utilizzano all’interno di sistemi più complessi.

Documentazione e registro interno dei sistemi di IA

Quando ricorrono gli obblighi previsti dall’AI Act, la gestione della documentazione assume un ruolo centrale.

Il CIO dovrebbe quindi assicurare la tracciabilità almeno di:

• sistema o modello utilizzato;
• provider originario;
• finalità e destinazione d’uso;
• dati trattati;
• modalità di integrazione;
• eventuali modifiche sostanziali;
• controlli tecnici e organizzativi applicati;
• soggetto responsabile del sistema;
• risultati delle verifiche di sicurezza;
• incidenti e anomalie;
• valutazioni di conformità eventualmente richieste.

Il registro interno dei sistemi di IA diventa così uno strumento di governance, anche quando non coincida con uno specifico registro imposto direttamente dalla normativa.

AI Act per i CIO: trasparenza e AI literacy

L’AI Act introduce obblighi di trasparenza applicabili a specifiche categorie di sistemi e utilizzi.

Per i sistemi destinati a interagire direttamente con persone fisiche, il regolamento prevede, in determinate condizioni, che le persone interessate siano informate del fatto di interagire con un sistema di IA, salvo i casi in cui ciò risulti già evidente dal contesto.

Per i sistemi che generano contenuti sintetici audio, immagini, video o testo, l’articolo 50 prevede inoltre specifici obblighi di marcatura degli output in un formato leggibile meccanicamente e rilevabile come generato o manipolato artificialmente. Il requisito non deve essere tradotto automaticamente nell’obbligo di adottare uno specifico sistema di watermarking crittografico: la soluzione tecnica deve essere valutata alla luce delle prescrizioni del regolamento e dello stato dell’arte.

Accanto alla trasparenza assume rilievo l’articolo 4 dell’AI Act, relativo all’alfabetizzazione in materia di IA. Provider e deployer devono adottare misure per garantire, nella misura del possibile, un livello sufficiente di AI literacy del personale e delle altre persone che operano per loro conto.

Per il CIO questo significa trasformare la formazione sull’IA da iniziativa facoltativa a componente strutturale del modello di governance tecnologica.

La formazione dovrebbe riguardare almeno:

• utilizzi consentiti e vietati;
• gestione delle informazioni riservate;
• protezione dei dati personali;
• verifica degli output;
• rischi di prompt injection e manipolazione;
• proprietà intellettuale;
• obblighi di supervisione umana;
• procedure interne per la segnalazione degli incidenti.

Fornitori di IA tra NIS2 e AI Act: il vendor assessment

L’approvvigionamento di piattaforme SaaS, API e servizi GenAI richiede l’integrazione dei profili di sicurezza, protezione dei dati e conformità AI all’interno del processo di vendor assessment.

Il CIO dovrebbe evitare che la valutazione del fornitore si esaurisca nella verifica di una certificazione o di una dichiarazione contrattuale.

Certificazioni quali ISO/IEC 27001 e, ove pertinenti, ISO/IEC 27017, ISO/IEC 27018 e ISO/IEC 42001 possono costituire elementi utili di assurance, ma non devono essere trattate come sostitutive della valutazione del rischio.

La verifica deve inoltre considerare l’intera catena di fornitura: il provider contrattuale può dipendere da ulteriori fornitori di infrastruttura, modelli, servizi di sicurezza, storage o componenti software.

Dalla Shadow AI alla governance operativa dei CIO

La gestione del rischio di Shadow AI non può limitarsi allo scrutinio documentale.

Dal punto di vista tecnico, l’organizzazione può utilizzare strumenti quali CASB, Secure Web Gateway, DLP, DNS monitoring e sistemi SIEM per individuare connessioni verso servizi di IA non autorizzati.

L’obiettivo non deve essere esclusivamente quello di bloccare l’utilizzo dell’IA, ma di costruire un perimetro aziendale nel quale gli strumenti autorizzati siano facilmente accessibili e configurati secondo policy definite.

Una strategia efficace può quindi prevedere:

1. discovery degli strumenti effettivamente utilizzati;
2. classificazione dei servizi;
3. valutazione dei dati trattati;
4. definizione dei casi d’uso autorizzati;
5. individuazione dei servizi vietati o soggetti ad autorizzazione;
6. predisposizione di un catalogo aziendale degli strumenti approvati;
7. monitoraggio continuo degli utilizzi;
8. formazione degli utenti.

L’AI procurement deve diventare parte integrante del processo di procurement IT, evitando che l’acquisizione di un servizio di IA avvenga al di fuori dei normali controlli di sicurezza, privacy e approvvigionamento.

NIS2 per i CIO: incidenti e contratti multi-cloud

L’integrazione di servizi cloud gestiti all’interno di architetture ibride e distribuite rende più complessa la gestione degli incidenti significativi.

Per i soggetti rientranti nel perimetro NIS2, la disciplina prevede una sequenza di comunicazioni articolata su più livelli.

Tempi di preallarme, notifica e relazione finale

In presenza di un incidente significativo, il soggetto interessato deve trasmettere:

• un preallarme senza indebito ritardo e comunque entro 24 ore da quando viene a conoscenza dell’incidente significativo;
• una notifica dell’incidente senza indebito ritardo e comunque entro 72 ore;
• una relazione finale entro un mese dalla trasmissione della notifica dell’incidente;
• una relazione intermedia, quando richiesta dal CSIRT o dall’autorità competente.

Il preallarme deve contenere le informazioni necessarie a informare il CSIRT o l’autorità competente dell’evento e, ove opportuno, indicare se l’incidente è sospettato di derivare da atti illeciti o malevoli o se può avere un impatto transfrontaliero.

La notifica successiva deve aggiornare le informazioni disponibili e fornire una valutazione iniziale della gravità e dell’impatto dell’incidente, includendo, ove disponibili, gli indicatori di compromissione.

La relazione finale deve descrivere l’incidente, la gravità e l’impatto, la minaccia o causa di fondo presumibilmente all’origine dell’evento e le misure di mitigazione adottate o in corso.

Security SLA con i Cloud Service Provider

Il rispetto dei termini normativi dipende anche dalla velocità con cui il provider rende disponibili le informazioni.

Un contratto cloud che preveda comunicazioni tardive o generiche può quindi creare un rischio operativo rilevante.

Il CIO dovrebbe introdurre nei contratti e negli accordi quadro specifici Security SLA, stabilendo tempi di comunicazione coerenti con la capacità dell’organizzazione di effettuare il triage e rispettare gli obblighi normativi.

Una finestra contrattuale di 4-8 ore per la comunicazione iniziale di eventi potenzialmente rilevanti può essere adottata come best practice contrattuale, purché sia proporzionata al servizio, al rischio e alle effettive capacità del provider.

La clausola dovrebbe essere accompagnata da:

• disponibilità tempestiva dei log;
• accesso alle informazioni forensi pertinenti;
• indicazione dei referenti di sicurezza;
• obblighi di cooperazione;
• escalation 24/7 per gli incidenti critici;
• tempi di conservazione dei dati adeguati alle esigenze investigative;
• procedure per la gestione dei subfornitori;
• eventuali penali contrattuali proporzionate al rischio.

Le clausole di manleva devono invece essere costruite con particolare attenzione: non possono essere utilizzate per trasferire automaticamente al provider obblighi o responsabilità che la normativa pone in capo al soggetto rientrante nel perimetro NIS2.

Vettori di minaccia per i sistemi di IA

In un’architettura multi-cloud che utilizza sistemi generativi, il SOC dovrebbe integrare nei propri casi d’uso di monitoraggio anche indicatori relativi ai sistemi di IA.

Tra i principali vettori di rischio:

Indirect Prompt Injection. Inserimento di istruzioni malevole all’interno di documenti, pagine web, e-mail o altri contenuti elaborati da un sistema di IA, con l’obiettivo di alterarne il comportamento o indurlo a utilizzare strumenti e API in modo non previsto.

RAG Poisoning. Alterazione fraudolenta dei contenuti o degli indici utilizzati da sistemi Retrieval-Augmented Generation, con il rischio di condizionare le risposte prodotte dal modello.

Compromissione di API key e token. Sottrazione di credenziali utilizzate per accedere ai servizi di inferenza, con conseguente rischio di accesso abusivo, aumento dei costi, utilizzo fraudolento delle risorse o compromissione dei dati.

Abuso degli strumenti collegati al modello. Un agente dotato di accesso a sistemi esterni può trasformare una vulnerabilità del modello in un rischio operativo se non sono applicati controlli di autorizzazione, least privilege e human oversight.

Il monitoraggio dovrebbe quindi correlare log applicativi, autenticazioni, chiamate API, anomalie di consumo, accessi ai vector database e attività degli strumenti collegati agli agenti.

La tempistica contrattuale del provider non deve essere confusa con la tempistica prevista dalla NIS2: la prima è uno strumento organizzativo finalizzato a consentire all’ente di rispettare la seconda.

NIS2, AI Act e FinOps: sicurezza e sostenibilità economica

L’adeguamento ai requisiti di resilienza, sicurezza e governance dei dati impone una ridefinizione della spesa tecnologica.

Nel caso della GenAI, il controllo dei costi assume caratteristiche differenti rispetto al cloud tradizionale. Il consumo può infatti dipendere dal numero di richieste, dai token di input e output, dalla lunghezza del contesto, dal modello utilizzato e dagli strumenti collegati al modello.

Costi della GenAI e Context Window Creep

In una tradizionale infrastruttura cloud, i costi sono prevalentemente collegati a risorse quali CPU, memoria, storage e traffico.

Nel caso dei servizi GenAI, una componente significativa della spesa può dipendere dal volume di token elaborati.

Nelle applicazioni multi-turno, la crescita del contesto può determinare un aumento significativo dei token trasmessi al modello. La gestione inefficiente della cronologia, dei documenti recuperati tramite sistemi RAG e delle istruzioni di sistema può quindi produrre un aumento progressivo del consumo.

Per prevenire l’instabilità dei costi, il CIO dovrebbe introdurre tecniche di ingegnerizzazione quali:

Model Right-Sizing e Dynamic Prompt Routing

Classificazione preliminare delle richieste per indirizzare le attività semplici verso modelli meno onerosi e riservare i modelli più avanzati ai casi che richiedono maggiore capacità di ragionamento.

Prompt Caching

Utilizzo, quando disponibile, di meccanismi di caching dei contenuti ripetitivi per ridurre elaborazioni e costi ricorrenti.

Batch Processing

Utilizzo di modalità asincrone per le attività non interattive quando il provider offre condizioni economiche più favorevoli.

Context Compression e Re-ranking

Riduzione e selezione dei contenuti inviati al modello attraverso tecniche di compressione semantica, ranking e selezione dei documenti più pertinenti.

Queste misure devono tuttavia essere valutate congiuntamente alla qualità dell’output: la riduzione del costo per token non coincide necessariamente con la riduzione del costo complessivo del processo.

Dai token al costo per esito utile

Il controllo finanziario della GenAI dovrebbe progressivamente superare la semplice misurazione del numero di token consumati.

Un modello meno costoso può infatti produrre più errori, richiedere più tentativi, generare escalation verso operatori umani o richiedere ulteriori elaborazioni.

Il CIO e il CFO dovrebbero quindi misurare il costo per esito utile, integrando i costi dei modelli, delle piattaforme, dei vector database e delle infrastrutture con gli effettivi risultati conseguiti.

Alcuni KPI possibili sono:

• Cost per Resolved Ticket: costo complessivo per ticket risolto senza escalation;
• Cost per Analyzed Regulatory Document: costo per documento elaborato e verificato secondo le policy interne;
• Cost per Accepted Code Change: costo per modifica di codice generata, verificata e accettata nella pipeline di sviluppo;
• Cost per Successful Workflow: costo per processo completato correttamente dall’agente o dall’applicazione IA.

In una fase iniziale può essere utile adottare meccanismi di Showback, attribuendo i costi ai diversi dipartimenti senza trasformarli immediatamente in addebiti contabili. Successivamente, una volta consolidata la qualità dei dati di consumo, possono essere valutati meccanismi di Chargeback.

NIS2 e AI Act per i CIO: cinque azioni prioritarie

In vista dei rinnovi contrattuali e delle verifiche di conformità, il CIO dovrebbe predisporre un piano strutturato che integri NIS2, AI Act, sicurezza cloud e controllo dei costi.

Per dare attuazione pratica ai principi di governance e sicurezza del cloud e dell’IA generativa, sono individuate di seguito cinque azioni operative prioritarie. Ciascuna azione definisce il contesto di riferimento, le attività chiave da intraprendere e i principali deliverable attesi per garantire conformità e controllo strategico.

Mappare la Shadow AI e registrare i sistemi

Contesto operativo: l’utilizzo non censito di strumenti di IA può generare rischi di sicurezza, protezione dei dati e controllo della supply chain.

Attività: effettuare un audit utilizzando, ove disponibili, CASB, Secure Web Gateway, DNS, proxy e log applicativi per individuare connessioni verso servizi di IA non autorizzati.

Deliverable: Registro interno dei Sistemi di Intelligenza Artificiale contenente almeno:

• modello o servizio utilizzato;
• provider;
• finalità;
• dati trattati;
• utenti e processi interessati;
• ruolo dell’organizzazione;
• classificazione del rischio;
• misure di sicurezza;
• eventuali modifiche o personalizzazioni;
• responsabile interno.

Riscrivere SLA e Security Addendum

Contesto operativo: i tempi di comunicazione del provider devono essere compatibili con la necessità dell’organizzazione di rilevare, analizzare e notificare gli incidenti.

Attività: identificare i contratti cloud e AI maggiormente critici e verificare le clausole relative a incidenti, log, subfornitori, cooperazione e accesso alle evidenze.

Deliverable: Security Addendum contenente, ove appropriato:

• obblighi di notifica tempestiva;
• escalation 24/7;
• accesso alle informazioni tecniche;
• disponibilità dei log;
• cooperazione forense;
• gestione dei subfornitori;
• requisiti di retention;
• procedure di uscita e portabilità;
• eventuali penali proporzionate al rischio.

Governare il rischio e costruire l’AI literacy

Contesto operativo: la sicurezza e l’utilizzo dell’IA devono essere riportati nei processi di governance dell’organizzazione.

Attività: presentare periodicamente agli organi competenti una relazione sul rischio cyber, sulla sicurezza della supply chain e sull’utilizzo dei sistemi di IA.

Deliverable:

• approvazione delle policy di sicurezza;
• attribuzione delle responsabilità;
• piano di formazione;
• programma di AI Literacy;
• procedure per la gestione degli incidenti;
• evidenze delle decisioni assunte dagli organi competenti.

Applicare l’AI FinOps alla spesa

Contesto operativo: la crescita incontrollata delle chiamate ai modelli può produrre costi non previsti.

Attività: introdurre un livello di orchestrazione che consenta di monitorare consumi, modelli utilizzati, utenti, applicazioni e costi.

Deliverable:

• dashboard dei consumi;
• budget per dipartimento;
• soglie di allerta;
• dynamic routing;
• caching ove disponibile;
• classificazione dei casi d’uso;
• KPI di costo per esito utile.

Testare incidenti e notifiche con un tabletop exercise

Contesto operativo: la capacità di rispettare i tempi di gestione e notifica degli incidenti deve essere verificata prima di un evento reale.

Attività: organizzare un’esercitazione congiunta tra SOC, Incident Response Team, IT, ufficio legale, DPO, procurement e referenti dei provider cloud.

Scenario: compromissione di un servizio AI con possibile esfiltrazione di dati attraverso una tecnica di prompt injection o compromissione del repository utilizzato dal sistema RAG.

Deliverable:

• cronologia dell’incidente;
• individuazione dei responsabili;
• raccolta delle evidenze;
• simulazione del preallarme;
• simulazione della notifica entro 72 ore;
• verifica dei canali di comunicazione;
• individuazione delle criticità;
• piano di remediation.

NIS2 e AI Act nella PA: cloud e sovranità digitale

Per le amministrazioni pubbliche, il governo del cloud deve essere inserito nel quadro nazionale di qualificazione e classificazione previsto dalla Strategia Cloud Italia e dalla disciplina ACN applicabile.

La classificazione dei dati e dei servizi costituisce un passaggio preliminare per individuare le misure e le infrastrutture cloud utilizzabili.

In questo contesto, il CIO o il responsabile competente deve evitare un approccio semplificato nel quale la qualificazione del cloud venga trattata come un requisito generico valido per qualsiasi dato o servizio.

La scelta dell’infrastruttura deve invece partire da:

1. classificazione del dato o servizio;
2. analisi dell’impatto in caso di compromissione;
3. requisiti di sicurezza;
4. requisiti di continuità;
5. localizzazione e trattamento dei dati;
6. qualificazione dell’infrastruttura o del servizio;
7. dipendenze da subfornitori;
8. requisiti di portabilità e uscita.

Lo stesso principio deve essere applicato alle piattaforme di IA.

Prima di trasmettere dati dell’amministrazione verso un servizio GenAI occorre verificare non soltanto la qualità del modello, ma anche:

• dove vengono trattati i dati;
• chi può accedervi;
• per quanto tempo vengono conservati;
• se vengono utilizzati per addestramento o miglioramento del servizio;
• quali subfornitori intervengono;
• quali garanzie contrattuali sono previste;
• quali misure di sicurezza sono applicate;
• come può essere esercitato il diritto di audit;
• come avviene la cancellazione o restituzione dei dati alla cessazione del contratto.

La sovranità digitale, quindi, non coincide con la sola localizzazione geografica del dato. È un concetto più ampio che comprende controllo, resilienza, dipendenza tecnologica, continuità operativa, portabilità e capacità dell’amministrazione di esercitare effettivamente i propri poteri di governo sul servizio.

NIS2 e AI Act per i CIO: la governance come funzione strategica

La convergenza tra NIS2 e AI Act modifica profondamente il modo in cui le organizzazioni devono governare cloud e intelligenza artificiale.

L’esternalizzazione dell’infrastruttura verso un cloud provider e l’utilizzo di modelli fondazionali non eliminano il rischio: ne modificano la distribuzione e rendono indispensabile una capacità di governo della filiera tecnologica.

Per il CIO questo significa passare da un modello centrato sul controllo del perimetro a un modello fondato su:

• inventario degli asset e dei sistemi di IA;
• classificazione del rischio;
• gestione della supply chain;
• sicurezza contrattuale;
• monitoraggio continuo;
• gestione degli incidenti;
• formazione;
• controllo dei costi;
• documentazione delle decisioni.

Il rapporto con il Cloud Service Provider non può più essere considerato una semplice relazione di outsourcing. Il contratto diventa uno strumento di sicurezza, continuità operativa e compliance.

Allo stesso modo, l’adozione dell’IA non può essere affidata esclusivamente alle singole strutture operative. Ogni organizzazione deve sapere quali sistemi vengono utilizzati, per quali finalità, con quali dati, sotto quale responsabilità e con quali controlli.

La sfida dei prossimi anni non sarà quindi soltanto adottare più cloud o più intelligenza artificiale, ma costruire un modello nel quale innovazione, sicurezza, conformità e sostenibilità economica siano governate come parti dello stesso sistema.

Per i CIO italiani, NIS2 e AI Act rappresentano in questo senso non soltanto nuovi obblighi di compliance, ma l’occasione per trasformare la gestione del rischio tecnologico in una vera funzione strategica di governance.