Ihr Führungsteam ist der Meinung, dass es sich hierbei um eine Rollout-Frage handelt. Das ist nicht. Dies ist eine Governance-Entscheidung mit einer sehr kurzen Startbahn. Und der Druck ist groß, da Co-Pilot nicht auf ihre Richtlinienbereinigung oder ihre interne Abstimmung wartet. Sobald es in ihrer Umgebung in Betrieb genommen wird, verwendet es das System genau so, wie es es vorfindet. Und genau hier liegt das Problem. Die meisten Organisationen mit mehreren Microsoft 365 Mandanten gehen davon aus, dass sie über eine einzige KI-Steuerungsstrategie verfügen, hauptsächlich weil sie von einem Anbieter kaufen und einen Identitätsbestand verwalten. Sie hören eine strategische Erzählung von Microsoft und gehen davon aus, dass die Realität mit dem Pitch übereinstimmt. Die Betriebsbedingungen sind jedoch ganz anders. KI arbeitet an Mandantengrenzen, während sich das Risiko quer durch diese erstreckt.

Die Frage ist also nicht, ob wir Co-Pilot überall aktivieren können. Die eigentliche Frage ist, welches Governance-Modell uns eine sichere Skalierung über Mandanten ermöglicht, die sich unabhängig voneinander verhalten. Bevor wir zu diesem Modell kommen, müssen wir die Falle definieren. Die Falle. Souveräne KI-Inseln innerhalb eines Unternehmens. In den meisten Organisationen beginnt die Illusion mit Vertrautheit. Sie öffnen Microsoft 365, sie öffnen Purview, sie öffnen Entra, sie öffnen Power-Plattformen. Das Branding ist dasselbe. Die Admin-Sprache fühlt sich einheitlich an. Und der Werbespot erzählt eine sehr klare Geschichte. Ein Ökosystem, eine Strategie, eine Richtung. Aber das zugrunde liegende Kontrollmodell ist nicht einheitlich und das ist wichtiger als das Branding. Basierend auf den hier durchgeführten Untersuchungen gibt es kein einzelnes globales KI-Admin-Center mit vollständiger Funktionsparität, das ihnen eine zentrale Anlaufstelle für die saubere Steuerung von Co-Piloten bei allem anderen erbietet.

Unterdessen haben sie es mit einem fragmentierten Kontrollschrauben zu tun. Teile der Governance befinden sich in Purview, andere Teile in Admin-Centern und der Rest ist über Entra und Power-Plattformen verstreut. Einige Features entstehen in neueren Microsoft-Steuerungsebenen, bilden aber noch keine vollständig ausgereifte globale Ebene über alle Mandantengrenzen hinweg. Diese Lücke schafft trügerisches Vertrauen. Führungskräfte betrachten das Ökosystem und gehen von einer Zentralisierung aus, während Teams auf eine gemeinsame Identität achten und von Konsistenz ausgehen. Die Beschaffung sieht eine Vereinbarung und geht von einem Betriebsmodell aus. Aber jeder Mandant hat immer noch seine eigenen Richtlinien und Datengrenzen, was in der Praxis bedeutet, dass jeder Mandant seine eigene Version der Wahrheit hat. Was er tatsächlich passiert ist einfach. Sie haben keine einheitliche KI-Unternehmensumgebung.

Sie haben mehrere KI-Umgebungen, die zufällig zum selben Unternehmen gehören. Das ist ein ganz anderes Risikobild. Ein Mandant verfügt möglicherweise über eine stärkere Abdeckung des Zuständigkeitsbereichs, während ein anderer eine schwächere Label-Akzeptanz oder eine unvollständige Audit-Erfassung aufweist. Aus Vorstandsebene mag dies immer noch wie ein Programm aussehen. Aus der Sicht eines Audits oder Vorfalls handelt es sich jedoch überhaupt nicht um ein Programm. Es handelt sich um eine Ansammlung separater Betriebsbedingungen. Und sobald diese Bedingungen abweichen, beginnt die Berichterstattung zu lügen. Nicht absichtlich, sondern strukturell. Das Essential-Team fragt, werden wir kontrolliert? Ein Mandant sagt ja, weil das Audit aktiviert ist. Ein anderer sagt ja, weil Labels vorhanden sind, auch wenn die Abdeckung schwach ist. Ein dritter sagt ja, weil die Identität verbunden ist.

Ein vierter sagt ja, weil Co-Pilot technisch bereitgestellt wurde. Jede Antwort klingt für sich genommen vernünftig, aber keine von ihnen bedeutete selten. Das ist die Falle. Sie denken, Sie betrachten eine globale Kontrollebene. Dabei betrachten Sie in Wirklichkeit eine Reihe souveräner KI-Inseln innerhalb eines Unternehmens. Sie sind über die Marke und manchmal über die Identität verbunden, werden aber nicht als ein System kontrolliert. Und wenn Sie sich an nichts anderes aus diesem Abschnitt erinnern, merken Sie sich diese Zeile. Es gibt kein globales KI-Admin-Center, sondern nur die Illusion eines solchen. Ist diese Illusion erst einmal zerbrochen, zeigt sich schnell das nächste Problem. Die meisten Unternehmen reagieren darauf, indem sie die Governance für jeden Mandanten manoliert. Das nennen sie Kontrolle. Warum die manuelle Governance pro Mandant bei großem Umfang zusammen. Sobald Führungskräfte das Problem der Grenzen erkennen, klingt die übliche Antwort vernünftig.

Sie sagen, okay, wir verwalten jeden Mandanten ordnungsgemäß. Ein Admin-Team prüft hier die Einstellung, ein anderes Team wiederholt sie dort. Jemand führt eine Tabellenkalkulation, ein anderes eine Checkliste. Einmal im Monat trifft sich eine Lenkungsgruppe und fragt, ob der Rollout auf Kurs ist. Auf dem Papier wirkt das diszipliniert. In der Praxis ist es eine manuelle Wiederholung, die als Governance getarnt ist. Und der Grund, warum das scheitert, ist einfach. Wiederholung erzeugt keine Kontrolle, sondern im Laufe der Zeit Variationen. Das geschieht, weil sich jeder Mandant anders bewegt, jeder Admin die Standards ein wenig anders liest und lokale Ausnahmen sich gerechtfertigt anfühlen, weil das Unternehmen sofort Fortschritte möchte und nicht erst nach einer weiteren zentralen Überprüfung. Dieses alte Modell überlebt, weil es nachvollziehbar ist. Mitarbeiter können auf geschlossene Tickets, erstellte Richtlinien und geänderte Einstellungen verweisen.

Sie können Aktivitäten vorweisen, doch sichtbarer Aufwand ist nicht dasselbe wie ein stabiles Betriebsmodell. Und mit Co-Pilot wird diese Lücke sehr schnell teuer. Das System beginnt vorhandene Berechtigungen, vorhandene Inhaltsfreigaben und vorhandene Kennzeichnungslücken zu verwenden, sobald Benutzer mit der Eingabeaufforderung beginnen. Das ist es, was die meisten Leute übersehen. Co-Pilot wartet nicht auf die Reife der Governance. Das läuft auf der Grundlage der Berechtigungen, die sie bereits haben, der Inhaltshygiene, die sie bereits tolerieren und der Prüfstruktur, die sie bereits nicht standardisiert haben. Wenn ein Mandant den Zugriff bereinigt und ein anderer gelöscht hat oder wenn ein Mandant nützliche Prüfdaten streamt, während ein anderer kaum genug für die Untersuchung erfasst, deckt Co-Pilot diese Unterschiede sofort auf. Das geschieht nicht theoretisch, sondern durch die Nutzung.

Wenn ein Mandant den umfassenden SharePoint-Zugriff überprüft hat und ein anderer davon ausgeht, dass er gut genug ist, findet die KI die Lücken. Und eine Ebene tiefer vervielfacht jeder neue Mandant das Problem. Nicht, weil die Mandanten schlecht sind, sondern weil sich nicht verwaltete Unterschiede häufen. Ein neues Pilotteam fügt eine lokale Ausnahme hinzu. Eine Fusion bringt einen weiteren Mandanten mit anderen Bezeichnungen ein und ein regionaler Administrator kopiert einen alten Administrator, kopiert eine alte Basislinie. Ein Geschäftsbereich fordert einen schnelleren Zugriff an und keine dieser Entscheidungen wirkt für sich genommen dramatisch. Führt man sie über Monate zusammen, erhält man Richtlinienabweichungen, Zugriffsabweichungen und Rollout-Riffen. Das Ergebnis ist ein Governance-Team, das mehr Zeit mit dem Abgleichen von Differenzen als mit der Risikoprävention verbringt.

Hier greift die manuelle Kontrolle. Sie fühlt sich sicherer an, weil Menschen die Einstellungen beeinflussen, aber sie skaliert tatsächlich die Inkonsistenz, da jeder Berührungspunkt eine weitere Chance für Mandanten darstellt, voneinander abzuweichen. Das Ergebnis ist ein langsamerer Rollout, wo Geschwindigkeit gefragt ist, mehr Prüfaufwand, wo Nachweise gefragt sind und mehr Nacharbeit, wo Standards gefragt sind. Das Schlimmste ist jedoch, dass dadurch versteckte Risiken entstehen, wo die Führungskräfte Sicherheit erwarten. Das wurde mir klar, als ich aufhörte, Governance als Einrichtungsaufgabe zu betrachten. Das ist nicht. Es verhält sich eher wie verfallen. Wenn Sie Berechtigung einmal bereinigen, aber keine Kontrolle, Sie vor erneuten Abweichungen bewahrt, kehrt das Risiko zurück. Wenn Sie eine Label-Taxonomie einmal definieren, diese aber von den Mandanten ungleichmäßig angewendet wird, erodiert die Basislinie.

Wenn Sie Co-Pilot in Wellen genehmigen, ohne zu überprüfen, ob die zugrunde liegende Kontrolle noch gilt, skalieren Sie nicht sicher. Sie expandieren einfach schneller, als Ihre Governance mithalten kann. Die hier wichtige Kennzahl ist also die Zugriffsverschiebung und nicht nur, ob Sie etwas behoben haben, sondern wie schnell sich Berechtigungen nach der Behebung wieder ausbreiten. Daran können Sie erkennen, ob Ihr Modell hält oder nachlässt. Denn Governance ist kein Projekt, das Sie abschließen. Es handelt sich um ein Problem des Zerfalls des Kontinuels. Und wenn die Skalierung das alte Modell überfordert, greifen die meisten Führungskräfte auf die bekannteste Antwort zurück, Identität. Sie gehen davon aus, dass sich die Governance irgendwie mit Ihnen verschieben wird, wenn sich Benutzer problemlos zwischen Mandanten bewegen können. Besonders der Fall. Warum löst Identität das Problem der Governance nicht?

Hier schlagen viele Programme den falschen Weg ein, da Identität die saubere Antwort zu sein scheint. Wenn sich Benutzer mandantenübergreifend authentifizieren können, Entra verbunden ist und mandantenübergreifende Einstellungen vorhanden sind, gehen Führungskräfte davon aus, dass der Schwereteil gelöst ist. Der Zugriff scheint vereinheitlicht zu sein, die Anmeldung sieht vereinheitlicht aus, das Architekturdiagramm sieht übersichtlich aus, aber die Co-Pilot Governance wird nicht vereinheitlicht, nur weil die Identität verschoben werden kann. Diese Annahme scheitert an dem Punkt, an dem die KI tatsächlich funktioniert. Co-Pilot erdet Antworten innerhalb des Mandanten-Kontexts, in dem die Anforderung ausgeführt wird und die eigenen Richtlinien von Microsoft sind diesbezüglich eindeutig. Microsoft 3 von von FaceTime Co-Pilot arbeitet innerhalb der Sicherheits- und Compliance-Grenzen des Mandanten und respektiert die Berechtigungen des Benutzers in diesem spezifischen Mandanten-Kontext.

Ein Benutzer kann als Gast den Kontext wechseln, ja, aber Co-Pilot ist immer noch auf jeweils einen Mandanten beschränkt. Es werden nicht mehrere Mandanten für eine einzelne Antwort in einem intelligenten Arbeitsbereich zusammengeführt. Die Identität kann also durchlaufen werden, die Governance nicht. Und sobald man diese beiden Aspekte trennt, beginnen viele Begriffe aus der Geschäftswelt gefährlich vage zu klingen. Verbundene Mandanten, gemeinsame Identität, einheitliche Erfahrung. Diese Ausdrücke mögen für die Zusammenarbeit richtungsweisend sein. Sie sind aber nicht dasselbe wie die Aussage, dass Richtliniendurchsetzung, Datenerdung, Protokollierung und Kontrollvalidierung und Kontrollvalidierung jetzt als ein System zusammen. Diese Lücke wird noch offensichtlicher, wenn man sich den mehr instanzenfähigen Modus von Co-Pilot-Studio ansieht, der die Vorschau eine ganz bestimmte Geschichte erzählt.

Tipp. Ja, die Verwendung mit mehreren Mandanten ist möglich. Und ein mit einem Mandanten gehosteter Agent kann von einem anderen Mandanten aus verwendet werden. Die Endbenutzer-Authentifizierung im mehr instanzenfähigen Modus wird in der Vorschau jedoch noch nicht unterstützt. Gastbenutzer werden nicht unterstützt. Benutzer-Definierte-Connectors werden nicht unterstützt. Graph und Microsoft Red 65 Standard-Connectors werden nicht unterstützt. Multi-Geo wird nicht unterstützt. Verschiedene Analysefunktionen sind nicht verfügbar. Unterhaltungstranskripte sind in diesem Modus ebenfalls deaktiviert. Das ist keine ausgereifte, mandantenfähige Governance-Struktur. Das ist eine begrenzte Vorschau mit klaren Grenzen. Und diese Grenzen sind wichtig, weil sie die Geschichte, die sich viele Führungsteams erzählen, zunichte machen. Sie hören von mehreren Mandanten und gehen von betrieblicher Reife aus.

Ihre Architekten hören von mandantenfähig und gehen von richtigen Symmetrie aus. Ihre Kontrollteams hören von demselben Anbieter und gehen von einer einheitlichen Prüfung aus. Dann beginnt der Rollout und die Mitarbeiter entdecken unterschiedliche Verhaltensweisen, fehlende Signale und unangenehme Lücken bei der Authentifizierung und Analyse. Stellen Sie sich den zweiten Fall vor. Ein globales Unternehmen richtet mandantenübergreifende Beziehungen ein und geht davon aus, dass sich die Benutzererfahrung auf natürliche Weise auf die Verwendung von Co-Pilot auswirkt. Die Erwartung klingt vernünftig und umfasst eine gemeinsame Vertrauensstellung in Verzeichnisse, einen reibungsloseren Zugriff und Kompetitizien. Wenn Teams jedoch tatsächliche Co-Pilot- und Agent-Szenarien testen, ist das Verhalten uneinheitlich. Einige Daten werden nur in gewechselten Kontexten angezt. Einige erwartete Konnektoren sind nicht verfügbar.

Einige Prüferwartungen stimmen nicht mit den tatsächlichen Vorschaufunktionen überein. Die Geschäftsleitung hört immer noch eine Verbindung, während das Kontrollteam anfängt, Ausnahmen zu finden. Es ist kein technischer Sonderfall. Es ist eine Fehlinterpretation der Governance. Denn Prüfer überprüfen nicht ihre Architekturgeschichte, sondern Beweise. Sie fragen, wo Eingabeaufforderungen ausgeführt wurden, welche Richtlinie vom Mandanten durchgesetzt wurde, welche Protokolle vorhanden sind und ob ihre Kontrollen tatsächlich in den von ihnen, als er sich in den von ihnen als verknüpft beschriebenen Umgebungen vergleichbar waren. Wenn ihr Betriebsmodell Identität als Governance behandelt hat, erhalten sie keine eindeutige Antwort. Wenn sie sich also eine Zeile hier merken, dann dies. Mandantenübergreifende Identität ist nicht mandantenübergreifende Intelligent. Identität hilft Benutzer beim Zugriff.

Sie sagt ihnen nicht, ob das Co-Pilotverhalten konsistent gesteuert, ordnungsgemäß überwacht oder sicher an allen Orten skaliert werden kann, an denen ihr Unternehmen jetzt eine Umgebung bezeichnet. Und wenn das klar ist, kann die Antwort nicht mehr Mandantenverbindungen sein. Es muss Architektur sein. Das Governance-Modell, das tatsächlich funktioniert. Hub-and-Spoke. Wie sieht nun ein echtes Governance-Modell aus, wenn ihre Plattform fragmentiert ist, die Identität nur teilweise vorhanden ist und Mandantenkranzen immer noch eine Rolle spielen? Es ähnelt einem Hub-and-Spoke-System. Ich schlage dies nicht vor, weil das Diagramm auf einer Folie übersichtlich aussieht, sondern weil es tatsächlich den unübersichtlichen Betriebsbedingungen entspricht, mit denen sie es derzeit zu tun haben. Sie benötigen einen zentralen Ort, an dem Governance-Entscheidungen als ein einziges System entworfen, gemessen und durchgesetzt werden und dann?

Benötigen Sie lokale Mandantenteams, um diese Entscheidung umzusetzen. Diese lokalen Teams müssen innerhalb ihrer eigenen Grenzen arbeiten, ohne jedes Mal, wenn sie ein wenig Druck verspüren, ihre eigene Version der Regeln zu erfinden. Wir müssen mit dem Hub beginnen. Der Hub ist kein Verwaltungsportal, kein schickes Dashboard und definitiv kein heldenhaftes zentrales Team, das sich in jeden einzelnen Mandanten begibt, um Dateien manuell zu bereinigen. Stattdessen fungiert der Hub als ultimative Governance-Instanz. Diese Gruppe ist für das Richtlinien-Design, die Prüfbasis-Linien, die Label-Standards und die Rollout-Kriterien verantwortlich. Sie entscheiden, was bereit für Co-Pilot tatsächlich bedeutet, welche Beweise als Beleg gelten und wie schnell eine Sicherheitslücke geschlossen werden muss. Diese Verschiebung verändert die gesamte Konversation. Aufgrund dieser Struktur ist global nicht mehr nur ein Wort für einen magischen Bildschirm, sondern bedeutet ein einheitliches Governance-System.

Sie erhalten einen Standard für Zuständigkeitsbereichskontrollen, einen Standard für die Erfassung von Audits und einen Standard für ihre Vertraulichkeitsbezeichnung. Es gibt eine klare Messlatte dafür, was erfüllt sein muss, bevor ein bestimmter Mandant den Co-Pilot-Zugriff auf mehr Benutzer erweitern darf. Dann brauchen Sie die Speichen. Die Speichen sind ihre lokalen Mandanten-Ausführungsteams, die diese Basislinie nehmen und auf ihre spezifische Umgebung anwenden. Sie sind diejenigen, die die Korrektur durchführen, die Protokolle validieren und umfassende Zugriffsberechtigungen überprüfen. Sie führen all diese Arbeiten jedoch in einem sehr engen Entwurfsbereich durch und haben nichts Freiraum. Wenn ein lokales Team vom Plan abweichen muss, gibt es einen formellen Weg für Ausnahmen. Und wenn Sie schneller vorankommen wollen, müssen Sie trotzdem zuerst die gemeinsamen Kontrollen einhalten.

Wenn regionale oder rechtliche Unterschiede auftreten, werden diese Probleme dokumentiert und genehmigt, anstatt stillschweigend in einer lokalen Problemumgehung aufgegangen zu sein, von der sonst niemand weiß. Diese Struktur ist von entscheidender Bedeutung, da vollständig zentralisierte Modelle in der Regel an lokalen Details scheitern, während vollständig lokale Modelle fast sofort in völlige Inkonsistenz abdriften. Hub & Spoke vermeidet beide Fehlermuster. Der Hub bietet Ihnen die benötigte Konsistenz, während die Spokes Ihnen die Ausführungsgeschwindigkeit dort bieten, wo die Arbeit tatsächlich stattfindet. Machen wir das konkret. Im Hub definieren Sie den Mindestkontrollsatz für den Zuständigkeitsbereich, den jeder Mandant ausführen muss, bevor Co-Pilot wachsen darf. Sie definieren genau, welche Prüfereignisse Sie erwarten und wie oft Sie diese überprüfen werden. Außerdem erstellen Sie eine gemeinsame Bezeichnungstaxonomie für sensible Inhalte, damit ein vertrauliches Tag nicht fünf verschiedene Dinge für fünf verschiedene Mandanten bedeutet.

Sie legen den Rhythmus für Überprüfungen fest, vielleicht monatlich für Ihre allgemeine Sicherheitslage und häufiger in Bereichen, in denen der Rollout gerade aktiv ist. Im Spoke ordnet Ihr Team diese hohen Standards den Realitäten des jeweiligen Mandanten zu. Sie finden heraus, welche Websites noch immer einen breiten Zugriff haben und welche Geschäftsbereiche bei Ihrer Kennzeichnung hinterherhinken. Sie überprüfen, ob das Audit tatsächlich aktiviert ist und ob die richtigen Datensätze für das Sicherheits-Team sichtbar sind. Sie suchen nach lokalen Administratoren, die möglicherweise Ausnahmen eingeführt haben, die nie offiziell überprüft wurden, und entscheiden, ob eine Pilotgruppe sicher erweitert werden kann oder ob sie angehalten und zuerst Probleme behoben werden müssen. Und hier ist die feste Regel, denn ohne Regel ist dieses Modell nur ein Vorschlag und keine tatsächliche Governance.

Kein Co-Pilot-Rollout erfolgt in einem Mandanten ohne validierte Audit-Protokollierung, einen abgeschlossenen Oversharing-Scan und eine Mindestbasis für die Kennzeichnungsabdeckung. Ich spreche nicht davon, dass diese Dinge geplant oder teilweise besprochen werden. Sie müssen validiert werden. Wenn ein Mandant nicht nachweisen kann, dass diese drei Bedingungen erfüllt sind, wird der Rollout unterbrochen. Das mag streng klingen, bis man es mit den enormen Kosten vergleicht, die durch die Bereinigung eines Chaos entstehen, wenn benutzer sensible Inhalte finden, die sie niemals über KI-Preis geben wollten. Wenn man es so betrachtet, sind diese Regeln einfach nur gesunder Menschen verstanden. Ein weiterer Grund, warum dieses Modell so gut funktioniert, ist das Timing. Je länger sie mit der Einrichtung warten, desto mehr Schulden verursachen sie später. Jeder Mandant, der vor der Baseline eingeführt wird, führt zu einem weiteren riesigen Rückstand an Ausnahmen und fehlenden Nachweisen, den ihr Team irgendwann aufarbeiten muss.

Führungskräfte behandeln Governance oft als etwas, das nach Abschluss der Einführung ausgereift ist. In einer Multitenant-Co-Pilot-Welt ist diese Reihenfolge jedoch völlig umgekehrt. Die Governance muss den Rollout leiten. Andernfalls verursacht der Rollout mehr Schulden, als ihre Teams jemals bewältigen können. Wenn Sie dies auf Unternehmensebene leiten, ist der nächste Schritt ganz klar. Richten Sie jetzt den Hub ein und definieren Sie noch heute diese Baseline. Weisen Sie Ihre Speichen zu und halten Sie Ihren Prozess zur Ausnahmebehandlung sofort schriftlich fest. Sie müssen global sicherstellen, dass Ihre Entscheidungen und Ihre Rollout-Gates als ein einziges System funktionieren, selbst wenn dies für die Mandanten selbst nicht der Fall ist. Ein Modell ist nur dann von Bedeutung, wenn es tatsächlich Änderungen vor in einer Änderung vornimmt. Führungskräfte sollten dies messen, bevor Sie skalieren.

Ein Governance-Modell ist nur dann schlüssig, wenn es Kennzahlen liefert, die von allen geteilt werden. Andernfalls behauptet jeder Mandant, dass er in seiner eigenen Sprache Fortschritte macht und die Führungskräfte erhalten Statusaktualisierungen, ohne wirkliche Kontrolle zu haben. Bevor Sie Co-Pilot weiter skalieren, benötigen Sie eine kleine Reihe von Metriken, die Ihnen Aufschluss darüber geben, ob sich die Architektur so verhält, wie Sie es erwarten. Aktivitätsniveaus sagen Ihnen nicht die Wahrheit und Akzeptanzzahlen zeigen Ihnen definitiv nicht die Risiken. Sie sollten mit der Reduzierung von Oversharing beginnen. Dies ist nach wie vor eines der offensichtlichsten Anzeichen dafür, dass Ihre Umgebung tatsächlich sicherer für KI wird. Sie müssen sich breite Zugriffsgruppen, offene SharePoint-Websites und alte Berechtigungen ansehen, die viel mehr Zugriff gewähren, als das Unternehmen tatsächlich benötigt.

Das Ziel besteht hier nicht darin, eine perfekte Zahl zu erreichen, sondern nachzuweisen, dass Sie Ihre Gefährdung verringert, bevor Sie Ihre Co-Pilot-Reichweite erhöhen. Wenn sich diese beiden Linien in entgegengesetzte Richtungen bewegen, expandieren Sie viel schneller, als Sie die zugrunde liegenden Probleme beheben. Die zweite Metrik, die Sie benötigen, ist die Abdeckung der Observe. Können Sie tatsächlich sehen, was Co-Pilot in allen Ihren Mandanten tut, und zwar so, dass eine echte Untersuchung unterstützt wird? Die meisten Untersuchungen deuten darauf hin, dass Microsoft Purview der Hauptspeicherort für zentrale Datensätze wie Co-Pilot-Interaktion ist. Dies setzt jedoch voraus, dass die Überwachung überall aktiviert ist. Man kann nicht einfach davon ausgehen, dass die Abdeckung funktioniert. Sie müssen genau wissen, bei welchen Mandanten die Überwachung der Datenerfassung aktiv ist und bei welchen nur teilweise Transparenz besteht.

Ohne Protokolle gibt es keine Governance und keine Verantwortlichkeit. Das klingt unverblüm, weil es das auch sein muss. Wenn ein Mandant keine brauchbaren Beweise für das Geschehen liefern kann, ist dieser Mandant nicht bereit für eine sichere Skalierung. Sie können nicht steuern, was Sie nicht überprüfen dürfen, und Sie werden Ihre Handlungen erst recht nicht verteidigen können, wenn später etwas schief geht. Die dritte Kennzahl ist die Zeit bis zur Richtlinienerstellung für alle Mandanten. Hier findet die Geschäftsleitung heraus, ob das Hub-and-Spoke-Modell tatsächlich real oder nur dekorativ ist. Eine zentrale Entscheidung bedeutet absolut nichts, wenn ein Mandant Sie diese Woche durchsetzt, während ein anderer einen Monat wartet, um darüber nachzudenken. Sie sollten die Zeit messen, die von der Genehmigung einer Richtlinie bis zu ihrer effektiven Durchsetzung in jedem einzelnen Mandanten vergeht.

Ich spreche hier nicht von der Zeit, die es braucht, um etwas anzukündigen oder zu dokumentieren, sondern von der Zeit, bis es tatsächlich läuft. Für ein KI-Programm, das so schnell voranschreitet, ist eine solche Verzögerung nur ein anderes Wort für Risiko. Ein praktikables Ziel für die meisten Unternehmen liegt bei unter 72 Stunden für Standardänderungen. Wenn Ihre Zykluszeit viel länger ist, haben Sie noch kein skalierbares Modell. Es liegt lediglich ein Koordinationsproblem vor, das gelöst wird. Als nächstes müssen Sie sich Ihre Label-Coverage-Ration ansehen. Lassen Sie dies nicht zu einer Eitelkeitsmetrik werden, bei der ein Mandant hohe Werte erreicht, während die anderen zurückfallen. Wirklich wichtig ist, ob Ihre sensiblen Inhalte einheitlich genug gekennzeichnet sind, damit das Verhalten von Co-Pilot nicht nur auf Vermutungen der Benutzer beruht. Sie streben hier keine Perfektion an, sondern ein vergleichbares Maß an Kontrolle für jeden Mandanten in Ihrem Unternehmen.

Schließlich müssen Sie Ihre Zugriffstrifftrate nachverfolgen. Diese Metrik gibt Ihnen Aufschluss darüber, ob Ihre Bereinigungsbemühungen im Laufe der Zeit tatsächlich wirkend. Wie schnell breiten sich diese Berechtigungen nach Abschluss eines Behebungsprojekts wieder aus? Wie oft kehren diese großen Gruppen zum System zurück? Viele Teams bemerken dies zu spät, dass Sie die Fehlerbehebung einmal gemessen und angenommen haben, das Problem sei für immer behoben. Das war es nicht. Die einzige wichtige Kennzahl ist, wie schnell das System nachlässt, wenn man es nicht mehr genauer betrachtet. Vergehen. Das ist Ihr operatives Dashboard. Sie müssen die Reduzierung von Oversharing, die Abdeckung der Observability, die Zeit bis zur Richtlinienerstellung, die Abdeckung von Labels und die Zugriffsabweichungen nachverfolgen. Der Rhythmus Ihrer Berichterstattung ist genauso wichtig wie die Zahlen selbst.

Der Hub sollte das Executive Dashboard besitzen, da die Unternehmensleitung eine einzige Sicht auf den gesamten Status benötigt. In der Zwischenzeit sollten die Spokes für die Behebung verantwortlich sein, da die eigentliche Arbeit dort stattfinden muss, wo die Mandantengrenze verläuft. Ein Team liest das System und das andere Team korrigiert es. Sie müssen diese Zahlen nachverfolgen, bevor Sie eine Erweiterung vornehmen und nicht im Namen. Das Risiko warte nicht auf Ihr nächstes Meeting oder Ihren nächsten Governance Work. Es ist bereits in jedem Mandanten aktiv, wo Co-Pilot genau feststellen kann, was Ihre aktuellen Kontrollen noch zulassen. Die beiden Muster die Führungskräfte übersehen. Ich sehe in der Praxis immer wieder zwei spezifische Muster und beide treten auf, weil Führungskräfte Co-Pilot wie eine Software-Einführung und nicht wie ein wichtiges Kontrollereignis behandeln. Das erste Muster beginnt, wenn eine Organisation Co-Pilot einführt, bevor sie eine echte Basis für den Zuständigkeitsbereich festlegt oder ihren SharePoint-Zugriff überprüft.

Am ersten Tag sieht der Rollout perfekt aus. Lizenzen werden zugewiesen, die Benutzer sind begeistert und die internen Mitteilungen drehen sich nur um Produktivität. Doch dann beginnen normale Eingabeaufforderungen, Material abzurufen, das zwar die ganze Zeit technisch zugänglich war, für den durchschnittlichen Mitarbeiter jedoch praktisch unsichtbar war. Vor der KI hat niemand seinen Tag damit verbracht, sich durch alte Websites, veraltete Ordner oder geerbte Berechtigungen zu klicken, um Dinge zu finden, die er nicht sehen sollte. Aber jetzt müssen sie das nicht mehr. Ein Benutzer stellt eine einfache Frage, erhält eine Zusammenfassung und eine Datei wird angezeigt. Möglicherweise handelt es sich um sensible HR-Inhalte, Finanzmaterial oder Geschäftsinformationen, die nur in einem sehr engen Kreis aufbewahrt werden sollen. Es gab keine Sicherheitsverletzung, keine Malware und keine Verletzung der Sicherheitsgrenze im herkömmlichen Sinne.

Das System verwendete einfach die Berechtigung und den Inhaltsstatus, die der Mandant bereits zugelassen hatte. Das ist der Moment, in dem viele Teams endlich das Problem verstehen. KI hat die Gefährdung nicht verursacht. Sie hat lediglich die Reibungspunkte, beseitigt diese bisher verdeckt. Sobald dies bei einem Mandanten geschieht, sinkt für gewöhnlich das Vertrauen der Führungskräfte im gesamten Unternehmen, da niemand mit Sicherheit sagen kann, wo dasselbe Muster als nächstes auftreten könnte. Der Vorfall mag lokal begrenzt erscheinen, doch der Vertrauensschaden ist unternehmensweit. Das zweite Muster ist weniger aufwendig, aber genauso gefährlich. Ein Unternehmen richtet mandantenübergreifende Identitätsbeziehungen ein, erfährt, dass mandantenfähige Szenarien möglich sind und geht davon aus, dass sein Betriebsmodell ausgereift genug für eine flächendeckende Einführung ist. Auf Folien klingt das nach einem soliden Plan.

In der Realität werden die Abläufe jedoch chaotisch. Ein Team erwartet eine reibungslose Co-Pilot-Erfahrung in jeder verbundenen Umgebung, während ein anderes eine vergleichbare Transparenz erwartet und ein drittes davon ausgeht, dass dem Benutzer überall dieselben Kontrollen folgen. Dann zeigt die tatsächliche Nutzung uneinheitliches Verhalten, Lücken bei der Authentifizierung und Schwachstellen bei den tatsächlich messbaren Daten. Das Problem ist nicht, dass diese Teams nachlässig waren. Das eigentliche Problem ist, dass sie Konnektivität in Sicherheit übersetzt haben. Diese Annahme vermittelt ein falsches Bild von der Compline. Die Unternehmensleitung hört das Wort vernetzt und geht davon aus, dass die Organisation bereit ist. Monate später stellen Kontrollüberprüfungen fest, dass Verhalten, Nachweise und Durchsetzung viel stärker voneinander abwichen, als anfangs irgendjemand zugeben wollte.

Vergleichen wir das nun mit einem besseren Muster. Eine andere Organisation entscheidet sich dafür, langsamer vorzugehen, nur vor sie hochskaliert. Sie legt zunächst eine Label-Baseline fest, überprüft zunächst den breiten Zugriff und validiert ihre Audit-Transparenz, bevor sie andere Maßnahmen ergreift. Sie weitet Co-Pilot in Wellen aus, nicht weil sie Angst vor der Einführung haben, sondern weil sie möchten, dass jede Welle brauchbare Nachweise liefert, bevor die nächste beginnt. Diese Organisation kommt auf lange Sicht in der Regel schneller voran, da sie nicht ständig anhalten muss, um Überraschungen zu erklären, exponierte Inhalte zu bereinigen oder darüber zu streiten, was Kontrollierte eigentlich bedeuten soll. Das ist der Vorteil, den die meisten Führungskräfte übersetzen. Eine gute Governance blockiert ihren Rollout nicht. Sie beseitigt die Verzögerung des Rollouts, nachdem die erste Welle abgeschlossen ist.

Die Falle ist nicht die Einführung selbst. Die Falle ist die nicht verwaltete Einführung über Mandanten hinweg, die aus der Ferne verbunden erscheinen, sich aber aus der Nähe ganz anders verhalten. Die Entscheidung, die sie treffen müssen, ist eigentlich ganz einfach. Sie müssen jetzt zu einem föderierten Hubensburg-KI-Governance-Modell wechseln und aufhören, das Umschalten von Mandant zu Mandant mit tatsächlicher Kontrolle zu verwechseln. Sie sollten Ihre Co-Pilot-Erweiterung in jedem Mandanten pausieren, der seine Protokollierung, seine Oversharing-Überprüfungen, seine Label-Baseline-Abdeckung nicht nachweisen kann. DKI wird sich an dem System orientieren, das Sie tatsächlich aufbauen und nicht an dem Organigramm, dem Sie unterstellt. Wenn dies Ihre Sicht auf die Multi-Tenant-Copilot-Governance verändert hat, folgen Sie mir, Mirko Peters, auf LinkedIn und teilen Sie dies mit Ihrem Team, wenn Sie sich gerade mit diesem Problem befassen.