95 % der PII-Redaktion brauchen keinen LLM. Die anderen 5 % sind das, was Ihre Maske durchlässt.

Ein IT-Leiter eines SAP-Betriebs hat es mir kürzlich klar gesagt: “Jedes Mal wenn wir unsere Produktionsdaten in unsere Non-Prod-Landschaften kopieren, sickern PII-Daten durch. Und nein, wir werfen keinen LLM darauf. Das ist das Tausendfache der Rechenleistung, die wir heute schon fahren.”

Er hat recht.

Der größte Teil des PII-Redaktionsproblems in Enterprise-Daten ist kein Neural-Network-Problem. Es ist ein Lookup-Table-Problem. Und die etablierten Tools lösen es längst. SAP TDMS, Delphix, Informatica, IBM InfoSphere Optim. Alle schemakundig. Alle zeilenbasiert. Alle deterministisch.

Die 95%, wo Deterministik gewinnt

In einer SAP-Produktionsdatenbank sagt Ihnen das Schema fast alles. KNA1-NAME1 ist ein Kundenname. BSEG-IBAN ist ein Bankkonto. USR02-BNAME ist eine Benutzer-ID. Eine YAML-Regel sagt: “Für diesen Spaltentyp ersetze mit diesem Muster.” Fertig.

Die Rechnung ist brutal. Ein Regex plus Lookup-Table kostet Mikrosekunden pro Zeile. Ein 1,5-Milliarden-Parameter-Modell kostet 10 bis 50 Millisekunden pro Zeile, selbst auf einer GPU. Das sind drei bis fünf Größenordnungen. Ein nächtlicher Batch-Kopierjob, der mit TDMS bis zum Morgen fertig ist, würde mit einem LLM in der Schleife Wochen dauern.

Rechenleistung ist nicht einmal das Hauptargument.

Referenzielle Integrität ist es. “Anna Müller” muss in 200 Tabellen konsistent zu “Person_47” werden. KNA1, VBAK, VBKD, BSEG — wohin auch immer die Kundennummer wandert. Deterministische Pseudonymisierung mit HMAC und scope-spezifischem Salt liefert das umsonst. Neuronale Outputs driften.

Auditierbarkeit ist es. Der Aufseher fragt: “Zeigen Sie mir die Regel, die diese Spalte maskiert hat.” Eine YAML-Regel ist verteidigbar. Ein Modelloutput nicht.

Für jedes SAP-Feld mit bekanntem Schematyp gewinnt also deterministische Maskierung. Punkt. Lassen Sie sich von niemandem eine Neural-Network-getriebene “Modernisierung” dieser Schicht verkaufen.

Wo ein fein abgestimmtes Modell seine Rechenleistung verdient

Hier ist, was TDMS, Delphix und ihre Konkurrenten stillschweigend übersehen.

Freitextspalten. BSEG-SGTXT, das Langtext-Feld, in das jemand geschrieben hat: “Ansprechpartner Anna Müller, Tel +49-170-…”. Ticket-Beschreibungen aus ServiceNow, gespiegelt ins Dev-System. E-Mail-Bodies als CLOBs. ADRC-Annotationen. Der Spaltentyp ist “Text”. Der Inhalt ist eine PII-Goldgrube.

Unstrukturierte Anhänge. PDFs, gescannte Rechnungen, per OCR erfasste Verträge, die via ArchiveLink ins Dev-System gezogen werden. Namen und IBANs mitten im Fließtext, nicht in einer Spalte.

Schema-Drift. Berater legen Z-Tabellen an. Der Data Steward hat sie noch nicht klassifiziert. Deterministische Tools wissen nicht, dass die Spalte PII enthält. Sie lassen die Daten ungefiltert durch.

Regelbasierte Tools tun in diesen Fällen eines von zwei Dingen. Sie wischen die komplette Spalte weg, zerstören damit die Testrealität, und das Dev-Team kann keine Bugs gegen realistische Daten debuggen. Oder sie übersehen die PII komplett — und Sie haben einen Compliance-Vorfall.

Ein deutsch-spezialisierter Redactor lohnt sich hier, weil die Alternative nicht “schnellerer Regex” ist. Sie ist “gar keine Abdeckung”.

Die hybride Architektur

Das ist der Teil, der produktiv geht.

1. Klassifikator-Durchgang über die SAP-Kopie. Günstige Heuristiken (Spaltenname-Schlüsselwörter, Spaltentyp, Regex auf Beispielwerten) flaggen jede Spalte als structured_pii, free_text oder safe.
2. Deterministischer Masker verarbeitet structured_pii. TDMS oder was immer Sie bereits einsetzen.
3. Fein abgestimmter LLM-Redactor läuft nur auf free_text, Anhängen und unklassifizierten Z-Spalten.
4. Konsistenz-Brücke. Beide Pfade teilen sich eine Pseudonymtabelle, gekeyed auf HMAC(wert, tenant_salt). “Anna Müller” wird zu “Person_47” — egal, ob der Regex oder das Modell sie erwischt hat.

Rechenbudget: Der LLM läuft auf vielleicht 1 bis 5 Prozent der Zellen. Die Gesamtkosten werden weiterhin von der deterministischen Schicht dominiert. Sie ersetzen TDMS nicht. Sie decken seine blinden Flecken ab.

Was ich nicht verspreche

Drei Dinge, die ich Ihnen nicht verkaufe:

1. Der LLM ist günstiger als ein Regex. Ist er nicht. Nie.
2. Er ersetzt Ihren etablierten Maskierungs-Anbieter. Tut er nicht.
3. Ein Benchmark gegen TDMS auf strukturierten Spalten ist aussagekräftig. Den Benchmark verlieren Sie. Benchmarken Sie auf Freitext und Anhängen, wo deterministische Tools gegen Null scoren.

Der ehrliche Pitch an den IT-Leiter war dieser: “Sie haben recht. Für die 90% strukturierter Fälle behalten Sie TDMS. Das Modell ist die Long-Tail-Schicht. Es läuft nur über die Freitextfelder und Anhänge, die Ihre aktuellen Tools stillschweigend durchlassen. Kleiner Job. Anderes Problem.”

Das ist das Gespräch, das landet. Nicht “ersetzen Sie Ihren Stack”. Nicht “KI-powered everything”.

Regex für das Schema. LLM für die Schatten.

Der fein abgestimmte deutsche PII-Redactor, den ich für die Long-Tail-Schicht verwende, ist auf Hugging Face: renezander030/qwen-2.5-1.5b-de-pii-redactor. Lassen Sie ihn über Ihre eigenen Freitextspalten laufen, prüfen Sie, wo TDMS PII still durchreicht, und entscheiden Sie von dort aus.

Wo lässt Ihr aktueller Masker durch?