Datenschutz-Gateway für KI
AI Guard
Ein Gateway, das personenbezogene Daten ersetzt, bevor sie ein LLM erreichen, und sie in der Antwort wiederherstellt.
In Entwicklung, noch nicht im Produktivbetrieb
1Dein Prompt
Schreib eine Mail an Anna Schmidt (anna.schmidt@
beispiel.de): Sie muss die Rechnung RE-2026-0417 bis zum 15.12.2026 bezahlen. 2Das sieht das Modell
Schreib eine Mail an Mira Vogt (m.vogt@
post-beispiel.de): Sie muss die Rechnung RE-2026-8852 bis zum 03.12.2026 bezahlen. 3Das antwortet das Modell
An: m.vogt@
post-beispiel.de Hallo Frau Vogt, bitte bezahlen Sie die Rechnung RE-2026-8852 bis zum 03.12.2026. Viele Grüße 4Das bekommst du
An: anna.schmidt@
beispiel.de Hallo Frau Schmidt, bitte bezahlen Sie die Rechnung RE-2026-0417 bis zum 15.12.2026. Viele Grüße
Echte DatenErsatzdaten
Beispiel mit erfundenen Daten.
Kernkompetenzen
- LLMs und Agenten
- Sicherheit und Datenschutz
- Zuverlässigkeit
- Echtzeit-Systeme
- Backend und APIs
- Testen und Verifizieren
Tech-Stack
- TypeScript
- NestJS
- OpenAI SDK
- Docker
- GLiNER
- onnxruntime
- Custom grammars
- LLM
- Vitest
- Leak corpus
- Benchmarks
Das Schwierigste
Der falsche Name darf nie durchrutschen
Wo ein Stream getrennt wird, ist Zufall. Der Code darf sich nie darauf verlassen.
Die ganze Geschichte
Was man sah
Das Modell schreibt seine Antwort Stück für Stück. Der Ersatzname „Mira Vogt“ kann als „Mi“, „ra Vo“ und „gt“ ankommen. Suchen und Ersetzen findet ihn dann nie, und du liest einen fremden Namen in deiner Mail.
Was wirklich los war
Die Stücke trennen mitten im Wort, rein zufällig. Reicht man alles sofort weiter, siehst du den falschen Namen. Sammelt man alles, bis die Antwort fertig ist, schaust du lange auf einen leeren Bildschirm.
Die Lösung
Zurückgehalten werden nur die Zeichen, die noch der Anfang eines Ersatznamens sein könnten. Alles andere läuft sofort weiter, die Antwort tippt sich also wie gewohnt.
- 512
- Tests in Guard
- ~99 %
- Erkennung in freiem Text laut eigener Spec, keine Garantie
- 4
- Erkennungs-Schichten
In einfachen Worten
Viele Firmen wollen KI nutzen, dürfen ihr aber keine Kundendaten schicken. Guard setzt sich dazwischen: Aus „Max Müller“ wird für das Modell ein erfundener Name, und in der Antwort steht für dich wieder „Max Müller“.
Sobald Texte an ein LLM gehen, gehen oft auch personenbezogene Daten mit, etwa aus Telefon-Transkripten oder Kundenmails. Guard löst das an einer Stelle: als Gateway mit OpenAI-kompatibler API, vor jeder LLM-Anwendung.
So funktioniert es
Schritt 1 von 5
Anfrage
Die Anwendung schickt ihre Anfrage an Guard statt an den LLM-Anbieter. Am Client ändert sich nur die URL.
Was gebaut wurde
- OpenAI-kompatible API, die sich vor bestehende LLM-Anwendungen schalten lässt
- Erkennung in Schichten: deterministische Grammatiken, LLM, lokale NER und im Zweifel schwärzen
- Realistische Ersatzwerte, damit das Modell mit dem Text weiter sinnvoll arbeiten kann
- Wiederherstellung auch im laufenden Stream, ohne je ein Token zu zerteilen
- Benchmarks mit schweren Fällen, ein langes generiertes Dokument mit Ground Truth und ein Leak-Test-Korpus als Gate
Wie die Kompetenzen eingesetzt wurden
- LLMs und Agenten
- Mehrstufige PII-Erkennung, lokale Inferenz mit GLiNER auf ONNX und Evaluation mit eigenen Benchmarks
- Sicherheit und Datenschutz
- Datenschutz als Architektur: lokal maskieren, bei Fehlern sperren und nur versprechen, was beweisbar ist
- Zuverlässigkeit
- Fail-closed: Fällt eine Schicht aus, gehen die Daten nicht ungeschützt durch
- Echtzeit-Systeme
- Streaming-Puffer, der Teil-Tokens zurückhält, bis feststeht, ob sie zu einem Ersatzwert gehören
- Backend und APIs
- Gateway mit NestJS, dazu zustandslose Mask- und Demask-Primitive
- Testen und Verifizieren
- 512 eigene Tests und ein Leak-Korpus, das als Gate dient
Meine Rolle
Konzept, Architektur, Führung der Agenten und Prüfung. Den Großteil des Codes hat Claude Code in meinem selbst entwickelten Agent-Workflow geschrieben.
Siehe Projekt Context Observer