Paper. What i write

L’artificial intelligence potenzia rilevazione, risposta e ripristino, e nello stesso tempo diventa l’asset più scoperto dei piani di continuità. Un white paper ricostruisce il quadro per le infrastrutture critiche, dal caso CrowdStrike all’articolo 15 dell’AI Act.

Sono le 04:09 UTC del 19 luglio 2024 quando CrowdStrike distribuisce un aggiornamento di configurazione del sensore Falcon. Contiene un difetto logico. Alle 05:27 la distribuzione viene fermata, ma i settantotto minuti di esposizione bastano a mandare in crash circa 8,5 milioni di dispositivi Windows nel mondo: voli cancellati, ospedali costretti alle procedure manuali, un evento che il Government Accountability Office statunitense classifica tra i più estesi IT outage della storia. In un solo sistema sanitario americano, ECU Health, si contano 8.647 blue screen e 729 macchine ripristinate una per una, con chiave BitLocker e avvio in safe mode, mentre il command center resta operativo per una trentina di ore.

In quell’aggiornamento non c’era intelligenza artificiale. Ma il pattern strutturale (un agente con privilegi profondi, installato su una flotta globale, alimentato da update automatici considerati fidati) è esattamente quello con cui oggi distribuiamo gli strumenti di sicurezza basati su AI e con cui domani distribuiremo gli AI agent. Se un file di configurazione ha prodotto questi effetti, un model update difettoso o avvelenato avrebbe la stessa cinetica di propagazione. Parte da qui il white paper «Business Continuity e Disaster Recovery nell’era dell’Artificial Intelligence», una rassegna dedicata alle infrastrutture critiche.

I numeri del contesto li fornisce l’ENISA Threat Landscape 2025: 4.875 incidenti censiti in dodici mesi, il 53,7% a carico dei soggetti essenziali; a inizio 2025 le campagne di phishing supportate da AI superavano l’80% del social engineering osservato a livello globale, e crescono gli attacchi alla AI supply chain. La stessa tecnologia, però, è la migliore alleata di chi difende. Il paper scioglie l’apparente paradosso con una prospettiva dual-use: AI for resilience, l’intelligenza artificiale che potenzia le capability di continuità, e resilience of AI, il sistema che protegge e che va protetto. Due facce che non si lasciano separare, perché ogni capability introdotta apre a sua volta superficie d’attacco e dipendenze.

Sul versante abilitante la rassegna copre sei famiglie di capability, mappate sulle fasi del ciclo di continuità e sulle metriche che migliorano. La manutenzione predittiva converte il guasto subito in fermo programmato; l’anomaly detection sui log, dove il deep learning supera i metodi convenzionali, comprime il tempo di rilevazione; i large language model entrano nei Security Operations Center per il triage degli alert, la sintesi degli incidenti e, alla frontiera della ricerca, la generazione di piani di risposta con tecniche di contenimento delle hallucination. Seguono l’orchestrazione del failover e il self-healing, la difesa dei backup dal ransomware (rilevazione dei pattern di cifratura, selezione dell’ultimo restore point integro) e il digital twin, che trasforma l’esercitazione da evento annuale a processo continuo. Il paper mantiene però un contrappunto costante: la maturità è disomogenea, la detection è in produzione mentre la decisione resta assistiva, e le azioni irreversibili stanno sotto approvazione umana.

Il versante di rischio è organizzato in tre famiglie. Le minacce esogene: deepfake audio e video che colpiscono il punto più fragile dei piani, le comunicazioni di crisi, dove i controlli ordinari sono sospesi per definizione. Gli attacchi ai modelli, classificati dal NIST nel rapporto AI 100-2e2025 (evasion, poisoning, prompt injection), con un tratto che distingue questa classe da ogni guasto convenzionale: il degrado silente. Un sistema compromesso tende a rompersi; un modello avvelenato continua a rispondere, solo peggio, e i cruscotti restano verdi. Le fragilità intrinseche completano il quadro senza bisogno di avversari: model drift, hallucination e automation bias, con la combinazione critica di errori a velocità macchina e vigilanza umana mal calibrata. Sopra tutto, il rischio sistemico: pochi foundation model e pochi hyperscaler, accesso via API, e la lezione del Financial Stability Board sulla concentrazione dei fornitori. Modelli simili commettono errori simili: il guasto individuale diventa common mode failure.

Qui il paper porta il suo contributo metodologico. Gli standard di continuità, ISO 22301 in testa, trattano ancora l’AI come generica risorsa ICT: gli inventari non vedono dataset, feature store, model registry. La proposta è estendere gli strumenti esistenti, non sostituirli. La business impact analysis acquisisce una seconda domanda: non solo che cosa si ferma se l’asset manca, ma quali decisioni peggiorano se degrada senza fermarsi. L’RTO si sdoppia: ripristinare l’artefatto è questione di minuti, ripristinare una capability fidata può richiedere un riaddestramento, e il model recovery time va dimensionato su quello scenario. L’RPO diventa distanza dall’ultimo punto fidato, non dall’ultimo disponibile, perché un poisoning scoperto oggi può essere iniziato mesi fa. E l’impianto MLOps, nato per l’efficienza, si rivela l’infrastruttura di disaster recovery che molte organizzazioni possiedono senza saperlo: il registry è il backup del modello, la pipeline riproducibile è la procedura di ripristino, il lineage dei dati è la precondizione del punto integro. Chiudono il metodo le modalità degradate progettate in anticipo, il kill switch indipendente dal sistema da spegnere e le esercitazioni a AI spenta contro l’atrofia della competenza manuale.

Il quadro giuridico europeo sta trasformando queste pratiche in obblighi. Il passaggio più rilevante è l’articolo 15 dell’AI Act: la robustezza dei sistemi ad alto rischio può essere conseguita con ridondanze tecniche che includono, testualmente, «backup or fail-safe plans». Per la prima volta la continuità entra nel diritto come requisito di prodotto del sistema AI, non solo come misura organizzativa dell’ente; e il quinto paragrafo, imponendo misure contro data poisoning e adversarial examples, trasforma il testing avversario in presidio di conformità. La scadenza è vicina: 2 agosto 2026 per i sistemi dell’Allegato III, che include l’AI nelle infrastrutture critiche. Intorno, NIS2 già oggi elenca continuità, backup e disaster recovery tra le misure minime (in Italia il d.lgs. 138/2024), la direttiva CER presidia la resilienza dei soggetti critici e DORA fa da laboratorio sul rischio da terze parti ICT. Gli standard volontari, da ISO/IEC 42001 al NIST AI RMF che ad aprile 2026 ha avviato un profilo dedicato alle infrastrutture critiche, forniscono i veicoli attuativi. La convergenza è tale che, conclude il paper, chi attua il metodo costruisce con lo stesso investimento la parte sostanziale della conformità.

Il framework finale ricompone il tutto su tre livelli: le capability sopra il ciclo di continuità, i presidi sugli asset AI sotto, la governance intorno, con una scala di maturità in quattro passi (inconsapevole, censito, presidiato, integrato) e indicatori costruiti su un criterio solo: capacità provate, non dichiarate. Il messaggio conclusivo è quasi tradizionale, ed è la sua forza: l’artificial intelligence va trattata con la disciplina riservata a ogni asset critico. Censirla, assegnarle obiettivi di ripristino, progettarne l’assenza, provarla regolarmente. L’era dell’AI non abroga i fondamentali della continuità operativa: ne estende il perimetro. Conviene arrivarci prima che sia il prossimo incidente a dettare l’agenda.