Dieci ore per reagire: il board non è pronto

L'intelligenza artificiale offensiva ha compresso il tempo di exploitation da mesi a ore. Il modello di difesa della vostra organizzazione è ancora calibrato sul calendario sbagliato.

Il crollo della finestra di reazione

Tra il 2023 e il 2026, il tempo medio che intercorre tra la scoperta di una vulnerabilità e il suo sfruttamento attivo è passato da cinque mesi a dieci ore. Non è un'ipotesi accademica: è la traiettoria che le evidenze di settore stanno confermando con crescente solidità. L'AI agentica applicata alla ricerca offensiva sta generando un volume senza precedenti di vulnerabilità individuate in modo automatizzato. I modelli più avanzati raggiungono risultati convincenti sulle falle semplici, prestazioni modeste su quelle di complessità media e risultati ancora scarsi sulle vulnerabilità più severe. Lo ha ribadito anche Ari Herbert-Voss, tra i primi profili di sicurezza assunti da OpenAI e oggi impegnato nella ricerca sulla validazione automatizzata delle vulnerabilità: i modelli frontier non sostituiscono il giudizio umano, lo accelerano sulla fascia bassa dello spettro e lo lasciano scoperto su quella alta. Il risultato è un'asimmetria strutturale: le organizzazioni ricevono più segnali di quanti possano processare, e il collo di bottiglia non è tecnologico. È decisionale.

L'economia rovesciata della difesa

Questo collasso temporale non è un problema del team di sicurezza. È un problema di budget, di modello operativo e di responsabilità manageriale. Se un bug viene sfruttato entro ore dalla sua scoperta pubblica, il patching programmato su cicli settimanali o mensili diventa un esercizio di conformità formale privo di valore protettivo reale. Il board si trova davanti a scelte concrete: investire in capacità di risposta rapida, ristrutturare i team di engineering perché operino in modo nativo con strumenti di intelligenza artificiale, decidere in quale misura costruire internamente o acquistare. Ma il dato più scomodo è un altro. L'attaccante paga solo il costo dei successi. Il difensore paga il costo di ogni singolo falso allarme, di ogni triage che non porta a nulla, di ogni escalation che si rivela vuota. Questa asimmetria economica non si risolve con più tool: si governa con scelte di allocazione e con una ridefinizione chiara di chi risponde di cosa. La pressione non è più solo sul perimetro tecnico. È sul management.

Il paradosso di chi adotta più strumenti

La frizione più insidiosa è organizzativa. L'AI moltiplica in modo esponenziale la superficie di scoperta delle vulnerabilità, ma la capacità interna di filtrarle, prioritizzarle e gestirle resta lineare, umana, limitata. Chi guida la sicurezza si trova davanti a un paradosso operativo che pochi board hanno ancora compreso: più strumenti di discovery automatizzata si adottano, più il team viene sommerso da segnali che richiedono giudizio esperto per essere qualificati. La responsabilità della risposta resta interamente in capo alla funzione sicurezza, ma le risorse per gestire il volume generato dall'automazione non crescono allo stesso ritmo. La promessa di efficienza dell'AI, se non accompagnata da un ridisegno del modello di governo della vulnerabilità, si trasforma in un amplificatore di esposizione. Non è un problema di competenza. È un difetto di architettura organizzativa che nessun acquisto tecnologico può compensare da solo. La domanda non è se servano più strumenti, ma se il modello decisionale sia ancora coerente con la velocità del rischio.

NIS2 e DORA: quando la velocità diventa compliance

Il quadro normativo europeo rende questa accelerazione direttamente rilevante per board e organi di gestione. L'articolo 21 della direttiva NIS2 richiede alle organizzazioni essenziali e importanti misure di gestione delle vulnerabilità e di risposta agli incidenti proporzionate al rischio. Se il rischio cambia velocità, da mesi a ore, la proporzionalità impone un adeguamento dei tempi di reazione. Un piano di patching calibrato su cicli incompatibili con la finestra reale di exploitation rischia di non soddisfare il requisito di proporzionalità. L'articolo 5 della stessa direttiva attribuisce agli organi di gestione la responsabilità diretta di approvare e sovrintendere le misure di gestione del rischio: non è una delega che si esaurisce nella nomina di un responsabile. Il regolamento DORA, per i soggetti finanziari, impone una gestione strutturata del rischio ICT e della resilienza operativa, incluso il monitoraggio continuo delle vulnerabilità. In entrambi i casi, la velocità di risposta non è più un indicatore operativo: è un parametro di conformità implicito.

La domanda che manca nei comitati rischi

Se il tempo di exploitation è crollato a dieci ore, il vostro attuale processo di gestione delle vulnerabilità è dimensionato per reagire prima che un agente AI offensivo sfrutti ciò che un altro agente AI ha appena trovato? È una domanda che non riguarda la tecnologia. Riguarda il disegno organizzativo, la catena di escalation, la capacità reale, non dichiarata, di prendere decisioni operative sotto pressione temporale estrema. Riguarda la coerenza tra ciò che il board approva nei documenti di risk appetite e ciò che accade alle tre di notte quando un exploit è già in circolazione. La risposta non si trova in un tool, in un vendor, in un framework. Si trova nella distanza tra il tempo del rischio e il tempo della vostra organizzazione.

Il rischio non aspetta il prossimo comitato. La vera domanda è se la vostra catena decisionale sia più veloce di un exploit automatizzato, e chi, stanotte, ne risponde davvero.