Microsoft Copilot in der Praxis

Security, Compliance und Governance für den ehrlichen Rollout

Microsoft Copilot ist das wahrscheinlich am meisten missverstandene Produkt im Microsoft-Universum. Die einen halten ihn für einen besseren Schreibassistenten, der höflichere E-Mails formuliert. Die anderen erwarten den heiligen Gral der Produktivität. Beide Lager haben in einem Punkt recht: Copilot kann tatsächlich verblüffend gute Ergebnisse liefern. In einem zweiten Punkt liegen beide spektakulär daneben: Sie unterschätzen, was Copilot mit der Datenhygiene eines Tenants anstellt.

Denn Copilot ist im Kern keine neue Anwendung. Copilot ist eine sehr schnelle, sehr fleißige Suchmaschine über alles, was der angemeldete User innerhalb des Microsoft-365-Tenants sehen darf. Plus eine Schicht Sprachmodell obendrauf, die das Gefundene zusammenfasst, umformuliert und höflich präsentiert. Der Effekt: Was Tante Erna aus der Buchhaltung seit acht Jahren versehentlich sehen darf, weil 2017 jemand bei einer SharePoint-Berechtigung das falsche Häkchen gesetzt hat, findet Copilot in unter einer Sekunde. Garniert mit einer freundlichen Zusammenfassung, sauber formatiert.

Dieser Pillar liefert die Basis für einen Copilot-Rollout, der nicht im Vorstand mit einer unangenehmen Frage des Datenschutzbeauftragten endet. Im Mittelpunkt stehen die drei Themen, die in der Microsoft-Marketingfolie meistens fehlen: Sicherheit, Compliance und Governance.

Drei Bemerkungen vorweg, damit klar ist, in welche Richtung dieser Text geht. Erstens: Copilot ist kein Produkt für unfertige Tenants. Wer Microsoft 365 als Sammlung lose verbundener Postfächer betreibt, sollte zuerst dort aufräumen. Zweitens: Das größte Risiko ist nicht das Sprachmodell, sondern das eigene Berechtigungsmodell. Microsoft hat das LLM gut eingehegt – das eigene SharePoint hat das niemand. Drittens: Copilot belohnt vorhandene Ordnung und bestraft vorhandene Unordnung. Beides verstärkt sich.

Die unbequeme Wahrheit über Copilot-Rollouts

Bevor du auch nur eine einzige Lizenz vergibst, lohnt sich ein ehrlicher Blick in den Tenant. Die Erfahrung aus zahlreichen Beratungsprojekten zeigt: Mehr als die Hälfte aller Microsoft-365-Tenants hat ein Oversharing-Problem in einer Größenordnung, die niemand wahrhaben will. SharePoint-Sites mit Berechtigung „Jeder im Unternehmen außer externe Benutzer“, OneDrive-Freigaben mit anonymen Links aus dem Jahr 2019, vergessene M365-Gruppen mit aktivem Public-Access. Solange niemand explizit sucht, fällt das nicht auf. Copilot sucht aber permanent.

Der zweite Klassiker: Sensitivity Labels existieren entweder gar nicht oder nur auf dem Papier. In einem typischen Tenant trägt vielleicht jedes zwanzigste vertrauliche Dokument tatsächlich ein passendes Label. Der Rest läuft nackt durch die Gegend. Ohne Label keine Vererbung, ohne Vererbung keine Kontrolle darüber, was Copilot mit den Inhalten in seiner Antwort anstellt.

Drittens: Niemand hat eine Übersicht, welche Plugins, Connectoren oder Copilot-Studio-Agents im Tenant inzwischen herumschwirren. Was als „kreativer Power-User“ in der Fachabteilung anfängt, ist sechs Monate später eine Schatten-IT in der Cloud-Variante.

Der Pre-Flight-Check vor jedem Rollout besteht deshalb aus drei nicht verhandelbaren Punkten: Permission-Audit, Label-Strategie, Agent-Inventur. Wer das überspringt, baut auf Sand.

Die drei Säulen der Copilot-Governance

Eine belastbare Copilot-Governance ruht auf drei Säulen, die unabhängig voneinander funktionieren müssen. Fällt eine weg, kippt das ganze Gebäude. Identität & Zugriff regelt, wer überhaupt mit Copilot reden darf. Daten & Information regelt, was Copilot dabei finden und ausliefern darf. Nutzung & Kontrolle regelt, was im Betrieb tatsächlich passiert und wie auffällige Muster erkannt werden.

Abbildung 1: Identität, Daten und Nutzung – drei Schichten, ohne die kein Copilot-Rollout sauber wird.

Säule 1: Identität & Zugriff

Auf dieser Ebene gehört das gesamte Identity-Werkzeug von Entra ID zum Pflichtprogramm. Conditional Access Policies, die explizit auf den Copilot-Service-Principal abzielen. Multifaktor-Authentifizierung als Standardvoraussetzung, nicht als Empfehlung. Risk-based Sign-in, das verdächtige Muster blockiert, bevor sie produktiv werden. Privileged Identity Management für administrative Rollen, weil ein Globaler Administrator mit Copilot-Lizenz ein eigenes Risikoprofil ist. Und ein wachsames Auge auf Gastzugriffe, denn jeder externe Gast bringt seine eigene Berechtigungsspur mit.

Säule 2: Daten & Information

Hier liegt das größte Brachland. SharePoint-Berechtigungen müssen aufgeräumt werden, bevor Copilot lossuchen darf. Sensitivity Labels müssen flächendeckend ausgerollt sein, idealerweise mit Auto-Labeling über Trainable Classifiers oder Sensitive Information Types. Restricted SharePoint Search ist das vielleicht wichtigste Notfall-Werkzeug der letzten Jahre: Es schränkt Copilot temporär auf eine Allowlist freigegebener Sites ein, während das Aufräumen läuft. Data Loss Prevention muss aktiv sein, anonyme Links gehören abgeschaltet, ein Lifecycle-Management muss alte Inhalte aus dem Index nehmen.

Säule 3: Nutzung & Kontrolle

Auf dieser Ebene geht es um den laufenden Betrieb. Audit Logs müssen aktiv und retentioniert sein. Eine eDiscovery-Strategie muss vor dem ersten ernsthaften Vorfall stehen, nicht danach. Plugins, Connectoren und Copilot-Studio-Agents brauchen eine Allowlist-Logik. Adoption-Monitoring zeigt, wer Copilot wie nutzt und wo sich Lizenzen lohnen oder eben nicht. Schulung mit Schwerpunkt Prompt-Hygiene reduziert die Fälle, in denen Mitarbeiter ungewollt vertrauliche Informationen anfragen. Die Betriebsvereinbarung schließlich ist kein Selbstzweck, sondern juristisches Schutzschild.

Wie eine Copilot-Antwort tatsächlich entsteht

Wer verstehen will, wo die Risiken sitzen, muss den Datenfluss kennen. Eine Copilot-Anfrage durchläuft sieben Stationen, und an jeder einzelnen kann etwas schiefgehen, wenn die Tenant-Konfiguration nicht stimmt.

Abbildung 2: Sieben Stationen – Prompt, Identität, Graph-Query, Permissions, Labels, LLM, Antwort & Audit.

Schritt eins ist der Prompt selbst. Schritt zwei prüft die Identität gegen Entra ID samt Conditional Access. Schritt drei stößt eine Suche über den Microsoft Graph an, also über Mails, Dateien, Chats, Kalender, Teams-Nachrichten und alles andere, was im Tenant indexiert ist. Schritt vier filtert das Ergebnis nach den Berechtigungen des Users – Copilot zeigt grundsätzlich nur das, was der User auch sonst sehen dürfte. Schritt fünf wendet Sensitivity Labels und DLP an. Schritt sechs schickt das Material an das Sprachmodell – innerhalb der EU Data Boundary, ohne Training auf Kundendaten, ohne dauerhafte Speicherung des Prompts. Schritt sieben liefert die Antwort zurück, schreibt einen Audit-Log-Eintrag, hängt Quellenverweise an und vererbt das höchste gefundene Label auf die Antwort.

Drei Stellen sind besonders kritisch. Die Berechtigungsprüfung in Schritt vier ist nur so gut wie das Berechtigungsmodell des Tenants – Garbage in, Garbage out. Die Label-Prüfung in Schritt fünf ist nur so wirksam wie die Label-Abdeckung im Tenant. Und die Audit-Spur in Schritt sieben ist nur dann etwas wert, wenn sie auch tatsächlich ausgewertet wird, statt nur 90 Tage in einem Microsoft-Datacenter herumzuliegen.

Sensitivity Labels: Das Schweizer Taschenmesser

Wenn es ein einzelnes Werkzeug gibt, das in der Copilot-Welt überdurchschnittlich viel bewirkt, dann sind es Sensitivity Labels aus Microsoft Purview. Ein gut gesetztes Label wirkt auf mehreren Ebenen gleichzeitig. Es kann den Zugriff auf das Dokument einschränken, es kann eine Verschlüsselung erzwingen, es kann Wasserzeichen aufbringen, es kann DLP-Regeln triggern – und es vererbt sich auf alles, was Copilot daraus generiert. Wer ein Word-Dokument mit Label „Vertraulich – Geschäftsleitung“ als Quelle nutzt, bekommt eine Copilot-Antwort, die automatisch dasselbe Label erbt.

Die Krönung ist die Label-Eigenschaft „Block Copilot from processing“. Damit lassen sich besonders heikle Inhalte vollständig aus dem Copilot-Index ausnehmen, unabhängig von der Berechtigungslage. Ideal für Personalakten, M&A-Dokumente, Strafverfahrens-Unterlagen und ähnliche Klassen, wo selbst eine theoretische Findbarkeit zum Problem werden kann.

Eine schlanke, durchdachte Label-Taxonomie schlägt jede aufgeblähte Struktur. Drei bis fünf Hauptlabel mit jeweils zwei bis drei Sublabeln reichen in den meisten Organisationen vollkommen aus. Wichtiger als die Anzahl ist die Auto-Labeling-Strategie: Sensitive Information Types und Trainable Classifiers, die im Hintergrund arbeiten und für Abdeckung sorgen, ohne dass jeder User alles manuell labeln muss.

Das Reifegradmodell: Wo steht dein Tenant wirklich?

Im PowerPoint sind alle Tenants auf Stufe vier oder fünf. In der Realität sieht das anders aus. Das folgende Reifegradmodell hat sich aus zahlreichen Bestandsaufnahmen herausdestilliert und bietet eine ehrliche Selbsteinschätzung.

Abbildung 3: Fünf Stufen vom Wild West zum adaptiven Betrieb – ein realistischer Maßstab.

Stufe eins ist Wild West. Lizenzen werden nach Bauchgefühl verteilt, ein Pre-Flight hat nicht stattgefunden, im Zweifel darf jeder alles. Stufe zwei ist Aufgewacht. Die ersten Vorfälle sind passiert, ein Oversharing-Audit läuft, Conditional Access Policies werden nachgezogen, aufgeräumt wird ad hoc. Stufe drei ist Strukturiert. Eine Label-Taxonomie steht, Restricted SharePoint Search ist aktiv, DLP greift, eine Audit-Strategie ist beschlossen, ein Schulungskonzept rollt aus, eine Agent-Governance ist etabliert.

Stufe vier ist Gehärtet. Zero-Trust-Prinzipien sind durchgesetzt, Auto-Labeling deckt den Großteil des Bestands ab, Insider Risk Management läuft, eDiscovery wurde mindestens einmal scharf geübt, eine Betriebsvereinbarung ist unterschrieben, KPI-Reporting steht. Stufe fünf ist Adaptiv. Kontinuierliches Monitoring, adaptive Policies, eigene Agents im produktiven Einsatz, ROI-Messung pro Lizenz, ein KI-Governance-Board, EU-AI-Act-Konformität. Das ist der Zustand, den seriöse Großorganisationen 2027 erreichen sollten.

Erfahrungswert: Mehr als die Hälfte aller Tenants steht zum Zeitpunkt des Copilot-Rollouts auf Stufe eins oder zwei. Der Sprung auf Stufe drei ist die Stelle, an der professionelle Beratung den größten Hebel hat.

Compliance: DSGVO, EU AI Act und der Betriebsrat

Die rechtliche Seite wird gerne unterschätzt, weil Microsoft viele Hausaufgaben bereits gemacht hat. Der Auftragsverarbeitungsvertrag ist Bestandteil des Microsoft Online Service Terms, die EU Data Boundary deckt die wesentlichen Verarbeitungen ab, eine ISO-27001- und SOC-2-Zertifizierung liegt vor. Das entbindet aber nicht von den eigenen Hausaufgaben.

Der EU AI Act stuft Microsoft Copilot in seiner Standardausprägung als System mit begrenztem Risiko ein. Das bedeutet primär Transparenzpflichten gegenüber den Nutzern – diese müssen wissen, dass sie mit einem KI-System interagieren und dass dessen Antworten Fehler enthalten können. Sobald ein Unternehmen aber eigene Copilot-Studio-Agents baut, die Entscheidungen mit Personenbezug vorbereiten, kann sich die Risikoklasse ändern. Eine eigene KI-Risikoklassifizierung der gebauten Agents ist deshalb Pflicht.

Die Mitbestimmung des Betriebsrats nach Paragraf 87 BetrVG ist ein häufig unterschätzter Stolperstein. Copilot ist eine technische Einrichtung, die geeignet ist, Verhalten und Leistung der Beschäftigten zu überwachen. Damit ist sie mitbestimmungspflichtig. Eine Betriebsvereinbarung sollte vor dem Produktivstart stehen, nicht erst bei der ersten beanstandeten Auswertung. Inhaltlich gehören Zweckbindung, Auswertungsverbote, Aufbewahrungsfristen für Audit Logs und ein Eskalationsprozess für Auffälligkeiten in den Vertrag.

Ergänzend zur Betriebsvereinbarung empfiehlt sich eine schriftlich fixierte Acceptable-Use-Policy für Endanwender. Sie regelt im Klartext, welche Inhalte nicht in Copilot gehören – Klassiker sind Gehaltsdaten, laufende Personalmaßnahmen, Mandantengeheimnisse und alles, was unter besondere Verschwiegenheitspflichten fällt.

Die Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO ist je nach Einsatzszenario verpflichtend. Werden mit Copilot personenbezogene Daten in größerem Umfang verarbeitet – Mails, Kalender und Teams-Chats fallen praktisch immer darunter – ist eine DSFA durchzuführen und zu dokumentieren. Microsoft stellt für die Standardszenarien Vorlagen und Material zur Verfügung, die Bewertung der konkreten Tenant-Situation muss aber jede Organisation selbst leisten. Wer eigene Agents baut, kommt an einer eigenständigen DSFA pro Agent kaum vorbei.

Drei Stolperfallen, die fast jeder mitnimmt

Auch in vorbildlich aufgesetzten Tenants gibt es drei Klassen von Problemen, die mit auffälliger Regelmäßigkeit auftreten und deshalb hier eine eigene Erwähnung verdienen.

Erstens: Mailboxen sind heimliche Goldgruben. Eine moderne Postfachgröße liegt bei mehreren Gigabyte, gefüllt mit Dingen, die der Besitzer längst vergessen hat. Copilot findet das alles. Eine harmlose Frage wie „Fass mir mal die Personalentwicklung der letzten beiden Jahre zusammen“ kann beim CEO eine Antwort produzieren, die auf Mails der Personalleiterin zugreift, die er nie hätte sehen sollen – aber technisch durfte. Mailboxen gehören in den Pre-Flight ebenso wie SharePoint.

Zweitens: Geteilte Postfächer und Funktionsmailboxen sind ein Sonderfall. Wer Vollzugriff auf ein Shared Mailbox hat, sieht über Copilot alles, was dort jemals reingelaufen ist. Das wird gerne vergessen, weil shared mailboxes traditionell als technisch betrachtet werden, nicht als Datenquelle.

Drittens: Loop-Komponenten und Whiteboards bilden eine eigene, oft übersehene Datenklasse. Sie sind in OneDrive gespeichert, lassen sich aber kaum mit klassischen Permission-Reports erfassen. Copilot greift darauf zu, ein klassisches Berechtigungs-Audit dagegen meistens nicht. Hier hilft nur eine bewusste Strategie zur Loop-Governance, idealerweise schon vor dem Copilot-Rollout.

Der Viersprung für Copilot: Beratung, Buch, Software, Schulung

Diese Webseite ist eine Säule eines kombinierten Angebots, das genau auf die hier beschriebenen Themen zugeschnitten ist. Die Beratung deckt den klassischen Pre-Flight-Check, die Erarbeitung der Label-Taxonomie, die Begleitung des Rollouts und die Etablierung der Governance-Strukturen ab. Sie endet nicht mit einem PowerPoint, sondern mit einem konkreten Aktionsplan im neunteiligen Consulting-Format.

Das Buchprojekt zur Microsoft-Copilot-Reihe ist auf zwei Bände angelegt. Der erste Band richtet sich an Entscheider und liefert die Grundlagen, die Strategie und das wirtschaftliche Bild. Der zweite Band richtet sich an IT-Profis und behandelt im Detail die Sicherheits-, Compliance- und Governance-Themen, die in diesem Pillar nur angerissen werden.

Auf der Software-Seite entsteht der Copilot Readiness Diagnostiker, ein Werkzeug zur strukturierten Bestandsaufnahme: Oversharing-Scan, Label-Coverage, Restricted-Search-Konfiguration, Plugin- und Agent-Inventar, Lizenz-Mapping. Das Ergebnis ist ein Bericht, der direkt als Beratungsdokument im neunteiligen Format vorliegt – und der das Tool zugleich zum Pre-Flight-Begleiter beim Kunden macht.

Die Schulungsformate runden das Angebot ab. Sie reichen vom Halbtagsworkshop für Entscheider über die mehrtägige Admin-Schulung bis zum Endanwender-Training mit Schwerpunkt Prompt-Hygiene. Vier Bausteine, die einzeln gut funktionieren und gemeinsam einen vollständigen, ehrlichen Copilot-Rollout abbilden – ohne PowerPoint-Romantik, mit klarem Blick auf das, was im Tenant tatsächlich passiert.