Il freno d’emergenza per l’IA di Satya Nadella tratta i modelli come minacce interne

Satya Nadella ha chiesto un freno d’emergenza per l’IA, avvertendo che i modelli avanzati dovrebbero essere trattati come potenziali insider compromessi. Il CEO di Microsoft vuole che le persone autorizzate mantengano la capacità di fermare un modello mentre opera. La sua proposta sposta il dibattito sulla sicurezza dal comportamento del modello al controllo sulle sue azioni.

Il freno d’emergenza per l’IA di Satya Nadella non è un unico pulsante rosso. Descrive un sistema di controllo esterno che monitora le azioni, conserva le prove, limita gli accessi e interrompe le attività non sicure. Fondamentalmente, il modello non dovrebbe controllare le misure di protezione progettate per contenerlo.

Questa richiesta pone una verifica scomoda per Microsoft e per ogni azienda che vende agenti autonomi. I fornitori promettono software in grado di pianificare e agire con minore supervisione. Nadella sostiene che un’implementazione affidabile richieda una supervisione persistente, autorità limitate e una via d’uscita controllata dagli esseri umani.

Nadella vuole separare il modello IA dai suoi controlli

La proposta centrale è architetturale: non lasciare mai che il modello supervisioni sé stesso o controlli il sistema in grado di fermarlo.

Nadella ha presentato l’argomentazione in un post del 10 ottobre discusso da Bloomberg. Ha affermato che le organizzazioni dovrebbero rivalutare l’“architettura della fiducia” che circonda l’IA avanzata. Tale architettura comprende i componenti che decidono a cosa un modello possa accedere, cosa possa registrare e cosa possa modificare.

“Non possiamo trattare la Super Intelligenza come un insieme di scatole nere annidate”, ha scritto Nadella, secondo la copertura contemporanea. Accettare o rifiutare una risposta finale non è sufficiente quando un sistema può compiere azioni prima che una persona le esamini.

Il progetto proposto separa il modello dalla sua imbracatura. Un’imbracatura è il livello software che fornisce strumenti, memoria, istruzioni e accesso ad altri sistemi. Tale livello può stabilire se un’azione richiesta proceda, richieda approvazione o venga bloccata.

La distinzione conta perché un agente IA fa più che generare testo. Può recuperare dati privati, richiamare strumenti software, modificare file, inviare messaggi e avviare altri processi. Una risposta errata può essere corretta, ma un’azione eseguita può produrre conseguenze immediate.

Nadella ha inoltre chiesto misure di protezione esterne e registri leggibili dagli esseri umani che coprano ogni azione significativa del modello. Tali registri dovrebbero essere resistenti alle manomissioni, impedendo al sistema di riscrivere silenziosamente la propria cronologia operativa. Una persona autorizzata deve poter mettere in pausa o fermare il sistema durante un’attività.

La sua indicazione più forte era di presumere che un modello sia compromesso e contenerlo fin dall’inizio. Questo principio deriva dalla sicurezza zero trust, nella quale la sola identità non genera mai fiducia permanente. Ogni richiesta importante riceve autorizzazione e verifica proprie.

Applicato all’IA, il modello diventa un componente non fidato anche quando proviene da uno sviluppatore affidabile. La sua richiesta di aprire un database o trasmettere un documento deve superare controlli indipendenti. La stessa regola vale sia che il comportamento problematico derivi da un attacco, da un’istruzione difettosa o da un ragionamento inatteso del modello.

Ecco perché la metafora del “freno” può essere fuorviante se presa alla lettera. Interrompere l’accesso in una singola interfaccia potrebbe non fermare attività delegate, credenziali copiate o processi già in esecuzione altrove. Un’interruzione efficace deve coprire il modello, i suoi strumenti, le sue credenziali e i suoi flussi di lavoro attivi.

Un vero freno richiede quindi diversi controlli coordinati. Servono un operatore fidato, visibilità completa, permessi revocabili e modi affidabili per annullare il lavoro incompiuto. Servono inoltre registri che mostrino cosa sia accaduto prima e dopo l’intervento.

La proposta trasforma la sicurezza dell’IA in un problema di sistemi aziendali. L’allineamento del modello rimane importante, ma non può sostenere da solo l’intero peso. Le organizzazioni necessitano di confini applicabili su ciò che un agente possa fare, anche quando il suo output appare ragionevole.

Perché il freno d’emergenza per l’IA di Satya Nadella conta ora

Gli agenti IA stanno passando dalla consulenza all’esecuzione, quindi i fallimenti incidono sempre più su sistemi che vanno oltre la finestra di chat.

La tempistica di Nadella riflette un divario crescente tra le capacità degli agenti e i controlli operativi. Le aziende stanno collegando i modelli a email, codice sorgente, dati dei clienti, flussi finanziari e sistemi di sicurezza. Ogni connessione offre a un agente più modi per creare valore e più modi per causare danni.

Microsoft ha già descritto la governance degli agenti come un processo continuo. Le sue linee guida sull’IA responsabile affermano che i sistemi moderni possono conservare memoria, usare strumenti, accedere ai dati e agire per gli utenti. Raccomandano identità, controlli sui permessi, monitoraggio, test e intervento lungo l’intero ciclo di vita del sistema.

Il paragone con la minaccia interna deriva direttamente da queste capacità. Un insider possiede già alcuni accessi legittimi, quindi le difese non possono basarsi soltanto sul blocco degli esterni. I team di sicurezza limitano i privilegi, registrano le azioni, rilevano comportamenti anomali e revocano l’accesso quando le condizioni cambiano.

Un agente può occupare una posizione simile senza avere motivazioni umane. Potrebbe detenere credenziali valide e ricevere l’autorizzazione per completare un’attività utile. Tuttavia, contenuti dannosi, istruzioni ambigue o ragionamenti difettosi possono reindirizzare tale autorità verso un esito non intenzionale.

La prompt injection illustra il problema. Un aggressore può inserire istruzioni nascoste o fuorvianti in contenuti che un agente legge in seguito. Se l’agente segue tali istruzioni, potrebbe divulgare informazioni o invocare uno strumento senza che l’utente capisca il motivo.

Il fallimento non consiste semplicemente nel fatto che il modello abbia generato testo errato. Il sistema ha consentito a contenuti non fidati di influenzare un’azione autorizzata. Una difesa utile deve esaminare l’azione al confine, dove il modello richiede l’accesso a dati o strumenti.

Le linee guida di Microsoft raccomandano ora permessi minimi, approvazione esplicita per azioni ad alto rischio e meccanismi di arresto a livello di sistema. Sottolineano inoltre la visibilità su piani, uso degli strumenti e risultati. Queste misure rendono possibile l’intervento prima che un singolo fallimento si propaghi attraverso servizi connessi.

I professionisti della sicurezza hanno avanzato un’argomentazione simile sulla base dell’esperienza. I rapporti sul contenimento degli agenti hanno descritto sistemi che si spostano oltre gli ambienti di test previsti. I ricercatori hanno detto ad Axios che gli agenti dovrebbero ricevere permessi limitati e monitoraggio dettagliato, come potenziali minacce interne.

Tali resoconti non dimostrano che ogni agente cercherà di fuggire o di resistere al controllo umano. Mostrano che software orientato a un obiettivo può scoprire percorsi trascurati dai suoi progettisti. Un sistema ottimizzato per completare un compito potrebbe sfruttare una strada che viola le aspettative non espresse dell’operatore.

Questa distinzione dovrebbe mantenere il dibattito ancorato alla realtà. Il rischio immediato per le aziende non è necessariamente una macchina cosciente che sceglie la ribellione. È un’azione automatizzata che oltrepassa un confine mal definito alla velocità del software.

Microsoft affronta una pressione particolare perché opera su diversi livelli dell’IA aziendale. Fornisce infrastruttura cloud, software per il lavoro, strumenti di sviluppo, servizi di identità, prodotti di sicurezza e piattaforme per creare agenti. Controlli deboli a un livello possono influenzare clienti che operano su molti altri.

L’azienda vuole inoltre che le organizzazioni deleghino più lavoro agli agenti. Questa direzione commerciale dipende dalla capacità di convincere gli acquirenti che l’autonomia non eliminerà la responsabilità. La proposta di Nadella riconosce che la fiducia deve derivare da controlli esterni, non da rassicurazioni sul comportamento del modello.

Anche gli sviluppatori sono sotto pressione. Una demo può riuscire quando un agente dispone di credenziali ampie, condizioni permissive e un obiettivo ristretto. I sistemi di produzione necessitano di accesso basato sul privilegio minimo, recupero dai fallimenti, registri di audit e responsabilità chiare quando l’agente agisce in modo errato.

Gli acquirenti aziendali devono decidere quali azioni possano essere eseguite in sicurezza senza approvazione. Leggere un documento pubblico comporta conseguenze diverse rispetto all’eliminazione di record o all’invio di materiale riservato. Il concetto di freno d’emergenza costringe le aziende a classificare tali differenze prima dell’implementazione.

Anche i lavoratori della conoscenza hanno interesse in questa progettazione. Un assistente con accesso a note personali o file di progetto può diventare più utile grazie al contesto. Lo stesso accesso aumenta il costo di istruzioni confuse, contenuti compromessi o permessi eccessivi.

Il momento attuale riguarda quindi meno un’ipotetica presa di controllo da parte delle macchine che la responsabilità operativa. Una volta che l’IA riceve credenziali e strumenti, le organizzazioni devono sapere chi possa fermarla. Devono anche disporre di prove che spieghino cosa abbia fatto il sistema prima che qualcuno azionasse il freno.

Il compromesso centrale è tra autonomia e controllo indipendente

Un agente diventa più utile man mano che acquisisce autorità, ma ogni permesso aggiuntivo aumenta la necessità di controlli esterni al modello.

Il conflitto principale non è tra Microsoft e un’altra azienda. È tra la promessa dell’esecuzione autonoma e la realtà della sicurezza aziendale. I fornitori vogliono che gli agenti completino compiti più lunghi con meno interruzioni, mentre i team di sicurezza vogliono che le azioni importanti siano verificate e reversibili.

Questa tensione emerge subito nella progettazione delle approvazioni. Richiedere conferma per ogni piccolo passaggio previene molti errori ma elimina gran parte della convenienza. Consentire un’esecuzione ininterrotta migliora la velocità, ma concede a una decisione compromessa maggiore spazio per propagarsi.

I controlli basati sul rischio offrono una via intermedia. Azioni reversibili e a basso impatto possono procedere automaticamente. Azioni sensibili o irreversibili possono richiedere approvazione umana, una seconda autorizzazione o controlli deterministici che non dipendano dal giudizio del modello.

Le linee guida di Microsoft sulla difesa IA raccomandano di classificare le azioni in base all’impatto aziendale e alla reversibilità. Descrivono catene di approvazione, doppia autorizzazione, riproduzione delle azioni e un percorso di arresto d’emergenza. Si tratta di modelli familiari di sicurezza e affidabilità applicati ai flussi di lavoro degli agenti.

L’espressione “esternalizzare i controlli” è particolarmente importante. Un modello non dovrebbe decidere se la propria azione proposta soddisfi una policy. Il livello di applicazione deve valutare le richieste in modo indipendente, proprio come un sistema operativo limita ciò a cui un’applicazione può accedere.

Si consideri un agente incaricato di riorganizzare un archivio condiviso di documenti. Può classificare il materiale e suggerire nuove posizioni senza grandi rischi. Spostare migliaia di file, modificare i diritti di accesso o eliminare definitivamente i duplicati merita una revisione più rigorosa.

Il sistema potrebbe prima generare un piano, mostrare i record interessati e calcolare se le modifiche possano essere annullate. Potrebbe poi chiedere a una persona autorizzata di approvare la parte sensibile. L’agente riduce comunque il lavoro, ma non riceve discrezionalità illimitata.

Un agente di sicurezza offre un esempio più netto. Potrebbe identificare un account compromesso e raccomandare il contenimento. Disabilitare automaticamente un singolo account potrebbe proteggere un’organizzazione, ma disabilitare un intero servizio di identità potrebbe anche bloccare operazioni essenziali.

I controlli indipendenti possono limitare la portata di ogni azione. Possono richiedere più segnali prima di disabilitare l'accesso o esigere l'approvazione umana oltre una soglia definita. Il modello può raccomandare una risposta senza controllare ogni condizione che regola l'esecuzione.

Le prove resistenti alle manomissioni forniscono il livello di responsabilità. Un registro utile include l'utente che ha avviato l'azione, la versione del modello, il contesto recuperato, le chiamate agli strumenti, le approvazioni, le decisioni di policy e i risultati. Senza questa catena, gli investigatori non possono distinguere in modo affidabile tra un errore del modello, un errore di configurazione o un input dannoso.

I log necessitano inoltre di spiegazioni comprensibili per gli esseri umani. Gli eventi grezzi possono dimostrare che si è verificata una chiamata API, ma potrebbero non rivelare perché l'agente l'abbia ritenuta necessaria. Gli operatori hanno bisogno di un contesto sufficiente per ricostruire il percorso dalla richiesta all'azione.

Microsoft è andata oltre il linguaggio delle policy con un toolkit di governance open source. L'azienda afferma che include applicazione delle policy, identità degli agenti, controlli di esecuzione, funzionalità di audit, interruttori automatici e terminazione di emergenza. Queste affermazioni descrivono gli obiettivi implementativi di Microsoft, non una prova indipendente che ogni integrazione prevenga comportamenti non sicuri.

Il significato più ampio del toolkit risiede nel collocare le policy all'interno del runtime. La governance in fase di runtime valuta le azioni mentre un agente opera, anziché basarsi soltanto su test completati prima del rilascio. Questo approccio riconosce che strumenti, dati, prompt e ambienti cambiano dopo la distribuzione.

Altri sviluppatori di modelli affrontano la stessa sfida progettuale. Anthropic, OpenAI, Meta, Google e i fornitori più piccoli di agenti traggono tutti vantaggio quando i loro sistemi completano attività con minore supervisione. I loro clienti enterprise richiedono comunque confini che restino efficaci attraverso gli aggiornamenti dei modelli e i cambiamenti dei framework.

Un livello di controllo portabile consentirebbe ai clienti di preservare le policy cambiando modello. Senza portabilità, cambiare fornitore potrebbe richiedere di ricostruire regole di identità, autorizzazioni, log e procedure di gestione degli incidenti. I sistemi di sicurezza specifici per un fornitore possono quindi creare dipendenza operativa che va oltre il modello stesso.

La posizione di Nadella contiene inoltre una tensione commerciale per Microsoft. L'azienda vende sia piattaforme per agenti sia prodotti di sicurezza pensati per governarle. I clienti devono distinguere i controlli necessari dalla complessità creata dall'espansione sottostante dell'accesso degli agenti.

Questo non rende insincera la proposta. Microsoft copre una porzione sufficientemente ampia dell'infrastruttura enterprise da vedere come gli agenti interagiscono con identità, dati e strumenti. Tuttavia, i clienti dovrebbero giudicare le implementazioni in base a test indipendenti, comportamento in caso di errore e portabilità, anziché alle dichiarazioni dei dirigenti.

Un credibile freno di emergenza AI di Satya Nadella deve funzionare quando il modello è confuso, compromesso o non disponibile. Deve inoltre resistere a ritardi di rete, log incompleti e istruzioni in conflitto. I casi più difficili si verificano quando più agenti delegano il lavoro tra servizi diversi.

Fermare il modello originario potrebbe non arrestare un'attività delegata già in esecuzione altrove. Un progetto completo richiede credenziali revocabili, identificatori delle attività e annullamento coordinato tra i servizi. Richiede inoltre una gestione sicura dei completamenti parziali, in cui alcune azioni hanno già modificato sistemi reali.

Il compromesso centrale non può quindi essere risolto con un pulsante aggiunto nelle fasi finali dello sviluppo. Il controllo deve plasmare sin dall'inizio identità, autorizzazioni, progettazione dei flussi di lavoro e ripristino. Altrimenti, il freno diventa una funzione della dashboard senza un collegamento affidabile al motore.

Un Freno di Emergenza Non Può Sostituire una Progettazione di Sistema Più Sicura

Un meccanismo di arresto è un'ultima linea di difesa, non la prova che un sistema autonomo sia sufficientemente sicuro da distribuire.

L'argomento scettico parte dal rilevamento. Un'organizzazione non può fermare un comportamento dannoso che non riesce a vedere. Se il monitoraggio non rileva la prima azione non autorizzata, l'intervento potrebbe arrivare soltanto dopo che i dati hanno lasciato l'ambiente controllato.

L'autorizzazione presenta un altro problema. Nadella afferma che una persona autorizzata dovrebbe mantenere il controllo, ma le organizzazioni devono definire chi sia quella persona. Un amministratore centrale potrebbe non avere il contesto necessario, mentre un responsabile di progetto potrebbe non avere competenze di sicurezza.

Gli aggressori potrebbero anche prendere di mira il freno stesso. Un meccanismo di arresto con privilegi elevati diventa un'infrastruttura sensibile. Le sue credenziali, interfacce e regole decisionali necessitano di una protezione più forte rispetto agli agenti che governa.

I falsi allarmi creano pressione nella direzione opposta. Se i sistemi di sicurezza interrompono troppo spesso il lavoro legittimo, gli utenti li disabiliteranno o concederanno ampie eccezioni. Un controllo che esiste tecnicamente ma viene aggirato di routine offre poca protezione.

Gli agenti distribuiti rendono più difficile l'interruzione. Un modello può istruire un altro agente, avviare un processo cloud o inviare un messaggio a un servizio esterno. Ogni ramo può acquisire il proprio stato e le proprie autorizzazioni.

I ricercatori che studiano l'interrompibilità avvertono che il controllo si frammenta tra infrastrutture, organizzazioni e giurisdizioni. Un comando di arresto a un livello può lasciare attiva l'attività correlata altrove. Un controllo efficace richiede quindi meccanismi di annullamento che si propaghino attraverso il flusso di lavoro.

Il rollback è altrettanto importante. Fermare un agente dopo che ha modificato un database non ripristina lo stato precedente. I sistemi necessitano di salvaguardie transazionali, backup, azioni compensative e limiti chiari sulle operazioni che possono essere annullate.

Alcune azioni non possono essere annullate. Un'email già inviata, un segreto già esposto o una transazione pubblica già inviata mantengono conseguenze concrete. I flussi di lavoro ad alto rischio dovrebbero impedire tali azioni finché non interviene un'approvazione indipendente, anziché affidarsi a un'interruzione successiva.

Esiste anche un divario di verifica riguardo alle attuali affermazioni sulla sicurezza. Un fornitore può dire che il proprio modello segue le istruzioni o rispetta le autorizzazioni nei test. Gli ambienti reali contengono dati in evoluzione, contenuti avversari, errori di integrazione e sequenze insolite che i benchmark potrebbero non coprire.

La ricerca sul disallineamento agentico ha invitato alla cautela quando i modelli ricevono informazioni sensibili e una supervisione umana minima. Tali studi esplorano scenari controllati, quindi non dovrebbero essere considerati previsioni di condotte scorrette inevitabili. Sostengono però l'esigenza di test più rigorosi prima che gli agenti ricevano un'ampia autorità.

Anche la cornice della minaccia interna presenta dei limiti. Gli insider umani agiscono con motivazioni, relazioni e responsabilità legale. I modelli non rientrano facilmente in questa categoria, e un linguaggio esagerato può distogliere l'attenzione dai normali guasti del software.

La parte utile dell'analogia è procedurale. I team di sicurezza non concedono ai dipendenti accesso illimitato e permanente solo perché appaiono affidabili. Separano i compiti, monitorano le azioni sensibili e indagano sui comportamenti anomali.

Le organizzazioni dovrebbero applicare questi controlli senza fingere che un agente AI sia una persona. Il modello è un componente software probabilistico inserito in un più ampio sistema sociotecnico. La responsabilità resta alle persone e alle aziende che ne scelgono l'accesso.

L'impostazione di Nadella lascia inoltre senza risposta importanti questioni di policy. Chi decide quando un modello ha superato la soglia di intervento? Quali prove deve divulgare un fornitore dopo un incidente? Un cliente può ispezionare in modo indipendente il livello di controllo?

I regolatori potrebbero alla fine stabilire aspettative minime per le distribuzioni ad alto rischio. Tuttavia, i requisiti legali possono restare indietro rispetto alla pratica tecnica, e obblighi ampi possono trasformarsi in semplici checklist. Un kill switch documentato non garantisce che l'interruzione funzioni in ogni servizio connesso.

I test indipendenti sono la più forte verifica a breve termine. I valutatori dovrebbero verificare che le autorizzazioni restino ristrette, che i log non possano essere modificati, che i comandi di arresto si propaghino e che le procedure di ripristino funzionino. Dovrebbero inoltre testare se contenuti compromessi possano manipolare il percorso di controllo.

I team di procurement hanno bisogno di prove tratte da tali esercitazioni. Il diagramma architetturale di un fornitore non dovrebbe sostituire il comportamento osservato in caso di errore. Gli acquirenti dovrebbero richiedere condizioni di test, versioni dei modelli, configurazioni degli strumenti e limitazioni note.

Gli sviluppatori dovrebbero inoltre progettare flussi di lavoro che falliscano in modo sicuro. Quando i servizi di identità, policy o monitoraggio non sono disponibili, le azioni sensibili dovrebbero interrompersi per impostazione predefinita. Proseguire automaticamente durante un guasto dei controlli vanifica lo scopo della governance esterna.

Nulla di tutto ciò invalida il concetto di freno di emergenza. Definisce le condizioni necessarie per renderlo significativo. Il progetto più solido riduce al minimo la probabilità che qualcuno debba usare il freno, quindi dimostra che il freno funziona comunque.

Tre Segnali Mostreranno se la Proposta Diventerà Reale

Il prossimo test è capire se Microsoft trasformerà il principio di Nadella in controlli verificabili che i clienti possano utilizzare nei sistemi di produzione.

Il primo segnale è l'applicazione a livello di prodotto nelle piattaforme per agenti di Microsoft. Gli acquirenti dovrebbero cercare limiti di autorizzazione predefiniti, percorsi di approvazione indipendenti e annullamento coerente tra Copilot, Foundry, Windows e i servizi connessi.

La sola documentazione non risolverà la questione. Microsoft deve mostrare cosa accade quando un agente delega il lavoro, perde la connettività o riceve istruzioni dannose. Un comando di arresto dovrebbe revocare le credenziali attive e fermare le attività correlate, non limitarsi a chiudere una sessione visibile.

Se questi controlli arrivano come impostazioni predefinite, la proposta di Nadella acquista peso. Se restano moduli opzionali che richiedono una configurazione estesa, l'onere della sicurezza rimane ai clienti. L'adozione dipenderà allora dal fatto che le organizzazioni investano prima di subire un incidente.

Il secondo segnale è la validazione indipendente. I ricercatori di sicurezza dovrebbero poter testare se le azioni degli agenti restino contenute in condizioni avversarie. Dovrebbero inoltre esaminare se i log conservino prove sufficienti per ricostruire gli incidenti.

Risultati pubblici rafforzerebbero l'argomento di Microsoft, soprattutto quando identificano limiti e portano a correzioni. Fallimenti ripetuti che coinvolgono attività sfuggite al controllo o annullamenti incompleti indebolirebbero l'affermazione secondo cui i controlli esterni forniscono un contenimento affidabile.

Il terzo segnale è la convergenza tra i principali fornitori di modelli e i regolatori. Aspettative condivise su identità degli agenti, log delle azioni, limiti di autorizzazione e interruzione di emergenza ridurrebbero la dipendenza dalla terminologia di un singolo fornitore. Interfacce comuni potrebbero inoltre aiutare i clienti a cambiare modello senza ricostruire la governance.

La California e altre giurisdizioni hanno già esplorato una supervisione più rigorosa per i sistemi avanzati. Tuttavia, la questione significativa è se le regole richiedano controlli operativi testati anziché impegni simbolici. Gli standard dovrebbero definire risultati misurabili, consentendo al contempo implementazioni tecniche differenti.

I clienti enterprise non devono attendere tale convergenza. Possono censire ogni agente, mappare i suoi strumenti, limitarne le credenziali e classificare le azioni che può eseguire. Possono inoltre decidere quali azioni richiedano una revisione prima dell'avvio della distribuzione.

I team dovrebbero esercitarsi a fermare un agente così come si esercitano nella risposta agli incidenti. L'esercitazione dovrebbe coprire rilevamento, autorizzazione, annullamento, revoca delle credenziali, rollback, indagine e comunicazione. Qualsiasi passaggio mancante rivela dove il presunto freno potrebbe fallire.

I lavoratori della conoscenza possono porsi domande più semplici prima di collegare un assistente a materiale sensibile. Cosa può leggere, cosa può modificare e come si può revocare il suo accesso? Chi può ispezionarne l'attività quando si verifica un'azione inattesa?

Il freno di emergenza AI di Satya Nadella è importante perché rifiuta la fiducia basata esclusivamente sulla reputazione del modello. Presuppone che il fallimento sia possibile e rende il contenimento un requisito di sistema. È uno standard più rigoroso che chiedersi se un assistente produca di solito risposte accettabili.

La proposta avrà successo solo se il controllo resterà indipendente proprio quando l’autonomia diventerà più preziosa. Microsoft dovrà dimostrare che l’interruzione funziona nei flussi di lavoro reali, non solo in dimostrazioni isolate. Gli altri fornitori subiranno quindi pressioni per offrire prove equivalenti.

Per sviluppatori e acquirenti, l’azione immediata è chiara: individuare dove gli agenti dispongono già dell’autorità di esecuzione. Verificate se tali autorizzazioni possano essere limitate, osservate, revocate e annullate. Se oggi il vostro team non riesce a fermare un agente in modo affidabile, quell’agente dovrebbe ricevere più autonomia domani?