La governance come requisito d'ingresso nell'IA aziendale
Microsoft ha preso una decisione poco rumorosa a Build 2026 che merita più attenzione di quanta ne abbia ricevuta: invece di presentare un modello più potente o un agente più capace, ha reso disponibile in modo generale l'Agent 365 SDK e lo ha circondato di controlli di identità, policy e dati che si attivano durante la progettazione, non quando l'agente ha già rotto qualcosa in produzione. La scommessa implicita è che la capacità del modello ha smesso di essere il collo di bottiglia per le grandi organizzazioni. Ciò che frena i progetti di agenti non è la potenza del sistema, ma l'incapacità di dimostrare che qualcuno sa cosa sta facendo quell'agente, con quali dati, sotto quale autorizzazione e a nome di chi.
Questo non è un argomento tecnico. È un argomento di architettura del potere all'interno delle organizzazioni.
Perché la ragione per cui i progetti di agenti si bloccano in sede di revisione legale, nei comitati di rischio o sulla scrivania di un CISO non è che il modello sia scadente. È che nessuno riesce a rispondere a tre domande fondamentali: chi ha approvato l'esistenza di questo agente, cosa può toccare e come lo si dimostra di fronte a un audit. Microsoft ha identificato quel collo di bottiglia e ha deciso di costruire la propria piattaforma attorno ad esso.
Cosa Microsoft ha capito che i suoi concorrenti continuano a risolvere con la velocità
L'Agent 365 SDK arriva con un registro centralizzato che Microsoft descrive come la "fonte di verità" per l'inventario degli agenti aziendali. Questo registro si collega a Defender, Purview, Entra e Foundry, il che significa che i controlli di sicurezza, identità e conformità che una grande azienda ha già implementato non devono essere replicati per gli agenti: vengono semplicemente estesi. Ogni agente può avere un'identità unica separata da qualsiasi utente umano. Gli amministratori possono definire quali agenti vengono resi visibili, quali vengono messi in quarantena, chi li crea e in quali condizioni operano.
Il registro rileva anche gli agenti che sono già in esecuzione senza che nessuno li abbia approvati. Microsoft afferma che il sistema riconosce più di 20 tipi di agenti locali, inclusi i server Model Context Protocol, che sono esattamente il tipo di infrastruttura che i team di ingegneria distribuiscono rapidamente senza passare per il procurement. Chiamarlo "sprawl di agenti" è il modo elegante per dire che le organizzazioni hanno già agenti che operano al di fuori di qualsiasi framework di controllo, e che questo è un problema di governance prima ancora di essere un problema di sicurezza.
Rispetto a Google Cloud, che ha costruito la sua piattaforma di agenti attorno a identità crittografiche univoche per agente, e ad AWS, che ha scommesso su un percorso più rapido e leggero con Bedrock AgentCore, Microsoft ha scelto il terreno dove già vince: l'infrastruttura di controllo che i suoi clienti enterprise più grandi hanno già installato e di cui già si fidano. Questo non è un vantaggio tecnico. È un vantaggio di capitale sociale accumulato con i team di sicurezza aziendali nel corso di due decenni.
Il pattern che emerge non è casuale. I tre grandi fornitori di cloud stanno convergendo verso la stessa architettura concettuale: un piano di controllo per gli agenti che replica ciò che Kubernetes è stato per i container. La differenza è che Microsoft arriva con Entra, Intune, Defender e Purview già presenti nella maggior parte delle grandi imprese. La governance degli agenti non arriva come una nuova piattaforma da giustificare nel budget. Arriva come un'estensione di ciò che il team di sicurezza già gestisce oggi.
Chi era in sala quando è stato progettato tutto questo e cosa questo rivela
È qui che la storia diventa più interessante da una prospettiva di design strutturale. L'Agent 365 SDK è stato costruito per risolvere il problema del compratore aziendale, non dello sviluppatore che vuole muoversi velocemente. Le funzionalità che Microsoft ha prioritizzato — il registro, il controllo degli accessi, la prevenzione della perdita di dati in tempo di esecuzione, i controlli di Windows a livello di sistema operativo — sono progettate per convincere un CISO, un team legale o un responsabile della conformità che l'agente è distribuibile. Questa è una scelta di design che rivela chi detiene il potere di veto nel ciclo di adozione.
Non è un dettaglio marginale. Quando una piattaforma viene progettata per ridurre l'attrito dell'auditor prima dell'attrito dello sviluppatore, si sta riconoscendo esplicitamente che il potere di blocco nelle grandi organizzazioni non risiede nel team tecnico. Risiede nelle funzioni di controllo. Microsoft ha scommesso che guadagnerà più mercato convincendo il team di rischio piuttosto che convincendo il team di ingegneria, e questa scommessa ha implicazioni per come le altre aziende dovrebbero pensare all'adozione dei propri strumenti di agenti.
La domanda strutturale che questo pone è chi è rimasto fuori da quella sala di progettazione. L'SDK dichiara la compatibilità con qualsiasi piattaforma di agenti, non solo quella di Microsoft, il che è un segnale di apertura tattica. Ma l'architettura di controllo più robusta opera all'interno del perimetro di Windows, Entra e Microsoft Foundry. Un'azienda che gestisce agenti su AWS, su Google Cloud e su un insieme di strumenti SaaS legacy acquisisce visibilità all'interno del confine Microsoft e al contempo eredita una dipendenza più profonda da quel confine. La governance multi-cloud rimane, nei fatti, un problema irrisolto da parte di tutti e tre i grandi fornitori. I vendor indipendenti come Saviynt o TrueFoundry esistono proprio perché quella domanda è reale e non è soddisfatta dalle piattaforme degli hyperscaler.
C'è qualcos'altro che vale la pena nominare con precisione: Microsoft ha lanciato l'Agent Governance Toolkit come progetto open source con licenza MIT nell'aprile 2026, prima di Build. L'azienda lo posiziona come il primo toolkit che risponde ai dieci rischi dell'IA agentica identificati da OWASP con l'applicazione di policy deterministiche in meno di un millisecondo. Questa è una mossa per definire lo standard prima che chiunque altro lo faccia. Quando un attore dominante pubblica il framework di sicurezza di riferimento come open source, non sta essendo generoso. Sta mettendo la propria architettura concettuale al centro della conversazione del settore.
Il costo della governance che nessuna presentazione di vendita menziona
Microsoft non risolve tutti i problemi che crea. Ci sono tre attriti che qualsiasi organizzazione che adotti questa architettura dovrebbe nominare prima di impegnarsi.
Il primo è che una parte importante di ciò che è stato annunciato a Build 2026 è ancora in anteprima, non in disponibilità generale. L'integrazione tra Defender e GitHub Code Security è disponibile. Windows 365 per gli Agenti è disponibile. Ma il sistema MDASH di scansione agentica con più di 100 agenti specializzati, i controlli in tempo di esecuzione di Purview e diverse funzionalità di Defender sono ancora in preview o con date da confermare. Un piano di governance costruito su funzionalità in anteprima è un piano con uno spazio vuoto al suo interno.
Il secondo attrito è operativo. Ogni livello di controllo che protegge l'organizzazione rallenta anche lo sviluppatore. I team che sovra-calibrano i controlli vedranno i propri ingegneri cercare percorsi alternativi, distribuendo agenti al di fuori del registro perché il processo di approvazione richiede tre settimane. La governance che crea un attrito eccessivo produce esattamente lo sprawl di agenti non gestiti che il registro era stato progettato per rilevare. Questo è un problema di design organizzativo, non di tecnologia.
Il terzo attrito è strategico. Le organizzazioni che adottano Agent 365 come proprio livello di controllo acquisiscono visibilità reale all'interno del perimetro Microsoft. Ciò che ereditano, simultaneamente, è una dipendenza più profonda da quel perimetro. Questo non è un argomento contro la piattaforma. È una variabile che dovrebbe apparire in qualsiasi decisione di architettura onesta. La portabilità della governance, attraverso standard come Model Context Protocol che i tre grandi fornitori dichiarano di supportare, potrebbe non essere così disponibile nella pratica come nei comunicati stampa.
L'identità non umana come nuova frontiera del controllo aziendale
Ciò che Microsoft sta costruendo, quando lo si descrive senza la terminologia di prodotto, è un sistema di identità e autorizzazione per entità che non sono umane ma che possono agire come se lo fossero: leggere dati sensibili, invocare strumenti, avviare processi, prendere decisioni a nome dell'organizzazione. Questo problema non esisteva su questa scala due anni fa.
L'implicazione in termini di budget è diretta. La spesa che andava all'accesso ai modelli e alla sperimentazione ora necessita di una voce per il livello di identità e governance che trasforma gli esperimenti in deployment approvati. Questa spesa non è discrezionale una volta che gli agenti possono leggere dati e attivare azioni autonomamente. L'identità non umana diventa un problema di prima classe, con la stessa urgenza con cui le organizzazioni gestiscono l'identità umana da quando il perimetro aziendale ha smesso di essere una parete fisica.
La mossa di Microsoft non risolve la domanda su quanto funzioni bene la governance quando l'organizzazione opera su più cloud con decine di strumenti SaaS e agenti costruiti su piattaforme di terze parti. Ma rivela la meccanica del potere che determinerà quali organizzazioni riusciranno a scalare gli agenti e quali continueranno a restare intrappolate nel ciclo di progetti pilota che muoiono in sede di revisione legale. La capacità di dimostrare cosa ha fatto ogni agente, con quali dati e sotto quale autorizzazione, prima che lo richieda un regolatore o un consiglio di amministrazione, è il criterio che separerà chi distribuisce da chi sperimenta indefinitamente.
L'architettura che Microsoft ha presentato a Build 2026 non è l'unico modo per risolvere questo problema. Ma è la prima che arriva confezionata con l'infrastruttura di controllo che le organizzazioni più grandi hanno già installato. Questo vantaggio di distribuzione non è tecnico. È strutturale, ed è molto più difficile da replicare di un benchmark di sicurezza.
