Tuo team dirigenziale pensa che sia una questione di lancio. Non lo è. Questa è una decisione di governance con tempi strettissimi e la pressione è alta perché Copilot non aspetta che tu faccia pulizia nelle poli se lo trovi un allineamento interno. Una volta che inizi a operare nel tuo ambiente, usa il sistema esattamente per come lo trova ed è lì che tutto si blocca. La maggior parte delle organizzazioni computant Microsoft 365 presume di avere un'unica strategia di controllo degli A, principalmente perché acquistano da un solo fornitore e gestiscono un solo dominio di identità. Sentono un'unica narrazione strategica da Microsoft e presumono che dall'età corrisponde al discorso. Ma la condizione operativa è molto diversa. L'IA lavora entro i confini dei tenant mentre il rischio li attraversa liberamente. Quindi la domanda non è, possiamo abietare Copilot ovunque? La vera domanda è, quale modello di governance ci permette di scalare in sicurezza tra tenant che si comportano in modo indipendente?

Prima di arrivare a quel modello dobbiamo definire la trappola. La trappola, isole di A sovrane all'interno di una singola azienda. Nella maggior parte delle organizzazioni l'illusione inizia dalla familiarità. Apri Microsoft 365, apri Preview, apri Entra, apri Power Platform. Il brand è lo stesso. Il linguaggio amministrativo sembra connesso. E la strategia commerciale racconta una storia molto lineare. Un ecosistema, una strategia, una direzione. Ma il modello di controllo sottostante non è un'unica entità. Questo conta più del brand. Basandosi sulla ricerca qui presentata, non esiste un unico centro di amministrazione IA globale con parità di funzioni che offre un unico punto per governare Copilot in modo pulito sotto i tenant. Ciò che è in realtà uno stack di controllo frammentato. Parti della governance risiedono in Preview, altri in vari centri di amministrazione e il resto è sparso tra Entra e Power Platform.

Alcune funzionalità stanno emergendo nei nuovi livelli di controllo Microsoft ma non formano ancora un piano globale completo e maturo oltre ogni confine di tenant. Quel divario crea una falsa sicurezza. I leader guardano l'ecosistema e presumono la centralizzazione mentre i team guardano l'identità condivisa e presumono la coerenza. L'ufficio acquisti vede un solo contratto e assume un solo modello operativo ma ogni tenant mantiene il proprio confine di policy e di dati il che significa che, in pratica, ognuno ha la propria versione della verità. Quindi ciò che sta accadendo è semplice. Non hai un unico ambiente IA aziendale. Hai molteplici ambienti IA che appartengono alla stessa azienda. È un quadro di rischio molto diverso. Un tenant potrebbe avere una copertura per view più forte mentre un altro ha un'adozione di etichette più debole o un'acquisizione di login completo. A livello di consiglio di amministrazione questo potrebbe sembrare un unico programma ma dal punto di vista dell'audito degli incidenti non lo è affatto.

È una collezione di condizioni operative separate. E una volta che quelle condizioni variano il report inizia la mente. Non intenzionalmente ma strutturabile. Team Essenziale chiede Siamo governati? Un tenant dice sì perché l'audito è attivo un altro dice sì perché esistono le etichette anche se la copertura è debole un terzo dice sì perché l'identità è connessa un quarto dice sì perché Copilot è tecnicamente distribuito Ogni risposta sembra ragionevole di per sé ma nessuna di esse significa la stessa cosa. Questa è la trappola. Pensi di guardare un piano di controllo globale quando in realtà stai guardando un insieme di isole AI sovrane all'interno di un'unica azienda sono connesse nel marchio e talvolta nell'identità ma non sono governate come un unico sistema e se non ricordate nient'altro di questa sezione ricordate questa frase non esiste un centro di amministrazione AI globale solo l'illusione di uno.

Una volta che quell'illusione si rompe il problema successivo si presenta rapidamente. La maggior parte delle organizzazioni risponde gestendo la governance tenant per tenant manualmente chiamano questo controllo perché la governance manuale per tenant fallisce su larga scala. Una volta che i leader vedono il problema del confine la risposta solita sembra sensata. Dicono va bene governeremo ogni tenant in modo appropriato. Un team di amministratori controlla impostazioni qui un altro team le ripete lì. Qualcuno tiene un foglio di calcolo qualcun altro crea una checklist. Un comitato direttivo si riunisce una volta al mese e chiede se il roll out è sulla buona strada. Sulla carta sembra disciplinato. In pratica è una ripetizione manuale mascherata da governance. Il motivo per cui fallisce è semplice. La ripetizione non produce controllo produce variazione nel tempo. Ciò accade perché ogni tenant si muove a una velocità diversa ogni amministratore interpreta gli standard in modo leggermente differente e le eccezioni locali iniziano a sembrare giustificate perché l'azienda vuole progredire ora non dopo un'altra revisione centrale.

Questo vecchio modello sopravvive perché sembra visibile. Le persone possono indicare ticket chiusi policy create impostazioni modificate. Possono mostrare attività ma lo sforzo visibile non equivale a un modello operativo stabile. E con Copilot nel quadro quel divario diventa costoso molto rapidamente. Il sistema inizia a utilizzare i permessi esistenti l'esposizione dei contenuti esistenti le lacune di etichettatura esistenti nel momento in cui gli utenti ne direi prom. Questo che la maggior parte delle persone non cop. Copilot non aspetta la maturità della govern. Funziona con i permessi che hai già l'igiene dei contenuti che già tolleri e la postura di audit che hai già mancato di standardizzare. I'm Se un tenant ha ripulito l'accesso e un altro ha cancellato i dati o se un tenant trasmette dati di audit utili mentre un altro ne cattura malapena abbastanza per le indagini il Copilot esporrà immediatamente quelle differenze.

Non accade in teoria, accade attraverso l'uso. Se un tenant ha revisionato un accesso ampio a SharePoint e un altro ha dato per scondato che bastasse li ha troverà le lacune. E andando più a fondo ogni nuovo tenant moltiplica il problema non perché i tenants siano negativi ma perché le differenze non gestite si accumulano. Un nuovo team pilota aggiunge un'eccezione locale una fusione introduce un altro tenant con etichette diverse e un'amministratura regionale copia una vecchia base di riferimento. L'unità aziendale richiede un accesso più rapido e nessuna di queste scelte appare drammatica si è presa isolatamente. Mettili insieme nel corso dei mesi e otterrai una deriva delle policy e dei accessi e dell'implementazione. Il risultato è un team di governance che spende più tempo a conciliare le differenze che a prevenire i rischi. È qui che il controllo manuale fallisce. Sembra più sicuro perché gli esseri umani gestiscono le impostazioni ma in realtà ha scala di incoerenza perché ogni punto di contatto è un'occasione per i tenant di divergere.

L'esito è un'implementazione più lenta dove si desidera velocità più sforzi di audit dove si vogliono prove e più rilaborazioni dove si vorrebbero stando. Peggio ancora crea un'esposizione nascosta dove la dirigenza si aspetta sicurezza. L'ho capito quando ho smesso di trattare la governance come un'attività di configurazione iniziale. Non lo è. Si comporta più come un decadimento. Se ripulisci le autorizzazioni una volta ma nessun controllo impedisce loro di tornare a divergere l'esposizione dei tuoi. Se definisci una tassonomia di etichette una volta ma i tenant la applicano in modo uniforme la base di riferimento si erode. Se approvi co-pilot a ondate senza verificare se i controlli sottostanti siano ancora validi non stai scalando in sicurezza. Ti stai solo espandendo più velocemente di quanto la tua governance riesca a gestire. Quindi la metrica che conta qui è la deriva degli accessi.

Non solo se hai risolto qualcosa ma quanto velocemente le autorizzazioni si diffondono di nuovo dopo la correzione. Questo ti dice se il tuo modello sta reggendo o cedendo. Perché la governance non è un progetto che si conclude. Un problema di decadimento che gestisci continuamente. Quando la scala rompe il vecchio modello la maggior parte dei leader cerca la risposta più familiare l'identità. Presumano che se gli utenti possono spostarsi facilmente tra i tenant la governance si sposterà in qualche modo con lui. Non succederà. Perché l'identità non risolve la governance? Che molti programmi prendono una strada sbagliata perché l'identità sembra la risposta pulita? Se gli utenti possono autenticarsi tra i tenant se entra è connesso e se le impostazioni cross tenant sono attive i leader presumono che la parte difficile sia risolva. L'accesso sembra unificato l'accesso sembra unificato il diagramma dell'architettura appare ordinato ma la governance di Copilot non diventa unificata solo perché l'identità può spostarsi.

Quell'assunzione fallisce nel momento in cui l'IA entra effettivamente in gioco. Copilot basa le risposte all'interno del contesto del tenant in cui viene eseguita la richiesta e le linee guida di Microsoft sono chiare su questo punto. Microsoft 365 Copilot opera all'interno del perimetro di sicurezza e conformità del tenant e rispetta le autorizzazioni dell'utente nello specifico contesto del tenant. Un utente può cambiare contesto come Gessy ma Copilot resta limitato a un solo tenant alla volta. Non unisce più tenant in un unico spazio di lavoro intelligente per una risposta singola. Quindi l'identità può spostarsi la governance no? E una volta separati questi due aspetti gran parte del linguaggio dirigenziale inizia a suonare pericolosamente vago. Tenant connessi? Identità condivisa? Esperienza unificata? Queste frasi possono essere corrette per la collaborazione ma non significano che l'applicazione delle policy il data grounding il logging e la convalida dei controlli funzionino come un unico sistema.

Il divario diventa ancora più evidente osservando la modalità multi-tenant di Copilot Studio perché l'anteprima racconta una storia molto specifica. Sì, l'uso multi-tenant esiste e un agente ospitato in un tenant può essere usato da un altro ma l'autenticazione dell'utente finale in modalità multi-tenant non è ancora supportata nell'anteprima. gli utenti guest non sono supportati i connettori personalizzati non sono supportati i connettori standard i graph e Microsoft 365 non sono supportati multi-GA non è supportato diverse funzionalità di analisi non sono disponibili anche le trascrizioni delle conversazioni sono disattivate in quella modalità non si tratta di una solida struttura di governance cross-tenant è un'anteprima limitata con vincoli chiari questi limiti contano perché smientiscono la versione che molti team dirigenziari si raccontano sentono multi-tenant e presumono una motorità operativa i loro architetti sentono cross-tenant e presumono una simmetria nelle policy i loro team di controllo sentono stesso fornitore e presumono una coerenza di out poi inizia a roll out e si scoprono comportamenti diversi segnali mancanti e lacune evidenti in autenticazione e analisi immaginiamo secondo caso un'azienda globale imposta relazioni cross-tenant e presume che l'esperienza utente si estenderà naturalmente all'uso di copilot l'aspettativa sembra ragionevole includendo fiducia nella directory condivisa accesso fluido e modelli di identità comuni ma quando i team testano gli scenari reali copilot degli agenti il comportamento disomogene alcuni dati appaiono solo in contesti commutati alcuni connettori previsti non sono disponibili alcune aspettative di audit non corrispondono a ciò che le funzioni in anteprima espongono realmente la dirigenza continua a sentire connesso mentre il team di controllo inizia a trovare eccezioni non è un caso limite tecnico è un errore di interpretazione della go perché i revisori non controllano la vostra narrazione architetturale contro chiedono dove sono stati eseguiti i prompt quale tenant ha applicato la policy quali log esistono e se i vostri controlli fossero realmente comparabili tra gli ambienti descritti come collegati se il vostro modello operativo ha trattato l'identità come governance non avrete una risposta chiara quindi se dovete ricordare una sola cosa che sia questa l'identità cross tenant non è intelligenza cross tenant l'identità aiuta gli utenti ad accettare non ti dice se il comportamento di copilot è governato in modo coerente è monitorato correttamente o sicuro da scalare in tutti i luoghi che la tua azienda ora definisce un unico ambiente e una volta che questo diventa chiaro la risposta non può essere aggiungere più connessioni tra deve essere l'architettura il modello di governance che funziona davvero hub e spoke quindi che aspetta un vero modello di governance quando la tua piattaforma è frammentata l'identità è solo parziale e i confini dei tenant contano ancora davvero all'aspetto di un sistema hub spoke non lo suggerisco perché il diagramma appare pulito su una slide ma perché corrisponde realmente alle caotiche condizioni operative che stai affrontando ora ti serve un posto centrale dove le decisioni di governance siano progettate misurate e applicate come un unico sistema poi ti servono team locali per i tenant che seguono quelle decisioni questi team locali devono lavorare entro i propri confini senza inventare la propria versione delle regole ogni volta che sentono un po' di pressione dobbiamo partire dal lab lab non è un portale di amministrazione non è una dashboard brillante e sicuramente non è un eroico team centrale che entra in ogni singolo tenant per pulire i file manualmente al contrario lab funge da autorità di governance definitiva questo gruppo possiede la progettazione delle policy le linee di guida di audit gli standard delle etichette e i criteri di implementazione sono loro a decidere cosa significa realmente essere pronti per co-pilot quali prove valgano come dimostrazione e quanto velocemente debba essere colmata una falla di sicurezza questo cambiamento trasformerli della conversazione grazie a questa struttura globale smette di essere un termine per una schermata magica e inizia a significare un unico sistema di governance unificato ottieni uno standard per i controlli di preview uno standard per come acquisire gli audit e uno standard per le tue etichette di sensibilità c'è un unico parametro chiaro per ciò che deve essere vero prima che un tenant specifico sia consentito estendere l'accesso a co-pilot più utenti poi ti servono gli spoke gli spoke sono i tuoi team locali di esecuzione dei tenant che prendono quella base e la applicano al loro ambiente specifico sono loro a gestire la risoluzione con validare i log e rivedere i permessi di accesso estesi tuttavia svolgono tutto quel lavoro all'interno di uno spazio progettuale molto limitato piuttosto che non liberi tutti se un team locale deve discostarsi dal piano esiste un percorso formale per le eccezioni se vogliono muoversi più velocemente devono comunque soddisfare prima i controlli condivisi quando emergono differenze regionali e legali tali questioni vengono documentate approvate invece di essere silenziosamente assorbite in qualche soluzione locale di cui nessuno sa nulla questa struttura è fondamentale perché i modelli completamente centralizzati solitamente si bloccano sui dettagli locali mentre quelli puramente locali scivolano quasi subito in coerenza totale il modello hub and spoke evita entrambi questi schemi di fallimento l'hub garantisce la coerenza necessaria mentre gli spoke offrono velocità di esecuzione dove il lavoro avviene concretamente prendiamolo concreto nel hub definisci il set minimo di controlli per view che ogni talento deve eseguire prima che copilot possa espandersi definisci esattamente quali eventi di audio ti aspetti di vedere e con quale frequenza li esaminerai inoltre crei una tassonomia di etichette condivisa per i contenuti sensibili affinché un tag riservato non significhi 5 cose diverse in 5 tenant diversi imposti il ritmo delle revisioni magari mensile per la postura di sicurezza generale e più frequente nelle aree in cui il rollout è attivo nello spoke il tuo team adatta quelli standard di alto livello alla realtà di quel tenant specifico individuano quali siti hanno ancora un accesso troppo esteso e quali unità aziendali sono in ritardo con l'etichettatura verificano se l'audit è effettivamente attivo e se i record corretti sono visibili al team di sicurezza cercano amministratori locali che potrebbero aver introdotto eccezioni mai revisionate ufficialmente e decidono se un gruppo pilota può espandersi in sicurezza o se è necessario fermarsi prima per risolvere i problemi ed ecco la regola ferrea perché senza regole questo modello è solo un suggerimento e non una vera governance nessun rollout di copilot avviene in alcun tenant senza log di audit convalidati una scansione di condivisione eccessiva completata è una base minima di copertura delle etichette non sto parlando di cose pianificate o discusse solo in parte devono essere convalidati se un tenant non può dimostrare che queste tre condizioni sono soddisfatte e i rollout si interrompono potrebbe sembrare severo finché non lo confronti con l'enorme costo di rimediare al disordine quando gli utenti iniziano a trovare contenuti sensibili che non intendevi esplorare tramiteria vista in quest'ottica queste regole sono solo semplice buonsenso un altro motivo per cui questo modello funziona così bene è la tempistica più aspetti a impostarlo più debito di pulizia creerai per il futuro ogni tenant che parte prima di aver raggiunto la base di riferimento diventa un enorme arretrato di eccezioni e prove mancanti che il tuo team dovrà alla fine districare i leader spesso trattano il completamento dell'adozione ma in un mondo co-pilot multi-tenant questa sequenza è completamente errata la governance deve guidare il rollout altrimenti il rollout crea più debito di quanto i tuoi team possono mai sperare di gestire se stai guidando questo processo a livello aziendale la tua prossima mossa è molto più crea subito l'hub e rifinisci oggi stesso con la linea di base assegni i tuoi spot che metti immediatamente per iscritto il processo di gestione dell'eccezione devi fare in modo che globale significhi che le tue decisioni i tuoi passaggi di rollout funzionino come un unico sistema anche quando i tenant stessi non lo fanno un modello conta solo se cambia effettivamente ciò che verrà applicato domani mattina cosa dovrebbero misurare i leader prima di scalare un modello di governance regge solo se produce misurazioni condivise da tutti altrimenti ogni tenant dichiarerà di fare progressi nel proprio linguaggio e la leadership riceverà aggiornamenti senza avere alcun controllo reale prima di espandere ulteriormente i copilot ti serve un piccolo set di metriche che ti indichi se l'architettura si comporta come pensi i livelli di attività non ti diranno la verità e i numeri di adozione non ti mostreranno di certo i rischi dovresti iniziare riducendo la condivisione eccessiva questo resta uno dei segnali più evidenti che il tuo ambiente sta diventando davvero più sicuro per l'IA devi esaminare gruppi di accesso estesi city sharepoint aperti e vecchi permessi che concedono molto più accesso di quanto l'azienda richieda l'obiettivo qui non è raggiungere un numero perfetto ma dimostrare che la tua esposizione sta diminuendo prima che la portata di copilot home se quelle due linee si muovono in direzioni opposte ti stai espandendo molto più velocemente di quanto tu stai risolvendo i problemi sottostanti la seconda metrica di cui hai bisogno è una copertura di osservabilità riesci davvero a vedere cosa sta facendo copilot in tutti i tuoi tenant in modo da sopportare un'indagine reale gran parte della ricerca indica Microsoft Preview come il luogo principale in cui vengono archiviati i record fondamentali come le interazioni di copilot ma ciò presuppone che l'auditing sia attivo ovunque la copertura non è qualcosa che puoi dare per scontato devi sapere esattamente quali tenant hanno l'ingestione dei log attiva e quali ti lasciano ancora una visibilità parziale se non hai log non hai governance e non hai responsabilità sembra crudo perché deve esserlo se un tenant non può fornire prove utilizzabili di ciò che sta accadendo il tenant non è pronto per scalare in sicurezza non puoi governare ciò che non ti ha permesso ispezionare e di certo non sarai in grado di difendere le tue azioni se qualcosa dovesse andare storto in seguito la terza metrica è il tempo di applicazione delle policy su tutti i tenant che la readership scopre se il modello abbanspoke è reale o solo decorativo o solo decorativo una decisione centrale non significa nulla se un tenant la applica questa settimana mentre un altro aspetta un mese per pensarci dovresti misurare il tempo che intercorre dall'approvazione di una policy alla sua effettiva applicazione in ogni singolo tenant non parlo del tempo necessario per annunciarlo o documentarlo ma del tempo fino a quando non è effettivamente operativo per un programma di IA che si evolve così rapidamente quel tipo di ritardo è solo un altro modo di chiamare il rischio un obiettivo pratico per la maggior parte delle organizzazioni è stare sotto le 72 ore per le modifiche standard se il tempo del vostro ciclo è molto più lungo non avete ancora un modello scalabile avete solo un problema di coordinamento che deve essere risolto successivamente dovete esaminare il rapporto di coperture Z non lasciate che diventi una metrica di vanità dove un tenant raggiunge numeri alti mentre gli altri restano indietro ciò che conta davvero è se i vostri contenuti sensibili siano etichettati in modo abbastanza coerente ma non far basare il comportamento di copilot su ipotesi dell'utente non cercate la perfezione qui ma cercate un livello di controllo paragonabile in ogni tenant dell'organizzazione infine dovete monitorare il tasso di deriva degli accessi questa metrica vi dice se i vostri sforzi di pulizia stanno effettivamente resistendo nel tempo dopo aver terminato un progetto di rimedio quanto velocemente quelle autorizzazioni iniziano a diffondersi di quanto spesso quei gruppi estesi si insinuano nuovamente nel sistema molti team se ne accorgono troppo tardi perché hanno misurato la correzione una sola volta dando per scontato che il prodotto sia non lo era l'unica metrica che conta è quanto velocemente il sistema inizia a cedere una volta che smettete di sorvegliarlo questo è il vostro ruscotto operativo dovete monitorare la riduzione della condivisione eccessiva la copertura dell'osservabilità il tempo di applicazione delle policy la copertura delle etichette in etichette nella deriva degli accessi il ritmo della vostra reportistica è importante tanto quanto i numeri stessi l'hub dovrebbe gestire il ruscotto esecutivo perché la dirigenza ha bisogno di una visione unica dell'intera postura nel frattempo gli spook dovrebbero occuparsi della rimedio perché il lavoro effettivo deve avvenire dove risiede il confine del tenant un team legge il sistema e l'altro team lo corregge dovete monitorare questi numeri prima di espandervi non a posteriori il rischio non aspetta la vostra prossima riunione o il vostro workshop di cover è già attivo in ogni tenant in cui copilot può trovare esattamente ciò che i vostri attuali controlli gli consentono ancora di vedere i due modelli che i leader continuano a trascurare continua a vedere i due modelli specifici sul campo ed entrambi accadono perché i leader trattano copilot come un lancio di software invece che come un evento di controllo importante il primo modello inizia quando un'organizzazione lancia copilot prima di definire una reale base di riferimento di preview o di rivedere i propri accessi sharepoint al primo giorno il lancio sembra perfetto le licenze sono assegnate, gli utenti sono entusiasti e la comunicazione interna punta tutta sulla produttività ma poi i normali prompt iniziano a far emergere materiale che era tecnicamente accessibile da sempre ma praticamente invisibile al dipendente medio prima dell'IA nessuno passava la giornata a cliccare su vecchi siti cartelle obsolete o permessi ereditati per trovare cose che non avrebbe dovuto vedere ma ora non devono più farlo un utente pone una domanda di base, riceve un riepilogo e appare un file magari si tratta di contenuti sensibili di risorse umane, materiale finanziario o informazioni su accordi che dovevano restare in una cerchia molto ristretta non c'è stata alcuna violazione, nessun malware e nessuna barriera di sicurezza infranda nel senso tradizionale il sistema ha semplicemente utilizzato i permessi e lo stato dei contenuti che il tenant già consentiva è il momento in cui molti team finalmente comprendono il problema LIA non ha creato l'esposizione ha solo rimosso l'attrito che la nascondeva una volta che ciò accade in un tenant la fiducia della dirigenza solitamente crolla in tutta l'organizzazione perché nessuno può dire con certezza dove lo stesso schema potrebbe ripresentarsi l'incidente può sembrare locale ma il danno alla fiducia a livello aziendale il secondo schema è più silenzioso ma altrettanto pericoloso un'azienda stabilisce relazioni di identità tra tenant sente che gli scenari multi tenant sono possibili e presume che il proprio modello operativo sia abbastanza maturo per un'implementazione su larga scala su una presentazione sembra un piano solido in realtà le operazioni diventano caotiche un team si aspetta un'esperienza copilot fluida in ogni ambiente connesso mentre un altro si aspetta una visibilità comparabile e un terzo presume che gli stessi controlli seguiranno l'utente ovunque poi l'utilizzo effettivo inizia a mostrare comportamenti disomogeni lacune nell'autenticazione e punti deboli in ciò che può effettivamente essere misurato il problema non è che questi team siano stati negligenti il vero problema è che hanno tradotto la connettività in garanzia tale presupposto crea una falsa narrazione sulla conformità la dirigenza sente la parola connesso e presume che l'organizzazione sia pronta mesi dopo le revisioni dei controlli scoprono che il comportamento le prove e l'applicazione variavano molto più di quanto chiunque volesse ammettere all'inizio ora confrontalo con uno schema migliore un'altra organizzazione sceglie di rallentare prima di espandersi definiscono prima una base di etichettatura esaminano prima gli accessi estesi e convalidano la loro visibilità di audit prima di fare qualsiasi altra cosa espandano copilot a ondate non perché temano l'adozione ma perché vogliono che ogni ondata produca prove utilizzabili prima che inizi la successiva quell'organizzazione di solito si muove più velocemente a lungo termine perché non deve fermarsi continuamente a spiegare sorprese ripulire i contenuti esposti e discutere su cosa dovesse effettivamente significare governato questo è il vantaggio che molti leader trascura una buona governance non blocca il tuo roll out elimina gli attriti dal roll out una volta terminata la prima ondata la trappola non è l'adozione in sé la trappola è l'adozione non gestita tra tenant che sembrano connessi da lontano ma che si comportano in modo molto diverso da vicino la decisione che devi prendere è in realtà molto semplice devi passare subito a un modello di governance dell'IA federato Habenspo che smettere di confondere l'attivazione tenant per tenant con un controllo reale dovresti sospendere l'espansione di copilot in ogni tenant che non può dimostrare il proprio logging le revisioni delle condivisioni eccessive la copertura di base delle etichette l'IA seguirà il sistema che costruirai realmente non l'organigramma a cui fai riferimento se questo ha cambiato il tuo modo di pensare alla governance di copilot multitenant seguimi Mirko Peter su LinkedIn e condividi questo post con il tuo team se stai affrontando questi problemi proprio ora grazie a tutti