← Torna a tutti gli articoli
strategy

Nessun governo può spegnere un modello che gira sul tuo hardware

Di Marc Molas·14 giugno 2026·11 min di lettura

Questo fine settimana abbiamo visto progetti e prototipi rompersi perché un governo di un altro paese ha deciso di vietare l'uso di una merce.

Non è un bug. Non è un deploy andato male. Non è un rate limit che puoi ritentare dopo una pausa. Una direttiva statunitense di controllo delle esportazioni ha ordinato di spegnere il modello di IA pubblico più capace del mondo — per ogni utente, ovunque, compresi i dipendenti dello stesso fornitore che avevano il passaporto sbagliato. Se il tuo prodotto chiamava quel modello tramite un'API, il tuo prodotto non si è degradato con grazia. Ha restituito un errore e si è fermato. In Un sistema di visti per l'intelligenza ho analizzato cosa questo ha fatto al prezzo del rischio sovrano e ai conti delle quotazioni in borsa. Questo articolo riguarda l'altra metà del conto: cosa fa al modo in cui costruisci.

Scrivo dal sedile di chi costruisce, non dalla scrivania delle politiche né dal tavolo degli investitori. Mando in produzione sistemi che chiamano queste API, e la lezione che porto a casa da questa settimana non è politica: è architetturale. Un modello che chiami via rete, posato su un server dietro un confine nazionale, è una dipendenza con un interruttore di spegnimento che non è tuo. E lo Stato ha appena dimostrato, con tanto di orario, che lo azionerà. Il mercato ha già iniziato ad aggirare quell'interruttore. La stessa settimana in cui un modello si è spento per decreto, Microsoft ha documentato in sordina come farne girare un altro senza alcuna API di mezzo. E tre settimane prima di tutto questo, Nvidia — l'azienda che vende i picconi e le pale — ha riscritto i propri bilanci per scommettere che l'informatica va esattamente in quella direzione.

Un'API dietro un confine ha una modalità di guasto che vive in un palazzo del governo

Tengo una breve lista dei modi in cui una funzionalità può morire senza che nessuno tocchi il suo codice. Il blackout di CrowdStrike è stato un aggiornamento a monte fatto male: 8,5 milioni di macchine a terra per un file che nessuno nella tua azienda ha scritto. La runtime fee di Unity è stata una modifica di prezzo che non avevi accettato, applicata retroattivamente a software che avevi già rilasciato. Entrambi sono guasti di dipendenza da un fornitore, ed entrambi sono, in fin dei conti, negoziabili: un brutto patch lo aggiri con l'ingegneria e una fattura la tratti al ribasso.

Ieri ha aggiunto una terza voce con una causa genuinamente nuova, e questa non è negoziabile. Una direttiva sovrana: filtrata per nazionalità, con effetto immediato, senza alcun SLA che la copra e senza altro appello che obbedire. Non esiste un ticket di supporto da aprire contro un ordine di controllo delle esportazioni. Lo stesso fornitore non ha potuto rifiutare: ha potuto solo protestare mentre obbediva. L'articolo sul sistema di visti ha battezzato tutto questo rischio di ritiro sovrano, e ciò che conviene interiorizzare è che è strutturalmente diverso da qualunque rischio di dipendenza che già sappiamo gestire. Puoi comprare ridondanza tra regioni, tra fornitori, tra cloud. Ciò che non puoi comprare è ridondanza di fronte al fatto che il livello di modello più capace è ormai un asset strategico controllato, e che il governo che lo decide è lo stesso in cui il tuo fornitore ha sede.

Ogni mitigazione a cui ricorriamo per riflesso — multiregione, multicloud, un secondo fornitore — finisce comunque su un modello posato sul server di qualcun altro, raggiungibile solo finché una direttiva lo consente. C'è una sola mitigazione che elimina l'interruttore invece di coprirsi: far girare il modello su hardware che è tuo. Una settimana fa suonava come qualcosa che non potevamo permetterci. Oggi è un requisito di resilienza, e gli strumenti per agire sono arrivati la stessa settimana del rischio.

La stessa settimana in cui un modello è stato spento, Microsoft ha documentato come farne girare un altro senza alcun server

Ecco la parte che mi ha fatto fermare. Phi Silica, di Microsoft, è un piccolo modello linguistico da 3,3 miliardi di parametri. Fino a poco fa girava solo sulle unità di elaborazione neurale (NPU) dei PC Copilot+: una fascia hardware stretta e certificata. Questo giugno, Microsoft ha ampliato in sordina la sua documentazione Windows AI con una nuova pagina: come eseguire Phi Silica su GPU Nvidia RTX, senza NPU. L'elenco di compatibilità risale alla serie RTX 30 e successive, l'asticella è intorno a 8 GB di memoria video dedicata e a un driver del ramo 560 o più recente, e l'esecuzione passa per il Windows Copilot Runtime su DirectML. La documentazione è netta sull'unica cosa che conta qui: il modello e l'inferenza girano interamente sull'hardware dell'utente. Nessuna chiamata API nel cloud.

Rileggi il requisito e toglilo dal linguaggio da scheda tecnica: un modello linguistico utile, supportato ed eseguito in locale punta ora a una scheda grafica che milioni di persone hanno già. Non un acceleratore da data center sotto licenza di esportazione. Non un PC IA certificato da andare a comprare. La scheda che è già nel case a far girare i giochi. La capacità non è diventata più economica: si è trasferita in un palazzo dove lo Stato non può entrare senza un mandato.

Nvidia ha riscritto i propri bilanci per scommettere sull'edge — tre settimane prima del ritiro

Se vuoi sapere dove va davvero la domanda di inferenza, non leggere i manifesti. Leggi l'azienda che ha la visione più chiara del portafoglio ordini e l'incentivo più forte a non sbagliare — e guarda cosa fa quando deve affermare cose sotto giuramento.

Nei risultati del primo trimestre dell'anno fiscale 2027, il 20 maggio, Nvidia ha cambiato il modo in cui rendiconta il proprio business. I vecchi segmenti operativi — «Compute & Networking» e «Graphics» — sono spariti. Al loro posto ci sono due piattaforme di mercato: Data Center ed Edge Computing. Dentro Data Center ci sono due sotto-mercati, Hyperscale e ACIE (AI Clouds, Industrial, Enterprise). E accanto, per la prima volta come piattaforma di pari rango, c'è Edge Computing — definita come i dispositivi per l'IA agentica e fisica: PC, console, workstation, stazioni base AI-RAN, robotica, automotive. La categoria che Nvidia chiamava «gaming» non si è ristretta: è stata assorbita in una piattaforma il cui nome parla ora di far girare l'IA all'edge. Edge Computing ha registrato 6,4 miliardi di dollari nel trimestre sulla propria riga.

Un'azienda non ristruttura la propria rendicontazione per segmenti per capriccio. È un documento certificato, duraturo, costoso da cambiare, e letto con la lente da gente che fa causa quando viene tratta in inganno. Quando l'azienda con la visione migliore sul futuro mette Edge Computing accanto al data center come piattaforma di pari rango, ti sta dicendo — nel linguaggio più vincolato legalmente che un'azienda abbia — che non crede che il futuro sia un unico modello gigante su un unico server dietro il confine di una sola nazione. E l'ha detto a maggio, tre settimane prima del ritiro di giugno. Quindi non è una reazione alla notizia. È la scommessa strutturale che la notizia è poi venuta a convalidare.

Va detto, questo film l'abbiamo già visto. L'informatica si decentra ogni volta che il centro accumula una passività che la periferia non porta. Dal mainframe al PC, quando la passività erano costo e accesso. Dal PC di nuovo al cloud per un decennio, quando la passività era la fatica operativa. Ora il pendolo si carica nell'altra direzione sotto il peso della latenza, dell'economia unitaria, della privacy — e, da questa settimana, della sovranità, la passività più pesante che il centro abbia mai portato, perché è l'unica che non puoi prezzare, assicurare o negoziare. L'oscillazione non è ideologica. È un business che aggira il rischio più caro sul tavolo.

Il business aggira il rischio; è l'unica cosa che fa senza fallire

Togli la geopolitica ed ecco un'osservazione ordinaria su come si comportano le aziende. Un'azienda è, sopra quasi ogni cosa, una macchina che aggira il rischio. Accetterà latenza peggiore, costo iniziale più alto e più lavoro di ingegneria pur di eliminare un rischio di coda capace di azzerare il suo prodotto da un giorno all'altro — allo stesso modo in cui paga un'assicurazione che spera di non usare mai. Per due anni l'argomento a favore dell'inferenza locale si è giocato su costo e privacy, e ha perso quasi tutte le discussioni, perché la comodità di un'API di frontiera valeva il lock-in. Questa settimana il calcolo è cambiato, perché il rischio di coda ha smesso di essere ipotetico e ha acquisito una data e un'ora.

Ora l'obiezione più forte, di petto, perché è giusta: un modello da 3,3 miliardi di parametri non è Fable 5, e non ci si avvicina. Non puoi far girare un ragionamento di livello frontiera su una GPU da gaming, e gran parte di ciò che rende questi strumenti degni di essere pagati vive nel livello più alto che solo i grandi modelli remoti possono servire. Vero, ma è l'inquadratura sbagliata. Nessuno di serio propone di spostare tutto in locale. La mossa è stratificare il lavoro:

  • L'80–90% ad alto volume, sensibile alla latenza e di esigenze modeste — classificazione, estrazione, stesura di bozze, autocompletamento, risposte aumentate dal recupero sui tuoi documenti — gira oggi perfettamente su un modello locale da 3–8B. Ed è, non a caso, la parte del tuo stack dove un'interruzione costa di più, perché sta sul percorso critico di tutto.
  • Il 5–10% genuinamente difficile che richiede la frontiera resta sull'API — ma dietro un fallback documentato e testato, così che un ritiro ti degradi invece di fermarti.

E il divario si stringe ogni trimestre; i modelli piccoli continuano ad assorbire capacità che un tempo richiedevano la frontiera. L'obiettivo di andare in locale non è mai stato la parità. È l'opzionalità — e possedere l'interruttore di spegnimento sulla parte del tuo prodotto che non puoi permetterti che venga spenta da qualcun altro.

Un'ultima precisazione onesta, perché taglia nell'altro senso: lo Stato controlla anche i chip. La stessa amministrazione che ha ritirato il modello fa girare a Nvidia e AMD una fetta dei loro ricavi in Cina per il solo privilegio di poter esportare. Ma c'è una differenza reale tra controllare la prossima vendita e mettere le mani in una GPU che già ronza nel tuo rack. La direttiva caduta questa settimana era remota e istantanea. Un modello residente su hardware che è già tuo non espone alcuna interfaccia remota che una direttiva possa afferrare. I controlli all'export rallentano il tuo prossimo acquisto. Non ritirano il tuo parco già installato.

Cosa metterei sul diagramma di architettura questo trimestre

Se fossi il tuo CTO, ecco il lavoro che finanzierei prima che chiuda il prossimo ciclo di pianificazione — concreto, non velleitario:

  1. Aggiungi una riga alla mappa delle dipendenze. Per ogni funzionalità di IA, scrivi quale governo può spegnerla, e per quali dei tuoi utenti in base alla nazionalità. Se quella cella è vuota, il progetto non è finito. Va sul diagramma di architettura, non in una nota a piè di pagina legale.
  2. Metti un'interfaccia di inferenza stabile davanti a ogni chiamata al modello, con almeno un'opzione a pesi aperti o locale già cablata dietro. Il modello diventa intercambiabile; l'impalcatura resta tua. Il modello è la merce; l'impalcatura attorno è il fossato — e ora, la resilienza.
  3. Stratifica i tuoi carichi in base alla capacità realmente richiesta, poi sposta il livello ad alto volume e di esigenze modeste su un modello locale da 3–8B — di classe Phi su una macchina RTX, o i suoi equivalenti a pesi aperti. Quella singola mossa toglie del tutto dalla rete il tuo percorso più caldo.
  4. Scrivi e testa un fallback per ogni funzionalità di livello frontiera come lo scriveresti per un gateway di pagamento: rileva il 4xx, degrada al modello locale, allerta, continua a servire. Poi provalo davvero. CrowdStrike e Unity ci hanno insegnato ad avere un fallback; il ritiro ha alzato la posta sul testarlo sul serio.
  5. Dimensiona l'hardware adesso. La capacità che possiedi in proprio non può essere requisita per direttiva. Una macchina RTX nel tuo rack — o già nel case del tuo utente — è una copertura di sovranità che, per inciso, taglia la tua bolletta di inferenza. L'economia dei modelli fondativi parlava di non strapagare per noleggiare capacità; questa è la versione più affilata dello stesso istinto.

Non costruire il muro portante con qualcosa che il vento può portarsi via

Mio nonno ha avuto un'impresa di costruzioni, e aveva una frase che ripeteva ogni volta che qualcuno gli proponeva un affare appeso a qualcosa di esterno alla stanza: non fare mai affari che dipendono da come gira il vento. Parlava del tempo, dei raccolti e delle dipendenze politiche. Mio nonno se ne intendeva e, cinquant'anni dopo, tocca a me prendere sul serio il suo consiglio. Non costruire su una capacità che un governo può spegnere per capriccio.

Questa settimana il vento ha cambiato direzione, e un modello da cui dipendevano centinaia di milioni di persone è sparito prima che arrivasse la richiesta successiva. Il modello di frontiera è fallito perché stava su un server dietro un confine, e il confine ha un padrone. La documentazione di Microsoft e il cambio di rendicontazione di Nvidia sono lo stesso istinto espresso due volte, da due delle più grandi aziende del settore, nello stesso mese: il posto duraturo dove far girare un modello è hardware che qualcuno possiede, dove nessuna direttiva può raggiungerlo. Non perché il locale è più veloce. Perché il locale non si può ritirare.

Se stai mappando la tua catena di fornitura dell'IA in cerca dell'interruttore che non controlli, parti dall'articolo che accompagna questo — Un sistema di visti per l'intelligenza — poi torna e scrivi «quale governo può spegnere questo» sul diagramma, nero su bianco, accanto alla funzionalità che farebbe cadere.

Pronto a costruire il tuo team di ingegneria?

Parla con un partner tecnico e distribuisci sviluppatori validati da CTO in 72 ore.