Wie Copilot auf Ihre Daten zugreift — und warum das Ihre Berechtigungsstruktur betrifft

 

📋 MANAGEMENT SUMMARY — Was Sie in 5 Minuten wissen müssen

Copilot greift auf Ihre Unternehmensdaten zu — genau auf die Daten, die der jeweilige Mitarbeiter sehen darf. Das klingt zunächst beruhigend. Es ist es nicht, sobald man die Berechtigungsstruktur eines typischen gewachsenen Microsoft-365-Tenants betrachtet. In den meisten Organisationen haben Mitarbeiter Zugriff auf weit mehr Daten als für ihre Rolle tatsächlich notwendig ist. SharePoint-Bibliotheken wurden vor Jahren mit der Gruppe „Jeder außer externe Benutzer“ geteilt — damals bequem, heute ein Risikofaktor. Niemand hat diese Einstellung je wieder angefasst, weil alles irgendwie funktioniert hat. Bis jetzt. Microsoft Graph ist die technische Schnittstelle, über die Copilot auf Exchange-Mails, SharePoint-Dokumente, Teams-Chats, Kalendereinträge und Kontakte zugreift. Der Semantic Index dahinter indexiert nicht nur nach Schlagwörtern, sondern nach Bedeutung — und findet dadurch Dokumente, die vorher im Rauschen untergingen: Gehaltslisten, Personaldossiers, Strategiepapiere. Die EU Data Boundary ist eine wichtige Zusicherung von Microsoft: Enterprise-Kundendaten werden in europäischen Rechenzentren verarbeitet, ohne die EU-Region zu verlassen. Das löst jedoch nicht das Oversharing-Problem — und ist kein Ersatz für einen ordnungsgemäßen Auftragsverarbeitungsvertrag. Die Hausaufgaben vor der Copilot-Aktivierung sind klar definiert: Berechtigungen bereinigen, Everyone-Gruppen aufflösen, Sensitivity Labels einführen, DSB einbinden, MFA erzwingen. Dieses Kapitel zeigt, wie das geht — und was passiert, wenn man es lässt.

 

3.1 Microsoft Graph — das Nervensystem Ihres Tenants

Bevor Sie verstehen können, was Copilot mit Ihren Daten tut, müssen Sie verstehen, wie Microsoft Graph funktioniert. Graph ist nicht irgendeine Schnittstelle zwischen Produkten — es ist die zentrale Kommunikationsschicht des gesamten Microsoft-365-Universums. Jede E-Mail, jedes Dokument, jeder Teams-Chat, jeder Kalendereintrag, jede Berechtigungsstruktur — alles läuft durch Microsoft Graph.

Technisch ist Microsoft Graph eine REST-API mit einem einheitlichen Endpunkt für alle M365-Dienste: graph.microsoft.com. Das ist eine designerische Entscheidung, die 2015 eingehend diskutiert wurde und seither den Microsoft-Entwickler-Alltag prägt. Statt für Exchange eigene Web Services anzusprechen, für SharePoint die CSOM-API, für Teams wieder eine eigene Schnittstelle — gibt es einen einzigen Zugangspunkt für alles. Das ist elegant, für Entwickler effizient, und aus Governance-Perspektive ein zweischneidiges Schwert.

Warum zweischneidig? Weil Graph als einheitlicher Zugangspunkt auch bedeutet, dass jede Anwendung, die Graph-Zugriff hat, potenziell auf alle Dienste gleichzeitig zugreifen kann — sofern die Berechtigungen es erlauben. Copilot ist eine solche Anwendung. Und Copilot hat Zugriff auf den Graph mit den Berechtigungen des jeweils angemeldeten Nutzers.

Das ist der Kern des Ganzen, deshalb sei er noch einmal klar formuliert: Copilot erbt die Berechtigungen des anfragenden Nutzers. Kein mehr, kein weniger. Copilot kann keine höheren Rechte erlangen. Es gibt keinen versteckten Administrator-Modus, keine Backdoor, keine geheime Superkraft. Was Copilot sieht, ist genau das, was der Nutzer sehen darf. Der Satz klingt zunächst beruhigend. Aber lesen Sie weiter.

Abb. 3.1 — Tenant-Architektur: Datenpfade von der Benutzeranfrage bis zur Azure-OpenAI-Verarbeitung

Der Semantic Index: mehr als eine Suche

Was macht Copilot technisch anders als die SharePoint-Suche, die Sie schon länger kennen und die so mittelalterlich funktioniert, dass viele Mitarbeiter lieber alles im Explorer organisieren? Die Antwort liegt im Semantic Index.

Der Semantic Index ist kein Volltextindex. Er repräsentiert Inhalte als hochdimensionale Vektoren — mathematische Darstellungen der semantischen Bedeutung eines Dokuments oder einer Konversation. Wenn Sie in einem Dokument über „Auftragsabwicklung“ schreiben, aber nie das Wort „Prozess“ verwenden, kann der Semantic Index trotzdem erkennen, dass dieses Dokument prozessrelevant ist — weil die semantische Nähe zwischen den Konzepten repräsentiert ist.

Das bedeutet in der Praxis: Wenn ein Mitarbeiter Copilot fragt „Was sind die aktuellen Konditionen für unsere Großkunden?“, findet Copilot nicht nur Dokumente, die das Wort „Konditionen“ enthalten, sondern alle Dokumente, die semantisch mit Preisgestaltung, Rabatten, Rahmenverträgen und Großkunden zu tun haben — auch wenn diese Begriffe in verschiedenen Dokumenten verteilt sind.

Das ist leistungsfähig. Das ist der Grund, warum Copilot Dinge findet, die die SharePoint-Suche niemals gefunden hätte. Und das ist genau der Grund, warum Berechtigungen, die vorher „theoretically wrong aber practically invisible“ waren, mit Copilot plötzlich praktisch relevant werden.

Dienst	Datentyp	Sensitivität	Was Copilot konkret liest
Exchange Online	E-Mails, Kalender, Kontakte	Sehr hoch	Mails zusammenfassen, Termine vorbereiten, Kontexte herstellen
SharePoint Online	Dokumente, Listen, Sites, Bibliotheken	Hoch (Oversharing!)	Volltextsuche, Inhaltsextraktion, Zusammenfassungen
Microsoft Teams	Chats, Kanäle, Meetings, Transkripte	Hoch	Chat-Zusammenfassungen, Meeting-Protokolle, Action Items
OneDrive for Business	Persönliche Dateien, Freigaben	Mittel bis hoch	Lesen, Zusammenfassen, Referenzieren eigener Inhalte
Outlook-Kalender	Termine, Einladungen, Raumbuchungen	Mittel	Terminvorschläge, Meeting-Vorbereitung, Conflicts erkennen
Microsoft Planner / To Do	Aufgaben, Projekte, Fristen	Mittel	Aufgabenübersicht, Status-Abfragen, Fristenhinweise
Azure AD / Microsoft Entra	Identitäten, Gruppen, Berechtigungen	Sehr hoch	Interne Berechtigungsprüfung (nicht lesbar für Nutzer)
Kontakte (People API)	Personen, Org-Hierarchie, Expertise	Mittel	Personensuche, Org-Kontext, Expertise-Matching

Tabelle 3.1 — Microsoft Graph: Dienste, Datentypen, Sensitivität und Copilot-Nutzung

Abb. 3.2 — Microsoft Graph als Hub: Copilot verbindet alle M365-Dienste gleichzeitig

Der Copilot-Verarbeitungsprozess Schritt für Schritt

Ein häufiges Missverständnis: Copilot lädt nicht alle Daten herunter und durchsucht sie lokal. Die Verarbeitung ist ein mehrstufiger Prozess, der in Sekunden abläuft und verschiedene Sicherheitsprüfungen durchläuft.

Abb. 3.3 — Copilot-Anfrage Schritt für Schritt: Authentifizierung, Graph-Abfrage, Datenfilterung und LLM-Verarbeitung

Schritt 1 ist die Nutzereingabe im Copilot-Interface — in Outlook, Teams, Word oder dem dedizierten Copilot-Chat. Schritt 2 ist die Authentifizierung über Microsoft Entra ID (früher Azure AD). Dieser Schritt ist kritisch: Ein kompromittiertes Konto gibt einem Angreifer vollen Copilot-Zugriff auf alle Daten des Kontoinhabers. Multi-Faktor-Authentifizierung ist deshalb keine optionale Sicherheitsmaßnahme, sondern eine Grundvoraussetzung für den Copilot-Betrieb.

Schritt 3 ist der Semantic Index: Copilot analysiert die Anfrage semantisch und identifiziert relevante Datenquellen und Dokumente im Tenant. Schritt 4 ist die Graph-API-Abfrage mit simultaner Berechtigungsprüfung — hier entscheidet sich, welche Inhalte tatsächlich zur Verarbeitung weitergegeben werden. Nur Dokumente, auf die der Nutzer explizit berechtigt ist, werden in diesem Schritt selektiert.

Schritt 5 filtert die Ergebnisse auf autorisierte Inhalte. Dieser Filter ist keine nachträgliche Sicherheitsschicht — er ist in den Graph-Aufruf integriert. Schritt 6 übergibt die gefilterten Daten an Azure OpenAI zur LLM-Verarbeitung innerhalb der EU Data Boundary. Schritt 7 liefert die strukturierte Antwort zurück an den Nutzer.

ℹ️ TECHNISCHER HINTERGRUND — Was der Semantic Index wirklich ist

Der Semantic Index ist eine vektorbasierte Repräsentation aller Inhalte, auf die ein Nutzer Zugriff hat. Jedes Dokument, jede E-Mail, jeder Chat wird — vereinfacht gesagt — in einen hochdimensionalen Zahlenvektor umgewandelt, der seine semantische Bedeutung repräsentiert. Diese Vektoren werden nicht im Dokument gespeichert, sondern in einem separaten Index, der für jeden Nutzer individuell angelegt wird. Das heißt: Nutzer A und Nutzer B haben unterschiedliche Semantic Indexes — abhängig davon, auf welche Inhalte sie jeweils Zugriff haben. Kein Cross-Contamination. Der Semantic Index wird kontinuierlich aktualisiert. Wenn ein neues Dokument in SharePoint veröffentlicht wird, wenn eine neue E-Mail eintrifft, wenn ein Teams-Chat stattfindet — all das fließt zeitnah in den Index ein. Copilot sucht also immer in einem aktuellen Bild Ihrer Daten, nicht in einem Snapshot von gestern. Die Konsequenz: Wenn Sie heute die Berechtigung für einen SharePoint-Ordner ändern, spiegelt sich das zeitnah im Semantic Index wider. Copilot findet morgen nichts mehr aus diesem Ordner für diesen Nutzer. Das ist die gute Nachricht. Die schlechte: Bis zur Änderung war der Zugriff offen.

 

3.2 Was Copilot tatsächlich sieht — und was nicht

„Copilot sieht alles, was der Nutzer sehen darf“ — dieser Satz ist technisch korrekt und trotzdem unvollständig. Um zu verstehen, was das bedeutet, müssen Sie zwei Dinge gleichzeitig im Blick haben: Was sind die Grenzen des Copilot-Zugriffs? Und was sind die Grenzen des Nutzer-Zugriffs in Ihrem Tenant?

Die Grenzen des Copilot-Zugriffs sind klar: Copilot kann keine höheren Rechte erlangen als der Nutzer selbst hat. Es gibt keine versteckte Administrator-Ebene. Copilot greift nicht auf andere Benutzerkonten zu (außer bei expliziter Stellvertretungsberechtigung). Copilot liest keine Dokumente, auf die der Nutzer keine Zugriffsrechte hat. Diese Grenzen sind technisch implementiert und im Verhalten konsistent.

Die Grenzen des Nutzer-Zugriffs in einem typischen Tenant sind dagegen oft vage. Und hier liegt das Problem: „Was der Nutzer sehen darf“ ist in vielen Organisationen nicht „nwas für seine Rolle relevant ist“, sondern „was niemand je explizit eingeschränkt hat“. Das ist ein grundlegend anderer Satz. Und Copilot arbeitet mit dem, was vorhanden ist.

Das Effective-Permissions-Prinzip: Ein Praxisbeispiel

Stellen Sie sich vor: Julia Koch ist Sachbearbeiterin im Vertrieb bei der Musterwerk GmbH. Sie nutzt Copilot in Microsoft Teams. Sie fragt: „Können Sie mir die wichtigsten Infos über unsere Lieferanten zusammenfassen?“

Was Copilot für Julia tut: Es durchsucht alle Dokumente, E-Mails und Teams-Nachrichten, auf die Julia zugreifen kann, semantisch nach lieferantenrelevanten Inhalten. Findet es Angebote, Lieferantenverträge, Preislisten? Ja — wenn Julia darauf Zugriff hat. Ist das korrekt? Das hängt davon ab, was Julia wirklich sehen soll.

In einem gut strukturierten Tenant: Julia sieht die Lieferanteninformationen, die für ihre Vertriebsrolle relevant sind. Einkaufskonditionen aus verhandelten Rahmenverträgen, die den Einkauf betreffen, sieht sie nicht — weil sie keinen Zugriff auf die entsprechenden SharePoint-Bibliotheken hat.

In einem typischen Tenant mit gewachsenen Berechtigungen: Julia sieht auch die Einkaufskonditionen, weil die SharePoint-Bibliothek des Einkaufs irgendwann mit „Jeder außer externe Benutzer“ geteilt wurde. Und die internen Kostenkalkulationen. Und die Lieferantenbewertungen aus dem letzten Audit. Weil Copilot semantisch sucht und all das inhaltlich zu „Lieferanteninformationen“ passt.

Datenkategorie	Im gut konf. Tenant	Im typischen Tenant	DSGVO-Relevanz
E-Mails des Nutzers	Ja, immer	Ja, immer	Nutzer hat Kenntnis
SharePoint (berechtigte Sites)	Ja	Ja	Berechtigung dokumentiert
SharePoint (Everyone-Sites)	Nicht vorhanden	Ja — Oversharing-Risiko	Potenziell DSGVO-relevant
Teams-Kanäle (Mitglied)	Ja	Ja	Kanalzugehörigkeit geprüft
Teams-Kanäle (kein Mitglied)	Nein	Nein	Zugriff korrekt gesperrt
Postfächer anderer Nutzer	Nein	Nein (außer Stellvertretung)	Korrekte Abgrenzung
OneDrive anderer Nutzer	Nein	Nein	Korrekte Abgrenzung
Verschlüsselte Dokumente (IRM)	Nein (kein Entschlüsseln)	Nein	Korrekte Abgrenzung
Externe Daten (außer M365)	Nein	Nein	Kein Graph-Zugriff

Tabelle 3.2 — Was Copilot sieht und was nicht — Vergleich gut konfigurierter vs. typischer Tenant

Sensitivity Labels: der zweite Kontrollmechanismus

Neben dem Berechtigungssystem gibt es einen zweiten Mechanismus, der Copilot-Zugriff steuert: Sensitivity Labels aus Microsoft Purview. Labels klassifizieren Dokumente nach Vertraulichkeit und können Copilot anweisen, bestimmte Inhalte nicht in Antworten zu verwenden.

Ein Dokument mit dem Label „Streng vertraulich“ kann so konfiguriert sein, dass Copilot es zwar findet (wenn der Nutzer Lesezugriff hat), aber seinen Inhalt nicht in Zusammenfassungen oder Antworten verwendet. Das ist eine zusätzliche Schutzschicht — aber nur, wenn Labels korrekt konfiguriert und konsequent angewendet wurden.

Das Problem: In den meisten Organisationen gibt es entweder keine Sensitivity Labels oder sie wurden halb konfiguriert und werden inkonsistent angewendet. Etwa 45 Prozent aller Dokumente in einem typischen Tenant haben kein Label — oder das Default-Label „Intern“, das kaum Einschränkungen bewirkt.

 

3.3 Das Oversharing-Problem — wenn Copilot zu viel weiß

Oversharing ist das konkreteste Risiko bei der Copilot-Einführung. Der Begriff bezeichnet Dokumente und Daten mit zu weit gefassten Berechtigungen: Inhalte, die mehr Personen zugänglich sind als ursprünglich beabsichtigt oder für die jeweilige Rolle sinnvoll.

Oversharing ist kein neues Problem — es existiert in nahezu jedem Microsoft-365-Tenant, der älter als zwei Jahre ist. Bisher war es ein theoretisches Risiko: Mitarbeiter hätten aktiv nach Dokumenten suchen müssen, um auf Informationen zu stoßen, die über ihre Rolle hinausgehen. Das erforderte Initiative, Neugier und in gewissem Sinne auch bösen Willen. Die meisten Mitarbeiter haben das nie getan.

Copilot ändert diese Gleichung fundamental. Copilot sucht aktiv — nicht aus bösem Willen, sondern weil es seinen Job macht. Es sucht bei jeder Anfrage im gesamten berechtigten Datenbestand nach relevanten Inhalten und präsentiert das Ergebnis als freundlich formulierte Zusammenfassung. Das theoretische Risiko wird real.

⚠️ RISIKO — Copilot als ungewollter Informationsverteiler: das Oversharing-Szenario

Copilot hat keine eigene Ethikschicht, die entscheidet, ob eine Information für den anfragenden Nutzer “passend“ ist. Copilot prüft Berechtigungen — und wenn die Berechtigung besteht, liefert Copilot die Information. Das ist technisch korrekt und kann praktisch katastrophal sein. Das Kernproblem in einem Satz: Wenn ein Praktikant technisch Zugriff auf eine SharePoint-Bibliothek hat, in der Gehaltstabellen der Führungsebene liegen, und er fragt Copilot nach „Gehalt Teamleiter“ — dann erhält er die Antwort. Copilot macht keinen Fehler. Ihre Berechtigungsstruktur macht keinen Fehler. Es ist der Zustand, den Sie zulassen. Die Konsequenzen gehen weit über die Information selbst hinaus: ein Vertrauensverlust im Führungskreis, wenn Gehaltsstrukturen intern bekannt werden; eine potenzielle DSGVO-Verletzung, wenn Personaldaten unbeabsichtigt offengelegt werden; Betriebsrats-Implikationen; und im schlimmsten Fall eine meldepflichtige Datenpanne bei der zuständigen Aufsichtsbehörde. Das alles, weil ein SharePoint-Ordner seit 2019 eine zu große Berechtigungsgruppe hat.

 

Die folgende Karte zeigt die häufigsten Oversharing-Szenarien nach Wahrscheinlichkeit und Datensensitivität:

Abb. 3.4 — Oversharing-Risikomatrix: Wahrscheinlichkeit und Datensensitivität nach Szenario

Szenario	Wahrscheinlichkeit	Datensensitivität	Sofortmaßnahme
Gehaltstabellen in SharePoint für alle sichtbar	Sehr hoch	Kritisch	HR-Zugriffsgruppe erstellen, Berechtigungen sofort einschränken
Vorstandsprotokolle mit Everyone-Berechtigung	Mittel	Kritisch	Zugriff auf definierten Vorstandskreis beschränken
Personaldaten im allgemeinen Teams-Kanal	Hoch	Kritisch	Privaten Teams-Kanal für HR erstellen, Inhalte migrieren
Angebote und Preislisten für alle zugänglich	Sehr hoch	Hoch	Vertriebszugriff definieren, Bibliothek einschränken
IT-Passwörter und Zugangsdaten in Teams	Mittel	Sehr hoch	Sofort löschen, Passwort-Manager einführen
Strategiepapiere ohne Sensitivity Label	Sehr hoch	Hoch	Labels setzen, Zugriff auf Strategie-Gremium einschränken
Kundendaten in projektübergreifenden Ordnern	Hoch	Kritisch	DSFA prüfen, Zugriff auf Projektmitglieder einschränken
Personaldaten für externe oder Praktikanten erreichbar	Mittel	Kritisch	DSGVO-Meldepflicht prüfen, Zugriff sofort entziehen

Tabelle 3.3 — Oversharing-Szenarien: Häufigkeit, Sensitivität und Sofortmaßnahmen

Warum Oversharing so verbreitet ist

Die Ursachen von Oversharing sind fast immer dieselben. Zuerst: Bequemlichkeit bei der initialen Einrichtung. Als SharePoint vor fünf Jahren migriert wurde, waren Everyone-Gruppen die schnellste Lösung. Niemand hatte Zeit, eine durchdachte Gruppenstruktur aufzubauen. Das war verständlich — und ist heute ein Problem.

Zweite Ursache: fehlende Review-Prozesse. Berechtigungen werden gesetzt und nie wieder angefasst. Wenn jemand das Unternehmen verlässt, werden seine Gruppenmitgliedschaften selten systematisch bereinigt. In vielen Organisationen gibt es ehemalige Mitarbeiter-Accounts, die zwar deaktiviert sind, aber noch Gruppenmitgliedschaften haben — die dann auf reaktivierte Accounts angewendet werden können.

Dritte Ursache: Technische Schulden aus SharePoint-Migrationen. Bei einer Migration von SharePoint on-premises in die Cloud werden oft Berechtigungen 1:1 übernommen — inklusive aller problematischen Strukturen. Die Migration ist dann der richtige Moment für eine Bereinigung, aber auch der Moment mit dem größten Zeitdruck. Berechtigungen wandern unverändert mit.

Oversharing in der Praxis: Drei Szenarien

Die folgenden drei Szenarien sind keine Konstrukte aus dem Lehrbuch. Sie entsprechen Situationen, die in realen Microsoft-365-Tenants vorkommen — und die mit der Copilot-Einführung plötzlich praktische Konsequenzen haben.

● Szenario 1 — Das Projekt-Laufwerk. Ein Projektleiter legt vor drei Jahren eine SharePoint-Team-Site für das Projekt „Relaunch 2023“ an. Er gibt „Everyone“ Lesezugriff, damit Stakeholder die Dokumente einfach erreichen können. Das Projekt endet. Die Site bleibt bestehen, die Berechtigungen bleiben bestehen. Heute enthält die Site: Budgetpläne, eine Mitarbeiterliste mit Gehaltsinformationen (versehentlich dort abgelegt) sowie Protokolle mit Personalentscheidungen. Copilot hat Zugriff auf alles davon — und kann es jedem Nutzer mit entsprechender Anfrage zusammenfassen. Niemand hat die Site je als aktiv betrachtet. Sie ist es trotzdem.

● Szenario 2 — Die Vertriebsabteilung. Der Vertriebsleiter möchte, dass alle Vertriebsmitarbeiter Zugriff auf alle Kundendaten haben — „damit niemand geblockt wird“. Er setzt die SharePoint-Berechtigungen für den Kundenbereich auf die gesamte Vertriebsgruppe. Das umfasst 45 Personen, darunter Auszubildende und zwei externe Projektmitarbeiter auf Jahresbasis. Copilot kann für alle 45 Nutzer alle Kundendaten abrufen — einschließlich Konditionen, Rabattvereinbarungen und offener Beschwerden. Die Absicht des Vertriebsleiters war gut. Das Ergebnis ist ein DSGVO-Problem.

● Szenario 3 — Die Führungskräfte-Kommunikation. Die Geschäftsführung kommuniziert über Teams. Der IT-Administrator hat die Teams-Kanal-Einstellungen nie explizit eingeschränkt. Protokolle der Geschäftsführungssitzungen liegen in einem SharePoint-Ordner, der aus Versehen für alle Mitarbeiter lesbar ist. Niemand hat diesen Fehler bemerkt — weil die Protokolle nie aktiv gesucht wurden. Bis ein Mitarbeiter in der Kaffeeecke sagt: „Copilot, was hat die Geschäftsführung letzten Monat besprochen?“ — und eine präzise Zusammenfassung bekommt.

Szenario	Wie es entsteht	Wie Sie es erkennen
„Everyone“-Berechtigung	Schnell gesetzt, nie entfernt	Access Review: wer hat Zugriff auf was?
Projekt-Sites ohne Ablauf	Projekte enden, Sites bleiben	SharePoint-Audit: inaktive Sites mit breitem Zugriff
Externe in internen Gruppen	Gastzugang nie widerrufen	Entra ID: Gast-Accounts älter als 90 Tage
Fehlgeleitete Ablage	Falsche Bibliothek, falsche Berechtigungen	DLP-Scan: sensible Inhalte an falschen Orten

Tab. 3.4a — Oversharing-Szenarien: Wie sie entstehen und wie Sie sie erkennen

 

💡 TIPP — SharePoint-Berechtigungs-Check: Oversharing in 2 Stunden identifizieren

Sie brauchen keine teuren Drittanbieter-Tools für eine erste Einschätzung. Microsoft liefert die Werkzeuge: SharePoint Admin Center → Sites → Active Sites: Spalte „External sharing“ einblenden. Alle Sites mit „Anyone“ oder „New and existing guests“ priorisieren. Purview Compliance Portal → Content Explorer: Zeigt alle Dokumente mit sensiblen Inhalten und wo sie liegen. PowerShell (Graph API): Get-MgSitePermission für alle Sites. Ein simples Skript, das alle Sites mit Everyone-Gruppen listet. SharePoint Advanced Management (SAM): Falls lizenziert, liefert der Data Access Governance Report eine vollständige Oversharing-Analyse. Zeitplan: 2 Stunden für den Report, 2–8 Wochen für die Bereinigung je nach Tenant-Größe. Priorisierung: zuerst HR-Daten und Finanzinformationen, dann Managementdokumente, dann allgemeine Bibliotheken.

 

🏢 FALLSTUDIE — Musterwerk GmbH: Die Gehaltstabelle und die Werkstudentin

Es war ein Dienstag Mitte Oktober. Thomas Berger, IT-Leiter der Musterwerk GmbH in Dortmund, hatte den Copilot-Piloten gerade zwei Wochen laufen — 25 Mitarbeiter aus verschiedenen Abteilungen, durchweg positive Rückmeldungen. Copilot spare Zeit, die Dokumentensuche sei endlich brauchbar, Meeting-Zusammenfassungen seien ein echter Mehrwert. Berger war kurz davor, den Rollout auf 100 Nutzer auszuweiten. Dann rief Melanie Hoffmann an. Melanie war Werkstudentin in der Logistik, seit August dabei. Technisch kompetent, neugierig. Sie hatte Copilot intensiv genutzt und in einem Teams-Chat mit ihrer Kommilitonin erwähnt, dass der IT-Leiter 96.000 Euro im Jahr verdiene, der Vertriebsleiter 112.000 und der Produktionsleiter 89.000. Copilot habe das aus einem Dokument „Salary_Grid_2024.xlsx“ zusammengefasst. Thomas Berger fand das Dokument in 30 Sekunden: eine SharePoint-Bibliothek, die vor der letzten Migration für das HR-Team erstellt worden war, aber mit der Gruppe „Jeder außer externe Benutzer“ geteilt war. Seit der Migration 2021. Drei Jahre lang war das kein Problem — weil niemand danach gesucht hatte. Copilot suchte. Was folgte: 48 Stunden Pilotpause, vollständiger Berechtigungs-Audit, Erstellung eines Bereinigungsplans für 34 Sites mit überbreiten Berechtigungen, eine intensive Unterhaltung mit dem Betriebsrat, eine Einschätzung des DSB zur DSGVO-Meldepflicht, und ein sehr unkomfortables Gespräch im Führungskreis. Was Thomas Berger danach tat: Er nutzte den Vorfall als Argument für das Budget für SharePoint Advanced Management und eine externe Berechtigungsberatung. Vier Wochen später war der Pilot wieder aktiv — auf einem deutlich besser konfigurierten Tenant. Melanie durfte Copilot weiternutzen. Die Gehaltstabelle liegt jetzt in einer Site, auf die nur HR-Mitglieder Zugriff haben. Die Moral der Geschichte ist nicht, dass Copilot gefährlich ist. Die Moral ist, dass eine vierjahre alte, unreviewte Berechtigungsstruktur gefährlich ist — und dass Copilot das demonstriert hat. Auf eine Art, die lehrreich, aber unangenehm war.

 

3.4 Was Microsoft mit Ihren Daten macht — Fakten statt Gerüchte

Kaum ein Thema bei der Copilot-Einführung sorgt für mehr Missverständnisse als die Frage, was Microsoft mit den Unternehmensdaten tut, die Copilot verarbeitet. Es gibt zwei Extreme: die Fraktion, die Microsoft völlig vertraut und das Thema als irrelevant abtut, und die Fraktion, die überzeugt ist, Microsoft lese alle E-Mails mit. Die Wahrheit liegt näher an der ersten Version — aber mit einigen wichtigen Nuancen.

Trainiert Microsoft KI-Modelle mit Ihren Unternehmensdaten?

Nein — für Enterprise-Kunden mit entsprechenden Lizenzen (M365 E3/E5, Copilot für Microsoft 365). Microsoft hat das vertraglich zugesichert und in den Online Service Terms explizit ausgeschlossen: Kundendaten aus Enterprise-Tenants werden nicht zum Training von Basis-KI-Modellen verwendet. Das gilt für Copilot-Interaktionen, Dokumenteninhalte, E-Mails und alle anderen Inhalte, die Copilot verarbeitet.

Diese Zusicherung gilt nicht für Consumer-Dienste ohne Enterprise-Anmeldung — also Copilot.microsoft.com ohne Unternehmens-Account, Bing Chat in der kostenlosen Version oder ähnliche Angebote. Wer seinen Mitarbeitern erlaubt, Unternehmensdaten in kostenlose KI-Dienste einzugeben, hat ein eigenständiges Problem, das unabhängig von Microsoft-Copilot gelöst werden muss.

Was wird protokolliert?

Copilot-Aktivitäten werden im Microsoft Purview Audit Log als Ereignisse erfasst. Protokolliert werden: Zeitstempel der Anfrage, Identität des Nutzers, welche Dateien als Quellen referenziert wurden (nur Metadaten, nicht der Inhalt), und ob eine Antwort generiert wurde. Diese Protokollierung ist für Security- und Compliance-Zwecke vorgesehen und standardmäßig 90 Tage aufbewahrt. Mit dem M365 E5 Compliance Add-on ist eine Verlängerung auf bis zu einem Jahr möglich.

Was nicht protokolliert wird: der vollständige Inhalt der Dokumente, die Copilot gelesen hat. Das Audit Log zeigt, dass Copilot auf „Budget_2025_final.xlsx“ zugegriffen hat — aber nicht, welche konkreten Zahlen aus der Datei in die Antwort eingeflossen sind. Das ist eine wichtige Grenze für Forensik-Szenarien, aber auch eine Einschränkung für vollständige Transparenz.

Datenkategorie	Speicherort	Aufbewahrung	Microsoft-Zugriff
Copilot-Anfragen (Enterprise)	Tenant-Bereich, Azure EU	Nutzer-kontrollierbar	Vertraglich ausgeschlossen
Dokumenteninhalte (verarbeitet)	Im Tenant verbleibend	Nach Aufbewahrungsrichtlinie	Kein Zugriff
Audit Logs (Aktivitäten)	Purview, EU-Region	90 Tage Standard, bis 1 Jahr	Nur bei Support-Ticket mit Zustimmung
Telemetrie und Diagnose	Microsoft global	30 Tage	Ja, anonymisiert für Betriebsdiagnose
Modelltraining	Nicht anwendbar	Entfällt	Enterprise-Daten nicht verwendet
Copilot-Interaktionsverlauf	Tenant-Bereich	Nutzer-kontrollierbar	Kein Zugriff

Tabelle 3.4 — Datenspeicherung und Microsoft-Zugriff nach Datenkategorie im Enterprise-Szenario

Eine Warnung für Datenschutzbeauftragte: Auch wenn Microsoft keine Unternehmensdaten für das Modelltraining nutzt und die Daten in der EU verarbeitet, heißt das nicht, dass der Copilot-Einsatz datenschutzrechtlich unkritisch ist. Die DSGVO stellt eigenständige Anforderungen, die davon unabhängig sind, was der Auftragsverarbeiter mit den Daten tut. Diese Anforderungen werden in Kapitel 6 ausführlich behandelt.

 

3.5 Die EU Data Boundary — was das konkret bedeutet

Im Januar 2023 kündigte Microsoft die EU Data Boundary an: eine Zusage, dass Kundendaten von Enterprise-Kunden mit Tenant-Standort in der EU innerhalb europäischer Rechenzentren gespeichert und verarbeitet werden. Seit Januar 2024 gilt das vollumfänglich für Microsoft 365, Azure und Dynamics 365. Für Copilot für Microsoft 365 ist die EU Data Boundary ab Aktivierung grundsätzlich eingeschlossen.

Was die EU Data Boundary konkret bedeutet: Copilot-Anfragen werden in europäischen Rechenzentren verarbeitet — Deutschland, Niederlande, Irland, Frankreich, Finnland. Ihre Dokumente und E-Mails bleiben in der EU. Die LLM-Verarbeitung durch Azure OpenAI findet in EU-Rechenzentren statt. Das Modell „reist“ Ihre Daten nicht in US-Infrastruktur.

Abb. 3.5 — EU Data Boundary: Abgedeckte Dienste und Ausnahmen im Detail

Was die EU Data Boundary nicht bedeutet: Sie ist kein Freifahrtschein für die DSGVO. Der Auftragsverarbeitungsvertrag (AVV) mit Microsoft ist weiterhin erforderlich. Die Verantwortung für die Zweckbestimmung der Datenverarbeitung liegt weiterhin bei Ihnen als Verantwortlichem im Sinne der DSGVO. Die Rechte betroffener Personen — Auskunft, Löschung, Berichtigung — müssen Sie gewährleisten.

Ausnahmen und Feinheiten: Telemetrie- und Diagnosedaten können weiterhin in US-Rechenzentren verarbeitet werden — allerdings handelt es sich dabei ausschließlich um technische Metadaten für den Betrieb der Dienste, nicht um Inhaltsdaten. Microsoft dokumentiert diese Ausnahmen im Service Trust Portal. Bestimmte globale Infrastrukturdienste — DNS-Dienste, CDN, Anti-Abuse-Systeme — arbeiten ebenfalls global, ohne Inhaltsdaten zu verarbeiten.

Praktischer Check: Ist Ihr Tenant korrekt konfiguriert?

Die EU Data Boundary ist für Tenants, die in einer europäischen Region angelegt wurden, automatisch aktiv. Den aktuellen Status prüfen Sie im Microsoft 365 Admin Center unter Einstellungen → Organisationsprofil → Datenstandort. Dort sehen Sie für jeden Dienst, in welcher Region Ihre Daten gespeichert werden.

Wenn Ihr Tenant in einer nicht-europäischen Region angelegt wurde — was für deutsche Unternehmen selten, aber nicht unmöglich ist — gibt es das Data Residency Add-On, das eine kostenpflichtige Migration der Daten in EU-Rechenzentren ermöglicht. Der Prozess dauert mehrere Monate und ist aufwendig. Er ist selten notwendig, da die große Mehrheit der in Deutschland angelegten Tenants von Anfang an in der EU-Region konfiguriert wurde.

ℹ️ HINWEIS FÜR DSBs — EU Data Boundary und der Auftragsverarbeitungsvertrag

Die EU Data Boundary entbindet nicht von der Pflicht zum Abschluss eines Auftragsverarbeitungsvertrags (AVV) gemäß Art. 28 DSGVO. Microsoft stellt den AVV im Microsoft Online Subscription Agreement bereit — er wird automatisch akzeptiert, wenn Sie einen Enterprise-Vertrag abschließen. Was viele DSBs übersehen: Der AVV mit Microsoft regelt die Datenverarbeitung durch Microsoft als Auftragsverarbeiter. Er regelt nicht die Datenverarbeitung Ihrer Mitarbeiter untereinander — also die Tatsache, dass Copilot Mitarbeiter A Informationen liefert, die aus Dokumenten stammen, die Mitarbeiter B erstellt hat. Das ist interne Verarbeitung durch Sie als Verantwortlichen, die Sie selbst rechtskonform gestalten müssen. Kurz gesagt: Der Microsoft-AVV ist notwendig. Er reicht nicht allein. Ihre DSFA (Datenschutz-Folgenabschätzung) muss beide Ebenen abdecken: die Verarbeitung durch Microsoft und die interne Verarbeitung durch Copilot im Nutzerkreis.

 

3.6 Die fünf Fragen, die Sie sich jetzt stellen müssen

Am Ende dieses Kapitels stehen fünf Fragen, die keine rhetorischen sind. Es sind Fragen mit Konsequenzen — für die Sicherheit Ihres Copilot-Einsatzes, für die DSGVO-Konformität und für Ihr persönliches Haftungsrisiko als Verantwortlicher. Gehen Sie diese Fragen ehrlich durch.

Abb. 3.6 — Sensitivity Labels: Die fünf Stufen und ihr direkter Einfluss auf das Copilot-Verhalten

Abb. 3.7 — Berechtigungsstruktur: Typischer Zustand vor und nach der Copilot-Bereinigung

Abb. 3.8 — Datenklassifizierungsstatus: Wie ein typischer Tenant vor der Copilot-Einführung aussieht

Frage	Wenn Nein — Konsequenz	Zeitaufwand Behebung	Priorität
Wissen Sie, wer auf was Zugriff hat? Berechtigungsaudit vorhanden?	Copilot verteilt unbeabsichtigt sensible Daten an nicht berechtigte Nutzer	4 bis 12 Wochen	Kritisch
Sind Sensitivity Labels konfiguriert und flächendeckend angewendet?	Copilot hat keine Klassifizierungsgrundlage, behandelt 75 % der Daten als frei zugänglich	2 bis 8 Wochen	Hoch
Gibt es Everyone- oder All-Company-Gruppen in SharePoint-Sites?	Alle Inhalte dieser Sites sind für alle Mitarbeiter durch Copilot abrufbar	1 bis 4 Wochen	Kritisch
Wurden Zugriffsrechte in den letzten 12 Monaten reviewed?	Ehemalige Mitarbeiter, überzogene Rechte und verwaiste Konten sind aktiv	2 bis 6 Wochen	Hoch
Hat Ihr DSB den Copilot-Einsatz bewertet und eine DSFA erstellt?	DSGVO-Verletzung möglich, fehlende Dokumentation, persönliche Haftungsrisiken	4 bis 8 Wochen	Kritisch

Tabelle 3.5 — Die fünf Kernfragen vor der Copilot-Aktivierung mit Konsequenzen und Aufwandseinschätzung

Eine ehrliche Einschätzung auf Basis der Praxiserfahrung: Die meisten Organisationen können mindestens drei dieser fünf Fragen nicht mit einem klaren „Ja“ beantworten. Das ist kein Grund, Copilot nicht einzuführen — aber es ist ein klares Signal, in welcher Reihenfolge die Vorbereitungsarbeiten priorisiert werden müssen.

Was Sie mit den Antworten tun

Die fünf Fragen sind keine Checkliste, die man „durchhakt“. Sie sind Indikatoren für die Systemreife Ihres Tenants. Ein „Ja“, das nicht der Realität entspricht, ist gefährlicher als ein ehrliches „Nein“. Gehen Sie die Antworten daher nicht mit dem Ziel durch, möglichst viele Haken zu setzen — sondern mit dem Ziel, ein realistisches Bild Ihrer Situation zu bekommen.

Wenn alle fünf Fragen mit „Ja“ beantwortet werden können: Sie sind bereit für einen Copilot-Pilot. Nicht für den unternehmensweiten Rollout — für einen kontrollierten Pilot mit 20 bis 50 Nutzern, klaren Erfolgskriterien und einer Beobachtungszeit von mindestens acht Wochen. Nutzen Sie den Pilot, um verbleibende Oversharing-Risiken zu identifizieren, die der Audit möglicherweise nicht gefunden hat. Kein Tenant ist nach einem ersten Audit perfekt.

Wenn eine oder zwei Fragen mit „Nein“ beantwortet werden: Identifizieren Sie, welche Lücken Sie innerhalb von vier bis acht Wochen schließen können — und welche länger dauern. Eine fehlende DSFA lässt sich bei guter Vorbereitung in sechs Wochen erstellen. Eine vollständige Berechtigungsbereinigung eines großen Tenants dauert vier bis sechs Monate. Beides gleichzeitig anzugehen ist möglich — aber nur mit klar definierten Verantwortlichen und ausreichend Ressourcen. Erstellen Sie einen Maßnahmenplan mit konkreten Zuständigkeiten und realistischen Terminen.

Wenn drei oder mehr Fragen mit „Nein“ beantwortet werden: Stopp. Kein Pilot, kein Rollout. Lösen Sie zuerst die Grundprobleme. Die häufigsten Ursachen für dieses Ergebnis in der Praxis: eine Berechtigungsstruktur, die seit Jahren nicht angefasst wurde, und eine fehlende DSFA. Beides lässt sich lösen — aber nicht parallel zur Copilot-Einführung. Die Versuchung, trotzdem anzufangen und „parallel zu bereinigen“, ist groß. Die Konsequenzen, wenn dabei etwas schiefgeht, sind größer. Ein Vorfall, der durch unzureichende Vorbereitung entsteht, kostet mehr Zeit, Geld und Vertrauen als die Bereinigung selbst.

 

Eine häufige Frage: Kann man Copilot aktivieren und die Bereinigung parallel durchführen? Technisch ja. Praktisch ist das riskant. Sobald Copilot aktiv ist, beginnt es, Daten zu finden. Wenn die Bereinigung noch läuft, ist das Zeitfenster für unangenehme Überraschungen geöffnet. Empfehlung: Bereinigen Sie mindestens die kritischen Punkte — Everyone-Gruppen, HR-Daten, Gehaltsinfos — vor der Aktivierung. Nutzen Sie dann den kontrollierten Piloten als Qualitätscheck für den Rest.

 

➡️ WAS JETZT ZU TUN IST — Konkrete Schritte für die nächsten Wochen

Schritt 1 — Sofort, unabhängig von Copilot-Plänen: SharePoint-Berechtigungsaudit starten. Priorität: Sites mit Everyone-Gruppen und Sites mit HR-, Finanz- oder Strategiedaten. Ehemalige Mitarbeiter-Konten prüfen und inaktive Konten deaktivieren. Offboarding-Prozess dokumentieren. Teams-Kanäle auf IT-Passwörter und Zugangsdaten durchsuchen und bereinigen.   Schritt 2 — Vor der Copilot-Aktivierung: Sensitivity Labels konfigurieren: Mindestens drei Stufen (Öffentlich / Intern / Vertraulich). Default-Label für neue Dokumente setzen. DSB einbinden: Datenschutz-Folgenabschätzung für Copilot in Auftrag geben. MFA für alle Copilot-Nutzer erzwingen: Conditional-Access-Policy erstellen. Berechtigungskonzept dokumentieren: Wer darf was sehen? Welche Gruppen gibt es?   Schritt 3 — Während des Pilots: Pilotnutzer aktiv nach Oversharing-Findings befragen: Was hat Copilot gefunden, das es nicht hätte finden sollen? Purview Audit Log aktivieren und Copilot-Ereignisse wöchentlich prüfen. Findings aus dem Pilot als Bereinigungsliste für den Breit-Rollout nutzen.   Zeitplan-Empfehlung für eine mittelgroße Organisation (500–2.000 Mitarbeiter): Wochen 1–2: Berechtigungsaudit + kritische Sofortmaßnahmen (Everyone-Gruppen, HR-Daten) Wochen 3–4: Sensitivity Labels konfigurieren + DSB-Bewertung beauftragen Wochen 5–6: Piloten starten mit 25–50 Nutzern, MFA erzwingen Wochen 7–8: Piloten auswerten, restliche Bereinigung priorisieren Ab Woche 9: Stufenweiser Rollout, Abteilung für Abteilung

 

Fazit: Copilot ist so sicher wie Ihre Berechtigungsstruktur

Die technische Architektur von Copilot ist durchdacht und transparent. Microsoft hat klare Grenzen gezogen: kein Modelltraining auf Enterprise-Daten, EU Data Boundary für die Verarbeitung, konsequente Berechtigungsinheritanz ohne Privilege Escalation. Das sind echte Zusicherungen mit vertraglichem Fundament.

Die Risiken liegen nicht bei Microsoft — sie liegen in den Berechtigungsstrukturen, die in Organisationen über Jahre gewachsen sind und die niemand je systematisch aufgeräumt hat. Copilot macht diese Risiken sichtbar. Meistens auf eine Art, die unangenehm und lehrreich zugleich ist.

Der Unterschied zwischen einem guten und einem problematischen Copilot-Start liegt nicht in der Technologie. Er liegt in der Vorbereitung: Ein halbes Dutzend Wochen gezielter Arbeit an Berechtigungen, Labels und Prozessen. Wer diese Investition tätigt, erlebt Copilot als das, was es sein soll: ein leistungsfähiges Werkzeug, das die Arbeit erleichtert. Wer es lässt, erlebt die Gehaltstabellen-Geschichte — und die Erklärungen, die darauf folgen.

Es gibt einen Aspekt, der in der Diskussion um Copilot oft vergessen wird: Die Bereinigung der Berechtigungsstruktur ist nicht nur eine Copilot-Voraussetzung, sie ist eine überfällige Maßnahme für jede Organisation, die seriös mit Daten umgeht. Copilot ist in diesem Sinne eine Chance: Die Notwendigkeit einer Berechtigungsbereinigung ist plötzlich kein abstraktes Compliance-Thema mehr, sondern ein konkretes Geschäftsrisiko. Das ist ein Argument, das in Führungsgremien besser ankommt als jede ISO-27001-Anforderung.

 

Praktische Umsetzung: Die Berechtigungsbereinigung in Phasen

Eine vollständige Berechtigungsbereinigung in einem gewachsenen Tenant ist kein Wochenendprojekt. Sie ist ein strukturiertes Programm, das in Phasen aufgeteilt werden muss, um den laufenden Betrieb nicht zu stören. Die folgende Tabelle zeigt eine bewährte Phasenstruktur:

Phase	Dauer	Inhalt	Ergebnis
Phase 1: Inventarisierung	Woche 1–2	SharePoint-Berechtigungsaudit, Everyone-Gruppen identifizieren, inaktive Konten listen	Vollständiges Bild der Ist-Situation
Phase 2: Sofortmaßnahmen	Woche 2–3	HR-Daten absichern, Passwörter entfernen, kritische Oversharing-Punkte schließen	Kritischste Risiken beseitigt
Phase 3: Strukturbereinigung	Woche 3–6	Gruppenstruktur aufbauen, Everyone-Gruppen durch rollenbasierte Gruppen ersetzen	Need-to-know-Prinzip umgesetzt
Phase 4: Klassifizierung	Woche 4–8	Sensitivity Labels konfigurieren, Default-Labels setzen, DLP-Richtlinien aktivieren	Datenklassifizierung aktiv
Phase 5: Prozesse	Woche 6–8	Access-Review-Zyklus etablieren, Offboarding-Prozess dokumentieren, Schulungen	Nachhaltige Governance
Phase 6: Pilot	Ab Woche 9	Copilot-Pilot mit 25–50 Nutzern, Audit Log aktivieren, Findings auswerten	Controlled Rollout-Start

Tabelle 3.6 — Berechtigungsbereinigung in Phasen: Zeitplan und Meilensteine

Anmerkung zur Zeitschätzung: Die Angaben gelten für eine mittlere Organisation mit 500 bis 2.000 Nutzern und einem Tenant, der seit mindestens drei Jahren besteht. Kleinere Organisationen können schneller sein — sofern die Dokumentation stimmt, was selten der Fall ist. Größere Organisationen brauchen entsprechend länger, können aber mit mehr Ressourcen und parallelisierten Teams arbeiten.

Copilot und Gast-Nutzer: ein unterschätztes Risiko

Ein Thema, das bei der Copilot-Einführung oft vergessen wird: Gast-Nutzer im Tenant. In vielen Organisationen gibt es externe Partner, Dienstleister oder Berater, die als Azure-AD-Gast-Accounts eingeladen sind und Zugriff auf Teams-Kanäle oder SharePoint-Sites haben. Diese Konten haben keine Copilot-Lizenz — aber sie können Copilot-Ausgaben sehen, wenn sie in denselben Teams-Kanälen aktiv sind wie Copilot-Nutzer.

Das bedeutet: Wenn ein Mitarbeiter in einem Teams-Kanal, in dem auch Gast-Nutzer Mitglieder sind, eine Copilot-Zusammenfassung teilt — oder wenn Copilot im Kanal eine Meeting-Zusammenfassung postet — können externe Gast-Nutzer diese Inhalte sehen. Das ist technisch korrektes Verhalten: der Kanal ist für alle Mitglieder sichtbar, und Copilot-Ausgaben sind Kanal-Inhalte. Trotzdem ist es ein Datenschutzrisiko, das in der Copilot-Richtlinie adressiert werden muss.

Empfehlung: Copilot-Nutzung in Kanälen mit Gast-Mitgliedern explizit einschränken oder die Gast-Mitgliedschaft vor dem Copilot-Rollout bereinigen. Die Frage, welche externen Personen Zugriff auf welche Teams haben, ist ohnehin eine Frage, die jährlich reviewt werden sollte — und die die meisten Organisationen seit der Einladung der Gast-Accounts nicht mehr gestellt haben.

Copilot-Governance: Wer darf Copilot wie nutzen?

Neben der technischen Vorbereitung braucht der Copilot-Betrieb eine klare Governance: Wer darf Copilot nutzen? Für welche Zwecke? Was ist verboten? Und was passiert, wenn jemand gegen die Regeln verstößt?

Diese Fragen können nicht von der IT alleine beantwortet werden. Sie erfordern die Beteiligung von HR, Rechtsabteilung, DSB und Betriebsrat (soweit vorhanden). Kapitel 4 und 5 behandeln das ausführlich. An dieser Stelle sei nur so viel gesagt: Eine Copilot-Nutzungsrichtlinie ist kein nettes Add-on, das man irgendwann schreibt. Sie ist eine Voraussetzung für den verantwortungsvollen Betrieb.

Die Richtlinie sollte mindestens folgende Punkte umfassen: Welche Daten dürfen Copilot-Prompts enthalten (keine Kundendaten in Prompts, die in externen Kontexten erscheinen könnten)? Was sind die Grenzen der Delegation (darf ein Mitarbeiter Copilot nutzen, um Informationen über Kollegen zu recherchieren)? Wie werden Copilot-Ausgaben behandelt — als vertrauliche Geschäftsinformation oder als öffentlich teilbare Zusammenfassung? Und was ist die Konsequenz bei Missbrauch?

Die letzte Frage wird selten gestellt und noch seltener beantwortet. Das ist ein Fehler. Denn die fehlende Konsequenz ist das erste, was Mitarbeiter bemerken, wenn eine Richtlinie nicht ernst genommen wird.

Ein abschließender Gedanke zur Governance: Copilot ist keine Ausnahme vom normalen Datenschutzrahmen Ihrer Organisation — es ist ein Teil davon. Das bedeutet, dass alle Richtlinien, die für den Umgang mit Unternehmensdaten gelten, auch für Copilot-Interaktionen gelten. Copilot-Ausgaben sind Dokumente im Sinne Ihrer Aufbewahrungsrichtlinien. Copilot-Prompts mit sensiblen Daten können die Vertraulichkeitspflichten verletzen, die für bestimmte Mitarbeitergruppen gelten. Und Copilot-generierte Zusammenfassungen sind keine neutral-objektiven Tatsachen, sondern KI-Ausgaben, die auf Wahrscheinlichkeit basieren — und gelegentlich falsch sind.

Das Bewusstsein für diese Einschränkungen ist Teil der Schulungsanforderung, die vor dem Rollout erfüllt werden muss. Mitarbeiter, die Copilot als unfehlbare Informationsquelle behandeln, sind ein Risiko — nicht wegen der KI, sondern wegen der ungeprüften Weiterverwendung ihrer Ausgaben. Auch das ist ein Thema der Governance, nicht der Technologie.

 

KAPITEL 4