TL;DR: Dal 1° agosto 2026 Microsoft sostituisce la modalità “Agent” di Azure Copilot con singoli agenti (Deployment, Troubleshooting, Optimization, Resiliency, Migration, Observability), attivi di default per ogni tenant con Copilot abilitato, incluse le versioni Public Preview. Chi vuole evitarlo deve disabilitare Azure Copilot prima del 1° agosto o gestire i singoli agenti nell’Admin Center subito dopo.
Ieri mattina ho aperto la casella di posta e ho trovato l’ennesima mail da Microsoft con oggetto “Action recommended”. Di solito le scorro veloce, ma questa parlava di agenti che si accendono da soli su tutti i tenant Azure che ho in gestione, me compreso. Ho smesso di bere il caffè e ho iniziato a leggere riga per riga, perché la frase “enabled by default” accanto a “Public Preview” mi ha fatto venire i brividi: significa agenti non ancora maturi, attivi ovunque, senza che nessuno lo chieda esplicitamente.
Cos’è il cambiamento annunciato da Microsoft e perché conta davvero?
Dal 1° agosto 2026 Azure Copilot elimina la vecchia “modalità Agent” unica e la sostituisce con sei agenti distinti, ciascuno con un proprio stato di rilascio (General Availability o Public Preview) e un proprio switch di attivazione. Non è un semplice restyling dell’interfaccia: cambia il modello di governance, perché non si gestisce più un blocco unico ma singoli agenti con permessi e rischi diversi.
L’Observability Agent (integrato in Azure Monitor per l’analisi degli alert) passa in General Availability, mentre Deployment, Troubleshooting, Optimization, Resiliency Agent e Migration Agent restano in Public Preview, dettaglio che Microsoft Learn conferma descrivendo capacità già operative ma “solo per i tenant con accesso agli Agents (preview)” (Microsoft, 2026a). In pratica, funzionalità sperimentali diventano lo standard silenzioso per milioni di tenant.
Cosa succede se il mio tenant ha già Azure Copilot abilitato?
Se Azure Copilot è già attivo nel tuo tenant, dal 1° agosto tutti gli agenti si accenderanno automaticamente, incluse le versioni Public Preview, senza bisogno di richiesta o approvazione. Il controllo primario resta l’impostazione di tenant: se Copilot è disabilitato, gli agenti restano disabilitati.
Oggi l’accesso alla preview richiede una richiesta approvata a livello di tenant tramite l’Azure Copilot Admin Center (Microsoft, 2026b). Dal 1° agosto questo passaggio sparisce: niente più allowlist, niente più sign-up. Chi ha già detto “sì” a Copilot in passato, magari per abilitare la chat base, si ritroverà con sei agenti operativi senza aver mai firmato nulla di specifico per loro. È il classico caso in cui un consenso generico diventa un consenso implicito per funzionalità molto più invasive.
Quali agenti diventano GA e quali restano in Public Preview dal 1° agosto?
Solo l’Observability Agent raggiunge la General Availability; Deployment, Troubleshooting, Optimization, Resiliency e Migration Agent restano in Public Preview. La distinzione conta perché le funzionalità in preview sono per definizione meno testate e più soggette a modifiche improvvise.
| Agente | Stato dal 1° agosto 2026 | Dove si usa |
|---|---|---|
| Observability Agent | General Availability | Azure Monitor (analisi alert Application Insights) |
| Deployment Agent | Public Preview | Chat Azure Copilot (Terraform, IaC) |
| Troubleshooting Agent | Public Preview | Chat Azure Copilot |
| Optimization Agent | Public Preview | Chat Azure Copilot / Advisor |
| Resiliency Agent | Public Preview | Chat Azure Copilot (backup, disaster recovery) |
| Migration Agent | Public Preview | Azure Migrate |
Cinque agenti su sei restano quindi sperimentali, ma verranno comunque distribuiti di default. Come nota la stessa documentazione Microsoft, “as new agent capabilities become available, they automatically become available to your users” (Microsoft, 2026c): un’espansione automatica delle superfici di rischio, agente dopo agente, senza un nuovo momento di consenso.
Come disabilito il rollout automatico prima o dopo il 1° agosto 2026?
Prima del 1° agosto l’unica leva è disabilitare Azure Copilot a livello di tenant, seguendo la guida ufficiale “Manage access to Azure Copilot”. Dopo tale data, la gestione si sposta sull’Azure Copilot Admin Center, dove ogni agente può essere attivato o disattivato singolarmente.
In pratica:
- Prima del 1° agosto 2026: un Global Administrator disattiva Azure Copilot per l’intero tenant (Microsoft, 2026b).
- Dal 1° agosto 2026: si entra nell’Azure Copilot Admin Center, sezione Access management, e si spengono i singoli agenti non desiderati, uno per uno.
- In entrambi i casi, se Copilot resta disabilitato a livello di tenant, nessun agente si attiverà comunque, indipendentemente dal loro stato individuale.
Chi ha già valutato e disattivato la preview in passato non è automaticamente al sicuro: la disattivazione va confermata di nuovo, perché il modello di controllo cambia radicalmente struttura, non solo etichetta.
Quali rischi di governance comporta l’attivazione di default di tutti gli agenti (anche i “nostri”)?
Attivare di default agenti con permessi su deployment, backup, ottimizzazione costi e migrazione significa moltiplicare i punti in cui un’azione automatica può toccare risorse di produzione. Il rischio principale non è tecnico ma di governance: pochi tenant hanno oggi un processo di revisione periodica per ogni singolo agente AI attivo.
Lo vedo ogni settimana lavorando con clienti PMI: la maggior parte non sa nemmeno che l’Agent mode di Azure Copilot esiste, figuriamoci se saprà spegnere selettivamente cinque agenti su sei dall’Admin Center. Come sottolinea Microsoft stessa nella documentazione su Entra Agent ID, “globally disabling agent identities can cause existing agents to fail, degrade Microsoft product experiences” (Microsoft, 2026d): il problema non è solo attivarli per errore, ma anche disattivarli senza sapere cosa si spegne davvero. Per chi, come Argos New Dreams, costruisce agenti custom su Copilot Studio, il rischio concreto è la confusione di responsabilità: un agente Microsoft nativo che agisce sulle stesse risorse toccate da un agente aziendale può generare conflitti operativi difficili da diagnosticare, perché appartengono a due filiere di governance distinte.
Che impatto pratico ha questo cambiamento per chi lavora ogni giorno con agenti AI in produzione?
Per chi gestisce agenti AI in produzione, l’impatto pratico è un aumento della superficie da monitorare senza un aumento proporzionale di visibilità: sei agenti indipendenti, ciascuno con log e permessi propri, ma nessun cruscotto unico “prima del 1° agosto” per capire quali azioni stanno realmente eseguendo.
Nella mia esperienza con Bussola, l’agente che ho costruito in Copilot Studio, il primo problema non è mai la tecnologia ma la domanda “chi ha acceso questo?”. Con il nuovo modello, ogni cliente enterprise dovrà rispondere sei volte a quella domanda invece di una, e dovrà farlo per ognuno dei tenant Azure che gestisce. È un lavoro di audit che va pianificato ora, non il 2 agosto.
Implicazioni pratiche per le PMI italiane
Per le PMI italiane che usano Azure senza un team IT dedicato alla governance AI, questo cambiamento rischia di passare inosservato fino a quando qualcosa non va storto: un backup avviato da un agente, uno script di ottimizzazione applicato senza revisione, una raccomandazione di migrazione presa per buona senza controllo umano. Non è hype fantascientifico, è un problema di processo molto concreto.
La buona notizia è che l’opportunità è reale: gli agenti di Deployment e Optimization possono davvero ridurre tempo speso su attività ripetitive di infrastruttura, e l’Observability Agent in GA è già abbastanza maturo da essere utile su ambienti di produzione con Application Insights. Il punto non è “spegnere tutto per paura”, ma pianificare entro il 1° agosto una checklist minima: verificare chi in azienda ha ruolo di Global Administrator, capire se Copilot è già abilitato, e decidere consapevolmente quali agenti servono davvero e quali vanno disattivati dall’Admin Center. Rimandare la decisione significa lasciarla a un default scelto da Microsoft, non dalla propria organizzazione.
Cosa devo fare concretamente prima del 1° agosto 2026?
Se non vuoi che tutti gli agenti Azure Copilot si attivino automaticamente, disabilita Azure Copilot a livello di tenant prima del 1° agosto 2026 seguendo la guida “Manage access to Azure Copilot” di Microsoft Learn. Se invece vuoi tenerli attivi, non serve fare nulla: il rollout è automatico per i tenant già abilitati.
Gli agenti in Public Preview sono sicuri da usare in produzione?
Non sono garantiti stabili come le funzionalità in General Availability: Public Preview significa che possono cambiare comportamento, subire interruzioni o venire modificati senza preavviso lungo. Vanno testati in ambienti non critici prima di affidargli azioni su risorse di produzione.
Chi può disattivare i singoli agenti nell’Azure Copilot Admin Center?
Solo un Global Administrator del tenant può gestire l’accesso agli agenti tramite l’Azure Copilot Admin Center, sezione Access management. Lo stesso ruolo può anche disabilitare Azure Copilot nel suo complesso in qualsiasi momento.
Questo cambiamento riguarda anche Microsoft 365 Copilot?
No, la notifica riguarda specificamente Azure Copilot e i suoi agenti infrastrutturali (deployment, migrazione, osservabilità). Sono in corso, in parallelo, ristrutturazioni distinte su Microsoft 365 Copilot riportate da testate di settore, ma si tratta di un prodotto e di un percorso di rilascio diversi, da verificare separatamente.
Conclusioni
Non è breaking news da prima pagina generalista, ma per chi amministra tenant Azure è una di quelle comunicazioni che, se ignorate, si pagano più avanti. Il pattern è sempre lo stesso: Microsoft spinge sull’adozione automatica dell’AI agentica, e scarica sull’amministratore l’onere di capire, prima che sia troppo tardi, cosa sta accendendo di default. La mia posizione è chiara: usate questi agenti, sono utili, ma decidetelo voi entro il 1° agosto, non lasciate che la scelta la faccia un timer.
Riferimenti (APA)
- Microsoft. (2026a). Agents (preview) in Azure Copilot. Microsoft Learn. — Livello B — consultato il 23/07/2026.
- Microsoft. (2026b). Manage access to Agents (preview) in Azure Copilot. Microsoft Learn. — Livello B — consultato il 23/07/2026.
- Microsoft. (2026c). Manage access to Azure Copilot. Microsoft Learn. — Livello B — consultato il 23/07/2026.
- Microsoft. (2026d). Manage agent identities in your organization. Microsoft Learn, Microsoft Entra. — Livello B — consultato il 23/07/2026.
- Microsoft. (2026e). Notifica ufficiale tenant admin “Action recommended: Review Azure Copilot agent access settings before 1 August 2026”. — Livello B (comunicazione diretta Microsoft) — ricevuta luglio 2026.
- Fonti verificate al 23/07/2026.
Link interni
- Governance e sicurezza degli agenti AI: la risposta alla domanda che ogni CIO fa prima o poi
- Microsoft accelera su Copilot: agenti, governance e AI enterprise al centro della nuova strategia
- Microsoft 365 Agent Store: come pubblicare agenti AI interni con governance enterprise
- Skills, agenti e il conto: chi governa e chi paga
Lascia un commento