KI-DSGVO-Proxy: Personenbezogene Daten aus KI-Anfragen heraushalten

Viele Unternehmen nutzen KI-Dienste heute bereits produktiv – für Support, interne Auswertung, Entwürfe, Automatisierung oder die Arbeit mit Kundendaten. Genau dabei entsteht aber schnell ein praktisches Problem: In Anfragen an das Modell landen personenbezogene Daten, die dort eigentlich nicht im Klartext hingehören.

Namen, Adressen, Telefonnummern, IBANs, Ticketinhalte oder Projektdaten werden in der Hektik des Alltags schnell mitgeschickt. Technisch funktioniert das. Datenschutzrechtlich und organisatorisch ist es oft der Punkt, an dem ein eigentlich sinnvolles KI-Projekt unsauber wird.

Genau dafür setzen wir einen KI-DSGVO-Proxy ein: eine vorgeschaltete Kontrollschicht, die personenbezogene Daten erkennt, ersetzt und erst danach an den eigentlichen KI-Anbieter weitergibt.

Was der Proxy in der Praxis macht

Der Proxy sitzt zwischen eurer Anwendung und dem KI-Dienst. Bevor eine Anfrage den Anbieter erreicht, werden sensible Inhalte durch Platzhalter ersetzt. Die Antwort wird auf dem Rückweg wieder sauber zurückübersetzt, damit eure Anwendung normal weiterarbeiten kann.

Das bedeutet konkret:

• beim Anbieter kommen personenbezogene Daten nicht im Klartext an
• eure Anwendung bleibt in ihrem Verhalten unverändert nutzbar
• die Verarbeitung wird auf eurer Seite nachvollziehbar und kontrollierbar

So entsteht eine saubere technische Kontrollschicht, ohne dass Teams ihre tägliche Arbeit komplett umstellen müssen.

Warum wir auf zwei Erkennungsstufen setzen

Nicht jede sensible Information sieht gleich aus. Manche Daten lassen sich sehr klar und schnell erkennen, andere stehen nur im Fließtext und brauchen mehr Kontext.

Deshalb arbeitet der Proxy in zwei Schritten:

1. Zuerst die klaren Muster

Strukturierte Daten werden direkt und deterministisch erkannt. Dazu gehören zum Beispiel:

• E-Mail-Adressen
• IBAN
• deutsche Telefonnummern
• Postleitzahl und Ort
• Steuer-ID
• IPv4- und CIDR-Angaben
• Datumsangaben
• Kfz-Kennzeichen
• Hashes, Tokens, API-Keys und ähnliche technische Merkmale

Diese Fälle müssen nicht erst durch ein Sprachmodell. Sie lassen sich schnell, reproduzierbar und mit sehr geringer Last abdecken.

2. Danach der Rest mit Kontext

Erst danach wird geschaut, was im verbleibenden Text noch übrig ist. Genau dort liegen oft die schwierigeren Fälle:

• Personennamen
• Adressen im Fließtext
• Hostnamen und Benutzernamen in gewachsenen Umgebungen
• Organisations- und Projektnamen
• sensible Zusatzinformationen, die nicht nach einem festen Muster aufgebaut sind

Für diesen Teil wird ein lokal betriebenes Modell genutzt – nur dort, wo es wirklich sinnvoll ist.

Warum das im Betrieb wichtig ist

Viele Sicherheits- und Datenschutzprobleme entstehen nicht an der Theorie, sondern an der Belastung im Alltag. Wenn Teams mit Supportfällen, Logs, Kundenanfragen oder internen Auswertungen arbeiten, wird selten jede Zeile manuell auf sensible Inhalte geprüft.

Ein vorgeschalteter Proxy nimmt genau diese Aufgabe ab. Er sorgt dafür, dass die Regeln nicht von der Tagesform einzelner Mitarbeitender abhängen, sondern technisch durchgesetzt werden.

Das ist vor allem dann relevant, wenn:

• mehrere Teams KI-Dienste parallel nutzen
• verschiedene Anbieter im Einsatz sind
• sensible Inhalte regelmäßig in Support-, Projekt- oder Kundentexten vorkommen
• ein sauberer Nachweis über die Verarbeitung erforderlich ist

Einheitliche Zuordnung statt Zufallsersetzung

Wichtig ist nicht nur, dass Daten ersetzt werden, sondern auch wie. Wenn derselbe Kunde in einer Anfrage anders maskiert wird als in der nächsten, wird der gesamte Kontext unbrauchbar.

Deshalb arbeitet der Proxy mit einer stabilen Zuordnung zwischen Originalwert und Ersatzwert. So bleibt derselbe Inhalt innerhalb eines Vorgangs konsistent, auch wenn mehrere Anfragen nacheinander verarbeitet werden.

Das ist besonders wichtig für:

• längere KI-Dialoge
• Ticket- und Fallbearbeitung
• wiederkehrende Projektkontexte
• technische Auswertungen über mehrere Nachrichten hinweg

Nachvollziehbarkeit gehört dazu

Ein solcher Proxy ist nur dann wirklich sinnvoll, wenn nicht nur maskiert, sondern auch nachvollziehbar protokolliert wird, was passiert ist. Deshalb schreiben wir zu jedem Vorgang ein strukturiertes Audit mit.

Dabei wird unter anderem festgehalten:

• welcher Vorgang oder Kunde betroffen war
• welcher Ziel-Endpoint angesprochen wurde
• welche Arten von Daten erkannt wurden
• wie viele Ersetzungen stattgefunden haben
• ob die schnelle Mustererkennung ausgereicht hat oder ob zusätzlicher Kontext nötig war

So wird aus einer reinen Schutzfunktion auch ein sauber dokumentierbarer Verarbeitungsweg.

Nicht auf einen Anbieter festgelegt

Ein weiterer wichtiger Punkt im Alltag: Unternehmen nutzen selten nur einen einzigen KI-Anbieter. Mal geht es in Richtung Claude, mal zu OpenAI-kompatiblen Endpoints, mal über OpenRouter oder in eigene Modellumgebungen.

Der Proxy ist deshalb bewusst so aufgebaut, dass er vor unterschiedlichen Zielsystemen eingesetzt werden kann. Die Schutzlogik bleibt auf eurer Seite gleich, auch wenn ihr Modelle oder Anbieter wechselt.

Das verhindert, dass jede neue KI-Integration wieder von vorn bewertet und einzeln abgesichert werden muss.

Warum wir das auf eigener Infrastruktur betreiben

Ein Datenschutz-Proxy, der selbst wieder unkontrolliert bei einem Dritten liegt, löst das Problem nur halb. Deshalb setzen wir hier auf eigene Infrastruktur mit klaren Betriebsgrenzen.

Dazu gehören unter anderem:

• sauber abgesicherter HTTPS-Zugang
• klar begrenzte Firewall-Regeln
• Container-basierter Betrieb für Proxy, Speicher und Modell
• getrennte Zuständigkeiten für Erkennung, Zuordnung und Protokollierung
• nachvollziehbare Wartung und Updates

So bleibt die Schutzschicht technisch unter Kontrolle und organisatorisch beherrschbar.

Für wen das besonders sinnvoll ist

Der KI-DSGVO-Proxy ist besonders interessant für Unternehmen, die KI produktiv nutzen wollen, ohne dabei personenbezogene Daten unkontrolliert nach außen zu geben.

Typische Szenarien sind:

• Support- und Ticketsysteme mit Kundendaten
• interne Wissens- und Assistenzsysteme
• KI-gestützte Auswertung von E-Mails oder Dokumenten
• Assistenzfunktionen für Vertrieb, Projektarbeit oder Backoffice
• mehrere Teams oder Standorte mit gemeinsamer KI-Nutzung

Wo nur testweise mit rein technischen Beispieldaten gearbeitet wird, ist das meist noch nicht nötig. Sobald reale Personen, Kunden oder Vorgänge im Spiel sind, wird die Schutzschicht dagegen schnell zum Pflichtbaustein.

Ein sinnvoller Einstieg

In der Praxis hat sich ein pragmischer Start bewährt:

1. vorhandene Datenflüsse in KI-Anfragen sichtbar machen
2. kritische Datenarten priorisieren
3. den Proxy zunächst für die häufigsten Fälle produktiv dazwischen schalten
4. Prüf- und Protokollierungslogik schrittweise erweitern
5. Retention, Zuständigkeiten und Betriebsprozesse sauber festziehen

So entsteht keine zusätzliche Schatten-IT, sondern ein kontrollierter Weg, KI im Unternehmen verantwortbar einzusetzen.

Weitere Einordnung und passende Bausteine

Wer tiefer in die technische Herleitung einsteigen will, findet die vollständige Einordnung im Beitrag DSGVO-Anonymisierungs-Proxy für KI-Dienste: Regex-first, LLM-Residual, eigene Infrastruktur.

In der Praxis kombinieren wir solche Projekte häufig mit:

• Managed IT für den laufenden Betrieb
• Docker Hosting als stabile Container-Basis
• passender Server-Infrastruktur in deutschen Rechenzentren
• Authentik als Identitätsschicht für Zugriffssteuerung

Damit wird aus einer einzelnen Schutzfunktion eine sauber eingebettete Betriebs- und Compliance-Lösung.