Enterprise-KI für PII-Redaktion in sensiblen Dokumenten

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.

Was das betriebswirtschaftlich bedeutet (Modellrechnung)

Eine Modellrechnung mit offenen Annahmen, damit Sie die Zahlen an Ihre Umgebung anpassen können: Ein Unternehmen zieht 4 Datenkopien pro Jahr aus der Produktion. Wird jede Kopie manuell auf durchgerutschte personenbezogene Daten gesichtet (Annahme: 2,5 Personentage je Kopie, interner Vollkostensatz 600 € pro Tag), kostet das 6.000 € pro Jahr, bleibt stichprobenhaft und hängt an einzelnen Personen. Nach dem einmaligen Setup läuft der Redactor je Kopie automatisiert mit, prüft jede Freitextspalte statt Stichproben, und der manuelle Aufwand sinkt auf die Durchsicht der wenigen markierten Fälle. Der eigentliche Wert liegt jedoch nicht in den gesparten Tagen, sondern im geschlossenen DSGVO-Risiko: Die 3-Prozent-Bußgeldstufe rechnet gegen Jahresumsatz, nicht gegen Personentage (Rechnung im EU-AI-Act-Guide).

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.
• Compliance-Einordnung: EU AI Act für den Mittelstand: Fristen, Bußgeld-Rechnung, Referenzarchitektur

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.