Hanno spento il modello AI più potente del mondo in tre giorni: il rischio di continuità che nessun contratto copre

La mia pipeline di orchestrazione su oltre cinquanta codebase passa ogni giorno da chiamate API a Claude. Quando il 9 giugno 2026 Anthropic ha reso disponibile Claude Fable 5, il modello di classe Mythos portato in disponibilità generale con un classifier che degrada a Opus 4.8 le richieste sensibili, l'ho integrato nella stessa giornata come modello di default per i task più complessi. Tre giorni dopo, un venerdì, alle 17:21 ora della costa est, Anthropic ha ricevuto una direttiva di export control dal governo degli Stati Uniti e ha disabilitato Fable 5 e Mythos 5 per tutti i clienti del mondo, accessi via API e via cloud di terze parti inclusi, dissentendo apertamente e dichiarando di lavorare al ripristino. La cosa importante non è che un servizio sia andato giù: i servizi vanno giù di continuo. La cosa importante è che è la prima volta che uno Stato passa sopra il fornitore e spegne, in tutto il mondo e in un pomeriggio, un modello commerciale già deployato, su una base che lo stesso fornitore giudica tecnicamente infondata. Non è una notizia di prodotto a finestra breve. È un precedente, e i precedenti non si annullano se domani il modello torna disponibile.

Tengo a fissare subito il punto che governa tutto il resto: questo non è un fallimento di Anthropic, che ha agito da soggetto compliant a una direttiva legale dissentendo nel merito. La causa addotta è la scoperta di un metodo per aggirare le safeguard di Fable 5. Anthropic ha risposto pubblicamente che si tratta di un jailbreak narrow e non universale, che nella pratica consiste nel chiedere al modello di leggere una codebase e correggerne i difetti, capace di produrre solo vulnerabilità minori già note, le stesse che i difensori usano ogni giorno per tenere in piedi i sistemi e che altri modelli pubblici ottengono senza alcun bypass, OpenAI GPT-5.5 incluso. I fatti e le date sono nello statement ufficiale di Anthropic del 12 giugno. C'è una frase, in quel comunicato, che vale più di tutto il resto per chi costruisce sistemi: se lo stesso standard venisse applicato all'intero settore, fermerebbe di fatto ogni nuovo rilascio di qualunque fornitore di frontiera. Tradotto per un ingegnere: la causa non è il singolo modello, è il meccanismo, e il meccanismo resta acceso anche quando Fable torna.

Che cosa è successo davvero a Fable 5, e perché non è colpa di Anthropic?

La risposta breve è che un asset tecnico critico è stato reso indisponibile per una decisione amministrativa di una giurisdizione estera, contro la volontà commerciale del fornitore e su una base che il fornitore stesso definisce infondata. Il modello esiste, funziona, è il migliore della sua categoria, e tu non puoi usarlo perché il Dipartimento del Commercio americano ha vietato l'accesso a qualunque cittadino straniero, dentro o fuori dagli Stati Uniti. Gli altri modelli della famiglia (Opus, Sonnet, Haiku) non sono toccati, e già questo è un dato architetturale che la maggior parte delle analisi si lascia sfuggire: la continuità non è una proprietà del fornitore in blocco, è una proprietà del singolo modello su cui hai costruito. Avere un contratto enterprise con Anthropic non ti ha protetto, perché il rischio non vive nel rapporto tra te e il vendor, vive un piano sopra, nel rapporto tra il vendor e uno Stato che il tuo contratto non nomina nemmeno.

C'è poi un dettaglio che cambia la portata dell'episodio e che quasi nessuno mette a fuoco. La direttiva non vietava il modello a un paese o a una regione: vietava l'accesso ai cittadini stranieri, dentro e fuori dagli Stati Uniti, fino a comprendere i dipendenti stranieri della stessa Anthropic. Un ordine, sulla carta, chirurgico. Ma applicarlo davvero su un servizio cloud condiviso avrebbe richiesto di verificare la nazionalità di ogni singolo utente dietro ogni API key, ogni reseller, ogni seat enterprise: una cosa che il layer di accesso di un sistema multi-tenant non sa fare in modo affidabile. Così, per essere certa di non lasciar passare un solo cittadino straniero, Anthropic ha spento il modello per tutti, clienti statunitensi inclusi. È la lezione laterale più importante del 12 giugno, e va detta senza giri: un ordine chirurgico, calato su un'architettura che non sa eseguirlo in modo granulare, diventa uno strumento contundente. Il blast radius di una decisione sovrana non è quello che lo Stato scrive, è quello che il sistema è in grado di applicare, e qui i due divergono al massimo, perché a restare a piedi sono stati anche quelli che l'ordine non voleva colpire. La sostanza giuridica è quella del deemed export, dove dare accesso a una tecnologia controllata a un cittadino straniero, anche su suolo americano, conta come esportazione, e dove il vuoto normativo sull'accesso remoto via cloud è già oggetto di proposte legislative dedicate. Per chi costruisce, la conseguenza è spiazzante: non basta nemmeno stare dalla parte "giusta" della giurisdizione, perché l'over-compliance del fornitore travolge anche te.

Per anni abbiamo trattato il vendor lock-in come un rischio commerciale e tecnico: i prezzi che salgono, l'API che cambia, il costo di migrazione che cresce. È la stessa lente con cui da sempre valuto la dipendenza da un hosting o da un framework. Quel modello mentale, dopo il 12 giugno, è incompleto. Esiste una terza dimensione, fuori dal perimetro contrattuale, che conviene chiamare con il suo nome tecnico: forza maggiore politica. Non un guasto, non un inadempimento, ma la rimozione di una capacità decisa da un attore che non controlli (un governo, un'autorità, una corte) e che nessuna clausola di SLA, uptime o preavviso intercetta. È una classe di rischio che, fino a tre giorni prima, non compariva praticamente in nessun risk register aziendale, e che ora va aperta accanto al disaster recovery. La domanda che un responsabile IT deve smettere di farsi non è più soltanto "questo modello è sicuro, è conforme". È diventata: chi può spegnermelo, con quanto preavviso, e in quale giurisdizione gira fisicamente l'inferenza.

Se stai integrando modelli di frontiera in processi di produzione e vuoi vedere come imposto pipeline AI con governance dei costi e perimetro dichiarato, nel mio hub dedicato all'AI per le aziende raccolgo gli articoli tecnici con la metodologia che applico, inclusa la parte di sostituibilità del modello che è il cuore di questo pezzo.

C'è un dettaglio architetturale che questo evento porta a galla e che riguarda quasi tutti. Buona parte di ciò che oggi si chiama "AI aziendale", e in particolare di ciò che si vende come "AI europea", è in termini tecnici un wrapper: una interfaccia sottile che sanifica un input e lo inoltra via API a un modello che gira altrove, sotto un'altra bandiera. Affidare l'intelligenza fondazionale di un prodotto a un'unica regione geopolitica è, in linguaggio da architetto, un single point of failure travestito da scelta di comodità. Il multi-cloud ce l'ha insegnato quindici anni fa per lo storage e il compute: non concentri la disponibilità su un solo fornitore se quel servizio è critico. Quasi nessuno, finora, ha applicato quella stessa disciplina al layer del modello, perché il layer del modello sembrava intoccabile. Il 12 giugno ha dimostrato che è il più toccabile di tutti.

Il tuo accordo di Zero Data Retention regge davvero a una direttiva?

C'è una seconda parte dell'annuncio del 9 giugno, passata in secondo piano rispetto alla sospensione, che per chi ha vincoli di compliance pesa quanto il kill-switch. Insieme a Fable 5, Anthropic ha introdotto una retention obbligatoria a 30 giorni per tutto il traffico sui modelli di classe Mythos, per finalità di trust and safety, dichiarandola come parte di una strategia di defense in depth e riconoscendo apertamente che ha un costo reale per i clienti. Il dettaglio dirimente è che questa retention si applica anche alle organizzazioni che avevano un accordo di Zero Data Retention, e anche quando accedi al modello via Amazon Bedrock, Google Cloud o Microsoft Foundry. Chi aveva negoziato lo ZDR proprio per ragioni di conformità se l'è vista scavalcare da una policy di sicurezza del fornitore. La fonte è la pagina ufficiale sulla data retention per i modelli Mythos-class.

Qui conviene fare un passo laterale, perché il problema è più profondo di una singola policy ed è già noto da anni a chi si occupa di protezione del dato. La confidenzialità non dipende da dove sta fisicamente il dato, dipende da quale legge governa chi lo custodisce. Un datacenter a Francoforte gestito da un'entità soggetta alla giurisdizione statunitense resta, sul piano legale, esposto a quella giurisdizione, indipendentemente dalla bandiera sul tetto. È la lezione che il diritto europeo ha imparato sul tema dei trasferimenti transatlantici: nessuna clausola contrattuale, da sola, neutralizza l'accesso che una legge estera può imporre al fornitore. A reggere sono soltanto le misure tecniche, ossia tenere le chiavi di cifratura sotto controllo europeo o non far transitare affatto il dato sensibile da quella superficie. La retention imposta su Fable è la stessa identica lezione che arriva da una porta diversa: la confidenzialità del dato è una proprietà dell'architettura che scegli, non una promessa che ti fai firmare. Per un soggetto GDPR o NIS2 questo va messo nero su bianco nella valutazione d'impatto, e il modo in cui si traduce in voci concrete di governance lo affronto nel pezzo gemello su Executive Order, regime FAA e risk register del frontier model, che è la faccia compliance dello stesso evento.

Come si progetta la sostituibilità di un modello di frontiera?

Qui c'è l'unica risposta ingegneristica, e va detta senza ambiguità: non è "non usare i modelli di frontiera". Io li uso, in produzione, ogni giorno, e continuo a farlo. È progettare la loro sostituibilità dal primo giorno, in modo che spegnere un modello sia un cambio di configurazione e non una riscrittura. È lo stesso principio di disaccoppiamento con cui da vent'anni isolo un'applicazione dal database concreto: il codice di business non deve sapere quale modello sta parlando, esattamente come un controller non sa se sotto c'è MySQL o PostgreSQL. Il primo strato è un punto di contatto unico, configurabile, dove vive la scelta del modello, anziché averla sparsa nel codice:

# Catena di fallback: il primo disponibile vince.
# Se un modello sparisce (kill-switch, deprecation), si riordina questa lista,
# non si tocca una riga di codice applicativo.
AI_PROVIDER_PRIMARY=anthropic:claude-opus-4-8
AI_PROVIDER_FALLBACK=openai:gpt-5.5
AI_PROVIDER_SOVEREIGN=selfhosted:mistral-large-3
AI_TIMEOUT_SECONDS=60

Fin qui è il manuale, e da solo non basta, perché il lock-in di un modello non è solo tecnico, è comportamentale. Quando costruisci sopra Fable, non consumi un'API: leghi il tuo prodotto al modo specifico in cui quel modello ragiona, al suo tono, ai suoi modi di sbagliare, ai prompt che hai calibrato per le sue idiosincrasie. Più il sistema diventa agentico, più questo legame si stringe, perché ogni guardrail e ogni prompt di orchestrazione che aggiungi è tarato su quel modello. È la ragione per cui l'astrazione va messa presto, prima che la complessità agentica si sedimenti: dopo, "cambiare modello" non è più una riga di configurazione, è un travaso di comportamento che scopri solo sul campo.

Per questo il secondo strato non è un piano B teorico, è un warm standby vero. Le migrazioni a freddo falliscono: un team che non ha mai mandato in produzione un'alternativa non la tira su in sei settimane il giorno in cui il modello primario sparisce. La pratica solida è far passare già da subito una quota di traffico reale, indicativamente tra il quindici e il venti per cento, su un secondo provider o su un modello self-hosted europeo, così da far emergere prima i difetti di integrazione, le differenze di prompt e i divari di latenza, mentre l'incumbent regge ancora. A questo serve una eval di portabilità: un set di test sul tuo workload reale che misura quanto si degrada la qualità passando dal modello A al modello B, perché un fallback che dimezza la qualità non è un fallback, è un downgrade silenzioso. E serve una vera prova d'uscita periodica, sul modello degli stress test di resilienza operativa che il settore finanziario ha già istituzionalizzato: una esercitazione trimestrale in cui si simula la perdita del modello primario e si verifica che il sistema regga. Su questa parte ho scritto sia il lato infrastrutturale, con un LLM self-hosted su VPS Hetzner con Ollama per la produzione, sia il confronto frontale tra un modello a pesi aperti ospitato in Europa e l'API di frontiera in Mistral 3 MoE on-premise contro l'API Claude sul piano della sovranità e del GDPR.

A chi obietta che un'alternativa self-hosted significhi rinunciare alla qualità del frontier, rispondo con un dato che l'entusiasmo sul "modello più grande" tende a nascondere: la maggior parte dei task aziendali ad alto valore (classificazione, estrazione di entità, smistamento e triage di documenti, instradamento, sintesi, redazione strutturata) sta comodamente alla portata di modelli compatti a pesi aperti, eseguibili su hardware che possiedi davvero. Il milione di token di contesto e la capability di frontiera servono per le codebase intere e gli agenti long-horizon, non per il novanta per cento del lavoro di produzione. Rinunciare al modello di frontiera per quei task non è rinunciare alla produzione: è togliere una dipendenza sovrana da dove non serviva. Nella mia pipeline personale, quando Fable 5 è stato spento, il riallineamento è stato il cambio di una riga, perché il modello di frontiera era già trattato come un componente sostituibile e non come una fondazione. La lezione non l'ho imparata il 12 giugno: l'ho applicata. L'avevo imparata vent'anni fa su un hosting che cambiava prezzo, ed è la stessa.

Vale la pena un dato di mercato, perché spiega quanto questa disciplina sia rara. Secondo la ricerca dell'Osservatorio Artificial Intelligence del Politecnico di Milano presentata il 5 febbraio 2026, il 71% delle grandi imprese italiane ha avviato almeno un progetto AI, ma solo il 9% ha una governance strutturata. Tradotto: quasi tutti hanno già messo l'AI in produzione, e quasi nessuno ha pensato a cosa fa quando l'AI su cui poggia diventa indisponibile. L'affaire Fable non ha creato questo divario, lo ha solo illuminato in un pomeriggio.

Un punto di non ritorno, non un incidente

Sarebbe comodo derubricare il 12 giugno a episodio irripetibile. La cronaca recente dice il contrario, e c'è una nota di ironia strutturale che va riportata con precisione perché è istruttiva. Lo stesso fornitore a cui lo Stato ha appena spento il modello è quello che, pochi giorni prima, nella sua proposta di policy sull'esponenziale dell'AI, aveva chiesto per il governo il potere di bloccare o revocare un modello di frontiera giudicato a rischio, in un regime di certificazione e recall sul modello dell'aviazione civile. Il punto non è la coerenza del singolo attore, è il segnale per chi costruisce: il kill-switch sovrano non è un guasto isolato, è una direzione che l'industria stessa chiede di istituzionalizzare. L'Executive Order firmato il 2 giugno va nella stessa direzione, inserendo lo Stato a monte del rilascio dei modelli. Quando una capacità diventa oggetto di richieste regolatorie esplicite da parte di chi la produce, la probabilità che si concretizzi smette di essere trascurabile, e progettare la sostituibilità del modello smette di essere una buona pratica facoltativa.

Una precisazione di metodo, perché il taglio non sia frainteso: non è un pezzo anti-Anthropic né anti-AI. Uso Claude e ho usato Fable in produzione, e la lezione vale identica per qualunque fornitore, OpenAI, Google o xAI compresi, perché la radice non è la qualità del modello ma la giurisdizione che lo governa. Chi predica il disaccoppiamento standone fuori non è credibile; chi lo predica usando ogni giorno lo strumento di cui consiglia la sostituibilità, sì. Resta una domanda che un titolare o un responsabile IT dovrebbe portarsi a casa guardando la propria infrastruttura: se domattina il modello su cui poggia il processo più critico diventasse indisponibile per una decisione presa in un altro continente, quante ore perderei prima di tornare operativo, e su quale alternativa già accesa e già testata? Se la risposta è "non lo so" o "nessuna", il problema non è Fable 5, è l'architettura, e la buona notizia è che la difesa non chiede di rinunciare ai modelli migliori: chiede di trattarli per quello che sono, componenti potenti e sostituibili, dietro un layer di astrazione, con un fallback caldo e una prova d'uscita scritta. È esattamente il lavoro che faccio quando affianco un'azienda nel mettere l'AI in produzione senza costruirci sopra una dipendenza che un terzo paese può spegnere. Se hai un progetto AI concreto e vuoi capire dove sei esposto e cosa serve per renderlo resiliente, puoi usare il modulo di preventivo gratuito: sette domande, due minuti, e ti dico subito se rientra nel mio perimetro o se ti conviene un'altra figura.