Sua equipe de liderança acha que essa é uma questão de implementação. Essa é uma decisão de governança com um prazo muito curto, e a pressão aumenta porque o copilot não espera pela limpeza de suas políticas ou pelo alinhamento interno para alcançá-lo. Depois que começa a operar em seu ambiente, ele usa o sistema exatamente como encontra, e é aí que isso falha. A maioria das organizações com vários locatários do Microsoft 365 presume que tenha uma história de controle de IA, principalmente porque compra de um fornecedor e gerencia um estado de identidade. Elas ouvem uma narrativa estratégica da Microsoft e presumem que a realidade corresponde ao argumento de venda. Mas a condição operacional é muito diferente. A IA atua nos limites dos locatários, enquanto o risco passa por eles. A questão não é se podemos habilitar o copilot em toda parte. A questão real é qual modelo de governança nos permite calar com segurança entre locatários que agem de modo independente.

Antes de chegarmos a esse modelo, precisamos definir a armadilha. A armadilha é ilhas de IA soberanas dentro de uma empresa. Na maioria das organizações, a ilusão começa com familiaridade. Se abre o Microsoft 365, abre o Purview, abre o Entra e abre o Power Platform, a marca é a mesma. A linguagem de administração parece conectada. O movimento comercial conta uma história muito clara. Um ecossistema, uma estratégia, uma direção. Mas o modelo de controle subjacente não é coisa só. Isso importa mais do que a marca. Com base na pesquisa, não existe um centro de administração de IA global com paridade de recursos que permita governar o Copara de forma centralizada em todos os locatários. Você realmente tem uma pilha de controle fragmentada. Partes da governança ficam no Purview, outras partes ficam em centro de administração e o restante está espalhado pelo Entra e Power Platform. Alguns recursos estão surgindo em camadas de controle mais recentes da Microsoft, mas ainda não formam um plano global maduro completo em todos os limites de inquilino.

Essa lacuna cria uma falsa confiança. Líderes olham para o ecossistema e presumem centralização, enquanto equipes buscam uma identidade compartilhada e presumem consistência. A aquisição vê um acordo e assume um modelo operacional, mas cada inquilino ainda carrega seu próprio limite de política e seu próprio limite de dados, o que significa que, na prática, cada um carrega sua própria versão da verdade. O que realmente está acontecendo é assim. Você não tem um ambiente de IA empresarial. Você tem vários ambientes de IA que pertencem à mesma empresa. Esse é um cenário de risco bem diferente. Um inquilino pode ter uma cobertura de escopo maior, enquanto o outro apresenta adoção de rótulo fraca ou ingestão de auditoria falha. Do ponto de vista do conselho, isso ainda pode parecer um programa, mas do ponto de vista de auditoria ou incidente, não é um programa. É uma coleção de condições operacionais separadas.

Quando essas condições mudam, os relatórios começam a mentir. Não intencionalmente, estruturalmente. A equipe essencial pergunta, somos governados? Um inquilino diz sim, pois a auditoria está ativa. Outro diz sim, pois os rótulos existem, ainda que a cobertura seja fraca. Diz que sim, porque a identidade está conectada. Um quarto diz que sim, porque o copilot está tecnicamente implantado. Cada resposta parece razoável por si só, mas nenhuma delas significa a mesma coisa. Essa é a armadilha. Você acha que está olhando para um plano de controle global, quando o que realmente está olhando é um conjunto de índices soberanas de IA dentro de uma empresa? Elas estão conectadas em marca e às vezes em identidade, mas não são governadas como um sistema. E se você não se lembrar de mais nada desta sessão, lembre-se desta linha. Não existe um centro de administração global de apenas a ilusão de um. Quando essa ilusão se desfaz, o próximo problema aparece rapidamente.

A maioria das organizações responde fazendo a governança manualmente, inquilino por inquilino, chamando isso de controle. Por que a governança manual para o locatário colapso em escala? Quando os líderes veem um problema de limite, a resposta usual parece sensata. Eles dizem que tudo bem, governaremos cada equadamente. Uma equipe administrativa checa os ajustes aqui, outra equipe os repete ali. Alguém mantém uma planilha. Outra pessoa crê uma lista de verificação. Um comitê se reúne uma vez por mês para checar se a implementação segue no rumo. No papel, isso parece disciplinado. Na prática, é repetição manual disfarçada de governança. O motivo pelo qual ela fala é sim. A repetição não produz controle, ela produz variação ao longo do tempo. Isso acontece porque cada inquilino se move em uma velocidade diferente, cada administrador lê os padrões de forma um pouco diferente e as exceções locais começam a parecer justificadas porque a empresa quer progresso agora, não depois de outra revisão central.

Esse modelo antigo sobrevive porque parece visível. As pessoas podem apontar para tickets fechados, políticas criadas e configurações alteradas. Eles podem mostrar atividade, mas esforço visível não é o mesmo que o modelo operacional estável. E com o copilot em cena, essa lacuna se torna cara muito rapidamente. O sistema passa a usar permissões, exposição de conteúdo e lacunas de rotulagem existentes assim que os usuários começam a solicitar. É o que a maioria das pessoas não vê. O copilot não espera pela maturidade governança. Ele é executado nas permissões que você já tem, na agenda e conteúdo que você já tolera e na postura de auditoria que você já não conseguiu padronizar. Se um locatário limpou o acesso e outro excluiu, ou se um locatário transmite dados de auditoria úteis enquanto outro mal captura o suficiente para a investigação, o copilot exporá essas diferenças imediatamente. Isso não acontece na teoria, acontece por meio do uso.

Se um locatário revisou o amplo acesso ao SharePoint e outro presumiu que era bom o suficiente, a IA encontrará as lacunas. Em um nível mais profundo, cada novo locatário multiplica o problema, não porque os locatários são ruins, mas porque as diferenças não gerenciadas se agravam. Uma nova equipe piloto adiciona uma exceção local. Uma fusão traz outro locatário com rótulos diferentes e um administrador regional copia uma linha de base antiga. Uma unidade de negócios perde acesso mais rápido e nenhuma dessas escolhas parece dramática isoladamente. Coloque-as juntas ao longo de meses e você terá desvios de política, desvios de acesso e desvios de implementação. O resultado é uma equipe de governança que gasta mais tempo reconciliando diferenças do que prevenindo riscos. É aí que o controle manual falha. Parece mais seguro porque os humanos tocam nas configurações, mas na verdade aumenta a inconsistência, porque cada ponto de contato é outra chance para os inquilinos divergirem.

O resultado é a implementação mais lenta onde você quer velocidade, mais esforço de auditoria onde você quer evidências e mais retrabalho onde você quer padrões. O pior de tudo é que isso cria uma exposição oculta onde a liderança espera garantir. Entendi isso quando parei de tratar a governança como tarefa de configuração. Né? Comporta-se mais com decadência. Se você limpar as permissões uma vez, mas nenhum controle é impedido de desviar novamente, a exposição retorna. Se definir uma taxonomia de rótulos uma vez, mas os inquilinos aplicarem mal, a linha de base corrói. Se você aprovar o copilot em ondas sem verificar se o controle subjacente ainda é válido, você não estará escalando com segurança. Você está expandindo mais rápido o que sua governança consegue seguir. Portanto, a métrica que importa aqui é o desvio de acesso. Não apenas se você corrigiu algo, mas a rapidez com que as permissões se espalham novamente após a correção, novamente após a correção.

Isso informa se seu modelo está se mantendo ou se deteriorando. Que a governança não é um projeto que você conclui. É um problema de decadência que você gerencia continuamente. Quando a escala quebra o modelo antigo, a maioria dos líderes recorre à resposta mais familiar, identidade. Eles presumem que, se usuários transitarem entre locatários, a governança irá acompanhá-los de alguma forma. Porque a identidade não resolve a governança. É aqui que muitos programas tomam o caminho errado, porque a identidade parece a resposta limpa. Se usuários se autenticam entre locatários, se o entro está conectado, e se as configurações entre locatários estão ativas, líderes creem que tudo foi resolvido. O acesso parece unificado, o login parece unificado, o diagrama de arquitetura parece organizado, mas a governança do Copilot não se torna unificada apenas porque a identidade pode se mover. Essa suposição falha no ponto em que a IA realmente funciona.

O Copilot fundamenta as respostas no contexto locatário da solicitação, e as orientações da própria Microsoft são claras a esse respeito. O Microsoft 305 Copilot opera dentro do limite de segurança e conformidade do locatário e respeita as permissões do usuário naquele contexto de locatário específico. Um usuário pode alternar o contexto com um convidado, sim, mas o Copilot ainda tem como escopo um locatário por vez. Ele não mescla vários locatários em um espaço de trabalho inteligente por uma única resposta. Portanto, a identidade pode ser cruzada, a governança não. E depois que você separa essas duas coisas, muita linguagem executiva começa a soar perigosamente vaga. Locatários conectados, identidade compartilhada, experiência unificada, Essas fases podem ser verdadeiras em termos de colaboração, mas não são a mesma coisa que dizer que a aplicação de políticas, a base de dados, o registro em log e a validação de controle agora funcionam como um sistema.

Essa lacuna se torna ainda mais óbvia quando você olha para o modo multilocatário do Copilot Studio porque a prévia conta uma história muito específica. Sim, o uso multi-tenant existe, e um agente hospedado em um tenant pode ser usado por outro, mas a autenticação de usuários finais nesse modo ainda não é suportada na versão preview. Usuários convidados não são compatíveis. Conectores personalizados não são compatíveis. Conectores padrão do Graph e do Microsoft 365 não são compatíveis. O TGL não é compatível. Vários recursos de análise não estão disponíveis. As transcrições de conversas também são desativadas nesse modo. Essa não é uma estrutura de governança madura entre inquilinos. Essa é uma visualização limitada, com limites claros. E esses limites são importantes porque quebram a história que muitas equipes de liderança contam a si mesmas. Elas ouvem multi-inquilinos e pressupõem maturidade operacional.

Seus arquitetos ouvem entre inquilinos e pressupõem simetria de política. Suas equipes de controle ouvem o mesmo fornecedor e presumem consistência. Então a implementação começa e as pessoas descobrem comportamentos diferentes, sinais ausentes e lacunas incômodas em torno da autenticação e da análise. Imagine o segundo caso. Uma empresa global configura relações entre inquilinos e pressupõe que a experiência do usuário se estenderá naturalmente ao uso do Copilot. A expectativa parece razoável envolvendo confiança de diretório compartilhado, acesso mais suave e padrões de identidade comum. Mas quando as equipes testam cenários reais do Copilot e do agente, o comportamento é irregular. Alguns dados aparecem apenas em contextos alternos. Alguns conectores esperados não estão disponíveis. Expectativas de auditoria não coincidem com que recursos de visualização expõem. A liderança ainda houve conectada, enquanto a equipe de controles começa a encontrar exceções.

Esse não é um caso tech-extrame. Uma leitura equivocada governa. Porque os auditores não verificam sua história de arquitetura, eles verificam as evidências. Eles perguntam onde os prompts foram executados, qual locatório aplicou a política, quais logs existem e se seus controles eram realmente comparáveis nos ambientes que você descreveu como vinculados. Se seu modelo operacional tratasse a identidade como governança, você não teria uma resposta clara. Portanto, se você se lembrar de uma linha aqui, diga esta. A identidade entre locatários não é inteligência de locatários. A identidade ajuda os usuários a entrar. Ela não informa se o comportamento do copilot é governado de forma consistente, monitorado adequadamente ou seguro para escalar em todos os lugares que sua empresa agora chama de um ambiente. E quando isso fica claro, a resposta não pode ser mais conexões de locatários. Tem que ser arquitetura.

Modelo de governança que realmente funciona. Hub Spoke. Então, como é um modelo de governança real, quando sua plataforma é fragmentada, a identidade é apenas parcial, e os limites do locatário ainda importam. Parece um sistema de Hub Spoke. Não estou sugerindo isso porque o diagrama parece limpo em um slide, mas porque ele realmente corresponde às condições operacionais confusas com as quais você está lidando agora. Você precisa de um local central onde as decisões de governança sejam projetadas, medidas e aplicadas como um único sistema, e então precisa de equipes de locatários locais para executar essas decisões. Essas equipes locais precisam trabalhar dentro de seus próprios limites, sem inventar a sua própria versão das regras, toda vez que sentem um pouco de pressão. Temos que começar com o Hub. O Hub não é um portal de administração, não é um painel brilhante, e definitivamente não é uma equipe central heróica entrando em cada locatário para limpar arquivos manualmente.

Em vez disso, o Hub atua como autoridade de governança final. Este grupo cuida do design da política, das bases de auditoria, dos padrões de rótulo e critérios de lançamento. São eles que decidem o que realmente significa pronto para o Copilot, quais evidências contam como prova e com que rapidez uma lacuna de segurança deve ser fechada. Essa mudança muda toda a conversa. Por causa dessa estrutura, global deixa de ser uma palavra com uma tela mágica e passa a significar um sistema de governança unificado. Você obtém um padrão para controle de competência, um padrão para como você ingere editorias e um padrão para seus rótulos de sensibilidade. Existe um critério claro que deve ser cumprido antes que um locatário possa expandir o acesso ao Copilot para mais usuários. Não se precisa dos raios. Os raios são suas equipes de execução de locatários locais que pegam essa linha de base e aplicam o seu ambiente específico.

São eles que executam a correção, validam os logs e revisam as permissões de acesso amplas. No entanto, eles fazem todo esse trabalho dentro de um espaço de design muito restrito, em vez de um vale-tudo. Se uma equipe local precisasse desviar do plano, há um caminho formal para exceções. E se eles quiserem se mover mais rápido, ainda precisam atender aos compartilhados primeiro. Quando surgem diferenças regionais ou legais, tais questões são documentadas e aprovadas, em vez de absorvidas por alguma solução local que ninguém mais conhece. Essa estrutura é vital porque modelos totalmente centralizados geralmente se prendem a detalhes locais, enquanto modelos totalmente locais caem em consistência total quase que imediatamente. O Hub e o Spoke evitam esses dois padrões de falha. O Hub oferece a consistência necessária, enquanto os Spokes oferecem a velocidade de execução onde o trabalho está realmente acontecendo.

Vamos tornar isso concreto. No Hub, você define o conjunto mínimo de controle de escopo que cada locatário deve executar antes que o Copilot possa crescer. Você define exatamente quais eventos de auditoria espera ver e com que frequência os revisará. Você também cria uma taxonomia de rótulos compartilhados para conteúdo sensível, garantindo que uma tag confidencial não signifique cinco coisas em cinco locatários. Você define o ritmo das revisões, talvez mensalmente para sua postura geral de segurança e com mais frequência em áreas onde a implementação está ativa no momento. No Spokes, o equipe mapeia esses padrões de alto nível para a realidade desse locatário específico. Eles descobrem quais sites ainda têm amplo acesso exposto e quais unidades de negócios estão atrasadas em sua rotulagem. Eles verificam se a auditoria está realmente ativada e se os registros corretos estão visíveis para a equipe de segurança.

Eles procuram administradores locais que possam ter introduzido exceções que nunca foram revisadas oficialmente e decidem se um grupo piloto pode se expandir com segurança ou se precisam parar e consertar as coisas primeiro. E aqui está a regra rígida, porque sem uma regra. Esse modelo é apenas uma sugestão em vez de governança real. Nenhuma implementação do Copilot ocorre em tenants sem registro de auditoria validado, varredura de compartilhamento excessivo e baseline de rótulos. Não estou falando sobre essas coisas serem planejadas ou parcialmente discutidas. Elas devem ser validadas. Se um tenant não provar que essas três condições são atendidas, o rollout pausa. Isso pode parecer rigoroso até você comparar com o custo enorme de limpar uma bagunça depois que os usuários começam a encontrar conteúdo confidencial que você nunca quis expor por meio da IA. Quando você olha dessa forma, essas regras são apenas sensos como um básico.

Outro motivo pelo qual esse modelo funciona tão bem é o momento. Quanto mais você esperar para configurar isso, mais dívida de limpeza estará querendo para si mesmo. Cada tenant que é implementado antes da linha de base se torna outro acúmulo enorme de exceções e evidências ausentes que sua equipe eventualmente terá que resolver. Os líderes geralmente tratam a governança como algo que pode amadurecer após a conclusão da adoção, mas em um mundo copilot com vários inquilinos, essa sequência é completamente inversa. A governança precisa liderar a implementação, ou a implementação criará mais dívidas do que suas equipes podem esperar absorver. Se você estiver liderando isso em nível empresarial, seu próximo passo é muito claro. Crie o hub agora mesmo e defina essa linha de base hoje. Atribua seus raios e coloque seu processo de tratamento de exceções por escrito imediatamente. Você precisa fazer com que global signifique que suas decisões e portões de implementação funcionem como um só sistema mesmo quando os inquilinos não.

Um modelo só importa se realmente muda o que será aplicado amanhã de manhã, o que os líderes devem medir antes de escalar. Um modelo de governança só se mantém se produzir medições que todos compartilhem. Caso contrário, cada inquilino negará que está progredindo em seu próprio idioma, e a liderança receberá atualizações de status sem ter nenhum controle real. Antes de escalar ainda mais o copilot, é necessário um pequeno conjunto de métricas para verificar se a arquitetura se comporta como você espera. Os níveis de atividade não dirão a verdade, e os números de adoção definitivamente não mostrarão os riscos. Você deve começar com a redução do compartilhamento. Este ainda é um dos sinais mais óbvios de que seu ambiente está realmente se tornando mais seguro para a IA. Você precisa analisar grupos de acesso amplos, sites abertos do SharePoint e permissões antigas que concedem muito mais acesso ao que a empresa realmente precisa.

O objetivo aqui não é atingir o número perfeito, mas provar que sua exposição está diminuindo antes que seu alcance do copilot aumente. Se essas duas linhas estiverem se movendo em direções opostas, você está se expandindo muito mais rápido do que está corrigindo os problemas subjacentes. A segunda métrica necessária é a cobertura de observabilidade. Você consegue realmente ver o que o copilot está fazendo com todos os seus inquilinos de uma forma que suporte uma investigação real. A maior parte das pesquisas indica o Microsoft Purview como o local principal de armazenamento de registros, como interações do copilot se a auditoria estiver ativa. Cobertura não é algo que se pode simplesmente presumir. Você precisa saber exatamente quais inquilinos têm gestão de auditoria ativa e quais ainda estão deixando você com visibilidade parcial. Se você não tem registros, não tem governança nem responsabilidade, isso soa direto porque tem que ser.

Se um locatário não puder fornecer evidências úteis do que está acontecendo, ele não estará pronto para escalar com segurança. Você não pode controlar o que não tem permissão para inspecionar e certamente não conseguirá defender suas ações se algo der errado mais tarde. A terceira métrica é o tempo de política para todos os locatários. É aqui que a liderança descobre se o modelo de hub and spoke é realmente real ou apenas decorativo. Uma decisão central não significa absolutamente nada se um locatário aplica esta semana enquanto o outro espera um mês para pensar sobre ela. Você deve medir o tempo que leva desde a aprovação de uma política até que ela seja efetivamente aplicada em cada locatário. Não estou falando sobre o tempo que leva para anunciá-la ou documentá-la, mas o tempo até que ela esteja realmente ativa. Para um programa de IA que se move tão rápido, esse tipo de atraso é apenas outra palavra para risco.

Uma meta prática para a maioria das organizações é menos de 72 horas para alterações padrão. Se o tempo do seu ciclo for muito maior do que isso, você ainda não tem um modelo escalável e tem apenas um problema de coordenação que precisa ser resolvido. A seguir, você precisa analisar a sua taxa de cobertura de roda. Não deixe isso virar uma métrica de vaidade onde um locatário atinge números altos enquanto os outros ficam para trás. O que importa é se seu conteúdo confidencial está rotulado com a consistência necessária para que o comportamento do Copilot não dependa de exposições. Você não está procurando a perfeição aqui, mas sim um nível comparável de controle em todos os locatários da organização. Por fim, você precisa monitorar sua taxa de excesso. Essa métrica informa se seus esforços de limpeza estão realmente se mantendo ao longo. Depois de concluir um projeto de correção, com que rapidez as permissões começam a espalhar novamente?

Com que frequência esses grupos amplos retornam ao sistema? Muitas equipes percebem isso tarde demais, pois mediram a correção apenas uma vez e assumiram que o problema sumiu. A única métrica que importa é a rapidez com que o sistema comece a falhar quando você para de analisá-lo. Esse é o seu painel operacional. Você precisa monitorar a redução de compartilhamento, cobertura de observabilidade, tempo de política, rótulos e desvio de acesso. O ritmo dos seus relatórios é tão importante quanto os números em si. O hub deve ser responsável pelo painel executivo porque a liderança precisa de uma visão única de toda a postura. Enquanto isso, os spokes devem ser responsáveis pela correção porque o trabalho real precisa acontecer onde o limite do locatário está. Uma equipe lê o sistema e a outra equipe o corrige. Deve monitorar esses números antes de expandir, não depois do fato. O risco não está esperando pela sua próxima reunião ou workshop de governança.

Ele já está ativo em cada locatário, onde o copilot pode encontrar exatamente o que seus controles atuais ainda estão permitindo que ele veja. Dois padrões que os líderes continuam perdendo. Continuo vendo dois padrões específicos no campo e ambos acontecem porque os líderes tratam o copilot como um lançamento de software em vez de um grande evento de controle. O primeiro padrão começa quando uma organização implementa o copilot antes de definir uma linha de base de escopo real ou revisar seu acesso ao SharePoint. No primeiro dia, a implementação pode ser perfeita. As licenças são atribuídas, os usuários estão animados e as mensagens internas são todas sobre produtividade. Mas então, prompts normais começam a exibir material que era tecnicamente acessível o tempo todo, mas praticamente invisível para o funcionário médio. Antes da IAR, ninguém passava o dia clicando em sites antigos, pastas desatualizadas ou permissões herdadas para encontrar coisas que não deveria ver.

Mas agora eles não precisam mais fazer isso. Um usuário faz uma pergunta básica, um resumo é retornado e um arquivo aparece. Talvez seja conteúdo confidencial de RH, material financeiro ou informações de negócios que deveriam permanecer dentro de um círculo muito restrito. Não houve violação malware ou quebra de limite de segurança no sentido tradicional. O sistema simplesmente usou as permissões e o estado do conteúdo que o locatário já permitia. Esse é o momento em que muitas equipes finalmente entendem o problema. A IAR não criou exposição, ela apenas removeu o atrito que costumava esconder. Quando isso acontece em um locatário, a confiança dos executivos geralmente cai em toda a organização, porque ninguém pode dizer com certeza uma empresa onde esse mesmo padrão pode aparecer em seguida. O incidente pode parecer local, mas o dano à confiança atinge toda a empresa. O segundo padrão é mais silencioso, mas é igualmente perigoso.

Uma empresa configura relações de identidade entre locatários. Ouve que cenários multilocatários são possíveis e presume que seu modelo operacional está maduro para uma ampla implementação. Em um slide deck se parece um plano sólido. Na realidade, as operações ficam confusas. Uma equipe espera uma experiência tranquila do copilot em todos os ambientes conectados, enquanto outra espera visibilidade comparável, e uma terceira presume que os mesmos controles seguirão o usuário em todos os lugares. Então o uso real começa a expor comportamento irregular, lacunas na autenticação e pontos fracos no que pode realmente ser medido. O problema não é que essas equipes estavam sendo descuidadas? O verdadeiro problema é que elas traduziram conectividade em garantia. Essa suposição criou uma história falsa sobre conformidade. A liderança ouve a palavra conectado e presume que a organização está pronta.

Meses depois, revisões de controle mostram que o comportamento, as evidências e a aplicação variaram bem mais do que se quis admitir no início. Agora compare isso a um padrão melhor. Uma organização diferente opta por desacelerar antes de expandir. Ela define uma linha de base de rótulo primeiro, analisa o acesso amplo primeiro e valida sua visibilidade de auditoria antes de fazer qualquer outra coisa. Eles expandem o Copilot em ondas, não porque tenham medo da adoção, mas porque querem que cada onda produza evidências úteis antes que a próxima comece. Essa organização geralmente se move mais rápido no longo prazo, porque não para constantemente para explicar surpresas, limpar conteúdo exposto ou discutir sobre o que governado realmente deveria significar. Essa é a vantagem que líderes não veem. A boa governança não bloqueia sua implementação. Ela remove o empecilho da implementação depois que a primeira onda é concluída.

A armadilha não é a adoção em si. A armadilha é a adoção não gerenciada entre inquilinos que parecem conectados à distância, mas se comportam de forma muito diferente quando você se aproxima. Decisão que você precisa tomar é realmente muito simples. Você precisa migrar para um modelo de governança de AdHub e Spoke Federal da Lora e precisa parar de confundir a alternância de inquilino por inquilino com controle real. Você deve pausar a expansão do Copilot em qualquer inquilino que não comprove seu registro, revisões de compartilhamento e cobertura de linha de base. Aí assegirá o sistema que você realmente constrói no organograma ao qual você se reporta. Se isso mudou a forma como você pensa sobre a governança do Copilot multilocatário, siga-me, Mirko Peters, no LinkedIn e compartilhe isso com sua equipe se você estiver lidando com esses problemas agora. Obrigado.