AI DLP vs. klassisches DLP: Warum dein DLP Prompts an lokale Modelle nicht sieht

Kurz gesagt

• Klassisches DLP wurde für Dateien, E-Mails und Uploads gebaut. Es erkennt Muster in Anhängen und Dateitransfers.
• Sensible Daten verlassen Unternehmen heute über andere Kanäle: Prompts in Chat-Tools, Kontextfenster von Coding-Assistenten, Tool-Calls von Agents und lokale Modelle, die gar keinen Netzwerkverkehr erzeugen.
• AI DLP prüft genau diese Kanäle, und zwar auf dem Gerät, bevor die Daten verschlüsselt werden oder den Rechner verlassen.
• Die beiden Ansätze ersetzen sich nicht. Klassisches DLP bleibt für Dateien zuständig, AI DLP übernimmt die AI-Interaktionen.

Was ist AI DLP?

AI DLP ist Data Loss Prevention für AI-Interaktionen. Es inspiziert Prompts, Modellantworten und Agent-Aktionen auf personenbezogene Daten, Secrets und vertrauliche Inhalte und setzt Regeln durch, bevor die Daten ein AI-System erreichen: schwärzen, blockieren oder mit Audit-Eintrag durchlassen.

Der Unterschied zum klassischen DLP liegt weniger in der Erkennung als im Ort und im Format. Klassisches DLP sitzt am Netzwerkrand oder im E-Mail-Gateway und versteht Dateien. AI DLP sitzt auf dem Endpoint und versteht Gespräche.

Wo klassisches DLP blind ist

Die typische Entdeckung sieht so aus: Ein Security-Team hat DLP-Regeln für Kundendaten, testet ChatGPT im Browser, fügt eine Kundenliste in den Prompt ein, und nichts passiert. Kein Alarm, kein Block, kein Log. Drei Gründe:

Prompts sind keine Dateien. DLP-Engines parsen Dateiformate: PDF, DOCX, XLSX, Bilder per OCR. Ein Prompt ist ein JSON-Feld in einem API-Aufruf, oft in mehrere Nachrichten zerlegt, manchmal als Stream. Die Antwort des Modells kommt als Server-Sent Events oder über WebSockets in Bruchstücken zurück. Klassische Engines haben dafür keinen Parser.

Verschlüsselung verbirgt den Inhalt. AI-API-Aufrufe sind TLS-verschlüsselt. Ein Netzwerk-DLP ohne TLS-Inspektion sieht Bytes und ein Ziel, etwa api.openai.com. Mit TLS-Inspektion sieht es den Inhalt, aber nur bei Apps, die kein Certificate Pinning nutzen, und nur für Traffic, der tatsächlich über den Proxy läuft.

Lokale Modelle erzeugen keinen Traffic. Wer Ollama, LM Studio oder ein in die IDE eingebautes Modell nutzt, schickt den Prompt an einen Prozess auf demselben Rechner. Es gibt keinen Netzwerkverkehr, den ein Gateway prüfen könnte. Dasselbe gilt für Agents, die lokal Dateien lesen und erst das Ergebnis nach draußen schicken.

Was AI DLP anders macht

Der wichtigste Punkt ist die Reaktion. Klassisches DLP kann eine E-Mail zurückhalten, aber einen Prompt nicht reparieren. AI DLP ersetzt die Kundennummer durch einen Platzhalter und lässt den Rest des Prompts durch. Die Mitarbeiterin bekommt ihre Antwort, die Kundennummer bleibt im Haus.

Wie die Erkennung auf dem Gerät funktioniert

Patronus Protect läuft als kleine Software auf dem Firmenrechner und sitzt im Netzwerkpfad, bevor Daten verschlüsselt werden. Die Erkennung von AI-Traffic ist verhaltensbasiert und unabhängig vom Anbieter: Ein neues Chat-Tool oder eine unbekannte API wird am Muster erkannt, nicht an einer Domain-Liste. Wie das technisch geht, beschreibt der Beitrag zur Erkennung über WebSockets, SSE und gRPC.

Für die Inhaltsprüfung laufen lokale Modelle aus unserem Model Zoo: Orca Sonar klassifiziert den Dokumenttyp (Vertrag, HR-Unterlage, Quellcode, Finanzbericht), GLiNER-basierte Modelle extrahieren personenbezogene Entitäten, deterministische Regeln erkennen Secrets wie API-Keys und Tokens. Das Ergebnis liegt in Millisekunden vor, ohne dass der Prompt das Gerät verlässt.

Die Policy entscheidet je Datentyp und Anwendung. Beispiele aus der Praxis:

• Kundendaten in ChatGPT: schwärzen, Rest durchlassen
• API-Keys in einem beliebigen Prompt: blockieren
• Quellcode an einen nicht freigegebenen Anbieter: blockieren, an den freigegebenen erlauben
• Interne Dokumente an ein lokales Modell: erlauben, aber protokollieren

Woran du AI DLP erkennst, das den Namen verdient

Wenn du Lösungen vergleichst, helfen fünf Fragen:

1. Sieht es lokale Modelle? Wenn die Antwort "über den Proxy" lautet, ist die Antwort nein.
2. Kann es schwärzen statt nur blockieren? Blockieren allein führt dazu, dass Mitarbeiter auf private Geräte ausweichen.
3. Versteht es Streams? Antworten kommen als SSE oder WebSocket-Frames. Wer erst am Ende prüft, hat die Daten schon durchgelassen.
4. Prüft es Agent-Aktionen? Ein Coding-Agent, der eine .env-Datei liest und den Inhalt in einen API-Call packt, ist der häufigste Abflussweg im Entwicklungsumfeld.
5. Wo landen die Prompts zur Prüfung? Wenn sie zur Analyse in eine Cloud gehen, hast du das Datenschutzproblem nur verschoben.

Was das für die Architektur bedeutet

Klassisches DLP bleibt. Dateien, E-Mail-Anhänge und Uploads brauchen weiter die vorhandenen Regeln. AI DLP ergänzt den Kanal, der in den letzten zwei Jahren entstanden ist, und der einzige Ort, an dem beide Welten zusammenkommen, ist das Gerät. Dort entsteht der Prompt, dort läuft der Agent, dort liegt das lokale Modell.

Wie Patronus das umsetzt, steht auf der Seite zur AI-DLP-Lösung. In der Live-Demo siehst du an einem Beispiel, was beim Anbieter ankommt und was geschwärzt wird.

Quellen und Einordnung

• Die Beschreibung von klassischem DLP folgt den üblichen Produktkategorien (Netzwerk-DLP, E-Mail-DLP, Endpoint-DLP für Dateitransfers). Herstellerabhängige Funktionen wurden bewusst nicht bewertet.
• Zu Agent-Tool-Calls und MCP: MCP, die Angriffsfläche, die niemand absichert.
• Stand: 7. September 2026.