Im Sommer 2026 veröffentlichte Cyberhaven seinen AI Adoption & Risk Report mit einer Zahl, die in vielen deutschen IT-Abteilungen für Unruhe sorgte: 39,7 Prozent aller Interaktionen mit KI-Tools enthalten mittlerweile sensible Daten, Tendenz steigend. Im Schnitt gibt jeder Beschäftigte alle drei Tage vertrauliche Informationen in ein KI-Tool ein, oft ohne es zu merken. Wer als IT- oder Sicherheitsverantwortlicher fragt, wie viele Mitarbeitende gerade Kundendaten, Quellcode oder interne Finanzzahlen in ChatGPT, Gemini oder Claude einfügen, bekommt selten eine belastbare Antwort. Genau diese Lücke schließt Data Loss Prevention für KI-Werkzeuge.
Diese Anleitung zeigt in zwölf Schritten, wie du ein eigenes DLP-Gateway für KI-Chatbots aufbaust, das ausgehenden Datenverkehr zu öffentlichen KI-Diensten überwacht, sensible Inhalte erkennt und wahlweise blockiert oder anonymisiert. Das Projekt basiert vollständig auf freier Software: dem Proxy-Framework mitmproxy und der von Microsoft entwickelten Open-Source-Bibliothek Presidio zur Erkennung personenbezogener und vertraulicher Daten. Am Ende hast du ein lauffähiges System, das du per Docker ausrollen und an deine eigene Firmenumgebung anpassen kannst. Plane für den kompletten Aufbau etwa 90 Minuten ein, für das reine Testen des Beispielprojekts reichen 30 Minuten.
Kommerzielle Lösungen wie Microsoft Purview DSPM for AI gehen in großen Konzernen oft einen ähnlichen Weg, kombiniert mit zentraler Identitätsverwaltung und Compliance-Reporting. Für kleinere Teams, Agenturen oder Mittelständler ohne eigenes Sicherheitsbudget bietet der selbst betriebene Ansatz aus dieser Anleitung jedoch einen Einstieg ohne Lizenzkosten. Die Technik lässt sich später problemlos um kommerzielle Bausteine ergänzen, etwa wenn zentrales Reporting für die Geschäftsführung gefragt ist.
Der Aufbau folgt einer klaren Logik: Zuerst richtest du die technische Umgebung ein, dann bringst du den Proxy zum Laufen, anschließend verbindest du ihn mit der Erkennungslogik von Presidio, und zum Schluss rollst du das fertige Gateway produktiv aus. Jeder Schritt funktioniert auch einzeln nachrüstbar, falls in deinem Unternehmen bereits Teile einer Lösung existieren.
Diese Anleitung richtet sich an IT-Administratoren und Sicherheitsverantwortliche mit Grundkenntnissen in Python und Netzwerktechnik, nicht an Einsteiger ohne jede Vorerfahrung. Du solltest wissen, was ein Reverse Proxy tut und wie Zertifikatsketten grundsätzlich funktionieren. Was diese Anleitung bewusst nicht leistet: Sie ersetzt keine vollständige Data-Loss-Prevention-Strategie für klassische Kanäle wie E-Mail oder Dateiserver, und sie ist kein Freibrief dafür, Mitarbeiterkommunikation ohne rechtliche Prüfung lückenlos zu überwachen. Das Gateway ist ein technischer Baustein, der in eine größere Governance-Struktur eingebettet werden muss.
Warum Data Loss Prevention für KI-Tools 2026 zur Pflichtaufgabe wird
Der Anteil sensibler Daten in KI-Interaktionen ist laut Cyberhaven in den letzten Jahren kontinuierlich gewachsen: von 10,7 Prozent im Jahr 2023 über 27,4 Prozent im Jahr 2024 auf 34,8 Prozent im April 2025. Am häufigsten landen dabei Quellcode (18,7 Prozent), Forschungs- und Entwicklungsdaten (17,1 Prozent) sowie Vertriebs- und Marketingdaten (10,7 Prozent) in den Prompt-Fenstern öffentlicher Chatbots. Klassische Data-Loss-Prevention-Systeme wurden nie dafür gebaut, Prompt-Text oder Datei-Uploads in Echtzeit auf solche Inhalte zu prüfen, sie überwachen E-Mail-Anhänge, USB-Sticks und Druckaufträge, nicht aber ein Texteingabefeld im Browser.
Dazu kommt ein zweites Problem: Laut Cyberhaven laufen 32,3 Prozent der ChatGPT-Nutzung und 24,9 Prozent der Gemini-Nutzung über private Accounts statt über freigegebene Unternehmenskonten. Zentrale Identitätsverwaltung, Single Sign-on und unternehmensweite DLP-Richtlinien greifen bei einem privaten Account grundsätzlich nicht, weil der Anbieter diesen Account nicht als Teil der Unternehmensumgebung kennt. Ein Mitarbeitender, der aus Bequemlichkeit sein privates Gemini-Konto nutzt, umgeht damit jede Kontrolle, die das Unternehmen für den offiziellen Account eingerichtet hat.
Wie real das Risiko ist, zeigte der Fall DeepSeek im Januar 2025: Das Sicherheitsunternehmen Wiz Research entdeckte eine öffentlich erreichbare ClickHouse-Datenbank von DeepSeek, komplett ohne Authentifizierung. Sie enthielt über eine Million Logzeilen mit Chatverläufen, API-Keys und Backend-Metadaten, zugänglich über eine einfache Weboberfläche, über die sich sogar beliebige SQL-Abfragen ausführen ließen. Wer vertrauliche Daten in einen Chatbot eingibt, verlässt sich darauf, dass der Anbieter seine eigene Infrastruktur sauber absichert, eine Annahme, die sich in diesem Fall als falsch erwies.
Auch große, etablierte Anbieter sind vor Fehlern nicht gefeit. Für 2026 wurde ein Vorfall bei Meta beschrieben, bei dem ein interner KI-Agent eine fehlerhafte technische Empfehlung ausgab. Ein Mitarbeiter setzte den Vorschlag um, wodurch sensible Unternehmens- und Nutzerdaten für rund zwei Stunden für unberechtigte interne Entwickler einsehbar waren. Der Fehler lag nicht bei einem externen Angreifer, sondern in der Kombination aus KI-gestützter Fehlberatung und fehlender technischer Absicherung dagegen, ein Muster, das sich mit zunehmender Verbreitung von KI-Agenten in internen Workflows eher verstärken als abschwächen dürfte.
Data Loss Prevention für KI-Tools schließt also zwei Lücken gleichzeitig: Sie macht sichtbar, welche Daten überhaupt das Unternehmen in Richtung KI-Dienst verlassen, und sie reduziert das Risiko, falls beim Anbieter selbst einmal etwas schiefgeht. Keine Lösung kann verhindern, dass ein Anbieter gehackt wird, aber sie kann verhindern, dass ein Kreditkartendatensatz oder ein Kundenname überhaupt erst dorthin gelangt.
Interessant ist dabei, warum Mitarbeitende überhaupt zu privaten Accounts oder nicht freigegebenen Tools greifen. Selten steckt böser Wille dahinter. Meistens ist die offizielle, freigegebene Lösung schlicht langsamer, umständlicher oder schränkt Funktionen ein, die das kostenlose Pendant anbietet. Eine Marketingmitarbeiterin unter Zeitdruck öffnet dann eben schnell ihr privates ChatGPT-Fenster, statt erst ein IT-Ticket für den Unternehmenszugang zu stellen. Eine funktionierende Data-Loss-Prevention-Strategie muss diesen Bequemlichkeitsfaktor mitdenken, sonst verlagert sie das Problem nur von einem Gerät auf ein anderes.
Schatten-KI in Unternehmen: Zahlen, Rechtslage und Risiken
Eine zweite Datenquelle liefert ein ähnliches Bild aus anderem Blickwinkel. Harmonic Security wertete 2025 mehr als 22 Millionen anonymisierte Unternehmens-Prompts aus und kam je nach Betrachtungszeitraum auf unterschiedliche, aber konsistent hohe Werte: In einer Stichprobe aus dem zweiten Quartal 2025 enthielten 4,37 Prozent der Prompts sensible Inhalte, über das gesamte Jahr gerechnet lag der Anteil bei bis zu 8,5 Prozent. Fast 22 Prozent der hochgeladenen Dateien enthielten laut derselben Auswertung vertrauliche Informationen. Auf ChatGPT allein entfielen dabei rund 72,6 Prozent der beobachteten sensiblen Prompts, ein Hinweis darauf, wo eine Data-Loss-Prevention-Strategie zuerst ansetzen sollte.
| Kennzahl | Wert | Quelle |
|---|---|---|
| Anteil sensibler Daten in KI-Interaktionen (2026) | 39,7 % | Cyberhaven AI Adoption & Risk Report |
| Anteil sensibler Daten in KI-Tools (April 2025, Vorjahresvergleich) | 34,8 % (2025) / 27,4 % (2024) / 10,7 % (2023) | Cyberhaven |
| ChatGPT-Nutzung über private statt Firmen-Accounts | 32,3 % | Cyberhaven |
| Gemini-Nutzung über private statt Firmen-Accounts | 24,9 % | Cyberhaven |
| Sensible Inhalte in Unternehmens-Prompts (Jahresschnitt 2025) | bis zu 8,5 % | Harmonic Security AI Usage Index |
| Hochgeladene Dateien mit sensiblen Inhalten | rund 22 % | Harmonic Security |
| Anteil sensibler Prompts, die an ChatGPT gingen | 72,6 % | Harmonic Security |
Für deutsche Unternehmen kommt die rechtliche Dimension dazu. Sobald personenbezogene Daten in einen externen KI-Dienst eingegeben werden, handelt es sich datenschutzrechtlich um eine Verarbeitung durch einen weiteren Dienstleister, mit allen Pflichten aus der DSGVO: Rechtsgrundlage, Zweckbindung, Auftragsverarbeitungsvertrag und gegebenenfalls Prüfung internationaler Datenübermittlung. Das Bundesamt für Sicherheit in der Informationstechnik hat dazu eine eigene Orientierungshilfe zum sicheren Einsatz generativer KI veröffentlicht und empfiehlt darin unter anderem, Schatten-IT durch verbindliche KI-Richtlinien zu verhindern, nur freigegebene Systeme zuzulassen und personenbezogene Daten grundsätzlich nicht ungeschützt an externe Dienste weiterzugeben.
Das zeigt auch, warum Data Loss Prevention für KI nicht allein eine IT-Entscheidung ist. In Betrieben mit Betriebsrat greift bei der systematischen Überwachung von Mitarbeiterkommunikation in aller Regel die Mitbestimmungspflicht, weil Protokolldaten über das Verhalten Einzelner Rückschlüsse zulassen. Wer ein DLP-Gateway für KI-Tools einführt, sollte Betriebsrat und Datenschutzbeauftragten von Anfang an einbinden, nicht erst, wenn das System bereits läuft.
Daneben läuft seit 2026 die stufenweise Umsetzung der EU-KI-Verordnung, die zusätzliche Pflichten für bestimmte Risikoklassen von KI-Systemen vorsieht. Diese Pflichten ersetzen eine eigene Data-Loss-Prevention-Strategie nicht, sie ergänzen sie um Fragen der Risikoklassifizierung und Dokumentation. Für die tägliche Praxis bleibt der wichtigste Hebel trotzdem der gleiche: technisch nachvollziehbar zu machen, welche Daten das Unternehmen tatsächlich in Richtung KI-Dienst verlassen, unabhängig davon, welche regulatorische Schublade am Ende greift.
Für Unternehmen, die bereits unter das neue KRITIS-Dachgesetz oder die NIS-2-Umsetzung in Deutschland fallen, ist ein dokumentiertes DLP-Konzept für KI-Tools ohnehin Teil der erwarteten technischen und organisatorischen Maßnahmen. Wer für diese Regelwerke bereits ein Risikomanagement aufgebaut hat, kann das in dieser Anleitung beschriebene Gateway als zusätzlichen, klar abgegrenzten Baustein dort einhängen, statt ein komplett neues Compliance-Projekt aufzusetzen.
Voraussetzungen für das KI-DLP-Gateway
Software und Versionen
Für das Beispielprojekt in dieser Anleitung brauchst du eine Linux-Maschine oder WSL2 unter Windows, Administratorrechte auf den Geräten, deren Datenverkehr du prüfen willst, und ein grundlegendes Verständnis von Python. Die folgende Tabelle listet alle verwendeten Komponenten.
Organisatorisch brauchst du vor dem ersten Schritt drei Dinge: eine verantwortliche Person in der IT, die später für Pflege und Updates des Gateways zuständig ist, ein kurzes Gespräch mit Betriebsrat und Datenschutzbeauftragtem über Umfang und Zweck der Protokollierung, und eine grobe Liste, welche KI-Dienste im Unternehmen überhaupt offiziell genutzt werden sollen. Fehlt dieser letzte Punkt, startest du das Projekt ohne klare Zielsetzung und läufst Gefahr, am Ende entweder zu viel oder zu wenig zu blockieren.
| Komponente | Zweck | Version |
|---|---|---|
| Python | Laufzeitumgebung für Proxy-Addon und Erkennungslogik | 3.12 oder neuer |
| mitmproxy | HTTPS-Proxy zum Abfangen des Datenverkehrs | aktuelle stabile Version |
| presidio-analyzer | Erkennung sensibler Daten (PII, Secrets) | aktuelle Version |
| presidio-anonymizer | Redigieren oder Maskieren erkannter Treffer | aktuelle Version |
| spaCy inkl. de_core_news_lg | Sprachmodell für deutsche Namenserkennung | aktuelle Version |
| Docker & Docker Compose | Produktivbetrieb und Verteilung | Docker 27.x, Compose v2 |
| SQLite | Audit-Log für geprüfte Anfragen | in Python enthalten |
Architekturüberblick
Das Gateway sitzt als expliziter Proxy zwischen den Arbeitsplatzrechnern und dem Internet. Jedes Gerät sendet seinen Datenverkehr an den Proxy, der für bekannte KI-Domains wie chatgpt.com, gemini.google.com oder claude.ai den Inhalt der Anfrage entschlüsselt, mit Presidio analysiert und je nach Ergebnis durchlässt, redigiert oder blockiert. Für alle anderen Domains leitet der Proxy den Verkehr unverändert weiter. Damit das funktioniert, muss auf jedem Client ein eigenes Root-Zertifikat installiert werden, sonst bricht die TLS-Verbindung ab, weil der Browser die Zwischenschaltung des Proxys als Manipulation erkennt. Rechne für den kompletten Aufbau inklusive Tests mit 90 Minuten, für Schritt 1 bis 8 allein reichen etwa 45 Minuten.
Wichtig für die Planung: Diese Architektur deckt Geräte ab, die im Firmennetz oder über ein verwaltetes VPN laufen. Reines Split-Tunneling, bei dem nur ein Teil des Datenverkehrs durch das Firmennetz geht, kann den Proxy umgehen, wenn der Tunnel KI-Domains explizit ausschließt. Prüfe deine VPN-Konfiguration deshalb parallel zum Gateway-Aufbau, sonst bleibt eine Lücke offen, die auf dem Papier geschlossen aussieht, es in der Praxis aber nicht ist. Für Außendienstmitarbeitende ohne durchgehende VPN-Pflicht empfiehlt sich zusätzlich eine Richtlinie, die den Proxy als Voraussetzung für den Zugriff auf Unternehmensressourcen definiert.
Schritt 1 und 2: Projektumgebung und Pakete einrichten
Schritt 1: Projektverzeichnis und virtuelle Umgebung
Lege zunächst ein eigenes Projektverzeichnis an und richte eine isolierte Python-Umgebung ein. Das verhindert Versionskonflikte mit anderer Software auf demselben Rechner.
mkdir ki-dlp-gateway && cd ki-dlp-gateway
python3 -m venv venv
source venv/bin/activate
python3 -m pip install --upgrade pipSchritt 2: mitmproxy und Presidio installieren
Installiere anschließend die drei zentralen Bibliotheken des Projekts sowie das deutsche Sprachmodell für spaCy, auf dem Presidio bei der Namens- und Adresserkennung aufbaut.
pip install mitmproxy presidio-analyzer presidio-anonymizer
python3 -m spacy download de_core_news_lgPrüfe danach, ob mitmproxy korrekt installiert wurde, indem du die Versionsnummer abfragst. Erscheint ein Fehler, fehlt meist eine Systemabhängigkeit wie libffi oder openssl, die sich über den Paketmanager der jeweiligen Linux-Distribution nachinstallieren lässt.
Das Sprachmodell de_core_news_lg ist mit mehreren hundert Megabyte deutlich größer als die kleineren spaCy-Modelle, liefert dafür aber spürbar bessere Trefferquoten bei deutschen Namen, Orten und Organisationen. Wer das Gateway auf einem Server mit wenig Speicherplatz betreibt, kann testweise mit dem kleineren Modell de_core_news_sm starten, sollte dann aber einplanen, die Erkennungsqualität in Schritt 5 noch einmal gegenzuprüfen, bevor das System produktiv geht.
Schritt 3 und 4: mitmproxy-Zertifikat und erstes Addon
Schritt 3: CA-Zertifikat erzeugen und verteilen
Starte mitmproxy einmal kurz, damit es sein eigenes Root-Zertifikat erzeugt. Das Zertifikat liegt danach im Verzeichnis ~/.mitmproxy/ und muss auf jedem Client-Gerät als vertrauenswürdige Zertifizierungsstelle importiert werden, etwa über die Gruppenrichtlinie in einer Windows-Domäne oder ein Mobile-Device-Management-Profil bei Laptops und Smartphones.
mitmdump --set confdir=~/.mitmproxy &
sleep 2 && kill %1
ls ~/.mitmproxy/mitmproxy-ca-cert.pemSchritt 4: Erstes Addon-Skelett schreiben
mitmproxy-Addons sind einfache Python-Klassen mit speziellen Methodennamen, die bei bestimmten Ereignissen aufgerufen werden. Die Methode request feuert, sobald eine Anfrage beim Proxy eintrifft, bevor sie an das Ziel weitergeleitet wird. Lege eine Datei dlp_addon.py an und beschränke die Logik zunächst auf bekannte KI-Domains.
from mitmproxy import http
AI_DOMAINS = (
"chatgpt.com", "chat.openai.com",
"gemini.google.com", "generativelanguage.googleapis.com",
"claude.ai", "api.anthropic.com",
)
class DlpAddon:
def request(self, flow: http.HTTPFlow) -> None:
if not any(domain in flow.request.pretty_host for domain in AI_DOMAINS):
return
print(f"[DLP] KI-Anfrage erkannt: {flow.request.pretty_host}{flow.request.path}")
addons = [DlpAddon()]Teste das Addon, indem du mitmproxy damit startest und den Systemproxy deines Testrechners kurzzeitig auf 127.0.0.1:8080 umstellst. Rufst du danach eine der hinterlegten KI-Domains auf, sollte die Konsole die erkannte Anfrage protokollieren.
mitmdump -s dlp_addon.pyAn dieser Stelle lohnt sich ein kurzer Zwischenstand: Das Addon erkennt bislang nur, dass eine Anfrage an eine KI-Domain geht, es schaut sich den Inhalt noch nicht an. Das ist bewusst so aufgebaut, damit du die Grundfunktion des Proxys isoliert testen kannst, bevor in den nächsten Schritten die eigentliche Inhaltsanalyse dazukommt. Wer an dieser Stelle bereits Fehler im Domain-Abgleich findet, etwa weil ein Anbieter zusätzliche Subdomains für mobile Apps nutzt, sollte die Liste AI_DOMAINS jetzt vervollständigen, statt das Problem auf später zu verschieben.
Schritt 5 und 6: Sensible Daten mit Presidio erkennen
Schritt 5: Presidio-Analyzer isoliert testen
Bevor die Erkennung in den Proxy wandert, lohnt sich ein separater Test. Presidio erkennt von Haus aus Entitäten wie E-Mail-Adressen, Kreditkartennummern, IBANs und mit dem deutschen Sprachmodell auch Personennamen und Adressen.
from presidio_analyzer import AnalyzerEngine
analyzer = AnalyzerEngine()
text = "Bitte fasse den Vertrag fuer Max Mustermann, IBAN DE02120300000000202051, zusammen."
results = analyzer.analyze(text=text, language="de")
for r in results:
print(r.entity_type, text[r.start:r.end], round(r.score, 2))Die Ausgabe zeigt Entitätstyp, erkannten Textabschnitt und einen Konfidenzwert zwischen 0 und 1:
PERSON Max Mustermann 0.85
IBAN_CODE DE02120300000000202051 0.95Schritt 6: Eigene Erkenner für Secrets und interne Codenamen
Die Standarderkennung deckt keine API-Keys oder internen Projektnamen ab. Dafür braucht Presidio eigene, musterbasierte Erkenner, ähnlich den Regeln, die Secret-Scanner für Git-Repositories verwenden. Ergänze einen Erkenner für gängige API-Key-Formate sowie für interne Projektbezeichnungen.
from presidio_analyzer import Pattern, PatternRecognizer
api_key_pattern = Pattern(name="api_key", regex=r"\b(sk|pk)-[A-Za-z0-9]{20,}\b", score=0.9)
api_key_recognizer = PatternRecognizer(
supported_entity="API_KEY", patterns=[api_key_pattern], supported_language="de"
)
project_pattern = Pattern(name="internal_project", regex=r"\bProjekt-(Falke|Luchs|Adler)\b", score=0.85)
project_recognizer = PatternRecognizer(
supported_entity="INTERNAL_PROJECT", patterns=[project_pattern], supported_language="de"
)
analyzer.registry.add_recognizer(api_key_recognizer)
analyzer.registry.add_recognizer(project_recognizer)Passe die Regex-Muster für interne Projektnamen an deine tatsächliche Namenskonvention an. Je spezifischer das Muster, desto weniger False Positives produziert der Erkenner später im Produktivbetrieb.
Ein praktischer Tipp aus dem Betrieb ähnlicher Systeme: Sammle in den ersten Wochen nach dem Rollout alle Fälle, in denen Presidio einen Treffer meldet, der sich im Nachhinein als harmlos herausstellt. Diese Fälle sind die beste Grundlage, um die Score-Schwellenwerte der einzelnen Erkenner nachzujustieren. Ein Erkenner, der mit einem Score von 0.4 schon auslöst, produziert typischerweise deutlich mehr Fehlalarme als einer, der erst ab 0.8 reagiert, dafür aber auch leichter echte Treffer übersieht. Die richtige Balance findet sich meist erst nach einigen Wochen Betrieb.
Schritt 7 und 8: Erkennung mit dem Proxy verbinden und reagieren
Schritt 7: Request-Bodies an KI-Domains abfangen
Jetzt verbindest du die Presidio-Analyse mit dem Addon aus Schritt 4. Der Request-Body einer Chat-Anfrage liegt meist als JSON vor, das relevante Textfeld unterscheidet sich je nach Anbieter. Für das Beispiel gehen wir vereinfacht von einem Feld content aus.
import json
from mitmproxy import http
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()
class DlpAddon:
def request(self, flow: http.HTTPFlow) -> None:
if not any(d in flow.request.pretty_host for d in AI_DOMAINS):
return
try:
body = json.loads(flow.request.get_text())
content = body.get("content", "")
except (ValueError, AttributeError):
return
if not content:
return
findings = analyzer.analyze(text=content, language="de")
self._handle_findings(flow, body, content, findings)Schritt 8: Blockieren oder redigieren
Für die Reaktion gibt es zwei sinnvolle Strategien: harte Treffer wie API-Keys oder IBANs blockierst du komplett, weniger kritische Treffer wie Namen ersetzt du durch Platzhalter und lässt die Anfrage durch. Das erhöht die Akzeptanz im Team, weil nicht jede Erwähnung eines Namens die Arbeit unterbricht.
def _handle_findings(self, flow, body, content, findings):
hard_blockers = {"API_KEY", "IBAN_CODE", "CREDIT_CARD"}
if any(f.entity_type in hard_blockers for f in findings):
flow.response = http.Response.make(
403, b"Anfrage blockiert: sensible Daten erkannt.",
{"Content-Type": "text/plain"}
)
self.log_event(flow, findings, action="blocked")
return
if findings:
anonymized = anonymizer.anonymize(text=content, analyzer_results=findings)
body["content"] = anonymized.text
flow.request.set_text(json.dumps(body))
self.log_event(flow, findings, action="redacted")Eine blockierte Anfrage liefert dem Nutzer direkt im Browser die Fehlermeldung 403 mit dem Hinweistext, eine redigierte Anfrage läuft unbemerkt weiter, nur eben ohne die sensiblen Originaldaten.
Überlege dir vor dem Rollout genau, welche Entitätstypen in welche der beiden Kategorien fallen. API-Keys und Kreditkartennummern gehören fast immer in die harte Blockliste, weil es für ihre Erwähnung in einem KI-Prompt kaum einen legitimen Anwendungsfall gibt. Bei Personennamen ist die Lage uneindeutiger: Ein Prompt wie „Wie spreche ich Konflikte im Team diplomatisch an“ erwähnt vielleicht einen Namen, ohne dass dahinter ein echtes Datenschutzrisiko steckt. Hier zahlt sich die weichere Redigierstrategie aus, weil sie die Arbeit nicht unnötig unterbricht.
Schritt 9 und 10: Audit-Log und Domain-Richtlinien
Schritt 9: Ereignisse in SQLite protokollieren
Ohne Protokollierung lässt sich weder nachweisen, dass das Gateway funktioniert, noch lässt sich im Streitfall klären, was genau passiert ist. Ein einfaches SQLite-Log reicht für die meisten mittelständischen Umgebungen völlig aus.
import sqlite3, time
def init_db():
con = sqlite3.connect("dlp_audit.db")
con.execute("""CREATE TABLE IF NOT EXISTS events (
ts REAL, host TEXT, entity_types TEXT, action TEXT
)""")
con.commit()
return con
def log_event(self, flow, findings, action):
con = init_db()
types = ",".join(sorted({f.entity_type for f in findings}))
con.execute(
"INSERT INTO events VALUES (?, ?, ?, ?)",
(time.time(), flow.request.pretty_host, types, action),
)
con.commit()
con.close()Speichere im Log bewusst keine Klartextinhalte der Prompts selbst, nur Metadaten wie Zielhost, erkannte Kategorien und Aktion. Ein Audit-Log, das die sensiblen Daten im Klartext erneut sammelt, schafft sonst ein zweites Datenschutzproblem an der Stelle, an der eigentlich eines gelöst werden sollte. Lege außerdem von Anfang an eine feste Löschfrist für die Log-Einträge fest, etwa 90 Tage, und dokumentiere diese Frist zusammen mit dem Zweck der Protokollierung. Ein unbegrenzt wachsendes Log ohne definierte Aufbewahrungsdauer ist datenschutzrechtlich schwerer zu rechtfertigen als eines mit klarer, regelmäßig durchgesetzter Löschroutine.
Schritt 10: Allowlist statt Komplettsperre
Ein Totalverbot öffentlicher KI-Dienste führt in der Praxis meist dazu, dass Mitarbeitende auf private Geräte ausweichen, außerhalb jeder Kontrolle. Sinnvoller ist eine Richtlinie, die zwischen freigegebenen Unternehmens-Tenants und privaten Konten unterscheidet.
| Ansatz | Kosten | Abdeckung | Typisches Werkzeug |
|---|---|---|---|
| DNS-Blocking privater KI-Domains | niedrig | grob, keine Inhaltsanalyse | Pi-hole, Firewall-Regeln |
| Browser-Erweiterung mit DLP-Regeln | mittel | nur Browser, keine Apps | Browser-eigene DLP-Add-ons |
| Selbst gehosteter DLP-Proxy | niedrig (nur Betriebsaufwand) | systemweit, inhaltsbasiert | mitmproxy + Presidio (diese Anleitung) |
| Enterprise-Plattform mit zentralem Reporting | lizenzabhängig | systemweit, inklusive Compliance-Dashboard | Microsoft Purview DSPM for AI |
Pflege die Liste freigegebener Domains zentral in einer Konfigurationsdatei, nicht hartkodiert im Addon. So kannst du neue KI-Dienste aufnehmen oder sperren, ohne den Code jedes Mal anzufassen, und IT-Teams ohne Python-Kenntnisse können die Liste selbst pflegen.
Die Domain-Liste sollte regelmäßig überprüft werden, idealerweise monatlich. Anbieter ändern Endpunkte, führen neue Subdomains für mobile Clients ein oder bringen ganz neue Produkte auf den Markt, die vorher schlicht nicht existierten. Ein Gateway, dessen Domain-Liste seit der Einführung nicht mehr aktualisiert wurde, deckt nach einem Jahr oft nur noch einen Bruchteil der tatsächlich genutzten KI-Dienste ab, während neue Anbieter ungeprüft durchlaufen.
Schritt 11 und 12: Docker-Deployment und Rollout
Schritt 11: Gateway als Container paketieren
Für den Produktivbetrieb gehört das Gateway in einen Container, damit es sich einheitlich auf einem zentralen Server oder in der Cloud betreiben lässt, statt auf einem einzelnen Entwickler-Notebook zu laufen.
# Dockerfile
FROM python:3.12-slim
WORKDIR /app
RUN pip install mitmproxy presidio-analyzer presidio-anonymizer \
&& python3 -m spacy download de_core_news_lg
COPY dlp_addon.py domains.json ./
EXPOSE 8080
CMD ["mitmdump", "-s", "dlp_addon.py", "--listen-port", "8080"]# docker-compose.yml
services:
ki-dlp-gateway:
build: .
ports:
- "8080:8080"
volumes:
- ./mitmproxy-ca:/root/.mitmproxy
- ./dlp_audit.db:/app/dlp_audit.dbStarte den Container anschließend mit docker compose up -d und exportiere das erzeugte Zertifikat aus dem gemounteten Verzeichnis mitmproxy-ca für die Verteilung an die Clients.
Schritt 12: Client-Geräte anbinden
Verteile das CA-Zertifikat über Gruppenrichtlinien unter Windows oder ein MDM-Profil unter macOS und bei Smartphones. Den Proxy selbst konfigurierst du am einfachsten über eine PAC-Datei, die festlegt, dass nur Verkehr zu bekannten KI-Domains über das Gateway läuft, während der Rest direkt ins Internet geht.
function FindProxyForURL(url, host) {
var aiHosts = ["chatgpt.com", "gemini.google.com", "claude.ai", "chat.openai.com"];
for (var i = 0; i < aiHosts.length; i++) {
if (dnsDomainIs(host, aiHosts[i])) {
return "PROXY 10.0.0.5:8080";
}
}
return "DIRECT";
}Dieser selektive Ansatz hält die Latenz für normalen Internetverkehr niedrig und konzentriert die Rechenlast des Gateways auf den Verkehr, der tatsächlich geprüft werden muss.
Plane den Rollout in Wellen statt als einmaligen Stichtag für die gesamte Belegschaft. Starte mit einer freiwilligen Pilotgruppe aus der IT-Abteilung, sammle dort zwei bis drei Wochen Erfahrung mit Fehlalarmen und Performance, und erweitere das Gateway erst danach auf weitere Abteilungen. Diese Reihenfolge verhindert, dass ein einzelner schlecht kalibrierter Erkenner gleich die gesamte Belegschaft bei der täglichen Arbeit ausbremst und das Projekt intern in Verruf bringt, bevor es seinen Nutzen zeigen konnte.
Das Gateway testen: Beispiel-Prompts und Ergebnisse
Teste das fertige Setup mit einer Reihe realistischer Beispiele, bevor du es unternehmensweit ausrollst. Die folgende Tabelle zeigt typische Testfälle und wie das Gateway darauf reagieren sollte.
| Beispiel-Prompt | Erkannter Typ | Reaktion des Gateways |
|---|---|---|
| „Fasse diesen Artikel über Quantencomputer zusammen.“ | keiner | durchgelassen |
| „Formuliere die Kündigung für Max Mustermann, IBAN DE02120300000000202051.“ | PERSON, IBAN_CODE | blockiert (403) |
| „Hier ist mein API-Key sk-abcdefghijklmnopqrst12345, warum funktioniert er nicht?“ | API_KEY | blockiert (403) |
| „Schreib eine E-Mail an unseren Kunden Peter Schmidt wegen des Liefertermins.“ | PERSON | redigiert, Name ersetzt durch Platzhalter |
| „Welche Risiken bestehen bei Projekt-Falke im aktuellen Zeitplan?“ | INTERNAL_PROJECT | blockiert (403) |
Eine redigierte Anfrage kommt beim KI-Dienst in etwa so an: „Schreib eine E-Mail an unseren Kunden <PERSON> wegen des Liefertermins.“ Der Chatbot kann die Aufgabe weiterhin sinnvoll erfüllen, ohne dass der echte Name das Unternehmensnetz verlässt. Prüfe bei den ersten Testläufen gezielt auch Grenzfälle wie Namen in Tabellenform oder über mehrere Sätze verteilte IBANs, da Presidio bei stark fragmentiertem Text gelegentlich schwächer erkennt als bei zusammenhängenden Sätzen.
Baue dir aus den Testfällen eine kleine, wiederholbare Testsuite statt nur manuell durchzuklicken. Ein einfaches Python-Skript, das eine Liste von Beispieltexten gegen den Analyzer laufen lässt und die erwarteten Entitätstypen mit den tatsächlichen Treffern vergleicht, reicht dafür völlig aus. So fällt sofort auf, wenn ein Update von Presidio oder spaCy die Erkennungsqualität für einzelne Kategorien verschlechtert, statt dass dir das erst Wochen später über Beschwerden aus dem Team auffällt.
Grenzen des Ansatzes: Was ein KI-DLP-Gateway nicht leisten kann
So nützlich das Gateway ist, es löst nicht jedes Problem rund um Schatten-KI. Verschlüsselter Verkehr über Apps mit striktem Certificate Pinning lässt sich grundsätzlich nicht aufbrechen, ohne die App selbst zu manipulieren, was in den meisten Unternehmen weder praktikabel noch rechtlich unproblematisch wäre. Ebenso wenig schützt das Gateway vor Daten, die ein Mitarbeiter vor der Eingabe bereits manuell umformuliert oder in Bildform einfügt, etwa als Screenshot einer Tabelle. Texterkennung in Bildern ließe sich zwar ergänzen, erhöht aber Komplexität und Fehlerquote spürbar.
Ebenfalls außerhalb der Reichweite liegt, was nach der Antwort des KI-Dienstes mit den Daten passiert. Das Gateway kontrolliert den ausgehenden Datenverkehr, nicht aber, ob ein Mitarbeiter eine KI-generierte Antwort anschließend ungeprüft in eine öffentliche Präsentation kopiert. Data Loss Prevention für KI-Tools ist deshalb immer nur ein Baustein neben Schulung, klaren Richtlinien und einer Unternehmenskultur, in der Rückfragen zum Umgang mit sensiblen Daten erwünscht statt lästig sind. Wer das Gateway als alleinige Lösung verkauft, weckt Erwartungen, die keine Technik allein erfüllen kann.
Die fünf häufigsten Fehler beim Aufbau eines KI-DLP-Gateways
Die meisten gescheiterten DLP-Projekte für KI-Tools scheitern nicht an der Technik, sondern an der Rollout-Planung. Die folgenden fünf Fehler tauchen in der Praxis besonders häufig auf und lassen sich mit etwas Vorbereitung komplett vermeiden.
- Zertifikat nicht auf allen Geräten verteilt: Fehlt das CA-Zertifikat auf einem Client, brechen dort reihenweise HTTPS-Verbindungen ab, nicht nur zu KI-Diensten. Das führt schnell zu Supportanfragen und Akzeptanzproblemen im Team.
- Nur Browserverkehr erfasst: Desktop-Apps von ChatGPT oder Claude nutzen teils eigene Zertifikatsprüfungen (Certificate Pinning) und ignorieren Systemproxys. Wer nur den Browser absichert, übersieht einen wachsenden Teil der Nutzung.
- Zu aggressive Erkennungsregeln: Werden selbst harmlose Vornamen in jedem Kontext blockiert, weicht das Team auf private Geräte aus. Teste Regex-Muster ausgiebig, bevor du sie produktiv schaltest.
- Audit-Log speichert Klartext: Wer aus Bequemlichkeit den vollständigen Prompt statt nur Metadaten protokolliert, baut ein neues, oft schlechter geschütztes Datensilo auf.
- Betriebsrat und Datenschutz zu spät eingebunden: Ein fertiges System nachträglich rechtlich absegnen zu lassen, kostet in der Regel mehr Zeit, als beide Seiten von Beginn an einzubeziehen.
- Kein Prozess für dringende Ausnahmen: Blockiert das Gateway eine geschäftskritische Anfrage kurz vor einem Termin, braucht das Team einen schnellen Weg zur temporären Freigabe. Fehlt dieser Notfallpfad, wird die IT-Abteilung zur Flaschenhals-Stelle und das Projekt verliert an Rückhalt.
Troubleshooting: Acht Probleme und ihre Lösungen
Auch nach einem sauberen Aufbau tauchen im Betrieb typische Probleme auf, die sich meist in wenigen Minuten lösen lassen, wenn man weiß, wo man suchen muss.
- Browser meldet „NET::ERR_CERT_AUTHORITY_INVALID“: Das mitmproxy-CA-Zertifikat wurde nicht oder falsch importiert. Prüfe den Zertifikatsspeicher des Betriebssystems und importiere
mitmproxy-ca-cert.pemerneut als vertrauenswürdige Stammzertifizierungsstelle. - mitmproxy startet nicht, Port 8080 belegt: Ein anderer Dienst blockiert den Port. Starte mit
mitmdump --listen-port 8081auf einem alternativen Port oder beende den blockierenden Prozess. - Presidio erkennt deutsche Namen nicht: Meist fehlt das Sprachmodell oder es wurde die englische Analyzer-Instanz statt der deutschen genutzt. Prüfe, ob
de_core_news_lginstalliert ist undlanguage="de"im Analyzer-Aufruf steht. - Addon wirft Exception bei großen JSON-Bodies: Sehr große Uploads oder gestreamte Antworten lassen sich nicht immer vollständig parsen. Begrenze die Body-Größe, die analysiert wird, und leite überlange Anfragen sicherheitshalber ungeprüft, aber protokolliert, weiter.
- Docker-Container kann kein Zertifikat erzeugen: Meist ein Rechteproblem am gemounteten Volume. Prüfe die Schreibrechte des Verzeichnisses
mitmproxy-caauf dem Host-System. - Hohe CPU-Last bei vielen gleichzeitigen Verbindungen: Die NLP-Analyse von Presidio ist rechenintensiv. Skaliere das Gateway horizontal mit mehreren Containern hinter einem Loadbalancer oder reduziere die Menge aktivierter Erkenner auf das Nötigste.
- Desktop-App verweigert die Verbindung komplett: Manche Anwendungen erzwingen Certificate Pinning und lassen sich grundsätzlich nicht über einen Proxy abfangen. Hier hilft nur eine Netzwerk-Policy, die den direkten Zugriff dieser App komplett blockiert und auf die Web-Version verweist.
- SQLite meldet „database is locked“: Bei vielen parallelen Schreibzugriffen stößt SQLite an Grenzen. Für Umgebungen mit hohem Durchsatz lohnt der Wechsel zu PostgreSQL als Backend für das Audit-Log.
- Mitarbeitende beschweren sich über spürbare Verzögerung: Jede zusätzliche Analyse kostet Zeit. Miss die Latenz vor und nach Einführung des Gateways gezielt, und wenn sie merklich steigt, reduziere zunächst die Zahl gleichzeitig aktiver Erkenner, bevor du zusätzliche Serverkapazität beschaffst.
Erweiterte Tipps für den Produktivbetrieb
Sobald das Grundgerüst läuft, lohnen sich einige Ergänzungen. Wer branchenspezifische Begriffe zuverlässig erkennen will, etwa Patientendaten in einer Arztpraxis oder Vertragsklauseln in einer Kanzlei, sollte eigene, feinjustierte Erkenner statt generischer Muster aufbauen und diese regelmäßig anhand echter Fehlklassifizierungen nachschärfen. Für Unternehmen, die zusätzlich zentrales Compliance-Reporting benötigen, lässt sich das selbst betriebene Gateway mit einer Plattform wie Microsoft Purview kombinieren, etwa indem das eigene Audit-Log zusätzlich an ein zentrales SIEM-System weitergeleitet wird.
Eine zweite sinnvolle Ergänzung ist die Bereitstellung einer lokal gehosteten Alternative. Bietet die IT-Abteilung ein selbst gehostetes Sprachmodell für unkritische interne Aufgaben an, sinkt der Druck, aus Bequemlichkeit auf private Cloud-Dienste auszuweichen, deutlich. Schließlich lohnt sich ein Blick auf Anomalie-Erkennung: Ein Nutzer, der plötzlich zehnmal mehr Anfragen an KI-Dienste stellt als im Durchschnitt der letzten Wochen, ist ein guter Kandidat für eine manuelle Prüfung, unabhängig davon, ob einzelne Prompts als sensibel markiert wurden.
Um den Erfolg des Gateways messbar zu machen, lohnt sich ein wöchentlicher Blick auf drei Kennzahlen aus dem Audit-Log: die Gesamtzahl geprüfter Anfragen, der Anteil blockierter gegenüber redigierter Treffer und die Verteilung der erkannten Entitätstypen über die Zeit. Steigt der Anteil blockierter API-Keys plötzlich an, deutet das oft auf ein einzelnes Team hin, das gerade eine neue, noch nicht freigegebene Integration testet, ein guter Anlass für ein klärendes Gespräch statt für eine automatische Eskalation. Wer diese Kennzahlen monatlich an die Geschäftsführung berichtet, macht den Nutzen der Investition sichtbar, lange bevor der erste größere Vorfall verhindert wurde.
Häufig gestellte Fragen
Zum Abschluss die Fragen, die in Gesprächen mit IT-Teams und Datenschutzbeauftragten zu diesem Thema am häufigsten auftauchen, von der rechtlichen Zulässigkeit bis zu praktischen Fragen rund um Presidio und die Abgrenzung zu klassischer Data Loss Prevention.
Ist das Mitlesen von KI-Prompts der Mitarbeitenden in Deutschland überhaupt erlaubt?
Grundsätzlich ja, solange die Maßnahme verhältnismäßig ist, der Zweck klar auf Datenschutz und IT-Sicherheit beschränkt bleibt und Betriebsrat sowie Datenschutzbeauftragter eingebunden sind. Reines Protokollieren von Metadaten wie Zielhost und erkannter Kategorie ist deutlich unkritischer als das Speichern vollständiger Prompt-Inhalte.
Was kostet eine selbst gebaute Lösung im Vergleich zu Enterprise-Tools?
Die in dieser Anleitung verwendeten Werkzeuge mitmproxy und Presidio sind quelloffen und kostenlos nutzbar. Es entstehen lediglich Betriebskosten für Server und Administrationsaufwand, grob vergleichbar mit dem Betrieb eines kleinen internen Webdienstes. Enterprise-Plattformen bringen dafür zentrales Reporting, Support und oft eine engere Integration mit bestehender Identitätsverwaltung mit, die konkreten Lizenzkosten hängen vom jeweiligen Vertrag mit dem Anbieter ab und sollten direkt erfragt werden, statt pauschale Zahlen aus Vergleichsportalen zu übernehmen.
Erkennt Presidio auch typisch deutsche Daten wie IBAN oder Personalausweisnummern?
IBAN-Nummern erkennt Presidio bereits mit den mitgelieferten Standarderkennern zuverlässig. Für Personalausweis- oder Steuernummern braucht es, wie in Schritt 6 gezeigt, eigene musterbasierte Erkenner, da diese Formate nicht standardmäßig enthalten sind.
Reicht einfaches DNS-Blocking statt eines vollständigen Proxys?
DNS-Blocking verhindert den Zugriff auf eine Domain komplett, kann aber keine Unterscheidung zwischen einer harmlosen und einer sensiblen Anfrage treffen. Für reine Verbotslisten reicht es aus, für eine inhaltsbasierte Data-Loss-Prevention-Strategie ist ein Proxy mit Inhaltsanalyse wie in dieser Anleitung notwendig.
Wie gehe ich mit privaten Smartphones der Mitarbeitenden um?
Auf privaten Geräten ohne Mobile-Device-Management lässt sich ein Unternehmensproxy nicht erzwingen. Hier hilft nur eine klare, kommunizierte Richtlinie in Kombination mit freigegebenen Unternehmens-Accounts, die den gleichen Komfort bieten wie private Alternativen, damit der Anreiz zum Ausweichen sinkt.
Muss ich den Betriebsrat vor der Einführung einbeziehen?
In den meisten Fällen ja, da ein System, das Mitarbeiterverhalten protokolliert, der Mitbestimmung unterliegt. Eine frühzeitige Abstimmung über Umfang, Speicherdauer und Zweck des Audit-Logs spart im Nachhinein Diskussionen und sorgt für höhere Akzeptanz im Team.
Funktioniert der Aufbau auch für kleine Unternehmen ohne eigene IT-Abteilung?
Ja, der komplette Aufbau lässt sich auf einem einzelnen kleinen Server betreiben und benötigt keine spezialisierte Sicherheitsabteilung. Für Unternehmen ganz ohne technisches Personal kann es dennoch sinnvoll sein, die Einrichtung einmalig von einem IT-Dienstleister begleiten zu lassen.
Worin unterscheidet sich das von klassischem Data Loss Prevention für E-Mail oder USB-Sticks?
Klassisches Data Loss Prevention prüft definierte Kanäle wie E-Mail-Anhänge, Druckaufträge oder externe Speichermedien. KI-Chatbots stellen einen neuen Kanal dar, bei dem Daten als freier Fließtext statt als strukturierte Datei das Unternehmen verlassen. Das erfordert Erkennungslogik, die auf natürlicher Sprache statt auf Dateitypen basiert, wie sie Presidio in dieser Anleitung liefert.
