Schatten-KI erkennen mit Microsoft Purview DSPM

Die Freigabe von Microsoft 365 Copilot oder eines internen Claude-Zugangs beantwortet nur die halbe Frage, die IT-Verantwortliche eigentlich haben: Was passiert mit den KI-Tools, die niemand freigegeben hat? Mitarbeitende öffnen ChatGPT, Claude.ai oder ein Dutzend weiterer Dienste über den privaten Zugang im Browser, weil es schneller geht als jede offizielle Beschaffung - und laden dabei Kundendaten, interne Dokumente oder Quellcode in Systeme hoch, die außerhalb jeder Vereinbarung mit dem Unternehmen liegen. Das ist Schatten-KI, und sie unterscheidet sich von klassischer Schatten-IT vor allem darin, wie leicht sie entsteht: kein Setup, keine Installation, nur ein Tab im Browser.

Für M365-Admins ist das zunächst ein Sichtbarkeitsproblem, bevor es ein Richtlinienproblem wird. Sie können nur eindämmen, was Sie messen - und die Signale, die Schatten-KI im Tenant hinterlässt, liegen an mehreren Stellen gleichzeitig verstreut: im Netzwerk, auf dem Endgerät, im Browser. Microsoft bündelt genau diese Signale in Microsoft Purview Data Security Posture Management (DSPM), inzwischen in einer neu aufgestellten, vereinheitlichten Fassung. Dieser Artikel zeigt, wie Sie Schatten-KI mit Purview DSPM erkennen, welche Signale dafür im Detail nötig sind, und was für den Umstieg von der bisherigen, separaten „DSPM for AI”-Lösung wichtig ist.

Was Schatten-KI technisch von freigegebener KI-Nutzung unterscheidet

Der Unterschied zwischen freigegebener und nicht freigegebener KI-Nutzung ist aus Sicht des Tenants kein graduelles, sondern ein strukturelles Problem. Bei Microsoft 365 Copilot, Copilot Studio oder Entra-registrierten KI-Apps läuft die Interaktion innerhalb der Microsoft-365-Vertrauensgrenze: Auditing zeichnet Prompts und Antworten auf, Sensitivitätslabels greifen, DLP kann Copilot als Policy-Standort direkt adressieren. Die Sichtbarkeit ist von Anfang an eingebaut, nicht nachgerüstet.

Bei einem privaten ChatGPT- oder Claude.ai-Zugang im Browser gibt es diese eingebaute Sichtbarkeit nicht. Die Anwendung liegt außerhalb des Tenants, es gibt keinen Audit-Log-Eintrag, der in Purview landet, und ohne zusätzliche Instrumentierung sieht die IT-Abteilung schlicht nichts. Genau deshalb braucht die Erkennung von Schatten-KI andere Werkzeuge als die Steuerung freigegebener KI: nicht Policies für einen bekannten, kooperativen Endpunkt, sondern Signale, die auf dem Weg zwischen Nutzer und fremdem Dienst abgegriffen werden - im Browser, auf dem Gerät, im Netzwerkverkehr.

Wichtig für die Einordnung: „unautorisiert” bedeutet in diesem Kontext nicht zwangsläufig böswillig. Die meisten Fälle sind schlicht produktive Abkürzungen von Mitarbeitenden, die eine Aufgabe schneller lösen wollen. Das ändert nichts an der Risikolage - sensible Daten verlassen den Tenant ohne Vertragsgrundlage, ohne Löschzusagen, ohne die Kontrolle, die eine Auftragsverarbeitung normalerweise bietet, wie wir sie an anderer Stelle für den DSGVO-konformen Betrieb von KI-Modellen im Detail einordnen - , ist aber für den Ton der internen Kommunikation relevant, wenn Sie Ergebnisse aus DSPM später auswerten.

Die drei Ebenen, auf denen Schatten-KI überhaupt sichtbar wird

Bevor eine einzelne Purview-Policy greift, braucht es Rohdaten. Microsoft beschreibt für die Erkennung nicht freigegebener KI-Nutzung im Kern drei unterschiedliche Signalquellen, die sich ergänzen:

Netzwerksignale. Microsoft Defender for Cloud Apps erkennt über die Cloud-App-Discovery-Funktion, welche Cloud- und KI-Dienste aus dem Netzwerk heraus aufgerufen werden - Grundlage sind unter anderem Netzwerk-Logs, die über Microsoft Defender for Endpoint auf verwalteten Geräten gesammelt werden. Diese Ebene beantwortet primär „welche Dienste werden überhaupt genutzt”, unabhängig davon, ob dabei sensible Daten übertragen wurden.

Endpunktsignale. Auf dem Gerät selbst liefern Microsoft Defender Vulnerability Management und die in Intune erfassten „Discovered Apps” ein zweites Bild - welche Anwendungen tatsächlich installiert oder ausgeführt werden.

Datensignale. Die dritte und für Purview DSPM zentrale Ebene ist die inhaltliche: Was wurde tatsächlich in ein KI-Tool eingegeben, und enthielt es sensible Informationen? Dafür braucht es zusätzliche Instrumentierung - konkret die Microsoft-Purview-Browsererweiterung und das Onboarding der Geräte an Microsoft Purview. Beides ist Voraussetzung dafür, dass Purview erkennt, wenn jemand beispielsweise Kreditkartennummern in ChatGPT einfügt, und dass Endpoint-DLP-Richtlinien greifen können, um zu warnen oder zu blockieren.

Für den Browser kommt eine vierte Voraussetzung dazu: eine Edge-Konfigurationsrichtlinie, die die Purview-Integration in Microsoft Edge aktiviert. Ohne sie bleibt die Sichtbarkeit in Chrome oder Firefox beschränkt auf das, was die Browsererweiterung selbst beitragen kann.

Diese Ebenen laufen bei Microsoft nicht in einem einzigen Produkt zusammen, sondern werden von Purview DSPM aggregiert und in Berichten, im Activity Explorer und in vorkonfigurierten Policies nutzbar gemacht. DSPM ist also keine eigenständige Sensorik, sondern die Auswertungs- und Steuerungsebene über Signalen, die an anderer Stelle bereits erhoben werden müssen.

Die zweite Halbwahrheit: nicht jede sichtbare KI-Nutzung wird gleich behandelt

Wie viel Detail Sie über eine KI-Interaktion sehen, hängt vom App-Typ ab. Der Activity Explorer kennt vier Ereignistypen: AI interaction (Interaktion inklusive Prompt und Antwort, sofern erfasst), AI website visit (reiner Seitenbesuch), DLP rule match und Sensitive info types (erkannte sensible Informationen).

Entscheidend ist der Unterschied bei „AI interaction”: Bei nicht verwalteten KI-Apps im Browser - dem typischen Schatten-KI-Fall - werden laut Microsoft ausschließlich Text-Prompts erfasst, nicht die Antworten. Bei Microsoft 365 Copilot benötigt dieses Ereignis eingeschaltetes Auditing; bei Nicht-Copilot-KI-Apps braucht es zusätzlich eine Collection Policy mit aktivierter Inhaltserfassung, damit Prompt und Antwort überhaupt gespeichert werden. Ohne diese Policy sieht der Activity Explorer nur, dass eine Interaktion stattfand, nicht ihren Inhalt.

Für Schatten-KI heißt das: Die Standard-Sichtbarkeit ist eher „wer war wann auf welcher KI-Site” als „was genau wurde eingegeben”. Erst die im nächsten Abschnitt beschriebenen Policies bringen die inhaltliche Tiefe für eine belastbare Risikobewertung.

Wie Purview DSPM Schatten-KI-Nutzung konkret aufdeckt: Reports und Policies

Im Microsoft-Purview-Portal (purview.microsoft.com) finden Sie die Lösung unter Solutions › DSPM. Nach dem ersten Einrichten schlägt Purview eine Reihe vorkonfigurierter „One-Click Policies” vor, die genau auf die Entdeckung nicht freigegebener KI-Nutzung zielen. Die für Schatten-KI relevantesten:

Eine DLP-Richtlinie, die sensible Inhalte erkennt, die in Edge, Chrome oder Firefox in KI-Sites eingefügt oder hochgeladen werden - zunächst nur im Audit-Modus, also ohne zu blockieren.
Eine Insider-Risk-Management-Richtlinie, die schlicht erkennt, wenn jemand über den Browser eine KI-Site besucht - die Grundlage für die reine Nutzungssichtbarkeit.
Eine weitere Insider-Risk-Richtlinie, die riskante Prompts und Antworten in Microsoft 365 Copilot, Agents und anderen generativen KI-Apps erkennt und in eine Risikobewertung pro Nutzer einfließen lässt.
Eine Collection Policy, die sensible Informationen erkennt, die über Netzwerkintegrationen (Secure Access Service Edge/SASE oder Security Service Edge/SSE) mit KI-Apps geteilt werden - Voraussetzung dafür ist, dass Sie mindestens eine SASE- oder SSE-Integration in den DLP-Einstellungen manuell hinterlegt haben. Die Tiefe der Erkennung hängt hier vom jeweiligen Netzwerkpartner ab.
Eine Collection Policy für Enterprise-KI-Apps wie ChatGPT Enterprise oder über Entra beziehungsweise Microsoft Foundry angebundene Anwendungen, die Prompts und Antworten für Compliance-Zwecke erfasst.

Die Ergebnisse landen in Reports (gruppiert nach „Copilot experiences and agents”, „Enterprise AI apps” und „Other AI apps”) und im Activity Explorer, jeweils mit mindestens einem Tag Vorlauf, bis erste Daten sichtbar werden. Ergänzend läuft automatisch eine wöchentliche Risikobewertung für die 100 meistgenutzten SharePoint-Websites, um Überteilung zu identifizieren - sie misst nicht direkt Schatten-KI-Nutzung, adressiert aber dieselbe Grundfrage: welche Daten überhaupt in Reichweite generativer KI liegen.

Für die Breite der Erkennung bei Drittanbieter-KI ist eine öffentlich gepflegte, laufend erweiterte Liste unterstützter Domains maßgeblich. Sie deckt marktübliche Dienste breit ab - von ChatGPT und Google Gemini über Perplexity bis zu Claude.ai (Stand: August 2026). Ein Abgleich mit den tatsächlich in Ihrem Netzwerk beobachteten Domains lohnt sich trotzdem: Nischenwerkzeuge, die (noch) nicht auf der Liste stehen, tauchen nicht in den DSPM-Auswertungen auf, auch wenn Defender for Cloud Apps sie über die allgemeine Cloud-App-Discovery bereits als genutzt meldet.

Von Melden zu Blockieren: Kombination mit Defender for Cloud Apps

Die oben beschriebenen DSPM-Policies liefern in ihrer Grundkonfiguration vor allem Sichtbarkeit - mehrere davon laufen bewusst im reinen Audit- oder Testmodus, um zunächst ein Bild der Lage zu bekommen, bevor irgendetwas blockiert wird. Für Organisationen, die von Melden zu tatsächlichem Blockieren nicht freigegebener KI-Domains übergehen wollen, sind zwei Bausteine relevant, die über DSPM selbst hinausgehen.

Der erste ist die Sanktionierung in Microsoft Defender for Cloud Apps: Jede über Cloud-App-Discovery erkannte Anwendung lässt sich dort als sanktioniert, nicht sanktioniert oder unbewertet markieren. Wird eine App als nicht sanktioniert eingestuft, setzt der Netzwerkschutz von Microsoft Defender for Endpoint diese Sperre auf verwalteten Geräten durch - die vollständige Durchsetzung über alle Endpunkte kann laut Microsoft bis zu drei Stunden dauern. Das ist der Mechanismus, mit dem sich eine riskante KI-Domain tenantweit sperren lässt, statt sie nur in Reports auftauchen zu sehen.

Der zweite Baustein sind die vorkonfigurierten DLP-Blockrichtlinien aus DSPM selbst: eine Richtlinie, die über Adaptive Protection risikoreiche Nutzer beim Einfügen sensibler Informationen in KI-Sites mit Override-Option blockiert, und eine strengere Variante, die Prompts an KI-Apps in Microsoft Edge für Nutzer mit erhöhtem, mittlerem oder geringem Risiko grundsätzlich unterbindet - einschließlich ungeschützter, nicht verwalteter Browser. Ergänzend rollt Microsoft (Stand: Juli 2026, in Preview) eine Integration mit Microsoft Entra Global Secure Access aus, die DLP-Kontrollen auf Netzwerkebene erweitert und Prompts bereits am Netzwerk abfängt, statt nur im Edge-Browser.

Praktisch heißt das: Nutzen Sie DSPM zunächst, um zu verstehen, welche KI-Dienste genutzt werden. Klassifizieren Sie die relevanten Apps in Defender for Cloud Apps als sanktioniert oder nicht sanktioniert. Aktivieren Sie erst danach gezielt die Blockrichtlinien - pauschales Blockieren ohne vorherige Sichtbarkeit erzeugt erfahrungsgemäß vor allem Umgehungsversuche über private Geräte, nicht weniger Schatten-KI-Nutzung.

Lizenzvoraussetzungen: was Sie tatsächlich brauchen

Die Lizenzlage folgt dem allgemeinen Purview-Muster: Die Kernfunktionen sind über Microsoft 365 E5, A5 oder G5 abgedeckt, alternativ über Compliance- und Information-Protection-Add-ons zu kleineren Grundlizenzen (etwa E3 plus Microsoft Purview Suite). Für Microsoft 365 Business Premium gibt es zusätzlich ein separates Purview-Suite-Add-on, gedeckelt auf maximal 300 Sitze.

Zwei Besonderheiten sollten Sie vorab einplanen: Erstens benötigen Nutzer, deren Copilot-Interaktionen erfasst werden sollen, zusätzlich eine Microsoft-365-Copilot-Lizenz - DSPM ersetzt diese nicht. Zweitens läuft die Erkennung bei KI-Apps jenseits von Copilot und Microsoft Facilitator über ein Pay-as-you-go-Abrechnungsmodell, dessen Kosten vom Umfang der erfassten Interaktionen abhängen. Für Browser-DLP auf nicht verwaltete Apps in Edge for Business gilt laut Microsofts Service-Beschreibung ebenfalls Pay-as-you-go, während das Schützen von Entra-registrierten (verwalteten) Apps in Edge bereits in einer regulären E5-Lizenz enthalten ist. Klären Sie diesen Unterschied früh mit dem Lizenzverantwortlichen, statt ihn erst nach der Pilotphase zu entdecken.

DSPM for AI (classic): Was abgelöst wird - und wann (Stand: unklar)

Der zeitkritische Anlass für diesen Artikel ist eine Neuaufstellung, die Microsoft 2026 bei Purview DSPM vollzogen hat. Bislang gab es zwei getrennte Lösungen im Purview-Portal: Data Security Posture Management (DSPM) für allgemeine Datenrisiken und DSPM for AI speziell für KI-Interaktionen - letztere ursprünglich als „Microsoft Purview AI Hub” gestartet. Seit Mai 2026 sind beide zu einer einzigen, allgemein verfügbaren (GA) Lösung zusammengeführt, die im Portal unter Solutions › DSPM erscheint. Die bisherigen getrennten Versionen laufen unter den neuen Bezeichnungen DSPM (classic) und DSPM for AI (classic) parallel weiter.

Was sich inhaltlich ändert: Die neue DSPM erweitert die Abdeckung über Microsoft 365 hinaus auf Drittanbieter-SaaS- und IaaS-Plattformen wie Google Cloud Platform, Snowflake und Databricks (über Partnerlösungen wie Varonis, Cyera, BigID oder OneTrust), führt eine eigene „AI observability”-Ansicht ein, die Agenten-Aktivitäten wie Überteilung, Exfiltration und ungewöhnliche Zugriffsmuster verfolgt, und ordnet die Arbeitsoberfläche neu um „Data security objectives” - geführte Workflows für konkrete Sicherheitsziele statt einer Liste einzelner Lösungen. Der Funktionsumfang der klassischen Version (Policies, Reports, Aktivitätsdaten) ist laut Microsoft vollständig übernommen; ein separater Migrationsschritt für Daten und Konfigurationen ist nicht nötig, da beide Versionen bis zur Ablösung parallel auf denselben Daten arbeiten.

Für bestehende Policies heißt das: Alles, was Sie über DSPM for AI (classic) eingerichtet haben, bleibt aktiv nutzbar. Neue Funktionen kommen aber ausschließlich in der aktuellen Version hinzu - die klassische Version läuft damit im reinen Wartungsmodus. Ein Beispiel macht den Unterschied konkret: Der neue, auf natürlicher Sprache basierende Data Security Posture Agent zur intentionsbasierten Suche nach sensiblen Daten ist ausschließlich in der aktuellen Version verfügbar und wird nicht in DSPM (classic) nachgerüstet.

Zum konkreten Abschalttermin der klassischen Version ist an dieser Stelle Sorgfalt geboten. Mehrere Fachblogs kursieren mit dem Datum 30. September 2026 als Stichtag, zu dem DSPM (classic) und DSPM for AI (classic) endgültig abgeschaltet werden. Bei der direkten Prüfung gegen die einschlägigen Microsoft-Learn-Seiten (learn.microsoft.com/purview/dspm-for-ai, .../dspm-for-ai-considerations, .../data-security-posture-management-considerations, .../whats-new sowie die zugehörige Ankündigung im Message Center, MC1191257) und Stand der letzten Aktualisierung dieser Seiten im Juni bzw. August 2026 findet sich dieses Datum jedoch nicht als expliziter, von Microsoft selbst genannter Abschalttermin. Die offiziellen Quellen formulieren durchgängig nur, dass die klassischen Versionen „ersetzt” wurden, in Wartungsmodus laufen und keine neuen Funktionen mehr erhalten - ohne ein festes Enddatum zu nennen. Auch ein zweiter, unabhängiger Abgleich bestätigt das: Der beim Microsoft-365-Message-Center-Spiegel mc.merill.net/message/MC1191257 hinterlegte Ankündigungstext (veröffentlicht 1. Dezember 2025, zuletzt aktualisiert 10. April 2026) enthält ausschließlich die Zusicherung „Customers will continue to have access to the current DSPM (classic) and DSPM for AI (classic) experiences” - kein Datum. Selbst unter den kursierenden Sekundärquellen gehen die Angaben auseinander: Ein Teil (z. B. thepurviewpractitioner.com, sharegate.com) nennt explizit kein Abschaltdatum, ein anderer Teil zitiert den 30. September 2026 unter Berufung auf einen angeblichen In-Produkt-Hinweis im Purview-Portal - eine Quelle, die sich von außen nicht nachprüfen lässt. Ein offizielles, von Microsoft selbst dokumentiertes Abschaltdatum für DSPM (classic) und DSPM for AI (classic) ist damit nicht bestätigt; die kursierende Angabe „30. September 2026” bleibt unbelegt und widersprüchlich zitiert (Stand: August 2026). Wer eine eigene Migrationsplanung darauf aufbauen will, sollte den Termin direkt gegen learn.microsoft.com/purview/whats-new und das Microsoft 365 Message Center im eigenen Tenant prüfen, statt sich auf Sekundärquellen zu stützen.

Für die Praxis ändert diese Unsicherheit wenig an der Handlungsempfehlung: Neue DSPM-Konfigurationen sollten Sie ab sofort in der aktuellen, vereinheitlichten Version anlegen, weil dort die Weiterentwicklung stattfindet und weil ein fester Abschalttermin für die klassische Version erkennbar aussteht, auch wenn er noch nicht zweifelsfrei belegt ist. Wer heute noch ausschließlich mit DSPM for AI (classic) arbeitet, verliert dadurch nichts an bestehender Funktionalität - verpasst aber alles, was seit Mai 2026 an neuen Fähigkeiten hinzugekommen ist, und sollte den Wechsel nicht auf den letzten Drücker verschieben.

Praktischer Einstieg: die ersten Schritte im Purview-Portal

Wer heute mit der Erkennung von Schatten-KI beginnt, sollte sich nicht an der Frage aufhalten, ob DSPM (classic) oder die aktuelle Version der richtige Startpunkt ist - die Antwort ist eindeutig die aktuelle Version. Eine sinnvolle Reihenfolge für den Einstieg:

Voraussetzungen schaffen: Purview-Auditing aktivieren, Geräte an Microsoft Purview onboarden, die Purview-Browsererweiterung an Windows-Geräte verteilen, eine Edge-Konfigurationsrichtlinie für die Purview-Integration setzen.
Sichtbarkeit zuerst: Die vorkonfigurierten Erkennungs-Policies (nicht Blockierung) aktivieren - insbesondere die Insider-Risk-Richtlinie für KI-Site-Besuche und die DLP-Richtlinie im Audit-Modus.
Mindestens 24 bis 48 Stunden warten, bis erste Daten in Reports und Activity Explorer erscheinen, und die Ergebnisse mit den Fachbereichen abgleichen.
Abgleich mit Defender for Cloud Apps: welche über Cloud-App-Discovery sichtbaren KI-Dienste tauchen in DSPM auf, welche nicht - und warum.
Erst danach gezielt blockieren: einzelne KI-Domains in Defender for Cloud Apps als nicht sanktioniert markieren, DLP-Blockrichtlinien für die risikoreichsten Fälle aktivieren.

Diese Reihenfolge ist bewusst konservativ. Schatten-KI-Nutzung ist in den meisten Organisationen zunächst ein Kommunikationsproblem - Mitarbeitende wissen oft nicht, dass ein freigegebenes Alternativangebot existiert. Technische Blockaden ohne begleitende Kommunikation verschieben das Problem eher auf private Geräte, wo Sie überhaupt keine Sichtbarkeit mehr haben. Wo bereits ein freigegebenes KI-Angebot wie Claude in Microsoft 365 Copilot existiert, sollte die interne Kommunikation genau diesen Unterschied klarmachen.

Ein Hinweis zur Mitbestimmung: Die systematische Erfassung von Nutzeraktivitäten, wie sie DSPM-Policies mit Insider-Risk-Management-Bezug liefern, kann je nach Ausgestaltung mitbestimmungspflichtig sein. Dieser Artikel ersetzt keine arbeitsrechtliche Beratung - klären Sie die konkrete Ausgestaltung Ihrer Policies frühzeitig mit den zuständigen internen Stellen, bevor Sie sie unternehmensweit ausrollen.

Häufige Fragen zu Schatten-KI und Purview DSPM

Was ist der Unterschied zwischen Schatten-KI und freigegebener KI-Nutzung aus Sicht von Purview?

Freigegebene KI-Nutzung - etwa Microsoft 365 Copilot - liegt innerhalb der Microsoft-365-Vertrauensgrenze, mit eingebautem Auditing und direkter DLP-Anbindung. Schatten-KI läuft über private Zugänge zu externen Diensten außerhalb des Tenants und wird nur sichtbar, wenn zusätzliche Signale - Browsererweiterung, Geräte-Onboarding, Netzwerkerkennung - aktiv eingerichtet sind.

Reicht Microsoft Purview DSPM allein, um Schatten-KI zu erkennen?

Nein. DSPM ist die Auswertungs- und Policy-Ebene über Signalen, die von Microsoft Defender for Cloud Apps (Netzwerk), Microsoft Defender for Endpoint und Intune (Endpunkt) sowie der Purview-Browsererweiterung (Inhalt) geliefert werden. Ohne diese vorgelagerten Komponenten bleibt die Sichtbarkeit in DSPM lückenhaft.

Was ist der Unterschied zwischen DSPM (classic), DSPM for AI (classic) und der aktuellen DSPM?

DSPM (classic) und DSPM for AI (classic) waren zwei getrennte Lösungen für allgemeine Datenrisiken beziehungsweise KI-spezifische Risiken. Seit Mai 2026 sind beide in einer einzigen, allgemein verfügbaren DSPM-Lösung zusammengeführt, die zusätzlich Drittanbieter-Plattformen abdeckt und neue Funktionen wie AI observability und den Data Security Posture Agent mitbringt. Die klassischen Versionen laufen parallel weiter, erhalten aber keine neuen Funktionen mehr.

Wann wird DSPM for AI (classic) abgeschaltet?

Ein von Microsoft selbst in der aktuellen Learn-Dokumentation oder im Message-Center-Spiegel genanntes, festes Abschaltdatum ließ sich zum Recherchezeitpunkt (20.08.2026) nicht verifizieren. Sekundärquellen widersprechen sich hier sogar gegenseitig: Manche nennen explizit kein Datum, andere den 30. September 2026 unter Verweis auf einen von außen nicht prüfbaren In-Produkt-Hinweis. Dieses Datum sollte vor einer eigenen Zeitplanung direkt gegen learn.microsoft.com/purview/whats-new, das Microsoft 365 Message Center und idealerweise die Hinweise im eigenen Purview-Portal geprüft werden, da sich Retirement-Termine kurzfristig ändern oder erst später offiziell bestätigt werden können.

Kann ich mit Purview DSPM unautorisierte KI-Domains direkt blockieren, oder nur melden?

Melden und Blockieren sind zwei getrennte Schritte. DSPM selbst liefert primär Sichtbarkeit über Reports, Activity Explorer und Erkennungs-Policies im Audit-Modus. Tatsächliches Blockieren einzelner KI-Domains läuft über die Sanktionierung in Microsoft Defender for Cloud Apps in Kombination mit Netzwerkschutz durch Defender for Endpoint, ergänzt um die vorkonfigurierten DLP-Blockrichtlinien aus DSPM für Microsoft Edge.

Fazit

Schatten-KI verschwindet nicht dadurch, dass Sie Microsoft 365 Copilot oder Claude offiziell freigeben - sie läuft in den meisten Tenants unverändert weiter, solange niemand hinschaut. Purview DSPM macht diesen blinden Fleck sichtbar, aber nur, wenn die vorgelagerten Signalquellen - Browsererweiterung, Geräte-Onboarding, Defender for Cloud Apps - tatsächlich eingerichtet sind; die Lösung selbst erzeugt keine neuen Daten, sie ordnet vorhandene ein. Wer heute einsteigt, sollte direkt in der aktuellen, vereinheitlichten DSPM-Version arbeiten statt in der klassischen, weil dort die Weiterentwicklung stattfindet - unabhängig davon, wann genau die klassische Version abgeschaltet wird. Und wer von reiner Sichtbarkeit zu aktivem Blockieren übergehen will, sollte diesen Schritt bewusst nach der Beobachtungsphase setzen, nicht davor. Sichtbarkeit schaffen ist dabei nur die eine Hälfte der Aufgabe: Genauso wichtig ist, warum eine kontrolliert freigegebene KI-Strategie Schatten-KI von vornherein seltener macht - und damit, welche Lizenzstrategie Sie für diese freigegebenen Angebote wählen.

Quellen (Stand: August 2026, Abruf 20.08.2026):