DLP für Copilot sperrt vertrauliche Inhalte über Sensitivitätslabels

In vielen Tenants, die ich betreue, gehört Microsoft 365 Copilot längst zum Alltag und ist kein Experiment mehr. Trotzdem höre ich immer wieder dieselben Fragen. Meine Kunden wollen wissen, wie sie sicherstellen können, dass Copilot und Copilot Chat tatsächlich keine vertraulichen Dokumente oder E-Mails verarbeiten, und was das im Alltag für Berechtigungen, Auffindbarkeit und die Arbeit der Benutzer bedeutet. Genau dafür gibt es in Microsoft Purview jetzt die neue DLP-Standortoption für Copilot. Damit existiert endlich eine technische Sperre, die Sensitivitätslabels als DLP-Kriterium direkt dort auswertet, wo Copilot auf Inhalte zugreift.

Purview bietet einen eigenen DLP-Standort für Copilot

Wer im Purview-Portal eine benutzerdefinierte DLP-Richtlinie anlegt, findet seit einiger Zeit unter „Standort“ (Location) die Option „Microsoft 365 Copilot und Copilot Chat“. Das wirkt unscheinbar, ist aber ein wichtiger Schritt. DLP setzt nun genau an der Stelle an, an der Copilot Inhalte verarbeitet, und nicht erst dann, wenn der Benutzer etwas bearbeitet oder teilt. Ausgelöst wird die Regel über das Sensitivitätslabel. So lässt sich fein abgestuft festlegen, dass Copilot Dokumente, Mails oder Chats mit bestimmten Labels (z. B. „Vertraulich“ oder „Streng geheim“) weder lesen noch als Kontext verwenden darf.

Die Einrichtung ist erstaunlich einfach. Im Purview-Portal (https://learn.microsoft.com/en-us/purview/dlp-microsoft365-copilot-location-learn-about) legt man eine neue DLP-Richtlinie an, wählt als Standort „Microsoft 365 Copilot und Copilot Chat“, setzt die Bedingung „Inhalt enthält Sensitivitätslabel“ und bestimmt, für welche Labels die Richtlinie gelten soll. Als Aktion genügt meist „Blockieren“, damit Copilot keinen Zugriff erhält. Mit einer sauberen Label-Taxonomie im Rücken steuert man auf diese Weise gezielt, was Copilot sehen darf und was nicht. Worauf es dabei ankommt, habe ich in meinem Beitrag zur Label-Strategie beschrieben: Microsoft Purview Information Protection: Eine Taxonomie, die wirklich schützt.

Praxistipp: In meinen Projekten schalte ich neue DLP-Richtlinien für Copilot immer zuerst im Simulationsmodus (Simulation Mode) ein. So sehe ich, ob wichtige Arbeitsdokumente versehentlich blockiert würden, und bremse die Anwender im Produktivbetrieb nicht gleich aus.

Gesperrte Dateien bleiben in der Suche unter Umständen sichtbar

Die Richtlinie sperrt ausschließlich Copilot für Inhalte, die als geschützt gekennzeichnet sind. Andere Nutzer mit passender Berechtigung kommen weiterhin an die Dateien. Auf ein Detail mache ich Teams regelmäßig aufmerksam. Auch wenn Copilot die Datei nicht verarbeiten darf, kann sie je nach Suchkontext weiterhin als Treffer in SharePoint oder OneDrive erscheinen. Der Nutzer sieht dann etwa den Dateinamen, Copilot kann daraus aber keinen Kontext erzeugen und keine Inhalte im Detail anzeigen. Wichtig wird das vor allem bei strengeren DLP-Richtlinien, wenn es um Informationen geht, die zwar vertraulich, aber nicht komplett verborgen sind.

Eine Einschränkung sollte man kennen. Die Richtlinie greift nur bei Inhalten, die bereits ein Sensitivitätslabel tragen. Dokumente ohne Label oder mit falschem Label rutschen vollständig durch. Dieses bekannte Grundproblem löst auch DLP für Copilot nicht. Ich empfehle deshalb, DLP mit einer Richtlinie für automatisches Labeling zu kombinieren.

Jede neue Richtlinie läuft zuerst im Simulationsmodus

Neue DLP-Richtlinien für Copilot sollten nie ohne vorherige Simulation live gehen. Im Purview-Portal lassen sich Richtlinien in den Simulationsmodus versetzen. Dann sieht man ihre Wirkung, ohne im Produktivbetrieb tatsächlich etwas zu blockieren (https://learn.microsoft.com/en-us/purview/dlp-create-deploy-policy). Oft zeigt sich erst dort, wie viele produktiv genutzte Dateien ein Label tragen und ob die Richtlinie zu streng eingestellt ist. Verläuft der Test erfolgreich, schaltet man die Richtlinie scharf.

Ein typischer Ablauf sieht so aus:

flowchart TD
  A["DLP Policy für Copilot konfigurieren"] --> B["Im Simulationsmodus aktivieren"]
  B --> C["Testfälle durchspielen (z.B. Copilot auf gelabelte Datei ansetzen)"]
  C --> D["Reports kontrollieren: Was wäre blockiert?"]
  D --> E["Policy produktiv schalten"]

Abbildung: Typischer Ablauf bei der Einführung von DLP für Copilot mit Simulation

Die Richtlinie ist nur so gut wie die vergebenen Sensitivitätslabels

Viele sind überrascht, dass die DLP-Standortoption Copilot nur am Zugriff auf Inhalte hindert. Dateinamen oder Metadaten kann Copilot weiterhin sehen. Außerdem arbeitet die Richtlinie rein labelbasiert, ihre Wirkung hängt also davon ab, dass Labels konsequent und möglichst automatisiert vergeben werden. Ich erlebe häufig, dass Organisationen das Labeling in den ersten Copilot-Pilotphasen zu locker handhaben und erst nachbessern, wenn DLP-Blockaden sie dazu zwingen. Wer DLP für Copilot erfolgreich einsetzen will, braucht deshalb neben der Richtlinie auch ein tragfähiges Konzept für Sensitivitätslabels (mehr dazu hier).

Größere Mengen Dateien testweise zu labeln oder Richtlinien schnell anzupassen, gelingt auch per PowerShell (Microsoft Graph PowerShell SDK, Rolle „Information Protection Admin“). So lässt sich einem Dokument ein Label zuweisen:

# Voraussetzung: Microsoft Graph PowerShell SDK, Information Protection Admin
Connect-MgGraph -Scopes 'InformationProtectionPolicy.ReadWrite.All'
$labelId = '<Label-ID>'
Set-MgUserDriveItem -UserId <UserId> -DriveId <DriveId> -ItemId <ItemId> -SensitivityLabelId $labelId

DLP für Copilot löst nicht alles, bringt aber einen deutlichen Fortschritt

Die DLP-Standortoption für Copilot ist ein wichtiger Baustein, wenn Unternehmen die Arbeit mit KI absichern wollen. Richtig eingesetzt, lässt sich damit erstmals fein steuern, wo Copilot die Finger weglassen muss, und zwar ohne aufwendige Umwege im Berechtigungssystem. Ebenso klar ist aber, dass DLP für Copilot ohne durchdachtes Labeling-Konzept ein stumpfes Werkzeug bleibt. Meine Projekte zeigen, dass erst Automatisierung, Sensitivitätslabels und DLP gemeinsam den nötigen Schutz schaffen. Dieses Zusammenspiel liefert auch dem Betriebsrat belastbare Argumente für den KI-Einsatz. Wer jetzt beginnt, nutzt Copilot kontrolliert und behält trotzdem die Compliance im Griff.