Formatbewahrende Anonymisierung: Warum XXXX Ihre KI-Pipeline zerstört

Das Problem mit XXXX

Hier eine Kreditkartennummer, die die Luhn-Prüfung besteht: 4532-1488-0343-6467. Redigieren Sie sie auf die naive Weise und schicken Sie das an ChatGPT:

Ist XXXX-XXXX-XXXX-XXXX eine gültige Kartennummer?

Das Modell antwortet ungefähr „Nein, das ist ein Platzhalter, keine echte Kartennummer". Technisch korrekt. Praktisch nutzlos. Die Frage, die Sie eigentlich beantwortet haben wollten, lautete „Ist die Karte, die mein Nutzer gerade eingegeben hat, strukturell gültig", und Sie haben jedes Signal vernichtet, das das Modell für diese Antwort gebraucht hätte.

Jetzt probieren Sie die formatbewahrende Umschreibung:

Ist 4532-1488-XXXX-6467 eine gültige Kartennummer?

Das Modell kann nun argumentieren: führende 4 bedeutet Visa, 16 Stellen passen zur Visa-Länge, die letzten 4 sind sichtbar für die Anzeige, die mittleren Bytes sind klar redigiert. Es beantwortet die eigentliche Frage — ja, das Muster ist mit einer echten Visa konsistent, die Prüfsumme lässt sich neu berechnen, und so zeigen Sie sie dem Kunden an.

Das ist der Unterschied zwischen naiver Redaktion und formatbewahrender Anonymisierung. Erstere ist ein Sicherheits-Häkchen, das das Produkt kaputtmacht. Letztere ist, was Zeuslock standardmäßig ausliefert, weil die Alternative — Nutzer, die das DLP abklemmen, weil es ihren KI-Assistenten dumm gemacht hat — sicherheitstechnisch strikt schlimmer ist als jede Restleckage.

Naive Redaktion ist Informationsvernichtung

Der Grund, warum Entwickler zu XXXX greifen, ist, dass es sich sicher anfühlt. Es ist die stärkstmögliche Schwärzung: jedes Byte des Geheimnisses ist weg. Das Problem ist, dass Sie auch die Metadaten zerstört haben. Drei Dinge reisen mit einem realen Wert mit, und Sie wollen fast nie alle drei verlieren:

• Das Format. Eine 16-stellige Zeichenkette mit Bindestrichen ist eine Kreditkarte. Eine IBAN beginnt mit zwei Buchstaben. Ein JWT enthält zwei Punkte. Ein Bearer-Token ist base64url. Das Format ist, wie das LLM weiß, worüber es spricht.
• Die Semantik innerhalb des Formats. Die führende 4 einer Visa, das Länderpräfix einer IBAN, das AKIA-Präfix eines AWS-Langzeitschlüssels, das kid in einem JWT-Header — all das sagt dem Modell, welche Bibliothek, welcher Anbieter, welche Jurisdiktion relevant ist.
• Die nicht geheimen Endungen. Letzte 4 Stellen einer Karte, Länge des E-Mail-Local-Part, IBAN-Prüfziffern — der Kontext, den die KI braucht, um eine umsetzbare Antwort zu geben.

Streichen Sie alle drei, und Sie bitten die KI nicht mehr um Hilfe — Sie bitten sie zu raten.

Fall 1: Kreditkarten

Nehmen Sie 4532-1488-0343-6467. Luhn-gültig, 16 Stellen, die führende 4 identifiziert Visa, die BIN 453214 löst auf einen bestimmten Issuer auf. Drei Redaktionsstrategien, drei sehr unterschiedliche LLM-Verhalten.

Die mittlere Zeile produzieren die meisten selbstgebauten DLP-Skripte, und es ist auch die Zeile, die Nutzer dazu treibt, die echte Kartennummer in einen privaten ChatGPT-Account zu kopieren, um eine echte Antwort zu bekommen. Die dritte Zeile hält sowohl das Sicherheitsteam als auch den Nutzer produktiv.

Einen formatbewahrenden, Luhn-gültigen Ersatz in Python generieren

Unten ein winziger Generator. Bei einer echten Kartennummer behält er die ersten sechs und die letzten vier Stellen und schreibt die Mitte so um, dass das Ergebnis weiterhin die Luhn-Prüfung besteht. Das Original wird nicht geloggt und nicht persistiert.

import secrets

def luhn_check_digit(digits: str) -> int:
    total = 0
    for i, ch in enumerate(reversed(digits)):
        d = int(ch)
        if i % 2 == 0:
            d *= 2
            if d > 9:
                d -= 9
        total += d
    return (10 - (total % 10)) % 10

def format_preserve_card(original: str) -> str:
    digits = ''.join(c for c in original if c.isdigit())
    if len(digits) != 16:
        raise ValueError('16-stellige Karte erwartet')
    bin6, last4 = digits[:6], digits[-4:]
    # 5 zufaellige Ziffern in der Mitte + 1 berechnete Luhn-Pruefziffer
    middle = ''.join(str(secrets.randbelow(10)) for _ in range(5))
    candidate = bin6 + middle + '0' + last4
    check = luhn_check_digit(candidate[:-1] + last4[:-1])
    fake = bin6 + middle + str(check) + last4
    return f'{fake[:4]}-{fake[4:8]}-{fake[8:12]}-{fake[12:]}'

Die Ausgabe ist eine realistisch aussehende 16-stellige Visa, die kein Zahlungsdienstleister je belasten wird, weil sie statistisch fast sicher nicht vergeben ist. Das LLM behandelt sie als Karte, der Issuer wird korrekt abgeleitet, der Nutzer bekommt eine brauchbare Antwort.

Fall 2: IBAN

Eine IBAN wie FR76 3000 6000 0123 4567 8901 234 trägt vier Bedeutungsebenen: Land (FR), Prüfziffern (76), Bank-/Filialcode (3000 6000), Kontonummer und eine nationale Prüfziffer. Das naive XXXX vernichtet alle vier. Fragen Sie das LLM danach „aus welchem Land stammt dieses Konto?" und Sie bekommen eine Verweigerung.

Formatbewahrende Umschreibung: FR76 XXXX XXXX XXXX XXXX XXXX 234. Land und mod-97-Prüfziffern bleiben erhalten. Ein nachgelagertes Modell antwortet souverän „Frankreich", und ein Generator kann eine plausible Prüfsumme rekonstruieren, falls Ihre Testpipeline eine braucht.

Fall 3: AWS-Zugangsschlüssel

Ein AWS-Langzeitschlüssel sieht aus wie AKIAIOSFODNN7EXAMPLE. Das Präfix AKIA ist nicht zufällig — es identifiziert den Schlüsseltyp (ASIA für STS-Temporärtoken, AKIA für IAM-Langzeit). Die Länge ist fest 20.

Naive Redaktion zu XXXX sagt dem LLM nichts. Formatbewahrend AKIA**************** sagt ihm „das ist ein IAM-Langzeitschlüssel, Länge 20, geheime Entropie entfernt". Der Ersatz ist kein gültiger Schlüssel — AWS lehnt ihn sofort ab — aber das Modell kann nun korrekt antworten „rotieren Sie über aws iam create-access-key und widerrufen Sie den alten" statt „mit Platzhalter-Zeichenketten kann ich nicht helfen".

Dasselbe Prinzip für Stripe (sk_live_), OpenAI (sk-), GitHub (ghp_), Slack (xoxb-), GitLab (glpat-), npm (npm_). Das Präfix ist der Typ. Präfix behalten, Entropie töten.

Fall 4: JWTs

Ein JWT hat drei mit Punkten getrennte Segmente: header.payload.signature. Der ganze Sinn eines JWT besteht darin, dass man den Header dekodieren kann, um den Algorithmus zu erfahren, ohne die Signatur zu prüfen. Wenn ein Entwickler ein echtes JWT in Claude einfügt mit der Frage „warum scheitert die Token-Validierung", braucht das Modell die Struktur, um sinnvollen Rat zu geben.

Naive Redaktion kollabiert das JWT zu XXXX. Das Modell hat nichts mehr zum Reden. Die formatbewahrende Variante behält die Punkte und Segmentlängen:

eyJhbGciOiJIUzI1NiJ9.XXXXXXXXXXXXXXXX.XXXXXXXXXXXX

Das Modell sieht drei Segmente, kann den sichtbaren Header kommentieren („alg: HS256, Sie wollen wahrscheinlich RS256 für asymmetrische Verifikation"), und die tatsächlichen Signaturbytes reisen nie. Der Entwickler bekommt eine echte Antwort; das Geheimnis bleibt lokal.

Fall 5: E-Mails — der schwierigste

E-Mail ist der Fall, in dem die richtige Umschreibung davon abhängt, was Sie schützen wollen. Zwei vernünftige Optionen für alice@acme.com:

Über die mittlere Zeile sollten Sie hart nachdenken. Die Domain zu erhalten leakt den Arbeitgeber des Nutzers. Für ein Support-Tool ist das in Ordnung — der Agent weiß, dass es acme.com ist — aber für eine Lebenslauf-Screening-Pipeline kann es geschützte Merkmale leaken. Dieselbe Regel wie bei IBANs: Formatbewahrung ist eine Policy, kein Default.

Wann Formatbewahrung die falsche Wahl ist

Der ganze Zweck von Formatbewahrung ist, dass das Format semantisch nützliche, nicht geheime Information trägt. Es gibt Kategorien, in denen das Format selbst das Geheimnis ist. In diesen Fällen härter anonymisieren oder blockieren.

• SSN-artige interne Kennungen. Die ersten drei Ziffern einer US-SSN kodierten früher den Ausstellerstaat. Die französische NIR kodiert Geschlecht, Geburtsjahr, -monat, -département und -kommune. Eine NIR „formatbewahrend" zu behandeln, heißt Demografie zu leaken. Richtig ist vollständige Redaktion oder Blockieren. Das BfDI, die CNIL und die AEPD vertreten diese Position für besondere Kategorien personenbezogener Daten unter DSGVO.
• Interne Kunden-IDs. Wenn Ihre Kunden-ID ACME-2024-018472 lautet und das Jahr die Onboarding-Kohorte kodiert, leakt das Format Geschäftsinformationen. Behandeln Sie sie als opak.
• Sequenzielle IDs in kleinem Raum. Wenn nur 5000 Mitarbeiter existieren und die Mitarbeiter-ID sequenziell ist, reduziert Formatbewahrung die Entropie der Redaktion auf nahezu null — das Modell (oder ein neugieriger Beobachter) kann die Person aus dem Kontext re-identifizieren.
• Alles, wofür die Aufsichtsbehörde explizit gesagt hat „bewahren Sie pseudonyme Kennungen nicht ohne Begründung auf". Wenn Sie keinen legitimen Verarbeitungszweck für das Behalten des Präfixes benennen können, lassen Sie das Präfix weg.

Die Abwägung, die Zeuslock getroffen hat, und warum

Zeuslocks Defaults neigen zur Strukturerhaltung. Der Grund ist eine simple Verhaltensbeobachtung: wenn das DLP den KI-Assistenten unbrauchbar macht, gibt der Nutzer nicht den KI-Assistenten auf. Er gibt das DLP auf. Er kopiert den Prompt in einen privaten ChatGPT-Account, aufs Handy oder in den Browser im Coffeeshop nebenan. Das Leck passiert trotzdem, und Sie haben zusätzlich die Audit-Spur verloren.

Das Schwierigste am Bau eines DLP für LLMs ist nicht die Erkennung. Es ist, das geschützte Erlebnis so gut zu machen, dass der Nutzer es nicht aktiv zu umgehen versucht.

Formatbewahrende Anonymisierung ist die technische Primitive, die das ermöglicht. Der Nutzer bekommt weiter nützliche Antworten, die geheimen Bytes bleiben auf dem Laptop, und der Operator hat eine vollständige Audit-Spur darüber, welcher Detektor ausgelöst und welche Umschreibung angewandt wurde. Pro Datentyp können Sie jede Umschreibung bis zu XXXX verschärfen oder zu Blockieren eskalieren — aber der Default bleibt strukturiert-aber-falsch, weil das der Default ist, der den Kontakt mit echten Nutzern überlebt.

Was als Nächstes zu tun ist

1. Auditieren Sie Ihre aktuelle Redaktion. Wenn Sie irgendwo in Ihrem Stack erkannte Werte durch [REDACTED], XXXX oder einen leeren String ersetzen, bevor sie ein LLM erreichen, degradieren Sie die Antwort ohne Sicherheitsgewinn gegenüber einer strukturierten Umschreibung.
2. Wählen Sie die Formatbewahrungs-Policy pro Datentyp. Karten und JWTs profitieren fast immer. IBANs und E-Mails sind Ermessensfragen. SSN-artige Kennungen sollten meist vollständig redigiert werden.
3. Zeigen Sie dem Nutzer die Umschreibung vor dem Senden. Die Vorab-Vorschau von Zeuslock vermittelt die Gewohnheit schneller als jedes Schulungsprogramm — siehe den Operator-Leitfaden zur Konfiguration der Erkennungsrichtlinien für den empfohlenen Rollout Monitor → Anonymisieren → Blockieren.