Warum euer DLP-Report grün ist, obwohl Mitarbeiter Daten in KI-Tools kopieren

Eure DLP-Policies schlagen zuverlässig an, wenn vertrauliche Dateien das Unternehmen verlassen. Das Problem: Bei der Nutzung von KI werden oft gar keine Dateien verschickt. Inhalte werden kopiert, in Prompts eingefügt oder direkt im Browser verarbeitet – und genau dort greifen klassische DLP-Kontrollen häufig nicht.

Bildlich gesprochen: Wir sichern die Türen mit Hochsicherheitsschlössern, während die Fenster weit offen stehen.

Fast jedes Unternehmen hat Data Loss Prevention im Einsatz: meist ein oder zwei Policies in der Cloud, die den Versand gelabelter Dokumente regeln. Sie warten auf ganz bestimmte Vorgänge — eine Datei per Mail verschicken, ein Dokument nach extern teilen, etwas in einen Cloud-Speicher hochladen.

Wer mit KI arbeitet, tut nichts davon. Er markiert einen Absatz im Vertrag und setzt ihn in ein Eingabefeld. Keine Datei verlässt das Unternehmen, keine Mail geht raus, nichts wird geteilt — also schlägt auch keine dieser Regeln an. Der Inhalt ist trotzdem draußen, in einem Werkzeug, das niemand freigegeben hat. Das ist Schatten-KI. Sichtbar wäre der Vorgang auf dem Gerät, bevor der Text es verlässt, und dort ist bei den meisten nichts konfiguriert.

Der häufigste Datenabfluss durch KI ist damit kein KI-Problem. Es ist ein Mensch, der etwas kopiert, und eine Kontrolle, die dort nicht hinsieht.

Der übliche Stand: kaum DLP-Policies in der Cloud

Die meisten Data-Loss-Prevention-Installationen, die ich sehe, bestehen aus zwei Dingen: einem Satz Sensitivity Labels und ein bis zwei Policies in der Cloud, die den Versand bestimmter Label nach außen regeln. Sie laufen, sie melden gelegentlich etwas, und sie erzeugen das Gefühl, dass das Thema abgedeckt ist.

Aber das Gefühl trügt. Die existierenden Policies warten auf klar umrissene Vorgänge:

• eine Datei geht per Mail hinaus

• ein Dokument wird nach extern geteilt

• seltener, wenn etwas in einen Cloud-Speicher geladen wird

Wer einen Absatz aus einem Vertrag markiert und in ein Eingabefeld setzt, löst keinen dieser Vorgänge aus. Die Datei bleibt liegen, wo sie liegt — und ihr Inhalt landet trotzdem in einer KI, die außerhalb der Kontrolle des Unternehmens agiert.

Zur Serie: 

Diese Reihe geht eine Landkarte mit zwei Achsen ab. 

Die erste fragt, wer die Daten bewegt: der Mensch, die eigene KI oder fremde KI. 

Die zweite fragt, wer die Data Loss Prevention betreibt: der Mensch allein, KI als Unterstützung, oder KI, die unter Anleitung selbst eingreift. 

Sechs Felder, und jede Frage rund um DLP und KI wohnt in genau einem davon. Dieser Artikel steht im ersten Feld: Ein Mensch bewegt die Daten, Menschen führen das Werkzeug. → Rahmenartikel

Warum Cloud-DLP den Weg in Schatten-KI nicht sieht

Erste Achse: Der Mensch bewegt die Daten.

Der Mensch tippt, er kopiert, er lädt hoch. Das ist der klassische Fall, und er ist durch KI nicht verschwunden — er hat neue Wege bekommen.

Diese neuen Wege sieht eine Cloud-Policy nicht, und das ist kein Konfigurationsfehler. Sie ist dafür gebaut, den Versand zu prüfen: eine Datei, die per Mail hinausgeht, ein Dokument, das nach extern geteilt wird. Was jemand in ein KI-Werkzeug eingibt, ist kein Versand. Es ist Text in einem Eingabefeld.

Sichtbar würde dieser Vorgang an einer anderen Stelle — auf dem Gerät oder im Browser, auf jeden Fall bevor der Text das Gerät verlässt. Und auch dort nur unter einer Bedingung: wenn dort Inhaltserkennung eingerichtet ist.

Das Label hilft hier nicht aus. Ein Label hängt an einer Datei. Was in ein Eingabefeld eingesetzt wird, ist Text ohne Datei — und Microsoft sagt das für den Einfügevorgang ausdrücklich: Geprüft wird der Inhalt, der eingefügt wird, unabhängig davon, wie die Quelldatei klassifiziert ist.

Erkannt werden muss er also aus sich selbst heraus. Und dafür braucht man Sensitive Information Types: Muster, die jemand definiert hat.

Es fehlen also zwei Dinge: der Ort und die Erkennung. Labels sind bei den meisten vorhanden. Inhaltserkennung praktisch nie.

Und daraus folgt etwas Unbequemes für jeden Data-Security-Bericht, den ihr euch anseht: Aus einem grünen DLP-Dashboard lässt sich nicht schließen, dass kein Data Leakage geschieht. Denn was nicht protokolliert wird, kann auch nicht gemeldet werden.

Wie viel wirklich in Schatten-KI abfließt — Zahlen aus drei Studien

Belastbare Zahlen zu diesem Feld sind rar, und die verfügbaren stammen von Anbietern, die etwas dazu verkaufen. Das gehört dazugesagt. Drei taugen trotzdem als Größenordnung — weil sie offenlegen, wie sie entstanden sind, oder weil sie messen statt zu fragen.

Veeam hat im April 2026 durch Censuswide tausend IT-, Daten- und Security-Entscheider aus Unternehmen ab 500 Mitarbeitern befragen lassen. In Deutschland geben 81 Prozent an, dass automatisierte KI-Workflows ohne vollständige Kontrolle mit sensiblen Unternehmensdaten umgehen. 79 Prozent berichten von Schatten-Workflows, die ihre IT-Teams nicht nachverfolgen können. Das sind Selbsteinschätzungen, keine Messungen — aber es sind die Selbsteinschätzungen derjenigen, die es wissen müssten.

LayerX misst statt zu fragen, über Browser-Telemetrie aus Kundenumgebungen. Dort heißt es: „On average, employees make 14 pastes/day into non-corporate accounts, and at least 3 of those paste activities contain sensitive data." Der Bericht nennt allerdings weder Stichprobe noch Erhebungszeitraum, und das schwächt ihn.

Netskope, ebenfalls aus Nutzungsdaten, liefert die Gegenprobe von der Seite der Regelverstöße: Im durchschnittlichen Unternehmen verstoßen drei Prozent der KI-Nutzer gegen Datenrichtlinien, zusammen 223 Mal im Monat — doppelt so viele Nutzer und doppelt so viele Vorfälle wie ein Jahr zuvor. Betroffen sind vor allem Quellcode (42 Prozent), regulierte Daten (32 Prozent) und geistiges Eigentum (16 Prozent). Wohlgemerkt: Das sind Verstöße, die eine Regel gesehen hat. Bei zwei Cloud-Policies sieht sie keinen davon.

Vierzehn Einfügungen am Tag, davon mindestens drei mit sensiblen Inhalten — pro Mitarbeiter. Rechnet das auf eure Belegschaft hoch, und ihr habt die Größenordnung, über die euer Report schweigt.

Die Wege dorthin sind überschaubar. Und für jeden gibt es eine dokumentierte Antwort, ob und womit er sich schließen lässt:

Die Spalte „Endpoint DLP“ setzt voraus, dass das Gerät in Purview onboarded ist, der verwendete Browser unterstützt wird und Inhaltserkennung eingerichtet ist. Ob sich jemand im KI-Werkzeug mit dem Firmenkonto oder privat anmeldet, spielt dabei keine Rolle. Die Kontrolle sitzt auf dem Gerät.

Der Schutz in Edge for Business geht einen Schritt weiter. Er prüft auch den abgeschickten Prompt, bevor er die KI-Seite erreicht. Das funktioniert auf verwalteten Windows-Geräten für eine von Microsoft unterstützte Liste von KI-Werkzeugen und kostet zusätzlich. Die Netzwerkebene erfasst weitere Wege, darunter Desktop-Anwendungen, braucht dafür aber eine SASE-Integration.

Damit lässt sich ein großer Teil der technischen Lücken schließen. Geräte müssen onboarded, unterstützte Browser durchgesetzt und die entsprechenden Kontrollen aktiviert werden. Das ist Projektarbeit mit einem absehbaren Ende.

Die Inhaltserkennung ist es nicht.

Blockiert wird nämlich nicht „Text“, sondern sensibler Inhalt. Und was sensibel ist, weiß das System nur, wenn es diesen Inhalt erkennen kann. Für Kreditkartennummern gibt es fertige Muster. Für euren Vertragsentwurf, eure Preisliste oder den Namen des Produkts, das nächstes Jahr kommt, gibt es sie nicht automatisch.

Jemand muss festlegen, was davon schützenswert ist und woran es sich erkennen lässt. Die Regel muss den Vertragsentwurf finden, ohne bei jeder Mittagsverabredung anzuschlagen. Das ist keine einmalige Konfiguration. Es ist eine laufende Entscheidung darüber, was in eurem Haus vertraulich ist und wie zuverlässig eine technische Kontrolle es erkennen kann.

Endpoint DLP ausbauen heißt Alarme ausbauen

Zweite Achse: Der Mensch allein betreibt die Data Loss Prevention.

Bis hierher ging es darum, wer die Daten bewegt. Jetzt zur anderen Hälfte dieses Feldes: wer die Kontrollen führt.

Das ist in fast jedem Unternehmen, das ich sehe, eine Person oder ein sehr kleines Team. Solange nur wenige Policies laufen, bleibt auch die Zahl der Treffer überschaubar. Das ändert sich, sobald die Erkennung besser wird.

Denn eine Policy, die mehr sieht, erzeugt nicht einfach mehr Schutz. Sie erzeugt zunächst mehr Fälle, über die jemand entscheiden muss. Ein Treffer kann ein echter Datenabfluss sein. Er kann genauso gut zu einem erlaubten Geschäftsprozess gehören, eine Ausnahme brauchen oder zeigen, dass die Regel zu breit gefasst ist.

Aus zwanzig Treffern werden deshalb zwanzig Entscheidungen. Jemand muss sie ansehen, einordnen und bei Bedarf die Regel anpassen. Kommen neue Datentypen, Anwendungen und Ausnahmen hinzu, wächst diese Arbeit mit.

Das ist die zweite Seite besserer Erkennung: Die Arbeitslast entsteht in dem Moment, in dem die Kontrolle mehr sieht. Wer Endpoint DLP ausbaut, ohne den Betrieb mit auszubauen, bekommt deshalb irgendwann genau das Problem zurück, das er lösen wollte. Es gibt mehr Regeln und mehr Alarme, aber niemanden, der sie noch zuverlässig bearbeitet.

Deshalb ist die Zahl der Policies kein guter Maßstab für den Reifegrad einer DLP. Entscheidend ist, wie viele davon jemand tatsächlich betreiben kann: Treffer prüfen, Ausnahmen beurteilen, Regeln nachschärfen und regelmäßig feststellen, ob sie noch das tun, wofür sie gebaut wurden.

Was ein leerer Report wirklich sagt

Die Frage dieses Feldes war: Warum meldet euer DLP nichts, während täglich Inhalte in Schatten-KI fließen? Eure Regeln stehen dort, wo Dateien verschickt werden. Der Abfluss passiert dort, wo Text eingegeben wird. Ein leerer Report ist kein Befund über eure Daten. Er ist ein Befund über den Standort eurer Kontrolle.

Jede Kontrolle hat eine Grenze, und die lässt sich nachlesen. Endpoint DLP kann eingefügten Text in den von Microsoft unterstützten Browser-/Betriebssystem-Kombinationen prüfen. Der Schutz in Edge sieht den abgeschickten Prompt auf dem verwalteten Gerät. Die Netzwerkebene sieht die Desktop-Anwendung. Das Foto vom Bildschirm sieht keine von ihnen.

Wer diese Grenzen kennt, baut seine IT dementsprechend. Auf dem verwalteten Gerät läuft der Browser, den die Kontrolle sieht, und die anderen lassen sich dort nicht öffnen. An Unternehmensdaten kommt nur, wer sich anmeldet, und nur von einem Gerät, das ihr kennt. Die Arbeit findet dann dort statt, wo eine Regel hinreicht — nicht, weil es jemand zugesagt hat, sondern weil es keinen anderen Weg gibt.

Ein Rest bleibt. Hundert Prozent Schutz gibt es nicht, und wer sie verspricht, kennt sich mit den Grenzen der Data Security schlichtweg nciht aus. Entscheidend ist, ob ihr euren Rest kennt — oder ob ein leerer Report ihn euch als Sicherheit ausreicht.

Die nächsten Felder: eigene KI, fremde KI, KI im Betrieb

Dieses Feld der Karte ist der Nullpunkt: ein Mensch bewegt die Daten, Menschen führen das Werkzeug. Nach rechts kommen neue Verursacher dazu — die eigene KI, dann die fremde. Nach unten neue Betriebsformen: KI, die bei der Data Loss Prevention hilft, und KI, die unter Anleitung selbst eingreift.

Im nächse Blogartikel schauen wir ein Feld weiter.