Viele Compliance-Projekte starten mit der falschen Frage. Projektleiter und Admins fragen: „Wir haben doch schon eine DLP-Richtlinie für Copilot, wozu brauchen wir jetzt noch Sensitivity Labels?“ Die kurze Antwort lautet: Eine Data-Loss-Prevention-Richtlinie ohne funktionierende Labels greift weitgehend ins Leere.
Beide Mechanismen ergänzen sich, erfüllen aber unterschiedliche Aufgaben. Sensitivity Labels klassifizieren Inhalte. DLP-Regeln hingegen lesen diese Klassifizierung und entscheiden dann, was mit dem Dokument geschehen darf. Fehlt die Klassifizierung, bleibt die Durchsetzung wirkungslos. Genau das entscheidet am Ende darüber, ob Microsoft Copilot vertrauliche Dokumente als Quelle ignoriert oder sensible Daten in Antworten ausgibt.
Klassifizierung vor Durchsetzung
Ein Sensitivity Label ordnet einem Inhalt eine Vertraulichkeitsstufe zu, etwa „Öffentlich“, „Intern“, „Vertraulich“ oder „Streng vertraulich“. DLP-Richtlinien greifen auf diese Kennzeichnung zurück. Erst auf dieser Basis entscheidet das System, ob ein Nutzer die Datei per E-Mail versenden, extern teilen oder ob Copilot sie verarbeiten darf.
In der Praxis vertauschen viele Teams die Reihenfolge. Unter Zeitdruck definieren sie komplexe DLP-Regeln für Copilot, bevor die Informationsarchitektur steht. Wer DLP-Bedingungen an Labels knüpft, braucht Inhalte, die diese Labels auch tragen. Die Konfiguration der Labels gehört deshalb immer an den Anfang.
Labels mit Copilot-Bezug einrichten
Die Einrichtung läuft zentral über das Microsoft Purview-Portal. Der Weg führt im Purview-Portal über „Microsoft Azure Information Protection -> Vertraulichkeitsbezeichnungen“. Dort erstellen Sie eine neue Bezeichnung oder bearbeiten eine bestehende, zum Beispiel „Streng vertraulich“.
Im Abschnitt „Geltungsbereich“ aktivieren Sie nach Bedarf „Dateien“, „E-Mails“ oder „Besprechungen“. Einen separaten Schalter für Copilot gibt es an dieser Stelle nicht. Copilot respektiert automatisch die Schutzeinstellungen des zugewiesenen Labels sowie alle verknüpften DLP-Regeln.
Die gewünschten Schutzeinstellungen legen Sie im Anschnitt „Elemente“ auf der Seite „Schutzeinstellungen für die ausgewählten Elementtypen auswählen“ fest, sofern Sie den Haken „Zugriff steuern“ setzen. Zu den konfigurierbaren Einschränkungen gehören insbesondere „Verschlüsselung“ und die damit verbundenen Nutzungsrechte oder „Wasserzeichen“.
Die in der Abbildung konfigurierbare Zugriffssteuerung steuert übrigens die RMS-Verschlüsselung (Azure Rights Mangement) und die Rechte. Für Coppilot würde das bedeuten: Wenn das Label selbst verschlüsselt und der Benutzer (bzw. der Dienst) kein EXTRACT-Recht hat, kann Copilot den Inhalt nicht verarbeiten.
Anschließend veröffentlichen Sie das Label mit Hilfe einer „Bezeichnungsrichtlinie“ für die gewünschten Benutzergruppen. In dieser legen Sie fest, ob das System beim Erstellen neuer Dokumente eine Standardbezeichnung erzwingt. Nach dem Veröffentlichen prüfen Sie in Word, Excel, PowerPoint oder SharePoint, ob das Label in der Auswahl erscheint und die Schutzrechte bei Testdokumenten greifen.
Automatische Bezeichnung statt manueller Disziplin
Der sicherste Weg, ein Label-Konzept scheitern zu lassen, ist das Vertrauen in die Sorgfalt der Anwender. Mitarbeiter stufen Dokumente selten konsequent manuell ein. Zeitdruck, Unwissenheit oder schlichtes Vergessen führen dazu, dass ein Großteil der Dateien unbeschriftet bleibt.
Für Copilot stellt das ein konkretes Risiko dar. Unbeschriftete Dokumente stuft das System als normale, uneingeschränkte Inhalte ein, selbst wenn darin hochsensible Daten stecken.
Im Microsoft Purview-Portal gibt es unter „Azure Information Protection“ drei voneinander zu unterscheidende Mechanismen:
- Richtlinien zur Veröffentlichung („Bezeichnungsrichtlinien“)
Diese Richtlinien machen die Sensitivity Labels für Benutzer und Gruppen sichtbar. Mit ihrer Hilfe legen Sie fest, „wer“ welche Labels in den Office-Anwendungen sieht und „welche Policy-Einstellungen“ gelten (zum Beispiel Standardbezeichnung oder Pflicht zur Kennzeichnung). Ohne eine Richtlinie zur Veröffentlichung erscheinen die Labels bei den Anwendern nicht. Diese Richtlinie ist die Voraussetzung für alle weiteren Schritte.
Eine Bezeichnungsrichtlinie ist die Basis für alles weitere, also auch 2. und 3. - Clientseitige automatische Bezeichnung (direkt im Label)
Diese Einstellung wird „innerhalb des Sensitivity Labels“ selbst konfiguriert (Bereich „Automatisches Bezeichnen von Dateien und E-Mails“). Sie greift nur, während ein Benutzer in Word, Excel, PowerPoint oder Outlook arbeitet. Das System kann das Label empfehlen oder automatisch anwenden. Bestehende Dateien, die niemand öffnet, bleiben unberührt - Dienstseitige automatische Bezeichnung (Richtlinien für automatische Bezeichnungen)
Hierbei handelt es sich um „“ im Portal unter „… Richtlinien → Automatische Bezeichnung“. Diese laufen im Hintergrund und kennzeichnen Dateien in SharePoint und OneDrive sowie E-Mails in Exchange, auch den bestehenden Datenbestand. Vor dem produktiven Einschalten lassen sie sich im Simulationsmodus prüfen. Das ist der skalierbarere Mechanismus und für den Schutz im Zusammenhang mit Copilot der wichtigere.
Den genauen Zusammenhang illustriert die folgende Tabelle:
| Mechanismus | Wo konfiguriert | Was macht er? |
| Richtlinie zur Veröffentlichung | Richtlinien → Richtlinien zur Veröffentlichung | Macht Labels für Benutzer sichtbar |
| Clientseitige Auto-Bezeichnung | Direkt im Sensitivity Label | Kennzeichnet Inhalte während der Bearbeitung |
| Dienstseitige Auto-Bezeichnung | Richtlinien → Automatische Bezeichnung | Kennzeichnet ruhende und neue Inhalte im Hintergrund |
Darüber hinaus gilt:
- 1 + 2 (Veröffentlichung + clientseitige Auto-Bezeichnung im Label)
→ Labels sind sichtbar und werden während der Bearbeitung empfohlen oder gesetzt. Bestehende Dateien bleiben weitgehend unberührt. - 1 + 3 (Veröffentlichung + dienstseitige Auto-Bezeichnung)
→ Labels sind sichtbar und der ruhende Datenbestand (SharePoint, OneDrive, Exchange) wird systematisch nachklassifiziert. Das ist der stärkere und für Copilot relevantere Weg. - 1 + 2 + 3
→ Die Kombination aus beiden Auto-Mechanismen. Das ist in den meisten Projekten die beste Lösung: dienstseitig für den Bestand, clientseitig als zusätzliche Absicherung bei der täglichen Arbeit.
Das manuelle Anwenden von Sensitivity Labels ist bereits mit Microsoft 365 E3 möglich. Die automatische Bezeichnung (sowohl clientseitig als auch dienstseitig) erfordert in der Regel eine der folgenden Lizenzen:
- Microsoft 365 E5 / A5 / G5
- Microsoft 365 E5 Compliance
- Microsoft 365 E5 Information Protection & Governance
- oder die älteren Äquivalente (EMS E5 / Azure Information Protection Plan 2)
Ohne eine dieser höheren Lizenzen stehen die Optionen für die automatische Bezeichnung im Portal entweder nicht zur Verfügung oder lassen sich nicht speichern.
Nutzen Sie dienstseitige Richtlinien für automatische Bezeichnungen als Hauptmechanismus, um den Datenbestand systematisch zu erfassen. Die clientseitige Einstellung im Label kann ergänzend eingesetzt werden. Beide Formen der automatischen Bezeichnung setzen voraus, dass das Label über eine Richtlinie zur Veröffentlichung bereitgestellt wurde. Testen Sie dienstseitige Richtlinien immer zuerst im Simulationsmodus.
Bestehende Taxonomie erweitern statt neu erfinden
Viele Unternehmen arbeiten seit Jahren mit einer festen Label-Struktur aus vier oder fünf Grundstufen. Ein häufiger Fehler beim Copilot-Rollout besteht darin, ein paralleles Label-System nur für KI-Anwendungsfälle aufzubauen. Das verwirrt Anwender und verdoppelt den Verwaltungsaufwand.
Prüfen Sie stattdessen die vorhandene Taxonomie. Oft reicht eine gezielte Erweiterung. Ein Sub-Label wie „Nicht für KI-Verarbeitung“, das auf der bestehenden Stufe „Streng vertraulich“ aufbaut, fügt sich nahtlos in den gewohnten Arbeitsablauf ein. Die Nutzer sehen weiterhin die vertrauten Bezeichnungen. Die zusätzliche Einschränkung für Copilot bleibt im Hintergrund und wirkt über die verknüpften DLP-Regeln.
Die Container-Falle: Team-Labels schützen keine Dateien
Ein weit verbreiteter Irrtum betrifft SharePoint-Websites und Teams-Kanäle. Ein Sensitivity Label auf einer solchen „Container“-Ebene steuert den externen Zugriff, die Geräterichtlinien oder die Möglichkeit, Gäste hinzuzufügen. Es vererbt seine Eigenschaften jedoch nicht automatisch auf die darin abgelegten Dateien. Liegt ein unbeschriftetes Dokument auf einer als „Vertraulich“ eingestuften SharePoint-Website, greifen dateibasierte DLP-Regeln für Copilot nicht. Für einen wirksamen Schutz kombinieren Sie beide Ebenen: Container-Labels schaffen den strukturellen Rahmen, Dateibezeichnungen sorgen für die eigentliche inhaltliche Klassifizierung. Nur so greifen die Regeln, die Copilot davon abhalten, sensible Inhalte in Antworten zu verwenden.
Typische Fehler und wie Sie sie vermeiden
In Projekten zeigen sich häufig die gleichen Stolperfallen. Teams aktivieren DLP-Regeln für Copilot, ohne zuvor die automatische Bezeichnung produktiv zu schalten. Das Ergebnis: Die Regeln finden kaum Treffer, weil die meisten Dateien keine Labels tragen. Andere Organisationen setzen auf manuelle Kennzeichnung und wundern sich Monate später über ungeschützte Altbestände.
Ein weiterer häufiger Fehler liegt in der zu groben Granularität. Wer nur drei Labels definiert und alle sensiblen Inhalte in „Vertraulich“ packt, verliert die Möglichkeit, differenziert zu steuern. Copilot braucht klare Signale. Je präziser die Klassifizierung, desto gezielter greifen die nachgelagerten Schutzmechanismen. Prüfen Sie außerdem die Verknüpfung mit „Restricted Content Discovery“ im SharePoint Admin Center (siehe Artikel „Daten vor KI-Crawlern“) schützen. Diese Funktion erlaubt es, Inhalte mit bestimmten Labels komplett von der Copilot-Suche auszuschließen. Sie ergänzt die DLP-Regeln und bietet eine zusätzliche Schutzschicht, ohne dass Nutzer die Dateien löschen oder verschieben müssen.
Praxis-Checkliste für den Rollout
Vor dem produktiven Einsatz von Copilot sollten folgende Punkte geklärt sein:
- Die Label-Taxonomie ist final und mit den Fachbereichen abgestimmt.
- Automatische Bezeichnungsrichtlinien laufen mindestens im Simulationsmodus und zeigen realistische Trefferquoten.
- DLP-Regeln für Copilot referenzieren die Labels und sind getestet.
- Container-Labels und Dateilabels sind sauber getrennt und ergänzen sich.
- Testbenutzer mit unterschiedlichen Rollen können die Labels in den Office-Anwendungen sehen und anwenden.
- Die Dokumentation beschreibt, welche Label-Stufe welche Auswirkungen auf Copilot hat.
Fazit
Sensitivity Labels bilden das Fundament für jede Sicherheitsarchitektur rund um Microsoft Copilot. Wer Durchsetzungsregeln ohne funktionierende Klassifizierung einrichtet, baut auf Sand. Verlassen Sie sich nicht auf die manuelle Disziplin der Nutzer. Setzen Sie auf automatische Bezeichnung, erweitern Sie die bestehende Taxonomie intelligent und unterscheiden Sie klar zwischen Container- und Dateilabels. Nur dann bleibt der Datenbestand auch beim Einsatz von Copilot abgesichert.
Die technische Konfiguration ist überschaubar. Der eigentliche Aufwand liegt in der sauberen Informationsarchitektur und der konsequenten Anwendung. Wer diesen Teil überspringt, riskiert, dass Copilot genau die Inhalte sieht, die eigentlich geschützt bleiben sollten.