Beste Open-Source-Modelle für PII-Redaktion

Vergleich der besten Open-Source-Modelle zur PII-Erkennung und -Redaktion in KI-Pipelines — GLiNER, DeBERTa, Piiranha, StarPII und mehr.

Regex allein reicht nicht

Wer KI-Features baut, braucht PII-Erkennung in der Pipeline. Regex erledigt strukturierte PII zuverlässig — E-Mails, Kreditkartennummern, Telefonnummern, Sozialversicherungsnummern. Aber was ist mit einem Kundennamen in einem Support-Ticket? Einer Adresse mitten im Fließtext? Einem Firmennamen, der alles sein könnte?

Für unstrukturierte PII braucht man ML-Modelle. Und 2026 sind die Open-Source-Optionen wirklich gut. Dieser Beitrag stellt die besten Open-Source-Modelle für PII-Redaktion vor — Stärken, Schwächen und welches Modell für welchen Anwendungsfall passt.

Wie PII-Erkennungsmodelle funktionieren

Die meisten PII-Erkennungsmodelle sind Named Entity Recognition (NER)-Systeme. Sie verarbeiten Text Token für Token und klassifizieren jedes Token mit Labels wie B-PERSON (Beginn eines Personennamens), I-EMAIL (innerhalb einer E-Mail) oder O (kein PII).

Zwei Hauptansätze:

• Feinabgestimmte Modelle — Auf PII-gelabelten Datensätzen trainiert, mit festen Entity-Typen. Schnell und genau für bekannte Kategorien, aber neue Entity-Typen erfordern erneutes Training.
• Zero-Shot-Modelle — Entity-Labels werden zur Inferenzzeit angegeben. Flexibler, auf Benchmarks etwas weniger genau, aber ohne Training an neue PII-Typen anpassbar.

Die Transformer-Revolution (BERT, DeBERTa und deren Nachfolger) hat beide Ansätze dramatisch verbessert gegenüber den früheren spaCy/Regex-Stacks. Schauen wir uns an, was verfügbar ist.

Presidio + spaCy: die Baseline

Microsoft Presidio ist kein Modell — es ist ein Framework. Es kombiniert Regex-Mustererkennung, regelbasierte Logik und NER (standardmäßig spaCy) in einer konfigurierbaren Erkennungspipeline. Es ist die am weitesten verbreitete Open-Source-PII-Lösung.

Funktionsweise: Presidio liefert eingebaute „Recognizer" für gängige PII-Typen. Die Standard-NER-Engine ist spaCys en_core_web_lg-Modell. Man kann eigene Recognizer hinzufügen oder ein anderes NER-Backend einsetzen.

Stärken:

• Produktionsreifes Framework mit jahrelanger Community-Härtung
• Verarbeitet Text, Bilder und strukturierte Daten (JSON, CSV)
• Modulare Architektur — spaCy durch GLiNER, Flair oder ein eigenes Modell austauschbar
• Gute Dokumentation, aktive Wartung

Schwächen:

• Standard-spaCy-NER hat Probleme mit nicht-westlichen Namen (indische, ostasiatische, arabische Namen)
• Regex-Recognizer übersehen implizite oder kontextabhängige PII
• Framework-Komplexität — man verwaltet eine Pipeline, nicht nur ein Modell
• spaCys NER-Genauigkeit liegt auf allgemeinen PII-Benchmarks hinter Transformer-Alternativen

Ideal für: Teams, die ein vollständiges Framework mit Batterien im Lieferumfang wollen und bereit sind, das NER-Backend anzupassen.

Fazit: Guter Startpunkt als Produktions-Framework, aber das Standard-spaCy-NER sollte durch GLiNER oder einen DeBERTa-Fine-Tune ersetzt werden.

GLiNER: die Zero-Shot-Option

GLiNER (Generalist and Lightweight model for Named Entity Recognition) ist ein Transformer-basiertes NER-Modell mit einer Schlüsselinnovation: Zero-Shot-Entity-Erkennung. Entity-Labels werden zur Inferenzzeit definiert — kein Nachtraining nötig.

Für PII-Erkennung gibt es spezialisierte Varianten:

• Knowledgator GLiNER-PII — Über 60 PII-Entity-Kategorien, in Small/Base/Large/Edge verfügbar. Die umfassendste PII-spezifische GLiNER-Variante.
• NVIDIA GLiNER-PII — Basiert auf GLiNER large-v2.1, deckt über 55 Entity-Typen ab, inklusive PHI (geschützte Gesundheitsinformationen).
• Gretel GLiNER — Auf synthetischen Gretel-Datensätzen feinabgestimmt, in Small/Base/Large verfügbar.
• urchade/gliner_multi_pii-v1 — Multi-PII-Variante vom GLiNER-Originalautor.

Funktionsweise: Text und eine Liste von Entity-Labels übergeben (z.B. ["person", "email", "credit_card", "address"]). GLiNER gibt Spans mit Confidence-Scores zurück.

from gliner import GLiNER

model = GLiNER.from_pretrained("knowledgator/gliner-pii-base-v1.0")

text = "Kontaktieren Sie Max Müller unter max@firma.de oder 0151-12345678"
labels = ["person", "email", "phone_number"]

entities = model.predict_entities(text, labels, threshold=0.5)
for entity in entities:
    print(f"{entity['text']} -> {entity['label']} ({entity['score']:.2f})")

Stärken:

• Zero-Shot-Flexibilität — neue Entity-Typen ohne Nachtraining
• Gute Genauigkeit (F1 ~0.81 auf Multi-Domain-PII-Benchmarks)
• Mehrere Größenoptionen von Edge (winzig) bis Large
• Direkte Integration mit Presidio als Custom Recognizer
• Besser bei nicht-westlichen Namen als spaCy

Schwächen:

• F1 sinkt auf ~0.41 bei klinischen/medizinischen Daten (Domain-Gap)
• Etwas langsamer als feste Fine-Tuned-Modelle (Zero-Shot-Overhead)
• GPU für akzeptablen Durchsatz im Produktionsbetrieb nötig

Ideal für: Teams, die Flexibilität bei Entity-Typen brauchen, diverse Texteingaben verarbeiten oder ein Modell wollen, das sich an verschiedene PII-Anforderungen anpasst.

DeBERTa Fine-Tunes: höchste Genauigkeit

Wer die höchste Rohgenauigkeit bei einem festen Satz von PII-Typen braucht, ist mit DeBERTa-Fine-Tunes am besten bedient. Diese Token-Klassifikationsmodelle sind speziell auf PII-gelabelten Datensätzen trainiert.

Die herausragenden Modelle:

• DeBERTa v3 + ai4privacy — Feinabgestimmt auf dem ai4privacy-300K-Datensatz. F1: 0,9757, Accuracy: 0,9915. Deckt 54 PII-Klassen in mehreren Sprachen ab. Das ist der Genauigkeits-Benchmark.
• lakshyakh93/deberta_finetuned_pii — Multi-Kategorie-Erkennung: Kontonamen, Kreditkarten, E-Mails, Telefonnummern, Adressen.
• JasperLS/deberta-v3-base-pii-identifier-v2 — Allgemeine PII-Identifikation.

Funktionsweise: Standard-Transformer-Token-Klassifikation. Text eingeben, Pro-Token-PII-Labels erhalten. Feste Entity-Sets aus dem Training.

from transformers import pipeline

classifier = pipeline(
    "token-classification",
    model="Isotonic/deberta-v3-base_finetuned_ai4privacy_v2",
    aggregation_strategy="simple"
)

text = "Mein Name ist Maria García und ich wohne in der Eichenstraße 42, Berlin"
results = classifier(text)
for r in results:
    print(f"{r['word']} -> {r['entity_group']} ({r['score']:.2f})")

Stärken:

• Höchste Benchmark-Scores (F1 > 0,97)
• Schnelle Inferenz — kein Zero-Shot-Overhead
• Bewährte Transformer-Architektur
• Mehrere Varianten für verschiedene Anwendungsfälle

Schwächen:

• Feste Entity-Sets — neue PII-Typen erfordern Nachtraining
• Qualität der Trainingsdaten bestimmt die reale Performance (einige auf synthetischen Daten trainiert)
• Größere Modelle brauchen GPU für Produktionsdurchsatz

Ideal für: Produktionssysteme, bei denen die zu erkennenden PII-Typen feststehen und Genauigkeit oberste Priorität hat.

Piiranha: am besten für Mehrsprachigkeit

Piiranha ist ein feinabgestimmtes microsoft/mdeberta-v3-base-Modell, speziell für mehrsprachige PII-Erkennung. Es erkennt 17 PII-Typen in 6 Sprachen.

Performance: 98,27% PII-Token-Erkennungsrate, 99,44% Gesamtklassifikationsgenauigkeit. Starke Werte, besonders über mehrere Sprachen hinweg.

Stärken:

• Beste mehrsprachige Abdeckung unter PII-spezifischen Modellen
• Hohe Genauigkeit über Sprachen hinweg (nicht nur Englisch)
• Basiert auf der bewährten mDeBERTa-Architektur

Schwächen:

• Kleineres Entity-Set (17 Typen) im Vergleich zu GLiNER-PII (60+) oder ai4privacy DeBERTa (54)
• Auf 6 Sprachen begrenzt — nicht universell

Ideal für: Anwendungen, die Text in mehreren europäischen Sprachen verarbeiten und konsistente sprachübergreifende Genauigkeit wichtiger ist als Entity-Typ-Breite.

StarPII: für Code gemacht

StarPII geht einen anderen Weg — es ist für die Erkennung von PII in Quellcode und code-nahem Text konzipiert. Teil des BigCode-Projekts, erkennt es 6 Kategorien:

• Namen
• E-Mails
• API-Schlüssel
• Passwörter
• IP-Adressen
• Benutzernamen

Warum wichtig: Wer KI-Coding-Assistenten baut oder Code-Repositories verarbeitet, übersieht mit allgemeinen PII-Modellen code-spezifische Muster. StarPII versteht, dass password = "hunter2" ein Credential ist, nicht nur ein String-Literal.

Ideal für: Code-Analyse, Repository-Scanning, Coding-Assistant-Pipelines. Mit einem allgemeinen PII-Modell für Nicht-Code-Text kombinieren.

Kleine LLMs als PII-Detektoren

Einige Teams setzen kleine Sprachmodelle (Phi-3 Mini, Qwen2-0.5B) ein, die für PII-Erkennung feinabgestimmt wurden. Modelle wie ab-ai/PII-Model-Phi3-Mini und betterdataai/PII_DETECTION_MODEL (Qwen2-0.5B, 29 Klassen, 7 Sprachen) nutzen diesen Ansatz.

Stärken:

• Können komplexe, kontextuelle PII erkennen, die NER-Modellen entgeht
• Natural-Language-Output macht Ergebnisse interpretierbar
• Teilweise Instruction-Following für benutzerdefinierte Erkennungsregeln

Schwächen:

• Deutlich langsamer als NER-Modelle (10-100x)
• Höhere Ressourcenanforderungen (auch „kleine" LLMs brauchen mehr Speicher)
• Weniger vorhersagbar — generative Modelle können Entities halluzinieren
• Schwieriger im großen Maßstab mit konsistenter Latenz zu betreiben

Ideal für: Offline-Batch-Verarbeitung, bei der Latenz keine Rolle spielt und maximales kontextuelles Verständnis nötig ist. Nicht empfohlen für Echtzeit-API-Traffic.

Vergleichstabelle

Das richtige Modell wählen

Es gibt kein einzelnes bestes Modell — es hängt von den Randbedingungen ab:

• Allgemeiner Text, bekannte PII-Typen → DeBERTa + ai4privacy Fine-Tune. Höchste Genauigkeit, schnelle Inferenz, 54 Entity-Klassen decken die meisten Fälle ab.
• Allgemeiner Text, sich ändernde PII-Typen → GLiNER-PII (Knowledgator oder NVIDIA). Zero-Shot-Flexibilität erlaubt neue Entity-Typen ohne Nachtraining.
• Mehrsprachig → Piiranha. Konsistente Genauigkeit über 6 Sprachen schlägt separate Modelle pro Sprache.
• Code und Repositories → StarPII. Allgemeine PII-Modelle verstehen code-spezifische Muster nicht.
• Produktions-Framework → Presidio mit GLiNER als NER-Backend. Presidios Pipeline-Management mit GLiNERs Erkennungsgenauigkeit. Microsoft dokumentiert diese Integration.
• Gesundheitswesen / PHI → NVIDIA GLiNER-PII oder domänenspezifische Fine-Tunes. Allgemeine Modelle verlieren bei klinischem Text deutlich an Genauigkeit.

Der hybride Ansatz gewinnt

In der Produktion setzen die besten PII-Erkennungssysteme nicht auf ein einzelnes Modell. Sie kombinieren Ansätze:

1. Regex-Muster für strukturierte PII — E-Mails, Kreditkarten, Sozialversicherungsnummern, Telefonnummern. Schnell (Sub-Millisekunde), deterministisch und auditierbar.

2. ML-Modelle für unstrukturierte PII — Namen, Adressen, Organisationen, Freitext-Entities. Hier verdienen sich die oben genannten Modelle ihren Platz.

3. Secret-Scanning für Credentials — API-Schlüssel, Tokens, Verbindungsstrings. Diese sind von PII verschieden, aber in KI-Pipelines ebenso wichtig.

Regex zuerst filtert die einfachen Fälle bei nahezu null Kosten heraus. Das ML-Modell verarbeitet nur, was Regex nicht abfängt. Das ist der Ansatz, den wir in unserem Leitfaden für PII-Erkennung empfehlen — und so funktionieren die meisten Produktionssysteme.

Wie Grepture hilft

PII-Erkennungsmodelle zu hosten, zu tunen und zu warten ist echte operative Arbeit. Man braucht GPU-Infrastruktur, Modell-Versionierung, Latenz-Monitoring und Fallback-Strategien.

Grepture übernimmt das auf der Proxy-Ebene. Jeder API-Aufruf an OpenAI, Anthropic oder einen anderen LLM-Anbieter fließt durch Grepture, wo er mit Regex-Mustern und KI-Modellen gescannt wird. Erkannte PII kann redaktiert, maskiert und wiederhergestellt oder für Audits protokolliert werden.

Der Vorteil: Keine Integration pro Service, kein Modell-Hosting, und reversible Redaktion sorgt dafür, dass KI-Antworten personalisiert bleiben.

Für einen detaillierten Vergleich von Presidio vs. Greptures Ansatz siehe unseren Direktvergleich.

Wichtigste Erkenntnisse

• GLiNER-PII-Varianten (Knowledgator, NVIDIA) sind die vielseitigste Wahl — Zero-Shot-Flexibilität mit guter Genauigkeit und 55-60+ Entity-Typen.
• DeBERTa, feinabgestimmt auf ai4privacy, hat den höchsten Benchmark-Score (F1: 0,9757) für maximale Genauigkeit bei festem Entity-Set.
• Piiranha ist die beste mehrsprachige Option mit 98%+ Erkennungsraten über 6 Sprachen.
• Produktionssysteme sollten Regex + ML-Modelle kombinieren — Regex für strukturierte PII (schnell und auditierbar), Modelle für Freitext-Entities.
• Kein Modell behandelt alle Domänen gleich — Klinischer/medizinischer Text verursacht signifikante Genauigkeitseinbußen bei Allzweckmodellen. Auf echten Daten testen, bevor man deployed.