Copilot-Readiness mit Purview: die Checkliste vor dem Rollout – vier Beine, fünf Phasen, eine Ampel

Der Vorstand hatte Copilot auf der Messe gesehen und wollte es bis zum Quartalsende für alle. Die IT hatte drei Wochen. Also: Lizenzen zugewiesen, Kurzschulung, los. In der zweiten Woche fragte ein Sachbearbeiter aus dem Vertrieb Copilot nach „den aktuellen Gehaltsbändern für Vertriebsleiter" – aus Neugier, sagte er später – und bekam eine ordentliche Tabelle mit Quelle: eine Excel-Datei aus einer HR-Site, freigegeben 2017 an „Jeder außer externe Benutzer", von der niemand mehr wusste. Er hatte kein Recht verletzt. Er hatte gefragt. Copilot hatte gefunden, was er sehen durfte. Am Freitag lag das Thema beim Betriebsrat, am Montag beim Datenschutzbeauftragten, und Copilot war für ein halbes Jahr abgeschaltet.

Copilot-Readiness ist kein Copilot-Thema, sondern ein Purview-Thema, und der Satz aus dem Pillar gilt unverändert: Vor Copilot musste man die falsch berechtigte Freigabe erst finden – mit Copilot reicht eine höfliche Frage. Microsoft 365 Copilot arbeitet mit den Berechtigungen des Benutzers und findet alles, was dieser Benutzer sehen darf; es respektiert Sensitivity Labels und Verschlüsselung; es hält sich an DLP-Richtlinien; und es protokolliert. Vier Dinge, die es tut – und vier Beine, auf denen ein Rollout stehen muss: eine Bestandsaufnahme mit DSPM for AI, Labels mit Verschlüsselung für die Kronjuwelen, DLP für KI-Interaktionen und Berechtigungshygiene. Wer die Reihenfolge überspringt, führt kein Copilot ein, sondern ein Enthüllungswerkzeug mit Lizenzgebühr.

Dieser Artikel ist der Fahrplan: Er erklärt die vier Beine als Ampel mit klaren Kriterien, führt durch fünf Phasen mit Zeitschätzung, Verantwortlichkeiten und Erfolgskriterien und endet bei der Freigabeentscheidung, die nicht tenantweit, sondern je Nutzergruppe fällt. Die Werkstätten dahinter haben eigene Spokes – DSPM for AI im Detail, Oversharing in SharePoint beheben, Was Copilot sieht – und was nicht –, und die Copilot-Einführung selbst mit Lizenz, Anwendungsfällen und Adoption ist Sache des Copilot-Kompetenzbereichs. Hier geht es um die Absicherungsseite, und wo die im Gesamtbild sitzt, zeigt der Überblick zum Kompetenzbereich Microsoft Purview.

Warum Copilot ohne Reihenfolge ein Enthüllungswerkzeug ist – und was die vier Beine leisten

Copilot tut nichts Böses. Es beantwortet Fragen mit den Inhalten, die der fragende Benutzer lesen darf – aus SharePoint, OneDrive, Exchange, Teams, über den semantischen Index von Microsoft Graph. Das Problem ist nicht Copilot, sondern das Wort „darf": In fast jedem gewachsenen Tenant dürfen Benutzer viel mehr lesen, als irgendjemand beabsichtigt hat. Freigabelinks an „Jeder in der Organisation" aus 2018, öffentliche Teams mit HR-Unterlagen, Projekt-Sites, deren Besitzer längst weg sind, OneDrives mit Kundenlisten in geteilten Ordnern. Bisher war das theoretisch: Wer die Gehaltsliste finden wollte, musste wissen, dass sie existiert, und wo. Copilot macht daraus eine Frage. Die vier Beine der Readiness sind die Antworten darauf – und sie haben eine Reihenfolge, die man nicht umdrehen sollte.

Die vier Beine im Überblick

Bein eins ist die Bestandsaufnahme: Bevor jemand etwas schützt, muss er wissen, was wo liegt und wer es sieht. DSPM for AI zeigt Oversharing-Bewertungen und sensible Daten in erreichbaren Inhalten, der Content Explorer die Verteilung von Sensitive Info Types und Labels je Site, die Oversharing-Berichte aus SharePoint Advanced Management die Sites mit den meisten offenen Freigaben – und die Fachbereiche sagen, was ihre Kronjuwelen sind. Bein zwei sind Sensitivity Labels mit Verschlüsselung: Ein Label ohne Verschlüsselung schützt nicht vor einer Zusammenfassung durch Copilot; ein Label mit Verschlüsselung, bei dem dem Benutzer das EXTRACT-Recht fehlt, schließt das Dokument als Quelle aus – das ist die einzige harte Copilot-Grenze. Bein drei ist DLP für KI: eine Richtlinie für den Speicherort Copilot, die Inhalte mit bestimmten Labels von der Verarbeitung ausschließt, und die Domänen-Ampel für Uploads an fremde KI-Dienste – beides gehört in ein Regelwerk, sonst widerspricht sich das eine dem anderen. Bein vier ist die Berechtigungshygiene: „Jeder"-Links abschalten, öffentliche Teams mit sensiblen Daten schließen, verwaiste Sites bereinigen, Container-Labels ausrollen – und für Sites, die heute nicht bereinigt werden können, Restricted Content Discovery als Notbremse.

Die Reihenfolge und ihre Begründung

Die Reihenfolge ist keine Pedanterie. Wer Labels ausrollt, bevor er weiß, wo die Kronjuwelen liegen, labelt das Falsche. Wer Berechtigungen aufräumt, bevor die Kronjuwelen verschlüsselt sind, hat nach dem Aufräumen immer noch Dokumente, die jeder Berechtigte per Copilot zusammenfassen kann. Wer DLP für Copilot baut, ohne dass Labels existieren, hat eine Richtlinie ohne Bedingung. Und wer mit dem Pilot beginnt, bevor die Bestandsaufnahme fertig ist, lernt aus dem Pilot, was er vorher hätte wissen können – meistens am Beispiel einer Gehaltsliste. Deshalb: erst sehen, dann labeln, dann Regeln, dann aufräumen, dann Pilot. Die Phasen überlappen sich, weil das Aufräumen lange dauert und die Sofortmaßnahmen früh kommen müssen, aber die Logik bleibt. Und sie mündet in eine Ampel: vier Beine, jedes rot, gelb oder grün, mit Kriterien, die man prüfen kann – und mit einer Freigaberegel, die aus der Ampel folgt.

Skizze 1: Die Readiness-Ampel – vier Beine mit Kriterien für Rot, Gelb und Grün, und die Freigaberegel daraus.

Der Fahrplan: fünf Phasen in rund vier Monaten

Aus den vier Beinen wird ein Fahrplan mit fünf Phasen, die in Projekten bei einem Mittelständler mit einigen hundert bis wenigen tausend Anwendern rund vier Monate dauern – bei Konzernen mit vielen Standorten und Betriebsräten länger, bei kleinen Häusern mit sauberem Tenant kürzer. Die Zahl, die dabei am häufigsten diskutiert wird, ist nicht die Dauer, sondern der Startpunkt: Viele Unternehmen haben Copilot-Lizenzen längst gekauft und wollen sie nutzen. Die ehrliche Antwort lautet: Wer heute rot ist, verliert mit einem Aufschub Lizenzkosten – wer heute rot ist und trotzdem startet, verliert das Vertrauen des Betriebsrats und im schlimmsten Fall die Meldung an die Aufsichtsbehörde. Das erste ist Geld, das zweite ist ein halbes Jahr.

Phase null ist die Bestandsaufnahme, zwei bis drei Wochen: DSPM for AI aktivieren, Oversharing-Bericht ziehen, Content Explorer je Site auswerten, „Jeder"-Links und öffentliche Teams zählen, Fachbereiche nach ihren Kronjuwelen fragen – Betriebsrat und Datenschutzbeauftragter sitzen ab hier am Tisch. Ergebnis ist eine Landkarte mit den zwanzig riskantesten Sites. Phase eins sind die Sofortmaßnahmen, zwei Wochen: „Jeder"-Links tenantweit abschalten, Top-Risiko-Sites per Restricted Content Discovery aus dem Copilot-Suchraum nehmen oder sperren, öffentliche Teams mit HR- und Finanzdaten auf privat stellen. Das ist Absperren, kein Aufräumen – aber es macht aus einem roten Bein vier ein gelbes. Phase zwei ist das Labeln der Kronjuwelen, sechs bis acht Wochen: Stufenmodell einführen, falls keines existiert; Kronjuwelen-Sites mit Labels versehen, die verschlüsseln und für Copilot ohne EXTRACT-Recht arbeiten; Auto-Labeling zuerst simulieren, dann für die Top-Sites scharf schalten. Phase drei ist DLP für KI, vier bis sechs Wochen, überlappend: Copilot-DLP im Audit-Modus, dann „Streng vertraulich" ausschließen; Domänen-Ampel für Schatten-KI mit Warnen und freigegebenem Weg; Retention für Copilot-Interaktionen; Betriebsvereinbarung unterschrieben. Phase vier ist Hygiene plus Pilot, sechs Wochen: Container-Labels auf alle Teams, Access Reviews für Gäste, verwaiste Sites mit Besitzern versorgen oder archivieren – und parallel ein Pilot mit zwanzig bis fünfzig Anwendern aus den Bereichen, deren Ampel gelb oder besser ist, mit aktivem Audit und definierten Abbruchkriterien.

Skizze 2: Der Readiness-Fahrplan – fünf Phasen mit Aufgaben und Ergebnissen; die Sofortmaßnahmen kommen früh, das Aufräumen dauert.

Die Tabelle fasst den Fahrplan zusammen: Phase, Dauer, wer verantwortet, welche Werkzeuge und woran man das Ende erkennt. Die Dauern sind Erfahrungswerte für einen Mittelständler; die Verantwortlichkeiten sind das, was in Projekten am häufigsten fehlt.

Verantwortlichkeiten und Gremien: wer was trägt

Der häufigste Grund, warum Readiness-Projekte stocken, ist nicht Technik, sondern die Frage, wer eigentlich zuständig ist. Die IT kann DSPM aktivieren, Labels anlegen und Links abschalten – aber sie kann nicht entscheiden, welche Dokumente Kronjuwelen sind, ob ein Team wirklich privat sein muss oder ob die Ablage von 2009 archiviert werden darf. Das können nur die Fachbereiche und die Site-Besitzer, und die haben andere Prioritäten als Purview. Deshalb braucht der Fahrplan von Anfang an eine Verteilung, die über die IT hinausgeht: Das Copilot-Projekt – meist ein Team aus IT, Kommunikation und einem Sponsor aus der Geschäftsführung – trägt den Fahrplan und die Freigabe. Die IT trägt die Purview-Konfiguration und die Berichte. Die Fachbereiche tragen die Benennung der Kronjuwelen und das Labeln in ihren Bibliotheken. Die Site-Besitzer tragen die Bereinigung ihrer Sites – mit Frist. Der Datenschutzbeauftragte trägt die Datenschutz-Folgenabschätzung für Copilot und die Freigabe der Label-Stufen. Und der Betriebsrat trägt die Betriebsvereinbarung, die vor Phase drei stehen muss und ohne die es keinen Pilot gibt.

Was in dieser Verteilung erfahrungsgemäß fehlt, ist die Ehrlichkeit über die Sofortmaßnahmen: Restricted Content Discovery und das Sperren von Sites sind Notbremsen. Sie nehmen Inhalte aus dem Copilot-Suchraum, ohne dass jemand die Berechtigungen aufgeräumt hat – die Gehaltsliste ist immer noch für alle lesbar, nur findet Copilot sie nicht mehr. Das ist für den Pilot ausreichend und für den Rollout nicht. Wer die Notbremse als Readiness verkauft, hat ein Bein vier, das gelb aussieht und rot ist; die Aufräumarbeit gehört trotzdem in Phase vier und in den Dauerbetrieb, wie sie der Spoke zum Oversharing in SharePoint beschreibt.

Erfolgskriterien und die Freigabeentscheidung: je Nutzergruppe, nicht tenantweit

Die wichtigste Erkenntnis aus Readiness-Projekten passt in einen Satz: Copilot wird nicht tenantweit freigegeben, sondern je Nutzergruppe – nach der Ampel der Bereiche, in denen diese Gruppe arbeitet. Der Vertrieb, der in bereinigten Projekt-Sites arbeitet, kann grün sein, während die Personalabteilung mit ihrer fünfzehn Jahre alten Ablage rot ist. Eine tenantweite Freigabe wartet entweder auf den langsamsten Bereich oder gibt dem gefährlichsten zu früh frei; die Freigabe je Gruppe löst beides. Sie braucht Kriterien, die man prüfen kann, und die kommen aus den vier Beinen: Für jedes Bein eine Handvoll Kennzahlen, die aus DSPM, Content Explorer, Oversharing-Berichten und Audit-Log ablesbar sind – und eine Regel, ab wann gelb und ab wann grün gilt.

Die Freigaberegel selbst ist einfach: Pilot ab „alle vier Beine gelb", Rollout ab „drei grün, eines gelb", kein Copilot bei einem roten Bein – für diese Nutzergruppe, in diesem Bereich. Der Pilot bekommt Grenzen: zwanzig bis fünfzig Anwender, Audit-Log aktiv und wöchentlich gesichtet, Copilot-DLP mindestens im Warnmodus, DSPM-Wochenbericht, und Abbruchkriterien, die vorher festgelegt sind – etwa ein Copilot-Treffer auf ein Dokument, das nach Bestandsaufnahme nicht hätte gefunden werden dürfen. Was das Audit-Log über Copilot-Interaktionen verrät und wie man es dafür einsetzt, beschreibt der Spoke zum Copilot-Audit. Und wer heute rot ist, aber Lizenzen hat, kann Copilot Chat ohne Zugriff auf Unternehmensdaten als Übergang nutzen – das ist der abgesicherte Weg, den der Spoke zur DLP gegen Schatten-KI beschreibt, und er kostet keine Readiness.

Skizze 3: Die Freigabeentscheidung je Nutzergruppe – Ampel der Sites, in denen die Gruppe arbeitet, und die drei Ausgänge.

Als Umsetzungshilfe die Kennzahlen je Bein, mit denen sich die Ampel für einen Bereich bestimmen lässt. Die Schwellen sind Erfahrungswerte aus Projekten und sollten mit Datenschutzbeauftragtem und Betriebsrat festgelegt werden – entscheidend ist, dass sie vor dem Pilot feststehen, nicht danach.

Der Deutschland-Winkel: Betriebsvereinbarung, DSFA und NIS2

Copilot berührt in Deutschland zwei Regelungsbereiche, die vor dem Pilot geklärt sein müssen. Der erste ist die Mitbestimmung: Copilot wertet Kommunikation aus, greift auf Chatverläufe zu, protokolliert jede Interaktion im Audit-Log, und diese Protokolle lassen sich nach Person auswerten – § 87 Abs. 1 Nr. 6 BetrVG in Reinform, mitbestimmungspflichtig, bevor der erste Pilotanwender eine Frage stellt. Die Betriebsvereinbarung sollte den Copilot-Einsatz, die Auswertung von Interaktionsprotokollen (Zweck, Rollen, Anlässe, Löschfristen), die DLP-Regeln für Copilot und die Frage der Leistungskontrolle regeln – und sie gehört in den Fahrplan vor Phase drei, nicht als Nachtrag. Meine Erfahrung: Betriebsräte reagieren auf den Readiness-Fahrplan positiv, weil er das Gegenteil von „einschalten und sehen" ist – sie wollen belastbare Antworten darauf, was Copilot sehen kann, was es protokolliert und was abschaltbar ist, und die Ampel liefert genau das. Was in die Vereinbarung gehört, beschreibt der Spoke zur Betriebsvereinbarung für Purview.

Der zweite Bereich ist der Datenschutz: Copilot ist eine neue Verarbeitung personenbezogener Daten mit hohem Risiko – automatisierte Auswertung, große Datenmengen, Beschäftigtendaten –, für die eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO regelmäßig angezeigt ist, und die Bestandsaufnahme aus Phase null ist zugleich das Material dafür: Welche personenbezogenen Daten liegen wo, wer kann sie über Copilot erreichen, welche Maßnahmen greifen. Der Datenschutzbeauftragte ist deshalb ab Phase null dabei, prüft die Label-Stufen und die Copilot-DLP-Regeln und zeichnet die Freigabe je Nutzergruppe mit ab. Für NIS2-pflichtige Unternehmen ist die Einführung einer KI, die Zugriff auf alle Unternehmensdaten hat, ein Vorgang, der ins Risikomanagement gehört – und der Readiness-Fahrplan mit Bestandsaufnahme, Zugriffskontrolle und Protokollierung ist der Nachweis, dass das Risiko behandelt wurde. Wie immer: keine Rechtsberatung, Stand 2026 – Datenschutzbeauftragter, Betriebsrat und bei Bedarf ein Jurist gehören ab Phase null an den Tisch.

Stolperfallen aus der Praxis

Der Pilot ist Phase null. „Wir schalten mal ein und schauen" – und der erste Fund ist die Gehaltsliste, der zweite der Betriebsrat. Bestandsaufnahme zuerst, Pilot zuletzt, und nur in gelben oder grünen Bereichen.

Tenantweite Freigabe. Alle bekommen Copilot, weil der Vorstand es will – auch die Personalabteilung mit der Ablage von 2009. Freigabe je Nutzergruppe nach der Ampel der Bereiche.

Notbremse als Readiness verkauft. Restricted Content Discovery auf hundert Sites, Bein vier steht auf gelb, und niemand räumt je auf. Liste mit Besitzer und Frist, Phase vier abarbeiten.

Labels ohne Verschlüsselung als Copilot-Schutz. Das Label „Vertraulich" ist gesetzt, verschlüsselt aber nicht – Copilot fasst zusammen wie zuvor. Nur Verschlüsselung ohne EXTRACT hält Copilot draußen.

Betriebsvereinbarung nach dem Pilot. Der Pilot läuft, das Audit-Log füllt sich mit Prompts, der Betriebsrat erfährt es aus dem Rundschreiben. Vereinbarung vor Phase drei, Betriebsrat ab Phase null.

Die IT allein. Fachbereiche nennen keine Kronjuwelen, Site-Besitzer räumen nicht auf, und die IT versucht, es selbst zu tun. Verantwortlichkeiten mit Fristen, Sponsor aus der Geschäftsführung, Copilot-Projekt statt Purview-Projekt.

Fazit: Erst sehen, dann labeln, dann Regeln, dann aufräumen – dann Copilot

Copilot-Readiness ist ein Fahrplan mit vier Beinen und fünf Phasen: die Bestandsaufnahme mit DSPM for AI und Oversharing-Berichten, Sofortmaßnahmen als Notbremse, Kronjuwelen mit Verschlüsselung ohne EXTRACT, DLP für Copilot und Schatten-KI in einem Regelwerk, Berechtigungshygiene im Dauerbetrieb – und am Ende eine Ampel je Bereich, aus der die Freigabe je Nutzergruppe folgt, nicht tenantweit. Rund vier Monate, mit Fachbereichen, Site-Besitzern, Datenschutzbeauftragtem und Betriebsrat, mit Kennzahlen, die man prüfen kann. Wer diesen Weg geht, führt Copilot ein; wer ihn überspringt, führt ein Enthüllungswerkzeug ein und erfährt es vom Betriebsrat. Wo die Readiness im Gesamtbild aus Labels, DLP und Aufbewahrung sitzt, zeigt der Purview-Überblick; was Copilot selbst kann und wie die Einführung jenseits der Absicherung läuft, der Copilot-Kompetenzbereich.

Wenn du wissen willst, wie die Ampel deines Tenants heute aussieht – wie viele „Jeder"-Links, wie viele offene Teams mit sensiblen Daten, wie viele Kronjuwelen ohne Label – und welche Nutzergruppe morgen starten könnte: Die Copilot-Readiness als Baustein der Purview-Beratung liefert genau diese Bestandsaufnahme mit Ampel und Fahrplan – kompakt, zum Festpreis, mit Aktionsplan je Bein.

FAQ: Häufige Fragen zur Copilot-Readiness mit Purview

Was bedeutet Copilot-Readiness?

Copilot-Readiness ist der Zustand eines Microsoft-365-Tenants, in dem Microsoft 365 Copilot eingeführt werden kann, ohne dass Anwender über die KI Inhalte finden, die sie zwar technisch sehen dürfen, aber nie sehen sollten. Sie steht auf vier Beinen: Bestandsaufnahme (DSPM for AI, Oversharing-Berichte), Sensitivity Labels mit Verschlüsselung für die Kronjuwelen, DLP für KI-Interaktionen und Berechtigungshygiene. Copilot selbst vergibt keine neuen Rechte – es macht die vorhandenen sichtbar.

Wie lange dauert die Copilot-Readiness?

Bei einem Mittelständler mit einigen hundert bis wenigen tausend Anwendern rund vier Monate: zwei bis drei Wochen Bestandsaufnahme, zwei Wochen Sofortmaßnahmen, sechs bis acht Wochen Labeln der Kronjuwelen, vier bis sechs Wochen DLP für KI und Betriebsvereinbarung, sechs Wochen Hygiene und Pilot – teils überlappend. Konzerne mit vielen Standorten brauchen länger, kleine Häuser mit sauberem Tenant kürzer. Entscheidend ist weniger die Dauer als die Reihenfolge und die Freigabe je Nutzergruppe.

Reicht es, Copilot einzuschalten, weil es die Berechtigungen respektiert?

Nein. Copilot respektiert die Berechtigungen – und genau die sind in gewachsenen Tenants das Problem: „Jeder"-Freigabelinks, öffentliche Teams mit Personaldaten, verwaiste Sites. Bisher musste man solche Inhalte finden, mit Copilot reicht eine Frage. Readiness heißt, diese Altlasten vor dem Rollout zu sehen, die Kronjuwelen zu verschlüsseln, DLP-Regeln zu setzen und aufzuräumen – nicht Copilot abzuschalten, sondern das Fundament zu bauen.

Was ist der Unterschied zwischen Restricted Content Discovery und echter Berechtigungshygiene?

Restricted Content Discovery nimmt eine SharePoint-Site aus dem Suchraum von Copilot und der organisationsweiten Suche, ohne Berechtigungen zu ändern – wer direkten Zugriff hat, kann die Site weiter öffnen. Es ist eine Notbremse für den Pilot, keine Readiness. Berechtigungshygiene heißt, „Jeder"-Links zu entfernen, öffentliche Teams mit sensiblen Daten zu schließen, verwaiste Sites zu bereinigen und Container-Labels auszurollen, damit die Berechtigungen dem entsprechen, was beabsichtigt ist.

Brauche ich für Copilot-Readiness Microsoft 365 E5?

Nicht zwingend, aber es hilft. Sensitivity Labels mit Verschlüsselung, DLP für Exchange, SharePoint und Teams sowie das Audit-Log Standard sind in E3 enthalten; Auto-Labeling, DSPM for AI im vollen Umfang, Endpoint DLP für Schatten-KI und Audit Premium brauchen E5 oder E5 Compliance. SharePoint Advanced Management mit Oversharing-Berichten und Restricted Content Discovery ist in der Copilot-Lizenz enthalten. Microsoft 365 Copilot selbst ist ein separates Add-on (Stand 2026).

Muss der Betriebsrat der Copilot-Einführung zustimmen?

Copilot wertet Kommunikation aus, greift auf Chats zu und protokolliert jede Interaktion im Audit-Log – eine technische Einrichtung, die zur Verhaltenskontrolle geeignet ist, und damit nach § 87 Abs. 1 Nr. 6 BetrVG mitbestimmungspflichtig, bevor der Pilot beginnt. Die Betriebsvereinbarung sollte Einsatz, Protokollauswertung, DLP-Regeln und Leistungskontrolle regeln; parallel ist eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO regelmäßig angezeigt. Das ist Praxiserfahrung, keine Rechtsberatung (Stand 2026).

Wo fange ich mit der Copilot-Readiness an?

Mit der Bestandsaufnahme, nicht mit dem Pilot: DSPM for AI aktivieren, Oversharing-Bericht ziehen, „Jeder"-Links und öffentliche Teams zählen, Fachbereiche nach ihren Kronjuwelen fragen – mit Betriebsrat und Datenschutzbeauftragtem am Tisch. Danach die Sofortmaßnahmen, dann Labels mit Verschlüsselung für die Kronjuwelen, DLP für KI, Hygiene – und ein Pilot nur in Bereichen, deren Ampel gelb oder besser ist. Wer heute rot ist, nutzt Copilot Chat ohne Graph-Zugriff als Übergang.