Das Leck, ueber das niemand spricht
Die meisten Teams, die heute RAG ausliefern, behandeln ihren Vektorspeicher wie einen Suchindex: Daten rein, Daten raus, weiter. Das mentale Modell ist falsch und aktiv gefaehrlich.
Wenn Sie "Bitte mailen Sie mir an john.doe@example.com zur Bestellung #45192" einbetten und den resultierenden 1536-dimensionalen Vektor in Pinecone, pgvector, Weaviate oder einem anderen Vektorspeicher ablegen, haben Sie einen Datensatz erzeugt, der:
- Unbegrenzt persistiert. Vektorspeicher sind fuer Retrieval gebaut, nicht fuer Lifecycle-Management. Der Vektor existiert, bis ihn jemand loescht — und niemand weiss, welche Vektoren zu welchem Nutzer gehoeren.
- Nicht selektiv loeschbar ist. Das DSGVO-Recht auf Loeschung verlangt, dass Sie die Daten einer Person auf Antrag entfernen. Jeden aus dem Text dieser Person abgeleiteten Vektor zu finden — inklusive Paraphrasen, Teil-Erwaehnungen und nachgelagerten Zusammenfassungen — ist praktisch unmoeglich.
- Abfragbar ist. k-NN-Suche bedeutet: Ein Angreifer mit einer aehnlichen Anfrage kann den Originaltext zurueckholen. Aktuelle Embedding-Inversion-Forschung zeigt, dass ueberraschend grosse Anteile des Quelltexts aus einem einzelnen Embedding rekonstruierbar sind.
- Wieder in Prompts injiziert wird. Das ist der ganze Sinn von RAG. Die PII, die Sie heute einbetten, landet morgen im System-Prompt und geht an das Modell, das Ihr Agent gerade aufruft.
Chat-Completions sind fluechtig. Eine schlechte Logging-Entscheidung dort ist ein begrenzter Vorfall. Vektorspeicher sind dauerhaft. Eine schlechte Embedding-Entscheidung ist ein strukturelles Problem.
Warum "Logs schwaerzen" nicht hilft
Das uebliche PII-Muster in 2026 sieht so aus: Sie proxen Requests durch ein Gateway, das Gateway schwaerzt E-Mails/Telefonnummern/SSNs aus Request und Response vor dem Schreiben ins Traffic-Log, und Ihr Dashboard zeigt saubere Strings. Funktioniert prima fuer Chat-Completions.
Fuer Embeddings faengt dieses Muster nichts Nuetzliches. Das Leck ist nicht im Log — es ist im Vektor, den Sie an OpenAI gesendet und in Pinecone gespeichert haben. Den Log-Eintrag zu schwaerzen, waehrend der Upstream-Call mit dem Original-PII durchgeht, ist genau die falsche Reihenfolge.
Was Sie tatsaechlich brauchen: den Eingabe-String schwaerzen, bevor der Embedding-Request zu OpenAI geht. Der zurueckkommende Vektor wird dann aus "Bitte mailen Sie mir an [EMAIL_REDACTED] zur Bestellung #45192" abgeleitet — und genau dieser Vektor landet im Speicher.
Der Platzhalter-Trick
Es gibt einen subtilen Grund, warum Platzhalter hier die richtige Schwaerzungs-Strategie sind. RAG haengt davon ab, dass aehnliche Eingaben aehnliche Vektoren erzeugen. Wenn Sie E-Mails durch Hashes schwaerzen (a3f9c1...), wird jede E-Mail zu einem einzigartigen Token und bricht die Aehnlichkeit — zwei Support-Tickets ueber "Probleme bei der E-Mail-Zustellung" landen in voellig verschiedenen Regionen des Vektorraums, nur weil die E-Mail-Adressen des Nutzers unterschiedlich sind.
Schwaerzen Sie mit stabilen Platzhaltern ([EMAIL_REDACTED]), wird jede E-Mail zum gleichen Token. Der Vektor fuer "meine E-Mail nutzer1@x.com funktioniert nicht" und "meine E-Mail nutzer2@y.com funktioniert nicht" ist nahezu identisch — genau das Clustering-Verhalten, das Sie fuer Retrieval brauchen.
Gleiche Logik gilt fuer Telefonnummern, SSNs, Adressen, Geburtsdaten. Platzhalter, keine Hashes.
Was wir gebaut haben
Greptures /v1/embeddings-Endpunkt ist ein OpenAI-kompatibler Passthrough, der PII-Schwaerzung auf der Eingabe ausfuehrt, bevor er weiterleitet. Free Tier bekommt regex-basierte Erkennung (E-Mail, Telefon, SSN, Kreditkarte, IP, Adresse, Geburtsdatum); Pro+ ergaenzt NER-basierte Erkennung fuer Namen, Orte und Organisationen.
curl -X POST https://proxy.grepture.com/v1/embeddings \
-H "Authorization: Bearer grp_live_..." \
-H "Content-Type: application/json" \
-d '{
"model": "text-embedding-3-small",
"input": "mailen Sie mir an john@example.com zur Bestellung #12345"
}'
Antwort: eine normale OpenAI-Embeddings-Response, plus zwei Header — x-grepture-redactions: 1 und x-grepture-pii-categories: email — damit Sie wissen, was erkannt wurde.
Wir speichern weder den Eingabetext noch die Response-Vektoren. Der ganze Sinn ist, PII aus dem Vektorspeicher fernzuhalten; sie auf unserer Seite zu speichern wuerde das Feature negieren.
Wann Block-Modus sinnvoll ist
Fuer Workloads, in denen jegliche PII inakzeptabel ist — regulierte Branchen, interne Dokumente, audit-sensitive Daten — setzen Sie x-grepture-on-pii: block. Der Endpunkt liefert 422 statt zu schwaerzen, inklusive der erkannten Kategorien, damit Ihre Anwendung das Problem dem Nutzer zeigen kann, anstatt seinen Input still zu transformieren.
Fuer die meisten RAG-Workloads ist der Default — schwaerzen und durchlassen — das, was Sie wollen. Der Vektorspeicher bleibt nuetzlich, Retrieval funktioniert weiter, und PII verlaesst Ihr Netzwerk nie in einer rekonstruierbaren Form.
Was das nicht loest
Das deckt die Eingabeseite ab. Es schuetzt nicht vor:
- PII im Dokumenten-Korpus, den Sie beim Indexieren einbetten (separates Problem, gleiche Schwaerzungslogik — richten Sie Ihren Indexer ebenfalls auf /v1/embeddings).
- PII, die das LLM in seinen Antworten erzeugt, die Sie dann einbetten.
- Rekonstruktionsangriffe gegen Vektoren, die aus geschwaerztem-aber-identifizierendem Text abgeleitet sind ("der Patient mit der seltenen Erkrankung X in PLZ Y").
Das Vektorspeicher-Leck ist behebbar. Fangen Sie bei den Eingaben an.