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

Tue, 21 Apr 2026 12:00:00 +0000

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.

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

Tue, 21 Apr 2026 10:00:00 +0000

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.

Dsgvo on René Zander | KI-Automatisierungsberater

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

Das Problem

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