Microsoft Copilot im Unternehmen: Produktivitäts-Booster oder Datenschutz-Risiko?

Microsoft Copilot wird vielen Geschäftsführern als sichere, integrierte KI für das eigene Unternehmen präsentiert. Der Gedanke liegt nahe: Wenn Copilot Teil von Microsoft 365 ist, wird es mit Datenschutz und DSGVO schon passen. Genau hier beginnt das Problem. Copilot ist kein Schutzschild, sondern ein Verstärker. Er bringt an die Oberfläche, was im Microsoft‑365‑Tenant ohnehin möglich ist – inklusive historisch gewachsener Fehlkonfigurationen.

Zwei Copilot‑Welten: Web-Copilot vs. M365-Copilot

Für eine saubere Einordnung ist die Unterscheidung zweier Welten entscheidend:

• Allgemeiner Copilot im Web: Der "kostenlose" Microsoft Copilot, aufrufbar im Browser oder über Windows, arbeitet primär auf Webdaten. Er ist funktional mit anderen öffentlichen KI‑Diensten vergleichbar. Für die Verarbeitung personenbezogener Daten gilt er nicht automatisch als datenschutzkonforme Unternehmenslösung.
• Copilot für Microsoft 365: Die lizenzpflichtige Variante, die direkt in Word, Excel, Teams, Outlook & Co. integriert ist. Hier greift das vertragliche Konstrukt von Auftragsverarbeitung und Data Protection Addendum (DPA) – allerdings nur, wenn das Unternehmen seine Hausaufgaben in Konfiguration, Berechtigungen und Dokumentation gemacht hat.

Die verbreitete Annahme „Copilot ist sicher, weil Microsoft“ ist damit zu kurz gegriffen. Entscheidend ist, in welchem Modus und in welchem Vertragsszenario Copilot betrieben wird – und wie der eigene Tenant dahinter aufgestellt ist.

Warum Copilot Altlasten im Tenant gefährlich macht

Copilot für Microsoft 365 arbeitet auf Basis der Daten, die über den Microsoft Graph aus SharePoint, OneDrive, Teams, Exchange und weiteren Diensten zugänglich sind. Technisch erhält Copilot keine Superrechte, sondern nutzt die bestehenden Berechtigungen des jeweiligen Nutzers. Genau dadurch entstehen für unvorbereitete Unternehmen zwei Risiken:

• Historisch gewachsene Oversharing-Strukturen: Viele KMU haben über Jahre hinweg SharePoint‑Sites, Teams‑Kanäle und Dateifreigaben aufgebaut, ohne ein stringentes Berechtigungskonzept umzusetzen. Anonyme Links, "Jeder im Unternehmen"‑Freigaben und externe Gäste sind keine Seltenheit.
• Sichtbarkeit durch KI: Was bisher nur theoretisch einsehbar war, aber praktisch kaum jemand gesucht hat, kann durch Copilot plötzlich über eine einfache Anfrage sichtbar werden – inklusive vertraulicher Personal‑, Projekt- oder Vertragsdaten.

Copilot macht also nicht per se etwas Neues, er macht bestehende Probleme sichtbar und nutzbar. Ohne vorherige Bereinigung der Berechtigungen wird aus einem Produktivitätstool schnell ein Compliance‑Risiko.

Schritt 1: Scope, Rechtsgrundlage und Verantwortung klären

Am Anfang steht eine klare Management-Entscheidung: Welche Copilot‑Variante wollen wir im Unternehmen zulassen – und wofür? Folgende Punkte sind dabei wesentlich:

• Trennung von privat und geschäftlich: Der allgemeine Copilot im Web sollte für die Verarbeitung interner Unternehmensdaten und personenbezogener Informationen nicht freigegeben werden. Hier gelten dieselben Vorsichtsmaßnahmen wie bei anderen öffentlichen KI‑Diensten.
• Auftragsverarbeitung und DPA: Für Copilot in Microsoft 365 muss ein aktueller Auftragsverarbeitungsvertrag mit Microsoft vorliegen. Die Nutzung erfolgt dann im Rahmen der bestehenden Microsoft‑365‑Produktverträge, inklusive klarer Rollenverteilung (Microsoft als Auftragsverarbeiter, Unternehmen als Verantwortlicher).
• Rechtsgrundlage und Zweckbindung: Die Nutzung von Copilot zur Verarbeitung personenbezogener Daten benötigt eine tragfähige Rechtsgrundlage (z. B. Vertragserfüllung, rechtliche Verpflichtung oder berechtigtes Interesse). Gleichzeitig müssen Zweckbindung, Datenminimierung und Speicherbegrenzung eingehalten werden.

Damit ist klar: Copilot-Einführung ist ein Thema für Geschäftsführung, Datenschutz und IT gemeinsam – nicht für die IT „im Alleingang“.

Schritt 2: Rechteinventur und Berechtigungs-Audit

Die Rechteinventur ist die wichtigste – und meist unterschätzte – Voraussetzung für einen sicheren Copilot-Einsatz. In der Praxis empfiehlt sich ein mehrstufiges Vorgehen:

• Bestandsaufnahme aller relevanten Datenquellen: Welche SharePoint‑Sites, OneDrive‑Konten, Teams‑Kanäle, Mailboxen und Archivsysteme liegen im Tenant? Wo liegen besonders sensible Daten wie Personalakten, Gesundheitsdaten oder vertrauliche Verträge?
• Analyse der Berechtigungen: Für jede zentrale Datenquelle sollten die Zugriffsebenen geprüft werden. Typische Fundstellen sind: Ordner mit gebrochener Vererbung, globale Freigaben auf "Jeder im Unternehmen", offene oder abgelaufene Links, externe Gäste mit weitreichenden Rechten.
• Bereinigung vor Aktivierung: Kritische Freigaben werden entfernt oder reduziert, sensible Bereiche auf definierte Personenkreise beschränkt, externe Zugriffe konsolidiert. Wo nötig, werden neue Gruppen- und Rollenmodelle eingeführt (z. B. rollenbasierte Zugriffskonzepte pro Abteilung).

Gerade hier tun sich viele Mittelständler schwer, weil die Strukturen über Jahre gewachsen sind und niemand „den ganzen Tenant“ im Blick hat. Aus Sicht von GLAESS ist genau das der Punkt, an dem Copilot‑Projekte in der Praxis stehen bleiben oder kippen – weil eine saubere Berechtigungsarchitektur bisher nie konsequent aufgesetzt wurde.

Schritt 3: Datenklassifikation und Vertraulichkeitsbezeichnungen

Nach der Bereinigung der Berechtigungen folgt die fachliche Dimension: Datenklassifikation. Ziel ist, dass das System unterscheiden kann, welche Informationen besonders geschützt werden müssen. In Microsoft 365 erfolgt das unter anderem über:

• Vertraulichkeitsbezeichnungen (Sensitivity Labels): Dateien, E‑Mails, Sites und Teams lassen sich mit Labels wie "Intern", "Vertraulich" oder "Streng vertraulich" versehen. Diese Labels können technische Maßnahmen auslösen, z. B. Verschlüsselung, eingeschränkte Weitergabe oder Zugriffsbeschränkung.
• Data Loss Prevention (DLP): Über DLP‑Richtlinien können Unternehmen definieren, welche Inhalte (z. B. IBAN, Personalausweisnummern, Gesundheitsdaten) nicht unbemerkt geteilt oder aus dem Unternehmen herausgetragen werden dürfen.
• Automatisierte Erkennung: Je nach Branche und Datenlage ist der Einsatz automatischer Klassifizierungsmechanismen sinnvoll, um sensible Inhalte auch dann zu markieren, wenn der Nutzer nicht aktiv ein Label setzt.

Für Copilot heißt das: Je besser die Daten klassifiziert und geschützt sind, desto gezielter lassen sich Risiken begrenzen. Copilot soll Mitarbeiter unterstützen – nicht dazu verleiten, unbemerkt in hochkritische Datenbereiche hineinzugreifen.

Schritt 4: Protokollierung, Aufbewahrung und Auskunftsfähigkeit

Aus Sicht der DSGVO sind Copilot‑Interaktionen ebenfalls personenbezogene Daten: Prompts, Antworten und abgeleitete Inhalte können Rückschlüsse auf Mitarbeiter, Kunden oder Geschäftsvorgänge zulassen. Daraus ergeben sich konkrete Pflichten:

• Logging aktivieren und strukturieren: Copilot‑Nutzung sollte über zentrale Audit‑Mechanismen protokolliert werden. Wichtig ist, dass klar erkennbar ist, welcher Benutzer welche Abfragen gestellt hat und auf welche Systeme zugegriffen wurde.
• Aufbewahrungs- und Löschfristen definieren: Unternehmen müssen festlegen, wie lange Interaktionsdaten aufbewahrt werden (z. B. 30 Tage) und wie sie automatisiert gelöscht werden. Diese Fristen müssen zu den allgemeinen Löschkonzepten und Aufbewahrungspflichten passen.
• Auskunfts- und Löschersuchen ermöglichen: Im Rahmen von Betroffenenrechten müssen Unternehmen in der Lage sein, relevante Copilot‑Interaktionen zu identifizieren, offenzulegen und – soweit keine anderen Pflichten entgegenstehen – zu löschen.

Praktisch bedeutet das: Copilot darf nicht als „Blackbox in der Wolke“ betrieben werden. Er muss in die bestehende Protokollierungs- und Governance‑Landschaft der Organisation integriert sein.

Schritt 5: Datenschutzfolgeabschätzung (DSFA) als Pflichtbaustein

Sobald Copilot in Bereichen eingesetzt wird, in denen umfangreich personenbezogene Daten verarbeitet werden, führt in der Regel kein Weg an einer Datenschutzfolgeabschätzung (DSFA) vorbei. Eine DSFA für Copilot sollte mindestens enthalten:

• Beschreibung der Verarbeitung: Welche Anwendungsfälle werden mit Copilot abgedeckt? In welchen Abteilungen? Welche Datenarten sind betroffen?
• Analyse der Risiken: Welche potenziellen Schäden könnten für Betroffene entstehen, wenn Copilot falsche Ergebnisse liefert, sensible Daten offenlegt oder langfristig Profile erkennbar macht?
• Bewertung und Maßnahmen: Welche technischen und organisatorischen Maßnahmen (TOMs) senken diese Risiken? Wie greifen Berechtigungskonzepte, DLP, Sensitivity Labels, Schulung und Richtlinien ineinander?

In einigen Branchen und öffentlichen Einrichtungen existieren bereits DSFA‑Bausteine für Microsoft‑365‑Dienste und Copilot. Für KMU ist es sinnvoll, sich davon inspirieren zu lassen, die Bewertung aber auf die eigenen Prozesse und Risiken zuzuschneiden.

Schritt 6: IT-Nutzungsrichtlinie, Schulung und Change Management

Technik allein reicht nicht. Ohne klare Regeln und Schulung wird Copilot entweder gar nicht genutzt – oder falsch. Eine praxisnahe Einführung umfasst daher:

• Anpassung der IT-Nutzungsrichtlinie: Die Richtlinie sollte konkret festlegen, wofür Copilot genutzt werden darf, welche Daten tabu sind, welche Kontroll- und Protokollmechanismen bestehen und wie mit Fehlverhalten umgegangen wird.
• Verfahrensanweisungen für Datenschutzfälle: Prozesse für Auskunfts‑ und Löschersuchen, Meldung von Datenschutzvorfällen und Korrektur falscher Ausgaben müssen auch den Copilot‑Einsatz abdecken.
• Schulung der Mitarbeitenden: Nutzer müssen den Unterschied zwischen "Arbeit"‑ und "Web"‑Modus kennen, verstehen, wie Copilot mit Unternehmensdaten arbeitet und warum bestimmte Anfragen unzulässig sind. Dazu gehört auch der kritische Umgang mit KI‑Antworten.

Wer Copilot nur technisch freischaltet, aber nicht erklärt, wie und wofür er eingesetzt werden soll, erzeugt Unsicherheit – oder unkontrollierte Schattennutzung.

Schritt 7: Laufendes Monitoring und Governance

Copilot‑Einführung ist kein einmaliges Projekt, sondern der Einstieg in eine neue Form der Arbeit. Entsprechend wichtig ist eine kontinuierliche Steuerung:

• Regelmäßige Rechte-Reviews: Mindestens einmal im Jahr, besser häufiger, sollten kritische Datenbereiche und Berechtigungen überprüft und bereinigt werden.
• Reporting und Kennzahlen: IT und Datenschutz sollten regelmäßig zusammen auf Logs, DLP‑Events und Auffälligkeiten schauen. Ziel ist, Muster zu erkennen und Maßnahmen anzupassen.
• Erweiterung auf weitere KI-Szenarien: Wer Copilot sauber eingeführt hat, baut damit die Basis für weitere KI‑Anwendungen im Unternehmen – von Prozessautomatisierung über Wissensmanagement bis hin zu branchenspezifischen Assistenten.

So wird aus Copilot kein Einmalprojekt, sondern ein Baustein einer langfristigen KI‑Strategie im Unternehmen.

Fazit: Copilot ist ein Compliance-Projekt – kein IT-Spielzeug

Für mittelständische Unternehmen ist Microsoft Copilot eine Chance, die Produktivität ihrer Organisation deutlich zu steigern. Gleichzeitig macht Copilot jede Schwäche in Berechtigungen, Datenorganisation und Governance sichtbar. Wer ihn unvorbereitet aktiviert, handelt grob fahrlässig – insbesondere im Hinblick auf DSGVO, Haftungsrisiken und Reputationsschäden.

Die gute Nachricht: Mit einer strukturierten Rechteinventur, klaren Datenklassifikationen, einer sauber dokumentierten DSFA, konsequentem Logging und praxisnahen Richtlinien lässt sich Copilot verantwortbar einsetzen. GLAESS versteht Automatisierung als durchgängige Kette: von der Maschine über die Office‑Prozesse bis zur KI‑Unterstützung. Genau diesen Blick brauchen KMU, wenn sie Copilot nicht als Hype‑Feature, sondern als strategisches Werkzeug für ihren Geschäftsalltag nutzen wollen.