AI Act rinviato.
La resilienza no.

Il 29 giugno 2026 il Consiglio UE ha dato il via libera definitivo al Digital Omnibus sull’AI: gli obblighi dell’AI Act (Regolamento UE 2024/1689) per i sistemi ad alto rischio, che sarebbero scattati il 2 agosto 2026, slittano al 2 dicembre 2027 — e al 2 agosto 2028 per quelli integrati in prodotti. In molte aziende il dossier è stato archiviato con un sospiro di sollievo: «se ne riparla nel 2027». È la lettura sbagliata. Gli obblighi di resilienza dei processi che dipendono dall’AI non arrivano solo dall’AI Act — e il calendario di NIS2 e DORA non è slittato di un giorno.

Cosa è stato rinviato davvero (e cosa no)

Il rinvio riguarda solo gli obblighi per i sistemi ad alto rischio — quelli dell’Annex III (tra cui HR analytics e valutazione dei candidati, biometria, credito, gestione di infrastrutture critiche) e i requisiti dell’articolo 15 su accuratezza, robustezza e cybersecurity. Tutto il resto segue il calendario originale, e un obbligo è stato persino anticipato:

Da notare il dettaglio della trasparenza: chi genera o manipola contenuti con l’AI — testi pubblicati, immagini, audio — dovrà renderlo riconoscibile prima di quanto previsto in origine. Il rinvio non è un condono generalizzato: è una redistribuzione delle scadenze. Per il quadro completo degli obblighi abbiamo una pagina dedicata all’AI Act.

Il calendario che non è slittato: NIS2 e DORA

Ecco il punto che molte letture del rinvio ignorano: la continuità operativa dei sistemi AI non è un’invenzione dell’AI Act. La direttiva NIS2 (art. 21, par. 2, lettera c, recepita dall’art. 24 del D.Lgs. 138/2024) impone ai soggetti essenziali e importanti «continuità operativa, come la gestione dei backup e il ripristino in caso di disastro, e gestione delle crisi» — e le misure di sicurezza diventano obbligatorie da ottobre 2026, tra tre mesi, non nel 2027. La norma non distingue tra software tradizionale e sistemi AI: se un processo critico dipende da uno strumento di intelligenza artificiale, il piano di continuità deve coprire anche quello.

Per il settore finanziario il discorso è già al presente: DORA (Regolamento UE 2022/2554) è applicabile dal 17 gennaio 2025 e richiede politiche di continuità ICT (art. 11), backup e ripristino (art. 12) e test di resilienza operativa digitale (artt. 24-26) — che includono i servizi ICT di terze parti, categoria in cui i servizi AI in cloud rientrano a pieno titolo. Chi fornisce servizi a banche, assicurazioni o intermediari se lo sente già chiedere nei questionari dei fornitori.

La sintesi scomoda: per un soggetto NIS2 che usa l’AI in un processo critico, il rinvio dell’AI Act cambia poco o nulla. L’obbligo di garantire che quel processo sopravviva a un guasto del sistema AI esiste già — e la scadenza vera è ottobre 2026.

La lezione CrowdStrike, due anni dopo

Esattamente due anni fa, il 19 luglio 2024, un aggiornamento difettoso del sensore CrowdStrike Falcon mandò in crash circa 8,5 milioni di dispositivi Windows nel giro di poche ore: voli a terra, ospedali in modalità di emergenza, banche ferme. La lezione non riguardava CrowdStrike: era che interi processi aziendali dipendevano da un singolo componente software di un singolo fornitore, e nessun piano di continuità lo aveva messo in conto.

Con l’AI la stessa dipendenza è più subdola, perché spesso non risulta da nessun inventario: il preventivatore che «funziona con l’AI» del gestionale, il flusso documentale che passa da un modello in cloud, l’assistente che il commerciale usa per le offerte. E i sistemi AI hanno modi tutti loro di fermarsi: un fornitore che cambia modello o listino, un degrado di qualità delle risposte, e persino un blocco regolatorio — a giugno 2026 il governo USA ha sospeso per quasi tre settimane l’export di uno dei modelli AI più avanzati sul mercato, e chi lo aveva in produzione senza alternativa è rimasto a guardare. Il piano di continuità che assume «il servizio AI c’è sempre» non è un piano: è una speranza.

Cosa fare adesso: quattro mosse concrete

Il tempo guadagnato con il rinvio vale qualcosa solo se viene usato. Quattro azioni, in ordine:

• 1Inventario delle dipendenze AI — quali processi si appoggiano a sistemi AI, inclusi quelli nascosti dentro SaaS e gestionali di terze parti. Se il fornitore del gestionale ha aggiunto «funzioni AI» all’ultimo aggiornamento, quella è una dipendenza nuova che ieri non c’era.
• 2Fallback manuale documentato — per ogni processo critico che usa l’AI, una procedura scritta che descriva come si lavora senza: chi fa cosa, con quali strumenti, per quanto tempo è sostenibile. È il requisito minimo su cui NIS2, DORA e AI Act convergono.
• 3RTO e RPO anche per i sistemi AI — portare le dipendenze AI dentro il piano di disaster recovery esistente, con obiettivi di ripristino definiti e test periodici — un piano mai testato è documentazione, non protezione.
• 4Chi rientra nell’Annex III usi bene il rinvio — HR analytics, valutazione candidati, credito, biometria: la documentazione dell’articolo 15 (robustezza, ridondanza, piani fail-safe) ora ha una scadenza al 2 dicembre 2027. Diciotto mesi ben spesi valgono più di una corsa all’ultimo trimestre.

I framework per farlo esistono già: ISO/IEC 27001 per la sicurezza delle informazioni e ISO 22301 per la continuità operativa. Chi li ha implementati — noi siamo certificati ISO/IEC 27001, 27017, 27018 e ISO 9001 — estende il perimetro ai sistemi AI; chi non li ha, ha un motivo in più per partire dal backup e disaster recovery, che di ogni piano di continuità è il fondamento.