La Banca centrale europea (BCE) vuole capire se le banche dell’area euro siano davvero pronte al salto di scala del rischio cyber causato dall’intelligenza artificiale (AI).

Domani, secondo quanto riportato dal Financial Times, l’istituto di Francoforte riunirà i principali gruppi bancari dell’eurozona per discutere l’impatto di Claude Mythos Preview, il modello di Anthropic che nelle ultime settimane ha spostato in avanti la frontiera della ricerca automatizzata di vulnerabilità software.

Il problema: se un modello trova falle più in fretta di quanto una banca riesca a correggerle, il vantaggio passa agli attaccanti. In un settore dove convivono mainframe, software legacy, fornitori terzi, canali digitali, applicazioni cloud e infrastrutture di pagamento, comprimere i tempi di remediation da settimane a ore è un cambiamento che tocca governance, change management e resilienza sistemica.

Perché il caso Mythos ha acceso l’allarme AI nella BCE

Anthropic ha diffuso il 22 maggio un primo aggiornamento del progetto Glasswing, l’iniziativa con cui sta facendo usare Mythos a un gruppo ristretto di partner per individuare vulnerabilità nei software più critici. Il dato che ha attirato maggiore attenzione è questo: oltre 10mila vulnerabilità high o critical sarebbero emerse nell’attività svolta con circa 50 partner.

Quel numero, però, va letto con precisione. Nel dashboard pubblico di coordinated vulnerability disclosure, sempre aggiornato al 22 maggio 2026, Anthropic indica 1.596 vulnerabilità già disclose su 281 progetti open source, di cui 97 già corrette. La differenza non è un dettaglio: una cosa è la mole di problemi individuati o stimati, altra cosa è il sottoinsieme già validato, triagiato, notificato ai maintainer e gestito con disclosure responsabile.

Fino a ieri il collo di bottiglia era trovare la vulnerabilità. Ora il collo di bottiglia diventa validarla, notificare chi deve intervenire e distribuire la patch prima che l’informazione si trasformi in un vantaggio per l’attaccante.

Il vero rischio per le banche non è la scoperta della falla, ma l’N-day race

Nel lessico della sicurezza il passaggio decisivo è quello tra zero-day e N-day. Lo zero-day è la vulnerabilità sconosciuta al vendor e non ancora corretta. L’N-day è la vulnerabilità già emersa, spesso già corretta con una patch, ma ancora sfruttabile perché gli utenti non hanno aggiornato.

Per una banca il problema può diventare più grave proprio nella fase successiva alla correzione. Quando il produttore rilascia una patch, infatti, fornisce indirettamente anche una mappa tecnica di cosa è stato corretto. Con tecniche di patch diffing, reverse engineering e generazione automatica di exploit, un attore ostile può ricostruire più rapidamente il punto debole e trasformarlo in un attacco operativo. Se l’istituto finanziario non ha ancora aggiornato i sistemi, si apre una finestra di esposizione molto più pericolosa di prima.

Come detto da Frank Elderson, membro dell’Executive Board della BCE e vicepresidente del Consiglio di vigilanza, la Bce chiederà alle banche di accelerare: devono essere in grado di applicare gli aggiornamenti in ore o minuti, non più in settimane secondo tempi che oggi sono ancora considerati fisiologici dal mercato.

Mythos AI, banche e BCE: perché il settore finanziario è un bersaglio più fragile di quanto sembri

Le banche hanno strutture di sicurezza mature, team dedicati, controlli regolamentari e investimenti elevati. Ma hanno anche caratteristiche che le rendono particolarmente esposte a una AI capace di accelerare la ricerca di vulnerabilità.

Legacy, dipendenze e finestre di manutenzione

Molti gruppi bancari operano su architetture stratificate: core banking, middleware, sistemi di autenticazione, software di rete, appliance di sicurezza, applicazioni internet-facing, sistemi di pagamento, strumenti di trading e un ecosistema di fornitori esterni. In questo contesto, patchare non significa soltanto installare un aggiornamento.

Significa verificare compatibilità, evitare disservizi, coordinare più team, ottenere approvazioni, testare rollback, rispettare finestre di manutenzione, controllare gli impatti regolamentari e gestire dipendenze spesso opache tra applicazioni. È una macchina complessa, e proprio questa complessità allunga i tempi.

Terze parti e concentrazione del rischio

La seconda fragilità è la dipendenza da fornitori Ict e da componenti software condivisi. Se un modello come Mythos individua con efficacia debolezze in librerie open source, appliance, stack middleware o prodotti ampiamente adottati, la stessa vulnerabilità può propagare rischio su più banche nello stesso momento. Qui il problema non è il singolo incidente, ma la simultaneità.

La vigilanza europea insiste da tempo su questo punto. Nelle priorità di vigilanza 2026-2028, la BCE colloca tra i fronti chiave la resilienza operativa, la gestione del rischio cyber e il rischio Ict di terze parti. Con l’entrata in applicazione del Dora dal 17 gennaio 2025, questi aspetti non sono più solo buone pratiche: diventano una disciplina di governo, testing, reporting e remediation con aspettative molto più stringenti.

Che cosa rende l’AI offensiva diversa dai tool tradizionali

La novità non è che esistano scanner, piattaforme di code analysis o sistemi di fuzzing. La novità è che modelli come Mythos combinano diverse capacità in una sola catena di lavoro: comprensione del codice, analisi del contesto, ragionamento multi-step, generazione di proof of concept, reverse engineering e prioritarizzazione delle vulnerabilità.

Anthropic, nella documentazione tecnica pubblicata ad aprile, descrive casi in cui Mythos ha supportato la ricerca di vulnerabilità severe e la costruzione di exploit funzionanti con una velocità difficile da ottenere con processi manuali. Se questa capacità si stabilizza e si diffonde, l’impatto per le difese bancarie è chiaro: si accorcia drasticamente il tempo disponibile tra individuazione della falla e possibile sfruttamento.

Certo, al momento l’accesso a Mythos è ancora ristretto. Il punto è che la soglia tecnica per industrializzare l’offensiva si sta abbassando e che il mercato produrrà con ogni probabilità modelli alternativi, tool open source specializzati e workflow ibridi più accessibili.

Una tabella per capire dove si concentra il rischio

Questi sono i numeri e i segnali che spiegano perché il tema è salito al livello della vigilanza finanziaria europea

Che cosa può chiedere la BCE alle banche a fronte dell’AI e Mythos

Il confronto del 26 maggio ha senso se produce un cambio di priorità concreto. Per una banca, oggi, accelerare la cyber resilience significa almeno cinque cose.

1. Inventario reale degli asset e delle dipendenze

Non basta sapere quali server esistono. Serve una mappa aggiornata di asset critici, software bill of materials, dipendenze di libreria, esposizioni internet-facing, collegamenti tra applicazioni e fornitori esterni. Senza questa base, la patch urgente resta bloccata nella ricerca manuale dei sistemi impattati.

2. Patch orchestration con logiche d’emergenza

Molti processi sono costruiti per change window periodiche. Il nuovo scenario richiede percorsi fast-track, con criteri ex ante per classificare le patch che devono saltare la coda, ambienti di test pronti, rollback automatizzati e approvazioni snelle per gli interventi su vulnerabilità ad alta probabilità di weaponization.

3. Compensating controls immediati

Quando la patch non è applicabile subito, la banca deve poter attivare in tempi rapidi segmentazione, isolamento di servizi, virtual patching, Waf, regole Edr, hardening temporaneo, disattivazione di funzioni esposte e monitoraggio mirato degli indicatori di compromissione. In altre parole, serve una difesa intermedia che riduca la finestra utile all’attaccante.

4. Testing realistico e threat-led

Il quadro normativo europeo offre già un riferimento. L’aggiornamento del framework Tiber-EU allineato a Dora spinge verso test più realistici, intelligence-led e centrati sulle funzioni critiche. Per il settore bancario, questo significa simulare non l’incidente generico, ma catene d’attacco plausibili su identità privilegiate, terze parti, ambienti cloud, software di rete e processi di pagamento.

5. Condivisione interbancaria e con i fornitori

Se alcune banche o grandi gruppi internazionali hanno accesso anticipato a strumenti più avanzati, la vigilanza può chiedere che le lesson learned vengano condivise più rapidamente con il resto del sistema. Non per diffondere dettagli sensibili, ma per accelerare indicatori di rischio, priorità di remediation, classi di vulnerabilità emergenti e pattern di attacco osservati.

Bce, AI Mythos: il rischio sistemico non è teorico

La BCE guarda a questo tema da una prospettiva che va oltre il singolo breach. Un incidente cyber grave in una banca importante può propagarsi attraverso canali operativi, finanziari e di fiducia. È la logica che l’istituto ha già richiamato nel lavoro su cyber resilience stress testing e nelle analisi macroprudenziali: il danno non si esaurisce nel sistema colpito, ma può allargarsi a pagamenti, liquidità, trading, servizi ai clienti, comunicazioni di mercato e continuità di funzioni critiche.

In questo quadro, l’AI offensiva introduce una forma nuova di stress: più vulnerabilità individuate nello stesso tempo, su basi software condivise, con finestra di sfruttamento più corta e maggiore capacità di automazione degli attaccanti. La combinazione è sufficiente per portare il tema dal livello Ciso al livello di stabilità finanziaria.

La partita si gioca prima dell’attacco

Il caso Mythos dimostra che il modello operativo della difesa bancaria è troppo lento rispetto alla velocità che i nuovi strumenti stanno rendendo possibile.

La Bce vorrà verificare se le banche dell’area euro abbiano già processi, automazione, testing e governo delle dipendenze adeguati a un contesto in cui la vulnerabilità non resta nascosta per mesi, ma può essere trovata, compresa e sfruttata in tempi molto più brevi. È su questa compressione del tempo che si misurerà la resilienza reale del sistema finanziario europeo.

La Bce cercherà anche di ottenere maggiore collaborazione dalle banche Usa, che a differenza delle nostre (e dell’Ue in generale) non hanno accesso a Mythos. C’è dietro anche una questione geopolitica e di sovranità digitale dell’Ue, certo. Importante e da risolvere.

Ma è una partita di lungo periodo. Nell’immediato alle banche è chiesto di fare un salto di maturità e non è detto che tutte siano in grado di farlo in tempo.