Votre équipe de direction pense qu'il s'agit d'une question de déploiement. Ce n'est pas le cas. Il s'agit d'une décision de gouvernance avec un horizon très court, et la pression est forte car copilote n'attend pas que votre politique soit nettoyée ou que votre alignement interne rattrape son otard. Une fois qu'il commence à fonctionner dans votre environnement, il utilise le système exactement tel qu'il l'a trouvé, et c'est là que cela se bloque. La plupart des organisations disposant de plusieurs locataires Microsoft 365 partent du principe qu'elles ont un seul scénario de contrôle de l'IA, principalement parce qu'elles achètent auprès d'un seul fournisseur et gèrent un seul fournisseur et gèrent un seul parc d'identité. Elles entendent un seul discours stratégique de la part de Microsoft et supposent que la réalité correspond à ce discours. Mais les conditions de fonctionnement sont très différentes.

L'IA fonctionne aux limites des locataires, tandis que le risque les traverse. La question n'est donc pas de savoir si nous pouvons activer copilote par... La vraie question est de savoir quel modèle de gouvernance nous permet de nous adapter en toute sécurité à des locataires qui se comportent indépendamment. Avant d'en arriver à ce modèle, nous devons définir le piège. Le piège, des îlots d'IA souverains au sein d'une même entreprise. Dans la plupart des organisations, l'illusion commence par la familiarité. Vous ouvrez Microsoft 365, vous ouvrez Purview, vous ouvrez Entra, vous ouvrez Power Platform, Power Platform. La marque est la même. Le langage administratif semble connecté. Et le mouvement commercial raconte une histoire très claire. Un écosystème, une stratégie, une direction. Mais le modèle de contrôle sous-jacent n'est pas unique, et cela compte plus que la marque. D'après les recherches menées ici, il n'existe pas de centre d'administration mondial unique d'IA avec une parité totale des fonctionnalités qui vous offre un endroit unique pour gouverner copilote proprement sur tous les locataires.

Ce que vous avez en réalité, c'est une pile de contrôle fragmentée. Certaines parties de la gouvernance résident dans Purview, d'autres dans les centres d'administration, et le reste est dispersé entre Entra et Power Platform. Certaines fonctionnalités émergent dans les nouvelles couches de contrôle Microsoft, mais elles ne font pas encore un plan mondial complet et mature sur chaque limite de locataire. Cet écart crée une fausse confiance. Les dirigeants examinent l'écosystème et supposent une centralisation, tandis que les équipes considèrent l'identité partagée et supposent la cohérence. Les achats voient un accord et supposent un modèle d'exploitation, mais chaque locataire a toujours sa propre limite de politique et sa propre limite de données, ce qui signifie qu'en pratique, chacun a sa propre version de la vérité. Donc ce qui se passe réellement est simple. Vous n'avez pas un environnement d'IA d'entreprise unique.

Vous avez plusieurs environnements d'IA qui appartiennent à la même entreprise. Cela donne une image de risque très différente. Un locataire peut avoir une couverture de compétences plus forte, tandis qu'un autre a une adoption d'étiquette plus faible, ou une ingestion d'audit incomplète. Du point de vue du conseil d'administration, cela peut toujours ressembler à un seul programme, mais du point de vue d'un audit ou d'un incident, il ne s'agit pas du tout d'un incident, il ne s'agit pas du tout d'un seul programme. Il s'agit d'un ensemble de conditions d'exploitation distinctes. Et une fois que ces conditions dérivent, les rapports commencent à mentir. Pas intentionnellement, mais structurellement. L'équipe essentielle demande, sommes-nous gouvernés ? Un locataire dit oui parce que l'audit est activé, un autre dit oui parce que les étiquettes existent, même si la couverture est faible. Un troisième dit oui parce que l'identité est connectée.

Un quatrième dit oui parce que Copilot est techniquement déployé. Chaque réponse semble raisonnable en soi, mais aucune d'entre elles ne signifie la même chose. C'est le piège. Vous pensez que vous regardez un plan de contrôle mondial, alors qu'en réalité vous regardez un ensemble d'îlots d'IA souverains au sein d'une même entreprise. Ils sont connectés par la marque et parfois par l'identité, mais ils ne sont pas gouvernés comme un seul système. Et si vous ne retenez rien d'autre de cette section, retenez cette ligne. Il n'existe pas de centre d'administration mondiale de l'IA, seulement l'illusion d'un seul. Une fois que cette illusion disparaît, le problème suivant apparaît rapidement. La plupart des organisations réagissent en procédant une gouvernance locataire par locataire manuellement et elles appellent cela du contrôle. Pourquoi la gouvernance manuelle par locataire s'effondre à grande échelle ?

Une fois que les dirigeants voient le problème des limites, la réponse habituelle semble sensée. Ils disent très bien, nous allons gérer chaque locataire correctement. Une équipe d'administration vérifie les paramètres ici, une autre équipe les répète là. Quelqu'un tient une feuille de calcul, quelqu'un d'autre établit une liste de contrôle. Un groupe de pilotage se réunit une fois par mois et demande si le déploiement est sur la bonne voie. Sur le papier, cela semble discipliné. En pratique, il s'agit d'une répétition manuelle déguisée en gouvernance. Et la raison pour laquelle cela est souhait simple ? La répétition ne produit pas de contrôle, elle produit des variations au fil du temps. Cela se produit parce que chaque locataire évolue à une vitesse différente, chaque administrateur lit les normes un peu différemment et les exceptions locales commencent à sembler justifiées parce que l'entreprise veut progresser maintenant et non après un autre examen central.

Cet ancien modèle survit parce qu'il semble visible. Les gens peuvent signaler les tickets fermés, les politiques créées et les paramètres modifiés. Ils peuvent montrer une activité. Mais un effort visible n'est pas la même chose qu'un modèle d'exploitation stable. Et avec Copilot dans le tableau, cet écart devient très vite coûteux. Le système commence à utiliser les autorisations existantes, l'exposition du contenu existant et les écarts d'étiquetage existants dès que les utilisateurs commencent à demander. C'est ce que la plupart des gens oublient. Copilot n'attend pas la maturité de la gouvernance. Il s'exécute sur les autorisations dont vous disposez déjà, l'hygiène du contenu que vous tolérez déjà et la posture d'audit que vous n'avez pas encore réussi à standardiser. Si un locataire a nettoyé l'accès et qu'un autre l'a supprimé, ou si un locataire diffuse des données d'audit utile tandis qu'un autre en capture à peine suffisamment pour une enquête, Copilot exposera ces différences immédiatement.

Cela n'arrive pas en théorie, cela arrive à l'usage. Si un locataire examine un accès SharePoint général et qu'un autre suppose qu'il est suffisamment bon, l'IA trouvera les écarts. Et à un niveau plus bas, chaque nouveau locataire multiplie le problème. Non pas parce que les locataires sont mauvais, mais parce que les différences non gérées s'accumulent. Une nouvelle équipe pilote ajoute une exception locale. Une fusion amène un autre locataire avec des étiquettes différentes et un administrateur régional copie une ancienne référence. Une unité commerciale demande un accès plus rapide et aucun de ces choix ne semble dramatique pris isolément. Si l'on les additionne sur plusieurs mois, on obtient une dérive des politiques, des accès et du déploiement. Le résultat est une équipe de gouvernance qui passe plus de temps à concilier les différences qu'à prévenir les risques. C'est là que le contrôle manuel échoue.

Cela semble plus sûr car les humains modifient les paramètres, mais cela augmente en réalité les incohérences car chaque point de contact est une nouvelle occasion pour les locataires de diverger. Le résultat est un déploiement plus lent, là où vous voulez de la rapidité, plus d'efforts d'audit là où vous voulez des preuves et plus de retouches là où vous voulez des preuves et plus de retouches là où vous voulez des normes. Pire encore, cela crée une exposition cachée là où la direction attend une assurance. Cela fait-il pour moi lorsque j'ai arrêté de traiter la gouvernance comme une tâche de configuration. Cela se comporte davantage comme une égale. Si vous nettoyez les autorisations une fois mais qu'aucun contrôle ne les empêche de dériver à nouveau, l'exposition revient. Si vous définissez une taxonomie d'étiquette une fois mais que les locataires l'appliquent de manière inégale, la base de référence s'érode.

Si vous approuvez copilote par vague sans vérifier si le contrôle sous-jacent est toujours valable, vous ne vous adaptez pas. En toute sécurité, vous développez simplement plus vite que votre gouvernance ne peut suivre. La mesure qui compte ici est donc la dérive des accès, pas seulement si vous avez corrigé quelque chose mais la vitesse à laquelle les autorisations se propagent à nouveau après la correction. car la gouvernance n'est pas un projet que vous termine. C'est un problème de dégradation que vous gérez en permanence. Et lorsque l'évolutivité brise l'ancien modèle, la plupart des dirigeants se tournent vers la réponse la plus familière, l'identité. Il suppose que si les utilisateurs peuvent se déplacer proprement d'un locataire à l'autre, la gouvernance évoluera d'une manière ou d'une autre avec... Pourquoi l'identité ne résout-elle pas la gouvernance ? C'est là que le nombre de programmes font fausse route car l'identité semble être la réponse claire.

Si les utilisateurs peuvent s'authentifier d'un locataire à l'autre, si on travaille connecté et si des paramètres interlocataires sont en place, les dirigeants supposent que le plus dur est résolu. L'accès semble unifié, la connexion semble unifiée, le diagramme d'architecture semble ordonné, mais la gouvernance copilote ne devient pas unifiée simplement parce que l'identité peut se déplacer. Cette hypothèse échoue au moment où l'IA fonctionne réellement. Copilote ancre les réponses dans le contexte du locataire où la requête s'exécute et les propres directives de Microsoft sont claires sur ce point. Microsoft 365 Copilote fonctionne dans les limites de sécurité et de conformité du locataire et il respecte les autorisations de l'utilisateur dans ce contexte de locataire spécifique. Un utilisateur peut changer de contexte en tant qu'invité ? Oui, mais Copilote est toujours limité à un locataire à la fois.

Il ne fusille un locataire en un seul espace de travail intelligent pour une seule réponse. Ainsi, l'identité peut traverser, mais pas la gouvernance. Et une fois que vous séparez ces deux éléments, une grande partie du langage de la direction commence à paraître dangereusement vague. Locataire connecté, identité partagée, expérience unifiée. Ces expressions peuvent être vraies dans le sens de la collaboration, mais elles ne sont pas identiques au fait de dire que l'application des politiques, la mise à la terre des données, la journalisation et la validation des contrôles fonctionnent désormais comme un seul système. Cet écart devient encore plus évident lorsque vous examinez le mode multilocataire de Copilote Studio car l'aperçu raconte une histoire très spécifique. Oui, l'utilisation multilocataire existe et un agent hébergé dans un locataire peut être utilisé à partir d'un autre locataire.

Mais l'authentification de l'utilisateur final en mode multilocataire n'est pas encore prise en charge dans la version préliminaire. Les utilisateurs invités ne sont pas pris en charge. Les connecteurs perdent son charge. Les connecteurs standard graph et Microsoft 365 ne sont pas pris en charge. Le multigeo n'est pas pris en charge. Plusieurs fonctionnalités d'analyse ne sont pas disponibles. Les transcriptions de conversations sont également désactivées dans ce mode. Il ne s'agit pas d'une structure de gouvernance interlocataire mature. Il s'agit d'une version préliminaire limitée avec des limites claires. Ces limites sont importantes car elles brisent l'histoire que se racontent de nombreuses équipes de direction. Elles entendent multilocataires et supposent une maturité opérationnelle. Leurs architectes entendent interlocataires et supposent une symétrie des politiques. Leurs équipes de contrôle entendent le même fournisseur et supposent une cohérence d'audit.

Puis le déploiement commence et les gens découvrent des comportements différents, des signaux manquants et des lacunes gênantes en matière d'authentification et d'analyse. Imaginez le deuxième cas. Une entreprise mondiale met en place des relations intralocataires et suppose que l'expérience utilisateur s'étendra naturellement à l'utilisation de copilotes. L'attente semble raisonnable impliquant une confiance dans les annuaires partagés, un accès plus fluide et des modèles d'identité communs. Mais lorsque les équipes testent des scénarios réels de copilotes et d'agents, le comportement est inégal. Certaines données n'apparaissent que dans des contextes inversés. Certains connecteurs attendus ne sont pas disponibles. Certaines attentes d'audit ne correspondent pas à ce que les fonctionnalités d'aperçu exposent réellement. La direction entend toujours connecter tandis que l'équipe de contrôle commence à trouver des exceptions.

Ce n'est pas un cas technique limite. C'est une mauvaise interprétation de la gouvernance. Car les auditeurs ne vérifient pas votre histoire d'architecture, ils vérifient les preuves. Ils demandent où les invités ont été exécutées, quels locataires a appliqué la politique, quels journaux existent et si vos contrôles étaient réellement comparables dans les environnements que vous avez décrits comme étant liés. Si votre modèle d'exploitation considérait l'identité comme une gouvernance, vous n'aurez pas de réponse claire. Donc si vous ne retenez qu'une seule ligne ici, disons celle-ci. L'identité interlocataire n'est pas une intelligence interlocataire. L'identité des utilisateurs entrez. Elle ne vous indique pas si le comportement de copilote est rigide de manière cohérente, surveillé correctement ou si peut être mis à l'échelle en toute sécurité, dans toute sécurité, dans toute sécurité, dans tous les endroits que votre emprise a bien environ.

Et une fois que cela devient clair, la réponse ne peut pas être davantage de connexion de locataire. Cela doit être l'architecture. Le modèle de gouvernance qui fonctionne réellement. En étoile. Alors à quoi ressemble un véritable modèle de gouvernance lorsque votre plateforme est fragmentée, que l'identité n'est que partielle et que les limites des locataires ont toujours de l'importance, cela ressemble à un système en étoile. Je ne suggère pas cela parce que le diagramme semble propre sur une diapositive, mais parce qu'il correspond réellement aux conditions de fonctionnement des ordonnées auxquelles vous êtes confronté en ce moment. Vous avez besoin d'un endroit central où les décisions de gouvernance sont conçues, mesurées et appliquées en tant que système unique, puis vous avez besoin d'équipes de locataires locales pour exécuter ces décisions. Ces équipes locales doivent travailler dans le cadre de leurs propres limites sans inventer leur propre version des règles à chaque fois qu'elles ressentent un peu de pression.

Nous devons commencer par le hub. Le hub n'est pas un portail d'administration, ce n'est pas un tableau de bord brillant, et ce n'est certainement pas une équipe centrale héroïque qui se lance dans chaque locataire pour nettoyer manuellement les fichiers. Au lieu de cela, le hub agit comme l'autorité de gouvernance ultime. Ce groupe est responsable de la conception des politiques, des références d'audit, des normes d'étiquetage et des critères de déploiement. Ce sont eux qui décident de ce que signifie réellement prêt pour copiloting A, des preuves qui comptent comme telles et de la rapidité avec laquelle une faille de sécurité doit être comblée. Ce changement change toute la conversation. Grâce à cette structure, le terme qui est global, global n'est cesse d'être un mot désignant, un écran magique et commence à désigner un système de gouvernance unifié. Vous obtenez une norme pour les contrôles de portée, une norme pour la manière dont vous ingérez les audits et une norme pour vos étiquettes de sensibilité.

Il existe une barre claire indiquant ce qui doit être vrai avant qu'un locataire spécifique ne soit autorisé à étendre l'accès à copilote à davantage d'utilisateurs. Ensuite, vous avez besoin des spocs. Les spocs sont vos équipes d'exécution de locataires locales qui prennent cette base de référence et l'appliquent à leur environnement spécifique. Ce sont elles qui exécutent la correction, valident les journaux et examinent les autorisations d'accès étendu. Cependant, elles effectuent tout ce travail dans un espace de conception très étroit plutôt que dans un cadre libre. Si une équipe locale doit s'écarter du plan, il existe un chemin formel pour les exceptions. Si elle souhaite aller plus vite, elle doit toujours d'abord respecter les contrôles partagés. Lorsque des différences régionales ou juridiques surviennent, ces problèmes sont documentés et approuvés au lieu d'être discrètement absorbés par une solution de contournement locale dont personne d'autre n'a connaissance.

Cette structure est essentielle, car les modèles entièrement centralisés s'étouffent généralement dans les détails locaux, tandis que les modèles entièrement locaux sombrent presque immédiatement dans une incohérence totale. Le modèle en étoile et en étoile évite ces deux schémas d'échecs. Le modèle en étoile vous offre la cohérence dont vous avez besoin, tandis que les modèles en étoile vous donnent la vitesse d'exécution là où le travail se déroule réellement. Concrétisons cela. Au niveau du modèle en étoile, vous définissez l'ensemble de contrôles de portée minimales que chaque locataire doit exécuter avant que Copelot ne soit autorisé à se développer. Vous définissez exactement les événements d'audit que vous attendez à voir et la fréquence à laquelle vous les examinerez. Vous créez également une taxonomie d'étiquette partagée pour le contenu sensible afin qu'une étiquette confidentielle ne signifie pas 5 choses différentes pour 5 choses différentes pour 5 locataires différents.

Vous définissez le rythme des examens, peut-être mensuel pour votre posture de sécurité globale, et plus fréquemment dans les zones où le déploiement est actuellement actif. Au niveau du modèle en étoile, votre équipe adapte ses normes de haut niveau à la réalité de ce locataire spécifique. Elle identifie les sites dont l'accès généralisé est encore exposé et les unités commerciales qui sont en retard en matière d'étiquetage. Il vérifie si l'audit est réellement activé et si les bons enregistrements sont visibles par l'équipe de sécurité. Il recherche les administrateurs locaux qui pourraient avoir introduit des exceptions qui n'ont jamais été officiellement examinées et il décide si un groupe pilote peut s'étendre en toute sécurité ou s'il doit d'abord s'arrêter et corriger les choses. Et voici la règle absolue, car sans règle, ce modèle n'est qu'une suggestion au lieu d'une véritable gouvernance.

Aucun déploiement copilote n'a lieu dans un locataire sans une journalisation d'audit validée, une analyse de partage excessif terminée et une base de référence minimale pour la couverture des étiquettes. Je ne parle pas de ces choses qui sont planifiées ou partiellement discutées. Ils doivent être validées. Si un locataire ne peut pas prouver que ces trois conditions sont remplies, le déploiement est suspendu. Cela peut sembler strict jusqu'à ce que vous le compariez au coût énorme du nettoyage d'un désordre après que les utilisateurs commencent à trouver du contenu sensible que vous n'aviez jamais voulu exposer via l'IA. Vu sous cet angle, ces règles relèvent simplement du bon sens. Une autre raison pour laquelle ce modèle fonctionne si bien au timing. Plus vous attendez pour le mettre en place, plus vous créez une dette de nettoyage plus importante par la suite. Chaque locataire qui se déploie avant la ligne de base devient un autre énorme arriéré d'exceptions et de preuves manquantes que votre équipe devra éventuellement éliminer.

Les dirigeants considèrent souvent la gouvernance comme quelque chose qui peut mûrir une fois l'adoption terminée. Mais dans un monde copilote multitenant, cette séquence est complètement inversée, cette séquence est complètement inversée. La gouvernance doit diriger le déploiement, sinon celui-ci créera plus de dettes que vos équipes ne pourront jamais espérer absorber. Si vous dirigez cela au niveau de l'entreprise, votre prochaine étape est très claire. Mettez en place le hub dès maintenant et définissez cette ligne de base aujourd'hui. Attribuez vos rayons et mettez immédiatement par écrit votre processus de gestion des exceptions. Vous devez faire en sorte que global signifie que vos décisions et vos portes de déploiement fonctionnent comme un système unique, même lorsque les locataires eux-mêmes ne le font pas. Un modèle n'a d'importance que s'il change réellement ce qui sera appliqué demain matin, ce que les dirigeants doivent mesurer avant de passer à l'échelle.

Un modèle de gouvernance ne tient la route que s'il produit des mesures que tout le monde partage. Sinon, chaque locataire prétendra faire des progrès dans sa propre langue et la direction recevra des mises à jour de statut sans avoir aucun contrôle réel. Avant de faire évoluer copilote, vous avez besoin d'un petit ensemble de mesures qui vous indiquent si l'architecture se comporte comme vous le pensez. Les niveaux d'activité ne vous diront pas la vérité et les chiffres d'adoption ne vous montreront certainement pas les risques. Vous devriez commencer par réduire le partage excessif. Cela reste l'un des signes les plus évidents que votre environnement devient réellement plus sûr pour l'IA. Vous devez examiner les groupes d'accès étendus, les sites SharePoint ouverts

l'objectif ici n'est pas d'atteindre un chiffre parfait mais de prouver que votre exposition diminue avant que votre portée copilote n'augmente. Si ces deux lignes évoluent dans des directions opposées, vous vous développez beaucoup plus vite que vous ne résolvez les problèmes sous-jacents. La deuxième mesure dont vous avez besoin est la couverture d'Observable. Pouvez-vous réellement voir ce que fait copilot sur tous vos locataires d'une manière qui permette une véritable enquête ? La plupart des recherches indiquent que Microsoft Purview est le principal endroit où sont stockés les enregistrements principaux tels que les interactions copilot. Mais cela suppose que l'audit soit activé partout. La couverture n'est pas quelque chose que vous pouvez simplement supposer qu'elle fonctionne. Vous devez savoir exactement quels locataires ont une ingestion d'audit active et lesquels vous laissent encore une visibilité partielle.

Si vous n'avez pas de journaux, vous n'avez aucune gouvernance ni aucune responsabilité. Cela semble brutal car cela doit l'être. Si un locataire ne peut pas fournir de preuves exploitables de ce qui se passe, ce locataire n'est pas prêt à évoluer en toute sécurité. Vous ne pouvez pas gouverner ce que vous n'êtes pas autorisé à inspecter et vous ne serez certainement pas en mesure de défendre vos actions si quelque chose tourne mal plus tard. La troisième mesure est votre délai de mise en œuvre de la politique pour tous les locataires. C'est là que la direction découvre si le modèle en étoile est réellement réel ou simplement décoratif. Une décision centrale ne signifie absolument rien si un locataire l'applique cette semaine tandis qu'un autre attend un mois pour y réfléchir. Vous devez mesurer le temps qu'il faut entre l'approbation d'une politique et son application effective dans chaque locataire.

Je ne parle pas du temps nécessaire pour l'annoncer ou la documenter mais du temps nécessaire pour qu'elle soit réellement mise en œuvre. Pour un programme d'IA qui évolue aussi rapidement ce type de retard n'est qu'un autre mot pour désigner le risque. Un objectif pratique pour la plupart des organisations est de moins de 72 heures pour les modifications standards. Si votre temps de cycle est beaucoup plus long que cela vous n'avez pas encore de modèle évolutif vous avez juste un problème de coordination à résoudre. Ensuite vous devez examiner votre couverture des étiquettes. Ne laissez pas cela se transformer en une mesure de vanité ou un locataire atteint des chiffres élevés tandis que les autres sont à la traîne. Ce qui compte vraiment c'est de savoir si votre compte du sensible est étiqueté de manière suffisamment cohérente pour que le comportement de cohérente pour que le comportement de copilote ne soit uniquement basé sur les utilisateurs.

Vous ne recherchez pas la perfection ici mais vous recherchez un niveau de contrôle comparable pour chaque locataire de l'organisation. Enfin vous devez suivre votre taux de dérive d'accès. Cette mesure vous indique si vos efforts de nettoyage sont réellement efficaces au fil du temps. Une fois que vous avez terminé un projet de correction à quelle vitesse ces autorisations recommencent-elles à se propager ? A quelle fréquence ces grands groupes reviennent-ils dans le système ? De nombreuses équipes s'en rendent compte trop tard car elles ont mesuré la correction une fois et ont supposé que le problème avait disparu à jamais. Ce n'était pas le cas. La seule mesure qui compte est la vitesse à laquelle le système commence à déraper une fois que vous cessez de le surveiller. Il s'agit de votre tableau de bord opérationnel. Vous devez suivre la réduction du partage excessif, la couverture de l'observabilité, le délai de mise en place de la politique, la couverture des étiquettes et la dérive des accès.

Le rythme de vos rapports est tout aussi important que les chiffres eux-mêmes. Le hub doit être propriétaire du tableau de bord exécutif car la direction a besoin d'une vue unique de l'ensemble de la posture. Pendant ce temps, les spokes doivent être responsables de la correction car le travail réel doit être effectué là où se trouve la limite du locataire. Une équipe lie le système et l'autre équipe le corrige. Vous devez suivre ces chiffres avant de vous développer, pas après coup. Le risque n'attend pas votre prochaine réunion ou votre prochain atelier de gouvernance. Il est déjà actif dans chaque locataire où Copilot peut trouver exactement ce que vos contrôles actuels lui permettent encore de voir. Les deux modèles que les dirigeants continuent d'oublier. Je continue de voir deux modèles spécifiques sur le terrain et ils se produisent tous les deux parce que les dirigeants traitent Copilot comme un lancement de logiciel plutôt que comme un lancement de logiciel plutôt que comme un manager.

Le premier modèle commence lorsqu'une organisation déploie Copilot avant de définir une véritable base de référence de portée ou de revoir son accès SharePoint. Le premier jour, le déploiement semble parfait. Les licences sont attribuées, les utilisateurs sont enthousiastes et la messagerie interne est axée sur la productivité. Mais ensuite, les invites normales commencent à afficher des informations qui étaient techniquement accessibles depuis le début mais pratiquement invisibles pour l'employé moyen. Moyen. Avant l'IA, personne ne passait sa journée à cliquer sur d'anciens sites, des dossiers obsolètes ou des autorisations héritées pour trouver des choses qu'il ne devrait pas voir. Mais maintenant, ce n'est plus nécessaire. Un utilisateur pose une question simple, un résumé revient et un fichier apparaît. Il peut s'agir de contenu RH sensible, de documents financiers ou d'informations sur une transaction qui était censée rester dans un cercle très restreint.

Il n'y a eu aucune violation, aucun logiciel malveillant et aucune limite de sécurité brisée au sens traditionnel du terme. Le système a simplement utilisé les autorisations et l'état du contenu que le locataire avait déjà autorisé. C'est à ce moment-là que de nombreuses équipes comprennent enfin le problème. L'IA n'a pas créé l'exposition. Elle a simplement supprimé la friction qui l'a masquée au parrain. Une fois que cela se produit dans un locataire, la confiance des dirigeants diminue généralement dans toute l'organisation car personne ne peut dire avec certitude où ce même schéma pourrait se reproduire. L'incident peut sembler local mais les dommages causés à la confiance sont à l'échelle de l'entreprise. Le deuxième modèle est plus discret mais il est tout aussi dangereux. Une entreprise met en place des relations d'identité entre locataires. En tant que des scénarios multilocataires sont possibles et suppose que son modèle d'exploitation est suffisamment mature pour un déploiement à grande échelle.

Sur un diaporama, cela ressemble à un plan solide. En réalité, les opérations deviennent désordonnées. Une équipe s'attend à une expérience copilote fluide dans tous les environnements connectés tandis qu'une autre s'attend à une visibilité comparable et une troisième suppose que les mêmes contrôles suivront l'utilisateur partout. Ensuite, l'utilisation réelle commence à exposer un comportement inégal, des lacunes dans l'authentification et des points faibles dans ce qui peut être réellement mesuré. Le problème n'est pas que ces équipes ont été négligentes. Le vrai problème est qu'elles ont traduit la connectivité en assurance. Cette hypothèse crée une fausse histoire sur la conformité. La direction entend le mot connecté et suppose que l'organisation est prête. Des mois plus tard, les examens de contrôle révèlent que le comportement, les preuves et l'application varient bien plus que quiconque ne voulait l'admettre au début.

Maintenant, comparons cela à un meilleur modèle. Une autre organisation choisit de ralentir avant de passer à l'échelle. Ils définissent d'abord une ligne de base d'étiquette, examinent d'abord l'accès général et valident leur visibilité d'audit avant de faire quoi que ce soit d'autre. Ils étendent copilote par vague, non pas parce qu'ils ont peur de l'adoption, mais parce qu'ils veulent que chaque vague produise des preuves exploitables avant le début de la suivante. Cette organisation évolue généralement plus rapidement à long terme, car elle ne s'arrête pas constamment pour expliquer les surprises, nettoyer le contenu exposé ou discuter de ce que la gouvernance s'était censée signifier. Oui. C'est l'avantage que la plupart des dirigeants négligent. Une bonne gouvernance ne bloque pas votre déploiement. Elle supprime le ralentissement du déploiement une fois la première vague terminée.

Piège n'est pas l'adoption en elle-même. Le piège est une adoption non gérée entre des locataires qui semblent connectés de loin mais qui se comportent très différemment lorsque vous vous en approchez, mais... La décision que vous devez prendre est en fait très simple. Vous devez passer à un modèle de gouvernance de l'IA en étoile fédérée dès maintenant et vous devez cesser de confondre le basculement locataire par locataire avec le contrôle réel. Vous devez suspendre votre expansion copilote

l'IA va suivre le système que vous construisez réellement et non l'organigramme auquel vous faites rapport. Si cela a changé votre façon de penser la gouvernance multitenante copilote, suivez-moi, Mirko Peter, sur LinkedIn et partagez cela avec votre équipe si vous êtes confronté à ces problèmes en ce moment.