Dodici aziende nella stanza, il vostro board fuori dalla porta

Quando l'AI genera exploit a velocità industriale, chi non ha accesso anticipato difende alla cieca — e le stime di rischio saltano

La macchina che trova ciò che nessuno cercava

Un modello di intelligenza artificiale è oggi in grado di individuare e sfruttare vulnerabilità zero-day presenti nei principali sistemi operativi e browser da dieci, venti, persino ventisette anni. Lo fa in ore, non in mesi. Lo fa senza che l'operatore possieda competenze di sicurezza offensive. Il risultato non è un proof-of-concept accademico: è un exploit funzionante, pronto per l'uso. Prima che questo modello diventasse accessibile al pubblico, il suo sviluppatore ha costituito un consorzio ristretto di dodici organizzazioni, tra cui i principali hyperscaler cloud, vendor di sicurezza e almeno un grande istituto finanziario globale, concedendo loro accesso anticipato per correggere le vulnerabilità nei propri prodotti. Il governo statunitense, come osservato da più voci autorevoli del settore, si è trovato nella posizione di dipendere interamente dalla volontà dei vendor privati di condividere ciò che il modello scopre. Non è un dettaglio: è un'inversione del rapporto tra regolatore e regolato. Va detto che esistono valutazioni indipendenti, incluse quelle dell'UK AI Safety Institute, che sollevano dubbi sulla reale potenza offensiva del modello e sulla robustezza dei target utilizzati nei test. Il punto, però, non è se questo specifico modello sia onnipotente. Il punto è che il meccanismo esiste, funziona e ridefinisce i tempi del gioco.

Budget, processi, piani: tutto tarato sul mondo di ieri

La compressione della finestra tra scoperta di una vulnerabilità e possibilità di sfruttarla cambia le regole operative. Il patching deve avvenire a velocità macchina, ma la quasi totalità delle organizzazioni ha team, processi e catene di approvazione dimensionati su cicli di settimane. Questo non è un problema tecnico risolvibile con un aggiornamento di procedura. È un disallineamento strutturale tra la velocità dell'attacco e la capacità di risposta. Per chi siede in un board, le implicazioni sono dirette: le stime di rischio su cui oggi si basano le decisioni di investimento in sicurezza potrebbero essere obsolete. I piani di risposta agli incidenti, calibrati su scenari in cui l'attaccante impiega giorni o settimane per weaponizzare una vulnerabilità, non reggono un contesto in cui lo stesso risultato si ottiene overnight. La democratizzazione dell'exploit, chiunque con accesso al modello può generare un attacco funzionante senza competenze avanzate, abbassa la barriera d'ingresso per il cybercrime in modo irreversibile. Non si tratta di chiedere più budget. Si tratta di capire se il modello di rischio su cui poggia la vostra governance è ancora valido.

La trappola della responsabilità senza leva

Chi ha la responsabilità della postura di sicurezza dell'organizzazione si trova in una posizione strutturalmente insostenibile. Deve difendere da attacchi che viaggiano a velocità macchina, ma non controlla i tempi di disclosure, quelli li decide il consorzio. Non ha accesso anticipato alle vulnerabilità scoperte dal modello, quel privilegio è riservato ai dodici. Deve negoziare risorse con un board che, nella maggior parte dei casi, non ha ancora metabolizzato il cambio di scala. L'asimmetria è netta: responsabilità piena, leva operativa parziale, informazione incompleta. Il contesto regolatorio amplifica la frizione. Negli Stati Uniti, la supervisione sull'AI offensiva si sta alleggerendo: l'obbligo di reporting sui red-teaming dei modelli AI è stato rimosso, l'agenzia federale per la sicurezza delle infrastrutture è in fase di ridimensionamento. In Europa accade l'opposto: gli obblighi crescono, ma il gap informativo e di risorse resta identico. Il risultato è una governance della sicurezza che opera in un vuoto informativo crescente, con vincoli di compliance che aumentano e strumenti di difesa che non tengono il passo.

Il quadro normativo europeo: obblighi reali, non teorici

Il collegamento tra questo scenario e il framework regolatorio europeo è diretto. La Direttiva NIS2 (2022/2555), all'articolo 21, impone ai soggetti essenziali e importanti l'adozione di politiche di gestione delle vulnerabilità e di divulgazione coordinata. La compressione dei tempi di sfruttamento rende questi obblighi operativamente più gravosi: non basta avere una policy di vulnerability management se la finestra utile per applicarla si riduce a ore. Il Regolamento AI Act (2024/1689) introduce, agli articoli 51 e seguenti, obblighi specifici per i modelli di AI a uso generale che presentano rischio sistemico, inclusi valutazione avversariale, red-teaming e notifica alla Commissione. Un modello capace di generare exploit zero-day a scala industriale rientra con evidenza in questa categoria. Il contrasto con l'approccio statunitense, che ha eliminato i propri obblighi di reporting, rende la posizione europea più esposta ma anche più esigente. Il Regolamento DORA (2022/2554), che disciplina la resilienza operativa digitale nel settore finanziario, aggiunge un ulteriore livello: la partecipazione di un grande istituto bancario globale al consorzio evidenzia come la gestione del rischio ICT di terze parti, tema centrale di DORA, sia già oggi condizionata da dinamiche di accesso privilegiato all'informazione sulle vulnerabilità.

La domanda che manca all'ordine del giorno

Se un modello AI può generare exploit per vulnerabilità che il vostro team di sicurezza non conosce ancora, e la vostra organizzazione non è tra le dodici che ricevono accesso anticipato, su quali basi state comunicando al board che il livello di rischio è sotto controllo? La Cloud Security Alliance ha già esortato i responsabili della sicurezza e i consigli di amministrazione a ricalibrare risorse e automazione senza attendere il primo incidente. Ma il problema non si risolve con una riga di budget in più. Si risolve, se si risolve, con una revisione del modello di governance del rischio che tenga conto di un fatto nuovo: l'informazione sulle vulnerabilità critiche è oggi distribuita in modo asimmetrico, e chi la controlla non è né il regolatore né il difensore, ma chi ha costruito il modello.

Il prossimo consiglio di amministrazione potrebbe non avere questa voce all'ordine del giorno. Il problema è che l'attaccante non aspetta la convocazione.