WEBVTT 00:00:00.000 --> 00:00:02.440 Ihr Führungsteam ist der Meinung, dass es sich hierbei um eine Rollout-Frage handelt. 00:00:02.780 --> 00:00:05.900 Das ist nicht. Dies ist eine Governance-Entscheidung mit einer sehr kurzen Startbahn. 00:00:06.020 --> 00:00:10.200 Und der Druck ist groß, da Co-Pilot nicht auf ihre Richtlinienbereinigung oder ihre interne Abstimmung wartet. 00:00:10.960 --> 00:00:14.760 Sobald es in ihrer Umgebung in Betrieb genommen wird, verwendet es das System genau so, wie es es vorfindet. 00:00:14.820 --> 00:00:15.700 Und genau hier liegt das Problem. 00:00:16.400 --> 00:00:20.200 Die meisten Organisationen mit mehreren Microsoft 365 Mandanten gehen davon aus, 00:00:20.280 --> 00:00:22.260 dass sie über eine einzige KI-Steuerungsstrategie verfügen, 00:00:22.400 --> 00:00:24.900 hauptsächlich weil sie von einem Anbieter kaufen und einen Identitätsbestand verwalten. 00:00:25.380 --> 00:00:27.760 Sie hören eine strategische Erzählung von Microsoft und gehen davon aus, 00:00:27.760 --> 00:00:29.200 dass die Realität mit dem Pitch übereinstimmt. 00:00:29.200 --> 00:00:31.220 Die Betriebsbedingungen sind jedoch ganz anders. 00:00:31.660 --> 00:00:34.600 KI arbeitet an Mandantengrenzen, während sich das Risiko quer durch diese erstreckt. 00:00:34.780 --> 00:00:37.020 Die Frage ist also nicht, ob wir Co-Pilot überall aktivieren können. 00:00:37.540 --> 00:00:41.280 Die eigentliche Frage ist, welches Governance-Modell uns eine sichere Skalierung über Mandanten ermöglicht, 00:00:41.340 --> 00:00:42.360 die sich unabhängig voneinander verhalten. 00:00:43.060 --> 00:00:45.080 Bevor wir zu diesem Modell kommen, müssen wir die Falle definieren. 00:00:45.880 --> 00:00:48.560 Die Falle. Souveräne KI-Inseln innerhalb eines Unternehmens. 00:00:49.220 --> 00:00:51.960 In den meisten Organisationen beginnt die Illusion mit Vertrautheit. 00:00:52.600 --> 00:00:56.960 Sie öffnen Microsoft 365, sie öffnen Purview, sie öffnen Entra, sie öffnen Power-Plattformen. 00:00:56.960 --> 00:00:57.840 Das Branding ist dasselbe. 00:00:57.840 --> 00:00:59.800 Die Admin-Sprache fühlt sich einheitlich an. 00:01:00.300 --> 00:01:02.320 Und der Werbespot erzählt eine sehr klare Geschichte. 00:01:02.880 --> 00:01:04.820 Ein Ökosystem, eine Strategie, eine Richtung. 00:01:05.640 --> 00:01:08.900 Aber das zugrunde liegende Kontrollmodell ist nicht einheitlich und das ist wichtiger als das Branding. 00:01:09.520 --> 00:01:13.240 Basierend auf den hier durchgeführten Untersuchungen gibt es kein einzelnes globales KI-Admin-Center 00:01:13.240 --> 00:01:17.540 mit vollständiger Funktionsparität, das ihnen eine zentrale Anlaufstelle für die saubere Steuerung von Co-Piloten bei allem anderen erbietet. 00:01:17.540 --> 00:01:19.640 Unterdessen haben sie es mit einem fragmentierten Kontrollschrauben zu tun. 00:01:20.080 --> 00:01:25.300 Teile der Governance befinden sich in Purview, andere Teile in Admin-Centern und der Rest ist über Entra und Power-Plattformen verstreut. 00:01:26.100 --> 00:01:33.080 Einige Features entstehen in neueren Microsoft-Steuerungsebenen, bilden aber noch keine vollständig ausgereifte globale Ebene über alle Mandantengrenzen hinweg. 00:01:33.720 --> 00:01:35.060 Diese Lücke schafft trügerisches Vertrauen. 00:01:35.060 --> 00:01:41.100 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. 00:01:41.520 --> 00:01:44.120 Die Beschaffung sieht eine Vereinbarung und geht von einem Betriebsmodell aus. 00:01:44.460 --> 00:01:50.360 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. 00:01:51.460 --> 00:01:52.440 Was er tatsächlich passiert ist einfach. 00:01:52.840 --> 00:01:55.060 Sie haben keine einheitliche KI-Unternehmensumgebung. 00:01:55.060 --> 00:01:57.820 Sie haben mehrere KI-Umgebungen, die zufällig zum selben Unternehmen gehören. 00:01:58.140 --> 00:01:59.240 Das ist ein ganz anderes Risikobild. 00:01:59.740 --> 00:02:03.040 Ein Mandant verfügt möglicherweise über eine stärkere Abdeckung des Zuständigkeitsbereichs, 00:02:03.040 --> 00:02:05.980 während ein anderer eine schwächere Label-Akzeptanz oder eine unvollständige Audit-Erfassung aufweist. 00:02:06.060 --> 00:02:08.320 Aus Vorstandsebene mag dies immer noch wie ein Programm aussehen. 00:02:08.560 --> 00:02:11.340 Aus der Sicht eines Audits oder Vorfalls handelt es sich jedoch überhaupt nicht um ein Programm. 00:02:11.820 --> 00:02:13.860 Es handelt sich um eine Ansammlung separater Betriebsbedingungen. 00:02:14.300 --> 00:02:16.780 Und sobald diese Bedingungen abweichen, beginnt die Berichterstattung zu lügen. 00:02:17.240 --> 00:02:18.380 Nicht absichtlich, sondern strukturell. 00:02:19.080 --> 00:02:20.900 Das Essential-Team fragt, werden wir kontrolliert? 00:02:21.280 --> 00:02:23.460 Ein Mandant sagt ja, weil das Audit aktiviert ist. 00:02:23.660 --> 00:02:26.420 Ein anderer sagt ja, weil Labels vorhanden sind, auch wenn die Abdeckung schwach ist. 00:02:26.820 --> 00:02:28.540 Ein dritter sagt ja, weil die Identität verbunden ist. 00:02:29.080 --> 00:02:31.420 Ein vierter sagt ja, weil Co-Pilot technisch bereitgestellt wurde. 00:02:31.420 --> 00:02:35.280 Jede Antwort klingt für sich genommen vernünftig, aber keine von ihnen bedeutete selten. 00:02:35.660 --> 00:02:36.320 Das ist die Falle. 00:02:36.620 --> 00:02:38.500 Sie denken, Sie betrachten eine globale Kontrollebene. 00:02:38.820 --> 00:02:42.220 Dabei betrachten Sie in Wirklichkeit eine Reihe souveräner KI-Inseln innerhalb eines Unternehmens. 00:02:42.880 --> 00:02:45.160 Sie sind über die Marke und manchmal über die Identität verbunden, 00:02:45.560 --> 00:02:47.040 werden aber nicht als ein System kontrolliert. 00:02:47.520 --> 00:02:50.460 Und wenn Sie sich an nichts anderes aus diesem Abschnitt erinnern, merken Sie sich diese Zeile. 00:02:50.760 --> 00:02:54.000 Es gibt kein globales KI-Admin-Center, sondern nur die Illusion eines solchen. 00:02:54.660 --> 00:02:57.360 Ist diese Illusion erst einmal zerbrochen, zeigt sich schnell das nächste Problem. 00:02:57.880 --> 00:03:00.460 Die meisten Unternehmen reagieren darauf, indem sie die Governance für jeden Mandanten manoliert. 00:03:00.460 --> 00:03:02.060 Das nennen sie Kontrolle. 00:03:03.020 --> 00:03:05.540 Warum die manuelle Governance pro Mandant bei großem Umfang zusammen. 00:03:06.020 --> 00:03:09.180 Sobald Führungskräfte das Problem der Grenzen erkennen, klingt die übliche Antwort vernünftig. 00:03:09.460 --> 00:03:11.460 Sie sagen, okay, wir verwalten jeden Mandanten ordnungsgemäß. 00:03:11.780 --> 00:03:14.540 Ein Admin-Team prüft hier die Einstellung, ein anderes Team wiederholt sie dort. 00:03:15.020 --> 00:03:17.320 Jemand führt eine Tabellenkalkulation, ein anderes eine Checkliste. 00:03:18.000 --> 00:03:21.360 Einmal im Monat trifft sich eine Lenkungsgruppe und fragt, ob der Rollout auf Kurs ist. 00:03:21.940 --> 00:03:23.240 Auf dem Papier wirkt das diszipliniert. 00:03:23.560 --> 00:03:26.420 In der Praxis ist es eine manuelle Wiederholung, die als Governance getarnt ist. 00:03:26.420 --> 00:03:28.320 Und der Grund, warum das scheitert, ist einfach. 00:03:28.820 --> 00:03:32.140 Wiederholung erzeugt keine Kontrolle, sondern im Laufe der Zeit Variationen. 00:03:32.880 --> 00:03:37.080 Das geschieht, weil sich jeder Mandant anders bewegt, jeder Admin die Standards ein wenig anders liest 00:03:37.080 --> 00:03:40.680 und lokale Ausnahmen sich gerechtfertigt anfühlen, weil das Unternehmen sofort Fortschritte möchte 00:03:40.680 --> 00:03:42.780 und nicht erst nach einer weiteren zentralen Überprüfung. 00:03:42.780 --> 00:03:45.620 Dieses alte Modell überlebt, weil es nachvollziehbar ist. 00:03:46.080 --> 00:03:49.480 Mitarbeiter können auf geschlossene Tickets, erstellte Richtlinien und geänderte Einstellungen verweisen. 00:03:49.880 --> 00:03:53.660 Sie können Aktivitäten vorweisen, doch sichtbarer Aufwand ist nicht dasselbe wie ein stabiles Betriebsmodell. 00:03:54.140 --> 00:03:56.360 Und mit Co-Pilot wird diese Lücke sehr schnell teuer. 00:03:57.180 --> 00:04:01.680 Das System beginnt vorhandene Berechtigungen, vorhandene Inhaltsfreigaben und vorhandene Kennzeichnungslücken zu verwenden, 00:04:01.780 --> 00:04:03.380 sobald Benutzer mit der Eingabeaufforderung beginnen. 00:04:03.920 --> 00:04:05.080 Das ist es, was die meisten Leute übersehen. 00:04:05.480 --> 00:04:06.960 Co-Pilot wartet nicht auf die Reife der Governance. 00:04:06.960 --> 00:04:11.300 Das läuft auf der Grundlage der Berechtigungen, die sie bereits haben, der Inhaltshygiene, die sie bereits tolerieren 00:04:11.300 --> 00:04:13.360 und der Prüfstruktur, die sie bereits nicht standardisiert haben. 00:04:14.140 --> 00:04:16.780 Wenn ein Mandant den Zugriff bereinigt und ein anderer gelöscht hat 00:04:16.780 --> 00:04:21.020 oder wenn ein Mandant nützliche Prüfdaten streamt, während ein anderer kaum genug für die Untersuchung erfasst, 00:04:21.280 --> 00:04:23.140 deckt Co-Pilot diese Unterschiede sofort auf. 00:04:23.840 --> 00:04:25.600 Das geschieht nicht theoretisch, sondern durch die Nutzung. 00:04:26.440 --> 00:04:28.840 Wenn ein Mandant den umfassenden SharePoint-Zugriff überprüft hat 00:04:28.840 --> 00:04:31.380 und ein anderer davon ausgeht, dass er gut genug ist, findet die KI die Lücken. 00:04:32.060 --> 00:04:34.640 Und eine Ebene tiefer vervielfacht jeder neue Mandant das Problem. 00:04:34.640 --> 00:04:37.520 Nicht, weil die Mandanten schlecht sind, sondern weil sich nicht verwaltete Unterschiede häufen. 00:04:38.520 --> 00:04:40.500 Ein neues Pilotteam fügt eine lokale Ausnahme hinzu. 00:04:40.700 --> 00:04:42.920 Eine Fusion bringt einen weiteren Mandanten mit anderen Bezeichnungen ein 00:04:42.920 --> 00:04:45.980 und ein regionaler Administrator kopiert einen alten Administrator, kopiert eine alte Basislinie. 00:04:46.120 --> 00:04:48.120 Ein Geschäftsbereich fordert einen schnelleren Zugriff an 00:04:48.120 --> 00:04:50.340 und keine dieser Entscheidungen wirkt für sich genommen dramatisch. 00:04:50.860 --> 00:04:54.540 Führt man sie über Monate zusammen, erhält man Richtlinienabweichungen, Zugriffsabweichungen und Rollout-Riffen. 00:04:54.880 --> 00:04:58.980 Das Ergebnis ist ein Governance-Team, das mehr Zeit mit dem Abgleichen von Differenzen als mit der Risikoprävention verbringt. 00:04:59.280 --> 00:05:00.280 Hier greift die manuelle Kontrolle. 00:05:00.280 --> 00:05:03.120 Sie fühlt sich sicherer an, weil Menschen die Einstellungen beeinflussen, 00:05:03.220 --> 00:05:04.700 aber sie skaliert tatsächlich die Inkonsistenz, 00:05:04.760 --> 00:05:07.440 da jeder Berührungspunkt eine weitere Chance für Mandanten darstellt, voneinander abzuweichen. 00:05:07.780 --> 00:05:10.280 Das Ergebnis ist ein langsamerer Rollout, wo Geschwindigkeit gefragt ist, 00:05:10.340 --> 00:05:13.300 mehr Prüfaufwand, wo Nachweise gefragt sind und mehr Nacharbeit, wo Standards gefragt sind. 00:05:13.900 --> 00:05:17.200 Das Schlimmste ist jedoch, dass dadurch versteckte Risiken entstehen, wo die Führungskräfte Sicherheit erwarten. 00:05:17.860 --> 00:05:20.800 Das wurde mir klar, als ich aufhörte, Governance als Einrichtungsaufgabe zu betrachten. 00:05:21.140 --> 00:05:22.720 Das ist nicht. Es verhält sich eher wie verfallen. 00:05:22.720 --> 00:05:27.200 Wenn Sie Berechtigung einmal bereinigen, aber keine Kontrolle, Sie vor erneuten Abweichungen bewahrt, kehrt das Risiko zurück. 00:05:27.560 --> 00:05:32.180 Wenn Sie eine Label-Taxonomie einmal definieren, diese aber von den Mandanten ungleichmäßig angewendet wird, erodiert die Basislinie. 00:05:32.540 --> 00:05:37.500 Wenn Sie Co-Pilot in Wellen genehmigen, ohne zu überprüfen, ob die zugrunde liegende Kontrolle noch gilt, skalieren Sie nicht sicher. 00:05:38.080 --> 00:05:40.420 Sie expandieren einfach schneller, als Ihre Governance mithalten kann. 00:05:40.920 --> 00:05:44.820 Die hier wichtige Kennzahl ist also die Zugriffsverschiebung und nicht nur, ob Sie etwas behoben haben, 00:05:44.920 --> 00:05:47.820 sondern wie schnell sich Berechtigungen nach der Behebung wieder ausbreiten. 00:05:47.820 --> 00:05:50.820 Daran können Sie erkennen, ob Ihr Modell hält oder nachlässt. 00:05:51.280 --> 00:05:52.800 Denn Governance ist kein Projekt, das Sie abschließen. 00:05:53.140 --> 00:05:55.060 Es handelt sich um ein Problem des Zerfalls des Kontinuels. 00:05:55.440 --> 00:05:59.680 Und wenn die Skalierung das alte Modell überfordert, greifen die meisten Führungskräfte auf die bekannteste Antwort zurück, Identität. 00:06:00.240 --> 00:06:02.340 Sie gehen davon aus, dass sich die Governance irgendwie mit Ihnen verschieben wird, 00:06:02.380 --> 00:06:04.340 wenn sich Benutzer problemlos zwischen Mandanten bewegen können. 00:06:04.640 --> 00:06:05.160 Besonders der Fall. 00:06:05.460 --> 00:06:07.260 Warum löst Identität das Problem der Governance nicht? 00:06:07.820 --> 00:06:11.440 Hier schlagen viele Programme den falschen Weg ein, da Identität die saubere Antwort zu sein scheint. 00:06:11.440 --> 00:06:14.860 Wenn sich Benutzer mandantenübergreifend authentifizieren können, 00:06:14.940 --> 00:06:17.260 Entra verbunden ist und mandantenübergreifende Einstellungen vorhanden sind, 00:06:17.260 --> 00:06:19.240 gehen Führungskräfte davon aus, dass der Schwereteil gelöst ist. 00:06:19.940 --> 00:06:22.760 Der Zugriff scheint vereinheitlicht zu sein, die Anmeldung sieht vereinheitlicht aus, 00:06:22.800 --> 00:06:24.580 das Architekturdiagramm sieht übersichtlich aus, 00:06:24.880 --> 00:06:28.220 aber die Co-Pilot Governance wird nicht vereinheitlicht, nur weil die Identität verschoben werden kann. 00:06:28.780 --> 00:06:31.120 Diese Annahme scheitert an dem Punkt, an dem die KI tatsächlich funktioniert. 00:06:31.480 --> 00:06:35.020 Co-Pilot erdet Antworten innerhalb des Mandanten-Kontexts, in dem die Anforderung ausgeführt wird 00:06:35.020 --> 00:06:37.040 und die eigenen Richtlinien von Microsoft sind diesbezüglich eindeutig. 00:06:37.260 --> 00:06:41.340 Microsoft 3 von von FaceTime Co-Pilot arbeitet innerhalb der Sicherheits- und Compliance-Grenzen des Mandanten 00:06:41.340 --> 00:06:44.560 und respektiert die Berechtigungen des Benutzers in diesem spezifischen Mandanten-Kontext. 00:06:44.560 --> 00:06:49.100 Ein Benutzer kann als Gast den Kontext wechseln, ja, aber Co-Pilot ist immer noch auf jeweils einen Mandanten beschränkt. 00:06:49.440 --> 00:06:53.000 Es werden nicht mehrere Mandanten für eine einzelne Antwort in einem intelligenten Arbeitsbereich zusammengeführt. 00:06:53.360 --> 00:06:55.200 Die Identität kann also durchlaufen werden, die Governance nicht. 00:06:55.720 --> 00:06:59.800 Und sobald man diese beiden Aspekte trennt, beginnen viele Begriffe aus der Geschäftswelt gefährlich vage zu klingen. 00:07:00.520 --> 00:07:04.400 Verbundene Mandanten, gemeinsame Identität, einheitliche Erfahrung. 00:07:05.900 --> 00:07:08.240 Diese Ausdrücke mögen für die Zusammenarbeit richtungsweisend sein. 00:07:08.240 --> 00:07:12.760 Sie sind aber nicht dasselbe wie die Aussage, dass Richtliniendurchsetzung, Datenerdung, Protokollierung und Kontrollvalidierung 00:07:12.760 --> 00:07:14.500 und Kontrollvalidierung jetzt als ein System zusammen. 00:07:15.040 --> 00:07:18.700 Diese Lücke wird noch offensichtlicher, wenn man sich den mehr instanzenfähigen Modus von Co-Pilot-Studio ansieht, 00:07:18.780 --> 00:07:20.320 der die Vorschau eine ganz bestimmte Geschichte erzählt. 00:07:20.640 --> 00:07:20.800 Tipp. 00:07:21.220 --> 00:07:23.020 Ja, die Verwendung mit mehreren Mandanten ist möglich. 00:07:23.340 --> 00:07:26.160 Und ein mit einem Mandanten gehosteter Agent kann von einem anderen Mandanten aus verwendet werden. 00:07:26.420 --> 00:07:30.120 Die Endbenutzer-Authentifizierung im mehr instanzenfähigen Modus wird in der Vorschau jedoch noch nicht unterstützt. 00:07:30.500 --> 00:07:31.520 Gastbenutzer werden nicht unterstützt. 00:07:31.820 --> 00:07:33.280 Benutzer-Definierte-Connectors werden nicht unterstützt. 00:07:33.280 --> 00:07:36.680 Graph und Microsoft Red 65 Standard-Connectors werden nicht unterstützt. 00:07:37.160 --> 00:07:38.260 Multi-Geo wird nicht unterstützt. 00:07:38.740 --> 00:07:40.680 Verschiedene Analysefunktionen sind nicht verfügbar. 00:07:41.920 --> 00:07:43.680 Unterhaltungstranskripte sind in diesem Modus ebenfalls deaktiviert. 00:07:44.100 --> 00:07:46.040 Das ist keine ausgereifte, mandantenfähige Governance-Struktur. 00:07:46.440 --> 00:07:48.180 Das ist eine begrenzte Vorschau mit klaren Grenzen. 00:07:48.640 --> 00:07:51.980 Und diese Grenzen sind wichtig, weil sie die Geschichte, die sich viele Führungsteams erzählen, zunichte machen. 00:07:52.460 --> 00:07:54.760 Sie hören von mehreren Mandanten und gehen von betrieblicher Reife aus. 00:07:55.120 --> 00:07:58.100 Ihre Architekten hören von mandantenfähig und gehen von richtigen Symmetrie aus. 00:07:58.620 --> 00:08:01.640 Ihre Kontrollteams hören von demselben Anbieter und gehen von einer einheitlichen Prüfung aus. 00:08:01.640 --> 00:08:08.140 Dann beginnt der Rollout und die Mitarbeiter entdecken unterschiedliche Verhaltensweisen, fehlende Signale und unangenehme Lücken bei der Authentifizierung und Analyse. 00:08:08.620 --> 00:08:09.520 Stellen Sie sich den zweiten Fall vor. 00:08:09.920 --> 00:08:16.040 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. 00:08:16.480 --> 00:08:21.300 Die Erwartung klingt vernünftig und umfasst eine gemeinsame Vertrauensstellung in Verzeichnisse, einen reibungsloseren Zugriff und Kompetitizien. 00:08:21.700 --> 00:08:25.580 Wenn Teams jedoch tatsächliche Co-Pilot- und Agent-Szenarien testen, ist das Verhalten uneinheitlich. 00:08:26.000 --> 00:08:27.840 Einige Daten werden nur in gewechselten Kontexten angezt. 00:08:28.220 --> 00:08:29.640 Einige erwartete Konnektoren sind nicht verfügbar. 00:08:29.640 --> 00:08:33.560 Einige Prüferwartungen stimmen nicht mit den tatsächlichen Vorschaufunktionen überein. 00:08:34.560 --> 00:08:37.940 Die Geschäftsleitung hört immer noch eine Verbindung, während das Kontrollteam anfängt, Ausnahmen zu finden. 00:08:38.240 --> 00:08:39.180 Es ist kein technischer Sonderfall. 00:08:39.620 --> 00:08:40.820 Es ist eine Fehlinterpretation der Governance. 00:08:41.000 --> 00:08:43.460 Denn Prüfer überprüfen nicht ihre Architekturgeschichte, sondern Beweise. 00:08:43.840 --> 00:08:47.120 Sie fragen, wo Eingabeaufforderungen ausgeführt wurden, welche Richtlinie vom Mandanten durchgesetzt wurde, 00:08:47.480 --> 00:08:51.980 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. 00:08:51.980 --> 00:08:55.900 Wenn ihr Betriebsmodell Identität als Governance behandelt hat, erhalten sie keine eindeutige Antwort. 00:08:56.560 --> 00:08:58.120 Wenn sie sich also eine Zeile hier merken, dann dies. 00:08:59.280 --> 00:09:01.360 Mandantenübergreifende Identität ist nicht mandantenübergreifende Intelligent. 00:09:01.780 --> 00:09:03.060 Identität hilft Benutzer beim Zugriff. 00:09:03.320 --> 00:09:08.220 Sie sagt ihnen nicht, ob das Co-Pilotverhalten konsistent gesteuert, ordnungsgemäß überwacht oder sicher an allen Orten skaliert werden kann, 00:09:08.380 --> 00:09:10.180 an denen ihr Unternehmen jetzt eine Umgebung bezeichnet. 00:09:10.180 --> 00:09:13.160 Und wenn das klar ist, kann die Antwort nicht mehr Mandantenverbindungen sein. 00:09:13.520 --> 00:09:14.420 Es muss Architektur sein. 00:09:15.340 --> 00:09:16.980 Das Governance-Modell, das tatsächlich funktioniert. 00:09:17.120 --> 00:09:17.500 Hub-and-Spoke. 00:09:18.300 --> 00:09:21.320 Wie sieht nun ein echtes Governance-Modell aus, wenn ihre Plattform fragmentiert ist, 00:09:21.380 --> 00:09:24.620 die Identität nur teilweise vorhanden ist und Mandantenkranzen immer noch eine Rolle spielen? 00:09:25.120 --> 00:09:26.480 Es ähnelt einem Hub-and-Spoke-System. 00:09:27.000 --> 00:09:29.740 Ich schlage dies nicht vor, weil das Diagramm auf einer Folie übersichtlich aussieht, 00:09:29.940 --> 00:09:33.600 sondern weil es tatsächlich den unübersichtlichen Betriebsbedingungen entspricht, mit denen sie es derzeit zu tun haben. 00:09:33.600 --> 00:09:37.660 Sie benötigen einen zentralen Ort, an dem Governance-Entscheidungen als ein einziges System entworfen, 00:09:37.760 --> 00:09:39.180 gemessen und durchgesetzt werden und dann? 00:09:39.180 --> 00:09:42.040 Benötigen Sie lokale Mandantenteams, um diese Entscheidung umzusetzen. 00:09:42.280 --> 00:09:44.680 Diese lokalen Teams müssen innerhalb ihrer eigenen Grenzen arbeiten, 00:09:44.820 --> 00:09:48.220 ohne jedes Mal, wenn sie ein wenig Druck verspüren, ihre eigene Version der Regeln zu erfinden. 00:09:49.040 --> 00:09:50.000 Wir müssen mit dem Hub beginnen. 00:09:50.500 --> 00:09:54.640 Der Hub ist kein Verwaltungsportal, kein schickes Dashboard und definitiv kein heldenhaftes zentrales Team, 00:09:54.720 --> 00:09:57.360 das sich in jeden einzelnen Mandanten begibt, um Dateien manuell zu bereinigen. 00:09:58.740 --> 00:10:01.120 Stattdessen fungiert der Hub als ultimative Governance-Instanz. 00:10:01.420 --> 00:10:06.740 Diese Gruppe ist für das Richtlinien-Design, die Prüfbasis-Linien, die Label-Standards und die Rollout-Kriterien verantwortlich. 00:10:06.740 --> 00:10:11.140 Sie entscheiden, was bereit für Co-Pilot tatsächlich bedeutet, welche Beweise als Beleg gelten 00:10:11.140 --> 00:10:13.560 und wie schnell eine Sicherheitslücke geschlossen werden muss. 00:10:14.560 --> 00:10:16.340 Diese Verschiebung verändert die gesamte Konversation. 00:10:17.120 --> 00:10:20.620 Aufgrund dieser Struktur ist global nicht mehr nur ein Wort für einen magischen Bildschirm, 00:10:21.140 --> 00:10:23.120 sondern bedeutet ein einheitliches Governance-System. 00:10:23.920 --> 00:10:26.320 Sie erhalten einen Standard für Zuständigkeitsbereichskontrollen, 00:10:26.380 --> 00:10:29.520 einen Standard für die Erfassung von Audits und einen Standard für ihre Vertraulichkeitsbezeichnung. 00:10:29.520 --> 00:10:32.040 Es gibt eine klare Messlatte dafür, was erfüllt sein muss, 00:10:32.120 --> 00:10:34.920 bevor ein bestimmter Mandant den Co-Pilot-Zugriff auf mehr Benutzer erweitern darf. 00:10:35.480 --> 00:10:36.060 Dann brauchen Sie die Speichen. 00:10:36.540 --> 00:10:38.700 Die Speichen sind ihre lokalen Mandanten-Ausführungsteams, 00:10:38.780 --> 00:10:41.300 die diese Basislinie nehmen und auf ihre spezifische Umgebung anwenden. 00:10:41.820 --> 00:10:44.440 Sie sind diejenigen, die die Korrektur durchführen, die Protokolle validieren 00:10:44.440 --> 00:10:46.300 und umfassende Zugriffsberechtigungen überprüfen. 00:10:46.780 --> 00:10:51.400 Sie führen all diese Arbeiten jedoch in einem sehr engen Entwurfsbereich durch und haben nichts Freiraum. 00:10:52.060 --> 00:10:55.640 Wenn ein lokales Team vom Plan abweichen muss, gibt es einen formellen Weg für Ausnahmen. 00:10:55.640 --> 00:10:59.520 Und wenn Sie schneller vorankommen wollen, müssen Sie trotzdem zuerst die gemeinsamen Kontrollen einhalten. 00:11:00.260 --> 00:11:04.120 Wenn regionale oder rechtliche Unterschiede auftreten, werden diese Probleme dokumentiert und genehmigt, 00:11:04.200 --> 00:11:07.580 anstatt stillschweigend in einer lokalen Problemumgehung aufgegangen zu sein, von der sonst niemand weiß. 00:11:08.180 --> 00:11:09.720 Diese Struktur ist von entscheidender Bedeutung, 00:11:09.820 --> 00:11:12.600 da vollständig zentralisierte Modelle in der Regel an lokalen Details scheitern, 00:11:12.720 --> 00:11:15.620 während vollständig lokale Modelle fast sofort in völlige Inkonsistenz abdriften. 00:11:16.400 --> 00:11:18.220 Hub & Spoke vermeidet beide Fehlermuster. 00:11:19.020 --> 00:11:20.780 Der Hub bietet Ihnen die benötigte Konsistenz, 00:11:20.780 --> 00:11:24.080 während die Spokes Ihnen die Ausführungsgeschwindigkeit dort bieten, wo die Arbeit tatsächlich stattfindet. 00:11:24.680 --> 00:11:25.380 Machen wir das konkret. 00:11:25.820 --> 00:11:28.760 Im Hub definieren Sie den Mindestkontrollsatz für den Zuständigkeitsbereich, 00:11:28.860 --> 00:11:31.100 den jeder Mandant ausführen muss, bevor Co-Pilot wachsen darf. 00:11:31.760 --> 00:11:35.560 Sie definieren genau, welche Prüfereignisse Sie erwarten und wie oft Sie diese überprüfen werden. 00:11:36.480 --> 00:11:39.740 Außerdem erstellen Sie eine gemeinsame Bezeichnungstaxonomie für sensible Inhalte, 00:11:39.860 --> 00:11:43.400 damit ein vertrauliches Tag nicht fünf verschiedene Dinge für fünf verschiedene Mandanten bedeutet. 00:11:44.340 --> 00:11:46.040 Sie legen den Rhythmus für Überprüfungen fest, 00:11:46.240 --> 00:11:48.100 vielleicht monatlich für Ihre allgemeine Sicherheitslage 00:11:48.100 --> 00:11:50.980 und häufiger in Bereichen, in denen der Rollout gerade aktiv ist. 00:11:50.980 --> 00:11:55.980 Im Spoke ordnet Ihr Team diese hohen Standards den Realitäten des jeweiligen Mandanten zu. 00:11:56.440 --> 00:11:59.260 Sie finden heraus, welche Websites noch immer einen breiten Zugriff haben 00:11:59.260 --> 00:12:01.360 und welche Geschäftsbereiche bei Ihrer Kennzeichnung hinterherhinken. 00:12:01.680 --> 00:12:03.520 Sie überprüfen, ob das Audit tatsächlich aktiviert ist 00:12:03.520 --> 00:12:05.540 und ob die richtigen Datensätze für das Sicherheits-Team sichtbar sind. 00:12:05.880 --> 00:12:08.980 Sie suchen nach lokalen Administratoren, die möglicherweise Ausnahmen eingeführt haben, 00:12:09.060 --> 00:12:10.200 die nie offiziell überprüft wurden, 00:12:10.280 --> 00:12:12.240 und entscheiden, ob eine Pilotgruppe sicher erweitert werden kann 00:12:12.240 --> 00:12:14.420 oder ob sie angehalten und zuerst Probleme behoben werden müssen. 00:12:14.420 --> 00:12:18.040 Und hier ist die feste Regel, denn ohne Regel ist dieses Modell nur ein Vorschlag 00:12:18.040 --> 00:12:19.580 und keine tatsächliche Governance. 00:12:20.460 --> 00:12:23.940 Kein Co-Pilot-Rollout erfolgt in einem Mandanten ohne validierte Audit-Protokollierung, 00:12:24.360 --> 00:12:25.780 einen abgeschlossenen Oversharing-Scan 00:12:25.780 --> 00:12:27.720 und eine Mindestbasis für die Kennzeichnungsabdeckung. 00:12:28.080 --> 00:12:30.600 Ich spreche nicht davon, dass diese Dinge geplant oder teilweise besprochen werden. 00:12:30.980 --> 00:12:31.820 Sie müssen validiert werden. 00:12:32.200 --> 00:12:34.660 Wenn ein Mandant nicht nachweisen kann, dass diese drei Bedingungen erfüllt sind, 00:12:34.720 --> 00:12:35.540 wird der Rollout unterbrochen. 00:12:36.080 --> 00:12:38.520 Das mag streng klingen, bis man es mit den enormen Kosten vergleicht, 00:12:38.600 --> 00:12:40.140 die durch die Bereinigung eines Chaos entstehen, 00:12:40.200 --> 00:12:42.880 wenn benutzer sensible Inhalte finden, die sie niemals über KI-Preis geben wollten. 00:12:42.880 --> 00:12:46.300 Wenn man es so betrachtet, sind diese Regeln einfach nur gesunder Menschen verstanden. 00:12:46.880 --> 00:12:49.320 Ein weiterer Grund, warum dieses Modell so gut funktioniert, ist das Timing. 00:12:49.860 --> 00:12:52.880 Je länger sie mit der Einrichtung warten, desto mehr Schulden verursachen sie später. 00:12:53.760 --> 00:12:55.740 Jeder Mandant, der vor der Baseline eingeführt wird, 00:12:55.820 --> 00:12:59.000 führt zu einem weiteren riesigen Rückstand an Ausnahmen und fehlenden Nachweisen, 00:12:59.080 --> 00:13:00.540 den ihr Team irgendwann aufarbeiten muss. 00:13:01.560 --> 00:13:03.240 Führungskräfte behandeln Governance oft als etwas, 00:13:03.320 --> 00:13:04.960 das nach Abschluss der Einführung ausgereift ist. 00:13:05.320 --> 00:13:08.380 In einer Multitenant-Co-Pilot-Welt ist diese Reihenfolge jedoch völlig umgekehrt. 00:13:08.800 --> 00:13:09.880 Die Governance muss den Rollout leiten. 00:13:10.400 --> 00:13:12.040 Andernfalls verursacht der Rollout mehr Schulden, 00:13:12.040 --> 00:13:13.200 als ihre Teams jemals bewältigen können. 00:13:13.760 --> 00:13:16.340 Wenn Sie dies auf Unternehmensebene leiten, ist der nächste Schritt ganz klar. 00:13:17.000 --> 00:13:19.420 Richten Sie jetzt den Hub ein und definieren Sie noch heute diese Baseline. 00:13:20.020 --> 00:13:23.560 Weisen Sie Ihre Speichen zu und halten Sie Ihren Prozess zur Ausnahmebehandlung sofort schriftlich fest. 00:13:24.180 --> 00:13:25.500 Sie müssen global sicherstellen, 00:13:25.620 --> 00:13:28.800 dass Ihre Entscheidungen und Ihre Rollout-Gates als ein einziges System funktionieren, 00:13:29.080 --> 00:13:30.920 selbst wenn dies für die Mandanten selbst nicht der Fall ist. 00:13:31.500 --> 00:13:32.820 Ein Modell ist nur dann von Bedeutung, 00:13:32.900 --> 00:13:34.720 wenn es tatsächlich Änderungen vor in einer Änderung vornimmt. 00:13:34.720 --> 00:13:37.360 Führungskräfte sollten dies messen, bevor Sie skalieren. 00:13:37.640 --> 00:13:41.040 Ein Governance-Modell ist nur dann schlüssig, wenn es Kennzahlen liefert, die von allen geteilt werden. 00:13:41.740 --> 00:13:44.800 Andernfalls behauptet jeder Mandant, dass er in seiner eigenen Sprache Fortschritte macht 00:13:44.800 --> 00:13:47.960 und die Führungskräfte erhalten Statusaktualisierungen, ohne wirkliche Kontrolle zu haben. 00:13:48.660 --> 00:13:51.600 Bevor Sie Co-Pilot weiter skalieren, benötigen Sie eine kleine Reihe von Metriken, 00:13:51.680 --> 00:13:54.320 die Ihnen Aufschluss darüber geben, ob sich die Architektur so verhält, wie Sie es erwarten. 00:13:54.320 --> 00:13:56.820 Aktivitätsniveaus sagen Ihnen nicht die Wahrheit 00:13:56.820 --> 00:13:59.060 und Akzeptanzzahlen zeigen Ihnen definitiv nicht die Risiken. 00:13:59.320 --> 00:14:01.140 Sie sollten mit der Reduzierung von Oversharing beginnen. 00:14:01.540 --> 00:14:03.640 Dies ist nach wie vor eines der offensichtlichsten Anzeichen dafür, 00:14:03.740 --> 00:14:05.560 dass Ihre Umgebung tatsächlich sicherer für KI wird. 00:14:06.260 --> 00:14:08.940 Sie müssen sich breite Zugriffsgruppen, offene SharePoint-Websites 00:14:08.940 --> 00:14:11.360 und alte Berechtigungen ansehen, die viel mehr Zugriff gewähren, 00:14:11.440 --> 00:14:12.720 als das Unternehmen tatsächlich benötigt. 00:14:13.220 --> 00:14:15.380 Das Ziel besteht hier nicht darin, eine perfekte Zahl zu erreichen, 00:14:15.440 --> 00:14:17.140 sondern nachzuweisen, dass Sie Ihre Gefährdung verringert, 00:14:17.220 --> 00:14:18.460 bevor Sie Ihre Co-Pilot-Reichweite erhöhen. 00:14:18.980 --> 00:14:21.300 Wenn sich diese beiden Linien in entgegengesetzte Richtungen bewegen, 00:14:21.300 --> 00:14:23.900 expandieren Sie viel schneller, als Sie die zugrunde liegenden Probleme beheben. 00:14:24.600 --> 00:14:26.840 Die zweite Metrik, die Sie benötigen, ist die Abdeckung der Observe. 00:14:27.440 --> 00:14:29.780 Können Sie tatsächlich sehen, was Co-Pilot in allen Ihren Mandanten tut, 00:14:29.840 --> 00:14:31.520 und zwar so, dass eine echte Untersuchung unterstützt wird? 00:14:31.940 --> 00:14:33.440 Die meisten Untersuchungen deuten darauf hin, 00:14:33.500 --> 00:14:35.980 dass Microsoft Purview der Hauptspeicherort für zentrale Datensätze 00:14:35.980 --> 00:14:36.940 wie Co-Pilot-Interaktion ist. 00:14:37.300 --> 00:14:39.580 Dies setzt jedoch voraus, dass die Überwachung überall aktiviert ist. 00:14:40.440 --> 00:14:42.280 Man kann nicht einfach davon ausgehen, dass die Abdeckung funktioniert. 00:14:42.880 --> 00:14:44.600 Sie müssen genau wissen, bei welchen Mandanten 00:14:44.600 --> 00:14:46.520 die Überwachung der Datenerfassung aktiv ist 00:14:46.520 --> 00:14:48.480 und bei welchen nur teilweise Transparenz besteht. 00:14:49.560 --> 00:14:51.060 Ohne Protokolle gibt es keine Governance 00:14:51.060 --> 00:14:52.060 und keine Verantwortlichkeit. 00:14:52.720 --> 00:14:54.100 Das klingt unverblüm, weil es das auch sein muss. 00:14:54.560 --> 00:14:56.900 Wenn ein Mandant keine brauchbaren Beweise für das Geschehen liefern kann, 00:14:56.980 --> 00:14:58.940 ist dieser Mandant nicht bereit für eine sichere Skalierung. 00:14:59.460 --> 00:15:01.300 Sie können nicht steuern, was Sie nicht überprüfen dürfen, 00:15:01.580 --> 00:15:03.500 und Sie werden Ihre Handlungen erst recht nicht verteidigen können, 00:15:03.560 --> 00:15:04.440 wenn später etwas schief geht. 00:15:04.880 --> 00:15:06.880 Die dritte Kennzahl ist die Zeit bis zur Richtlinienerstellung 00:15:06.880 --> 00:15:07.380 für alle Mandanten. 00:15:07.920 --> 00:15:09.240 Hier findet die Geschäftsleitung heraus, 00:15:09.320 --> 00:15:12.280 ob das Hub-and-Spoke-Modell tatsächlich real oder nur dekorativ ist. 00:15:12.880 --> 00:15:14.740 Eine zentrale Entscheidung bedeutet absolut nichts, 00:15:14.740 --> 00:15:16.120 wenn ein Mandant Sie diese Woche durchsetzt, 00:15:16.200 --> 00:15:18.180 während ein anderer einen Monat wartet, um darüber nachzudenken. 00:15:18.560 --> 00:15:19.500 Sie sollten die Zeit messen, 00:15:19.500 --> 00:15:22.220 die von der Genehmigung einer Richtlinie bis zu ihrer effektiven Durchsetzung 00:15:22.220 --> 00:15:23.600 in jedem einzelnen Mandanten vergeht. 00:15:24.000 --> 00:15:25.560 Ich spreche hier nicht von der Zeit, die es braucht, 00:15:25.620 --> 00:15:27.040 um etwas anzukündigen oder zu dokumentieren, 00:15:27.120 --> 00:15:28.280 sondern von der Zeit, bis es tatsächlich läuft. 00:15:28.560 --> 00:15:30.320 Für ein KI-Programm, das so schnell voranschreitet, 00:15:30.400 --> 00:15:32.460 ist eine solche Verzögerung nur ein anderes Wort für Risiko. 00:15:32.780 --> 00:15:34.420 Ein praktikables Ziel für die meisten Unternehmen 00:15:34.420 --> 00:15:36.480 liegt bei unter 72 Stunden für Standardänderungen. 00:15:37.080 --> 00:15:38.460 Wenn Ihre Zykluszeit viel länger ist, 00:15:38.520 --> 00:15:40.120 haben Sie noch kein skalierbares Modell. 00:15:40.760 --> 00:15:42.380 Es liegt lediglich ein Koordinationsproblem vor, 00:15:42.380 --> 00:15:42.880 das gelöst wird. 00:15:43.380 --> 00:15:45.400 Als nächstes müssen Sie sich Ihre Label-Coverage-Ration ansehen. 00:15:45.860 --> 00:15:47.660 Lassen Sie dies nicht zu einer Eitelkeitsmetrik werden, 00:15:47.660 --> 00:15:50.000 bei der ein Mandant hohe Werte erreicht, während die anderen zurückfallen. 00:15:50.520 --> 00:15:52.380 Wirklich wichtig ist, ob Ihre sensiblen Inhalte 00:15:52.380 --> 00:15:53.760 einheitlich genug gekennzeichnet sind, 00:15:53.980 --> 00:15:56.520 damit das Verhalten von Co-Pilot nicht nur auf Vermutungen der Benutzer beruht. 00:15:56.960 --> 00:15:58.360 Sie streben hier keine Perfektion an, 00:15:58.660 --> 00:16:00.240 sondern ein vergleichbares Maß an Kontrolle 00:16:00.240 --> 00:16:02.100 für jeden Mandanten in Ihrem Unternehmen. 00:16:02.920 --> 00:16:04.920 Schließlich müssen Sie Ihre Zugriffstrifftrate nachverfolgen. 00:16:05.220 --> 00:16:06.440 Diese Metrik gibt Ihnen Aufschluss darüber, 00:16:06.520 --> 00:16:08.800 ob Ihre Bereinigungsbemühungen im Laufe der Zeit tatsächlich wirkend. 00:16:08.800 --> 00:16:10.560 Wie schnell breiten sich diese Berechtigungen 00:16:10.560 --> 00:16:12.580 nach Abschluss eines Behebungsprojekts wieder aus? 00:16:13.320 --> 00:16:15.560 Wie oft kehren diese großen Gruppen zum System zurück? 00:16:15.560 --> 00:16:17.240 Viele Teams bemerken dies zu spät, 00:16:17.280 --> 00:16:19.040 dass Sie die Fehlerbehebung einmal gemessen und angenommen haben, 00:16:19.080 --> 00:16:20.060 das Problem sei für immer behoben. 00:16:20.320 --> 00:16:20.800 Das war es nicht. 00:16:21.040 --> 00:16:22.240 Die einzige wichtige Kennzahl ist, 00:16:22.300 --> 00:16:23.440 wie schnell das System nachlässt, 00:16:23.480 --> 00:16:24.660 wenn man es nicht mehr genauer betrachtet. 00:16:25.000 --> 00:16:25.240 Vergehen. 00:16:25.500 --> 00:16:26.700 Das ist Ihr operatives Dashboard. 00:16:27.160 --> 00:16:28.540 Sie müssen die Reduzierung von Oversharing, 00:16:28.620 --> 00:16:29.760 die Abdeckung der Observability, 00:16:29.900 --> 00:16:31.240 die Zeit bis zur Richtlinienerstellung, 00:16:31.300 --> 00:16:33.300 die Abdeckung von Labels und die Zugriffsabweichungen nachverfolgen. 00:16:33.360 --> 00:16:34.660 Der Rhythmus Ihrer Berichterstattung 00:16:34.660 --> 00:16:36.160 ist genauso wichtig wie die Zahlen selbst. 00:16:36.340 --> 00:16:38.520 Der Hub sollte das Executive Dashboard besitzen, 00:16:38.840 --> 00:16:40.340 da die Unternehmensleitung eine einzige Sicht 00:16:40.340 --> 00:16:41.460 auf den gesamten Status benötigt. 00:16:41.460 --> 00:16:43.100 In der Zwischenzeit sollten die Spokes 00:16:43.100 --> 00:16:44.300 für die Behebung verantwortlich sein, 00:16:44.460 --> 00:16:46.020 da die eigentliche Arbeit dort stattfinden muss, 00:16:46.080 --> 00:16:47.120 wo die Mandantengrenze verläuft. 00:16:47.740 --> 00:16:48.640 Ein Team liest das System 00:16:48.640 --> 00:16:49.760 und das andere Team korrigiert es. 00:16:50.200 --> 00:16:51.420 Sie müssen diese Zahlen nachverfolgen, 00:16:51.500 --> 00:16:52.500 bevor Sie eine Erweiterung vornehmen 00:16:52.500 --> 00:16:52.940 und nicht im Namen. 00:16:53.280 --> 00:16:54.880 Das Risiko warte nicht auf Ihr nächstes Meeting 00:16:54.880 --> 00:16:55.840 oder Ihren nächsten Governance Work. 00:16:56.320 --> 00:16:58.080 Es ist bereits in jedem Mandanten aktiv, 00:16:58.240 --> 00:16:59.580 wo Co-Pilot genau feststellen kann, 00:16:59.660 --> 00:17:01.240 was Ihre aktuellen Kontrollen noch zulassen. 00:17:01.460 --> 00:17:03.120 Die beiden Muster die Führungskräfte übersehen. 00:17:03.660 --> 00:17:04.820 Ich sehe in der Praxis immer wieder 00:17:04.820 --> 00:17:05.940 zwei spezifische Muster 00:17:05.940 --> 00:17:07.020 und beide treten auf, 00:17:07.100 --> 00:17:08.120 weil Führungskräfte Co-Pilot 00:17:08.120 --> 00:17:09.080 wie eine Software-Einführung 00:17:09.080 --> 00:17:10.780 und nicht wie ein wichtiges Kontrollereignis behandeln. 00:17:11.180 --> 00:17:12.220 Das erste Muster beginnt, 00:17:12.280 --> 00:17:13.980 wenn eine Organisation Co-Pilot einführt, 00:17:14.120 --> 00:17:15.160 bevor sie eine echte Basis 00:17:15.160 --> 00:17:16.560 für den Zuständigkeitsbereich festlegt 00:17:16.560 --> 00:17:17.780 oder ihren SharePoint-Zugriff überprüft. 00:17:18.020 --> 00:17:19.600 Am ersten Tag sieht der Rollout perfekt aus. 00:17:20.020 --> 00:17:20.960 Lizenzen werden zugewiesen, 00:17:21.040 --> 00:17:22.000 die Benutzer sind begeistert 00:17:22.000 --> 00:17:22.880 und die internen Mitteilungen 00:17:22.880 --> 00:17:24.220 drehen sich nur um Produktivität. 00:17:24.820 --> 00:17:26.660 Doch dann beginnen normale Eingabeaufforderungen, 00:17:26.760 --> 00:17:27.580 Material abzurufen, 00:17:27.780 --> 00:17:29.320 das zwar die ganze Zeit technisch zugänglich war, 00:17:29.380 --> 00:17:30.240 für den durchschnittlichen Mitarbeiter 00:17:30.240 --> 00:17:31.200 jedoch praktisch unsichtbar war. 00:17:32.360 --> 00:17:34.000 Vor der KI hat niemand seinen Tag damit verbracht, 00:17:34.060 --> 00:17:35.000 sich durch alte Websites, 00:17:35.160 --> 00:17:37.080 veraltete Ordner oder geerbte Berechtigungen zu klicken, 00:17:37.080 --> 00:17:38.380 um Dinge zu finden, die er nicht sehen sollte. 00:17:38.980 --> 00:17:39.960 Aber jetzt müssen sie das nicht mehr. 00:17:40.420 --> 00:17:41.920 Ein Benutzer stellt eine einfache Frage, 00:17:42.060 --> 00:17:42.940 erhält eine Zusammenfassung 00:17:42.940 --> 00:17:43.880 und eine Datei wird angezeigt. 00:17:44.500 --> 00:17:46.460 Möglicherweise handelt es sich um sensible HR-Inhalte, 00:17:46.540 --> 00:17:48.160 Finanzmaterial oder Geschäftsinformationen, 00:17:48.160 --> 00:17:49.900 die nur in einem sehr engen Kreis aufbewahrt werden sollen. 00:17:50.300 --> 00:17:51.320 Es gab keine Sicherheitsverletzung, 00:17:51.420 --> 00:17:51.940 keine Malware 00:17:51.940 --> 00:17:53.260 und keine Verletzung der Sicherheitsgrenze 00:17:53.260 --> 00:17:53.960 im herkömmlichen Sinne. 00:17:54.440 --> 00:17:56.140 Das System verwendete einfach die Berechtigung 00:17:56.140 --> 00:17:56.980 und den Inhaltsstatus, 00:17:57.040 --> 00:17:58.320 die der Mandant bereits zugelassen hatte. 00:17:58.680 --> 00:17:59.300 Das ist der Moment, 00:17:59.400 --> 00:18:00.940 in dem viele Teams endlich das Problem verstehen. 00:18:01.380 --> 00:18:02.700 KI hat die Gefährdung nicht verursacht. 00:18:03.120 --> 00:18:04.180 Sie hat lediglich die Reibungspunkte, 00:18:04.180 --> 00:18:05.040 beseitigt diese bisher verdeckt. 00:18:05.480 --> 00:18:07.040 Sobald dies bei einem Mandanten geschieht, 00:18:07.300 --> 00:18:08.440 sinkt für gewöhnlich das Vertrauen 00:18:08.440 --> 00:18:09.940 der Führungskräfte im gesamten Unternehmen, 00:18:10.340 --> 00:18:11.520 da niemand mit Sicherheit sagen kann, 00:18:11.580 --> 00:18:13.240 wo dasselbe Muster als nächstes auftreten könnte. 00:18:13.700 --> 00:18:15.240 Der Vorfall mag lokal begrenzt erscheinen, 00:18:15.240 --> 00:18:16.700 doch der Vertrauensschaden ist unternehmensweit. 00:18:17.160 --> 00:18:18.660 Das zweite Muster ist weniger aufwendig, 00:18:18.720 --> 00:18:19.480 aber genauso gefährlich. 00:18:19.860 --> 00:18:21.600 Ein Unternehmen richtet mandantenübergreifende 00:18:21.600 --> 00:18:22.780 Identitätsbeziehungen ein, 00:18:22.860 --> 00:18:24.780 erfährt, dass mandantenfähige Szenarien möglich sind 00:18:24.780 --> 00:18:25.600 und geht davon aus, 00:18:25.660 --> 00:18:26.980 dass sein Betriebsmodell ausgereift genug 00:18:26.980 --> 00:18:28.120 für eine flächendeckende Einführung ist. 00:18:28.500 --> 00:18:29.960 Auf Folien klingt das nach einem soliden Plan. 00:18:30.520 --> 00:18:32.060 In der Realität werden die Abläufe jedoch chaotisch. 00:18:32.540 --> 00:18:34.840 Ein Team erwartet eine reibungslose Co-Pilot-Erfahrung 00:18:34.840 --> 00:18:36.040 in jeder verbundenen Umgebung, 00:18:36.340 --> 00:18:38.440 während ein anderes eine vergleichbare Transparenz erwartet 00:18:38.440 --> 00:18:39.500 und ein drittes davon ausgeht, 00:18:39.560 --> 00:18:41.240 dass dem Benutzer überall dieselben Kontrollen folgen. 00:18:41.560 --> 00:18:43.120 Dann zeigt die tatsächliche Nutzung 00:18:43.120 --> 00:18:44.040 uneinheitliches Verhalten, 00:18:44.400 --> 00:18:45.420 Lücken bei der Authentifizierung 00:18:45.420 --> 00:18:47.120 und Schwachstellen bei den tatsächlich messbaren Daten. 00:18:47.540 --> 00:18:48.160 Das Problem ist nicht, 00:18:48.240 --> 00:18:49.260 dass diese Teams nachlässig waren. 00:18:49.840 --> 00:18:50.580 Das eigentliche Problem ist, 00:18:50.660 --> 00:18:52.480 dass sie Konnektivität in Sicherheit übersetzt haben. 00:18:53.240 --> 00:18:54.740 Diese Annahme vermittelt ein falsches Bild 00:18:54.740 --> 00:18:55.260 von der Compline. 00:18:55.760 --> 00:18:57.380 Die Unternehmensleitung hört das Wort vernetzt 00:18:57.380 --> 00:18:58.100 und geht davon aus, 00:18:58.100 --> 00:18:59.180 dass die Organisation bereit ist. 00:19:00.000 --> 00:19:01.880 Monate später stellen Kontrollüberprüfungen fest, 00:19:01.960 --> 00:19:03.560 dass Verhalten, Nachweise und Durchsetzung 00:19:03.560 --> 00:19:04.580 viel stärker voneinander abwichen, 00:19:04.640 --> 00:19:05.980 als anfangs irgendjemand zugeben wollte. 00:19:06.560 --> 00:19:07.840 Vergleichen wir das nun mit einem besseren Muster. 00:19:08.280 --> 00:19:09.640 Eine andere Organisation entscheidet sich dafür, 00:19:09.740 --> 00:19:10.300 langsamer vorzugehen, 00:19:10.360 --> 00:19:10.900 nur vor sie hochskaliert. 00:19:11.200 --> 00:19:12.860 Sie legt zunächst eine Label-Baseline fest, 00:19:13.100 --> 00:19:14.380 überprüft zunächst den breiten Zugriff 00:19:14.380 --> 00:19:15.760 und validiert ihre Audit-Transparenz, 00:19:15.820 --> 00:19:16.900 bevor sie andere Maßnahmen ergreift. 00:19:17.320 --> 00:19:18.900 Sie weitet Co-Pilot in Wellen aus, 00:19:19.000 --> 00:19:20.500 nicht weil sie Angst vor der Einführung haben, 00:19:20.740 --> 00:19:21.400 sondern weil sie möchten, 00:19:21.520 --> 00:19:23.060 dass jede Welle brauchbare Nachweise liefert, 00:19:23.160 --> 00:19:24.040 bevor die nächste beginnt. 00:19:24.820 --> 00:19:26.440 Diese Organisation kommt auf lange Sicht 00:19:26.440 --> 00:19:27.400 in der Regel schneller voran, 00:19:27.460 --> 00:19:28.580 da sie nicht ständig anhalten muss, 00:19:28.640 --> 00:19:29.620 um Überraschungen zu erklären, 00:19:29.800 --> 00:19:31.200 exponierte Inhalte zu bereinigen 00:19:31.200 --> 00:19:32.200 oder darüber zu streiten, 00:19:32.280 --> 00:19:33.800 was Kontrollierte eigentlich bedeuten soll. 00:19:34.520 --> 00:19:35.180 Das ist der Vorteil, 00:19:35.220 --> 00:19:36.300 den die meisten Führungskräfte übersetzen. 00:19:36.540 --> 00:19:38.100 Eine gute Governance blockiert ihren Rollout nicht. 00:19:38.760 --> 00:19:40.420 Sie beseitigt die Verzögerung des Rollouts, 00:19:40.500 --> 00:19:41.880 nachdem die erste Welle abgeschlossen ist. 00:19:42.260 --> 00:19:43.440 Die Falle ist nicht die Einführung selbst. 00:19:43.780 --> 00:19:45.360 Die Falle ist die nicht verwaltete Einführung 00:19:45.360 --> 00:19:46.200 über Mandanten hinweg, 00:19:46.300 --> 00:19:47.580 die aus der Ferne verbunden erscheinen, 00:19:47.660 --> 00:19:49.180 sich aber aus der Nähe ganz anders verhalten. 00:19:50.300 --> 00:19:51.680 Die Entscheidung, die sie treffen müssen, 00:19:51.740 --> 00:19:52.480 ist eigentlich ganz einfach. 00:19:53.300 --> 00:19:54.520 Sie müssen jetzt zu einem föderierten 00:19:54.520 --> 00:19:56.180 Hubensburg-KI-Governance-Modell wechseln 00:19:56.180 --> 00:19:58.120 und aufhören, das Umschalten von Mandant zu Mandant 00:19:58.120 --> 00:19:59.660 mit tatsächlicher Kontrolle zu verwechseln. 00:20:00.340 --> 00:20:01.740 Sie sollten Ihre Co-Pilot-Erweiterung 00:20:01.740 --> 00:20:02.840 in jedem Mandanten pausieren, 00:20:03.040 --> 00:20:03.840 der seine Protokollierung, 00:20:03.920 --> 00:20:05.040 seine Oversharing-Überprüfungen, 00:20:05.120 --> 00:20:06.120 seine Label-Baseline-Abdeckung 00:20:06.120 --> 00:20:06.800 nicht nachweisen kann. 00:20:07.260 --> 00:20:08.620 DKI wird sich an dem System orientieren, 00:20:08.680 --> 00:20:09.560 das Sie tatsächlich aufbauen 00:20:09.560 --> 00:20:10.380 und nicht an dem Organigramm, 00:20:10.400 --> 00:20:10.880 dem Sie unterstellt. 00:20:11.320 --> 00:20:12.120 Wenn dies Ihre Sicht 00:20:12.120 --> 00:20:13.680 auf die Multi-Tenant-Copilot-Governance 00:20:13.680 --> 00:20:14.180 verändert hat, 00:20:14.360 --> 00:20:15.560 folgen Sie mir, Mirko Peters, 00:20:15.640 --> 00:20:15.960 auf LinkedIn 00:20:15.960 --> 00:20:17.280 und teilen Sie dies mit Ihrem Team, 00:20:17.420 --> 00:20:18.020 wenn Sie sich gerade 00:20:18.020 --> 00:20:18.960 mit diesem Problem befassen.