Niemand misst PII-Erkennung auf Deutsch. Also trainierte ich.

Jeder PII-Detektor, den man kaufen oder herunterladen kann, scheitert an deutschem Text auf nachprüfbare Weise. Die öffentlichen Benchmarks messen Englisch, die Anbieter versprechen 99 Prozent, und die Kennungen, die eine deutsche Firma tatsächlich schwärzen muss, SVNR, Steuer-Identifikationsnummer, KVNR, fehlen in jedem Trainingsdatensatz. Also habe ich einen eigenen Detektor trainiert. Er misst F1 0,916.

Was messen die öffentlichen Benchmarks?#

Nimm PIIBench, den breitesten veröffentlichten Benchmark-Korpus: zehn Datensätze, zusammengeführt zu 2,37 Millionen annotierten Sequenzen über 48 PII-Typen. Die Autoren ließen acht veröffentlichte Systeme dagegen antreten, Microsoft Presidio eingeschlossen. „All systems achieve span-level F1 below 0.14“, steht im Paper, und das beste davon, Presidio mit 0,1385, zeigt „zero recall on most entity types“.

Das stärkste offene Modell schneidet besser ab. GLiNER2-PII, ein Modell mit 0,3 Milliarden Parametern, trainiert auf 4.910 synthetischen Texten, erreicht im Durchschnitt F1 0,471 auf dem SPY-Benchmark und schlägt den Privacy-Filter von OpenAI, der bei 0,373 liegt. Beide Zahlen liegen weit unter den 99 Prozent der Marketingseiten.

Im Kleingedruckten verschwindet Deutsch. Die GLiNER2-PII-Autoren benennen die Grenze selbst: „The evaluation covers only legal and medical documents“, beides Englisch. PIIBench führt mehrsprachige Korpora zusammen, liefert aber keine Ergebnisse pro Sprache. Einen deutschen PII-Benchmark hat niemand veröffentlicht. Nicht, weil Deutsch leicht wäre. Sondern weil ihn niemand gebaut hat.

Die Versprechen der Anbieter#

Limina, die Firma bis vor Kurzem als Private AI bekannt, schreibt, ihre Engine „misses between 0.2% and 7%“ der PII-Entitäten, wo allgemeine Lösungen „miss between 13.8% and 46.5%“. Die Seite zitiert „99.5% Accuracy on physician conversations“, nennt 52 Sprachen und führt Deutschland in der Liste der Einsatzländer. Einen Preis nennt die Seite nicht. Die Handlungsaufforderung lautet „Talk to an Expert“.

Selbst wörtlich genommen sagen diese Zahlen zwei Dinge. Erstens setzt das Marketing des Anbieters die Fehlrate allgemeiner Werkzeuge mit bis zu 46,5 Prozent an, und das deckt sich mit dem, was ich gesehen habe, als englisch trainierte Detektoren über deutsche Kundendokumente liefen: Die strukturierten Kennungen gingen unangetastet durch. Zweitens nennt ernsthafte Schwärzungssoftware in diesem Markt ihren Preis erst nach einem Verkaufsgespräch, wenn überhaupt.

Ein weiteres Signal steckt in der Infrastruktur. Presidio, jahrelang die Standardantwort, ist kein Microsoft-Produkt mehr. Die Dokumentation ist zur Gemeinschaftsorganisation Data Privacy Stack umgezogen. Die kostenlose Basis, auf der alle aufbauten, ist heute ein Freiwilligenprojekt.

Die Formate sind öffentlich, also kommt die Regex zuerst#

Eine deutsche Kennung ist kein freier Text. Die Rentenversicherungsnummer hat eine publizierte Form: zwei Ziffern, sechs Ziffern, ein Buchstabe, drei Ziffern. Die Steuer-Identifikationsnummer hat elf Ziffern und beginnt nie mit null. Personalausweis und Reisepass trennen die Buchstabenpools nach den Regeln seit November 2021. Vierzehn dieser Formate liegen in meinem Build als Regex-Muster vor, jedes Muster von Hand gegen die offizielle Spezifikation geprüft.

Diesen Satz würde ich jedem unterschreiben, der ein LLM-Projekt budgetiert: Das Sprachmodell entscheidet in diesem System nichts. Es half am Rand: Formate kartieren, Varianten für die Generatoren entwerfen, Vorlagen umformulieren. Es verwechselte die Steuernummer mit jeder anderen Ziffernfolge des Dokuments. Meine erste Version, nur Modell, erreichte bei Steuer-IDs ein F1 von 0,452. Im fertigen Build entscheidet bei Überschneidungen die Regex, und das Modell bekommt, was kein Format hat: Namen, Adressen, Passwörter im Kontext.

Warum die Trainingsdaten synthetisch sind#

Das eine Material, auf dem dieses Projekt nicht trainiert, sind echte Kundendokumente, denn genau dieses Material zu schwärzen ist der Zweck des Werkzeugs. Der Korpus ist deshalb synthetisch: über 50.000 Beispiele aus Musterfamilien, Adressen in deutscher, österreichischer und Schweizer Schreibung, Steuernummer in der alten Länderform und in der einheitlichen Form, Kennzeichen, IBANs mit plausiblen Banken, dazu Sätze ganz ohne PII.

Dieser letzte Teil zählt mehr, als er liest. Eine Version ohne Negativbeispiele sah in jedem Satz personenbezogene Daten, und ihre Präzision brach ein. Die Generatoren folgen auch Regeländerungen, die Ausweis- und Reisepass-Pools sind das aktuelle Beispiel.

Fünf Epochen auf einer kostenlosen T4#

Die Modell-Schicht ist ein nachtrainiertes GLiNER2, 307 Millionen Parameter auf einem mDeBERTa-Backbone. Das Training läuft auf Kaggles kostenloser T4-Stufe, einer 16-GB-GPU, und ein volles Fine-Tuning passt, sobald Batchgröße und Präzision passen. Eine Epoche ist ein Durchlauf durch den Trainingssatz. Meine Läufe nehmen fünf oder mehr, Early Stopping hält den besten Checkpoint zurück, und ein Lauf kostet etwa eine halbe Stunde: fp16, Cosine-Schedule, Warmup. Die GPU-Rechnung ist null.

Die Fehler waren mehr wert als die Hardware. Eine frühere Version fuhr Lernraten, die zehn- bis hundertfach unter den GLiNER2-Empfehlungen lagen, und trainierte auf deutschen Beschreibungen, während die Inferenz nach englischen Labels fragte. Beide Fehler stehen dokumentiert im Repo, und keiner hat Geld gekostet.

Was es heute misst#

Die 0,916 stammen aus meinem eigenen Benchmark: 188 deutsche Beispiele über alle 17 PII-Typen, namensähnliche Strings in Nicht-PII-Rollen, unvollständige IBANs, österreichische und Schweizer Formate. Er ist mein Benchmark, abgestimmt auf das, was Firmen wirklich senden: Tickettexte, Briefe, Formulare. Das ist Stärke und Einschränkung zugleich. Den öffentlichen deutschen Benchmark gibt es nicht, ihn zu bauen war Teil der Arbeit. Das Ziel der nächsten Datenrevision ist 0,95, die Fehlerliste steht schon: Lernraten, mehr Negativbeispiele, englische Label-Beschreibungen.

Das System läuft im Produktiveinsatz bei Firmen, als CLI über Dokumente und Tickettexte. Als Open Source ist es noch nicht veröffentlicht, kommerzielle Nutzung läuft über info@dimitripisarev.com. Die komplette Architektur, die Formattabellen und das Auswertungsprotokoll stehen in der Schwärzwerk-Case-Study.

Wenn du deutschen Kundentext verarbeitest, stelle jedem Anbieter genau eine Frage: Welcher Benchmark hat dein F1 auf Deutsch gemessen? Eine Prozentzahl ohne Datensatz ist Marketing. Beim Outreach-Werkzeug war es dasselbe Muster, dort habe ich eine eigene Engine gebaut. Die Teile, die deine Daten berühren, sollten die Teile sein, die du messen kannst.