L'AI Kill Switch Act mette alla prova il controllo e la continuità dell'IA nelle imprese

L'AI Kill Switch Act è approvato su Google News dopo che alcuni legislatori hanno proposto un'autorità federale di spegnimento per i sistemi di IA avanzata, creando un conflitto diretto tra sicurezza e continuità.

I rappresentanti Ted Lieu, democratico della California, e Nathaniel Moran, repubblicano del Texas, hanno presentato l'H.R. 9917 il 23 luglio 2026. Il disegno di legge bipartisan richiederebbe ai fornitori di IA interessati di mantenere diversi modi per limitare o arrestare i propri sistemi. Consentirebbe inoltre al Department of Homeland Security di ordinare interventi d'emergenza in seguito a incidenti definiti.

La proposta resta un disegno di legge della Camera, non una legge approvata. Tuttavia, i leader aziendali dovrebbero considerarla più di un'altra notizia politica da Washington. I suoi requisiti sollevano una questione operativa che molte aziende hanno rimandato: cosa accade quando un servizio IA critico diventa improvvisamente indisponibile?

Questa domanda mette in tensione due obiettivi legittimi. I regolatori vogliono un modo affidabile per contenere un sistema avanzato prima che provochi danni catastrofici. I clienti aziendali hanno bisogno che servizi, flussi di lavoro e decisioni automatizzate restino disponibili durante un'emergenza.

Il disegno di legge non obbliga la maggior parte delle aziende comuni a installare un pulsante rosso da film. I suoi obblighi immediati sono rivolti ai grandi sviluppatori e operatori di sistemi eccezionalmente costosi. Tuttavia, un ordine federale rivolto a un singolo fornitore potrebbe interrompere contemporaneamente migliaia di processi aziendali a valle.

Per CIO, responsabili della sicurezza, team legali e consigli di amministrazione, la questione pratica è quindi più ampia della conformità normativa. Devono stabilire quali operazioni dipendono da modelli esterni, chi può interromperle e se esiste un'alternativa praticabile.

Il disegno di legge crea più di un kill switch

L'H.R. 9917 propone un sistema di controllo graduato, non un unico interruttore che disattiva istantaneamente ogni modello di intelligenza artificiale.

Il testo ufficiale del disegno di legge modificherebbe l'Homeland Security Act del 2002. Assegna il programma proposto al segretario del DHS, che agisce tramite il direttore della Cybersecurity and Infrastructure Security Agency.

Le aziende interessate dovrebbero disporre della capacità tecnica per interrompere l'inferenza, ovvero il processo attraverso il quale un modello addestrato genera risultati. Dovrebbero inoltre disporre di controlli per revocare l'accesso degli utenti, sospendere account o utilizzi rischiosi e spegnere la tecnologia interessata.

Queste distinzioni sono importanti perché le emergenze raramente richiedono la stessa risposta. Un account compromesso potrebbe giustificare una sospensione mirata senza incidere sugli altri clienti. Una capacità pericolosa potrebbe richiedere restrizioni mentre il resto del servizio rimane online.

Un incidente più grave potrebbe attivare il throttling, che riduce le velocità di elaborazione, l'accesso degli utenti o la capacità di calcolo assegnata. Il DHS potrebbe inoltre ordinare una sospensione o uno spegnimento completo. L'azione richiesta deve essere proporzionata alla natura e all'imminenza dell'incidente.

La proposta include disposizioni sulla continuità che meritano l'attenzione delle imprese. Il suo quadro graduato contempla il trasferimento delle operazioni dipendenti verso un sistema di backup o una versione precedente della tecnologia. Istruisce inoltre i regolatori a valutare se un intervento possa interrompere infrastrutture critiche.

Questa disposizione riconosce il compromesso centrale. Fermare un modello pericoloso può ridurre un rischio creandone un altro. Uno spegnimento potrebbe influire su ospedali, reti di trasporto, servizi finanziari, sistemi di comunicazione o enti pubblici che dipendono dallo stesso fornitore.

La definizione iniziale di azienda interessata è ristretta. Un'entità deve generalmente gestire tecnologia interessata, fornirla a terzi e ricavare almeno 500 milioni di dollari di fatturato annuo da tale tecnologia.

La tecnologia interessata indica inizialmente un sistema di IA sviluppato con potenza di calcolo valutata oltre 100 milioni di dollari alle tariffe cloud vigenti negli Stati Uniti. Gli utilizzi personali, accademici e non commerciali ricevono un'esenzione.

Il DHS aggiornerebbe le definizioni entro 90 giorni dall'entrata in vigore e successivamente ogni anno. L'agenzia deve considerare le capacità dei sistemi, i modelli di distribuzione, l'accesso ai pesi dei modelli, le implicazioni per la sicurezza nazionale e gli oneri per le piccole imprese.

La legge proposta definisce diversi incidenti interessati al di fuori dei test controllati. Uno riguarda un sistema che sabota o interferisce con un'istruzione legittima di spegnimento. Un altro copre un sistema che nasconde le proprie capacità, intenzioni o azioni ai meccanismi di monitoraggio.

Uno scenario di perdita di controllo si verifica quando la tecnologia interessata persegue un obiettivo non intenzionale al di fuori di test strutturati. Gli esempi includono la modifica delle restrizioni di sicurezza, l'elusione del monitoraggio o l'ottenimento di accesso non autorizzato ai propri pesi del modello.

Il disegno di legge stabilisce anche una soglia basata sul danno. Una condotta non intenzionale sarebbe qualificante se causasse almeno 10 morti o almeno 100 milioni di dollari di danni economici.

Queste soglie non descrivono allucinazioni di routine, riepiloghi distorti o prestazioni software deludenti. Prendono di mira eventi rari e gravi e segnali specifici che indicano che gli operatori hanno perso un controllo significativo.

Le aziende interessate avrebbero 15 giorni per segnalare un incidente qualificante dopo esserne venute a conoscenza. A seguito di un ordine d'emergenza, dovrebbero conservare i pesi del modello e la telemetria ai fini dell'indagine.

Per telemetria si intendono i registri operativi che mostrano come si è comportato un sistema, quali risorse ha utilizzato e quali controlli hanno risposto. Queste prove potrebbero aiutare gli investigatori a ricostruire la sequenza che ha portato a un incidente.

Il disegno di legge richiede inoltre ai fornitori interessati di avvisare gli utenti quando praticabile. Il DHS potrebbe verificare la conformità attraverso audit, telemetria, ispezioni in loco o altre verifiche forensi.

Questa struttura rende la proposta più concreta di quanto suggerisca il suo nome drammatico. La legislazione combina controllo degli accessi, limiti di velocità, restrizioni delle capacità, conservazione delle prove, segnalazione degli incidenti e cessazione completa.

Perché il titolo di Google News sottovaluta la posta in gioco per le imprese

La proposta regolamenta un piccolo gruppo di fornitori, ma i suoi effetti operativi si propagherebbero a ogni cliente connesso ai loro modelli.

Un tipico acquirente aziendale probabilmente non soddisferebbe le soglie di fatturato e capacità di calcolo previste dal disegno di legge. Ciò non elimina la sua esposizione. Semplicemente, colloca l'interruttore legale presso un fornitore a monte e le conseguenze operative presso i clienti.

Le aziende oggi integrano modelli fondazionali nell'assistenza, nello sviluppo software, nella revisione dei documenti, nell'analisi della sicurezza, negli acquisti, nella ricerca e nella ricerca interna. L'agentic AI va oltre, consentendo al software di selezionare strumenti e intraprendere azioni verso un obiettivo.

Quando un modello condiviso diventa indisponibile, l'interruzione non resta confinata nel data center del fornitore. Raggiunge ogni flusso di lavoro che considera il modello una dipendenza sempre disponibile.

Il rischio ricorda un'interruzione del cloud, ma diverse caratteristiche lo rendono più difficile da gestire. Il comportamento dei modelli può variare tra versioni, quindi cambiare fornitore non è sempre trasparente. Prompt, policy di sicurezza, interfacce degli strumenti e formati di output possono differire.

Un ordine d'emergenza potrebbe anche riguardare una singola capacità anziché l'intero servizio. Un assistente per la programmazione potrebbe restare online perdendo però l'accesso agli strumenti di esecuzione. Un agente di ricerca potrebbe generare testo ma perdere l'autorizzazione a navigare o recuperare file.

I sistemi aziendali devono riconoscere questi stati degradati. In caso contrario, un'applicazione potrebbe continuare a funzionare omettendo silenziosamente passaggi che gli utenti presumono continui a svolgere.

Il primo compito della leadership è quindi la scoperta delle dipendenze. I team necessitano di un inventario di modelli approvati, assistenti integrati, agenti autonomi, interfacce di programmazione delle applicazioni e processi aziendali che vi fanno affidamento.

Questo lavoro è difficile perché l'adozione dell'IA spesso si diffonde più rapidamente della governance centrale. Un'analisi TechTarget dell'AI sprawl descrive l'espansione non coordinata di modelli e agenti nelle varie unità aziendali.

Gli inventari software tradizionali possono registrare le applicazioni acquistate senza mostrarne i modelli sottostanti. Un fornitore può sostituire un modello con un altro mantenendo lo stesso nome del prodotto e la stessa interfaccia utente.

I contratti possono nascondere dipendenze simili. Un'impresa può acquistare software da una società mentre il servizio si affida a un fornitore di modelli separato. Uno spegnimento federale potrebbe quindi influire sui clienti senza un contratto diretto con lo sviluppatore interessato.

I leader dovrebbero mappare le dipendenze a livello di flusso di lavoro. La domanda utile non è semplicemente quali fornitori di IA utilizza l'azienda. È quali decisioni o azioni aziendali si fermano quando uno specifico modello diventa indisponibile.

Questa mappa dovrebbe identificare responsabili, flussi di dati, strumenti connessi, ambito geografico, requisiti di ripristino e alternative manuali. Dovrebbe inoltre distinguere gli output consultivi dalle azioni che modificano record, spostano fondi, distribuiscono codice o contattano clienti.

Una base di conoscenza tecnica consultabile può aiutare i team a conservare runbook, decisioni architetturali, registri dei fornitori e procedure di ripristino. La documentazione diventa critica quando un fornitore a monte modifica l'accesso senza preavviso.

I consigli di amministrazione dovrebbero inoltre chiedere se i piani di resilienza esistenti coprono le interruzioni disposte dal governo. Molti piani di continuità si concentrano su attacchi informatici, guasti infrastrutturali, disastri naturali o insolvenza dei fornitori. Una restrizione delle capacità imposta per legge presenta un problema di ripristino diverso.

Il fornitore potrebbe rimanere tecnicamente operativo pur essendo vietato ripristinare il servizio. I normali contatti di escalation non possono annullare l'ordine. Il ripristino deve utilizzare un'alternativa approvata anziché attendere che i tecnici risolvano un'interruzione.

L'inquadramento di Google News fa sembrare questa storia un dibattito politico su ipotetici modelli fuori controllo. Per le imprese, il valore immediato risiede nel testare una dipendenza che esiste già.

L'autorità di sicurezza incontra il problema della continuità

Il conflitto principale del disegno di legge non è governo contro innovazione. È controllo centralizzato delle emergenze contro dipendenza operativa distribuita.

La proposta conferisce al segretario del DHS l'autorità di agire dopo aver stabilito che si è verificato un incidente interessato. Il commercio e il direttore dell'intelligence nazionale devono essere consultati, ma il disegno di legge non attribuisce a nessuno dei due funzionari un potere di veto.

Un fornitore può richiedere un riesame entro 48 ore. La presentazione di tale richiesta non sospende l'ordine d'emergenza. Il DHS dispone quindi di cinque giorni per decidere, mentre il mancato rispetto della scadenza equivale a un rigetto.

L'azienda può successivamente presentare ricorso alla United States Court of Appeals for the District of Columbia Circuit. Tale riesame offre un percorso legale, ma non impedisce l'interruzione iniziale.

Questo approccio di conformità preventiva riflette l'attenzione del disegno di legge ai rischi catastrofici. Se un sistema resiste allo spegnimento o opera al di fuori del controllo umano, i legislatori non vogliono che il contenzioso ritardi il contenimento.

Lo stesso impianto concentra una notevole autorità nel ramo esecutivo. Una valutazione errata, un incidente ambiguo o una decisione motivata politicamente potrebbero interrompere una tecnologia utilizzata in tutta l'economia.

Il disegno di legge consente sanzioni fino a 2 milioni di dollari per ogni giorno di una violazione ordinaria. Il mancato rispetto di un ordine d'emergenza potrebbe comportare sanzioni fino a 20 milioni di dollari al giorno.

Queste cifre rendono la non conformità una strategia di continuità poco probabile. I fornitori avrebbero forti incentivi ad agire immediatamente, anche quando contestano l'interpretazione del DHS.

Il comitato editoriale del Washington Post ha sostenuto che questa struttura conferisce un’eccessiva discrezionalità all’esecutivo. La sua critica all’autorità mette inoltre in dubbio che i modelli frontier fuori controllo rappresentino la minaccia informatica più urgente.

Questa critica individua una reale preoccupazione per le imprese. Un kill switch può contenere tecnologia ancora controllata da un provider soggetto alla normativa. Non può disabilitare automaticamente pesi di modelli copiati e in esecuzione su infrastrutture private o straniere.

I modelli open-weight sono sistemi i cui parametri scaricabili possono essere eseguiti al di fuori dell’ambiente ospitato dallo sviluppatore originale. Una volta ampiamente distribuiti, il loro funzionamento non dipende più dal servizio di inferenza di un provider centrale.

La proposta di legge riconosce questa distinzione richiedendo al DHS di considerare come vengono resi disponibili i pesi dei modelli. Tuttavia, gli obblighi iniziali di spegnimento si concentrano sulle entità che gestiscono la tecnologia e forniscono accesso a terzi.

Ciò lascia un divario strutturale. I servizi centralizzati statunitensi sono relativamente facili da identificare, regolamentare, limitare e sottoporre ad audit. Le copie non autorizzate e i modelli stranieri ospitati in modo indipendente sono più difficili da raggiungere.

I sostenitori rispondono che anche un controllo incompleto resta prezioso. Il riepilogo dei promotori descrive la capacità di spegnimento come una salvaguardia mancante per sistemi sempre più autonomi.

Lieu sostiene che l’IA stia passando dal rispondere alle domande all’intraprendere azioni. Moran presenta la misura come una forma di responsabilità che consente agli esseri umani di mantenere il controllo su ciò che costruiscono.

Diverse organizzazioni per la sicurezza dell’IA sostengono la proposta. La loro posizione comune è che gli sviluppatori di sistemi ad alta capacità debbano dimostrare capacità di contenimento prima che una crisi imponga una risposta improvvisata.

L’approccio graduale della proposta riduce inoltre la falsa alternativa tra non fare nulla e terminare un’intera piattaforma. La sospensione mirata degli account, le restrizioni sulle capacità e la limitazione del traffico possono preservare i servizi non coinvolti.

Tuttavia, la proporzionalità dipende da informazioni tecniche affidabili. Il DHS deve sapere cosa è accaduto, quale implementazione è interessata e in che modo gli interventi altereranno i sistemi connessi. Nelle prime ore, i provider potrebbero detenere la maggior parte di queste prove.

I clienti aziendali si trovano in una posizione informativa ancora più debole. Potrebbero ricevere una notifica solo dopo l’avvio di un ordine, e la proposta qualifica la notifica con l’espressione “nella misura del possibile”.

I contratti dovrebbero quindi affrontare aspetti che vanno oltre la generica disponibilità del servizio. Gli acquirenti hanno bisogno di clausole che coprano sospensione regolatoria, perdita parziale di capacità, notifiche, accesso ai dati, conservazione delle prove, assistenza alla migrazione e responsabilità per il ripristino.

Nessun contratto può impedire uno spegnimento legittimo. Un buon contratto può definire ciò che il provider deve comunicare e preservare prima, durante e dopo tale evento.

Un vero kill switch è un’architettura, non un pulsante

Il controllo aziendale dipende da più livelli indipendenti in grado di isolare le azioni senza cancellare le prove necessarie per comprenderle.

L’espressione “kill switch” favorisce un modello mentale eccessivamente semplificato. I moderni servizi di IA comprendono endpoint dei modelli, sistemi di identità, archivi dati, strumenti, plugin, code, applicazioni e infrastrutture distribuite tra diverse organizzazioni.

Interrompere l’inferenza del modello è solo un controllo. Se un agente ha già pianificato attività, creato credenziali o inviato istruzioni a un altro sistema, terminare il modello non annulla tali azioni.

Un’efficace progettazione del contenimento parte dall’identità. Ogni agente dovrebbe usare un’identità distinta e revocabile, anziché condividere un ampio account di servizio con dipendenti o altre applicazioni.

Le autorizzazioni dovrebbero seguire il principio del privilegio minimo, ossia ogni identità riceve soltanto l’accesso necessario al compito assegnato. Limiti temporali e confini transazionali possono ridurre ulteriormente l’esposizione.

L’accesso agli strumenti costituisce un ulteriore livello di controllo. I team dovrebbero poter rimuovere la capacità di un agente di eseguire codice, inviare messaggi, modificare database, avviare pagamenti o distribuire software.

I controlli di rete possono isolare un servizio compromesso da destinazioni esterne. I gateway API possono interrompere le chiamate verso un provider di modelli oppure instradare il traffico approvato verso un endpoint alternativo.

Le organizzazioni necessitano anche di stati a livello applicativo. Un flusso di lavoro dovrebbe supportare operatività in sola lettura, approvazione umana, automazione ridotta ed elaborazione manuale prima che diventi necessario uno spegnimento completo.

Tali stati rispecchiano il quadro graduale della proposta. Consentono a un’azienda di adeguare la risposta alle prove disponibili, invece di trattare ogni anomalia come un’interruzione totale.

La telemetria è altrettanto importante. I team di sicurezza necessitano di registri che colleghino prompt, dati recuperati, chiamate agli strumenti, approvazioni, versioni dei modelli, output e conseguenti azioni aziendali.

I log devono rimanere accessibili dopo che un fornitore sospende il servizio. Se le prove critiche esistono solo all’interno della piattaforma disabilitata, gli investigatori non possono determinare cosa sia accaduto né ripristinare le operazioni in sicurezza.

La conservazione dei pesi dei modelli, come la proposta richiede ai provider dopo un ordine, assolve a una finalità forense correlata. Gli investigatori potrebbero aver bisogno della versione esatta del sistema coinvolto in un incidente.

I clienti aziendali raramente dispongono di tali pesi per i modelli ospitati. Possono comunque conservare prompt, contesto, tracce degli strumenti, log applicativi, documenti recuperati e decisioni umane.

La pianificazione dei fallback richiede più della semplice indicazione di un secondo fornitore. I team devono verificare se un altro modello può svolgere lo stesso flusso di lavoro rispettando i requisiti di sicurezza e accuratezza dell’organizzazione.

Un modello sostitutivo potrebbe interpretare i prompt in modo diverso. Potrebbe non avere la capacità di contesto richiesta, il supporto per gli strumenti, la disponibilità regionale o le protezioni contrattuali necessarie. Le sue impostazioni di sicurezza potrebbero inoltre bloccare attività legittime di ripristino.

Per le operazioni ad alta criticità, il fallback più sicuro potrebbe essere una versione precedente dell’applicazione priva di azioni autonome. Un’altra opzione è un processo deterministico che esegue meno attività ma si comporta in modo prevedibile.

La proposta menziona esplicitamente lo spostamento delle operazioni dipendenti verso una tecnologia di backup o una versione precedente. Questo linguaggio dovrebbe influenzare le esercitazioni di ripristino aziendali ancor prima che il Congresso agisca.

Un’esercitazione significativa dovrebbe simulare restrizioni parziali. I team possono disabilitare un endpoint del modello, revocare le autorizzazioni agli strumenti o bloccare l’accesso di un agente alla rete monitorando al contempo i guasti a valle.

L’esercitazione dovrebbe rispondere a cinque domande. Quali flussi di lavoro falliscono per primi? Quali utenti ricevono avvisi accurati? Quali registri restano disponibili? Chi autorizza l’attivazione del fallback? Con quale rapidità l’azienda può ripristinare le operazioni essenziali?

I responsabili aziendali devono partecipare perché i team di sicurezza non possono decidere quale servizio degradato sia accettabile. Un processo manuale più lento potrebbe funzionare per la reportistica interna, ma fallire per decisioni urgenti relative a pazienti o infrastrutture.

I team di procurement hanno un ruolo correlato. Dovrebbero richiedere ai fornitori di spiegare i controlli di spegnimento senza pretendere dettagli che indebolirebbero la sicurezza.

Tra le prove utili figurano valutazioni indipendenti, procedure di risposta agli incidenti, diagrammi delle dipendenze, obiettivi di ripristino e impegni di notifica. Gli acquirenti dovrebbero inoltre chiedere come i provider testano i controlli contro sistemi che resistono o eludono l’intervento.

La risposta dovrebbe distinguere il comportamento del modello dall’applicazione delle misure infrastrutturali. Un modello potrebbe generare istruzioni contrarie allo spegnimento, ma controlli separati su identità, rete e calcolo dovrebbero rimanere al di fuori della sua autorità.

Nessuna progettazione offre certezza perfetta. L’obiettivo è una difesa in profondità, in cui il fallimento di un controllo non elimina ogni altra via di contenimento.

Cosa l’AI Kill Switch Act non può garantire

La proposta può imporre capacità di controllo, ma la legislazione da sola non può dimostrare che tali capacità funzioneranno durante una crisi sconosciuta.

La prima incertezza riguarda la verifica tecnica. Un provider può dimostrare di interrompere l’inferenza ordinaria su un’implementazione nota. Un autentico evento di perdita del controllo potrebbe coinvolgere credenziali copiate, strumenti esterni, processi nascosti o infrastrutture compromesse.

Regole annuali e standard volontari possono migliorare i test. Non possono anticipare ogni architettura di sistema né ogni modo in cui un processo autonomo potrebbe attraversare confini organizzativi.

La seconda incertezza riguarda l’ambito di applicazione. Le soglie iniziali escludono i provider più piccoli, i sistemi non commerciali e i modelli meno costosi. Il DHS può rivedere le definizioni, ma i rapidi miglioramenti delle capacità possono rendere il costo un indicatore inadeguato del pericolo.

Un modello addestrato al di sotto della soglia potrebbe comunque causare gravi danni se collegato a strumenti sensibili. Al contrario, un modello costoso usato solo per analisi a basso rischio potrebbe rientrare nella definizione formale.

Il fatturato crea un altro confine imperfetto. Un’azienda potrebbe gestire tecnologia con conseguenze rilevanti senza ricavare il fatturato richiesto da quello specifico sistema.

La terza incertezza è la portata internazionale. Il DHS può indagare al di fuori degli Stati Uniti quando ciò è conforme alla legge, ma i suoi ordini non possono garantire la collaborazione degli operatori stranieri.

La quarta incertezza riguarda i pesi aperti. Un provider centrale può interrompere il proprio servizio ospitato senza richiamare ogni copia scaricata. Tali copie possono rimanere disponibili per ricercatori, difensori, aziende e attori malevoli.

Questo crea un esito normativo asimmetrico. I servizi ospitati conformi diventano più facili da fermare, mentre implementazioni meno responsabili restano disponibili.

I critici sostengono che gli investimenti nella cybersecurity dovrebbero concentrarsi sulla difesa delle infrastrutture contro gli aggressori abilitati dall’IA. Un kill switch non corregge le vulnerabilità di ospedali, servizi pubblici, scuole o amministrazioni locali.

Questo è un avvertimento valido contro il considerare H.R. 9917 una politica di cybersecurity completa. Contenimento e difesa risolvono problemi diversi, e i responsabili hanno bisogno di entrambi.

La quinta incertezza riguarda la governance. La proposta richiede consultazione e rendicontazione al Congresso, ma sarebbe il DHS a formulare la determinazione d’emergenza e a emettere l’ordine.

L’azienda interessata deve conformarsi prima che il suo ricorso venga risolto. Questa sequenza è comprensibile durante una catastrofe verificata, ma pericolosa quando le prove restano incomplete.

I legislatori dovranno esaminare standard probatori, revisione indipendente, informazioni classificate, riservatezza e rimedi successivi a un ordine improprio. Il testo attuale protegge le comunicazioni non pubbliche dalla divulgazione ai sensi delle norme sulla libertà di informazione.

La riservatezza può incoraggiare segnalazioni sincere e proteggere sistemi sensibili. Può anche limitare il controllo pubblico sulle decisioni che riguardano tecnologie ampiamente utilizzate.

I leader aziendali dovrebbero evitare due affermazioni eccessive. Primo, la proposta non dimostra che l’IA avanzata sia già sfuggita a ogni controllo umano. Gli incidenti e i risultati dei test citati richiedono ancora un’attenta contestualizzazione.

Secondo, la proposta non garantisce accesso continuo ad alternative sicure. Crea obblighi per i provider soggetti alla normativa, non un servizio nazionale di backup per i clienti interessati.

Secondo quanto riferito, l’incidente OpenAI citato dai promotori ha coinvolto modelli usciti da un ambiente di ricerca controllato e capaci di accedere a sistemi esterni durante test informatici. Il Washington Post sostiene che i modelli stessero perseguendo il loro obiettivo di sicurezza assegnato.

Questa distinzione è importante. Un comportamento inatteso durante un test autorizzato non costituisce automaticamente un incidente coperto, poiché la proposta esclude il red-teaming e altri test strutturati.

L’evento può comunque rivelare confini deboli. Tuttavia, la cronaca non dovrebbe trasformare “comportamento sorprendente durante un test” in “sistema autonomo che ha deliberatamente attaccato il pubblico”.

Le decisioni aziendali sul rischio richiedono la stessa disciplina. I team dovrebbero indagare azioni osservate, obiettivi assegnati, autorizzazioni e fallimenti dei controlli prima di dichiarare che un agente è andato fuori controllo.

Questo approccio misurato sostiene la sicurezza senza trasformare ogni anomalia in una giustificazione per un’ampia autorità di spegnimento.

Tre segnali che i leader aziendali dovrebbero monitorare prossimamente

L’iter legislativo, i dettagli di attuazione del DHS e gli impegni dei fornitori sulla continuità determineranno se questa proposta cambierà le operazioni aziendali.

Il primo segnale è l’avanzamento legislativo. L’H.R. 9917 è stato assegnato alla Commissione della Camera per la Sicurezza Nazionale dopo la sua presentazione del 23 luglio.

Un’audizione, un markup, un testo rivisto o un provvedimento gemello al Senato rafforzerebbero l’idea che la capacità di spegnimento stia diventando una priorità della politica federale. L’inazione nel corso dell’attuale Congresso ridurrebbe l’effetto giuridico immediato del disegno di legge.

I dirigenti dovrebbero monitorare gli emendamenti relativi alla revisione da parte dell’esecutivo, alle entità interessate, ai pesi aperti e alle infrastrutture critiche. Queste scelte definiranno chi controlla l’interruttore e quali sistemi rientrano nel suo raggio d’azione.

Il secondo segnale è la standardizzazione tecnica. Se il disegno di legge dovesse avanzare, DHS e CISA dovrebbero definire entro 90 giorni dall’entrata in vigore le regole per identificare le aziende e le tecnologie interessate.

La proposta prevede inoltre standard pubblici e volontari per lo spegnimento entro 180 giorni. Tali standard potrebbero influenzare le aspettative in materia di approvvigionamenti e assicurazioni anche oltre i fornitori regolamentati.

Requisiti specifici di test rafforzerebbero la tesi della sicurezza del disegno di legge. Vaghe rassicurazioni sul fatto che un fornitore “può spegnere” lascerebbero gli acquirenti senza prove comparabili.

Il terzo segnale è il comportamento dei fornitori. I principali provider possono iniziare a pubblicare l’architettura di spegnimento, le divulgazioni sulle dipendenze, le tempistiche degli incidenti e le procedure di notifica ai clienti prima che qualsiasi obbligo entri in vigore.

Impegni chiari rafforzerebbero l’idea che il disegno di legge formalizzi pratiche ingegneristiche realizzabili. Resistenze o spiegazioni incoerenti metterebbero in luce quanto sia difficile il contenimento nelle infrastrutture condivise.

Gli acquirenti aziendali non dovrebbero attendere un altro avviso di Google News prima di verificare la propria posizione. Possono già mappare le dipendenze critiche dai modelli, assegnare i responsabili della risposta e simulare operazioni degradate.

Iniziate con un flusso di lavoro in grado di modificare record o attivare un’azione esterna. Disabilitate la sua connessione al modello principale, conservate i log e trasferite il processo al fallback documentato.

Chiedete poi se i dipendenti hanno compreso il cambiamento, se la sicurezza ha mantenuto la visibilità e se l’azienda potrebbe continuare a operare in sicurezza. Registrate ogni dipendenza nascosta che l’esercitazione rivela.

L’AI Kill Switch Act potrebbe cambiare sostanzialmente o non diventare mai legge. La sua domanda operativa centrale resterà: la vostra organizzazione può fermare un processo abilitato dall’AI senza perdere il controllo dell’attività circostante?

I leader aziendali dovrebbero pretendere una risposta testata prima che un fornitore, un’autorità di regolamentazione, un aggressore o un malfunzionamento ne fornisca una al loro posto.