Purview: Neue Data Loss Prevention-Regeln für DSGVO

Consulting Briefing · 24.06.2026 · boddenberg.de

Executive Summary

Kurz für die Eiligen, die diesen Absatz gleich durch ihren eigenen Copilot zusammenfassen lassen wollen – und genau das ist ab sofort das Thema: Microsoft hat Purview Data Loss Prevention (DLP) in den vergangenen Monaten spürbar umgebaut. DLP ist nicht mehr nur der Türsteher, der aufpasst, dass keine Excel mit 40.000 Kundendatensätzen per Mail nach draußen wandert. DLP sitzt jetzt direkt vor dem Sprachmodell. Tippt ein Mitarbeiter eine IBAN, eine Passnummer oder eine ganze Gehaltsliste in einen Copilot-Prompt, kann die Regel zuschlagen, bevor das Modell überhaupt antwortet.

Für den Datenschutz ist das ein echter Hebel: Die DSGVO-relevanten Daten – Namen, Adressen, Gesundheitsdaten, Steuer-IDs – lassen sich über Sensitive Information Types und Vertraulichkeitslabel erkennen und an genau den Stellen stoppen, an denen sie sonst unkontrolliert in KI-Antworten, Web-Suchen oder auf USB-Sticks landen. Der Haken: Ein Teil der Funktionen ist allgemein verfügbar (GA), ein anderer steckt noch in der Preview. Wer Preview-Features für DSGVO-Konformität als gesetzt verkauft, baut sein Compliance-Haus auf Sand. Dieses Briefing trennt sauber, was du heute scharf schalten darfst und was vorerst nur fürs Testlabor taugt.

Worum geht es im Detail?

Data Loss Prevention in Microsoft Purview funktioniert seit jeher nach einem einfachen Dreisatz: erkennen, bewerten, handeln. Erkannt wird über Sensitive Information Types (SITs) – das sind Mustererkenner für Kreditkartennummern, IBANs, Sozialversicherungsnummern, Ausweisdaten und Hunderte weiterer Datentypen. Dazu kommen Vertraulichkeitslabel, also die manuell oder automatisch vergebenen Stempel wie „Intern“, „Vertraulich“ oder „Personal“. Bewertet wird über Richtlinien, die diese Treffer mit Bedingungen verknüpfen. Und gehandelt wird mit Aktionen: blockieren, warnen, verschlüsseln, protokollieren.

Das Neue ist der Ort, an dem das passiert. Microsoft hat 2025 und 2026 einen eigenen Richtlinien-Speicherort „Microsoft 365 Copilot und Copilot Chat“ eingeführt. Damit kann eine DLP-Regel den Prompt selbst prüfen – also den Text, den ein Mensch in das Eingabefeld tippt. Enthält dieser Text einen konfigurierten SIT, antwortet Copilot schlicht nicht. Der Prompt wird weder ans Modell geschickt noch für eine Web-Suche verwendet. Der Nutzer bekommt eine Meldung, dass seine Anfrage geblockt wurde, weil sie Informationen enthält, die die Organisation für Copilot gesperrt hat. Das ist ein fundamentaler Unterschied zur klassischen DLP-Welt, die immer erst reagiert hat, wenn Daten schon irgendwo gespeichert oder versendet wurden.

Abbildung 1: Der DLP-Gate – jeder Copilot-Prompt durchläuft drei Prüfungen, bevor das Sprachmodell überhaupt antwortet.

Konkret gibt es mehrere Bausteine, und ihr Reifegrad ist unterschiedlich. Allgemein verfügbar ist das Ausschließen von Dateien und Mails mit bestimmten Vertraulichkeitslabeln aus Copilot-Antworten: Eine Datei mit dem Label „Streng vertraulich“ taucht dann zwar noch als Quellenzitat auf, ihr Inhalt fließt aber nicht in die generierte Zusammenfassung ein. Ebenfalls produktiv nutzbar ist die Web-Such-Bremse: Steckt ein SIT im Prompt, unterbindet Copilot die externe Web-Suche und erdet die Antwort nur noch auf internen Microsoft-365-Quellen.

In der Preview – und das ist die entscheidende Fußnote – stecken zwei Funktionen, die in jeder DSGVO-Präsentation als Highlight auftauchen: das Blockieren von SITs direkt im Prompt und das Ausschließen externer E-Mails als Erdungsquelle. Letzteres ist clever gedacht: Die Regel prüft nur die Absenderdomäne gegen die akzeptierten Domänen deines Tenants, nicht den Mailtext. So verhindert sie, dass eine eingeschleuste externe Mail mit versteckten Anweisungen zur Prompt-Injection wird – ein realer Angriffsweg, kein theoretisches Schreckgespenst.

Abbildung 2: Drei Ebenen, an denen DLP für DSGVO greift – Inhalt, Bezeichnung und Kanal werden getrennt geregelt.

Drumherum hat Microsoft die DLP-Klassiker weiter geschärft. Endpoint-DLP – also der Schutz direkt auf dem Gerät gegen Kopieren auf USB, Drucken oder Hochladen – lässt sich seit Juni 2026 über Device-Scoping gezielt auf bestimmte Gerätegruppen begrenzen. Beispiel: Die Finanzabteilung darf eine Regel nur dann auslösen, wenn sie von einem Windows-Gerät aus arbeitet, nicht vom privaten Mac. Die Gerätegruppen kommen dynamisch aus Entra ID. Für SharePoint und OneDrive kam zudem die Möglichkeit hinzu, den Zugriff auf sensible Dateien für einzelne externe Domänen oder einzelne externe Nutzer zu blockieren – nicht mehr nur pauschal für „alle Externen“.

Was sind Chancen? Was sind Risiken?

Die Chance ist offensichtlich und trotzdem unterschätzt: Du bekommst zum ersten Mal eine Kontrolle, die greift, bevor der Mensch den Fehler macht. Die klassische DSGVO-Sorge bei generativer KI lautet ja: „Was, wenn ein Mitarbeiter die komplette Bewerberliste in den Chat kippt und sich eine Zusammenfassung bauen lässt?“ Mit einer prompt-seitigen DLP-Regel ist genau dieser Reflex abgefangen. Der Prompt mit der Passnummer läuft auf, der Nutzer bekommt einen Hinweis, das Modell sieht die Daten nie. Das ist nicht nur Compliance-Kosmetik, das ist gelebte Datenminimierung nach Artikel 5 DSGVO.

Zweite Chance: Du steuerst die Erdung. Dass Copilot bei sensiblen Prompts keine externe Web-Suche mehr auslöst, schließt eine Lücke, über die sonst Bruchstücke interner Daten an Suchanbieter wandern könnten. Und das Label-basierte Ausschließen sorgt dafür, dass deine sauber gepflegte Klassifizierung endlich auch im KI-Kontext etwas bewirkt – wer jahrelang Label vergeben hat, ohne dass sie viel taten, erntet hier zum ersten Mal sichtbar.

Damit zu den Risiken, und davon gibt es eine ganze Handvoll. Das größte ist das falsche Sicherheitsgefühl. Eine DLP-Regel ist nur so gut wie die SITs und Label, auf denen sie sitzt. SITs arbeiten mit Mustern und Prüfsummen – eine deutsche Steuer-ID erkennt das System zuverlässig, eine kreativ umformatierte Kundennummer oder ein Klartext-Geheimnis im Fließtext eher nicht. Wer glaubt, mit drei Standard-SITs sei die DSGVO erledigt, täuscht sich. Dazu kommt das Thema False Positives: Zu scharf gestellt, blockiert die Regel auch die harmlose Anfrage des Vertrieblers, der nur eine Telefonnummer formatieren wollte. Dann lernt die Organisation in Rekordzeit, Copilot zu meiden – und du hast ein teures Lizenzpaket zur Zierde gekauft.

Zweites Risiko: die Lücken im Kleingedruckten. DLP prüft den eingetippten Prompt-Text – aber nicht den Inhalt von Dateien, die ein Nutzer direkt in den Prompt hochlädt. Wer also die sensible Tabelle nicht abtippt, sondern als Datei anhängt, umgeht die Prompt-Regel. Auch Kalendereinladungen werden nicht abgedeckt, und Änderungen an einer Richtlinie können bis zu vier Stunden brauchen, bis sie in der Copilot-Erfahrung greifen. Drittes Risiko: die Lizenz- und Rechtefrage. Die Copilot-DLP-Funktionen leben im Microsoft-Purview-Kosmos, der üblicherweise an die höherwertigen Pläne geknüpft ist. Wer ohne passende Lizenz plant, baut eine Architektur, die er nicht aktivieren darf.

Was müssen wir jetzt schon vorbereiten?

Die gute Nachricht zuerst: Du musst nicht bei null anfangen. Wer schon Vertraulichkeitslabel und SITs im Einsatz hat, sitzt auf dem halben Fundament. Die Vorbereitung läuft in vier Schritten, und keiner davon ist Raketenwissenschaft.

Erstens: Inventur der sensiblen Daten. Bevor du eine Regel baust, musst du wissen, welche DSGVO-relevanten Datentypen überhaupt in deinem Tenant kursieren. Data Security Posture Management und der Aktivitäts-Explorer zeigen, wo welche SITs auftauchen. Erst diese Landkarte verrät, welche SITs du wirklich brauchst und welche nur Lärm erzeugen. Zweitens: die Label-Taxonomie prüfen. Wenn deine Organisation noch mit fünf widersprüchlichen Labeln und keiner klaren Regel arbeitet, wird die Copilot-Integration das Chaos nur sichtbar machen. Ein sauberes Label „Personal“ oder „Streng vertraulich“ ist die Voraussetzung dafür, dass der Ausschluss aus Copilot-Antworten überhaupt funktioniert.

Abbildung 3: Reifegrad-Timeline – was heute GA ist, was Preview bleibt und was frisch dazugekommen ist.

Drittens: Rollen und Rechte klären. Eine DLP-Richtlinie für den Copilot-Speicherort darf nur bearbeiten, wer eine passende Rolle trägt – etwa Purview Data Security AI Admin, Compliance-Administrator oder die Information-Protection-Rollen. Wichtig für den Datenschutzbeauftragten: Die AI-Admin-Rolle darf Richtlinien bearbeiten, sieht aber bewusst nicht die Prompts und Antworten der Nutzer. Diese Trennung von Steuerung und Einblick ist genau das, was eine saubere Funktionstrennung verlangt – dokumentiere sie, sie ist ein Geschenk fürs DSFA-Kapitel „Zugriffskonzept“.

Viertens: im Simulationsmodus starten. Jede neue Regel zuerst nur beobachten lassen, nicht blockieren. Purview unterstützt für den Copilot-Speicherort ausdrücklich den Simulationsmodus samt Warnungen und Benachrichtigungen. Lass die Regel zwei bis vier Wochen mitlaufen, schau dir die Treffer an, justiere die SIT-Auswahl und die Schwellenwerte – und erst wenn die False-Positive-Quote erträglich ist, schaltest du auf „blockieren“. Plane dabei ein, dass Richtlinienänderungen bis zu vier Stunden zum Durchschlagen brauchen; wer im Minutentakt testet, misst nur die eigene Geduld.

Und ein letzter Hinweis für die Roadmap: Behalte die Reifegrade im Blick. Was heute Preview ist, kann in drei Monaten GA sein – dann darfst und solltest du es nachziehen. Wer einmal im Quartal die „What's new“-Liste von Purview durchgeht, vermeidet, dass die eigene DLP-Architektur an der Realität vorbeiläuft. Datenschutz mit KI ist kein Projekt mit Enddatum, sondern ein Abo – leider eines, das man nicht kündigen kann.

Häufig gestellte Fragen

Brauche ich eine teure E5-Lizenz, um DLP für Copilot zu nutzen?

Die DLP-Funktionen rund um Copilot leben im Microsoft-Purview-Umfeld, das üblicherweise an die höherwertigen Compliance- beziehungsweise E5-Pläne oder passende Add-ons gebunden ist. Prüfe deine konkrete Kombination aus Microsoft-365-Plan und Copilot-Add-on vor der Planung – die Architektur darf nicht von einer Funktion abhängen, die du am Ende gar nicht aktivieren darfst.

Blockiert DLP auch sensible Daten in Dateien, die ich in den Copilot-Prompt hochlade?

Nein. DLP prüft den Text, den du direkt in das Prompt-Feld tippst, nicht den Inhalt einer Datei, die du an den Prompt anhängst. Hochgeladene Dateien werden in diesem Schritt nicht auf sensible Daten ausgewertet – das ist eine bewusst einzuplanende Lücke, die du über andere Kontrollen wie Label und Endpoint-DLP abfangen musst.

Was ist der Unterschied zwischen Sensitive Information Types und Vertraulichkeitslabeln?

Sensitive Information Types erkennen Inhalte automatisch über Muster und Prüfsummen, etwa eine IBAN oder eine Steuer-ID. Vertraulichkeitslabel sind manuell oder per Automatik vergebene Stempel wie „Personal“ oder „Streng vertraulich“. DLP kann beide als Bedingung nutzen – aber nicht beide in derselben Regel; dafür legst du je eine Regel in derselben Richtlinie an.

Wie lange dauert es, bis eine geänderte DLP-Regel in Copilot greift?

Änderungen an einer DLP-Richtlinie für den Copilot-Speicherort können bis zu vier Stunden brauchen, bis sie in der Copilot-Erfahrung wirksam werden. Plane diese Verzögerung in Tests und Rollouts ein und miss den Effekt einer Änderung nicht schon nach fünf Minuten.

Sieht der Compliance-Admin die Prompts und Antworten der Mitarbeiter?

Die Rolle Purview Data Security AI Admin darf die Richtlinien bearbeiten und KI-Inhalte im Posture Management einsehen, hat aber keinen Zugriff auf die konkreten Prompts und Antworten einzelner Nutzer. Diese Trennung von Steuerung und Einblick solltest du im Zugriffskonzept deiner Datenschutz-Folgenabschätzung ausdrücklich dokumentieren.