Deutscher PII-Redactor: Der 5%-Layer, den TDMS & Co. übersehen

Das Problem

Jeder SAP-Betrieb kopiert Produktionsdaten in Dev-, QA- und Trainingslandschaften. So reproduziert man Kunden-Bugs mit echten Daten, lastet ein Release, und schult Endanwender auf Daten, die aussehen wie das, was sie am Montag im System sehen.

Jede Kopie ist ein Compliance-Ereignis. DSGVO, Art. 5 verlangt, dass personenbezogene Daten nur zu legitimen Zwecken verarbeitet und wo möglich pseudonymisiert werden. Die meisten DACH-Unternehmen haben ein deterministisches Maskierungstool beschafft — SAP TDMS, Delphix, Informatica TDM, IBM InfoSphere Optim — und in den Kopierjob eingebunden. Das Tool schreibt klassifizierte Spalten um: KNA1-NAME1 wird zu Mustermann, BSEG-IBAN wird zu einer Fake-IBAN mit gültiger Prüfsumme, USR02-BNAME wird zu USER042. Das deckt ~95% der PII ab, die in schemakundigen, zeilenbasierten Spalten steckt.

Die verbleibenden 5% sind, wo in jedem Programm, das ich gesehen habe, Daten durchsickern:

• Freitext-NOTES-Spalten auf Kunden-, Lieferanten- und Fall-Tabellen. Agents tippen Namen, Telefonnummern, IBANs und interne IDs hinein, die das Schema nicht vorhersehen kann.
• Unklassifizierte Z-Tabellen. Kundenspezifische Erweiterungen, die der Data Steward noch nicht klassifiziert hat. Das Maskierungstool kennt sie nicht und lässt sie unverändert.
• OCR’te Scan-Anhänge. Rechnungen, Ausweise, Versichertenkarten. Vollständiger Name, Geburtsdatum, teils Bankdaten — alles als Rohtext in der Anhangstabelle.
• Long-Tail-Entity-Typen. Deterministische Tools wissen, wie man eine deutsche IBAN maskiert. Sie kennen aber nicht den Unterschied zwischen einer Straßenadresse und einer Produktbeschreibung, wenn nicht jede Spalte klassifiziert ist.

Einen General-Purpose-LLM über 100% der Produktionsdaten laufen zu lassen, um das zu finden, ist keine Option — der IT-Leiter eines mittelständischen DACH-Herstellers formulierte es klar: “Das ist das Tausendfache der Rechenleistung, die wir heute schon fahren.” Er hatte recht. Die 95% brauchen keinen LLM. Aber die 5% schon.

Die Lösung

Ein 1,5-Milliarden-Parameter-fein-abgestimmter deutscher PII-Redactor, der sich hinter der deterministischen Maskierung einklinkt. Die Kopier-Pipeline sieht dann so aus:

1. Extrahieren der Produktionsdaten (SAP-Table-Unload, Datenbank-Dump, Datei-Export).
2. Strukturierte Spalten maskieren mit dem bestehenden Tool (TDMS, Delphix, Informatica). Unverändert.
3. Freitext und unklassifizierte Spalten routen in den Redactor. Ein kleiner Klassifikator entscheidet, welche Zeilen ihn brauchen — die meisten nicht.
4. Redactor liefert strukturiertes JSON: { redacted_text, entities, risk_level, needs_human_review }.
5. Rückführung des redigierten Freitexts in den maskierten Export.
6. Laden in Dev / QA / Training — End-to-End DSGVO-konform.

Der Redactor ist ein LoRA-Adapter auf Qwen2.5-1.5B-Instruct. Klein genug für eine einzelne Consumer-GPU, schnell genug, um mit einem nächtlichen Kopierjob Schritt zu halten, spezifisch genug für die zwölf deutschen Entity-Typen, die in Enterprise-Daten zählen: Name, Adresse, IBAN, Steuer-ID, Sozialversicherungsnummer, Krankenkassennummer, Geburtsdatum, Telefon, E-Mail, IP, Kfz-Kennzeichen, Kontoinhaber.

Der Output ist strukturiert, nicht span-basiert. Nachgelagerte Tools bekommen ein JSON-Dokument, das sie validieren und verarbeiten können — keinen hervorgehobenen Text-Blob. Das ist der Unterschied zwischen “Demo gebaut” und “Service ausgeliefert”.

Pseudonyme sind referenziell konsistent. Dieselbe Person wird in jeder Freitextspalte ihres Datensatzes zu [PERSON_1]. Dev-Engineers können weiterhin über Tabellen joinen und den Bug reproduzieren. Referenzielle Integrität ist das Feature, das Enterprise-Maskierungstools am stärksten hüten — der Redactor respektiert es.

Läuft vollständig auf der Kunden-Hardware. Keine Drittanbieter-API, kein Daten-Egress, keine Per-Token-Abrechnung. Der Adapter wird als 150-MB-Datei auf HuggingFace verteilt. Auf dem Basismodell innerhalb Ihrer Landschaft laden — fertig.

Das Ergebnis

Der v1-Adapter, trainiert auf 75 synthetischen deutschen Geschäftsdokumenten und evaluiert auf einem Held-out-Set von 16, hebt die drei entscheidenden Metriken:

Entity F1 ist der Kern-Qualitätsgrenzwert — findet und typisiert das Modell PII in einem Freitext korrekt? Ein 2,4-facher Lift zeigt, dass der Adapter die deutschen Muster gelernt hat, die das Basismodell verfehlt (besonders IBAN-Formatierung, Steuer-ID-Layout und deutsche Adresskonventionen).

JSON-Parse-Validität ist das “Kann man das wirklich produktiv nutzen”-Gate. 100% heißt: jede Inferenz liefert ein Dokument, das die nachgelagerte Pipeline ohne try/except-Fallback laden kann. Kritisch für nächtliche Batch-Jobs, bei denen ein einziger fehlerhafter Output den gesamten Stream anhält.

Risk-Level Exact-Match ist der Klassifikator-Kopf, der entscheidet, ob ein Dokument eine menschliche Prüfung braucht. Von Münzwurf (0,50) zu fast perfekt (0,94) zu kommen bedeutet: Compliance-Teams sehen nur Datensätze, die sie wirklich brauchen — nicht jeden vierten.

Review-EM blieb bei 0,69 flach, und das ist mein Hauptfokus für v2: den Human-Review-Signal doppelt labeln für Konsistenz, das Trainings-Corpus skalieren, und einen externen handkuratierten Eval-Slice mit Push-Gate ergänzen.

Positionierung

Dieses Modell ist kein Ersatz für Ihren deterministischen Maskierungs-Anbieter. TDMS, Delphix, Informatica und IBM Optim sind besser als jeder LLM bei spaltenweiser Maskierung strukturierter Daten — günstiger, schneller, auditierbar, und sie besitzen bereits den Graph referenzieller Integrität Ihrer Landschaft. Rippen Sie sie nicht heraus.

Positionieren Sie dieses Modell strikt als den Long-Tail-Layer für den Text, den Ihre schemakundigen Tools nicht sehen. Das ist der ehrliche Pitch, und es ist der, der bei Datenschutzbeauftragten, SAP-Basis-Teams und Architekten landet, die schon einmal von “KI macht alles”-Sales-Pitches verbrannt wurden.

Stack & Links

• Basismodell: Qwen2.5-1.5B-Instruct
• Training: LoRA via PEFT / TRL, synthetische deutsche Geschäftsdokumente
• Hardware (Training): RunPod A40, ~90 Minuten End-to-End
• Hardware (Inferenz): einzelne Consumer-GPU, CPU möglich für Batch-Jobs
• Lizenz: Apache 2.0
• Output: Pydantic-validiertes strukturiertes JSON
• Adapter auf HuggingFace: renezander030/qwen-2.5-1.5b-de-pii-redactor
• Ausführlicher Artikel im Blog: 95% der PII-Redaktion brauchen keinen LLM. Die anderen 5% sind, wo Ihr Masker durchlässt.

Wenn Sie für Prod→Non-Prod-Datenkopien in einer DACH-Landschaft verantwortlich sind und vermuten, dass Ihr Masker die 5% durchlässt, auf die dieses Modell zielt, gehe ich gerne Ihre konkrete Pipeline mit Ihnen durch. Keine Slide-Deck-Show, dreißig Minuten, Sie bringen ein Beispiel-Spalte mit.