Il 12 giugno 2026 il governo statunitense ha notificato ad Anthropic una direttiva di controllo all’esportazione.

Il provvedimento vieta l’accesso ai modelli Claude Mythos 5 e Claude Fable 5 a qualunque cittadino non statunitense, indipendentemente dalla sua posizione geografica, inclusi i dipendenti non americani della stessa Anthropic.

Non potendo applicare il blocco in modo selettivo senza compromettere l’intera infrastruttura, l’azienda ha scelto di disattivare entrambi i modelli a
livello globale, per tutti i clienti.

Perché Mythos è diverso da tutto ciò che lo ha preceduto

La lettera formale non specificava la natura esatta della minaccia alla sicurezza nazionale.

Anthropic ritiene che l’origine del provvedimento sia una tecnica di bypass, un jailbreak non universale, capace di sbloccare in un caso specifico alcune capacità cyber offensive del modello.

Inoltre, sostiene che la stessa tecnica sia replicabile sui modelli concorrenti già liberamente disponibili sul mercato.

Ma, per capire la posta in gioco, bisogna isolare la capacità tecnica che ha reso Mythos un caso a parte nel panorama dei modelli frontiera: la sua efficacia, fuori scala, nell’individuare vulnerabilità software, incluse falle rimaste latenti per anni.

Il modello mostra un livello di autonomia e di profondità di ragionamento superiore a qualsiasi tool di vulnerability research automatizzato visto finora.

Il moltiplicatore di potenza per la scoperta di zero-day a fini offensivi

Ed è proprio questa capacità ad aver attirato l’interesse delle agenzie governative per usi difensivi: la stessa che, sottratta al controllo dei safeguard, diventa un moltiplicatore di potenza per la scoperta di zero-day a fini offensivi.

Anthropic trattava già Mythos come un asset a duplice uso, ben prima dell’intervento governativo:

• Mythos 5, la versione “piena”, riservata a un perimetro selezionato di partner istituzionali e aziendali per programmi di hardening cyber.
• Fable 5, la versione pubblica, costruita sullo stesso modello ma filtrata da classificatori pensati per bloccare le risposte nelle aree più sensibili: cybersecurity offensiva e biotecnologia.

I safeguard

Il punto tecnico cruciale è questo: i safeguard erano già stati sottoposti a migliaia di ore di red-teaming, da parte del governo USA, dell’AI Security Institute britannico e di terze parti indipendenti, senza che emergesse alcun jailbreak universale.

Il problema che ha innescato la direttiva sembra essere un caso “narrow”, stretto: la richiesta al modello di leggere una codebase specifica e correggerne le falle.

Una prospettiva possibile: non stiamo parlando di un exploit universale, che funziona sempre e ovunque, ma di un comportamento limite riproducibile solo in un contesto molto specifico.

È il classico falso negativo che capita, prima o poi, in qualunque sistema di filtraggio basato su classificatori.

La vera domanda: cosa significa questo blocco

In termini di risk assessment esistono almeno quattro letture plausibili. Meglio non sceglierne una per fede, e tenerle tutte aperte, sul radar, per seguire come evolve la vicenda.

Il rischio tecnico è reale e proporzionato

Se esiste anche un solo percorso, per quanto stretto, capace di estrarre capacità di scoperta zero-day senza supervisione, il rischio di proliferazione è concreto.

Un attore statale o un gruppo cyber-criminale motivato non ha bisogno di un jailbreak comodo: gli basta che funzioni una volta sola, sul bersaglio giusto.

In questa lettura, la reazione drastica del governo è una misura precauzionale coerente con la posta in gioco.

Una faida geopolitica tra Anthropic e l’amministrazione USA

Il provvedimento non nasce nel vuoto. Pochi mesi fa il Dipartimento della Difesa USA aveva etichettato Anthropic come “rischio di supply chain”, una designazione storicamente riservata ad attori stranieri ostili, dopo il fallimento di alcuni negoziati commerciali, oggi oggetto di una causa legale pendente.

Il blocco di Mythos potrebbe quindi essere un ulteriore atto di pressione politica, dentro una relazione già conflittuale.

Un esperimento di governance globale

Lo strumento scelto è il controllo delle esportazioni, una normativa pensata per armamenti e tecnologie fisiche a duplice uso, mai applicata prima a un software commerciale distribuito via API.

È possibile che l’amministrazione stia testando, di fatto, un precedente giuridico: la possibilità di ritirare un modello AI dal mercato sulla base di valutazioni di rischio interne, senza un processo trasparente di contestazione.

Per chi gestisce il vendor risk questo significa una cosa sola: ogni fornitore AI può essere richiamato in modo unilaterale, senza preavviso.

Il paradosso del posizionamento di Anthropic

Anthropic ha costruito il proprio brand sull’idea che i modelli frontier fossero troppo rischiosi per una distribuzione di massa, usando spesso un linguaggio preso in prestito dal controllo delle armi.

C’è un’ironia piuttosto evidente in tutto questo: un’azienda che per anni ha chiesto al governo di normare e bloccare i deployment non sicuri si ritrova oggi vittima della stessa logica burocratica che ha contribuito a legittimare.

I Key takeaways operativi

Al di là di torti e ragioni, la vicenda introduce subito quattro voci nuove nel Risk Register.

Il rischio di “sovranità del vendor” adesso è reale, non più teorico. Fino a ieri il rischio legato ai fornitori AI si limitava a data handling, residency dei dati e SLA.

Oggi si aggiunge una componente geopolitico-regolatoria: un modello può essere spento per decreto, da un giorno all’altro.

Chi aveva integrato Fable 5 o Mythos 5 in pipeline critiche, SOC, vulnerability management, code review, si è svegliato senza lo strumento.

Poi c’è il blocco della catena di montaggio del codice. Molte aziende stavano sperimentando Fable 5 direttamente nelle pipeline di sviluppo, per il controllo di sicurezza del codice prima del rilascio in produzione.

Il blocco improvviso non ha solo tolto un consulente virtuale: ha interrotto i processi di deployment automatizzati di chi aveva legato il “via libera” al superamento del filtro AI.

La dimostrazione, se ce ne fosse bisogno, che l’AI non è più solo un tool di consultazione, ma un componente infrastrutturale a tutti gli effetti.

Le implicazioni (per le aziende italiane ed europee) nel perimetro di NIS2, DORA e AI Act

Per chi si occupa di sicurezza informatica in Europa la vicenda non si chiude con l’analisi geopolitica.

È un caso che accende, nello stesso momento, tre framework normativi diversi: la Direttiva NIS2, il Regolamento DORA e l’AI Act.

Nascono con finalità diverse, ma finiscono per guardare lo stesso identico problema: la dipendenza da un fornitore tecnologico extra-UE che può smettere di erogare un servizio per decisione unilaterale di un’autorità di un paese terzo.

Ognuno dei tre lo legge da un’angolazione diversa, e un’azienda che non li mette in relazione rischia di gestire lo stesso incidente tre volte, in modo scoordinato.

NIS2: il fornitore AI come “fornitore rilevante” della catena di approvvigionamento

Il Decreto Legislativo 138/2024, che recepisce la Direttiva NIS2, impone ai soggetti essenziali e importanti di includere la sicurezza della catena di approvvigionamento tra gli elementi obbligatori delle proprie misure di gestione del rischio (art. 24).

Fino a pochi mesi fa, per i fornitori di modelli AI, questo era un obbligo più teorico che pratico.

Con la Determinazione ACN n. 127437/2026, del 13 aprile 2026, l’Agenzia per la Cybersicurezza Nazionale ha reso la cosa concreta: ogni soggetto NIS deve identificare e dichiarare sulla piattaforma ACN i propri “fornitori rilevanti”, e il criterio per stabilirlo è quello della non fungibilità.

Un fornitore è rilevante non per il valore del contratto, ma perché, se la fornitura si interrompe, non c’è un’alternativa attivabile in tempi compatibili con la continuità del servizio.

L’esempio

Difficile trovare un esempio più calzante. Le aziende che avevano portato Fable 5 o Mythos 5 dentro le pipeline di vulnerability management, code review o controllo del SOC, proprio gli scenari citati sopra, e che non avevano un fornitore alternativo già pronto, hanno appena ricevuto la prova empirica della propria non fungibilità.

Se quel fornitore non era stato dichiarato “rilevante” sulla piattaforma ACN prima del blocco, l’azienda ha un doppio problema: un gap di compliance retroattivo (la finestra di aggiornamento annuale va dal 15 aprile al 31 maggio) e, soprattutto, l’assenza di un piano di continuità che quella dichiarazione avrebbe dovuto portare con sé.

Le sanzioni NIS2 per i soggetti essenziali arrivano fino a 10 milioni di euro o al 2% del fatturato globale, ma il danno più immediato resta quello già descritto: l’arresto operativo delle pipeline di sicurezza.

DORA: i 3 obblighi che il blocco rende verificabili

Per le entità finanziarie europee, oltre 22.000 soggetti nel perimetro DORA tra banche, assicurazioni, gestori di fondi e fornitori di servizi di pagamento, il caso è ancora più diretto.

Il Regolamento (UE) 2022/2554 impone tre obblighi che il blocco rende immediatamente verificabili:

• Il registro delle informazioni (art. 28) richiede che ogni contratto con un fornitore ICT, inclusi i fornitori di modelli AI usati per attività regolamentate come fraud detection, AML screening o vulnerability management interno, sia documentato e aggiornato con scadenza annuale, fissata a marzo. Se Fable 5 o Mythos 5 non compaiono in quel registro perché considerati “solo un tool di supporto”, probabilmente c’è già una lacuna.
• La valutazione del rischio di concentrazione (art. 29) chiede di valutare l’eccessiva dipendenza da un singolo fornitore, o da un gruppo ristretto. Il blocco di Mythos è un caso da manuale, di fatto: chi aveva affidato una funzione di sicurezza critica a un unico fornitore AI, senza alternative pronte, ha vissuto esattamente lo scenario che l’art. 29 chiede di prevenire.
• Le clausole contrattuali minime, con l’exit strategy (art. 30): non basta un diritto di recesso scritto nel contratto, serve un piano operativo di migrazione. Se non c’era nulla di simile, oggi l’azienda finanziaria deve spiegare, in caso di ispezione, come ha gestito un evento che avrebbe dovuto avere già pianificato.

ESA, EBA, ESMA, EIOPA, hanno già designato 19 fornitori come Critical Third-Party Provider, tra cui i principali hyperscaler cloud, sottoponendoli a vigilanza diretta tramite Joint Examination Team.

Il caso Mythos è un argomento in più per chi pensa che lo stesso regime di
designazione dovrebbe estendersi, prima o poi, anche ai fornitori di modelli AI frontier, e non solo all’infrastruttura cloud.

Un fornitore che alimenta funzioni critiche di centinaia di entità finanziarie europee soddisfa, nei fatti, gli stessi criteri di rilevanza sistemica già usati per i cloud provider.

AI Act: la natura “a rischio sistemico” di Mythos

Il Capo V dell’AI Act, articoli 51-56, pienamente applicabile dal 2 agosto 2025, disciplina i modelli GPAI.

Un modello supera la soglia di presunzione di rischio sistemico quando la potenza di calcolo cumulativa di addestramento eccede 10²⁵ FLOP, o quando la Commissione lo classifica così di sua iniziativa.

Considerando quanto descritto qui, un’efficacia “di gran lunga superiore a qualsiasi tool di vulnerability research automatizzato” nella scoperta di zero-day, è plausibile che Mythos 5, e per estensione lo stesso modello che sta sotto Fable 5, rientri già in questa categoria:le capacità cyber-offensive sono esplicitamente tra le aree di rischio sistemico che l’AI Act chiede ai fornitori di sorvegliare.

Questo comporta per Anthropic, come fornitore, obblighi aggiuntivi previsti dall’art. 55:

• valutazione tramite adversarial testing,
• mitigazione dei rischi identificati,
• sicurezza cibernetica del modello rafforzata
• e, punto centrale per come si è svolta la vicenda, l’obbligo di documentare e segnalare incidenti gravi all’AI Office europeo e alle autorità nazionali competenti (in Italia l’ACN, che avrà piena operatività di vigilanza dal 3 agosto 2026).

Se il jailbreak “narrow” che ha fatto scattare la direttiva americana ha davvero sbloccato capacità cyber-offensive senza supervisione, si tratterebbe, tecnicamente, di un evento rilevante, al di là della direttiva di export control statunitense.

Gli obblighi per i modelli

Per le aziende europee che usano il modello restano comunque obblighi propri:

• l’AI literacy del personale, vincolante già da febbraio 2025;
• e, per chi ha costruito su Fable 5 sistemi che rientrano nell’Allegato III, come credit scoring o fraud detection, la documentazione tecnica e la conformity assessment richieste entro il 2 agosto 2026.

Dimostrare quella conformità con un fornitore che oggi non è più accessibile, e che potrebbe non tornarlo nei tempi previsti, è un problema molto concreto per chi è a un passo dalla scadenza.

Inoltre, l’art. 54 obbliga i fornitori GPAI extra-UE a nominare un rappresentante autorizzato nell’Unione: le aziende che si sentono danneggiate dal blocco potrebbero rivolgersi prima a questa figura, come interlocutore di responsabilità contrattuale, prima ancora che a un’autorità regolatoria.

L’effetto della direttiva di export control sui fornitori

Per chi fa risk management il punto delicato non è la conformità a ciascun framework preso da solo, ma la cecità che si crea quando i tre vengono gestiti in compartimenti separati, IT, compliance, legale, senza che nessuno li guardi insieme.

Unfornitore AI che smette di funzionare per una direttiva di export control di un paese terzo è, nello stesso momento, un evento NIS2 (rischio di filiera), un evento DORA (rischio di concentrazione su un fornitore ICT) e un evento AI Act (interruzione di un sistema il cui fornitore del modello ha obblighi specifici).

I sistemi di GRC tradizionali, pensati per gestire ogni framework per conto suo, non sono fatti per vedere arrivare questo tipo di rischio composito.

I rischi concreti per le aziende italiane ed europee

• Sul piano operativo, l’interruzione delle pipeline CI/CD non resta isolata: se l’azienda colpita fornisce a sua volta servizi a soggetti NIS o DORA, l’effetto si propaga lungo la filiera, e il problema di un fornitore diventa un problema di “non fungibilità” anche per i propri clienti.
• Sul piano della compliance, il rischio è cumulativo: una sola lacuna, exit strategy mancante, fornitore rilevante non dichiarato, documentazione AI Act incompleta, può generare esposizione su più framework insieme. Nella prassi italiana il cumulo di sanzioni AI Act e GDPR per le imprese più grandi ha già, in alcune proiezioni, superato i 50 milioni di euro.
• Sul versante contrattuale e reputazionale, i grandi clienti enterprise che chiedono conformità NIS2 o DORA come condizione contrattuale tendono a penalizzare chi dipende da un solo modello AI senza un piano di continuità credibile.
• Sul fronte geopolitico, né l’Italia né l’Unione europea hanno oggi strumenti per far tornare l’accesso a un modello bloccato da una direttiva di export control statunitense. È un argomento in più, non solo industriale ma anche regolatorio, a favore di una maggiore sovranità tecnologica europea: modelli open-weight, cloud sovrano, fornitori alternativi qualificabili in tempi rapidi.

Una checklist in otto punti

• Mappare subito, lato NIS2: controllare se i fornitori di modelli AI usati in funzioni di sicurezza critiche sono già dichiarati “fornitori rilevanti” sulla piattaforma ACN, applicando il criterio di non fungibilità.
• Aggiornare il Registro delle Informazioni DORA (art. 28): inserire ogni contratto con fornitori di modelli AI, anche quando il loro ruolo sembrava “accessorio” rispetto ai sistemi core.
• Rifare, o rivedere, la valutazione del rischio di concentrazione (art. 29) per ogni funzione critica che dipende da un solo fornitore AI, qualunque sia la sua reputazione.
• Controllare le clausole contrattuali in essere: c’è una exit strategy operativa, un SLA sulla continuità, un diritto di audit e, soprattutto dopo questo precedente, un obbligo di notifica preventiva su eventuali modifiche regolatorie che potrebbero limitare l’accesso?
• Classificare ogni sistema costruito su un modello GPAI, soprattutto se a rischio sistemico, e tenere una documentazione tecnica che non dipenda solo da ciò che fornisce il vendor, per evitare un lock-in anche documentale.
• Costruire davvero una strategia multi-modello: qualificare almeno un fornitore alternativo, anche europeo o open-weight, per ogni funzione critica, con test periodici di switch-over, non solo una clausola sulla carta.
• Portare il “rischio di sovranità del vendor” dentro i piani di Business Continuity e Disaster Recovery, con la stessa serietà con cui si tratta il guasto di un data center.
• Costruire una governance unica del rischio AI/ICT, con un responsabile che segua insieme gli adempimenti NIS2 (piattaforma ACN), DORA (registro informazioni) e AI Act (documentazione tecnica), evitando di lavorare tre volte sulla stessa cosa.

Cosa monitorare nelle prossime settimane

Per capire dove sta andando la governance, ci sono almeno quattro filoni da seguire:

• L’esito del contenzioso legale tra Anthropic e il DoD sulla designazione di rischio supply chain.
• I tempi e le modalità di un eventuale ripristino dell’accesso: dicono molto sulla reale gravità del rischio tecnico, rispetto alle dinamiche politiche.
• La reazione degli altri governi, a partire da quello britannico. Se il blocco spingerà verso sanzioni o restrizioni speculari, si va verso una frammentazione regolatoria dell’AI su base nazionale, uno scenario con effetti pesanti sul mercato cyber globale.
• Le prime applicazioni pratiche di NIS2, DORA e AI Act a casi di interruzione di fornitori AI extra-UE: saranno il precedente operativo da cui capire quanto sono davvero severi questi framework, sul rischio di fornitore unico.

La verità più scomoda è che non esiste ancora un quadro normativo maturo per gestire il richiamo di un modello AI commerciale né una vera interoperabilità tra i framework europei che dovrebbero proteggere le aziende da questo stesso rischio.

Questo caso non è l’eccezione alla regola. È solo il primo della lista.