M365 Copilot sicher einführen: Berechtigungen zuerst

Die Angst vor Microsoft 365 Copilot ist fast immer falsch adressiert. Gefürchtet wird die KI: dass sie halluziniert, dass sie Firmendaten nach draussen trägt. Was dann im Pilotbetrieb passiert, ist viel banaler. Jemand fragt Copilot nach dem Thema Lohn und bekommt eine Auswertung aus einem SharePoint-Ordner, der seit Jahren auf «Jeder» freigegeben ist. Wer M365 Copilot sicher einführen will, hat selten ein KI-Problem. Er hat ein Berechtigungsproblem, und das ist älter als Copilot.

Was Copilot tut und was nicht

Microsoft schreibt es in der eigenen Dokumentation ziemlich unmissverständlich: «Microsoft Copilot only surfaces organizational data to which individual users have at least view permissions.» (Quelle: Microsoft Learn, Data, Privacy, and Security for Microsoft Copilot)

Das heisst im Grunde: Copilot erfindet keine Zugriffe. Es liest exakt das, was der angemeldete Benutzer heute schon öffnen dürfte, über Mail, Teams, SharePoint und OneDrive hinweg. Dieselbe Dokumentation hält ausserdem fest, dass Prompts und Antworten nicht zum Training der Sprachmodelle verwendet werden und dass Verschlüsselung über Sensitivity Labels respektiert wird. Dasselbe Prinzip gilt für Erweiterungen: Wenn ihr Copilot über Graph-Konnektoren oder Agenten an weitere Systeme anbindet, liefert es auch dort nur zurück, worauf der Benutzer Zugriff hat. Die Grenze verläuft konsequent an der Berechtigung, nirgendwo sonst.

Für die Frage, ob das Tool selbst sauber gebaut ist, sind das gute Nachrichten. Und genau hier sitzt der Denkfehler, den wir in Gesprächen zur KI-Einführung am häufigsten sehen: «Copilot respektiert eure Berechtigungen» ist nur so beruhigend wie eure Berechtigungen selbst.

Gesperrt ist nicht dasselbe wie unauffindbar

Vor Copilot hat euch in der Praxis nicht das Berechtigungskonzept geschützt. Euch hat die Unauffindbarkeit geschützt.

Kaum jemand klickt sich freiwillig durch zehntausende Dokumente in fremden Teamsites. Die Gehaltsübersicht im falschen Ordner, das Due-Diligence-Memo aus einem alten Projekt, die Kündigungsliste aus der Reorganisation: alles theoretisch zugänglich, praktisch unsichtbar. Ein M365-Tenant, der zehn Jahre gewachsen ist, trägt Migrationsarchive, verwaiste Teams-Kanäle und Freigaben auf «Jeder ausser externen Benutzern», die längst vergessen gegangen sind.

Copilot ändert das. Es durchsucht semantisch alles, worauf der Benutzer Zugriff hat, und liefert das Relevanteste in Sekunden, sauber zusammengefasst und auf Deutsch. Aus «theoretisch zugänglich» wird «eine Frage entfernt». Das Tool leakt nichts. Es macht sichtbar, was schon offen war.

In unserer Erfahrung ist das der Moment, in dem eine Copilot-Einführung ins Stocken gerät: nicht wegen der Technik, sondern weil beim ersten ernsthaften Test Dinge auftauchen, die dort nie hätten liegen dürfen. Das ist unangenehm. Es ist aber auch die ehrlichste Bestandesaufnahme eures Tenants, die ihr je gratis bekommen habt.

Das Muster sieht dabei meistens gleich aus. Ein Unternehmen startet den Pilot mit einer Handvoll Leuten aus IT und Fachbereichen. In den ersten Tagen tauchen keine Katastrophen auf, dafür Kleinigkeiten mit Gewicht: eine alte Geschäftsleitungspräsentation mit Lohnbändern, abgelegt in einer Projektsite von vor fünf Jahren. Ein Offertenordner, auf den der halbe Betrieb Zugriff hat, weil das Projektteam damals «alle» eingeladen hat und die Site nie geschlossen wurde. Nichts davon ist ein Copilot-Fehler. Alles davon war seit Jahren offen. Neu ist, dass es jemand sieht, und dass die Geschäftsleitung zum ersten Mal eine konkrete Liste hat statt eines diffusen Bauchgefühls.

Warum ein zusätzliches Tool die falsche erste Antwort ist

Der Reflex an dieser Stelle ist bekannt: ein Produkt dazukaufen. Der Markt liefert inzwischen für fast jede Copilot-Sorge ein Add-on, von Oversharing-Scannern bis zu KI-Monitoring-Suiten.

Manche davon sind nützlich. Aber ein Tool, das Oversharing meldet, räumt eure Freigaben nicht auf. Es dokumentiert nur, dass sie offen sind, und stellt euch dafür eine Jahresrechnung. Die eigentliche Arbeit bleibt dieselbe und ist unglamourös: wissen, welche Daten euch weh tun würden, die Ablagen mit genau diesen Daten zuerst aufräumen, Eigentümer benennen, Freigabelinks mit Ablaufdatum statt für immer. Das kostet Arbeitszeit und Disziplin, keine Lizenzen. Wie man schützenswerte Daten überhaupt identifiziert, haben wir im Beitrag zur Datenklassifizierung beschrieben; sie ist auch hier das Fundament.

Dazu kommt: Einen Teil der Werkzeuge für dieses Aufräumen bezahlt ihr bereits. Je nach Lizenz stecken im Tenant Freigabeberichte, Sensitivity Labels und Zugriffsüberprüfungen, die nie jemand aktiviert hat. Diese Funktionen sind unspektakulär, und kein Vertriebler ruft euch deswegen an, weil sie schon bezahlt sind. Deshalb beginnen wir dort. Erst ausschöpfen, was vorhanden ist, dann über Neues reden: dieselbe Logik, die wir bei Sicherheitstools generell vertreten, und sie gilt für KI-Projekte unverändert.

Dazu der Schweizer Kontext, weil er oft für Verwirrung sorgt: Die Schweiz hat kein eigenes KI-Gesetz, der Bundesrat hat sich Anfang 2025 bewusst dagegen entschieden. Was gilt, ist das nDSG. Wenn Copilot Personendaten in Antworten zusammenzieht, ist das ein Datenschutzthema nach bestehendem Recht, kein neues Rechtsgebiet. Auch hier gilt: Die Pflicht, Personendaten nur denen zugänglich zu machen, die sie brauchen, hattet ihr schon vor Copilot. Copilot macht nur messbar, ob ihr sie erfüllt. Und verantwortlich dafür bleibt ihr als Unternehmen, nicht Microsoft, egal wie gut die Plattform dokumentiert ist.

Verbieten ist die teuerste Variante

Der Gegenreflex zum Add-on-Kauf ist das Blockieren: Copilot bleibt aus, bis der Tenant perfekt aufgeräumt ist. Das fühlt sich vorsichtig an und schafft in der Praxis das grössere Problem. Die Nachfrage nach KI verschwindet nicht, sie wandert in private ChatGPT-Konten im Browser. Dort verlassen Firmendaten den Tenant tatsächlich, ohne Berechtigungsmodell, ohne Protokoll, ohne Sensitivity Label. Diesen Effekt kennen wir seit Jahren von der Schatten-IT; mit KI wiederholt er sich nur schneller und mit sensibleren Daten. Ein blockiertes Copilot neben frei erreichbaren Browser-KIs ist die schlechteste Kombination aus beidem: kein Produktivitätsnutzen, und das Datenrisiko liegt genau dort, wo ihr es am wenigsten seht.

Der Tenant muss vor dem Start auch nicht perfekt sein. Er muss an den Stellen sauber sein, an denen es weh tut, und der Rest wird im Betrieb besser. Perfektion als Startbedingung ist nur eine höfliche Form des Verbots.

Copilot sicher einführen: was vor dem Rollout stehen muss

Wir raten niemandem, Copilot deshalb auf Eis zu legen. Der Produktivitätsnutzen ist real, und die Konkurrenz eures Anbieters ist nicht besser, sie ist nur weniger tief in euren Daten. Strittig ist aus unserer Sicht nur die Reihenfolge. Vier Dinge gehören vor den breiten Rollout:

  1. Ihr wisst, welche Daten kritisch sind. Nicht als 40-seitiges Klassifizierungskonzept, sondern als kurze, ehrliche Liste: Löhne, Gesundheitsdaten, M&A, Kundenverträge, Preiskalkulationen. Was auf dieser Liste steht, bestimmt, wo ihr zuerst hinschaut.
  2. Die kritischen Ablagen sind geprüft. Nicht der ganze Tenant, das schafft niemand vor einem Rollout. Aber die Sites und Teams, in denen die Liste aus Punkt eins liegt, haben geklärte Zugriffe und einen Eigentümer, der sie halten muss.
  3. Ein Pilot, der aktiv sucht. Gebt einer kleinen Gruppe Copilot mit dem expliziten Auftrag, Dinge zu finden, die sie nicht sehen sollten. Die Prompts dürfen banal klingen: Was verdient die Geschäftsleitung? Fasse die letzten Kündigungen zusammen. Welche Konditionen hat unser grösster Kunde? Jeder Treffer ist eine Berechtigung, die ihr ohnehin korrigieren musstet, nur dass ihr sie jetzt kennt.
  4. Eine kurze Nutzungsregel. Wer bekommt Copilot, wofür, und was gehört weiterhin nicht in einen Prompt. Eine Seite reicht für den Anfang. Wie so eine Regel in eine bestehende Governance passt, zeigt unser Beitrag zur KI-Governance.

Danach in Wellen ausrollen statt für alle auf einmal. Jede Welle bringt neue Benutzer mit anderen Zugriffsprofilen und deckt damit andere Ecken des Tenants auf; der Rollout ist so nebenbei ein fortlaufender Berechtigungstest, den ihr sonst teuer einkaufen müsstet. Genau diese Reihenfolge, Datenlage vor Lizenzen, ist auch der Kern unserer Arbeit rund um KI-Governance und sichere KI-Einführung.

Die Frage vor dem ersten Prompt

Falls du die Person bist, die das der Geschäftsleitung erklären muss, hilft eine Umbenennung: Beantrage kein Budget für «KI-Sicherheit», das klingt nach einem weiteren Fass ohne Boden. Beantrage die Berechtigungs-Bereinigung, die euer Tenant ohnehin gebraucht hätte, mit Copilot als Anlass und Termin. Der Unterschied ist mehr als Rhetorik: Die Arbeit zahlt auf jedes Audit, jeden Versicherungsfragebogen und jeden künftigen Vorfall ein, nicht nur auf ein einzelnes Tool. So wird aus der Frage «Was kostet uns die KI zusätzlich?» die Frage «Was räumen wir bei der Gelegenheit endlich auf?».

Copilot einzuführen ist am Ende eine seltene Gelegenheit: Zum ersten Mal gibt es einen geschäftlichen Grund, das Berechtigungschaos anzugehen, das intern seit Jahren bekannt ist und nie Priorität hatte. Die Firmen, die den Rollout sauber hinbekommen, sind danach KI-tauglich. Und ihr Tenant ist nebenbei für jeden anderen Angriffspfad ein kleineres Ziel, ohne ein einziges neues Sicherheitsprodukt.

Wenn ihr vor dem Rollout eine ehrliche Aussensicht auf Datenlage und Berechtigungen wollt: ein Erstgespräch kostet nichts und endet nicht in einer Einkaufsliste.

Und bis dahin die eine Frage, die den ganzen Artikel zusammenfasst: Welche Datei in eurem Tenant möchtest du nie in einer Copilot-Antwort sehen, und weisst du heute, wer darauf Zugriff hat?