KI-Dienste sind in vielen Unternehmen längst im Alltag angekommen. In der Praxis entsteht dabei aber eine sehr konkrete Frage: Was genau geht da eigentlich im Request-Body raus? Namen, Adressen, IBANs, Telefonnummern, Kundenprojekt-Daten – und das potenziell über mehrere Anbieter, Accounts und Endpoints verteilt.
Für die produktive Nutzung von KI braucht es deshalb nicht nur gute Modelle, sondern vor allem eine saubere Kontrollstelle vor dem Modell. Genau dafür haben wir einen Anonymisierungs-Proxy gebaut, der sich in realen Kundenumgebungen betreiben lässt.
Das Problem: Prompt-Inhalte sind nicht neutral
Viele Integrationen schicken heute Geschäftsprozess-Daten direkt in Prompts: Ticketinhalte, E-Mails, Kundenakten, Logs, Chatverläufe. Das funktioniert, ist aus DSGVO-Sicht aber oft problematisch:
- personenbezogene Daten landen bei externen Anbietern
- es gibt keine zentrale Übersicht, was an welches Modell ging
- Audit-Anforderungen (Art. 30 DSGVO) werden stiefmütterlich behandelt
- Wiederverwendung über Sessions hinweg ist meist gar nicht mitgedacht
Ein klassisches “wir haben ja einen Vertrag mit dem Anbieter” reicht hier technisch nicht. Entscheidend ist, dass personenbezogene Daten die eigene Kontrollzone möglichst gar nicht erst verlassen.
Die Idee: Reverse-Proxy mit Anonymisierungs-Pipeline
Das Grundmodell ist bewusst einfach: Der Proxy sitzt zwischen Client und KI-Dienst und ersetzt personenbezogene Inhalte durch Surrogate, bevor sie in Richtung Anbieter gehen. Die Antwort wird beim Zurückweg wieder auf die Originalwerte gemappt.
Architektonisch in drei Schichten:
- Regex-Layer – schnell, deterministisch, exakt
- LLM-Layer – fängt das, was Regex nicht sauber greifen kann
- Vault – konsistente Zuordnung Original ↔ Surrogat pro Vorgang
Alle drei Komponenten laufen auf eigener Infrastruktur, nicht beim KI-Anbieter.
Warum Regex zuerst
Viele PII-Datenklassen sind hochgradig strukturiert und lassen sich deterministisch erkennen. Dazu gehören:
- E-Mail-Adressen
- IBAN (mit Prüfzifferkontext)
- deutsche Telefonnummern
- PLZ + Ort
- Steuer-ID
- IPv4 und CIDR-Blöcke
- Datumsangaben
- Kfz-Kennzeichen
- ICD-Codes mit Label
- Hashes, JWTs, API-Keys, Kreditkarten mit Luhn-Check
Für solche Klassen ist ein LLM nicht nur überdimensioniert, sondern oft auch ungenau und langsam. Regex schafft das in wenigen Millisekunden, reproduzierbar und prüfbar.
Warum trotzdem ein LLM im Spiel bleibt
Zwischen den klar definierten Datenklassen gibt es aber die “weichen” personenbezogenen Informationen, die Regex schlecht trifft:
- Personennamen
- Adressen in Fließtext
- Hostnames, Benutzernamen in Domain-Notation
- Klartext-Passwörter in ungewöhnlichem Format
- Organisations- und Projektnamen
- sensible Zusatzinformationen im Fließtext
Hier setzt die zweite Stufe an: Ein lokales Modell über Ollama (zum Beispiel Qwen3 4B) wird ausschließlich auf den Restteil des Textes angewendet, nachdem Regex schon alles Sichere maskiert hat.
Das reduziert CPU-Last deutlich und hält den Fokus des LLM auf genau die Fälle, für die es gedacht ist.
Entscheidungs-Gate vor dem LLM
Damit das LLM nicht unnötig läuft, gibt es eine einfache Heuristik davor. Aufgerufen wird es nur, wenn im Residualtext wirklich Naturtext enthalten ist, zum Beispiel:
- Mindestlänge erreicht
- mindestens zwei echte Wörter nebeneinander
Reine Daten-Dumps wie IP-Listen, Hashes, Keys, Logs werden gar nicht erst ans LLM weitergereicht. Das senkt die CPU-Last spürbar und macht den Durchsatz bei typischen Infrastruktur-Inhalten fast Regex-schnell.
Konsistenz durch einen Vault
Eine Anonymisierung ohne Konsistenz ist für den Betrieb wertlos. Wenn in Request #1 aus Müller Person-17 wird und in Request #47 dieselbe Person als Person-203 auftaucht, ist jede weitere Auswertung verloren.
Deshalb nutzt der Proxy einen Vault, der Original und Surrogat stabil zuordnet – mit wichtigen Eigenschaften:
- pro Vorgang (z. B. Kunden-ID) getrennt
- atomar geschrieben, damit parallele Requests sauber laufen
- optional mit TTL (DSGVO-Retention, z. B. 30 oder 90 Tage)
- performant im Lookup, damit der Proxy nicht zum Flaschenhals wird
Für den Betrieb hat sich Redis hier als pragmatisch gut geeignet herausgestellt: schnelle Zugriffe, klare TTL-Semantik, gutes Multi-Tenant-Verhalten.
Audit-Log als Pflichtbestandteil
Ein Anonymisierungs-Proxy ohne Nachweis ist in einer DSGVO-Diskussion schnell entwertet. Deshalb schreibt der Proxy ein strukturiertes Audit-Log:
- welche Engagement- oder Kunden-ID
- welcher Endpoint wurde adressiert
- welche Entity-Klassen wurden erkannt
- wie viele Ersetzungen fanden statt
- welche Pfad-Entscheidungen (Regex-only vs. LLM-Eskalation)
Das Audit liegt außerhalb des Containers auf dem Host, damit es jederzeit greifbar ist und nicht im Container-Lifecycle verloren geht.
Kompatibilität: nicht nur ein Anbieter
Ein Proxy, der nur zu einem Anbieter spricht, hilft im Alltag nur begrenzt. Deshalb ist die Weiterleitung bewusst offen gestaltet, inklusive:
- Anthropic Messages API
- OpenAI-kompatible Chat-Completions
- OpenRouter als Mehrwege-Gateway
- OAuth-basierte Szenarien (z. B. Claude Max)
- eigener Self-hosted-Backends (LocalAI, vLLM, LM Studio Server)
Damit wird der Proxy zum zentralen Kontrollpunkt, unabhängig davon, welches Modell oder welcher Anbieter gerade gewählt wird.
Betriebsaspekte in der Praxis
Ein paar Punkte, die beim Aufbau besonders wichtig sind:
- TLS von Anfang an – öffentliche Exposition eines Anonymisierungsproxys ohne HTTPS wäre genau das Gegenteil des Sicherheitsziels
- Firewall eng – nur 80/443 nach außen, alles andere zu
- Modellgröße realistisch wählen – Qwen3 4B ist ein guter Kompromiss zwischen Erkennungstiefe und CPU-Last
- Swap sinnvoll einrichten, wenn RAM knapp ist, statt das Modell hart in Grenzen zu quetschen
- CPU-Last messen, Regex-First und das Entscheidungs-Gate sind kein Luxus, sondern Voraussetzung für stabile Latenzen
- Tenant-Trennung früh mitdenken, spätestens wenn mehrere Kunden den gleichen Proxy nutzen sollen
Wann sich so ein Proxy lohnt
Besonders sinnvoll ist dieser Ansatz, wenn:
- personenbezogene Daten regelmäßig in KI-Prompts auftauchen
- mehrere Anbieter oder Modelle parallel genutzt werden
- es nachvollziehbare DSGVO-Prozesse geben muss
- KI in Kundenprozessen integriert werden soll, ohne Rohdaten nach außen zu geben
- ein zentraler Kontrollpunkt gewünscht ist, statt dass jedes Team einzeln improvisiert
Für rein experimentelle KI-Nutzung ohne personenbezogenen Kontext braucht es das nicht. Für produktive Kundenumgebungen wird es schnell zum wichtigen Baustein.
Wie ein sinnvoller Einstieg aussieht
Ein pragmatischer Rollout lässt sich in klare Schritte zerlegen:
- Datenflüsse identifizieren: Wo fließt heute PII in Prompts?
- Relevante Entity-Klassen priorisieren (E-Mail, IBAN, Telefon, Adresse, Namen etc.)
- Proxy initial mit Regex-Layer produktiv nehmen
- LLM-Layer für Fließtext-PII ergänzen
- Multi-Tenancy, TTL und Audit fest verankern
- Integration in bestehende Identitäts- und Betriebsprozesse
So entsteht Schritt für Schritt eine DSGVO-kompatible Zugriffsebene für KI, ohne neue Schatten-IT zu produzieren.
Für welche Umgebungen das besonders passt
Dieser Ansatz ist relevant für Unternehmen, die KI im Kundenkontext einsetzen möchten, aber gleichzeitig klar kontrollieren müssen, welche Daten den eigenen Raum verlassen. Das betrifft Dienstleister, Mittelständler, Agenturen und alle, die datenschutzrelevante Informationen regelmäßig verarbeiten.
Wenn dieser Punkt bei euch gerade aktuell ist, lohnt sich meist zuerst ein sauberer Blick auf eure bestehenden KI-Integrationen und Datenflüsse. Für den operativen Aufbau solcher Kontrollebenen verbinden wir das Projekt bei Bedarf mit Managed IT, Docker Hosting und passender Server-Infrastruktur.