WEBVTT 00:00:00.000 --> 00:00:02.300 Sua equipe de liderança acha que essa é uma questão de implementação. 00:00:03.420 --> 00:00:05.600 Essa é uma decisão de governança com um prazo muito curto, 00:00:05.900 --> 00:00:08.700 e a pressão aumenta porque o copilot não espera pela limpeza de suas políticas 00:00:08.700 --> 00:00:10.280 ou pelo alinhamento interno para alcançá-lo. 00:00:11.080 --> 00:00:12.760 Depois que começa a operar em seu ambiente, 00:00:12.860 --> 00:00:15.540 ele usa o sistema exatamente como encontra, e é aí que isso falha. 00:00:16.240 --> 00:00:19.160 A maioria das organizações com vários locatários do Microsoft 365 00:00:19.160 --> 00:00:20.820 presume que tenha uma história de controle de IA, 00:00:20.820 --> 00:00:23.920 principalmente porque compra de um fornecedor e gerencia um estado de identidade. 00:00:25.420 --> 00:00:27.120 Elas ouvem uma narrativa estratégica da Microsoft 00:00:27.120 --> 00:00:29.120 e presumem que a realidade corresponde ao argumento de venda. 00:00:29.120 --> 00:00:31.080 Mas a condição operacional é muito diferente. 00:00:31.700 --> 00:00:34.440 A IA atua nos limites dos locatários, enquanto o risco passa por eles. 00:00:34.820 --> 00:00:36.860 A questão não é se podemos habilitar o copilot em toda parte. 00:00:37.540 --> 00:00:39.620 A questão real é qual modelo de governança nos permite 00:00:39.620 --> 00:00:42.060 calar com segurança entre locatários que agem de modo independente. 00:00:43.140 --> 00:00:45.380 Antes de chegarmos a esse modelo, precisamos definir a armadilha. 00:00:45.800 --> 00:00:48.520 A armadilha é ilhas de IA soberanas dentro de uma empresa. 00:00:48.960 --> 00:00:52.000 Na maioria das organizações, a ilusão começa com familiaridade. 00:00:52.380 --> 00:00:56.580 Se abre o Microsoft 365, abre o Purview, abre o Entra e abre o Power Platform, 00:00:57.100 --> 00:00:57.820 a marca é a mesma. 00:00:57.820 --> 00:00:59.820 A linguagem de administração parece conectada. 00:01:00.320 --> 00:01:02.300 O movimento comercial conta uma história muito clara. 00:01:02.900 --> 00:01:04.840 Um ecossistema, uma estratégia, uma direção. 00:01:05.640 --> 00:01:07.500 Mas o modelo de controle subjacente não é coisa só. 00:01:07.600 --> 00:01:08.900 Isso importa mais do que a marca. 00:01:09.780 --> 00:01:12.940 Com base na pesquisa, não existe um centro de administração de IA global 00:01:12.940 --> 00:01:16.800 com paridade de recursos que permita governar o Copara de forma centralizada em todos os locatários. 00:01:17.800 --> 00:01:19.480 Você realmente tem uma pilha de controle fragmentada. 00:01:20.060 --> 00:01:23.260 Partes da governança ficam no Purview, outras partes ficam em centro de administração 00:01:23.260 --> 00:01:25.280 e o restante está espalhado pelo Entra e Power Platform. 00:01:26.000 --> 00:01:29.320 Alguns recursos estão surgindo em camadas de controle mais recentes da Microsoft, 00:01:29.600 --> 00:01:33.160 mas ainda não formam um plano global maduro completo em todos os limites de inquilino. 00:01:33.740 --> 00:01:35.140 Essa lacuna cria uma falsa confiança. 00:01:35.480 --> 00:01:37.940 Líderes olham para o ecossistema e presumem centralização, 00:01:38.200 --> 00:01:41.080 enquanto equipes buscam uma identidade compartilhada e presumem consistência. 00:01:41.440 --> 00:01:43.820 A aquisição vê um acordo e assume um modelo operacional, 00:01:44.160 --> 00:01:47.560 mas cada inquilino ainda carrega seu próprio limite de política e seu próprio limite de dados, 00:01:47.560 --> 00:01:50.660 o que significa que, na prática, cada um carrega sua própria versão da verdade. 00:01:51.360 --> 00:01:52.560 O que realmente está acontecendo é assim. 00:01:53.020 --> 00:01:54.600 Você não tem um ambiente de IA empresarial. 00:01:55.080 --> 00:01:57.580 Você tem vários ambientes de IA que pertencem à mesma empresa. 00:01:58.140 --> 00:01:59.280 Esse é um cenário de risco bem diferente. 00:01:59.780 --> 00:02:01.880 Um inquilino pode ter uma cobertura de escopo maior, 00:02:02.160 --> 00:02:05.540 enquanto o outro apresenta adoção de rótulo fraca ou ingestão de auditoria falha. 00:02:06.040 --> 00:02:08.320 Do ponto de vista do conselho, isso ainda pode parecer um programa, 00:02:08.580 --> 00:02:11.260 mas do ponto de vista de auditoria ou incidente, não é um programa. 00:02:11.800 --> 00:02:13.720 É uma coleção de condições operacionais separadas. 00:02:14.260 --> 00:02:16.660 Quando essas condições mudam, os relatórios começam a mentir. 00:02:16.660 --> 00:02:18.620 Não intencionalmente, estruturalmente. 00:02:19.100 --> 00:02:20.840 A equipe essencial pergunta, somos governados? 00:02:21.500 --> 00:02:23.440 Um inquilino diz sim, pois a auditoria está ativa. 00:02:23.580 --> 00:02:26.420 Outro diz sim, pois os rótulos existem, ainda que a cobertura seja fraca. 00:02:26.920 --> 00:02:28.520 Diz que sim, porque a identidade está conectada. 00:02:29.080 --> 00:02:31.620 Um quarto diz que sim, porque o copilot está tecnicamente implantado. 00:02:32.360 --> 00:02:35.420 Cada resposta parece razoável por si só, mas nenhuma delas significa a mesma coisa. 00:02:35.720 --> 00:02:36.320 Essa é a armadilha. 00:02:36.720 --> 00:02:38.580 Você acha que está olhando para um plano de controle global, 00:02:38.760 --> 00:02:42.120 quando o que realmente está olhando é um conjunto de índices soberanas de IA dentro de uma empresa? 00:02:42.700 --> 00:02:44.980 Elas estão conectadas em marca e às vezes em identidade, 00:02:44.980 --> 00:02:46.880 mas não são governadas como um sistema. 00:02:47.560 --> 00:02:50.320 E se você não se lembrar de mais nada desta sessão, lembre-se desta linha. 00:02:51.260 --> 00:02:54.220 Não existe um centro de administração global de apenas a ilusão de um. 00:02:54.600 --> 00:02:57.440 Quando essa ilusão se desfaz, o próximo problema aparece rapidamente. 00:02:58.100 --> 00:03:00.760 A maioria das organizações responde fazendo a governança manualmente, 00:03:00.840 --> 00:03:02.520 inquilino por inquilino, chamando isso de controle. 00:03:02.520 --> 00:03:05.500 Por que a governança manual para o locatário colapso em escala? 00:03:06.100 --> 00:03:09.040 Quando os líderes veem um problema de limite, a resposta usual parece sensata. 00:03:09.440 --> 00:03:11.100 Eles dizem que tudo bem, governaremos cada equadamente. 00:03:11.740 --> 00:03:14.600 Uma equipe administrativa checa os ajustes aqui, outra equipe os repete ali. 00:03:14.980 --> 00:03:15.920 Alguém mantém uma planilha. 00:03:16.160 --> 00:03:17.460 Outra pessoa crê uma lista de verificação. 00:03:17.980 --> 00:03:21.320 Um comitê se reúne uma vez por mês para checar se a implementação segue no rumo. 00:03:21.960 --> 00:03:23.040 No papel, isso parece disciplinado. 00:03:23.600 --> 00:03:26.420 Na prática, é repetição manual disfarçada de governança. 00:03:27.080 --> 00:03:28.260 O motivo pelo qual ela fala é sim. 00:03:28.260 --> 00:03:32.140 A repetição não produz controle, ela produz variação ao longo do tempo. 00:03:32.860 --> 00:03:35.620 Isso acontece porque cada inquilino se move em uma velocidade diferente, 00:03:35.760 --> 00:03:37.940 cada administrador lê os padrões de forma um pouco diferente 00:03:37.940 --> 00:03:40.000 e as exceções locais começam a parecer justificadas 00:03:40.000 --> 00:03:42.760 porque a empresa quer progresso agora, não depois de outra revisão central. 00:03:43.620 --> 00:03:45.680 Esse modelo antigo sobrevive porque parece visível. 00:03:46.080 --> 00:03:47.860 As pessoas podem apontar para tickets fechados, 00:03:47.980 --> 00:03:49.540 políticas criadas e configurações alteradas. 00:03:49.920 --> 00:03:52.020 Eles podem mostrar atividade, mas esforço visível 00:03:52.020 --> 00:03:53.680 não é o mesmo que o modelo operacional estável. 00:03:54.120 --> 00:03:57.000 E com o copilot em cena, essa lacuna se torna cara muito rapidamente. 00:03:57.000 --> 00:03:59.960 O sistema passa a usar permissões, exposição de conteúdo 00:03:59.960 --> 00:04:03.340 e lacunas de rotulagem existentes assim que os usuários começam a solicitar. 00:04:03.960 --> 00:04:05.100 É o que a maioria das pessoas não vê. 00:04:05.540 --> 00:04:07.060 O copilot não espera pela maturidade governança. 00:04:07.480 --> 00:04:09.480 Ele é executado nas permissões que você já tem, 00:04:09.560 --> 00:04:10.900 na agenda e conteúdo que você já tolera 00:04:10.900 --> 00:04:13.260 e na postura de auditoria que você já não conseguiu padronizar. 00:04:14.100 --> 00:04:16.180 Se um locatário limpou o acesso e outro excluiu, 00:04:16.460 --> 00:04:18.760 ou se um locatário transmite dados de auditoria úteis 00:04:18.760 --> 00:04:21.200 enquanto outro mal captura o suficiente para a investigação, 00:04:21.360 --> 00:04:23.500 o copilot exporá essas diferenças imediatamente. 00:04:23.840 --> 00:04:25.700 Isso não acontece na teoria, acontece por meio do uso. 00:04:25.700 --> 00:04:28.480 Se um locatário revisou o amplo acesso ao SharePoint 00:04:28.480 --> 00:04:30.000 e outro presumiu que era bom o suficiente, 00:04:30.180 --> 00:04:31.340 a IA encontrará as lacunas. 00:04:32.060 --> 00:04:34.840 Em um nível mais profundo, cada novo locatário multiplica o problema, 00:04:34.940 --> 00:04:35.960 não porque os locatários são ruins, 00:04:36.060 --> 00:04:38.040 mas porque as diferenças não gerenciadas se agravam. 00:04:38.860 --> 00:04:40.820 Uma nova equipe piloto adiciona uma exceção local. 00:04:41.160 --> 00:04:43.240 Uma fusão traz outro locatário com rótulos diferentes 00:04:43.240 --> 00:04:45.500 e um administrador regional copia uma linha de base antiga. 00:04:46.040 --> 00:04:47.920 Uma unidade de negócios perde acesso mais rápido 00:04:47.920 --> 00:04:50.040 e nenhuma dessas escolhas parece dramática isoladamente. 00:04:50.840 --> 00:04:51.960 Coloque-as juntas ao longo de meses 00:04:51.960 --> 00:04:54.660 e você terá desvios de política, desvios de acesso e desvios de implementação. 00:04:54.660 --> 00:04:57.040 O resultado é uma equipe de governança que gasta mais tempo 00:04:57.040 --> 00:04:59.000 reconciliando diferenças do que prevenindo riscos. 00:04:59.300 --> 00:05:00.480 É aí que o controle manual falha. 00:05:00.920 --> 00:05:03.140 Parece mais seguro porque os humanos tocam nas configurações, 00:05:03.260 --> 00:05:04.660 mas na verdade aumenta a inconsistência, 00:05:04.740 --> 00:05:07.180 porque cada ponto de contato é outra chance para os inquilinos divergirem. 00:05:07.720 --> 00:05:09.960 O resultado é a implementação mais lenta onde você quer velocidade, 00:05:10.200 --> 00:05:11.940 mais esforço de auditoria onde você quer evidências 00:05:11.940 --> 00:05:13.380 e mais retrabalho onde você quer padrões. 00:05:13.920 --> 00:05:15.920 O pior de tudo é que isso cria uma exposição oculta 00:05:15.920 --> 00:05:17.140 onde a liderança espera garantir. 00:05:17.860 --> 00:05:21.080 Entendi isso quando parei de tratar a governança como tarefa de configuração. 00:05:21.220 --> 00:05:21.300 Né? 00:05:21.300 --> 00:05:22.740 Comporta-se mais com decadência. 00:05:23.120 --> 00:05:24.560 Se você limpar as permissões uma vez, 00:05:24.640 --> 00:05:26.380 mas nenhum controle é impedido de desviar novamente, 00:05:26.460 --> 00:05:27.160 a exposição retorna. 00:05:27.600 --> 00:05:29.420 Se definir uma taxonomia de rótulos uma vez, 00:05:29.520 --> 00:05:31.960 mas os inquilinos aplicarem mal, a linha de base corrói. 00:05:32.520 --> 00:05:34.500 Se você aprovar o copilot em ondas sem verificar 00:05:34.500 --> 00:05:36.160 se o controle subjacente ainda é válido, 00:05:36.220 --> 00:05:37.620 você não estará escalando com segurança. 00:05:38.080 --> 00:05:40.320 Você está expandindo mais rápido o que sua governança consegue seguir. 00:05:40.700 --> 00:05:43.180 Portanto, a métrica que importa aqui é o desvio de acesso. 00:05:43.280 --> 00:05:44.460 Não apenas se você corrigiu algo, 00:05:44.460 --> 00:05:46.560 mas a rapidez com que as permissões se espalham novamente 00:05:46.560 --> 00:05:48.600 após a correção, novamente após a correção. 00:05:48.600 --> 00:05:50.880 Isso informa se seu modelo está se mantendo ou se deteriorando. 00:05:51.300 --> 00:05:52.880 Que a governança não é um projeto que você conclui. 00:05:53.200 --> 00:05:55.020 É um problema de decadência que você gerencia continuamente. 00:05:55.460 --> 00:05:56.820 Quando a escala quebra o modelo antigo, 00:05:56.880 --> 00:05:58.720 a maioria dos líderes recorre à resposta mais familiar, 00:05:58.960 --> 00:05:59.400 identidade. 00:06:00.320 --> 00:06:02.660 Eles presumem que, se usuários transitarem entre locatários, 00:06:02.720 --> 00:06:04.300 a governança irá acompanhá-los de alguma forma. 00:06:05.500 --> 00:06:07.180 Porque a identidade não resolve a governança. 00:06:08.020 --> 00:06:09.660 É aqui que muitos programas tomam o caminho errado, 00:06:09.800 --> 00:06:11.540 porque a identidade parece a resposta limpa. 00:06:11.540 --> 00:06:14.380 Se usuários se autenticam entre locatários, 00:06:14.460 --> 00:06:15.420 se o entro está conectado, 00:06:15.500 --> 00:06:17.500 e se as configurações entre locatários estão ativas, 00:06:17.620 --> 00:06:18.960 líderes creem que tudo foi resolvido. 00:06:19.940 --> 00:06:21.180 O acesso parece unificado, 00:06:21.300 --> 00:06:22.380 o login parece unificado, 00:06:22.700 --> 00:06:24.260 o diagrama de arquitetura parece organizado, 00:06:24.320 --> 00:06:26.680 mas a governança do Copilot não se torna unificada 00:06:26.680 --> 00:06:28.220 apenas porque a identidade pode se mover. 00:06:28.860 --> 00:06:31.020 Essa suposição falha no ponto em que a IA realmente funciona. 00:06:31.560 --> 00:06:34.620 O Copilot fundamenta as respostas no contexto locatário da solicitação, 00:06:34.700 --> 00:06:36.860 e as orientações da própria Microsoft são claras a esse respeito. 00:06:36.860 --> 00:06:41.560 O Microsoft 305 Copilot opera dentro do limite de segurança e conformidade do locatário 00:06:41.560 --> 00:06:45.160 e respeita as permissões do usuário naquele contexto de locatário específico. 00:06:45.220 --> 00:06:47.320 Um usuário pode alternar o contexto com um convidado, sim, 00:06:47.400 --> 00:06:49.360 mas o Copilot ainda tem como escopo um locatário por vez. 00:06:49.560 --> 00:06:52.040 Ele não mescla vários locatários em um espaço de trabalho inteligente 00:06:52.040 --> 00:06:52.920 por uma única resposta. 00:06:53.420 --> 00:06:55.160 Portanto, a identidade pode ser cruzada, a governança não. 00:06:55.740 --> 00:06:57.300 E depois que você separa essas duas coisas, 00:06:57.440 --> 00:06:59.740 muita linguagem executiva começa a soar perigosamente vaga. 00:07:00.540 --> 00:07:01.660 Locatários conectados, 00:07:02.000 --> 00:07:03.000 identidade compartilhada, 00:07:03.460 --> 00:07:04.340 experiência unificada, 00:07:04.340 --> 00:07:08.380 Essas fases podem ser verdadeiras em termos de colaboração, 00:07:08.480 --> 00:07:10.580 mas não são a mesma coisa que dizer que a aplicação de políticas, 00:07:10.700 --> 00:07:12.960 a base de dados, o registro em log e a validação de controle 00:07:12.960 --> 00:07:14.200 agora funcionam como um sistema. 00:07:15.220 --> 00:07:16.580 Essa lacuna se torna ainda mais óbvia 00:07:16.580 --> 00:07:18.640 quando você olha para o modo multilocatário do Copilot Studio 00:07:18.640 --> 00:07:20.560 porque a prévia conta uma história muito específica. 00:07:21.320 --> 00:07:22.980 Sim, o uso multi-tenant existe, 00:07:23.520 --> 00:07:25.680 e um agente hospedado em um tenant pode ser usado por outro, 00:07:25.680 --> 00:07:28.160 mas a autenticação de usuários finais nesse modo 00:07:28.160 --> 00:07:29.800 ainda não é suportada na versão preview. 00:07:30.280 --> 00:07:31.420 Usuários convidados não são compatíveis. 00:07:31.840 --> 00:07:33.260 Conectores personalizados não são compatíveis. 00:07:33.260 --> 00:07:36.640 Conectores padrão do Graph e do Microsoft 365 não são compatíveis. 00:07:37.160 --> 00:07:38.180 O TGL não é compatível. 00:07:38.760 --> 00:07:40.640 Vários recursos de análise não estão disponíveis. 00:07:41.460 --> 00:07:43.640 As transcrições de conversas também são desativadas nesse modo. 00:07:44.080 --> 00:07:46.060 Essa não é uma estrutura de governança madura entre inquilinos. 00:07:46.440 --> 00:07:48.280 Essa é uma visualização limitada, com limites claros. 00:07:48.640 --> 00:07:50.620 E esses limites são importantes porque quebram a história 00:07:50.620 --> 00:07:52.240 que muitas equipes de liderança contam a si mesmas. 00:07:52.240 --> 00:07:54.720 Elas ouvem multi-inquilinos e pressupõem maturidade operacional. 00:07:55.140 --> 00:07:58.140 Seus arquitetos ouvem entre inquilinos e pressupõem simetria de política. 00:07:58.720 --> 00:08:01.700 Suas equipes de controle ouvem o mesmo fornecedor e presumem consistência. 00:08:01.700 --> 00:08:05.080 Então a implementação começa e as pessoas descobrem comportamentos diferentes, 00:08:05.220 --> 00:08:08.040 sinais ausentes e lacunas incômodas em torno da autenticação e da análise. 00:08:08.740 --> 00:08:09.540 Imagine o segundo caso. 00:08:09.940 --> 00:08:12.200 Uma empresa global configura relações entre inquilinos 00:08:12.200 --> 00:08:15.660 e pressupõe que a experiência do usuário se estenderá naturalmente ao uso do Copilot. 00:08:16.080 --> 00:08:19.520 A expectativa parece razoável envolvendo confiança de diretório compartilhado, 00:08:19.600 --> 00:08:21.240 acesso mais suave e padrões de identidade comum. 00:08:21.780 --> 00:08:24.540 Mas quando as equipes testam cenários reais do Copilot e do agente, 00:08:24.620 --> 00:08:25.400 o comportamento é irregular. 00:08:25.980 --> 00:08:27.800 Alguns dados aparecem apenas em contextos alternos. 00:08:28.300 --> 00:08:29.780 Alguns conectores esperados não estão disponíveis. 00:08:29.780 --> 00:08:33.540 Expectativas de auditoria não coincidem com que recursos de visualização expõem. 00:08:34.680 --> 00:08:36.000 A liderança ainda houve conectada, 00:08:36.060 --> 00:08:37.820 enquanto a equipe de controles começa a encontrar exceções. 00:08:38.280 --> 00:08:39.200 Esse não é um caso tech-extrame. 00:08:39.660 --> 00:08:40.760 Uma leitura equivocada governa. 00:08:40.920 --> 00:08:42.780 Porque os auditores não verificam sua história de arquitetura, 00:08:42.840 --> 00:08:43.580 eles verificam as evidências. 00:08:43.980 --> 00:08:46.080 Eles perguntam onde os prompts foram executados, 00:08:46.180 --> 00:08:47.320 qual locatório aplicou a política, 00:08:47.740 --> 00:08:50.020 quais logs existem e se seus controles eram realmente comparáveis 00:08:50.020 --> 00:08:51.620 nos ambientes que você descreveu como vinculados. 00:08:51.780 --> 00:08:54.600 Se seu modelo operacional tratasse a identidade como governança, 00:08:54.700 --> 00:08:55.920 você não teria uma resposta clara. 00:08:56.500 --> 00:08:58.100 Portanto, se você se lembrar de uma linha aqui, diga esta. 00:08:58.100 --> 00:09:01.180 A identidade entre locatários não é inteligência de locatários. 00:09:01.700 --> 00:09:02.860 A identidade ajuda os usuários a entrar. 00:09:03.260 --> 00:09:06.520 Ela não informa se o comportamento do copilot é governado de forma consistente, 00:09:06.600 --> 00:09:08.900 monitorado adequadamente ou seguro para escalar em todos os lugares 00:09:08.900 --> 00:09:10.260 que sua empresa agora chama de um ambiente. 00:09:10.720 --> 00:09:13.180 E quando isso fica claro, a resposta não pode ser mais conexões de locatários. 00:09:13.580 --> 00:09:14.320 Tem que ser arquitetura. 00:09:15.380 --> 00:09:17.020 Modelo de governança que realmente funciona. 00:09:17.100 --> 00:09:17.620 Hub Spoke. 00:09:18.180 --> 00:09:19.700 Então, como é um modelo de governança real, 00:09:19.780 --> 00:09:21.140 quando sua plataforma é fragmentada, 00:09:21.480 --> 00:09:22.700 a identidade é apenas parcial, 00:09:22.700 --> 00:09:24.620 e os limites do locatário ainda importam. 00:09:25.220 --> 00:09:26.460 Parece um sistema de Hub Spoke. 00:09:27.060 --> 00:09:29.520 Não estou sugerindo isso porque o diagrama parece limpo em um slide, 00:09:29.620 --> 00:09:32.300 mas porque ele realmente corresponde às condições operacionais confusas 00:09:32.300 --> 00:09:33.460 com as quais você está lidando agora. 00:09:33.880 --> 00:09:36.260 Você precisa de um local central onde as decisões de governança 00:09:36.260 --> 00:09:39.080 sejam projetadas, medidas e aplicadas como um único sistema, 00:09:39.500 --> 00:09:41.140 e então precisa de equipes de locatários locais 00:09:41.140 --> 00:09:41.980 para executar essas decisões. 00:09:42.200 --> 00:09:44.960 Essas equipes locais precisam trabalhar dentro de seus próprios limites, 00:09:45.040 --> 00:09:46.740 sem inventar a sua própria versão das regras, 00:09:46.780 --> 00:09:48.360 toda vez que sentem um pouco de pressão. 00:09:49.080 --> 00:09:49.900 Temos que começar com o Hub. 00:09:50.920 --> 00:09:52.420 O Hub não é um portal de administração, 00:09:52.580 --> 00:09:53.540 não é um painel brilhante, 00:09:53.720 --> 00:09:55.580 e definitivamente não é uma equipe central heróica 00:09:55.580 --> 00:09:57.640 entrando em cada locatário para limpar arquivos manualmente. 00:09:58.780 --> 00:10:01.060 Em vez disso, o Hub atua como autoridade de governança final. 00:10:01.760 --> 00:10:03.360 Este grupo cuida do design da política, 00:10:03.500 --> 00:10:04.480 das bases de auditoria, 00:10:04.600 --> 00:10:06.500 dos padrões de rótulo e critérios de lançamento. 00:10:07.400 --> 00:10:10.100 São eles que decidem o que realmente significa pronto para o Copilot, 00:10:10.480 --> 00:10:11.840 quais evidências contam como prova 00:10:11.840 --> 00:10:13.900 e com que rapidez uma lacuna de segurança deve ser fechada. 00:10:14.700 --> 00:10:16.160 Essa mudança muda toda a conversa. 00:10:17.160 --> 00:10:18.260 Por causa dessa estrutura, 00:10:18.360 --> 00:10:20.460 global deixa de ser uma palavra com uma tela mágica 00:10:20.460 --> 00:10:23.000 e passa a significar um sistema de governança unificado. 00:10:23.940 --> 00:10:25.800 Você obtém um padrão para controle de competência, 00:10:25.900 --> 00:10:27.360 um padrão para como você ingere editorias 00:10:27.360 --> 00:10:29.400 e um padrão para seus rótulos de sensibilidade. 00:10:30.120 --> 00:10:31.860 Existe um critério claro que deve ser cumprido 00:10:31.860 --> 00:10:35.040 antes que um locatário possa expandir o acesso ao Copilot para mais usuários. 00:10:35.540 --> 00:10:36.160 Não se precisa dos raios. 00:10:36.500 --> 00:10:38.800 Os raios são suas equipes de execução de locatários locais 00:10:38.800 --> 00:10:41.380 que pegam essa linha de base e aplicam o seu ambiente específico. 00:10:42.000 --> 00:10:43.460 São eles que executam a correção, 00:10:43.720 --> 00:10:46.260 validam os logs e revisam as permissões de acesso amplas. 00:10:46.260 --> 00:10:48.240 No entanto, eles fazem todo esse trabalho 00:10:48.240 --> 00:10:50.400 dentro de um espaço de design muito restrito, 00:10:50.580 --> 00:10:51.380 em vez de um vale-tudo. 00:10:52.040 --> 00:10:54.140 Se uma equipe local precisasse desviar do plano, 00:10:54.320 --> 00:10:55.540 há um caminho formal para exceções. 00:10:56.260 --> 00:10:57.620 E se eles quiserem se mover mais rápido, 00:10:57.860 --> 00:10:59.260 ainda precisam atender aos compartilhados primeiro. 00:11:00.260 --> 00:11:02.340 Quando surgem diferenças regionais ou legais, 00:11:02.440 --> 00:11:04.160 tais questões são documentadas e aprovadas, 00:11:04.260 --> 00:11:06.140 em vez de absorvidas por alguma solução local 00:11:06.140 --> 00:11:07.340 que ninguém mais conhece. 00:11:07.340 --> 00:11:10.740 Essa estrutura é vital porque modelos totalmente centralizados 00:11:10.740 --> 00:11:12.240 geralmente se prendem a detalhes locais, 00:11:12.320 --> 00:11:15.460 enquanto modelos totalmente locais caem em consistência total quase que imediatamente. 00:11:16.220 --> 00:11:18.460 O Hub e o Spoke evitam esses dois padrões de falha. 00:11:18.980 --> 00:11:20.740 O Hub oferece a consistência necessária, 00:11:20.960 --> 00:11:22.880 enquanto os Spokes oferecem a velocidade de execução 00:11:22.880 --> 00:11:24.220 onde o trabalho está realmente acontecendo. 00:11:24.560 --> 00:11:25.400 Vamos tornar isso concreto. 00:11:25.840 --> 00:11:28.520 No Hub, você define o conjunto mínimo de controle de escopo 00:11:28.520 --> 00:11:31.200 que cada locatário deve executar antes que o Copilot possa crescer. 00:11:31.760 --> 00:11:34.220 Você define exatamente quais eventos de auditoria espera ver 00:11:34.220 --> 00:11:35.520 e com que frequência os revisará. 00:11:36.480 --> 00:11:39.800 Você também cria uma taxonomia de rótulos compartilhados para conteúdo sensível, 00:11:39.940 --> 00:11:43.300 garantindo que uma tag confidencial não signifique cinco coisas em cinco locatários. 00:11:44.260 --> 00:11:45.860 Você define o ritmo das revisões, 00:11:46.120 --> 00:11:48.300 talvez mensalmente para sua postura geral de segurança 00:11:48.300 --> 00:11:51.000 e com mais frequência em áreas onde a implementação está ativa no momento. 00:11:52.080 --> 00:11:54.200 No Spokes, o equipe mapeia esses padrões de alto nível 00:11:54.200 --> 00:11:56.040 para a realidade desse locatário específico. 00:11:56.700 --> 00:11:58.960 Eles descobrem quais sites ainda têm amplo acesso exposto 00:11:58.960 --> 00:12:01.300 e quais unidades de negócios estão atrasadas em sua rotulagem. 00:12:01.700 --> 00:12:03.680 Eles verificam se a auditoria está realmente ativada 00:12:03.680 --> 00:12:05.640 e se os registros corretos estão visíveis para a equipe de segurança. 00:12:05.940 --> 00:12:08.840 Eles procuram administradores locais que possam ter introduzido exceções 00:12:08.840 --> 00:12:10.380 que nunca foram revisadas oficialmente 00:12:10.380 --> 00:12:12.480 e decidem se um grupo piloto pode se expandir com segurança 00:12:12.480 --> 00:12:14.280 ou se precisam parar e consertar as coisas primeiro. 00:12:15.080 --> 00:12:17.020 E aqui está a regra rígida, porque sem uma regra. 00:12:17.220 --> 00:12:19.640 Esse modelo é apenas uma sugestão em vez de governança real. 00:12:20.680 --> 00:12:22.600 Nenhuma implementação do Copilot ocorre em tenants 00:12:22.600 --> 00:12:24.080 sem registro de auditoria validado, 00:12:24.500 --> 00:12:27.220 varredura de compartilhamento excessivo e baseline de rótulos. 00:12:27.220 --> 00:12:30.740 Não estou falando sobre essas coisas serem planejadas ou parcialmente discutidas. 00:12:31.120 --> 00:12:31.880 Elas devem ser validadas. 00:12:31.880 --> 00:12:34.540 Se um tenant não provar que essas três condições são atendidas, 00:12:34.680 --> 00:12:35.380 o rollout pausa. 00:12:36.100 --> 00:12:38.720 Isso pode parecer rigoroso até você comparar com o custo enorme 00:12:38.720 --> 00:12:40.840 de limpar uma bagunça depois que os usuários começam a encontrar 00:12:40.840 --> 00:12:43.020 conteúdo confidencial que você nunca quis expor por meio da IA. 00:12:43.640 --> 00:12:46.280 Quando você olha dessa forma, essas regras são apenas sensos como um básico. 00:12:46.980 --> 00:12:49.280 Outro motivo pelo qual esse modelo funciona tão bem é o momento. 00:12:49.780 --> 00:12:51.480 Quanto mais você esperar para configurar isso, 00:12:51.560 --> 00:12:53.140 mais dívida de limpeza estará querendo para si mesmo. 00:12:53.580 --> 00:12:55.780 Cada tenant que é implementado antes da linha de base 00:12:55.780 --> 00:12:58.380 se torna outro acúmulo enorme de exceções e evidências ausentes 00:12:58.380 --> 00:13:00.420 que sua equipe eventualmente terá que resolver. 00:13:01.340 --> 00:13:04.320 Os líderes geralmente tratam a governança como algo que pode amadurecer 00:13:04.320 --> 00:13:05.380 após a conclusão da adoção, 00:13:05.480 --> 00:13:06.940 mas em um mundo copilot com vários inquilinos, 00:13:07.040 --> 00:13:08.420 essa sequência é completamente inversa. 00:13:08.880 --> 00:13:10.540 A governança precisa liderar a implementação, 00:13:10.620 --> 00:13:13.260 ou a implementação criará mais dívidas do que suas equipes podem esperar absorver. 00:13:13.260 --> 00:13:15.400 Se você estiver liderando isso em nível empresarial, 00:13:15.500 --> 00:13:16.480 seu próximo passo é muito claro. 00:13:17.080 --> 00:13:19.320 Crie o hub agora mesmo e defina essa linha de base hoje. 00:13:20.020 --> 00:13:23.660 Atribua seus raios e coloque seu processo de tratamento de exceções por escrito imediatamente. 00:13:24.220 --> 00:13:28.220 Você precisa fazer com que global signifique que suas decisões e portões de implementação 00:13:28.220 --> 00:13:30.840 funcionem como um só sistema mesmo quando os inquilinos não. 00:13:31.640 --> 00:13:34.500 Um modelo só importa se realmente muda o que será aplicado amanhã de manhã, 00:13:35.320 --> 00:13:37.040 o que os líderes devem medir antes de escalar. 00:13:37.660 --> 00:13:41.080 Um modelo de governança só se mantém se produzir medições que todos compartilhem. 00:13:41.080 --> 00:13:44.900 Caso contrário, cada inquilino negará que está progredindo em seu próprio idioma, 00:13:45.120 --> 00:13:47.920 e a liderança receberá atualizações de status sem ter nenhum controle real. 00:13:48.660 --> 00:13:50.120 Antes de escalar ainda mais o copilot, 00:13:50.200 --> 00:13:52.000 é necessário um pequeno conjunto de métricas 00:13:52.000 --> 00:13:54.300 para verificar se a arquitetura se comporta como você espera. 00:13:54.920 --> 00:13:56.580 Os níveis de atividade não dirão a verdade, 00:13:56.800 --> 00:13:59.040 e os números de adoção definitivamente não mostrarão os riscos. 00:13:59.360 --> 00:14:00.940 Você deve começar com a redução do compartilhamento. 00:14:01.420 --> 00:14:05.440 Este ainda é um dos sinais mais óbvios de que seu ambiente está realmente se tornando mais seguro para a IA. 00:14:06.020 --> 00:14:08.220 Você precisa analisar grupos de acesso amplos, 00:14:08.320 --> 00:14:10.180 sites abertos do SharePoint e permissões antigas 00:14:10.180 --> 00:14:12.700 que concedem muito mais acesso ao que a empresa realmente precisa. 00:14:13.240 --> 00:14:15.020 O objetivo aqui não é atingir o número perfeito, 00:14:15.100 --> 00:14:18.420 mas provar que sua exposição está diminuindo antes que seu alcance do copilot aumente. 00:14:19.000 --> 00:14:21.360 Se essas duas linhas estiverem se movendo em direções opostas, 00:14:21.460 --> 00:14:23.980 você está se expandindo muito mais rápido do que está corrigindo os problemas subjacentes. 00:14:24.660 --> 00:14:26.800 A segunda métrica necessária é a cobertura de observabilidade. 00:14:27.460 --> 00:14:29.440 Você consegue realmente ver o que o copilot está fazendo 00:14:29.440 --> 00:14:31.660 com todos os seus inquilinos de uma forma que suporte uma investigação real. 00:14:32.080 --> 00:14:34.760 A maior parte das pesquisas indica o Microsoft Purview 00:14:34.760 --> 00:14:37.300 como o local principal de armazenamento de registros, 00:14:37.600 --> 00:14:39.920 como interações do copilot se a auditoria estiver ativa. 00:14:40.460 --> 00:14:42.440 Cobertura não é algo que se pode simplesmente presumir. 00:14:42.880 --> 00:14:46.000 Você precisa saber exatamente quais inquilinos têm gestão de auditoria ativa 00:14:46.000 --> 00:14:48.460 e quais ainda estão deixando você com visibilidade parcial. 00:14:49.160 --> 00:14:52.120 Se você não tem registros, não tem governança nem responsabilidade, 00:14:52.820 --> 00:14:53.940 isso soa direto porque tem que ser. 00:14:54.460 --> 00:14:57.380 Se um locatário não puder fornecer evidências úteis do que está acontecendo, 00:14:57.500 --> 00:14:59.060 ele não estará pronto para escalar com segurança. 00:14:59.460 --> 00:15:01.760 Você não pode controlar o que não tem permissão para inspecionar 00:15:01.760 --> 00:15:04.420 e certamente não conseguirá defender suas ações se algo der errado mais tarde. 00:15:05.060 --> 00:15:07.260 A terceira métrica é o tempo de política para todos os locatários. 00:15:08.140 --> 00:15:10.200 É aqui que a liderança descobre se o modelo de hub and spoke 00:15:10.200 --> 00:15:12.140 é realmente real ou apenas decorativo. 00:15:13.000 --> 00:15:15.000 Uma decisão central não significa absolutamente nada 00:15:15.000 --> 00:15:16.140 se um locatário aplica esta semana 00:15:16.140 --> 00:15:17.960 enquanto o outro espera um mês para pensar sobre ela. 00:15:18.560 --> 00:15:19.980 Você deve medir o tempo que leva 00:15:19.980 --> 00:15:21.160 desde a aprovação de uma política 00:15:21.160 --> 00:15:23.540 até que ela seja efetivamente aplicada em cada locatário. 00:15:24.040 --> 00:15:26.500 Não estou falando sobre o tempo que leva para anunciá-la ou documentá-la, 00:15:26.580 --> 00:15:28.080 mas o tempo até que ela esteja realmente ativa. 00:15:28.640 --> 00:15:30.320 Para um programa de IA que se move tão rápido, 00:15:30.320 --> 00:15:32.320 esse tipo de atraso é apenas outra palavra para risco. 00:15:32.760 --> 00:15:34.640 Uma meta prática para a maioria das organizações 00:15:34.640 --> 00:15:36.540 é menos de 72 horas para alterações padrão. 00:15:37.020 --> 00:15:38.700 Se o tempo do seu ciclo for muito maior do que isso, 00:15:39.100 --> 00:15:40.380 você ainda não tem um modelo escalável 00:15:40.380 --> 00:15:42.900 e tem apenas um problema de coordenação que precisa ser resolvido. 00:15:43.400 --> 00:15:45.460 A seguir, você precisa analisar a sua taxa de cobertura de roda. 00:15:45.880 --> 00:15:47.460 Não deixe isso virar uma métrica de vaidade 00:15:47.460 --> 00:15:48.880 onde um locatário atinge números altos 00:15:48.880 --> 00:15:49.940 enquanto os outros ficam para trás. 00:15:50.360 --> 00:15:52.100 O que importa é se seu conteúdo confidencial 00:15:52.100 --> 00:15:53.840 está rotulado com a consistência necessária 00:15:53.840 --> 00:15:56.340 para que o comportamento do Copilot não dependa de exposições. 00:15:56.920 --> 00:15:58.580 Você não está procurando a perfeição aqui, 00:15:58.580 --> 00:16:00.640 mas sim um nível comparável de controle 00:16:00.640 --> 00:16:02.300 em todos os locatários da organização. 00:16:03.020 --> 00:16:04.860 Por fim, você precisa monitorar sua taxa de excesso. 00:16:05.400 --> 00:16:07.360 Essa métrica informa se seus esforços de limpeza 00:16:07.360 --> 00:16:08.380 estão realmente se mantendo ao longo. 00:16:09.040 --> 00:16:10.540 Depois de concluir um projeto de correção, 00:16:10.640 --> 00:16:12.640 com que rapidez as permissões começam a espalhar novamente? 00:16:13.360 --> 00:16:15.560 Com que frequência esses grupos amplos retornam ao sistema? 00:16:16.100 --> 00:16:17.680 Muitas equipes percebem isso tarde demais, 00:16:17.780 --> 00:16:19.060 pois mediram a correção apenas uma vez 00:16:19.060 --> 00:16:20.060 e assumiram que o problema sumiu. 00:16:20.060 --> 00:16:22.620 A única métrica que importa é a rapidez 00:16:22.620 --> 00:16:23.760 com que o sistema comece a falhar 00:16:23.760 --> 00:16:25.060 quando você para de analisá-lo. 00:16:25.560 --> 00:16:26.680 Esse é o seu painel operacional. 00:16:27.180 --> 00:16:29.160 Você precisa monitorar a redução de compartilhamento, 00:16:29.260 --> 00:16:30.360 cobertura de observabilidade, 00:16:30.560 --> 00:16:32.720 tempo de política, rótulos e desvio de acesso. 00:16:33.280 --> 00:16:35.140 O ritmo dos seus relatórios é tão importante 00:16:35.140 --> 00:16:36.060 quanto os números em si. 00:16:36.720 --> 00:16:38.780 O hub deve ser responsável pelo painel executivo 00:16:38.780 --> 00:16:40.460 porque a liderança precisa de uma visão única 00:16:40.460 --> 00:16:41.220 de toda a postura. 00:16:41.960 --> 00:16:43.940 Enquanto isso, os spokes devem ser responsáveis 00:16:43.940 --> 00:16:45.920 pela correção porque o trabalho real precisa acontecer 00:16:45.920 --> 00:16:47.060 onde o limite do locatário está. 00:16:47.780 --> 00:16:48.740 Uma equipe lê o sistema 00:16:48.740 --> 00:16:49.760 e a outra equipe o corrige. 00:16:50.400 --> 00:16:52.060 Deve monitorar esses números antes de expandir, 00:16:52.120 --> 00:16:52.780 não depois do fato. 00:16:53.280 --> 00:16:54.180 O risco não está esperando 00:16:54.180 --> 00:16:55.880 pela sua próxima reunião ou workshop de governança. 00:16:56.200 --> 00:16:57.660 Ele já está ativo em cada locatário, 00:16:57.840 --> 00:16:59.400 onde o copilot pode encontrar exatamente 00:16:59.400 --> 00:17:01.480 o que seus controles atuais ainda estão permitindo que ele veja. 00:17:01.800 --> 00:17:03.300 Dois padrões que os líderes continuam perdendo. 00:17:03.720 --> 00:17:05.820 Continuo vendo dois padrões específicos no campo 00:17:05.820 --> 00:17:08.340 e ambos acontecem porque os líderes tratam o copilot 00:17:08.340 --> 00:17:09.460 como um lançamento de software 00:17:09.460 --> 00:17:10.840 em vez de um grande evento de controle. 00:17:11.260 --> 00:17:12.360 O primeiro padrão começa 00:17:12.360 --> 00:17:14.020 quando uma organização implementa o copilot 00:17:14.020 --> 00:17:15.920 antes de definir uma linha de base de escopo real 00:17:15.920 --> 00:17:17.260 ou revisar seu acesso ao SharePoint. 00:17:17.260 --> 00:17:19.680 No primeiro dia, a implementação pode ser perfeita. 00:17:20.020 --> 00:17:21.100 As licenças são atribuídas, 00:17:21.180 --> 00:17:22.000 os usuários estão animados 00:17:22.000 --> 00:17:24.080 e as mensagens internas são todas sobre produtividade. 00:17:24.880 --> 00:17:25.280 Mas então, 00:17:25.480 --> 00:17:27.100 prompts normais começam a exibir material 00:17:27.100 --> 00:17:28.840 que era tecnicamente acessível o tempo todo, 00:17:28.900 --> 00:17:30.900 mas praticamente invisível para o funcionário médio. 00:17:32.360 --> 00:17:32.900 Antes da IAR, 00:17:33.040 --> 00:17:34.800 ninguém passava o dia clicando em sites antigos, 00:17:35.040 --> 00:17:35.940 pastas desatualizadas 00:17:35.940 --> 00:17:36.800 ou permissões herdadas 00:17:36.800 --> 00:17:38.160 para encontrar coisas que não deveria ver. 00:17:38.860 --> 00:17:40.080 Mas agora eles não precisam mais fazer isso. 00:17:40.500 --> 00:17:41.940 Um usuário faz uma pergunta básica, 00:17:41.980 --> 00:17:42.840 um resumo é retornado 00:17:42.840 --> 00:17:43.660 e um arquivo aparece. 00:17:43.660 --> 00:17:45.700 Talvez seja conteúdo confidencial 00:17:45.700 --> 00:17:46.060 de RH, 00:17:46.200 --> 00:17:46.840 material financeiro 00:17:46.840 --> 00:17:47.760 ou informações de negócios 00:17:47.760 --> 00:17:48.580 que deveriam permanecer 00:17:48.580 --> 00:17:49.820 dentro de um círculo muito restrito. 00:17:50.480 --> 00:17:51.720 Não houve violação malware 00:17:51.720 --> 00:17:52.860 ou quebra de limite de segurança 00:17:52.860 --> 00:17:53.760 no sentido tradicional. 00:17:54.420 --> 00:17:56.200 O sistema simplesmente usou as permissões 00:17:56.200 --> 00:17:57.060 e o estado do conteúdo 00:17:57.060 --> 00:17:58.220 que o locatário já permitia. 00:17:58.800 --> 00:17:59.280 Esse é o momento 00:17:59.280 --> 00:18:00.060 em que muitas equipes 00:18:00.060 --> 00:18:01.120 finalmente entendem o problema. 00:18:01.500 --> 00:18:02.620 A IAR não criou exposição, 00:18:03.240 --> 00:18:04.240 ela apenas removeu o atrito 00:18:04.240 --> 00:18:04.940 que costumava esconder. 00:18:05.380 --> 00:18:06.900 Quando isso acontece em um locatário, 00:18:07.040 --> 00:18:08.060 a confiança dos executivos 00:18:08.060 --> 00:18:09.400 geralmente cai em toda a organização, 00:18:09.500 --> 00:18:10.820 porque ninguém pode dizer com certeza 00:18:10.820 --> 00:18:11.780 uma empresa onde esse mesmo padrão 00:18:11.780 --> 00:18:12.960 pode aparecer em seguida. 00:18:13.760 --> 00:18:14.880 O incidente pode parecer local, 00:18:15.020 --> 00:18:15.800 mas o dano à confiança 00:18:15.800 --> 00:18:16.600 atinge toda a empresa. 00:18:17.220 --> 00:18:18.500 O segundo padrão é mais silencioso, 00:18:18.580 --> 00:18:19.460 mas é igualmente perigoso. 00:18:19.900 --> 00:18:20.700 Uma empresa configura 00:18:20.700 --> 00:18:21.640 relações de identidade 00:18:21.640 --> 00:18:22.400 entre locatários. 00:18:22.940 --> 00:18:24.280 Ouve que cenários multilocatários 00:18:24.280 --> 00:18:24.880 são possíveis 00:18:24.880 --> 00:18:26.280 e presume que seu modelo operacional 00:18:26.280 --> 00:18:26.800 está maduro 00:18:26.800 --> 00:18:27.860 para uma ampla implementação. 00:18:28.480 --> 00:18:29.140 Em um slide deck 00:18:29.140 --> 00:18:30.080 se parece um plano sólido. 00:18:30.560 --> 00:18:30.900 Na realidade, 00:18:31.060 --> 00:18:32.080 as operações ficam confusas. 00:18:32.500 --> 00:18:33.180 Uma equipe espera 00:18:33.180 --> 00:18:34.200 uma experiência tranquila 00:18:34.200 --> 00:18:34.700 do copilot 00:18:34.700 --> 00:18:36.060 em todos os ambientes conectados, 00:18:36.400 --> 00:18:37.180 enquanto outra espera 00:18:37.180 --> 00:18:38.300 visibilidade comparável, 00:18:38.300 --> 00:18:39.460 e uma terceira presume 00:18:39.460 --> 00:18:40.300 que os mesmos controles 00:18:40.300 --> 00:18:40.900 seguirão o usuário 00:18:40.900 --> 00:18:41.480 em todos os lugares. 00:18:41.780 --> 00:18:42.420 Então o uso real 00:18:42.420 --> 00:18:43.060 começa a expor 00:18:43.060 --> 00:18:43.960 comportamento irregular, 00:18:44.260 --> 00:18:45.140 lacunas na autenticação 00:18:45.140 --> 00:18:45.880 e pontos fracos 00:18:45.880 --> 00:18:47.080 no que pode realmente ser medido. 00:18:47.580 --> 00:18:48.020 O problema não é 00:18:48.020 --> 00:18:48.420 que essas equipes 00:18:48.420 --> 00:18:49.240 estavam sendo descuidadas? 00:18:49.800 --> 00:18:50.540 O verdadeiro problema 00:18:50.540 --> 00:18:51.340 é que elas traduziram 00:18:51.340 --> 00:18:52.500 conectividade em garantia. 00:18:53.280 --> 00:18:53.880 Essa suposição 00:18:53.880 --> 00:18:54.700 criou uma história falsa 00:18:54.700 --> 00:18:55.360 sobre conformidade. 00:18:55.900 --> 00:18:56.640 A liderança ouve 00:18:56.640 --> 00:18:57.500 a palavra conectado 00:18:57.500 --> 00:18:58.640 e presume que a organização 00:18:58.640 --> 00:18:59.080 está pronta. 00:19:00.040 --> 00:19:00.720 Meses depois, 00:19:00.860 --> 00:19:01.680 revisões de controle 00:19:01.680 --> 00:19:02.880 mostram que o comportamento, 00:19:02.980 --> 00:19:04.080 as evidências e a aplicação 00:19:04.080 --> 00:19:04.900 variaram bem mais 00:19:04.900 --> 00:19:06.100 do que se quis admitir no início. 00:19:06.620 --> 00:19:07.280 Agora compare isso 00:19:07.280 --> 00:19:07.820 a um padrão melhor. 00:19:08.300 --> 00:19:09.220 Uma organização diferente 00:19:09.220 --> 00:19:10.120 opta por desacelerar 00:19:10.120 --> 00:19:10.700 antes de expandir. 00:19:11.220 --> 00:19:11.900 Ela define uma linha 00:19:11.900 --> 00:19:12.980 de base de rótulo primeiro, 00:19:13.100 --> 00:19:14.240 analisa o acesso amplo primeiro 00:19:14.240 --> 00:19:15.280 e valida sua visibilidade 00:19:15.280 --> 00:19:15.780 de auditoria 00:19:15.780 --> 00:19:16.820 antes de fazer qualquer outra coisa. 00:19:17.460 --> 00:19:18.920 Eles expandem o Copilot em ondas, 00:19:19.100 --> 00:19:19.740 não porque tenham medo 00:19:19.740 --> 00:19:20.200 da adoção, 00:19:20.280 --> 00:19:20.740 mas porque querem 00:19:20.740 --> 00:19:21.340 que cada onda 00:19:21.340 --> 00:19:22.560 produza evidências úteis 00:19:22.560 --> 00:19:23.820 antes que a próxima comece. 00:19:24.880 --> 00:19:25.540 Essa organização 00:19:25.540 --> 00:19:26.220 geralmente se move 00:19:26.220 --> 00:19:27.380 mais rápido no longo prazo, 00:19:27.480 --> 00:19:28.640 porque não para constantemente 00:19:28.640 --> 00:19:29.660 para explicar surpresas, 00:19:29.760 --> 00:19:30.740 limpar conteúdo exposto 00:19:30.740 --> 00:19:31.720 ou discutir sobre o que 00:19:31.720 --> 00:19:32.860 governado realmente 00:19:32.860 --> 00:19:33.800 deveria significar. 00:19:34.660 --> 00:19:35.360 Essa é a vantagem 00:19:35.360 --> 00:19:36.080 que líderes não veem. 00:19:36.080 --> 00:19:37.200 A boa governança 00:19:37.200 --> 00:19:38.180 não bloqueia sua implementação. 00:19:38.760 --> 00:19:39.640 Ela remove o empecilho 00:19:39.640 --> 00:19:40.260 da implementação 00:19:40.260 --> 00:19:41.200 depois que a primeira onda 00:19:41.200 --> 00:19:41.800 é concluída. 00:19:42.300 --> 00:19:43.440 A armadilha não é a adoção em si. 00:19:43.800 --> 00:19:44.680 A armadilha é a adoção 00:19:44.680 --> 00:19:45.480 não gerenciada 00:19:45.480 --> 00:19:45.980 entre inquilinos 00:19:45.980 --> 00:19:46.800 que parecem conectados 00:19:46.800 --> 00:19:47.300 à distância, 00:19:47.420 --> 00:19:48.040 mas se comportam 00:19:48.040 --> 00:19:48.920 de forma muito diferente 00:19:48.920 --> 00:19:49.860 quando você se aproxima. 00:19:50.640 --> 00:19:51.520 Decisão que você precisa tomar 00:19:51.520 --> 00:19:52.380 é realmente muito simples. 00:19:53.320 --> 00:19:54.040 Você precisa migrar 00:19:54.040 --> 00:19:55.040 para um modelo de governança 00:19:55.040 --> 00:19:56.260 de AdHub e Spoke Federal 00:19:56.260 --> 00:19:56.580 da Lora 00:19:56.580 --> 00:19:57.480 e precisa parar de confundir 00:19:57.480 --> 00:19:58.340 a alternância de inquilino 00:19:58.340 --> 00:19:58.760 por inquilino 00:19:58.760 --> 00:19:59.520 com controle real. 00:20:00.420 --> 00:20:01.160 Você deve pausar 00:20:01.160 --> 00:20:02.080 a expansão do Copilot 00:20:02.080 --> 00:20:02.940 em qualquer inquilino 00:20:02.940 --> 00:20:03.560 que não comprove 00:20:03.560 --> 00:20:04.220 seu registro, 00:20:04.300 --> 00:20:05.440 revisões de compartilhamento 00:20:05.440 --> 00:20:06.680 e cobertura de linha de base. 00:20:07.380 --> 00:20:08.240 Aí assegirá o sistema 00:20:08.240 --> 00:20:09.200 que você realmente constrói 00:20:09.200 --> 00:20:09.840 no organograma 00:20:09.840 --> 00:20:10.760 ao qual você se reporta. 00:20:11.380 --> 00:20:11.920 Se isso mudou 00:20:11.920 --> 00:20:13.020 a forma como você pensa 00:20:13.020 --> 00:20:13.660 sobre a governança 00:20:13.660 --> 00:20:14.820 do Copilot multilocatário, 00:20:14.940 --> 00:20:15.220 siga-me, 00:20:15.320 --> 00:20:15.840 Mirko Peters, 00:20:15.920 --> 00:20:16.300 no LinkedIn 00:20:16.300 --> 00:20:17.180 e compartilhe isso 00:20:17.180 --> 00:20:17.640 com sua equipe 00:20:17.640 --> 00:20:18.360 se você estiver lidando 00:20:18.360 --> 00:20:19.100 com esses problemas agora. 00:20:19.100 --> 00:20:20.100 Obrigado. 00:20:20.100 --> 00:20:21.100 Obrigado. 00:20:21.100 --> 00:20:22.100 Obrigado. 00:20:22.100 --> 00:20:23.100 Obrigado.