TL;DR — Un agente creato “al volo” in Copilot Studio e un agente aziendale governato sono due cose diverse: il secondo ha un’identità propria (Microsoft Entra Agent ID), uno sponsor umano responsabile, permessi minimi verificati e un ciclo di vita tracciato dalla creazione alla dismissione. Senza questo passaggio, un agente utile diventa “shadow AI”: Gartner stima che entro il 2027 il 40% dei progetti di agenti autonomi verrà ritirato proprio per problemi di governance.
Bussola è nata in una notte, per un bisogno mio e di un amico: nessuna approvazione, nessuno sponsor, nessuna policy. Andava benissimo così, per uno strumento personale usato da due persone che sanno esattamente cosa contiene. Ma mi sono chiesto: se domani un’azienda volesse fare la stessa cosa per il proprio HR o il proprio supporto clienti, cosa dovrebbe cambiare prima di lasciarlo lavorare su dati veri e processi reali? La risposta, ho scoperto, è: quasi tutto tranne l’idea di partenza.
Cosa cambia tecnicamente con Microsoft Entra Agent ID rispetto a un agente creato al volo
Microsoft Entra Agent ID trasforma un agente da “bot creato in Copilot Studio” a identità governabile di prima classe in Entra ID, con sponsor umano, permessi, log e ciclo di vita tracciati esattamente come per un utente o un’app. L’aggiornamento, pubblicato da Microsoft il 20 aprile 2026, introduce un principio semplice ma finora assente: ogni agente deve avere uno scopo, un proprietario funzionale e limiti chiari prima di entrare nei workflow aziendali1,3.
Per un maker che finora ha lavorato in Copilot Studio senza pensarci, questo significa un cambio di disciplina concreto: la progettazione parte dallo scopo dichiarato, non dal prompt; le fonti di conoscenza vanno scelte con più rigore; le azioni disponibili all’agente devono essere limitate al minimo utile al task, non “tutto quello che potrebbe servire”.
Chi deve possedere e sponsorizzare un agente aziendale, e perché serve uno sponsor umano
Ogni agente aziendale ha bisogno di un proprietario funzionale identificabile — non il maker che lo ha creato, ma una persona o un ruolo che risponde del suo comportamento nel tempo. Questo è il punto in cui molti progetti “dal basso” si bloccano: chi ha creato l’agente per risolvere un problema locale spesso non è, e non dovrebbe essere, l’unico responsabile quando l’agente inizia a toccare dati di altri colleghi o processi aziendali3.
| Agente personale (es. Bussola) | Agente aziendale governato | |
|---|---|---|
| Identità | Nessuna, o legata all’account del creatore | Microsoft Entra Agent ID dedicato |
| Proprietario | Il maker stesso | Sponsor/owner funzionale definito |
| Permessi | Impliciti, spesso ampi “per sicurezza” | Minimi, verificati e documentati |
| Ciclo di vita | Nessuna scadenza pianificata | Creazione, monitoraggio, dismissione tracciati |
| Rischio principale | Basso impatto, uso individuale | Shadow AI se non governato |
Quali controlli di accesso vanno applicati: privilegio minimo e Conditional Access
Gli admin devono spostarsi da un modello di “eccezioni caso per caso” a policy riutilizzabili applicate a intere categorie di agenti, non a ogni singolo caso. Concretamente questo vuol dire tre cose: accessi minimi per ogni agente rispetto al task che deve svolgere, regole di Conditional Access applicate anche alle identità degli agenti (non solo agli utenti umani), e una valutazione esplicita del rischio prima della messa in produzione, non dopo il primo incidente3.
Un errore frequente, secondo l’analisi di IT trip, è “dare accesso a troppe fonti ‘per sicurezza’”: la logica opposta a quella corretta, che dovrebbe partire dal minimo indispensabile e allargarsi solo se necessario e documentato. Altrettanto frequente è l’errore opposto e speculare — bloccare tutto dopo il primo incidente, che paralizza l’adozione invece di correggerla3.
Come si gestisce il ciclo di vita di un agente aziendale, dalla creazione alla dismissione
Il ciclo di vita di un agente aziendale governato prevede quattro fasi tracciate: creazione con scopo dichiarato, autorizzazioni assegnate e verificabili, monitoraggio continuo dell’uso e dell’accesso ai dati, e infine disattivazione pianificata quando il progetto termina o l’agente non serve più. Agent 365 funge da piano di controllo per questo intero ciclo: dà visibilità su quali agenti esistono, cosa fanno, con quali permessi e con quale costo, applicando agli agenti la stessa disciplina che oggi si applica a utenti e dispositivi4.
Senza questo tracciamento, gli agenti diventano “account fantasma”: permessi non tracciati, nessuno sa più chi li ha creati, restano attivi anche dopo che il progetto per cui erano nati è finito. Sono esattamente i rischi che framework come NIS2 e le buone pratiche di sicurezza cercano di prevenire, applicati a una nuova categoria di “utenti” non umani4.
Cosa rischia chi salta questo passaggio di governance
Il rischio concreto è duplice: da un lato la “shadow AI”, cioè agenti creati senza controllo che accumulano permessi e accesso a dati senza che nessuno ne abbia piena visibilità; dall’altro il fallimento del progetto stesso. Gartner stima che entro il 2027 il 40% dei progetti di agenti autonomi verrà ritirato proprio per problemi di governance — non per limiti tecnologici del modello, ma per l’assenza della disciplina organizzativa che dovrebbe accompagnarlo5.
“I veri problemi che le aziende stanno risolvendo non riguardano la generazione di testi carini” — Marco Casalaina, VP Products e AI Futurist, Microsoft, Build 20265
Il caso di Bayer, con 20.000 dipendenti già operativi su sistemi di agenti interni costruiti su Microsoft Foundry, mostra che la scala a cui questi temi diventano critici non è più teorica: è già operativa in aziende che hanno investito prima nella governance che nella singola funzionalità5.
Implicazioni pratiche per le PMI italiane
Non serve essere una multinazionale per avere questo problema: appena una PMI introduce più di un paio di agenti Copilot — anche solo a consumo con i crediti — nasce la necessità di sapere chi può crearli, cosa possono toccare e chi li spegne quando non servono più. È un tema di sicurezza e conformità che si lega direttamente alle richieste dell’AI Act, non un lusso da rimandare a quando l’azienda sarà più grande4.
Da dove partire concretamente, in ordine: primo, fare l’inventario di quali agenti o bot esistono già in azienda, incluso ciò che i team hanno creato “fai-da-te” senza passare dall’IT; secondo, assegnare identità e permessi minimi via Entra ID a ciascuno; terzo, stabilire una policy semplice su chi può creare nuovi agenti e su quali dati. Non serve partire con un framework complesso — serve partire, e partire con la disciplina giusta fin dal primo agente che esce dall’uso puramente personale.
FAQ
Cosa distingue un agente “personale” da uno aziendale in Copilot Studio?
La differenza non è tecnica ma organizzativa: un agente personale non ha uno sponsor formale né un ciclo di vita tracciato, mentre un agente aziendale ha un’identità Entra Agent ID, un proprietario funzionale responsabile e permessi documentati e verificabili nel tempo.
Serve Microsoft Entra Agent ID anche per una PMI piccola?
Sì, appena si superano uno o due agenti in uso reale: senza un’identità e un proprietario per ciascuno diventa impossibile sapere chi ha accesso a cosa, un rischio di sicurezza e conformità indipendente dalle dimensioni dell’azienda.
Cos’è Agent 365 e a cosa serve concretamente?
È il piano di controllo centrale per gli agenti aziendali: mostra quali agenti esistono, cosa fanno, con quali permessi e a quale costo, permettendo di applicare agli agenti la stessa disciplina già in uso per utenti e dispositivi aziendali.
Qual è l’errore più comune quando si passa da agente personale a governance aziendale?
Concedere accessi troppo ampi “per sicurezza” invece di applicare il privilegio minimo, oppure l’errore opposto: bloccare tutto dopo un primo incidente invece di correggere la policy in modo mirato.
Cosa succede se un’azienda non governa i suoi agenti AI?
Rischia la “shadow AI” — agenti attivi senza controllo su permessi e dati — e il fallimento del progetto stesso: Gartner stima che il 40% dei progetti di agenti autonomi verrà ritirato entro il 2027 proprio per problemi di governance.
Conclusioni
Il salto da Bussola a un agente aziendale non è una questione di potenza del modello o di funzionalità in più: è una questione di chi risponde di cosa, e da quando. Le aziende che stanno già scalando — Bayer ne è un esempio pubblico — non hanno vinto grazie a un prompt migliore, ma perché hanno trattato ogni agente come tratterebbero un nuovo dipendente: con uno scopo dichiarato, un responsabile e un accesso limitato al necessario. È una lezione che, da sistemista, riconosco bene: la tecnologia raramente fallisce da sola: fallisce quando la disciplina attorno ad essa manca.
Riferimenti
| # | Fonte | Livello |
|---|---|---|
| 1 | Microsoft Learn (2026). Guida visiva sulla governance degli agenti per Microsoft 365. | B |
| 2 | Microsoft Learn (2026). Domande frequenti sugli agenti per Microsoft 365. | B |
| 3 | IT trip (20 aprile 2026). Microsoft Entra Agent ID e Copilot Studio: come cambia la governance degli agenti AI nei workflow aziendali. | B |
| 4 | SynSphere (giugno 2026). Microsoft Agent 365 ed Entra Agent ID: governare gli agenti AI in azienda. | B |
| 5 | Epinium (8 giugno 2026, agg. 10 giugno 2026). Microsoft Copilot e Agenti IA Aziendali. (cita Gartner, Marco Casalaina/Microsoft Build 2026, caso Bayer) | B |
| 6 | Borio, L. / Argos New Dreams (15 luglio 2026). Microsoft Copilot Studio: come ho costruito “Bussola” in una notte, tra birre e un’amicizia. | C |
Fonti verificate al 21/07/2026. Contenuti a scopo divulgativo generati con AI; verificare link e riferimenti prima della pubblicazione.
Link interni
- Microsoft Copilot Studio: come ho costruito “Bussola” in una notte, tra birre e un’amicizia
- Skills, agenti e il conto: chi governa e chi paga
- Governance e sicurezza degli agenti AI: la risposta alla domanda che ogni CIO fa prima o poi
- Microsoft 365 Agent Store: come pubblicare agenti AI interni con governance enterprise
Lascia un commento