|Ben @ Grepture

Maskieren und Wiederherstellen: Reversible Schwärzung für LLMs

So funktioniert reversible PII-Schwärzung — sensible Daten vor dem LLM maskieren und Originalwerte in der Antwort wiederherstellen.

Das Schwärzungs-Dilemma

Sie wollen PII in Ihrer KI-Pipeline schützen. Also fügen Sie Schwärzung hinzu.

Nicht ganz. Traditionelle Schwärzung macht Ihre Anwendung kaputt.

Nehmen wir einen Kundensupport-KI-Assistenten. Ein Nutzer schreibt: "Hallo, ich bin Sarah Miller, meine E-Mail ist sarah@example.com und meine Bestellung #45231 fehlt."

Mit permanenter Schwärzung erhält das LLM: "Hallo, ich bin [GESCHWÄRZT], meine E-Mail ist [GESCHWÄRZT] und meine Bestellung #45231 fehlt."

Das Modell gibt sein Bestes. Es antwortet: "Es tut mir leid [GESCHWÄRZT], ich schaue mir Bestellung #45231 an. Ich sende ein Update an [GESCHWÄRZT]."

Der Kunde sieht [GESCHWÄRZT] in der Antwort. Der Schutz hat funktioniert — und die App ist kaputt. Die User Experience ist furchtbar. Sie haben ein Problem gegen ein anderes getauscht.

Mit traditioneller Schwärzung: Daten schützen oder eine funktionierende App. Nicht beides.

So funktioniert Mask and Restore

Mask and Restore ist Greptures Ansatz für reversible Schwärzung. Anstatt PII zu zerstören, werden sensible Werte temporär durch Token ersetzt, das LLM verarbeitet den tokenisierten Prompt, und dann werden die Originalwerte in der Antwort wieder eingesetzt. Das LLM sieht nie echte PII. Der Nutzer sieht nie Token. Die Anwendung funktioniert einwandfrei.

Der Ablauf:

Schritt 1: Erkennen

Greptures Erkennungs-Engine identifiziert PII in der eingehenden Anfrage. Das nutzt Regex-Muster für strukturierte Daten (E-Mails, Telefonnummern, Kreditkarten) und lokale KI-Modelle für unstrukturierte Daten (Namen, Orte, Organisationen). Die gesamte Erkennung läuft auf Greptures Infrastruktur — Ihre Daten werden nicht anderweitig weitergeleitet.

Schritt 2: Durch Token ersetzen

Jeder erkannte PII-Wert wird durch einen einzigartigen, typerhaltenden Token ersetzt. Das Token-Format kodiert den Entitätstyp und einen kurzen Hash:

  • Sarah Miller wird zu <<PERSON_a7f3>>
  • sarah@example.com wird zu <<EMAIL_b2e1>>

Der Typ-Präfix ist wichtig. Er teilt dem LLM mit, mit welcher Art von Entität es arbeitet, was dem Modell hilft, kohärente Antworten zu generieren. Mehr dazu, warum das funktioniert, im nächsten Abschnitt.

Schritt 3: Mapping im Vault speichern

Das Token-zu-Wert-Mapping wird in einem verschlüsselten Vault mit konfigurierbarer TTL (Time-to-Live) gespeichert. Der Vault hält die echten Werte, damit sie später wiederhergestellt werden können.

Schritt 4: Tokenisierte Anfrage senden

Das LLM erhält den bereinigten Prompt:

"Hallo, ich bin <<PERSON_a7f3>>, meine E-Mail ist <<EMAIL_b2e1>> und meine Bestellung #45231 fehlt."

Keine echte PII erreicht den KI-Anbieter. Wenn der Anbieter die Anfrage loggt, zwischenspeichert oder für Training verwendet — es spielt keine Rolle. Es gibt nichts Sensibles darin.

Schritt 5: LLM antwortet mit Token

Das Modell behält die referenzielle Konsistenz bei. Es verfolgt die Token als Entitäten und verwendet sie korrekt in seiner Antwort:

"Es tut mir leid <<PERSON_a7f3>>, ich schaue mir Bestellung #45231 an. Ich sende ein Update an <<EMAIL_b2e1>>."

Schritt 6: Wiederherstellung in der Antwort

Grepture fängt die Antwort ab, schlägt jeden Token im Vault nach und setzt die Originalwerte wieder ein:

"Es tut mir leid Sarah Miller, ich schaue mir Bestellung #45231 an. Ich sende ein Update an sarah@example.com."

Der Nutzer erhält eine natürliche, vollständige Antwort. Das LLM hat nie echte PII gesehen. Es waren keine Code-Änderungen nötig, abgesehen vom initialen Proxy-Setup. So sieht das Verhindern von Datenlecks aus, wenn die Anwendung gleichzeitig weiter funktionieren soll.

Warum das mit LLMs funktioniert

Warum sollte ein Sprachmodell erfundene Token korrekt verarbeiten? Es liegt daran, wie Transformer Text verarbeiten.

LLMs sind hervorragend bei referenzieller Konsistenz. Wenn ein Modell eine Entität im Prompt sieht — ob es ein echter Name oder ein Token wie <<PERSON_a7f3>> ist — verfolgt es diese Entität durch Attention-Mechanismen über das gesamte Kontextfenster. Dem Modell ist egal, ob die Entität wie ein menschlicher Name oder ein undurchsichtiger Identifier aussieht. Es kümmert sich um die Beziehungen und Referenzen.

Das Token-Format ist bewusst gewählt. Das <<TYPE_hash>>-Muster ist so gestaltet, dass es wie eine Entitätsreferenz aussieht — etwas, das Modelle natürlich verarbeiten. Es ist distinkt genug, damit das Modell es nicht mit normalem Text verwechselt, und der Typ-Präfix gibt dem Modell semantische Information darüber, was der Token repräsentiert.

Es funktioniert mit Streaming. Grepture unterstützt SSE (Server-Sent Events) Streaming und detokenisiert Chunks in Echtzeit, wenn sie vom Anbieter eintreffen. Es gibt kein Buffering — der Nutzer sieht eine normale Streaming-Antwort, bei der die wiederhergestellten Werte erscheinen, sobald jeder Chunk durchkommt.

Es funktioniert über Konversations-Turns hinweg. Solange die Vault-TTL nicht abgelaufen ist, werden Token in Multi-Turn-Konversationen korrekt wiederhergestellt. Das Mapping bleibt zwischen Anfragen bestehen, sodass eine Chatbot-Konversation über mehrere Nachrichten hinweg eine konsistente Wiederherstellung beibehält.

Der Attention-Mechanismus behandelt Token als Entitäten unabhängig von ihrer Oberflächenform — das macht Mask and Restore zuverlässig.

Ansätze im Vergleich

Nicht jede Situation erfordert Mask and Restore.

Permanente Schwärzung

PII durch [GESCHWÄRZT] ersetzen. Einfach, kein Risiko einer Offenlegung, keine Chance, dass Daten durch Token leaken. Aber es bricht die Anwendungslogik — das LLM kann die Originalwerte nicht referenzieren, und der Nutzer auch nicht. Am besten für: Audit-Logs, Analytics-Pipelines, jeder Kontext, in dem die Originalwerte nicht zurückgebraucht werden.

Partielle Maskierung

PII durch teilweise verdeckte Werte wie S**** M***** oder s****@example.com ersetzen. Bewahrt etwas Struktur, verliert aber trotzdem die eigentliche Information. Das LLM kann die Daten nicht sinnvoll in seiner Antwort verwenden. Bessere UX als [GESCHWÄRZT], aber dieselbe funktionale Einschränkung. Am besten für: Anzeigekontexte, in denen der Datentyp ohne vollständigen Wert ausreicht.

Client-seitige Schwärzung

Anwendungscode entfernt PII vor dem Senden an den KI-Anbieter. Das legt die Last auf Entwickler — jeder Dienst braucht seine eigene Implementierung, die Abdeckung ist inkonsistent, und die Wartung ist aufwändig, wenn sich Datenmuster ändern. Sie müssen außerdem darauf vertrauen, dass jedes Team es richtig macht. Am besten für: Umgebungen, in denen kein Proxy-Layer verwendet werden kann (selten, aber es gibt sie).

Mask and Restore

Voller Schutz plus volle Funktionalität. Netzwerk-Layer-Interception bedeutet keine Code-Änderungen über alle Dienste hinweg. Token-basierter Ersatz mit verschlüsseltem Vault-Storage und konfigurierbarer TTL. Am besten für: Nutzer-orientierte KI-Features, bei denen die LLM-Antwort an den Nutzer zurückgeht — Chatbots, Support-Agenten, Content-Generierung, alles wo Schutz UND eine funktionierende Anwendung gebraucht wird.

Abwägungen: Der Vault fügt eine Abhängigkeit hinzu (gemildert durch TTL-Ablauf und Zero-Data-Mode-Optionen), Token müssen das Kontextfenster des Modells überleben (kein Problem bei typischen Konversationen, aber sehr lange Prompts könnten theoretisch betroffen sein), und lang laufende Konversationen können an TTL-Limits stoßen, wenn die Sitzung die konfigurierte Ablaufzeit überschreitet.

Vault-Design

Der Vault speichert das verschlüsselte Mapping zwischen Token und Originalwerten und ist mit Datenminimierung im Blick konzipiert.

  • Verschlüsselter Speicher — Token-zu-Wert-Mappings sind im Ruhezustand verschlüsselt. Selbst wenn der Vault auf irgendeine Weise direkt zugänglich wäre, sind die Rohdaten nicht lesbar.
  • Konfigurierbare TTL — Werte laufen nach einer festgelegten Zeit ab. Das balanciert Nutzbarkeit (Token bleiben für die Dauer einer Konversation wiederherstellbar) mit minimierter Datenhaltung (Werte werden nicht endlos aufbewahrt). Die TTL wird in der Konfiguration festgelegt.
  • Zero-Data-Mode — Bei Business+-Plänen ist der Vault-Storage ausschließlich im Arbeitsspeicher. Token und Werte berühren nie die Festplatte. Der gesamte Mask-and-Restore-Zyklus wird innerhalb des Request-Lebenszyklus abgeschlossen, und nichts persistiert nach der Auslieferung der Antwort. Das ist der strengste Modus für Umgebungen, in denen selbst temporäres Speichern von PII ein Anliegen ist.
  • Isolierte Vault-Bereiche — Jeder API-Key hat seinen eigenen Vault-Namespace. Es gibt keine Vermischung zwischen verschiedenen Anwendungen oder Umgebungen, die dasselbe Grepture-Konto nutzen.
  • Automatische Bereinigung — Vault-Einträge werden pro Anfrage erstellt und bei TTL-Ablauf automatisch bereinigt. Es gibt keine manuelle Wartung — der Vault verwaltet sich selbst.

Die TTL ist die entscheidende Design-Entscheidung. Zu kurz und Multi-Turn-Konversationen brechen ab. Zu lang und Sie speichern PII länger als nötig. Der richtige Wert hängt vom Anwendungsfall ab — ein schneller Q&A-Bot könnte eine 5-Minuten-TTL verwenden, während eine komplexe Support-Konversation 30 Minuten oder mehr brauchen könnte.

Implementierung mit Grepture

Mask and Restore zum Laufen zu bringen dauert Minuten. Das SDK umhüllt Ihren bestehenden KI-Provider-Client, und Regeln werden im Dashboard konfiguriert — keine Code-Änderungen nötig, abgesehen vom initialen Setup.

import Grepture from "@grepture/sdk";
import OpenAI from "openai";

const grepture = new Grepture({
  apiKey: process.env.GREPTURE_API_KEY,
  proxyUrl: "https://proxy.grepture.com",
});

const openai = new OpenAI({
  ...grepture.clientOptions(),
  apiKey: process.env.OPENAI_API_KEY,
});

// Mit Mask-and-Restore-Regeln, die im Dashboard konfiguriert sind:
// - PII in der Anfrage erkannt → durch Token ersetzt
// - LLM verarbeitet tokenisierten Prompt
// - Token in der Antwort → zu Originalwerten wiederhergestellt
const response = await openai.chat.completions.create({
  model: "gpt-4o",
  messages: [
    { role: "system", content: "You are a helpful customer support agent." },
    { role: "user", content: "Hi, I'm Sarah Miller, my email is sarah@example.com" },
  ],
});

// response.choices[0].message.content enthält wiederhergestellte Werte
// Das LLM hat nie "Sarah Miller" oder "sarah@example.com" gesehen
console.log(response.choices[0].message.content);
// → "Hi Sarah Miller! How can I help you today? I have your email sarah@example.com on file."

Das ist alles. Das @grepture/sdk-Paket leitet den Traffic durch den Grepture-Proxy, wo Mask-and-Restore-Regeln automatisch angewendet werden. Der OpenAI-Client funktioniert exakt wie gewohnt — dieselbe API, dieselben Types, dieselbe Streaming-Unterstützung.

Im Dashboard können Sie den gesamten Ablauf im Traffic-Log sehen: die ursprüngliche Anfrage mit echter PII, die tokenisierte Version, die an das LLM gesendet wurde, und die wiederhergestellte Antwort, die an den Nutzer zurückging.

Regeln werden im Rule Builder des Dashboards konfiguriert. Sie wählen den Erkennungstyp (E-Mail, Name, Telefon usw.), die Aktion (Mask and Restore) und optional eine benutzerdefinierte TTL. Keine Code-Deployments nötig, um Ihre Schwärzungs-Policy zu ändern. Die Schnellstart-Anleitung führt in etwa fünf Minuten durch das vollständige Setup.

Grepture funktioniert mit OpenAI, Anthropic, Google AI, Azure OpenAI und jedem OpenAI-kompatiblen Anbieter. Die Mask-and-Restore-Logik ist anbieterunabhängig — sie operiert auf den Request- und Response-Payloads, unabhängig davon, welches Modell auf der anderen Seite steht.

Wann welchen Ansatz verwenden

Die Wahl der richtigen Aktion hängt vom Kontext ab.

  • Mask and Restore — Verwenden, wenn die LLM-Antwort an den Nutzer zurückgeht und die Originalwerte enthalten muss. Chatbots, Kundensupport-Agenten, personalisierte Content-Generierung, E-Mail-Entwürfe. Das ist die richtige Wahl, wenn Schutz UND Funktionalität gebraucht werden.

  • Permanente Schwärzung — Verwenden, wenn die Originalwerte nicht zurückgebraucht werden. Audit-Logs, Analytics, Modell-Evaluierungs-Pipelines, internes Monitoring. Die Daten sind weg, und genau das ist gewünscht.

  • Blockieren — Verwenden für hochsensible Erkennungen, bei denen das Vorhandensein bestimmter Daten bedeutet, dass etwas falsch läuft. API-Keys, Secrets, medizinische Daten in Kontexten, in denen sie nicht auftauchen sollten. Wenn die Erkennung anschlägt, sollte die Anfrage gar nicht stattfinden — Blockieren ist die korrekte Reaktion.

  • Nur protokollieren — Verwenden bei der initialen Bereitstellung. Datenflüsse verstehen, bevor Richtlinien durchgesetzt werden. Eine Woche im Beobachtungsmodus laufen, prüfen welche PII tatsächlich durch das System fließt, dann entsprechende Aktionen festlegen. Fast jeder entdeckt mehr PII als erwartet.

Diese Ansätze schließen sich nicht gegenseitig aus. Ein typisches Produktions-Setup könnte so aussehen:

  • Namen und E-Mails: Mask and Restore (nutzer-orientierte Antworten brauchen sie)
  • Sozialversicherungsnummern und Ausweisdaten: permanente Schwärzung (kein legitimer Grund für das LLM, diese zu haben)
  • API-Keys und Secrets: blockieren (ihr Vorhandensein deutet auf einen Prompt-Injection-Versuch oder fehlkonfigurierte Eingabe hin)
  • Alles andere: protokollieren (Transparenz aufbauen, bevor durchgesetzt wird)

Beginnen Sie breit mit Logging, verengen Sie auf spezifische Aktionen, wenn Sie Ihre Datenmuster verstehen, und passen Sie TTLs basierend auf Ihren Konversationslängen an. Das Ziel ist eine Policy, die sensible Daten schützt, ohne der Anwendung bei ihrer Arbeit im Weg zu stehen.