WEBVTT

00:00:00.000 --> 00:00:03.040
Tuo team dirigenziale pensa che sia una questione di lancio. Non lo è.

00:00:03.400 --> 00:00:10.080
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.

00:00:10.940 --> 00:00:15.660
Una volta che inizi a operare nel tuo ambiente, usa il sistema esattamente per come lo trova ed è lì che tutto si blocca.

00:00:16.700 --> 00:00:24.740
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à.

00:00:25.520 --> 00:00:29.160
Sentono un'unica narrazione strategica da Microsoft e presumono che dall'età corrisponde al discorso.

00:00:29.160 --> 00:00:34.520
Ma la condizione operativa è molto diversa. L'IA lavora entro i confini dei tenant mentre il rischio li attraversa liberamente.

00:00:34.780 --> 00:00:37.020
Quindi la domanda non è, possiamo abietare Copilot ovunque?

00:00:37.520 --> 00:00:42.200
La vera domanda è, quale modello di governance ci permette di scalare in sicurezza tra tenant che si comportano in modo indipendente?

00:00:43.080 --> 00:00:45.420
Prima di arrivare a quel modello dobbiamo definire la trappola.

00:00:45.940 --> 00:00:48.540
La trappola, isole di A sovrane all'interno di una singola azienda.

00:00:49.280 --> 00:00:51.960
Nella maggior parte delle organizzazioni l'illusione inizia dalla familiarità.

00:00:52.640 --> 00:00:56.280
Apri Microsoft 365, apri Preview, apri Entra, apri Power Platform.

00:00:56.280 --> 00:00:59.900
Il brand è lo stesso. Il linguaggio amministrativo sembra connesso.

00:01:00.220 --> 00:01:02.440
E la strategia commerciale racconta una storia molto lineare.

00:01:02.920 --> 00:01:04.860
Un ecosistema, una strategia, una direzione.

00:01:05.640 --> 00:01:07.900
Ma il modello di controllo sottostante non è un'unica entità.

00:01:08.080 --> 00:01:09.100
Questo conta più del brand.

00:01:09.600 --> 00:01:13.300
Basandosi sulla ricerca qui presentata, non esiste un unico centro di amministrazione IA globale

00:01:13.300 --> 00:01:17.120
con parità di funzioni che offre un unico punto per governare Copilot in modo pulito sotto i tenant.

00:01:17.820 --> 00:01:19.580
Ciò che è in realtà uno stack di controllo frammentato.

00:01:19.580 --> 00:01:23.020
Parti della governance risiedono in Preview, altri in vari centri di amministrazione

00:01:23.020 --> 00:01:25.260
e il resto è sparso tra Entra e Power Platform.

00:01:26.080 --> 00:01:29.520
Alcune funzionalità stanno emergendo nei nuovi livelli di controllo Microsoft

00:01:29.520 --> 00:01:33.180
ma non formano ancora un piano globale completo e maturo oltre ogni confine di tenant.

00:01:33.760 --> 00:01:35.080
Quel divario crea una falsa sicurezza.

00:01:35.600 --> 00:01:37.900
I leader guardano l'ecosistema e presumono la centralizzazione

00:01:37.900 --> 00:01:40.960
mentre i team guardano l'identità condivisa e presumono la coerenza.

00:01:41.640 --> 00:01:44.660
L'ufficio acquisti vede un solo contratto e assume un solo modello operativo

00:01:44.660 --> 00:01:47.180
ma ogni tenant mantiene il proprio confine di policy e di dati

00:01:47.180 --> 00:01:50.520
il che significa che, in pratica, ognuno ha la propria versione della verità.

00:01:51.360 --> 00:01:52.540
Quindi ciò che sta accadendo è semplice.

00:01:53.040 --> 00:01:54.620
Non hai un unico ambiente IA aziendale.

00:01:55.100 --> 00:01:57.640
Hai molteplici ambienti IA che appartengono alla stessa azienda.

00:01:58.140 --> 00:01:59.320
È un quadro di rischio molto diverso.

00:01:59.800 --> 00:02:02.040
Un tenant potrebbe avere una copertura per view più forte

00:02:02.040 --> 00:02:04.220
mentre un altro ha un'adozione di etichette più debole

00:02:04.220 --> 00:02:05.620
o un'acquisizione di login completo.

00:02:06.100 --> 00:02:07.440
A livello di consiglio di amministrazione

00:02:07.440 --> 00:02:09.120
questo potrebbe sembrare un unico programma

00:02:09.120 --> 00:02:11.660
ma dal punto di vista dell'audito degli incidenti non lo è affatto.

00:02:11.920 --> 00:02:13.620
È una collezione di condizioni operative separate.

00:02:13.620 --> 00:02:15.560
E una volta che quelle condizioni variano

00:02:15.560 --> 00:02:16.640
il report inizia la mente.

00:02:17.160 --> 00:02:18.640
Non intenzionalmente ma strutturabile.

00:02:19.100 --> 00:02:19.960
Team Essenziale chiede

00:02:19.960 --> 00:02:20.860
Siamo governati?

00:02:21.680 --> 00:02:23.200
Un tenant dice sì perché l'audito è attivo

00:02:23.200 --> 00:02:24.920
un altro dice sì perché esistono le etichette

00:02:24.920 --> 00:02:26.160
anche se la copertura è debole

00:02:26.160 --> 00:02:28.620
un terzo dice sì perché l'identità è connessa

00:02:28.620 --> 00:02:31.620
un quarto dice sì perché Copilot è tecnicamente distribuito

00:02:31.620 --> 00:02:33.940
Ogni risposta sembra ragionevole di per sé

00:02:33.940 --> 00:02:35.400
ma nessuna di esse significa la stessa cosa.

00:02:35.720 --> 00:02:36.340
Questa è la trappola.

00:02:36.760 --> 00:02:38.540
Pensi di guardare un piano di controllo globale

00:02:38.540 --> 00:02:39.840
quando in realtà stai guardando

00:02:39.840 --> 00:02:42.160
un insieme di isole AI sovrane all'interno di un'unica azienda

00:02:42.160 --> 00:02:45.000
sono connesse nel marchio e talvolta nell'identità

00:02:45.000 --> 00:02:46.940
ma non sono governate come un unico sistema

00:02:46.940 --> 00:02:49.340
e se non ricordate nient'altro di questa sezione

00:02:49.340 --> 00:02:50.240
ricordate questa frase

00:02:50.240 --> 00:02:53.200
non esiste un centro di amministrazione AI globale

00:02:53.200 --> 00:02:54.140
solo l'illusione di uno.

00:02:54.740 --> 00:02:56.020
Una volta che quell'illusione si rompe

00:02:56.020 --> 00:02:57.580
il problema successivo si presenta rapidamente.

00:02:58.140 --> 00:02:59.580
La maggior parte delle organizzazioni risponde

00:02:59.580 --> 00:03:01.920
gestendo la governance tenant per tenant manualmente

00:03:01.920 --> 00:03:02.800
chiamano questo controllo

00:03:02.800 --> 00:03:05.640
perché la governance manuale per tenant fallisce su larga scala.

00:03:06.080 --> 00:03:07.800
Una volta che i leader vedono il problema del confine

00:03:07.800 --> 00:03:09.140
la risposta solita sembra sensata.

00:03:09.140 --> 00:03:11.380
Dicono va bene governeremo ogni tenant in modo appropriato.

00:03:11.800 --> 00:03:13.520
Un team di amministratori controlla impostazioni qui

00:03:13.520 --> 00:03:14.760
un altro team le ripete lì.

00:03:15.060 --> 00:03:16.220
Qualcuno tiene un foglio di calcolo

00:03:16.220 --> 00:03:17.420
qualcun altro crea una checklist.

00:03:17.900 --> 00:03:19.860
Un comitato direttivo si riunisce una volta al mese

00:03:19.860 --> 00:03:21.420
e chiede se il roll out è sulla buona strada.

00:03:21.980 --> 00:03:23.200
Sulla carta sembra disciplinato.

00:03:23.560 --> 00:03:25.480
In pratica è una ripetizione manuale

00:03:25.480 --> 00:03:26.480
mascherata da governance.

00:03:26.480 --> 00:03:28.340
Il motivo per cui fallisce è semplice.

00:03:28.840 --> 00:03:30.480
La ripetizione non produce controllo

00:03:30.480 --> 00:03:32.060
produce variazione nel tempo.

00:03:32.860 --> 00:03:35.360
Ciò accade perché ogni tenant si muove a una velocità diversa

00:03:35.360 --> 00:03:36.920
ogni amministratore interpreta gli standard

00:03:36.920 --> 00:03:38.120
in modo leggermente differente

00:03:38.120 --> 00:03:40.020
e le eccezioni locali iniziano a sembrare giustificate

00:03:40.020 --> 00:03:41.380
perché l'azienda vuole progredire ora

00:03:41.380 --> 00:03:43.000
non dopo un'altra revisione centrale.

00:03:43.680 --> 00:03:45.600
Questo vecchio modello sopravvive perché sembra visibile.

00:03:46.160 --> 00:03:47.740
Le persone possono indicare ticket chiusi

00:03:47.740 --> 00:03:49.500
policy create impostazioni modificate.

00:03:49.920 --> 00:03:50.780
Possono mostrare attività

00:03:50.780 --> 00:03:53.720
ma lo sforzo visibile non equivale a un modello operativo stabile.

00:03:53.720 --> 00:03:55.240
E con Copilot nel quadro

00:03:55.240 --> 00:03:57.060
quel divario diventa costoso molto rapidamente.

00:03:57.500 --> 00:03:59.420
Il sistema inizia a utilizzare i permessi esistenti

00:03:59.420 --> 00:04:00.880
l'esposizione dei contenuti esistenti

00:04:00.880 --> 00:04:02.240
le lacune di etichettatura esistenti

00:04:02.240 --> 00:04:03.580
nel momento in cui gli utenti ne direi prom.

00:04:03.920 --> 00:04:05.140
Questo che la maggior parte delle persone non cop.

00:04:05.480 --> 00:04:07.020
Copilot non aspetta la maturità della govern.

00:04:07.420 --> 00:04:08.640
Funziona con i permessi che hai già

00:04:08.640 --> 00:04:10.180
l'igiene dei contenuti che già tolleri

00:04:10.180 --> 00:04:12.900
e la postura di audit che hai già mancato di standardizzare.

00:04:13.260 --> 00:04:13.500
I'm

00:04:13.500 --> 00:04:15.420
Se un tenant ha ripulito l'accesso

00:04:15.420 --> 00:04:16.620
e un altro ha cancellato i dati

00:04:16.620 --> 00:04:18.740
o se un tenant trasmette dati di audit utili

00:04:18.740 --> 00:04:21.240
mentre un altro ne cattura malapena abbastanza per le indagini

00:04:21.240 --> 00:04:23.300
il Copilot esporrà immediatamente quelle differenze.

00:04:23.920 --> 00:04:25.580
Non accade in teoria, accade attraverso l'uso.

00:04:26.540 --> 00:04:28.660
Se un tenant ha revisionato un accesso ampio a SharePoint

00:04:28.660 --> 00:04:30.340
e un altro ha dato per scondato che bastasse

00:04:30.340 --> 00:04:31.280
li ha troverà le lacune.

00:04:32.080 --> 00:04:32.820
E andando più a fondo

00:04:32.820 --> 00:04:34.420
ogni nuovo tenant moltiplica il problema

00:04:34.420 --> 00:04:35.840
non perché i tenants siano negativi

00:04:35.840 --> 00:04:37.940
ma perché le differenze non gestite si accumulano.

00:04:38.840 --> 00:04:40.700
Un nuovo team pilota aggiunge un'eccezione locale

00:04:40.700 --> 00:04:43.260
una fusione introduce un altro tenant con etichette diverse

00:04:43.260 --> 00:04:45.660
e un'amministratura regionale copia una vecchia base di riferimento.

00:04:46.020 --> 00:04:47.760
L'unità aziendale richiede un accesso più rapido

00:04:47.760 --> 00:04:49.480
e nessuna di queste scelte appare drammatica

00:04:49.480 --> 00:04:50.240
si è presa isolatamente.

00:04:50.920 --> 00:04:52.040
Mettili insieme nel corso dei mesi

00:04:52.040 --> 00:04:53.140
e otterrai una deriva delle policy

00:04:53.140 --> 00:04:54.420
e dei accessi e dell'implementazione.

00:04:54.900 --> 00:04:56.080
Il risultato è un team di governance

00:04:56.080 --> 00:04:57.840
che spende più tempo a conciliare le differenze

00:04:57.840 --> 00:04:58.680
che a prevenire i rischi.

00:04:59.240 --> 00:05:00.520
È qui che il controllo manuale fallisce.

00:05:00.940 --> 00:05:02.180
Sembra più sicuro perché gli esseri umani

00:05:02.180 --> 00:05:03.200
gestiscono le impostazioni

00:05:03.200 --> 00:05:04.400
ma in realtà ha scala di incoerenza

00:05:04.400 --> 00:05:05.500
perché ogni punto di contatto

00:05:05.500 --> 00:05:07.200
è un'occasione per i tenant di divergere.

00:05:07.720 --> 00:05:09.180
L'esito è un'implementazione più lenta

00:05:09.180 --> 00:05:10.280
dove si desidera velocità

00:05:10.280 --> 00:05:11.140
più sforzi di audit

00:05:11.140 --> 00:05:11.980
dove si vogliono prove

00:05:11.980 --> 00:05:13.580
e più rilaborazioni dove si vorrebbero stando.

00:05:13.920 --> 00:05:14.440
Peggio ancora

00:05:14.440 --> 00:05:15.760
crea un'esposizione nascosta

00:05:15.760 --> 00:05:17.340
dove la dirigenza si aspetta sicurezza.

00:05:17.720 --> 00:05:18.980
L'ho capito quando ho smesso di trattare

00:05:18.980 --> 00:05:20.840
la governance come un'attività di configurazione iniziale.

00:05:21.060 --> 00:05:21.360
Non lo è.

00:05:21.720 --> 00:05:22.880
Si comporta più come un decadimento.

00:05:23.180 --> 00:05:24.540
Se ripulisci le autorizzazioni una volta

00:05:24.540 --> 00:05:25.340
ma nessun controllo

00:05:25.340 --> 00:05:26.680
impedisce loro di tornare a divergere

00:05:26.680 --> 00:05:27.460
l'esposizione dei tuoi.

00:05:27.660 --> 00:05:29.400
Se definisci una tassonomia di etichette una volta

00:05:29.400 --> 00:05:31.000
ma i tenant la applicano in modo uniforme

00:05:31.000 --> 00:05:32.120
la base di riferimento si erode.

00:05:32.540 --> 00:05:33.680
Se approvi co-pilot a ondate

00:05:33.680 --> 00:05:35.440
senza verificare se i controlli sottostanti

00:05:35.440 --> 00:05:36.200
siano ancora validi

00:05:36.200 --> 00:05:37.520
non stai scalando in sicurezza.

00:05:37.980 --> 00:05:39.260
Ti stai solo espandendo più velocemente

00:05:39.260 --> 00:05:40.640
di quanto la tua governance riesca a gestire.

00:05:40.920 --> 00:05:42.040
Quindi la metrica che conta qui

00:05:42.040 --> 00:05:43.260
è la deriva degli accessi.

00:05:43.460 --> 00:05:44.600
Non solo se hai risolto qualcosa

00:05:44.600 --> 00:05:45.560
ma quanto velocemente

00:05:45.560 --> 00:05:47.280
le autorizzazioni si diffondono di nuovo

00:05:47.280 --> 00:05:48.180
dopo la correzione.

00:05:48.640 --> 00:05:49.600
Questo ti dice se il tuo modello

00:05:49.600 --> 00:05:50.660
sta reggendo o cedendo.

00:05:51.300 --> 00:05:52.880
Perché la governance non è un progetto che si conclude.

00:05:53.180 --> 00:05:54.040
Un problema di decadimento

00:05:54.040 --> 00:05:54.940
che gestisci continuamente.

00:05:55.380 --> 00:05:56.840
Quando la scala rompe il vecchio modello

00:05:56.840 --> 00:05:57.860
la maggior parte dei leader

00:05:57.860 --> 00:05:59.120
cerca la risposta più familiare

00:05:59.120 --> 00:05:59.600
l'identità.

00:06:00.260 --> 00:06:01.160
Presumano che se gli utenti

00:06:01.160 --> 00:06:02.700
possono spostarsi facilmente tra i tenant

00:06:02.700 --> 00:06:04.460
la governance si sposterà in qualche modo con lui.

00:06:04.740 --> 00:06:05.240
Non succederà.

00:06:05.540 --> 00:06:07.280
Perché l'identità non risolve la governance?

00:06:07.280 --> 00:06:09.600
Che molti programmi prendono una strada sbagliata

00:06:09.600 --> 00:06:11.580
perché l'identità sembra la risposta pulita?

00:06:12.600 --> 00:06:14.460
Se gli utenti possono autenticarsi tra i tenant

00:06:14.460 --> 00:06:15.400
se entra è connesso

00:06:15.400 --> 00:06:17.160
e se le impostazioni cross tenant sono attive

00:06:17.160 --> 00:06:19.300
i leader presumono che la parte difficile sia risolva.

00:06:20.000 --> 00:06:21.100
L'accesso sembra unificato

00:06:21.100 --> 00:06:22.260
l'accesso sembra unificato

00:06:22.260 --> 00:06:24.420
il diagramma dell'architettura appare ordinato

00:06:24.420 --> 00:06:25.840
ma la governance di Copilot

00:06:25.840 --> 00:06:28.200
non diventa unificata solo perché l'identità può spostarsi.

00:06:28.820 --> 00:06:29.660
Quell'assunzione fallisce

00:06:29.660 --> 00:06:31.180
nel momento in cui l'IA entra effettivamente in gioco.

00:06:31.560 --> 00:06:32.700
Copilot basa le risposte

00:06:32.700 --> 00:06:33.980
all'interno del contesto del tenant

00:06:33.980 --> 00:06:35.100
in cui viene eseguita la richiesta

00:06:35.100 --> 00:06:36.060
e le linee guida di Microsoft

00:06:36.060 --> 00:06:36.880
sono chiare su questo punto.

00:06:37.220 --> 00:06:39.000
Microsoft 365 Copilot

00:06:39.000 --> 00:06:40.820
opera all'interno del perimetro di sicurezza

00:06:40.820 --> 00:06:41.780
e conformità del tenant

00:06:41.780 --> 00:06:43.360
e rispetta le autorizzazioni dell'utente

00:06:43.360 --> 00:06:44.780
nello specifico contesto del tenant.

00:06:45.280 --> 00:06:46.900
Un utente può cambiare contesto come Gessy

00:06:46.900 --> 00:06:49.120
ma Copilot resta limitato a un solo tenant alla volta.

00:06:49.620 --> 00:06:50.380
Non unisce più tenant

00:06:50.380 --> 00:06:51.860
in un unico spazio di lavoro intelligente

00:06:51.860 --> 00:06:52.780
per una risposta singola.

00:06:53.420 --> 00:06:54.580
Quindi l'identità può spostarsi

00:06:54.580 --> 00:06:55.220
la governance no?

00:06:55.660 --> 00:06:57.140
E una volta separati questi due aspetti

00:06:57.140 --> 00:06:58.480
gran parte del linguaggio dirigenziale

00:06:58.480 --> 00:06:59.900
inizia a suonare pericolosamente vago.

00:07:00.580 --> 00:07:01.380
Tenant connessi?

00:07:02.140 --> 00:07:03.020
Identità condivisa?

00:07:03.420 --> 00:07:04.320
Esperienza unificata?

00:07:04.320 --> 00:07:07.560
Queste frasi possono essere corrette

00:07:07.560 --> 00:07:08.460
per la collaborazione

00:07:08.460 --> 00:07:09.220
ma non significano

00:07:09.220 --> 00:07:10.400
che l'applicazione delle policy

00:07:10.400 --> 00:07:11.140
il data grounding

00:07:11.140 --> 00:07:11.860
il logging

00:07:11.860 --> 00:07:12.940
e la convalida dei controlli

00:07:12.940 --> 00:07:14.240
funzionino come un unico sistema.

00:07:15.180 --> 00:07:16.640
Il divario diventa ancora più evidente

00:07:16.640 --> 00:07:18.060
osservando la modalità multi-tenant

00:07:18.060 --> 00:07:18.720
di Copilot Studio

00:07:18.720 --> 00:07:19.600
perché l'anteprima racconta

00:07:19.600 --> 00:07:20.700
una storia molto specifica.

00:07:21.320 --> 00:07:22.940
Sì, l'uso multi-tenant esiste

00:07:22.940 --> 00:07:24.880
e un agente ospitato in un tenant

00:07:24.880 --> 00:07:26.080
può essere usato da un altro

00:07:26.080 --> 00:07:27.860
ma l'autenticazione dell'utente finale

00:07:27.860 --> 00:07:28.820
in modalità multi-tenant

00:07:28.820 --> 00:07:30.140
non è ancora supportata nell'anteprima.

00:07:30.140 --> 00:07:31.500
gli utenti guest non sono supportati

00:07:31.500 --> 00:07:32.640
i connettori personalizzati

00:07:32.640 --> 00:07:33.160
non sono supportati

00:07:33.160 --> 00:07:34.280
i connettori standard

00:07:34.280 --> 00:07:35.740
i graph e Microsoft 365

00:07:35.740 --> 00:07:36.920
non sono supportati

00:07:36.920 --> 00:07:38.320
multi-GA non è supportato

00:07:38.320 --> 00:07:39.960
diverse funzionalità di analisi

00:07:39.960 --> 00:07:40.820
non sono disponibili

00:07:40.820 --> 00:07:42.020
anche le trascrizioni

00:07:42.020 --> 00:07:42.620
delle conversazioni

00:07:42.620 --> 00:07:43.780
sono disattivate in quella modalità

00:07:43.780 --> 00:07:45.420
non si tratta di una solida struttura

00:07:45.420 --> 00:07:46.200
di governance cross-tenant

00:07:46.200 --> 00:07:47.380
è un'anteprima limitata

00:07:47.380 --> 00:07:48.180
con vincoli chiari

00:07:48.180 --> 00:07:49.500
questi limiti contano

00:07:49.500 --> 00:07:50.640
perché smientiscono la versione

00:07:50.640 --> 00:07:51.540
che molti team dirigenziari

00:07:51.540 --> 00:07:52.140
si raccontano

00:07:52.140 --> 00:07:53.400
sentono multi-tenant

00:07:53.400 --> 00:07:54.660
e presumono una motorità operativa

00:07:54.660 --> 00:07:55.740
i loro architetti

00:07:55.740 --> 00:07:56.780
sentono cross-tenant

00:07:56.780 --> 00:07:57.660
e presumono una simmetria

00:07:57.660 --> 00:07:58.160
nelle policy

00:07:58.160 --> 00:07:59.580
i loro team di controllo

00:07:59.580 --> 00:08:00.540
sentono stesso fornitore

00:08:00.540 --> 00:08:01.640
e presumono una coerenza di out

00:08:01.640 --> 00:08:03.240
poi inizia a roll out

00:08:03.240 --> 00:08:04.800
e si scoprono comportamenti diversi

00:08:04.800 --> 00:08:05.600
segnali mancanti

00:08:05.600 --> 00:08:06.420
e lacune evidenti

00:08:06.420 --> 00:08:07.920
in autenticazione e analisi

00:08:07.920 --> 00:08:09.520
immaginiamo secondo caso

00:08:09.520 --> 00:08:10.820
un'azienda globale

00:08:10.820 --> 00:08:12.200
imposta relazioni cross-tenant

00:08:12.200 --> 00:08:12.740
e presume

00:08:12.740 --> 00:08:13.700
che l'esperienza utente

00:08:13.700 --> 00:08:14.700
si estenderà naturalmente

00:08:14.700 --> 00:08:15.500
all'uso di copilot

00:08:15.500 --> 00:08:17.880
l'aspettativa sembra ragionevole

00:08:17.880 --> 00:08:18.620
includendo fiducia

00:08:18.620 --> 00:08:19.640
nella directory condivisa

00:08:19.640 --> 00:08:20.280
accesso fluido

00:08:20.280 --> 00:08:21.780
e modelli di identità comuni

00:08:21.780 --> 00:08:22.700
ma quando i team testano

00:08:22.700 --> 00:08:23.460
gli scenari reali

00:08:23.460 --> 00:08:24.540
copilot degli agenti

00:08:24.540 --> 00:08:25.620
il comportamento disomogene

00:08:25.620 --> 00:08:26.720
alcuni dati appaiono

00:08:26.720 --> 00:08:27.740
solo in contesti commutati

00:08:27.740 --> 00:08:29.120
alcuni connettori previsti

00:08:29.120 --> 00:08:29.800
non sono disponibili

00:08:29.800 --> 00:08:31.180
alcune aspettative di audit

00:08:31.180 --> 00:08:31.820
non corrispondono

00:08:31.820 --> 00:08:32.420
a ciò che le funzioni

00:08:32.420 --> 00:08:32.880
in anteprima

00:08:32.880 --> 00:08:33.700
espongono realmente

00:08:33.700 --> 00:08:35.400
la dirigenza continua

00:08:35.400 --> 00:08:36.300
a sentire connesso

00:08:36.300 --> 00:08:37.160
mentre il team di controllo

00:08:37.160 --> 00:08:38.020
inizia a trovare eccezioni

00:08:38.020 --> 00:08:39.460
non è un caso limite tecnico

00:08:39.460 --> 00:08:39.880
è un errore

00:08:39.880 --> 00:08:40.680
di interpretazione della go

00:08:40.680 --> 00:08:41.540
perché i revisori

00:08:41.540 --> 00:08:42.180
non controllano

00:08:42.180 --> 00:08:42.920
la vostra narrazione

00:08:42.920 --> 00:08:43.760
architetturale contro

00:08:43.760 --> 00:08:44.860
chiedono dove sono stati

00:08:44.860 --> 00:08:45.520
eseguiti i prompt

00:08:45.520 --> 00:08:46.460
quale tenant ha applicato

00:08:46.460 --> 00:08:46.920
la policy

00:08:46.920 --> 00:08:47.920
quali log esistono

00:08:47.920 --> 00:08:48.880
e se i vostri controlli

00:08:48.880 --> 00:08:50.000
fossero realmente comparabili

00:08:50.000 --> 00:08:50.540
tra gli ambienti

00:08:50.540 --> 00:08:51.600
descritti come collegati

00:08:51.600 --> 00:08:53.080
se il vostro modello operativo

00:08:53.080 --> 00:08:53.940
ha trattato l'identità

00:08:53.940 --> 00:08:54.620
come governance

00:08:54.620 --> 00:08:55.880
non avrete una risposta chiara

00:08:55.880 --> 00:08:57.320
quindi se dovete ricordare

00:08:57.320 --> 00:08:57.820
una sola cosa

00:08:57.820 --> 00:08:58.320
che sia questa

00:08:58.320 --> 00:08:59.820
l'identità cross tenant

00:08:59.820 --> 00:09:01.280
non è intelligenza cross tenant

00:09:01.280 --> 00:09:02.620
l'identità aiuta gli utenti

00:09:02.620 --> 00:09:03.020
ad accettare

00:09:03.020 --> 00:09:03.740
non ti dice

00:09:03.740 --> 00:09:04.460
se il comportamento

00:09:04.460 --> 00:09:04.980
di copilot

00:09:04.980 --> 00:09:06.180
è governato in modo coerente

00:09:06.180 --> 00:09:07.200
è monitorato correttamente

00:09:07.200 --> 00:09:07.560
o sicuro

00:09:07.560 --> 00:09:08.500
da scalare in tutti i luoghi

00:09:08.500 --> 00:09:09.040
che la tua azienda

00:09:09.040 --> 00:09:10.240
ora definisce un unico ambiente

00:09:10.240 --> 00:09:11.800
e una volta che questo diventa chiaro

00:09:11.800 --> 00:09:12.480
la risposta non può essere

00:09:12.480 --> 00:09:13.340
aggiungere più connessioni tra

00:09:13.340 --> 00:09:14.560
deve essere l'architettura

00:09:14.560 --> 00:09:16.120
il modello di governance

00:09:16.120 --> 00:09:16.900
che funziona davvero

00:09:16.900 --> 00:09:17.600
hub e spoke

00:09:17.600 --> 00:09:18.940
quindi che aspetta

00:09:18.940 --> 00:09:19.960
un vero modello di governance

00:09:19.960 --> 00:09:20.880
quando la tua piattaforma

00:09:20.880 --> 00:09:21.500
è frammentata

00:09:21.500 --> 00:09:22.760
l'identità è solo parziale

00:09:22.760 --> 00:09:23.560
e i confini dei tenant

00:09:23.560 --> 00:09:24.560
contano ancora davvero

00:09:24.560 --> 00:09:26.220
all'aspetto di un sistema hub

00:09:26.220 --> 00:09:26.520
spoke

00:09:26.520 --> 00:09:27.740
non lo suggerisco

00:09:27.740 --> 00:09:28.260
perché il diagramma

00:09:28.260 --> 00:09:29.300
appare pulito su una slide

00:09:29.300 --> 00:09:30.640
ma perché corrisponde

00:09:30.640 --> 00:09:31.400
realmente alle caotiche

00:09:31.400 --> 00:09:32.220
condizioni operative

00:09:32.220 --> 00:09:33.160
che stai affrontando ora

00:09:33.160 --> 00:09:34.920
ti serve un posto centrale

00:09:34.920 --> 00:09:35.980
dove le decisioni di governance

00:09:35.980 --> 00:09:36.920
siano progettate

00:09:36.920 --> 00:09:38.000
misurate e applicate

00:09:38.000 --> 00:09:38.840
come un unico sistema

00:09:38.840 --> 00:09:40.440
poi ti servono team locali

00:09:40.440 --> 00:09:40.880
per i tenant

00:09:40.880 --> 00:09:41.960
che seguono quelle decisioni

00:09:41.960 --> 00:09:42.980
questi team locali

00:09:42.980 --> 00:09:43.600
devono lavorare

00:09:43.600 --> 00:09:44.660
entro i propri confini

00:09:44.660 --> 00:09:45.420
senza inventare

00:09:45.420 --> 00:09:46.120
la propria versione

00:09:46.120 --> 00:09:46.560
delle regole

00:09:46.560 --> 00:09:47.400
ogni volta che sentono

00:09:47.400 --> 00:09:48.340
un po' di pressione

00:09:48.340 --> 00:09:50.000
dobbiamo partire dal lab

00:09:50.000 --> 00:09:51.260
lab non è un portale

00:09:51.260 --> 00:09:52.020
di amministrazione

00:09:52.020 --> 00:09:53.220
non è una dashboard brillante

00:09:53.220 --> 00:09:53.800
e sicuramente

00:09:53.800 --> 00:09:54.920
non è un eroico team centrale

00:09:54.920 --> 00:09:56.020
che entra in ogni singolo tenant

00:09:56.020 --> 00:09:57.340
per pulire i file manualmente

00:09:57.340 --> 00:09:58.620
per pulire i file manualmente

00:09:58.620 --> 00:09:59.200
al contrario

00:09:59.200 --> 00:10:00.160
lab funge da autorità

00:10:00.160 --> 00:10:01.300
di governance definitiva

00:10:01.300 --> 00:10:02.180
questo gruppo

00:10:02.180 --> 00:10:03.040
possiede la progettazione

00:10:03.040 --> 00:10:03.560
delle policy

00:10:03.560 --> 00:10:04.460
le linee di guida di audit

00:10:04.460 --> 00:10:05.520
gli standard delle etichette

00:10:05.520 --> 00:10:06.720
e i criteri di implementazione

00:10:06.720 --> 00:10:07.920
sono loro a decidere

00:10:07.920 --> 00:10:08.460
cosa significa

00:10:08.460 --> 00:10:09.400
realmente essere pronti

00:10:09.400 --> 00:10:09.980
per co-pilot

00:10:09.980 --> 00:10:10.920
quali prove valgano

00:10:10.920 --> 00:10:11.700
come dimostrazione

00:10:11.700 --> 00:10:12.640
e quanto velocemente

00:10:12.640 --> 00:10:13.300
debba essere colmata

00:10:13.300 --> 00:10:14.040
una falla di sicurezza

00:10:14.040 --> 00:10:15.180
questo cambiamento

00:10:15.180 --> 00:10:16.480
trasformerli della conversazione

00:10:16.480 --> 00:10:18.140
grazie a questa struttura

00:10:18.140 --> 00:10:19.200
globale smette di essere

00:10:19.200 --> 00:10:20.660
un termine per una schermata magica

00:10:20.660 --> 00:10:21.720
e inizia a significare

00:10:21.720 --> 00:10:22.340
un unico sistema

00:10:22.340 --> 00:10:23.400
di governance unificato

00:10:23.400 --> 00:10:24.660
ottieni uno standard

00:10:24.660 --> 00:10:25.560
per i controlli di preview

00:10:25.560 --> 00:10:26.700
uno standard per come acquisire

00:10:26.700 --> 00:10:27.180
gli audit

00:10:27.180 --> 00:10:28.080
e uno standard

00:10:28.080 --> 00:10:29.440
per le tue etichette di sensibilità

00:10:29.440 --> 00:10:31.000
c'è un unico parametro chiaro

00:10:31.000 --> 00:10:31.860
per ciò che deve essere vero

00:10:31.860 --> 00:10:33.020
prima che un tenant specifico

00:10:33.020 --> 00:10:33.580
sia consentito

00:10:33.580 --> 00:10:34.220
estendere l'accesso

00:10:34.220 --> 00:10:35.160
a co-pilot più utenti

00:10:35.160 --> 00:10:36.280
poi ti servono gli spoke

00:10:36.280 --> 00:10:37.620
gli spoke sono i tuoi team

00:10:37.620 --> 00:10:38.420
locali di esecuzione

00:10:38.420 --> 00:10:38.860
dei tenant

00:10:38.860 --> 00:10:39.760
che prendono quella base

00:10:39.760 --> 00:10:40.340
e la applicano

00:10:40.340 --> 00:10:41.680
al loro ambiente specifico

00:10:41.680 --> 00:10:42.520
sono loro a gestire

00:10:42.520 --> 00:10:43.260
la risoluzione

00:10:43.260 --> 00:10:44.120
con validare i log

00:10:44.120 --> 00:10:45.560
e rivedere i permessi

00:10:45.560 --> 00:10:46.220
di accesso estesi

00:10:46.220 --> 00:10:47.400
tuttavia svolgono

00:10:47.400 --> 00:10:48.100
tutto quel lavoro

00:10:48.100 --> 00:10:49.320
all'interno di uno spazio

00:10:49.320 --> 00:10:50.640
progettuale molto limitato

00:10:50.640 --> 00:10:51.660
piuttosto che non liberi tutti

00:10:51.660 --> 00:10:52.740
se un team locale

00:10:52.740 --> 00:10:53.920
deve discostarsi dal piano

00:10:53.920 --> 00:10:55.040
esiste un percorso formale

00:10:55.040 --> 00:10:56.040
per le eccezioni

00:10:56.040 --> 00:10:56.980
se vogliono muoversi

00:10:56.980 --> 00:10:57.640
più velocemente

00:10:57.640 --> 00:10:58.560
devono comunque soddisfare

00:10:58.560 --> 00:10:59.600
prima i controlli condivisi

00:10:59.600 --> 00:11:01.340
quando emergono differenze

00:11:01.340 --> 00:11:02.220
regionali e legali

00:11:02.220 --> 00:11:02.820
tali questioni

00:11:02.820 --> 00:11:03.620
vengono documentate

00:11:03.620 --> 00:11:04.580
approvate invece di essere

00:11:04.580 --> 00:11:05.620
silenziosamente assorbite

00:11:05.620 --> 00:11:06.600
in qualche soluzione locale

00:11:06.600 --> 00:11:07.820
di cui nessuno sa nulla

00:11:07.820 --> 00:11:08.780
questa struttura

00:11:08.780 --> 00:11:09.480
è fondamentale

00:11:09.480 --> 00:11:10.080
perché i modelli

00:11:10.080 --> 00:11:11.260
completamente centralizzati

00:11:11.260 --> 00:11:12.260
solitamente si bloccano

00:11:12.260 --> 00:11:13.020
sui dettagli locali

00:11:13.020 --> 00:11:14.100
mentre quelli puramente locali

00:11:14.100 --> 00:11:14.940
scivolano quasi subito

00:11:14.940 --> 00:11:15.740
in coerenza totale

00:11:15.740 --> 00:11:17.120
il modello hub and spoke

00:11:17.120 --> 00:11:17.680
evita entrambi

00:11:17.680 --> 00:11:18.540
questi schemi di fallimento

00:11:18.540 --> 00:11:19.780
l'hub garantisce

00:11:19.780 --> 00:11:20.800
la coerenza necessaria

00:11:20.800 --> 00:11:21.620
mentre gli spoke

00:11:21.620 --> 00:11:22.820
offrono velocità di esecuzione

00:11:22.820 --> 00:11:24.160
dove il lavoro avviene concretamente

00:11:24.160 --> 00:11:25.480
prendiamolo concreto

00:11:25.480 --> 00:11:26.260
nel hub

00:11:26.260 --> 00:11:27.400
definisci il set minimo

00:11:27.400 --> 00:11:28.140
di controlli per view

00:11:28.140 --> 00:11:28.860
che ogni talento

00:11:28.860 --> 00:11:29.240
deve eseguire

00:11:29.240 --> 00:11:29.920
prima che copilot

00:11:29.920 --> 00:11:30.880
possa espandersi

00:11:30.880 --> 00:11:32.500
definisci esattamente

00:11:32.500 --> 00:11:33.320
quali eventi di audio

00:11:33.320 --> 00:11:34.020
ti aspetti di vedere

00:11:34.020 --> 00:11:34.980
e con quale frequenza

00:11:34.980 --> 00:11:35.640
li esaminerai

00:11:35.640 --> 00:11:36.940
inoltre

00:11:36.940 --> 00:11:38.200
crei una tassonomia di etichette

00:11:38.200 --> 00:11:39.760
condivisa per i contenuti sensibili

00:11:39.760 --> 00:11:40.900
affinché un tag riservato

00:11:40.900 --> 00:11:42.280
non significhi 5 cose diverse

00:11:42.280 --> 00:11:43.540
in 5 tenant diversi

00:11:43.540 --> 00:11:46.000
imposti il ritmo delle revisioni

00:11:46.000 --> 00:11:47.020
magari mensile

00:11:47.020 --> 00:11:48.580
per la postura di sicurezza generale

00:11:48.580 --> 00:11:49.300
e più frequente

00:11:49.300 --> 00:11:49.940
nelle aree in cui

00:11:49.940 --> 00:11:50.880
il rollout è attivo

00:11:50.880 --> 00:11:52.780
nello spoke

00:11:52.780 --> 00:11:53.480
il tuo team adatta

00:11:53.480 --> 00:11:54.780
quelli standard di alto livello

00:11:54.780 --> 00:11:56.680
alla realtà di quel tenant specifico

00:11:56.680 --> 00:11:57.660
individuano quali siti

00:11:57.660 --> 00:11:58.400
hanno ancora un accesso

00:11:58.400 --> 00:11:58.940
troppo esteso

00:11:58.940 --> 00:11:59.880
e quali unità aziendali

00:11:59.880 --> 00:12:00.480
sono in ritardo

00:12:00.480 --> 00:12:01.180
con l'etichettatura

00:12:01.180 --> 00:12:02.640
verificano se l'audit

00:12:02.640 --> 00:12:03.500
è effettivamente attivo

00:12:03.500 --> 00:12:04.380
e se i record corretti

00:12:04.380 --> 00:12:05.600
sono visibili al team di sicurezza

00:12:05.600 --> 00:12:07.220
cercano amministratori locali

00:12:07.220 --> 00:12:08.220
che potrebbero aver introdotto

00:12:08.220 --> 00:12:09.800
eccezioni mai revisionate ufficialmente

00:12:09.800 --> 00:12:10.940
e decidono se un gruppo pilota

00:12:10.940 --> 00:12:12.000
può espandersi in sicurezza

00:12:12.000 --> 00:12:13.220
o se è necessario fermarsi prima

00:12:13.220 --> 00:12:15.000
per risolvere i problemi

00:12:15.000 --> 00:12:16.020
ed ecco la regola ferrea

00:12:16.020 --> 00:12:16.820
perché senza regole

00:12:16.820 --> 00:12:17.380
questo modello

00:12:17.380 --> 00:12:18.320
è solo un suggerimento

00:12:18.320 --> 00:12:19.760
e non una vera governance

00:12:19.760 --> 00:12:21.640
nessun rollout di copilot

00:12:21.640 --> 00:12:22.500
avviene in alcun tenant

00:12:22.500 --> 00:12:23.960
senza log di audit convalidati

00:12:23.960 --> 00:12:25.120
una scansione di condivisione

00:12:25.120 --> 00:12:25.960
eccessiva completata

00:12:25.960 --> 00:12:26.660
è una base minima

00:12:26.660 --> 00:12:27.640
di copertura delle etichette

00:12:27.640 --> 00:12:29.580
non sto parlando di cose pianificate

00:12:29.580 --> 00:12:30.600
o discusse solo in parte

00:12:30.600 --> 00:12:32.000
devono essere convalidati

00:12:32.000 --> 00:12:33.360
se un tenant non può dimostrare

00:12:33.360 --> 00:12:34.220
che queste tre condizioni

00:12:34.220 --> 00:12:35.700
sono soddisfatte e i rollout si interrompono

00:12:35.700 --> 00:12:37.200
potrebbe sembrare severo

00:12:37.200 --> 00:12:38.040
finché non lo confronti

00:12:38.040 --> 00:12:38.740
con l'enorme costo

00:12:38.740 --> 00:12:39.640
di rimediare al disordine

00:12:39.640 --> 00:12:40.260
quando gli utenti

00:12:40.260 --> 00:12:41.760
iniziano a trovare contenuti sensibili

00:12:41.760 --> 00:12:43.040
che non intendevi esplorare tramiteria

00:12:43.040 --> 00:12:44.460
vista in quest'ottica

00:12:44.460 --> 00:12:46.280
queste regole sono solo semplice buonsenso

00:12:46.280 --> 00:12:47.440
un altro motivo

00:12:47.440 --> 00:12:48.820
per cui questo modello funziona così bene

00:12:48.820 --> 00:12:49.820
è la tempistica

00:12:49.820 --> 00:12:50.860
più aspetti a impostarlo

00:12:50.860 --> 00:12:52.020
più debito di pulizia

00:12:52.020 --> 00:12:52.980
creerai per il futuro

00:12:52.980 --> 00:12:54.800
ogni tenant che parte

00:12:54.800 --> 00:12:55.540
prima di aver raggiunto

00:12:55.540 --> 00:12:56.380
la base di riferimento

00:12:56.380 --> 00:12:57.480
diventa un enorme arretrato

00:12:57.480 --> 00:12:58.060
di eccezioni

00:12:58.060 --> 00:12:58.740
e prove mancanti

00:12:58.740 --> 00:13:00.460
che il tuo team dovrà alla fine districare

00:13:00.460 --> 00:13:02.460
i leader spesso trattano

00:13:04.220 --> 00:13:05.140
il completamento dell'adozione

00:13:05.140 --> 00:13:06.560
ma in un mondo co-pilot multi-tenant

00:13:06.560 --> 00:13:08.300
questa sequenza è completamente errata

00:13:08.300 --> 00:13:10.100
la governance deve guidare il rollout

00:13:10.100 --> 00:13:11.420
altrimenti il rollout crea più debito

00:13:11.420 --> 00:13:12.080
di quanto i tuoi team

00:13:12.080 --> 00:13:13.240
possono mai sperare di gestire

00:13:13.240 --> 00:13:14.880
se stai guidando questo processo

00:13:14.880 --> 00:13:15.620
a livello aziendale

00:13:15.620 --> 00:13:16.680
la tua prossima mossa è molto più

00:13:16.680 --> 00:13:17.720
crea subito l'hub

00:13:17.720 --> 00:13:18.680
e rifinisci oggi stesso

00:13:18.680 --> 00:13:19.380
con la linea di base

00:13:19.380 --> 00:13:20.760
assegni i tuoi spot

00:13:20.760 --> 00:13:21.600
che metti immediatamente

00:13:21.600 --> 00:13:23.040
per iscritto il processo di gestione

00:13:23.040 --> 00:13:23.580
dell'eccezione

00:13:23.580 --> 00:13:25.080
devi fare in modo che

00:13:25.080 --> 00:13:25.780
globale

00:13:25.780 --> 00:13:27.080
significhi che le tue decisioni

00:13:27.080 --> 00:13:28.000
i tuoi passaggi di rollout

00:13:28.000 --> 00:13:29.640
funzionino come un unico sistema

00:13:29.640 --> 00:13:31.460
anche quando i tenant stessi non lo fanno

00:13:31.460 --> 00:13:33.180
un modello conta solo se cambia effettivamente

00:13:33.180 --> 00:13:34.640
ciò che verrà applicato domani mattina

00:13:34.640 --> 00:13:36.680
cosa dovrebbero misurare i leader

00:13:36.680 --> 00:13:37.340
prima di scalare

00:13:37.340 --> 00:13:39.100
un modello di governance regge solo

00:13:39.100 --> 00:13:41.020
se produce misurazioni condivise da tutti

00:13:41.020 --> 00:13:42.940
altrimenti ogni tenant

00:13:42.940 --> 00:13:44.180
dichiarerà di fare progressi

00:13:44.180 --> 00:13:44.920
nel proprio linguaggio

00:13:44.920 --> 00:13:46.680
e la leadership riceverà aggiornamenti

00:13:46.680 --> 00:13:48.460
senza avere alcun controllo reale

00:13:48.460 --> 00:13:50.320
prima di espandere ulteriormente i copilot

00:13:50.320 --> 00:13:51.720
ti serve un piccolo set di metriche

00:13:51.720 --> 00:13:52.940
che ti indichi se l'architettura

00:13:52.940 --> 00:13:54.280
si comporta come pensi

00:13:54.280 --> 00:13:56.820
i livelli di attività non ti diranno la verità

00:13:56.820 --> 00:13:57.760
e i numeri di adozione

00:13:57.760 --> 00:13:59.040
non ti mostreranno di certo i rischi

00:13:59.040 --> 00:14:00.320
dovresti iniziare riducendo

00:14:00.320 --> 00:14:01.200
la condivisione eccessiva

00:14:01.200 --> 00:14:02.980
questo resta uno dei segnali più evidenti

00:14:02.980 --> 00:14:04.940
che il tuo ambiente sta diventando davvero più sicuro

00:14:04.940 --> 00:14:05.400
per l'IA

00:14:05.400 --> 00:14:08.320
devi esaminare gruppi di accesso estesi

00:14:08.320 --> 00:14:10.120
city sharepoint aperti e vecchi permessi

00:14:10.120 --> 00:14:11.260
che concedono molto più accesso

00:14:11.260 --> 00:14:12.380
di quanto l'azienda richieda

00:14:12.380 --> 00:14:15.120
l'obiettivo qui non è raggiungere un numero perfetto

00:14:15.120 --> 00:14:16.440
ma dimostrare che la tua esposizione

00:14:16.440 --> 00:14:18.300
sta diminuendo prima che la portata di copilot home

00:14:18.300 --> 00:14:20.720
se quelle due linee si muovono in direzioni opposte

00:14:20.720 --> 00:14:22.200
ti stai espandendo molto più velocemente

00:14:22.200 --> 00:14:24.080
di quanto tu stai risolvendo i problemi sottostanti

00:14:24.080 --> 00:14:25.900
la seconda metrica di cui hai bisogno

00:14:25.900 --> 00:14:27.080
è una copertura di osservabilità

00:14:27.080 --> 00:14:29.220
riesci davvero a vedere cosa sta facendo copilot

00:14:29.220 --> 00:14:31.600
in tutti i tuoi tenant in modo da sopportare un'indagine reale

00:14:31.600 --> 00:14:34.160
gran parte della ricerca indica Microsoft Preview

00:14:34.160 --> 00:14:35.920
come il luogo principale in cui vengono archiviati

00:14:35.920 --> 00:14:38.020
i record fondamentali come le interazioni di copilot

00:14:38.020 --> 00:14:40.020
ma ciò presuppone che l'auditing sia attivo ovunque

00:14:40.020 --> 00:14:42.460
la copertura non è qualcosa che puoi dare per scontato

00:14:42.460 --> 00:14:44.480
devi sapere esattamente quali tenant

00:14:44.480 --> 00:14:45.880
hanno l'ingestione dei log attiva

00:14:45.880 --> 00:14:48.220
e quali ti lasciano ancora una visibilità parziale

00:14:48.780 --> 00:14:49.960
se non hai log

00:14:49.960 --> 00:14:52.020
non hai governance e non hai responsabilità

00:14:52.020 --> 00:14:54.120
sembra crudo perché deve esserlo

00:14:54.120 --> 00:14:56.260
se un tenant non può fornire prove utilizzabili

00:14:56.260 --> 00:14:57.060
di ciò che sta accadendo

00:14:57.060 --> 00:14:59.040
il tenant non è pronto per scalare in sicurezza

00:14:59.040 --> 00:15:01.380
non puoi governare ciò che non ti ha permesso ispezionare

00:15:01.380 --> 00:15:03.280
e di certo non sarai in grado di difendere le tue azioni

00:15:03.280 --> 00:15:04.740
se qualcosa dovesse andare storto in seguito

00:15:04.740 --> 00:15:06.880
la terza metrica è il tempo di applicazione delle policy

00:15:06.880 --> 00:15:07.520
su tutti i tenant

00:15:07.520 --> 00:15:09.340
che la readership scopre se il modello

00:15:09.340 --> 00:15:11.220
abbanspoke è reale o solo decorativo

00:15:11.220 --> 00:15:12.580
o solo decorativo

00:15:12.580 --> 00:15:14.640
una decisione centrale non significa nulla

00:15:14.640 --> 00:15:16.200
se un tenant la applica questa settimana

00:15:16.200 --> 00:15:18.020
mentre un altro aspetta un mese per pensarci

00:15:18.020 --> 00:15:19.800
dovresti misurare il tempo

00:15:19.800 --> 00:15:21.420
che intercorre dall'approvazione di una policy

00:15:21.420 --> 00:15:23.560
alla sua effettiva applicazione in ogni singolo tenant

00:15:23.560 --> 00:15:26.240
non parlo del tempo necessario per annunciarlo o documentarlo

00:15:26.240 --> 00:15:28.280
ma del tempo fino a quando non è effettivamente operativo

00:15:28.280 --> 00:15:30.300
per un programma di IA che si evolve così rapidamente

00:15:30.300 --> 00:15:32.360
quel tipo di ritardo è solo un altro modo di chiamare il rischio

00:15:32.360 --> 00:15:34.520
un obiettivo pratico per la maggior parte delle organizzazioni

00:15:34.520 --> 00:15:36.460
è stare sotto le 72 ore per le modifiche standard

00:15:36.460 --> 00:15:39.180
se il tempo del vostro ciclo è molto più lungo

00:15:39.180 --> 00:15:40.480
non avete ancora un modello scalabile

00:15:40.480 --> 00:15:42.940
avete solo un problema di coordinamento che deve essere risolto

00:15:42.940 --> 00:15:45.560
successivamente dovete esaminare il rapporto di coperture Z

00:15:45.560 --> 00:15:47.380
non lasciate che diventi una metrica di vanità

00:15:47.380 --> 00:15:48.820
dove un tenant raggiunge numeri alti

00:15:48.820 --> 00:15:49.980
mentre gli altri restano indietro

00:15:49.980 --> 00:15:52.340
ciò che conta davvero è se i vostri contenuti sensibili

00:15:52.340 --> 00:15:54.040
siano etichettati in modo abbastanza coerente

00:15:54.040 --> 00:15:56.620
ma non far basare il comportamento di copilot su ipotesi dell'utente

00:15:56.620 --> 00:15:58.440
non cercate la perfezione qui

00:15:58.440 --> 00:16:00.380
ma cercate un livello di controllo paragonabile

00:16:00.380 --> 00:16:02.000
in ogni tenant dell'organizzazione

00:16:02.000 --> 00:16:05.320
infine dovete monitorare il tasso di deriva degli accessi

00:16:05.320 --> 00:16:07.200
questa metrica vi dice se i vostri sforzi di pulizia

00:16:07.200 --> 00:16:08.660
stanno effettivamente resistendo nel tempo

00:16:08.660 --> 00:16:10.520
dopo aver terminato un progetto di rimedio

00:16:10.520 --> 00:16:12.860
quanto velocemente quelle autorizzazioni iniziano a diffondersi di

00:16:12.860 --> 00:16:15.700
quanto spesso quei gruppi estesi si insinuano nuovamente nel sistema

00:16:15.700 --> 00:16:17.420
molti team se ne accorgono troppo tardi

00:16:17.420 --> 00:16:18.940
perché hanno misurato la correzione una sola volta

00:16:18.940 --> 00:16:20.060
dando per scontato che il prodotto sia

00:16:20.060 --> 00:16:20.680
non lo era

00:16:20.680 --> 00:16:23.720
l'unica metrica che conta è quanto velocemente il sistema inizia a cedere

00:16:23.720 --> 00:16:25.240
una volta che smettete di sorvegliarlo

00:16:25.240 --> 00:16:26.720
questo è il vostro ruscotto operativo

00:16:26.720 --> 00:16:29.080
dovete monitorare la riduzione della condivisione eccessiva

00:16:29.080 --> 00:16:30.200
la copertura dell'osservabilità

00:16:30.200 --> 00:16:31.340
il tempo di applicazione delle policy

00:16:31.340 --> 00:16:32.580
la copertura delle etichette in etichette

00:16:32.580 --> 00:16:33.420
nella deriva degli accessi

00:16:33.420 --> 00:16:36.680
il ritmo della vostra reportistica è importante tanto quanto i numeri stessi

00:16:36.680 --> 00:16:38.580
l'hub dovrebbe gestire il ruscotto esecutivo

00:16:38.580 --> 00:16:41.360
perché la dirigenza ha bisogno di una visione unica dell'intera postura

00:16:41.360 --> 00:16:44.020
nel frattempo gli spook dovrebbero occuparsi della rimedio

00:16:44.020 --> 00:16:46.960
perché il lavoro effettivo deve avvenire dove risiede il confine del tenant

00:16:46.960 --> 00:16:49.760
un team legge il sistema e l'altro team lo corregge

00:16:49.760 --> 00:16:53.200
dovete monitorare questi numeri prima di espandervi non a posteriori

00:16:53.200 --> 00:16:55.800
il rischio non aspetta la vostra prossima riunione o il vostro workshop di cover

00:16:55.800 --> 00:16:59.260
è già attivo in ogni tenant in cui copilot può trovare esattamente ciò

00:16:59.260 --> 00:17:01.420
che i vostri attuali controlli gli consentono ancora di vedere

00:17:01.420 --> 00:17:03.420
i due modelli che i leader continuano a trascurare

00:17:03.420 --> 00:17:05.800
continua a vedere i due modelli specifici sul campo

00:17:05.800 --> 00:17:08.980
ed entrambi accadono perché i leader trattano copilot come un lancio di software

00:17:08.980 --> 00:17:10.800
invece che come un evento di controllo importante

00:17:10.800 --> 00:17:13.620
il primo modello inizia quando un'organizzazione lancia copilot

00:17:13.620 --> 00:17:17.320
prima di definire una reale base di riferimento di preview o di rivedere i propri accessi sharepoint

00:17:17.320 --> 00:17:19.640
al primo giorno il lancio sembra perfetto

00:17:19.640 --> 00:17:22.160
le licenze sono assegnate, gli utenti sono entusiasti

00:17:22.160 --> 00:17:24.340
e la comunicazione interna punta tutta sulla produttività

00:17:24.340 --> 00:17:27.400
ma poi i normali prompt iniziano a far emergere materiale

00:17:27.400 --> 00:17:30.980
che era tecnicamente accessibile da sempre ma praticamente invisibile al dipendente medio

00:17:30.980 --> 00:17:35.080
prima dell'IA nessuno passava la giornata a cliccare su vecchi siti

00:17:35.080 --> 00:17:38.500
cartelle obsolete o permessi ereditati per trovare cose che non avrebbe dovuto vedere

00:17:38.500 --> 00:17:40.100
ma ora non devono più farlo

00:17:40.100 --> 00:17:43.700
un utente pone una domanda di base, riceve un riepilogo e appare un file

00:17:43.700 --> 00:17:47.380
magari si tratta di contenuti sensibili di risorse umane, materiale finanziario

00:17:47.380 --> 00:17:50.080
o informazioni su accordi che dovevano restare in una cerchia molto ristretta

00:17:50.080 --> 00:17:54.040
non c'è stata alcuna violazione, nessun malware e nessuna barriera di sicurezza infranda nel senso tradizionale

00:17:54.040 --> 00:17:58.260
il sistema ha semplicemente utilizzato i permessi e lo stato dei contenuti che il tenant già consentiva

00:17:58.260 --> 00:18:01.000
è il momento in cui molti team finalmente comprendono il problema

00:18:01.000 --> 00:18:02.740
LIA non ha creato l'esposizione

00:18:02.740 --> 00:18:04.960
ha solo rimosso l'attrito che la nascondeva

00:18:04.960 --> 00:18:06.800
una volta che ciò accade in un tenant

00:18:06.800 --> 00:18:09.580
la fiducia della dirigenza solitamente crolla in tutta l'organizzazione

00:18:09.580 --> 00:18:13.060
perché nessuno può dire con certezza dove lo stesso schema potrebbe ripresentarsi

00:18:13.060 --> 00:18:15.060
l'incidente può sembrare locale

00:18:15.060 --> 00:18:16.640
ma il danno alla fiducia a livello aziendale

00:18:16.640 --> 00:18:19.480
il secondo schema è più silenzioso ma altrettanto pericoloso

00:18:19.480 --> 00:18:22.240
un'azienda stabilisce relazioni di identità tra tenant

00:18:22.240 --> 00:18:24.740
sente che gli scenari multi tenant sono possibili

00:18:24.740 --> 00:18:26.900
e presume che il proprio modello operativo sia abbastanza maturo

00:18:26.900 --> 00:18:28.220
per un'implementazione su larga scala

00:18:28.220 --> 00:18:30.180
su una presentazione sembra un piano solido

00:18:30.180 --> 00:18:32.560
in realtà le operazioni diventano caotiche

00:18:32.560 --> 00:18:36.080
un team si aspetta un'esperienza copilot fluida in ogni ambiente connesso

00:18:36.080 --> 00:18:38.120
mentre un altro si aspetta una visibilità comparabile

00:18:38.120 --> 00:18:41.160
e un terzo presume che gli stessi controlli seguiranno l'utente ovunque

00:18:41.160 --> 00:18:44.240
poi l'utilizzo effettivo inizia a mostrare comportamenti disomogeni

00:18:44.240 --> 00:18:47.400
lacune nell'autenticazione e punti deboli in ciò che può effettivamente essere misurato

00:18:47.400 --> 00:18:49.460
il problema non è che questi team siano stati negligenti

00:18:49.460 --> 00:18:52.400
il vero problema è che hanno tradotto la connettività in garanzia

00:18:52.400 --> 00:18:55.420
tale presupposto crea una falsa narrazione sulla conformità

00:18:55.420 --> 00:18:59.200
la dirigenza sente la parola connesso e presume che l'organizzazione sia pronta

00:18:59.200 --> 00:19:02.700
mesi dopo le revisioni dei controlli scoprono che il comportamento

00:19:02.700 --> 00:19:06.240
le prove e l'applicazione variavano molto più di quanto chiunque volesse ammettere all'inizio

00:19:06.240 --> 00:19:07.900
ora confrontalo con uno schema migliore

00:19:07.900 --> 00:19:10.880
un'altra organizzazione sceglie di rallentare prima di espandersi

00:19:10.880 --> 00:19:12.720
definiscono prima una base di etichettatura

00:19:12.720 --> 00:19:14.280
esaminano prima gli accessi estesi

00:19:14.280 --> 00:19:16.980
e convalidano la loro visibilità di audit prima di fare qualsiasi altra cosa

00:19:16.980 --> 00:19:18.660
espandano copilot a ondate

00:19:18.660 --> 00:19:19.980
non perché temano l'adozione

00:19:19.980 --> 00:19:22.860
ma perché vogliono che ogni ondata produca prove utilizzabili

00:19:22.860 --> 00:19:24.060
prima che inizi la successiva

00:19:24.060 --> 00:19:27.380
quell'organizzazione di solito si muove più velocemente a lungo termine

00:19:27.380 --> 00:19:29.520
perché non deve fermarsi continuamente a spiegare sorprese

00:19:29.520 --> 00:19:30.760
ripulire i contenuti esposti

00:19:30.760 --> 00:19:32.080
ripulire i contenuti esposti

00:19:32.080 --> 00:19:34.160
e discutere su cosa dovesse effettivamente significare governato

00:19:34.160 --> 00:19:36.180
questo è il vantaggio che molti leader trascura

00:19:36.180 --> 00:19:38.120
una buona governance non blocca il tuo roll out

00:19:38.120 --> 00:19:41.720
elimina gli attriti dal roll out una volta terminata la prima ondata

00:19:41.720 --> 00:19:43.520
la trappola non è l'adozione in sé

00:19:43.520 --> 00:19:45.920
la trappola è l'adozione non gestita tra tenant

00:19:45.920 --> 00:19:47.280
che sembrano connessi da lontano

00:19:47.280 --> 00:19:49.380
ma che si comportano in modo molto diverso da vicino

00:19:50.140 --> 00:19:52.600
la decisione che devi prendere è in realtà molto semplice

00:19:52.600 --> 00:19:55.160
devi passare subito a un modello di governance

00:19:55.160 --> 00:19:56.280
dell'IA federato Habenspo

00:19:56.280 --> 00:19:58.560
che smettere di confondere l'attivazione tenant per tenant

00:19:58.560 --> 00:20:00.280
con un controllo reale

00:20:00.280 --> 00:20:01.940
dovresti sospendere l'espansione di copilot

00:20:01.940 --> 00:20:03.720
in ogni tenant che non può dimostrare il proprio logging

00:20:03.720 --> 00:20:05.180
le revisioni delle condivisioni eccessive

00:20:05.180 --> 00:20:06.620
la copertura di base delle etichette

00:20:06.620 --> 00:20:09.240
l'IA seguirà il sistema che costruirai realmente

00:20:09.240 --> 00:20:10.700
non l'organigramma a cui fai riferimento

00:20:10.700 --> 00:20:12.780
se questo ha cambiato il tuo modo di pensare

00:20:12.780 --> 00:20:14.300
alla governance di copilot multitenant

00:20:14.300 --> 00:20:15.780
seguimi Mirko Peter su LinkedIn

00:20:15.780 --> 00:20:17.400
e condividi questo post con il tuo team

00:20:17.400 --> 00:20:19.040
se stai affrontando questi problemi proprio ora

00:20:19.040 --> 00:20:21.040
grazie a tutti

00:20:21.040 --> 00:20:25.040
grazie a tutti