Microsoft Scout: perché l'identità degli agenti cambia la governance

L'AI enterprise sta per oltrepassare una soglia per la quale la maggior parte dei modelli di governance non è mai stata progettata. Microsoft Scout, presentato durante Microsoft Build 2026 come il primo agente della nuova categoria Autopilot di Microsoft, non aspetta un prompt e non si ferma quando la conversazione termina. Rimane attivo in background, costruisce un contesto sul modo in cui lavori attraverso Work IQ e agisce per tuo conto tra Microsoft 365, desktop e browser.

Il dettaglio che merita più attenzione di quella che sta ricevendo è più piccolo ma molto più significativo. Microsoft Scout ha una propria identità. Non prende in prestito la tua per la durata di una conversazione: è un'entità presente nella directory a cui possono essere assegnate autorizzazioni, che può agire quando nessuno la sta osservando e che deve quindi essere governata di conseguenza.

Si tratta di un cambiamento reale. Quasi tutti i modelli di controllo che le organizzazioni hanno costruito finora per l'AI presuppongono che l'agente agisca come un utente e ne erediti accessi, audit trail e responsabilità. Gli agenti Autopilot mettono in discussione questa assunzione. La domanda non è più chi possiede una licenza Microsoft 365 Copilot, ma che cos'è questo nuovo membro del tenant, cosa gli è consentito fare e come possiamo accorgerci se compie qualcosa che non avevamo previsto.

Copilot risponde a te. Scout risponde per te.

Un assistente AI tradizionale è reattivo per definizione. Tu gli fornisci un prompt, lui risponde, l'interazione termina e non rimane nulla se non ciò che hai scelto di conservare. Questo modello è relativamente semplice da governare proprio perché è delimitato: l'assistente agisce soltanto all'interno di una sessione avviata dall'utente, utilizzando autorizzazioni che quest'ultimo possiede già.

Un agente Autopilot ribalta questa logica. Microsoft descrive Scout come un agente che rimane attivo in background, mantiene il contesto di lavoro e agisce per conto dell'utente entro i limiti delle autorizzazioni e delle policy definite dall'utente stesso e dall'organizzazione. Il valore deriva dalla continuità: l'agente può accorgersi che una decisione è ancora in sospeso, che un documento è stato modificato o che una conversazione non ha ricevuto risposta. Il peso della governance nasce esattamente dallo stesso principio.

Che cos'è Microsoft Scout?

Microsoft Scout è un agente personale always-on per il lavoro, annunciato durante Build 2026 come il primo esponente della categoria Autopilot. Funziona come applicazione desktop per Windows e macOS e può leggere e scrivere file autorizzati, eseguire comandi, controllare un browser, interrogare i dati di Microsoft 365, svolgere attività pianificate o attivate in background e delegare attività ad agenti specializzati. Work IQ fornisce il livello di intelligence contestuale che gli consente di ragionare su contesto organizzativo, dati e strumenti nel rispetto delle autorizzazioni, permettendogli di evolvere da semplici risposte AI alla coordinazione di veri workflow aziendali.

Microsoft Scout e Microsoft 365 Copilot a confronto

Le due soluzioni sono complementari, non concorrenti. Microsoft 365 Copilot è l'assistente integrato nelle applicazioni, che viene richiamato all'interno di Word, Teams o Outlook e opera all'interno della sessione e delle autorizzazioni dell'utente. Microsoft Scout si colloca a un livello superiore: è un agente con una propria identità che coordina attività tra queste applicazioni nel tempo, senza dover essere chiamato in causa ogni volta. La maggior parte delle organizzazioni utilizzerà entrambe le soluzioni, ed è proprio per questo che il modello di governance deve tener conto delle differenze invece di trattare l'AI agentica come una semplice evoluzione di ciò che esiste già.

Ogni funzionalità è una decisione di controllo

È facile leggere l'elenco delle funzionalità di Scout come una storia di produttività. Rileggendolo dal punto di vista del controllo, ogni riga solleva una domanda a cui i team di sicurezza e compliance vorranno rispondere prima di un progetto pilota, non dopo.

Funzionalità	Domanda di controllo che solleva
Legge e scrive file autorizzati	Quali repository sono inclusi e come vengono applicate le etichette di sensibilità ai contenuti generati dall'agente?
Esegue comandi shell	Su quali endpoint? Con quale account? E dove viene registrata questa attività?
Interroga i dati di Microsoft 365	L'agente potrebbe accedere a informazioni condivise in modo eccessivo se i problemi esistenti relativi alle autorizzazioni Microsoft 365 non sono ancora stati risolti?
Esegue attività pianificate e in background	Chi verifica ciò che è accaduto durante la notte e rispetto a quale baseline?
Delega attività ad agenti secondari	L'approvazione concessa dall'utente all'agente principale si estende anche agli agenti figli?

 

Il problema delle approvazioni di cui ancora nessuno parla

La risposta di Microsoft a questo rischio è l'approvazione umana: Scout richiede conferma prima di eseguire azioni sensibili come inviare messaggi, scrivere file o eseguire comandi. Inoltre, l'accesso iniziale dipende dall'abilitazione da parte degli amministratori, dalla configurazione delle policy e dalla partecipazione al programma preview. È una scelta progettuale corretta. Ed è anche il punto in cui molti progetti enterprise rischiano di fallire silenziosamente.

L'approvazione funziona solo finché mantiene un significato reale. Un agente che opera continuamente durante la giornata di un knowledge worker genera richieste a una velocità che nessuna persona può valutare in modo realmente consapevole. Il risultato prevedibile è la approval fatigue: le persone cliccano su "approva" senza leggere, il controllo diventa puramente formale e i log di audit registrano un consenso che, in realtà, non è mai stato realmente espresso. L'errore opposto è altrettanto costoso. Se le approvazioni vengono configurate in modo troppo restrittivo, l'agente si blocca continuamente, gli utenti smettono di utilizzarlo e i benefici di produttività svaniscono prima ancora di poter essere misurati.

Il vero lavoro di adozione, quindi, non consiste nell'abilitare Scout. Consiste nel progettare il modello di approvazione: quali categorie di azioni sono pre-autorizzate per determinati ruoli, quali richiedono sempre un intervento umano, quali sono semplicemente vietate e come queste decisioni vengono riesaminate nel tempo invece di essere semplicemente registrate. Le organizzazioni che affrontano questo tema come un esercizio di progettazione fin dall'inizio otterranno valore dall'AI agentica. Quelle che lo considerano solo un'impostazione di configurazione finiranno inevitabilmente in uno dei due scenari di fallimento descritti sopra.

I controlli esistenti presuppongono che un agente sia una persona

Identità, accessi, protezione dei dati e monitoraggio devono essere ripensati partendo da una nuova premessa. Le policy di Conditional Access basate sui segnali di rischio dell'utente si comportano in modo diverso quando vengono applicate a un'identità non umana. Le regole di Data Loss Prevention progettate per persone che inviano email non sono state pensate per un agente che scrive file alla velocità di una macchina. Le etichette di sensibilità devono sopravvivere agli output dell'agente, non limitarsi a governarne gli input. E l'auditing deve essere in grado di rispondere a domande che oggi raramente vengono poste: cosa ha fatto l'agente, per conto di chi, con quale approvazione e possiamo ricostruirlo successivamente?

Come governare gli agenti AI in Microsoft 365

Una checklist iniziale per la sicurezza e la governance dell'AI agentica: 

1. Inventariare e assegnare la proprietà dell'identità dell'agente, associando a ogni agente presente nel tenant una persona chiaramente responsabile. 
2. Risolvere i problemi di oversharing prima di introdurre autonomia, perché un agente renderà accessibili tutte le informazioni consentite dalle autorizzazioni esistenti, più rapidamente e in modo più completo di quanto farebbe un essere umano. 
3. Definire categorie di azioni e classificare ciascuna come pre-autorizzata, soggetta ad approvazione o vietata. 
4. Estendere in modo esplicito a tutte le attività degli agenti le regole di Data Loss Prevention, sensitivity labeling e Conditional Access, senza dare per scontato che le coperture esistenti siano sufficienti. 
5. Rendere verificabili e soggette a revisione le attività degli agenti, assegnando chiaramente la responsabilità di tali verifiche. 
6. Stabilire in anticipo il meccanismo di disattivazione e verificare che funzioni realmente. 

Da dove iniziare: tre casi d'uso da provare e tre da evitare

Le organizzazioni non dovrebbero iniziare con automazioni estese. Un approccio più efficace consiste nell'identificare workflow limitati ma ad alto valore, in cui lo sforzo di coordinamento è elevato e il rischio di business è gestibile, per poi espandersi una volta che il modello di approvazione sarà stato messo alla prova sul campo.

I candidati migliori per iniziare sono la preparazione delle riunioni, in cui l'agente raccoglie informazioni da documenti e conversazioni precedenti mentre la riunione continua a essere gestita da una persona; il monitoraggio di attività e decisioni, dove il costo delle dimenticanze è elevato mentre il costo di eventuali errori dell'agente è contenuto; e la ricerca interna di documentazione, in cui l'output è una bozza che viene comunque revisionata da una persona prima di essere utilizzata. Ogni scenario dovrebbe essere valutato rispetto a sensibilità dei dati, requisiti di approvazione, esperienza utente, rischio operativo e risultati di business misurabili.

Tre scenari da rimandare a una fase successiva sono invece: qualsiasi attività che comporti comunicazioni esterne senza supervisione umana, qualsiasi attività che coinvolga dati regolamentati o altamente riservati prima che la classificazione dei dati sia adeguatamente gestita e qualsiasi scenario in cui l'agente esegua comandi su sistemi di produzione. La tecnologia consente già oggi di fare tutte queste cose. La maturità di governance necessaria per farle in sicurezza richiede però più tempo per essere costruita rispetto a quello necessario per implementare la tecnologia, ed è proprio in questo divario che si verificano gli incidenti.

Microsoft Scout mostra chiaramente la direzione dell'AI enterprise: il passaggio da copiloti che rispondono a istruzioni a agenti Autopilot in grado di coordinare il lavoro in modo continuativo sotto il controllo dell'organizzazione. La questione delle funzionalità è ormai quasi risolta. La questione aperta è il controllo. Un agente dotato di una propria identità, attivo in background, rappresenta un nuovo tipo di membro del tenant e il modello di approvazione costruito attorno a questa identità determinerà se genererà valore o introdurrà rischio.

Per i responsabili business e IT, la scelta più pragmatica è prepararsi fin da ora: selezionare due o tre casi d'uso circoscritti, completare il lavoro di riduzione dell'oversharing e di classificazione dei dati e progettare il modello di approvazione prima del progetto pilota, non dopo. SoftwareOne supporta questo percorso valutando il livello di preparazione a Microsoft 365 Copilot, progettando scenari sicuri di AI agentica, configurando controlli di governance e compliance e costruendo una roadmap di adozione che trasformi gli agenti AI in valore di business misurabile.