La governance della sicurezza AI di Microsoft si rafforza mentre gli agenti ottengono maggiore controllo

Microsoft ha riprogettato le proprie regole sull'AI responsabile mentre gli agenti acquisiscono più accesso, autonomia e capacità operative nei suoi prodotti. Il cambiamento nella governance della sicurezza AI di Microsoft affronta un conflitto fondamentale: i controlli scritti per i chatbot non regolano automaticamente software in grado di compiere azioni.

Il Responsible AI Transparency Report 2026 dell'azienda descrive nuove attività di threat modeling focalizzate sugli agenti, difese contro il prompt injection, classificatori di sicurezza e una supervisione pre-rilascio più rigorosa. Estende inoltre la governance oltre i modelli, includendo le piattaforme, gli strumenti, i dati e le applicazioni che li circondano.

Questa portata più ampia conta perché un agente può inviare messaggi, recuperare record, modificare documenti, chiamare strumenti software e delegare lavoro. Anthropic, OpenAI, Google e altri fornitori di modelli affrontano la stessa transizione: dalla generazione di risposte all'esecuzione di attività.

La risposta di Microsoft va oltre un aggiornamento delle policy. Rappresenta la scommessa che la sicurezza AI debba diventare un sistema di controllo operativo, non un documento esaminato prima del lancio.

La governance della sicurezza AI di Microsoft ora copre l'intero stack degli agenti

Microsoft sta spostando l'attenzione sulla sicurezza dagli output dei modelli all'intera catena di azioni che un sistema AI può eseguire.

L'azienda afferma di aver riprogettato in modo completo il proprio Responsible AI Standard. Questo standard guida il modo in cui Microsoft sviluppa, rilascia e gestisce sistemi AI in tutta la propria attività.

Secondo il suo transparency report, l'approccio rivisto riguarda modelli, servizi di piattaforma e applicazioni. Le capacità agentiche attraversano ogni livello anziché esistere come categoria di prodotto separata.

Un agente AI è un software che usa un modello per pianificare e completare attività tramite strumenti, dati o ambienti digitali. Il suo profilo di rischio dipende da più elementi oltre alle risposte del modello.

Un chatbot può produrre una risposta inesatta. Un agente può agire su quella risposta prima che una persona la esamini.

Questa differenza cambia ciò che la governance deve coprire. Un'azienda deve esaminare l'identità dell'agente, le autorizzazioni, la memoria, gli strumenti, i requisiti di approvazione e la cronologia di esecuzione.

Microsoft afferma che il suo standard ora include requisiti per le capacità agentiche lungo l'intero ciclo di vita dell'AI. L'azienda ha inoltre introdotto nuove pratiche di threat modeling progettate attorno al comportamento degli agenti.

Il threat modeling identifica in che modo un sistema potrebbe fallire, essere usato impropriamente o subire un attacco. Per gli agenti, il processo deve considerare attività in più fasi e condizioni che cambiano durante l'esecuzione.

Microsoft segnala diversi cambiamenti correlati. Ha ampliato le difese contro il prompt injection, aumentato la copertura dei classificatori di sicurezza, creato nuovi modelli di trasparenza e rafforzato le capacità di governance degli agenti.

Il prompt injection si verifica quando contenuti non attendibili tentano di sovrascrivere le istruzioni di un agente. L'attacco può comparire in un documento, un'email, una pagina web o un'interfaccia software elaborata dall'agente.

Un'iniezione riuscita può reindirizzare un agente senza compromettere il modello sottostante. Questo rende l'architettura dell'applicazione circostante centrale per la sicurezza.

Microsoft descrive inoltre un processo centralizzato di supervisione pre-rilascio. Il processo mira a verificare che i rischi pertinenti siano stati affrontati prima che un sistema diventi disponibile.

L'azienda allinea questo lavoro a quattro funzioni del NIST AI Risk Management Framework: govern, map, measure e manage. Queste funzioni trattano la gestione del rischio come un processo continuo anziché come una revisione finale prima del lancio.

Microsoft afferma di aver fornito formazione sull'AI responsabile a quasi 20.000 ingegneri, responsabili delle policy e clienti. Ha inoltre esaminato oltre 100 leggi proposte o promulgate durante la revisione del proprio standard.

Più di 80 dipendenti provenienti da oltre 30 team hanno partecipato a questo lavoro legale e di governance. Questi numeri mostrano la scala organizzativa dello sforzo, anche se non dimostrano che ogni controllo funzioni come previsto.

Il cambiamento centrale resta chiaro. Microsoft non presenta più la valutazione dei modelli come una protezione sufficiente per sistemi sempre più autonomi.

Il comportamento di un agente emerge dall'interazione tra il suo modello, le istruzioni, le autorizzazioni, gli strumenti, i dati e l'ambiente operativo. La governance deve seguire l'intera catena.

Perché le azioni degli agenti creano un problema di sicurezza diverso

Il problema più difficile inizia dopo che un modello genera una risposta, quando un agente trasforma quella risposta in un'azione esterna.

I controlli tradizionali per l'AI generativa si concentrano spesso sui contenuti. I team verificano se un modello produce istruzioni non sicure, risposte distorte, informazioni private o affermazioni inesatte.

I sistemi agentici aggiungono un ulteriore livello. Trasformano le decisioni del modello in chiamate a strumenti con conseguenze concrete.

Un agente per il servizio clienti potrebbe visualizzare i record degli account, scrivere risposte o autorizzare rimborsi. Un agente di coding potrebbe modificare un repository, eseguire comandi o aprire una pull request.

Un agente per l'ufficio potrebbe cercare nella posta, riassumere riunioni, aggiornare un documento e inviare messaggi ai colleghi. Ogni passaggio può influire su un sistema diverso con autorizzazioni separate.

Il rischio cresce per composizione. Un output del modello che sembra innocuo può attivare un'azione pericolosa se combinato con un accesso ampio o una convalida incompleta.

L'esempio di Microsoft per Agent Hooks illustra questo problema. Un agente di assistenza fittizio emette erroneamente rimborsi dopo che un controllo di approvazione genera un'eccezione.

Il framework circostante registra l'errore ma continua l'esecuzione. Un percorso batch separato aggira un altro controllo perché il callback previsto non viene mai eseguito.

La lezione è strutturale. Un controllo di sicurezza non può proteggere un percorso di esecuzione che non vede mai.

Per questo il recente lavoro di Microsoft distingue tra osservazione e applicazione. Registrare l'attività di un agente aiuta gli investigatori, ma non impedisce necessariamente un'azione non sicura.

Microsoft ha introdotto Agent Hooks come contratto aperto e indipendente dal framework per inserire controlli nell'esecuzione degli agenti. La specifica definisce come framework e componenti di governance dovrebbero interagire.

La versione iniziale include kit di sviluppo software per Python, TypeScript, .NET, Rust e Go. Include inoltre una suite di conformità con 47 scenari.

I test di conformità verificano se un framework rispetta il contratto in condizioni definite. L'obiettivo dichiarato da Microsoft è rendere il supporto verificabile anziché lasciarlo come semplice dichiarazione di compatibilità.

Il contratto punta a diverse modalità di fallimento. I controlli dovrebbero vedere ogni percorso di esecuzione pertinente, registrare prove e bloccare le azioni quando una policy le nega.

Quest'ultimo requisito sembra ovvio, ma i framework per agenti si sono spesso evoluti a partire da strumenti di orchestrazione e osservabilità. La loro gestione degli errori può privilegiare il completamento dell'attività rispetto a un'applicazione rigorosa.

Gli agenti creano anche rischi di delega. Un agente principale può chiedere a un sottoagente di completare parte di un'attività, introducendo un'altra identità e un altro percorso di esecuzione.

I tentativi ripetuti aggiungono ulteriore complessità. Un'azione bloccata potrebbe tornare attraverso un percorso di recupero che applica middleware o logiche di approvazione differenti.

I job in background e i processi batch possono comportarsi diversamente dalle sessioni interattive. Un controllo collegato solo a un flusso di lavoro rivolto all'utente può non rilevare affatto questi percorsi.

La memoria crea un'altra superficie di attacco. Il contesto archiviato può conservare istruzioni false o dati sensibili oltre la sessione in cui sono comparsi per la prima volta.

Questi rischi spiegano perché Microsoft descrive la governance come dinamica. Un test del modello una tantum non può catturare ogni autorizzazione, strumento, utente e fonte di dati incontrati dopo il deployment.

La posizione dell'azienda riflette anche la portata dei suoi prodotti. Microsoft fornisce modelli, infrastruttura cloud, applicazioni per il lavoro, sistemi di identità, strumenti per sviluppatori e prodotti di sicurezza.

Questa presenza offre a Microsoft punti in cui applicare le policy lungo tutto lo stack. Conferisce però anche all'azienda la responsabilità per più connessioni in cui i controlli possono fallire.

Per gli acquirenti aziendali, la domanda pratica non è più se un agente produca una dimostrazione accettabile. È se il sistema implementato si comporti in modo prevedibile lungo ogni percorso che conduce all'azione.

Il compromesso fondamentale riguarda capacità e controllo applicabile

Microsoft vuole che gli agenti completino attività più ampie, ma ogni autorizzazione aggiuntiva rende più difficile un'applicazione affidabile dei controlli.

I prodotti basati su agenti diventano più utili quando possono accedere al contesto pertinente e compiere azioni significative. Autorizzazioni ristrette riducono il rischio, ma possono anche limitare il lavoro che un agente riesce a completare.

Le autorizzazioni ampie creano il problema opposto. L'agente può completare più attività, ma errori e attacchi possono avere un impatto potenziale maggiore.

Questa tensione emerge nell'esempio Copilot Cowork di Microsoft. L'azienda afferma che il sistema completa attività lavorative in Microsoft 365 attraverso approvazioni degli utenti, accesso basato sulle autorizzazioni, controlli di sicurezza e distribuzione graduale.

Un rilascio graduale limita l'esposizione mentre i team raccolgono evidenze sul comportamento. L'approvazione dell'utente colloca una persona tra il piano dell'agente e le azioni selezionate.

Nessuno dei due meccanismi elimina il rischio. Gli utenti possono approvare azioni senza comprenderne le conseguenze, mentre un rilascio graduale potrebbe non rivelare fallimenti che richiedono condizioni insolite.

L'accesso con privilegio minimo offre un altro controllo. Fornisce a un agente solo le autorizzazioni necessarie per l'attività assegnata.

Questo principio diventa difficile quando le attività sono aperte. A un agente incaricato di preparare un aggiornamento di progetto potrebbero servire posta, calendario, documenti, chat e record dei clienti.

Potrebbe inoltre necessitare dell'autorizzazione per scrivere nei sistemi condivisi. Ogni nuova connessione aumenta sia l'utilità sia il numero di possibili percorsi di fallimento.

Il più ampio framework Microsoft per i modelli frontier affronta i rischi di capacità più gravi. Il suo governance framework monitora problematiche chimiche, biologiche, radiologiche, nucleari, informatiche, di autonomia, controllo e manipolazione.

Il framework valuta indicatori anticipatori quali ragionamento generale, ragionamento su contesti lunghi, pianificazione, uso degli strumenti, ragionamento scientifico e ingegneria del software.

I modelli che mostrano indicatori pertinenti ricevono valutazioni più approfondite. Microsoft classifica i rischi risultanti come bassi, medi, alti o critici.

L'azienda afferma che i rischi alti o critici richiedono ulteriori revisioni e mitigazioni prima del deployment. Si impegna inoltre a sospendere sviluppo e deployment quando i rischi identificati non possono essere ridotti a sufficienza.

Questo impegno è significativo, ma dipende dalle valutazioni interne e dalle decisioni di governance di Microsoft. Gli osservatori esterni non possono confermare in modo indipendente ogni risultato dei modelli o giudizio di deployment.

Il framework frontier si concentra inoltre sulle minacce alla sicurezza nazionale e alla sicurezza pubblica. Gli agenti aziendali creano molti rischi di portata minore che restano comunque importanti per i clienti.

Un agente non necessita di autonomia da livello frontier per esporre un file riservato, inviare un messaggio non autorizzato o eseguire una transazione errata.

Questi fallimenti dipendono in larga misura dal contesto di deployment. Lo stesso modello può presentare un rischio basso in uno strumento di redazione e un rischio molto maggiore quando è collegato a software finanziario.

Microsoft affronta questa distinzione attraverso una governance a livelli. Le valutazioni frontier coprono capacità eccezionali, mentre il suo standard più ampio copre prodotti, deployment e operatività continua.

Il suo Agent Governance Toolkit open source adotta un altro approccio. Fornisce componenti per l’applicazione delle policy, l’identità degli agenti, i controlli di esecuzione, l’affidabilità, le evidenze di conformità e la sicurezza dei plugin.

Il governance toolkit comprende sette pacchetti per Python, TypeScript, Rust, Go e .NET. Microsoft afferma che il repository include oltre 9.500 test.

Un componente colloca una decisione di policy prima dell’azione di un agente. Un altro assegna identità crittografiche agli agenti e supporta le decisioni di fiducia tra di essi.

Il toolkit include inoltre anelli di esecuzione, gestione delle transazioni, circuit breaker e un meccanismo di terminazione d’emergenza. Queste funzionalità riprendono concetti consolidati dei sistemi operativi e del site reliability engineering.

Questa direzione ingegneristica è importante. La sicurezza degli agenti non può dipendere interamente dal chiedere a un modello di rispettare una regola in linguaggio naturale.

Un prompt può esprimere un’intenzione, ma un motore di policy esterno può prendere una decisione deterministica. Può negare una chiamata a uno strumento vietata anche quando il modello la richiede.

Il compromesso resta irrisolto. Agenti più capaci richiedono più percorsi verso sistemi reali, mentre più percorsi creano ulteriori oneri di applicazione dei controlli.

La strategia di Microsoft consiste nel rendere tali percorsi visibili, testabili e governabili. Il valore di questa strategia dipenderà dalla coerenza con cui i prodotti la adotteranno.

Il Framework di Microsoft deve ancora colmare un divario nell’applicazione

Gli standard pubblicati descrivono il sistema previsto, ma la sicurezza dipende dalla capacità dei controlli di resistere alla pressione sui prodotti, agli errori di integrazione e ad attacchi sconosciuti.

Il rapporto sulla trasparenza di Microsoft fornisce ampi dettagli sui processi di governance. Non offre prove pubbliche complete per ogni prodotto, modello, controllo o incidente.

Questa distinzione conta perché la governance interna è in parte un’autovalutazione. Microsoft sviluppa la tecnologia, valuta molti rischi, seleziona le mitigazioni e decide quando il rilascio può procedere.

I test esterni possono ridurre tale conflitto. L’azienda afferma di aver ampliato le partnership per le valutazioni e di aver utilizzato un framework di test esterno per Copilot Health.

Ha consultato oltre 250 clinici abilitati provenienti da più di due dozzine di Paesi prima di rilasciare quell’esperienza sanitaria. Il lavoro ha riguardato chiarezza, utilità e sicurezza.

Questo caso dimostra un processo di valutazione specifico per il rilascio. Non dimostra che un esame indipendente equivalente si estenda a ogni prodotto agente.

La trasparenza diventa inoltre più difficile man mano che i sistemi crescono in complessità. Una singola applicazione può combinare modelli Microsoft, modelli di terze parti, plugin, dati proprietari e policy definite dai clienti.

La responsabilità può frammentarsi lungo questa catena di fornitura. Un fornitore di modelli potrebbe documentare i limiti, mentre uno sviluppatore di framework controlla l’esecuzione degli strumenti e un cliente assegna le autorizzazioni.

Quando si verifica un incidente, ogni partecipante può indicare un altro livello. Una governance efficace della sicurezza dell’AI di Microsoft richiede quindi una chiara attribuzione della responsabilità nell’intero deployment.

Il framework di rischio del NIST supporta questa visione del ciclo di vita. Considera la governance una funzione trasversale e richiede monitoraggio continuo, revisione, documentazione e responsabilità definite.

Il NIST osserva inoltre che una revisione indipendente può migliorare i test e ridurre i pregiudizi interni. Questo principio costituisce un utile parametro di riferimento per le future divulgazioni di Microsoft.

Gli acquirenti dovrebbero cercare prove che i controlli operino in condizioni di guasto. Un motore di policy deve negare un’azione quando una dipendenza si blocca, va in timeout o restituisce dati malformati.

Questo è noto come fail closed. Il sistema blocca le attività incerte invece di proseguire perché un controllo non è più disponibile.

Agent Hooks affronta direttamente questo requisito, ma una specifica non può garantire un’implementazione corretta. I manutentori dei framework devono integrarla e i team applicativi devono configurarla adeguatamente.

I test di conformità aiutano a evidenziare le incompatibilità. Non possono anticipare ogni percorso specifico dell’applicazione, plugin personalizzato o errore di policy.

Le prestazioni introducono un’ulteriore pressione. Gli sviluppatori potrebbero aggirare controlli che aggiungono una latenza percepibile, generano falsi positivi o interrompono flussi di lavoro comuni.

I team di prodotto affrontano anche incentivi all’adozione. Un agente che chiede costantemente approvazione può apparire meno utile di uno che agisce rapidamente.

La sfida progettuale risultante non consiste nella massima restrizione. Consiste nell’applicare controlli più forti alle azioni con maggiore impatto senza rendere inutilizzabile il lavoro ordinario.

La regolamentazione aggiunge un livello di pressione separato. Gli obblighi dell’Unione europea per i modelli di AI per finalità generali richiedono già documentazione tecnica e informazioni per i fornitori a valle.

Gli obblighi per i modelli della Commissione europea riguardano anche le policy sul copyright e i riepiloghi pubblici dei contenuti di addestramento. Requisiti aggiuntivi si applicano ai modelli con rischio sistemico.

Queste regole si concentrano in larga misura sui fornitori di modelli. I deployment degli agenti distribuiscono il rischio tra modelli, applicazioni, strumenti e organizzazioni.

Lo standard ampliato di Microsoft tenta di colmare questo divario. Il suo nuovo Deployer Chapter stabilisce requisiti per l’uso di applicazioni AI di terze parti all’interno di Microsoft.

L’azienda descrive tre fasi operative: valutare il fornitore, gestire i rischi di deployment e rilevare e rispondere continuamente dopo il rilascio.

Questo approccio riconosce un fatto scomodo. Anche un modello ben testato può diventare insicuro all’interno di un’applicazione progettata male.

L’incertezza più importante non riguarda il fatto che Microsoft abbia scritto regole dettagliate. Riguarda la possibilità per i team di dimostrare che tali regole governano ogni percorso d’azione significativo.

I clienti dovrebbero chiedere evidenze sui controlli, copertura delle valutazioni, processi per gli incidenti e registri di audit. Le rassicurazioni generiche sull’AI responsabile non sono sufficienti.

Dovrebbero inoltre mantenere i propri inventari. Un’organizzazione non può governare agenti di cui i team di sicurezza e conformità non sanno nemmeno l’esistenza.

Per il lavoro ad alta intensità di conoscenza, mantenere una base di conoscenza AI ricercabile può migliorare la tracciabilità. Tuttavia, i controlli di archiviazione e recupero devono comunque corrispondere alla sensibilità delle informazioni sottostanti.

Il divario nell’applicazione dei controlli si ridurrà soltanto quando la governance diventerà misurabile. Microsoft ha fornito più meccanismi, ma le prove in produzione restano il test decisivo.

I rivali di Microsoft convergono sulla governance basata sul rischio

I principali fornitori di AI concordano sempre più sul fatto che la crescita delle capacità debba attivare salvaguardie più forti, anche se soglie e divulgazioni differiscono.

Microsoft non è la sola a utilizzare regole di sicurezza basate sulle capacità. Anthropic mantiene una Responsible Scaling Policy dal 2023 e l’ha rivista ripetutamente con l’evoluzione dei modelli.

La policy di Anthropic collega soglie di capacità definite a salvaguardie richieste. I suoi materiali attuali affrontano rischi biologici, rischi informatici e ricerca autonoma sull’AI.

L’azienda descrive la propria policy come proporzionata, iterativa e adatta all’adozione oltre Anthropic. La sua scaling policy include inoltre un processo per la segnalazione di non conformità e contro le ritorsioni.

Il Frontier Governance Framework di Microsoft segue una struttura correlata. Entrambe le organizzazioni identificano capacità ad alto rischio, valutano i modelli e collegano i risultati a protezioni più forti.

I framework non sono identici. Utilizzano definizioni, soglie, pratiche di reporting e processi organizzativi diversi.

Anche OpenAI e Google hanno pubblicato approcci alla sicurezza di frontiera. Nel loro insieme, queste policy mostrano un consenso crescente attorno alla valutazione per fasi e al deployment basato sul rischio.

La competizione ora riguarda l’implementazione tanto quanto il principio. I fornitori vogliono rilasciare prodotti più capaci dimostrando al contempo a governi e clienti che le salvaguardie terranno il passo.

Microsoft occupa una posizione distinta perché opera nel software consumer, nell’infrastruttura enterprise, nell’identità, nella sicurezza e nelle piattaforme per sviluppatori.

Questa integrazione offre un vantaggio di governance. Microsoft può collegare le valutazioni dei modelli ai controlli di accesso, alla sicurezza degli endpoint, alle policy applicative e ai sistemi di audit organizzativi.

Crea però anche preoccupazioni di lock-in. I clienti potrebbero diventare dipendenti da un singolo fornitore per l’agente, il livello di identità, il motore di policy, il monitoraggio e le evidenze di conformità.

La decisione di Microsoft di rilasciare Agent Hooks come specifica indipendente dal framework contrasta questa preoccupazione. Il suo governance toolkit supporta inoltre diversi framework di agenti esterni.

Le interfacce aperte possono rendere i controlli portabili. Possono anche offrire ai clienti un livello di policy coerente quando i team usano modelli e framework di fornitori diversi.

La portabilità è importante perché gli ambienti AI aziendali raramente restano uniformi. Un’azienda può utilizzare Microsoft 365, Azure, un modello Anthropic, un agente di coding OpenAI e software di orchestrazione open source.

Un contratto indipendente dal framework può ridurre il lavoro di integrazione duplicato. Può anche chiarire quale componente debba applicare ogni decisione.

Tuttavia, una specifica aperta diventa significativa soltanto quando i framework concorrenti la implementano fedelmente. L’adozione al di fuori dei prodotti Microsoft sarà quindi una misura critica.

Anche le autorità di regolamentazione influenzano questa convergenza. Le norme dell’Unione europea richiedono documentazione, gestione del rischio e condivisione delle informazioni lungo la catena di fornitura dell’AI.

Gli standard volontari del NIST forniscono un altro vocabolario comune. Microsoft mappa esplicitamente il proprio processo di governance alle funzioni govern, map, measure e manage del NIST.

Una terminologia condivisa può semplificare gli audit e gli acquisti. Non garantisce prestazioni di sicurezza equivalenti tra i fornitori.

Ogni organizzazione sceglie comunque cosa testare, come valutare i risultati, quali rischi residui accettare e quali informazioni divulgare pubblicamente.

La pressione competitiva può rafforzare la governance quando i clienti richiedono prove credibili. Può indebolirla quando la velocità di rilascio diventa la principale misura del successo.

Questa è la competizione centrale del settore. Il vincitore non offrirà semplicemente l’agente più capace.

I clienti enterprise favoriranno sistemi in grado di dimostrare un’autonomia utile entro limiti applicabili. Ciò richiede che identità, autorizzazioni, monitoraggio, approvazione, ripristino e responsabilità lavorino insieme.

Microsoft sta costruendo verso questo modello integrato. I rivali la spingeranno a dimostrare che l’integrazione produce più della sola coerenza delle policy.

Cosa osservare mentre Microsoft porta le sue regole in produzione

Il prossimo test sarà verificare se Microsoft trasformerà la propria architettura di governance in prove visibili e ripetibili nei prodotti e nei framework esterni.

Il primo segnale è la documentazione a livello di prodotto. Microsoft dovrebbe mostrare in che modo il Responsible AI Standard rivisto modifica i singoli rilasci di agenti, le autorizzazioni, le valutazioni e le risposte agli incidenti.

Note di deployment dettagliate rafforzerebbero l’affermazione dell’azienda secondo cui la governance segue l’intero ciclo di vita dell’AI. Divulgazioni scarne lascerebbero i clienti dipendenti da rassicurazioni di alto livello.

I documenti più utili identificherebbero categorie di valutazione, limitazioni note, confini di approvazione, pratiche di monitoraggio e rischi residui. Dovrebbero inoltre spiegare cosa accade quando un controllo fallisce.

Queste evidenze sono importanti per i prodotti Copilot, i servizi di agenti Azure, gli agenti di coding e i sistemi che coordinano più agenti. Ogni contesto crea conseguenze diverse.

Il secondo segnale è l’adozione di Agent Hooks oltre il framework di Microsoft. Il supporto da parte di importanti progetti di orchestrazione convaliderebbe la domanda di un contratto di applicazione comune.

La sola adozione non è sufficiente. I framework devono superare la suite di conformità e preservare l'applicazione delle policy lungo percorsi di esecuzione interattivi, batch, di retry e delegati.

Rapporti indipendenti su fallimenti di integrazione indebolirebbero l'affermazione di Microsoft secondo cui un contratto comune risolve il problema della frammentazione. Risultati di conformità riproducibili la rafforzerebbero.

Il terzo segnale è la trasparenza sugli incidenti. Microsoft afferma che monitoraggio, feedback degli utenti e azioni correttive restano attivi dopo il deployment.

I lettori dovrebbero osservare se l'azienda pubblica informazioni significative sui fallimenti degli agenti e sulle correzioni risultanti. Gli incidenti reali rivelano lacune che le valutazioni di laboratorio non individuano.

Una reportistica utile distinguerebbe gli errori del modello dai fallimenti delle autorizzazioni, dall'uso improprio degli strumenti, dalla prompt injection e da una logica di approvazione difettosa. Questa separazione aiuta i clienti a migliorare i propri sistemi.

Anche il framework frontier di Microsoft merita un esame continuo. Nuovi modelli con maggiore autonomia, capacità di pianificazione, capacità cyber o capacità di ingegneria del software dovrebbero attivare una valutazione più approfondita.

L'azienda ha promesso di sospendere sviluppo e deployment quando i rischi non possono essere ridotti in misura sufficiente. Qualsiasi futuro ricorso a questo impegno rappresenterebbe un test importante dell'indipendenza della governance.

I clienti non devono attendere questi segnali prima di agire. Possono censire gli agenti già distribuiti, ridurre le autorizzazioni, separare gli strumenti ad alto impatto e richiedere approvazioni per azioni irreversibili.

Possono inoltre testare le condizioni di fallimento. I team dovrebbero interrompere deliberatamente i servizi di policy, inviare richieste di strumenti non valide e verificare che le azioni negate restino negate.

I log dovrebbero collegare una decisione di policy all'azione effettivamente eseguita. I record che acquisiscono solo i messaggi del modello lasciano importanti lacune.

Le organizzazioni dovrebbero definire chi è responsabile di un agente dopo il lancio. I team di prodotto, sicurezza, legale, dati e operazioni necessitano di responsabilità chiare quando il comportamento cambia.

Dovrebbero inoltre stabilire procedure di arresto e ripristino. Un arresto di emergenza è utile solo quando le persone sanno quando e come utilizzarlo.

La governance della sicurezza dell'AI di Microsoft si sta muovendo nella giusta direzione tecnica, trattando gli agenti come sistemi operativi per l'azione anziché come interfacce di chat. Le sue idee più solide riguardano l'applicazione runtime, l'identità, le autorizzazioni e le evidenze.

La domanda restante è se queste idee resistano alle condizioni disordinate del software in produzione. Gli acquirenti dovrebbero richiedere prove lungo ogni percorso di esecuzione prima di concedere agli agenti un'autorità più ampia.