La politica americana ha trovato nell’interruttore d’emergenza dell’intelligenza artificiale una formula capace di trasformare una questione tecnica complessa in una promessa immediatamente comprensibile agli elettori. Se un sistema diventa pericoloso, basta spegnerlo. Il ragionamento ha una forza comunicativa indiscutibile, soprattutto in una fase in cui l’autonomia degli agenti software alimenta timori sulla sicurezza informatica e sulla capacità delle imprese di mantenere il controllo delle proprie tecnologie. Il problema comincia quando lo slogan deve diventare una specifica tecnica, un obbligo giuridico e, soprattutto, una procedura applicabile durante un incidente reale.

La proposta di Lieu e Moran è rilevante proprio perché prova a superare la dimensione simbolica del dibattito. L’obiettivo è imporre ai soggetti interessati la capacità di intervenire sui sistemi coperti dalla legge, attribuendo al governo federale strumenti per richiederne il rallentamento o l’arresto in determinate circostanze. Il provvedimento, tuttavia, non equivale a una legge già operativa: il testo è stato introdotto alla Camera e assegnato alle commissioni competenti. La distinzione conta, perché nel mercato dell’intelligenza artificiale l’annuncio di un obbligo normativo può produrre aspettative e costi di adeguamento ben prima che il Congresso abbia definito una disciplina definitiva.

Il contesto elettorale contribuisce a spiegare la visibilità acquisita dalla questione. Le elezioni di metà mandato del novembre 2026 rendono la regolamentazione dell’IA un terreno sul quale dimostrare attenzione verso le preoccupazioni dei cittadini, senza dover necessariamente risolvere ogni controversia tecnica. Il tentativo di Kennedy di accelerare il proprio provvedimento al Senato, fermato dall’obiezione di Rand Paul, mostra inoltre che la convergenza sull’esigenza di sicurezza non coincide con un accordo sugli strumenti legislativi. Il sostegno trasversale a un principio generale può convivere con divergenze sostanziali sui poteri dello Stato, sui costi per le imprese e sui limiti dell’intervento federale.

La posizione di Newsom aggiunge un elemento politico ulteriore. Con l’ordine esecutivo del 18 settembre, il governatore californiano ha avviato un percorso per valutare nuovi requisiti di sicurezza, compreso un possibile sistema di arresto d’emergenza per i modelli più avanzati. Il precedente del 2024, quando aveva posto il veto a una proposta legislativa più restrittiva, rende il cambiamento particolarmente significativo. Non dimostra, da solo, che la nuova iniziativa sia dettata da calcoli elettorali, ma documenta come il quadro politico sia mutato nel giro di due anni. La California, sede di alcune delle principali imprese del settore, si trova in una posizione nella quale la regolamentazione dell’IA è contemporaneamente una questione di sicurezza pubblica, competitività industriale e leadership istituzionale.

Dal punto di vista tecnico, parlare di un unico kill switch è però fuorviante. Un modello linguistico, un agente dotato di accesso a Internet e un sistema collegato a infrastrutture operative non presentano lo stesso profilo di rischio. Nel primo caso può essere sufficiente interrompere il servizio ospitato dal fornitore; nel secondo occorre poter revocare credenziali, bloccare strumenti esterni e terminare processi già avviati; nel terzo bisogna considerare anche i sistemi fisici o digitali che ricevono le istruzioni dell’agente. Arrestare il modello non significa necessariamente annullare le azioni che ha già innescato. Un pagamento autorizzato, un file sottratto o un comando trasmesso a un sistema remoto possono produrre conseguenze anche dopo la cessazione dell’inferenza.

Questa distinzione separa la disponibilità di un comando amministrativo dalla capacità di garantire un arresto effettivo. Un fornitore può interrompere un modello eseguito sui propri server, purché controlli l’infrastruttura e disponga delle autorizzazioni necessarie. La situazione cambia quando il software viene distribuito presso clienti, installato in ambienti isolati oppure integrato in applicazioni di terzi. Il controllo dell’accesso a un servizio non coincide con il controllo del modello stesso, mentre un comando di spegnimento remoto non può essere considerato una garanzia assoluta se l’operatore non dispone di un canale affidabile per raggiungere il sistema.

È qui che emerge il nodo dei modelli open-weight, i cui pesi vengono distribuiti e possono essere eseguiti o modificati da soggetti diversi dallo sviluppatore originale. Una volta scaricato un modello, chi lo ha pubblicato può non avere più alcun controllo operativo sull’istanza installata da un cliente. Eventuali meccanismi di sicurezza possono essere rimossi o aggirati, mentre il modello può continuare a funzionare senza collegarsi ai server del produttore. Imporre al distributore originario una responsabilità illimitata per ogni impiego successivo significherebbe trasferirgli un obbligo che, in molti casi, non ha gli strumenti per adempiere. Esentare automaticamente ogni modello aperto, al contrario, potrebbe lasciare scoperti scenari di rischio che meritano una valutazione rigorosa.

Il conflitto è industriale prima ancora che ideologico. Le imprese che sostengono l’ecosistema open-weight vedono in questi modelli un mezzo per ridurre i costi, limitare la dipendenza dai grandi fornitori cloud e consentire lo sviluppo di applicazioni specializzate. Un regime di responsabilità mal progettato potrebbe favorire gli operatori che controllano verticalmente infrastruttura, distribuzione e accesso ai modelli, penalizzando invece le aziende più piccole e i fornitori indipendenti. La questione riguarda quindi anche la struttura competitiva del mercato americano: una misura concepita per ridurre il rischio potrebbe, se formulata senza proporzionalità, consolidare proprio il potere delle imprese che dispongono delle maggiori risorse per rispettarla.

La risposta non può essere nemmeno quella di considerare impossibile ogni intervento tecnico. Le procedure di sospensione dei servizi, la revoca delle credenziali, il blocco delle chiamate agli strumenti e l’isolamento delle infrastrutture sono misure realizzabili in molti ambienti controllati. Più difficile è garantire che funzionino in ogni configurazione, senza compromettere sistemi legittimi o provocare interruzioni impreviste. La discussione dovrebbe pertanto concentrarsi sulle capacità verificabili richieste a ciascuna categoria di sistema, sulle condizioni che autorizzano l’intervento e sulla responsabilità per eventuali errori. Un interruttore che nessuno ha testato in condizioni avverse rischia di essere soprattutto una rassicurazione documentale.

Anche la governance merita attenzione. Se il Department of Homeland Security potrà ordinare la sospensione di determinati sistemi, serviranno criteri comprensibili per definire il pericolo, procedure di escalation e forme di controllo sulle decisioni più invasive. Un potere d’emergenza senza limiti sufficientemente chiari può diventare fonte di incertezza per le imprese; un potere troppo debole, invece, rischia di arrivare quando il danno è già avvenuto. Il problema è stabilire chi certifica il rischio, quali prove devono giustificare l’ordine e come si distingue un comportamento realmente pericoloso da un risultato inatteso ma innocuo. Sono questioni che il semplice nome kill switch non risolve.