Quando lo Stato può spegnere la tua AI: l'Executive Order e il regime FAA che l'industria chiede

Il 2 giugno 2026 la Casa Bianca ha firmato un Executive Order intitolato "Promoting Advanced Artificial Intelligence Innovation and Security", seguito cinque giorni dopo da un National Security Presidential Memorandum collegato. Dieci giorni più tardi, il 12 giugno, lo stesso governo ha imposto la sospensione globale di Fable 5 e Mythos 5, i due modelli di frontiera più capaci di Anthropic, per tutti i clienti del mondo. La sequenza non è una coincidenza da cronaca tecnologica: nel giro di pochi giorni il quadro descritto nell'ordine esecutivo ha smesso di essere teoria. Per un responsabile dei sistemi informativi o per un decisore europeo che ha integrato modelli di frontiera in processi di produzione, qui c'è un fatto da portare in consiglio: un asset critico può essere governato da regole di un paese terzo, e quelle regole possono renderlo indisponibile dall'oggi al domani. C'è una vecchia osservazione sulla regolazione delle tecnologie, secondo cui quando gli effetti di una tecnologia diventano abbastanza chiari da volerli governare, spesso è già troppo tardi per farlo con facilità. L'AI di frontiera è arrivata esattamente a quel punto, e questo articolo non parla di geopolitica per il gusto di farlo: parla di come tradurre quel fatto in voci concrete del registro dei rischi, distinguendo con rigore ciò che è già diritto da ciò che è solo una posizione dichiarata.

Una premessa di trasparenza, perché il taglio sia chiaro: nella mia attività uso quotidianamente modelli Anthropic in produzione, Claude e, finché è stato disponibile, Fable. Non scrivo da detrattore esterno e questo non è un pezzo contro un fornitore. È una lettura di rischio architetturale, e vale identica per qualunque provider, americano o no: la radice del problema non è la qualità del modello, è la giurisdizione che lo governa. Proprio perché lo strumento lo uso, sono nella posizione di dire dove è esposto.

Che cosa cambia per un decisore europeo se gli Stati Uniti possono spegnere un modello?

La risposta sintetica è che alla classica matrice di rischio tecnologico (fornitore, costo, migrazione) si aggiunge una dimensione nuova, fuori dal controllo contrattuale: la forza maggiore politica. L'Executive Order del 2 giugno indirizza le agenzie federali a costruire un framework per il deployment sicuro dei modelli di frontiera e introduce un processo per cui i developer forniscono volontariamente al governo l'accesso anticipato ai modelli, fino a trenta giorni prima del rilascio. L'approccio è dichiarato volontario e collaborativo, ma l'effetto sistemico è inequivocabile: lo Stato si inserisce a monte del rilascio. Per un'azienda europea che usa quei modelli a valle, la disponibilità dell'asset dipende da decisioni prese in una giurisdizione in cui non ha voce, non ha rappresentanza e non ha rimedio contrattuale. Il caso Fable lo rende tangibile: il governo ha emesso una direttiva di export control e Anthropic, per garantire la compliance, ha disabilitato i modelli per tutti, dissentendo apertamente nel merito (i fatti sono nel suo statement ufficiale). Il punto per il risk register non è "Anthropic è inaffidabile", che sarebbe falso: il fornitore ha agito da soggetto compliant. Il punto è che tra te e l'autorità che ha deciso lo spegnimento non c'è alcun rapporto contrattuale, e quindi nessuna delle clausole che hai negoziato ti protegge da quella specifica causa.

Vale la pena capire con quali leve un meccanismo del genere può attivarsi, perché un rischio che non sai descrivere non sai nemmeno mitigarlo. La prima è l'export control applicato non a un chip ma a una capacità software accessibile da remoto, terreno giuridicamente nuovo: non è affatto pacifico che l'uso remoto di un modello costituisca un "export" nel senso classico, ed è proprio questa ambiguità che spinge il legislatore a inseguire la fattispecie con norme ad hoc sull'accesso remoto a tecnologia controllata. La seconda è la regola del prodotto diretto estero, che permette di rivendicare giurisdizione su qualunque prodotto realizzato usando tecnologia statunitense, e che è già stata usata come arma sulla supply chain dei semiconduttori. La terza, ed è il punto che toglie a questo discorso ogni tono anti-americano, è il geofencing regolatorio puro e semplice: è già accaduto nella direzione opposta, con un grande fornitore che ha tenuto fuori dall'Unione Europea le versioni multimodali di un suo modello per conflitti con il quadro normativo europeo. La lezione è simmetrica: un modello può essere reso indisponibile in un mercato per ragioni che non hanno nulla a che vedere con la sua qualità tecnica, e questo vale a Washington come a Bruxelles.

C'è un risvolto, nel modo in cui la direttiva ha agito, che un risk register accorto deve registrare per quello che è. L'ordine americano non vietava il modello a un paese, lo vietava ai cittadini stranieri, dentro e fuori dagli Stati Uniti, fino a comprendere i dipendenti stranieri del fornitore stesso. Ma poiché verificare la nazionalità di ogni utente su un servizio cloud condiviso non è praticabile, l'unico modo per garantire la compliance è stato spegnere il modello per tutti, clienti statunitensi compresi. È la logica del deemed export portata alle sue conseguenze: dare accesso a tecnologia controllata a un cittadino straniero, anche in patria, conta come esportazione, e in assenza di un layer capace di filtrare per nazionalità il fornitore previene il rischio bloccando l'intera platea. Tradotto in linguaggio di rischio, l'over-compliance del fornitore allarga il danno ben oltre il bersaglio dell'ordine: nemmeno essere un soggetto in regola o avere sede nella giurisdizione "giusta" garantisce la continuità, perché si finisce travolti come effetto collaterale. Per questo la mitigazione di questa voce non può essere "scegliere il fornitore giusto", ma deve essere strutturale.

Se stai impostando o rivedendo la governance IT della tua azienda e questo tipo di esposizione ti riguarda, nel mio profilo professionale trovi l'esperienza concreta su compliance NIS2 e GDPR, business continuity e architetture resilienti per realtà strutturate e PMI.

Il regime in stile FAA: una proposta potente e un'analogia che scricchiola

Qui serve la massima disciplina nel distinguere il fatto dalla posizione, perché confonderli trasforma un documento di compliance in disinformazione. Nella sua proposta di policy sull'esponenziale dell'AI, il CEO di Anthropic auspica un regime in stile FAA per i modelli di frontiera: testing obbligatorio da parte terza su quattro aree di rischio (cybersecurity, armi biologiche, perdita di controllo, ricerca e sviluppo automatizzata) e, soprattutto, il potere del governo di bloccare o revocare il deployment di un modello giudicato a rischio inaccettabile, con tutele dichiarate contro l'arbitrarietà. L'analogia è seducente: come un aereo passa per certificazione, collaudo e, all'occorrenza, per un ordine di messa a terra dell'intera flotta, così un modello dovrebbe passare per un cancello di sicurezza prima del rilascio e poter essere richiamato dopo.

È una proposta seria, e va trattata come posizione, non come norma in vigore. Ma proprio perché un decisore deve poterci ragionare sopra, va detto dove l'analogia scricchiola, perché è lì che si nasconde il rischio per chi usa l'AI a valle. Un aereo è un prodotto discreto, ben delimitato, con un momento di rilascio chiaro e un produttore responsabile identificabile. Un modello general-purpose è l'opposto: è difficile da delimitare, i suoi rischi sono segnati da un'incertezza profonda e i suoi effetti sono in larga parte "trasmissibili", perché passano attraverso una catena distribuita di sviluppatori, integratori e utilizzatori. La conseguenza pratica, per un CIO, è che il potere di recall che funziona su un aereo, dove la messa a terra colpisce il produttore e una flotta ben identificata, su un modello colpisce te. Quando viene richiamato un velivolo, a fermarsi è la compagnia aerea; quando viene richiamato un modello su cui hai costruito la produzione, a fermarti sei tu, senza preavviso e senza che il tuo nome compaia da nessuna parte nella decisione. C'è poi l'ironia che chiude il cerchio e che vale come monito: lo stesso fornitore che chiede per lo Stato il potere di revoca è quello a cui lo Stato ha appena revocato un modello, in un modo che il fornitore stesso giudica privo dei requisiti di trasparenza e fondatezza tecnica che la sua proposta esige. Il regime non esiste ancora, e già il primo esercizio analogo di quel potere è stato contestato come arbitrario da chi lo invocava. Per il risk register questo significa una cosa precisa: l'esposizione regolatoria non è un'ipotesi remota, è una direzione credibile da monitorare e mitigare per tempo.

Come si traduce in voci concrete del risk register?

Un decisore non agisce su una notizia, agisce su una voce di rischio strutturata: descrizione, evento di riferimento, impatto, mitigazione. Questo approccio spoglia l'evento dall'emotività della cronaca e lo rende governabile. Ecco le quattro voci che, alla luce del 2 e del 12 giugno, andrebbero aperte o riviste.

La prima voce, l'indisponibilità sovrana, è la più immediata e la più sottovalutata. La mitigazione non è "cambiare fornitore", che sposta solo il problema, ma progettare la sostituibilità del modello: isolare il punto di contatto con l'AI dietro un layer di astrazione e tenere in produzione, già testata su traffico reale, un'alternativa. Una migrazione provata a freddo nel giorno dell'emergenza fallisce; una provata a caldo, con una quota di traffico che gira sull'alternativa già da prima, regge. È la stessa filosofia degli stress test di resilienza operativa che il settore finanziario europeo ha già reso obbligatori: non basta avere un piano, bisogna esercitarlo a cadenza fissa. L'anatomia ingegneristica di questa difesa, dal layer di astrazione al fallback caldo, la sviluppo nel pezzo gemello su come hanno spento il modello AI più potente del mondo in tre giorni, che è la faccia tecnica dello stesso evento. Sul versante della continuità operativa, le stesse logiche di disaster recovery che applico alle applicazioni le ho descritte in business continuity e disaster recovery per applicazioni PHP nelle PMI: cambia l'asset, non il metodo.

La seconda voce, la confidenzialità, impatta di più chi ha vincoli GDPR o NIS2. Insieme a Fable 5, Anthropic ha introdotto una retention obbligatoria a trenta giorni per i modelli Mythos-class, che si applica anche a chi aveva un accordo di Zero Data Retention e anche agli accessi via marketplace cloud di terze parti. Qui vale un principio che in protezione del dato è noto da anni: dove sta fisicamente il dato conta meno di quale legge governa chi lo custodisce. Un datacenter in Europa gestito da un'entità soggetta a una giurisdizione estera resta esposto a quella giurisdizione, e nessuna clausola contrattuale, da sola, lo neutralizza; reggono solo le misure tecniche, come tenere le chiavi sotto controllo europeo o non far transitare il dato sensibile da quella superficie. Per il risk register la conseguenza è netta: la confidenzialità va riportata nella valutazione d'impatto come proprietà dell'architettura, non come clausola da far firmare. La terza voce, il lock-in, matura in silenzio: più calibri i prompt e le integrazioni agentiche su uno specifico modello, più costoso diventa cambiarlo, anche quando il cambio è obbligato; la mitigazione è una eval di portabilità che misuri davvero il degrado passando all'alternativa. La quarta, l'esposizione regolatoria, è l'unica che oggi poggia su una posizione e non su una norma, e proprio per questo va trattata come rischio da monitorare, non come obbligo da rincorrere.

Dove si incastra il quadro normativo italiano ed europeo

Il rischio sovrano si sovrappone agli obblighi che maturano in autunno, non li sostituisce, e conviene fissarli con lo stato corretto perché la scadenza più citata è anche la più fraintesa. Dal 2 agosto 2026 diventa applicabile in via generale il Regolamento UE 2024/1689, l'AI Act: scattano gli obblighi di trasparenza dell'articolo 50, i poteri di enforcement della Commissione sui provider di modelli general-purpose e i regimi sanzionatori nazionali. Attenzione però al claim killer: non è vero che "dal 2 agosto scattano gli obblighi per i sistemi high-risk". Quegli obblighi, con l'accordo provvisorio del cosiddetto Digital Omnibus (intesa politica del 7 maggio 2026), sono rinviati al dicembre 2027, ma finché l'Omnibus non è pubblicato in Gazzetta Ufficiale valgono le date originali. La formula corretta in un documento di compliance è il doppio binario con lo stato di ciascuna data, mai una scadenza secca presentata come certa.

Sul versante italiano, la legge quadro è la legge 132/2025 (non "132/2024", è un errore frequente che mina la credibilità di un documento), e con il Consiglio dei Ministri del 10 giugno 2026 sono stati approvati in via preliminare i decreti attuativi che assegnano ad AgID il ruolo di autorità di notifica e sandbox e all'ACN la vigilanza di mercato e il potere sanzionatorio. È rilevante perché l'ACN è anche l'autorità NIS2: la stessa entità presidia due fronti che convergono in autunno, con le misure di base NIS2 in scadenza al 31 ottobre 2026. Per un soggetto NIS2 che usa l'AI in produzione, la doppia scadenza sotto un'unica autorità è un framing che il marketing di settore quasi non tratta, ed è dove un risk register ben fatto fa la differenza. Per la parte di adeguamento più operativa rimando alla checklist sulla scadenza AI Act del 2 agosto 2026 per le PMI italiane. C'è un dato che inquadra perché questo lavoro sia raro e necessario: 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 e solo il 15% ha in corso un progetto di adeguamento all'AI Act integrato con le altre normative. La maggior parte delle aziende ha già messo l'AI in produzione senza un registro che ne mappi i rischi, e l'affaire Fable ha solo illuminato un'esposizione che era già lì. In un percorso di adeguamento per un'azienda del settore servizi digitali ho visto da vicino quanto la distanza tra "usiamo l'AI" e "abbiamo mappato cosa succede se l'AI sparisce" sia ampia anche in organizzazioni tecnicamente mature.

Una domanda da portare in consiglio

Resta una domanda che vale più di qualunque tabella, e che pesa oltre il perimetro aziendale: è accettabile che l'accesso globale a una tecnologia trasformativa dipenda dalla decisione di un singolo Stato, o di una manciata di aziende che vi hanno sede? Non è una questione che un'azienda possa risolvere da sola, ma è quella che le impone di non restare esposta passivamente. La traduzione operativa è netta: se il modello su cui poggia il processo più critico diventasse indisponibile domattina per una decisione presa in un altro continente, l'azienda saprebbe per quante ore resterebbe ferma e su quale alternativa già pronta ripartire? Scrivere quella risposta nero su bianco è il primo vero atto di governance dell'AI. L'Executive Order e la proposta di un regime in stile FAA ci dicono che la direzione è quella di uno Stato che può intervenire sul ciclo di vita di un modello; il caso Fable ci dice che non è un'ipotesi remota. Tradurre tutto questo in voci di rischio, distinguendo con onestà ciò che è già diritto da ciò che è ancora una posizione, e affiancare a ogni voce una mitigazione architetturale concreta, è il modo per smettere di subire la cronaca e iniziare a governarla. Se vuoi costruire questa parte della governance sulla tua realtà, dalla mappatura del rischio sovrano fino agli obblighi NIS2 e AI Act di questo autunno, contattami per una consulenza diretta: di solito tra l'analisi dell'esposizione e le prime contromisure concrete passano giorni, non trimestri.