Il tenant è pronto? I requisiti che si verificano davvero
Dichiariamo subito di quale prodotto parliamo: qui si tratta di Microsoft 365 Copilot, l’esperienza licenziata integrata nelle app, non di Microsoft 365 Copilot Chat, incluso nella sottoscrizione Microsoft 365 e descritto dalla documentazione come il punto d’ingresso all’esperienza Copilot. Requisiti diversi, impostazioni diverse.
La pagina dei requisiti minimi divide le voci in due colonne: Required to deploy e Strongly recommended. Sono obbligatori il licensing, una Exchange Online mailbox, un account Entra ID, sistemi operativi e browser supportati e gli endpoint di rete raggiungibili. Sono fortemente raccomandati la SharePoint governance, il Purview labeling e un phased rollout. La casella primaria dell’utente deve risiedere in Exchange Online: il mailbox grounding, cioè l’uso di email, eventi di calendario e metadati, non è supportato per caselle on-premises o ibride.
Un requisito che sfugge spesso è il canale di aggiornamento: Copilot è disponibile in tutti i canali di Microsoft 365 Apps tranne il Semi-Annual Enterprise Channel, quindi in produzione servono Current Channel o Monthly Enterprise Channel. E non è supportato assegnare licenze Copilot a utenti cross-tenant, guest compresi.
Leggere il report di readiness senza scambiarlo per un via libera
Il Microsoft 365 Copilot readiness report si apre dal Microsoft 365 admin center in Reports > Usage, poi Microsoft 365 Copilot e Copilot; la prima scheda è Readiness, la seconda Usage. La sezione copre gli ultimi 28 giorni; il report è disponibile entro 72 ore e i dati d’uso possono avere altrettanta latenza.
In alto trovi Total Prerequisite Licenses, Users on an eligible update channel, Assigned Licenses e Available Licenses, più le card Recommended action. La tabella per utente riporta Has Copilot license been assigned, Uses eligible update channel, Uses Teams Meetings, Uses Teams chat, Uses Outlook Email, Uses Office docs e Suggested candidate for Copilot, colonna che ogni settimana segnala il 25% superiore degli utenti non licenziati in base all’intensità d’uso e che, precisa la documentazione, non serve a valutare le prestazioni dei dipendenti.
Le esperienze in-app seguono l’assegnazione della licenza: Copilot compare nelle app come Word ed Excel, in alcuni casi dopo fino a 24 ore e un riavvio dell’app, e il file deve essere modificabile, non in sola lettura. Il resto si governa dal Copilot Control System, in Copilot e Settings, con le schede User access, Data access, Copilot actions e Other settings: lì vivono impostazioni come Pin Copilot Chat. Per modificarle serve il ruolo AI Administrator; Global Reader consente solo di vederle.
Che cosa verifica l’esame qui: la differenza fra idoneità tecnica e prontezza reale. Il report dice chi può ricevere una licenza, non che cosa vedrà Copilot il giorno dopo.
I dati sono pronti? Oversharing, fughe e conformità
Ogni prompt viene eseguito nel contesto di sicurezza dell’utente che lo scrive: per vedere un elemento in una risposta, quell’utente deve già avere il permesso di accedervi. È il punto che regge l’intero dominio. Copilot non crea un problema di permessi, lo rende visibile e istantaneo, e chi salta la fase sui dati se lo ritrova addosso il primo giorno.
Il lavoro parte da SharePoint Advanced Management. Il Content Management Assessment si avvia dal SharePoint admin center in Advanced Management e Start assessment. I Data access governance reports, in Reports e Data access governance, comprendono il site permissions baseline report, il site permissions for users report, il report Everyone except external users (EEEU) e i sharing links activity reports. Le policy di Site lifecycle management coprono Site ownership policies, Inactive site policies e Site attestation policies: siti senza proprietario, inattivi o mai riesaminati.
Per intervenire ci sono due leve da non confondere mai. Restricted Access Control, in Policies e Access control, limita davvero l’accesso a un sito a un gruppo di sicurezza. Restricted Content Discovery, che si attiva su Sites, Active sites, scheda Settings, con l’opzione Restrict content from Microsoft 365 Copilot, non cambia i permessi: limita la scoperta del contenuto nelle ricerche a livello di organizzazione e nelle risposte di Microsoft 365 Copilot, rimuove dal sito i punti d’ingresso AI come il pulsante Copilot e non toglie il contenuto dall’indice, tanto che eDiscovery e auto-labeling di Purview continuano a funzionare. È un controllo temporaneo, da usare con parsimonia.
Purview: chi osserva e chi blocca
In Microsoft Purview i data risk assessments si trovano in DSPM, Discover, Data risk assessments, e alimentano l’obiettivo Prevent oversharing of sensitive data. Un assessment predefinito gira ogni settimana sui primi 100 siti SharePoint per utilizzo; aprendo un sito trovi le schede Overview, Identify, Protect e Monitor.
Attenzione al confine: DSPM osserva, misura e raccomanda, ma non blocca. Le azioni della scheda Protect creano altri oggetti, ciascuno con un mestiere suo. Una sensitivity label classifica e protegge un elemento e può essere applicata da una policy di auto-labeling. Una policy DLP sulla location Microsoft 365 Copilot and Copilot Chat usa l’azione Prevent Copilot from processing content per escludere dall’elaborazione i contenuti con determinate etichette, che però possono ancora comparire fra le citazioni della risposta. Una retention policy decide per quanto tempo il contenuto resta, non chi lo vede. E Microsoft 365 Backup è un’altra cosa ancora: continuità operativa, non retention di Purview.
L’errore ricorrente è scegliere DSPM quando la domanda chiede di impedire un comportamento, o una retention policy quando il problema è l’esposizione. Domanda-guida: serve vedere, limitare l’accesso, ridurre la scoperta o impedire l’elaborazione? L’esame è in beta e Microsoft non pubblica né durata né numero di domande, ma la soglia di superamento resta 700.