M365 Copilot & Agents

Copilot legge quello che puoi leggere tu. Non sempre è una buona idea.

Ciò che Copilot e gli Agents trovano nel tuo tenant non sta nella documentazione Microsoft. Sta nei tuoi permessi. Ci assicuriamo che entrambi siano a posto.

Richiedi una consulenza

Prenota su Azure Marketplace

Introdurre M365 Copilot e Agents in modo sicuro: configurazione, oversharing e la giusta architettura

Prima di Copilot, l'oversharing non aveva conseguenze percepibili, perché nessuno aveva il tempo di setacciare tutti i documenti di un'azienda media. Copilot quel tempo lo ha. Gli bastano pochi secondi, e non cerca problemi, li trova e basta, perché accede a ciò che il singolo utente può leggere tramite Microsoft Graph, e nella maggior parte dei tenant un dipendente medio può statisticamente leggere circa 130.000 file mai pensati per lui. Il primo effetto più frequente dopo un rollout di Copilot non è quindi un aumento della produttività, ma una trasparenza indesiderata.

Non è un argomento contro Copilot. È un argomento a favore della sequenza corretta. Permessi, Sensitivity Labels, DLP policies, la configurazione del Copilot Control System e la domanda su quali admin center siano rilevanti prima del primo rollout: questi compiti esistevano prima di Copilot come dopo, solo che l'occasione per affrontarli in modo sistematico non è mai stata così concreta come ora. In questo senso Copilot non è un problema, è l'occasione per impostare il tenant come avrebbe dovuto essere da sempre.

16 %

di tutti i dati aziendali è statisticamente sovraesposto (Microsoft)

130.000

file a cui i dipendenti hanno accesso in media, mai pensati per loro

70 %

dei dipendenti ha condiviso dati business-critical con AI non autorizzate (Microsoft)

23 %

non sa se la propria azienda offra strumenti AI (Microsoft)

Cos'è Copilot, cos'è un agent e perché la differenza conta

La distinzione che Microsoft traccia tra Copilot e Agents è tecnicamente precisa, ma nella comunicazione spesso sfumata, e questo porta le aziende ad aspettarsi troppo o a partire dal lato sbagliato. La linea più semplice passa per la questione dell'autonomia.

M365 Copilot e Copilot Chat sono assistenti interattivi che rispondono a domande, riassumono contenuti e redigono testi, sempre sulla base di ciò che l'utente può leggere tramite Microsoft Graph. Non agiscono, supportano. I Declarative Agents, cioè SharePoint Agents o Agents costruiti con l'Agent Builder, estendono questo approccio a un'area di conoscenza ristretta e predefinita, ma non prendono decisioni autonome e non eseguono azioni di sistema.

Diventano davvero autonomi solo come Custom Engine Agents, costruiti in Copilot Studio, Power Platform o Azure AI Foundry: possono essere attivati da eventi, comunicare con servizi esterni ed eseguire azioni senza che un essere umano debba confermare ogni passo. Chi non conosce questa differenza costruisce Agents per compiti che un semplice prompt di Copilot svolgerebbe altrettanto bene, oppure si aspetta da un Declarative Agent un'autonomia che a livello architetturale non è prevista.

Copilot e Agents presuppongono una piattaforma pensata per questo

Copilot accede tramite Microsoft Graph ai dati che l'utente può leggere, e gli agent operano entro i confini di sistema definiti dalla piattaforma. Se questi confini non sono stati impostati esplicitamente, perché il tenant è cresciuto storicamente e non è mai stato progettato per l'accesso AI, Copilot e gli agent funzionano tecnicamente, ma in un ambiente non ottimizzato né per la performance né per la governance.

La nostra Cloud Workplace Foundation pone la base M365 di cui Copilot ha bisogno: struttura delle autorizzazioni, Sensitivity Labels, DLP, policy di governance, non aggiunte a posteriori ma integrate fin dall'inizio. Per gli agent che operano in Azure vale lo stesso: la Azure Foundation e la Azure Container Foundation assicurano che il terreno sia solido prima di costruire. Chi effettua il deploy di agent in un ambiente privo di questa base, sta costruendo sulla sabbia.