Kleines PII-Modell setzt auf lokale Maskierung – mit klaren Grenzen

Was die veröffentlichten Erkennungswerte aussagen

Die Projektseite präsentiert Ergebnisse aus neun Testsätzen, die nach Angaben des Entwicklers vor dem jeweiligen Training weder für das Training noch für die Modellauswahl verwendet wurden. Zusätzlich seien Trainingsdokumente entfernt worden, wenn sie eine Folge von zehn Wörtern mit einem Testdokument teilten. Einige Testsätze enthalten kleingeschriebene Texte, um Eingaben ohne übliche Großschreibung abzubilden. Diese Angaben beschreiben das Evaluationsdesign des Anbieters; eine unabhängige Replikation ist in den vorliegenden Quellen nicht dokumentiert. [1]

Eine zentrale Kennzahl ist der Anteil der Personennennungen, bei denen jedes Nicht-Leerzeichen-Zeichen maskiert wurde. Ein teilweise maskierter Name zählt in dieser Auswertung als nicht vollständig erkannt. Nach der auf der Projektseite dargestellten Auswertung liegt PrivAiTe PII MiniLM in sechs der neun Testsätze mindestens auf dem Niveau des jeweils besten verglichenen Systems. In zwei Testsätzen sind GLiNER PII und im Testsatz mit Urteilen des Europäischen Gerichtshofs für Menschenrechte NVIDIA GLiNER-PII stärker. Die Seite berichtet zudem, dass das Modell gegenüber GLiNER PII in zwei Testsätzen vorne liegt, in fünf gleichauf und in zwei zurück liegt. [1]

Die Resultate unterscheiden sich nach Textsorte. Bei mehrsprachigen Wikipedia- und Nachrichtenentitäten erreicht das Modell laut Tabelle 93,6 Prozent vollständig maskierte Personennennungen; in einer Zusammenstellung aus Europarl- und SwissNER-Daten sind es 97,0 Prozent. Für kurze Sprachassistenten-Anfragen wie im MASSIVE-Datensatz nennt die Seite dagegen 82,7 Prozent und weist GLiNER PII mit 87,9 Prozent als stärker aus. Bei langen juristischen Urteilen im TAB-Datensatz liegt NVIDIA GLiNER-PII mit 74,6 Prozent vor dem MiniLM-Modell mit 63,5 Prozent. [1]

Die zweite Kennzahl, Präzision, misst den Anteil maskierter Zeichen, die in einer annotierten Entität liegen. In Datensätzen, die nur bestimmte Kategorien markieren, können korrekt maskierte, aber nicht annotierte persönliche Daten die Präzision rechnerisch verschlechtern. Der Anbieter weist deshalb auf die Grenzen des Vergleichs hin. Zudem zählen Ergebnisse laut Beschreibung nur dann als statistisch überlegen oder unterlegen, wenn ein gepaarter Bootstrap-Test mit 2.000 Stichproben und 95-Prozent-Intervallen einen Unterschied ohne Null ergibt. Ein Tabellenwert allein belegt folglich nicht in jedem Fall einen belastbaren Vorsprung. [1]

Ein weiterer Benchmark – mit Einschränkungen bei der Vergleichbarkeit

Zusätzlich veröffentlicht der Anbieter Ergebnisse für 627 Dokumente aus TAB, PIILO und Privy. Diese drei Korpora seien beim Training nicht verwendet worden; fünf weitere Korpora des Benchmarks bleiben in dieser Auswertung außen vor, weil das Modell auf deren Trainingsanteilen trainiert wurde. Die Messung bezieht sich hier auf vollständig maskierte direkte Kennungen, darunter Namen, E-Mail-Adressen, Telefonnummern, IDs, Karten- und Kontonummern sowie Geheimnisse. [1]

Für diese drei Korpora nennt die Tabelle 82,7 Prozent vollständig maskierte direkte Kennungen und eine Präzision von 86,4 Prozent für PrivAiTe PII MiniLM in der ONNX-fp32-Ausführung. Die Präzision wurde allerdings nur auf TAB und Privy berechnet, weil PIILO nach Angaben der Projektseite nur einen Teil seiner persönlichen Daten annotiert. Beim Anteil vollständig maskierter direkter Kennungen ist das Ergebnis demnach statistisch nicht von NVIDIA GLiNER-PII zu unterscheiden: Der angegebene Unterschied beträgt 1,4 Punkte, das Intervall reicht von minus 1,3 bis plus 4,1. Die behaupteten Vorteile bei der Präzision sind ebenfalls Ergebnisse dieser vom Entwickler veröffentlichten Benchmark-Auswertung. [1]

Laufzeitwerte gelten für einen konkreten Testaufbau

Die Laufzeitmessungen wurden laut Projektseite auf einem Apple M1 Pro mit acht CPU-Threads durchgeführt. Der Benchmark umfasste 1.607 Dokumente; nach einem Aufwärmaufruf wurde die Erkennung für jedes vollständige Dokument einschließlich der Fensterverarbeitung gemessen. Die Werte sind Mediane aus diesem Aufbau und sollten nicht ohne eigene Messungen auf andere Prozessoren, Eingabelängen oder Produktionslasten übertragen werden. [1]

Für Core ML auf der Neural Engine nennt der Anbieter 5,6 Millisekunden pro Dokument beziehungsweise 9,3 Millisekunden pro 1.000 Zeichen. Für ONNX int8 auf der CPU sind es 14,8 beziehungsweise 22,7 Millisekunden; ONNX fp32 kommt auf 29,5 beziehungsweise 41,2 Millisekunden. Die angegebenen Modellgrößen betragen 224, 113 und 448 Megabyte. [1]

Die verglichenen Konkurrenzmodelle liefen in derselben Auswertung auf der CPU und über ihre jeweiligen Bibliotheken. Der Anbieter nennt etwa 186 Millisekunden pro 1.000 Zeichen für den OpenAI Privacy Filter und 258 Millisekunden für GLiNER PII. Weil die schnellste MiniLM-Zahl auf der Neural Engine und die Konkurrenzwerte auf der CPU gemessen wurden, ist dieser Vergleich nicht als isolierter Architekturvergleich zu lesen. Für eine Beschaffungs- oder Kapazitätsentscheidung wären Messungen auf der tatsächlich vorgesehenen Hardware und mit repräsentativen eigenen Dokumenten erforderlich. [1]

Trainingsdaten, Lizenz und Datenformate

Für das Training kombiniert der Entwickler reale und synthetische annotierte Texte aus mehreren Quellen. Die aufgeführten Datensätze umfassen unter anderem synthetische PII-Beispiele, EU-Rechtstexte, historische Zeitungen, Gerichtsentscheidungen, klinische Fälle, Verwaltungsakte sowie Nachrichten und Social-Media-Texte. Die genannten Sprachen reichen über Deutsch, Englisch und mehrere weitere europäische Sprachen hinaus; einzelne Trainingsquellen decken zusätzliche Sprachgruppen ab. Daraus folgt jedoch keine gleichmäßige Qualität für jede Sprache oder jede der 15 Kategorien. [1]

Das Training bestand nach der Beschreibung aus zwei Stufen: zunächst zwei Epochen auf annotierten Texten, danach weiteren 0,35 Epochen mit zusätzlichen strukturierten Darstellungen wie JSON, YAML, SQL, HTML, CSV und Logzeilen. Dabei seien auch ähnlich benannte Felder ohne persönliche Daten einbezogen worden. Außerdem wurden laut Seite Teile der Dokumente systematisch in Klein- oder Großbuchstaben umgewandelt. Diese Maßnahmen sollen unterschiedliche Schreibweisen und strukturierte Agenten- beziehungsweise Anwendungstexte berücksichtigen; ihre Wirksamkeit ist durch die genannten Benchmarks für einzelne Einsatzdomänen nicht automatisch belegt. [1]

Die Projektseite nennt BSD 3-Clause als Lizenz für das Modell, MIT für das Basismodell und führt die Lizenzen der Trainingsdatensätze separat auf. Sie erklärt, keine der dort aufgeführten Lizenzen beschränke die kommerzielle Nutzung; bei CC BY 4.0 sei die in der NOTICE-Datei genannte Attribution erforderlich. Unternehmen sollten diese Angaben vor einer Integration anhand der jeweiligen Lizenztexte und der bereitgestellten NOTICE-Datei prüfen. [1]

Maskierung ist eine Kontrollschicht, keine Garantie

Die technische Einordnung ist für den Einsatz entscheidend: Eine lokale Erkennung kann verhindern, dass bestimmte gefundene Textstellen an einen externen Dienst übermittelt werden. Sie garantiert aber nicht, dass sämtlicher sensibler Inhalt entfernt wird. Die Projektseite warnt ausdrücklich vor übersehenen Daten und empfiehlt, die maskierten Ergebnisse zu prüfen und strukturierte Kennungen bei Bedarf zusätzlich mit Regeln abzusichern. [1]

Auch allgemeine Leitlinien zum Umgang mit PII in LLM-Workflows empfehlen, Daten vor dem Versand zu erkennen und zu redigieren oder durch neutrale Platzhalter zu ersetzen. Das Lawrence Berkeley National Laboratory betont, dass Filter auf repräsentativen eigenen Beispielen getestet werden sollten, unter anderem auf ungewöhnliche Namensformen, nicht englische Texte und domänenspezifische Kennungen. Es empfiehlt außerdem, Präzision und Recall getrennt zu betrachten: Übersehene Daten bergen ein anderes Risiko als übermäßige Maskierung, die den Nutzwert des Textes mindern kann. [5]

Für einen produktiven Einsatz ergibt sich daraus eine gestufte Kontrolle: Unternehmen können das Modell als lokale Erkennungsschicht in eine Datenpipeline einbauen, sollten jedoch eigene Testsätze mit den tatsächlichen Sprachen, Dokumenttypen und Kennungen erstellen. Ebenso relevant sind die nachgelagerte Ersetzungslogik, der Umgang mit Teiltreffern und die Frage, ob Platzhalter später lokal zurückgeführt werden müssen. Das sind operative Konsequenzen aus den dokumentierten Grenzen des Modells und den allgemeinen Prüfempfehlungen, keine Garantie für regulatorische Konformität. [1] [5]

Die wichtigste Aussage der Veröffentlichung ist daher nicht, dass PII-Erkennung abschließend gelöst wäre. Sie zeigt vielmehr einen kompakten, lokal ausführbaren Ansatz mit mehreren Laufzeitoptionen und vergleichsweise detaillierten, aber vom Entwickler selbst veröffentlichten Tests. Für Unternehmen ist das ein Ansatzpunkt für eine kontrollierte Evaluation – nicht der Ersatz für eigene Validierung, zusätzliche Regeln oder eine übergreifende Datenschutz- und Sicherheitsarchitektur. [1] [5]

Quellen

1. [1] crp4222/privaite-pii-minilm · Hugging Face — https://huggingface.co/crp4222/privaite-pii-minilm (abgerufen am 2026-10-31)
2. [5] Handling PII and Sensitive Data with LLMs — http://cborg.lbl.gov/security_pii (abgerufen am 2026-10-31)