Microsoft-Presidio-Alternative für deutschen Freitext

Presidio ist ein von Microsoft veröffentlichtes, quelloffenes Software Development Kit für die Erkennung und Entfernung personenbezogener Daten. Es steht unter MIT-Lizenz auf GitHub, wird in Python geschrieben und besteht im Kern aus zwei Paketen: presidio-analyzer findet PII in Text und gibt Entitätstyp, Start- und Endposition sowie einen Score zurück, presidio-anonymizer wendet darauf Operatoren an und erzeugt den bereinigten Text. Ergänzend gibt es unter anderem einen Image-Redactor für Bilddateien.

Wichtig für die Einordnung: Presidio ist eine Bibliothek zum Selbstbetreiben, kein gebuchter Endpunkt. Sie binden es als Python-Abhängigkeit ein oder deployen es hinter einer eigenen Schnittstelle. Damit bleibt jeder Text vollständig in Ihrer Infrastruktur, und das ist der stärkste Punkt des Projekts. Wer diese Anforderung hat, ein Team mit NLP-Erfahrung mitbringt und ungewöhnliche Entitätstypen erkennen muss, sollte Presidio ernsthaft prüfen, bevor er einen Dienst einkauft.

Das Datenmodell von Presidio ist bewusst schlicht und deshalb gut erweiterbar. Die AnalyzerEngine hält eine Registry von Recognizern. Jeder Recognizer ist für einen Entitätstyp zuständig und meldet Treffer als Ergebnisobjekt mit entity_type, start, end und score zurück. Drei Sorten von Recognizern kommen in der Praxis vor:

• Pattern-Recognizer — reguläre Ausdrücke mit optionaler Prüfsumme, etwa für IBAN, Kreditkartennummern oder IP-Adressen. Zusätzlich lassen sich Kontextwörter hinterlegen, die den Score eines Treffers in der Nähe anheben.
• Deny-Lists — feste Wortlisten, sinnvoll für abgeschlossene Mengen wie interne Projektnamen oder Standorte.
• NER-basierte Recognizer — sie greifen auf die konfigurierte NLP-Engine zu. Presidio bringt Adapter für gängige Frameworks mit, in der Praxis meist spaCy, Stanza oder ein Transformer-Modell.

Die AnonymizerEngine nimmt Originaltext und Analyzer-Ergebnisse entgegen und wendet pro Entitätstyp einen Operator an. Dokumentiert sind unter anderem Ersetzen, Schwärzen, Maskieren einzelner Zeichen, Hashen und Verschlüsseln. Das ist mehr Gestaltungsfreiheit, als eine API sie geben kann, und zugleich die Stelle einer Designentscheidung, die viele Teams unterschätzen: Welche Ersetzung erlaubt es Ihnen später noch, das Ergebnis einer Person zuzuordnen?

Presidio ist nicht auf Englisch festgelegt, aber die mitgelieferte Grundausstattung ist es in Teilen. Wer deutschen Freitext verarbeitet, trifft in derselben Reihenfolge auf dieselben vier Punkte.

Erstens die Sprachkonfiguration. Ein deutsches NER-Modell muss ausgewählt, installiert und der NLP-Engine zugewiesen werden. Die klassischen statistischen Modelle liefern die groben Klassen Person, Ort und Organisation. Die Kategorien, die im Datenschutz zählen, sind feiner: Ein Geburtsdatum ist etwas anderes als ein Rechnungsdatum, eine private Mobilnummer etwas anderes als die Zentrale, ein persönliches Profil etwas anderes als ein Produktlink. Diese Trennung müssen Sie über eigene Regeln und Schwellenwerte nachbauen.

Zweitens die Groß- und Kleinschreibung. Im Englischen ist ein großgeschriebenes Wort mitten im Satz ein starkes Signal für einen Eigennamen. Im Deutschen wird jedes Substantiv großgeschrieben, das Signal trägt also fast keine Information mehr. Modelle, deren Trainingsschwerpunkt auf Englisch liegt, verlieren an dieser Stelle einen großen Teil ihrer Trefferqualität. Deutsche Nachnamen, die zugleich gewöhnliche Wörter sind, machen es nicht leichter: „Herr Koch“, „Frau Sommer“ und „die Familie Klein“ lassen sich nur aus dem Kontext auflösen, nicht aus dem Wort.

Drittens Formate und Flexion. Anschriften stehen im Deutschen als Straße, Hausnummer, dann Postleitzahl und Ort; Datumsangaben laufen von Tag zu Jahr; Rufnummern erscheinen als 0176-Schreibweise ebenso wie mit Ländervorwahl. Vor allem aber werden Namen gebeugt: „Bergmanns Antrag“, „an Herrn Bergmann“, „laut Frau Dr. Bergmann-Weiß“. Ein Regex, der auf einer Form sitzt, verfehlt die anderen.

Viertens die hauseigenen Kennungen. Aktenzeichen, Versicherten- und Vorgangsnummern sind oft der eigentliche Grund, warum ein Text intern identifizierend ist. Für sie liefert kein Werkzeug einen fertigen Erkenner mit.

Die beiden Systeme lösen dieselbe Aufgabe an unterschiedlichen Stellen der Wertschöpfung. Presidio gibt Ihnen die Bausteine und überlässt Ihnen den Zusammenbau, Persona gibt Ihnen ein Ergebnis und nimmt Ihnen die Kontrolle über den Zusammenbau ab. Die folgende Tabelle benennt die Kriterien, an denen die Entscheidung tatsächlich hängt.

Drei Dinge kann Presidio, die Persona nicht kann, und sie sind für manche Projekte entscheidend.

Persona ist kein Open-Source-Projekt. Das Modell hinter der Erkennung basiert auf dem offen lizenzierten perplexity-ai/pplx-pii-masking unter MIT-Lizenz, der Dienst selbst ist es nicht. Sie können den Code nicht lesen, nicht forken und keinen Pull Request stellen. Wenn Quelloffenheit eine Anforderung Ihrer Architektur oder Ihrer Beschaffung ist, endet die Prüfung hier, und Presidio ist die richtige Wahl.

Im Standardplan trainieren Sie kein eigenes Modell. Starter und Pro liefern neun feste Kategorien. Wer ein zehntes Label braucht, etwa ein hauseigenes Aktenzeichenformat, oder wer das Modell auf den eigenen Textsortenmix nachziehen will, braucht dafür den Enterprise-Plan mit eigenen Kategorien und Fine-Tuning. In Presidio ist ein zusätzlicher Erkenner dagegen eine Klasse, die Sie registrieren.

Persona maskiert keine Datenbanken und keine Bilder. Der Gegenstand ist Freitext: Tickets, Mails, Protokolle, Prompts, Vertragspassagen. Für das Maskieren strukturierter Spalten in einer Testdatenbank oder das Schwärzen von Scans ist dieses Werkzeug nicht gebaut. Wenn Sie beides brauchen, ist die Kombination der naheliegende Weg: Beide Systeme arbeiten mit zeichengenauen Positionen und lassen sich in einer Pipeline hintereinanderschalten.

Was Persona statt Konfigurierbarkeit anbietet, ist eine Antwortstruktur, die für den deutschen Fall bereits entschieden ist. Ein Aufruf von POST /v1/pseudonymize liefert vier Dinge zurück: den maskierten Text, die erkannten Spans mit zeichengenauen Start- und Endpositionen im Original, das Mapping von Token zu Originalwert und einen Sensitivitätswert zwischen 0.0 und 1.0 für den gesamten Text.

Die neun Kategorien sind private_person, private_email, private_phone, private_address, private_url, private_date, account_number, secret und other_pii. Die Erkennung läuft kontextbasiert über ein mehrsprachiges Modell und nicht über Regex. Deshalb wird ein gebeugter Name ebenso erfasst wie die Grundform, und ein Geburtsdatum anders behandelt als ein beliebiges Datum im Fließtext. Innerhalb eines Textes bleiben die Pseudonyme konsistent: Dieselbe Person trägt an jeder Fundstelle dasselbe Token, sodass ein Sprachmodell den Text noch verstehen kann.

Die zeichengenauen Spans sind der praktisch wichtigste Teil der Antwort: Mit ihnen lässt sich die Ersetzung im eigenen System nachvollziehen, hervorheben oder um einen eigenen Erkenner ergänzen. Die Feldreferenz steht in der API-Dokumentation; wer die Erkennung erst einmal ohne Anmeldung an eigenem Text sehen will, kann das im Browser-Werkzeug zum Text anonymisieren tun, das vollständig lokal läuft.

Der Sensitivitätswert ist kein Compliance-Urteil, sondern ein Routing-Signal: harmlose Anfragen an ein günstiges Cloud-Modell, heikle an ein lokales.

In einer LLM-Pipeline ist das Maskieren nur die Hälfte des Vorgangs. Das Sprachmodell antwortet auf den maskierten Text und schreibt dabei die Pseudonyme mit: „Sehr geehrter ⟨PERSON_1⟩, Ihre Sendung an ⟨ADDRESS_1⟩ …“. Bevor diese Antwort einen Sachbearbeiter oder einen Kunden erreicht, müssen die Tokens wieder aufgelöst werden. Genau dieser Rückweg entscheidet darüber, ob Pseudonymisierung in einer Anwendung überhaupt tragfähig ist.

Presidio kennt umkehrbare Operatoren und bringt für sie auch einen Gegenweg mit. Was es nicht mitbringt, ist der operative Round-Trip einer LLM-Pipeline: die Zuordnungstabelle über den Modellaufruf hinweg halten, ihre Lebensdauer begrenzen, den Antworttext dagegen auflösen und mit Tokens umgehen, die das Modell verändert oder erfunden hat. Lösbar, aber Code, den Sie schreiben, testen und pflegen.

Persona kapselt diesen Schritt in POST /v1/reidentify: Sie schicken den Antworttext und das Mapping aus dem ersten Aufruf, und Sie erhalten den Klartext zurück. Der Dienst ist dabei zustandslos: Das Mapping existiert nur in Ihrer Antwort und in Ihrem System, nicht auf dem Server. An eine solche Trennung knüpft auch die Definition der Pseudonymisierung in Art. 4 Nr. 5 DSGVO an, die verlangt, dass die zusätzlichen Informationen gesondert aufbewahrt werden. Wie Sie das Mapping in Ihrem System schützen und wie lange Sie es vorhalten, bleibt Ihre Entscheidung und Ihre Verantwortung.

Die Lizenzkosten von Presidio sind null, und dabei bleibt es. Die Rechnung, die aufgemacht werden muss, ist eine andere: Welche Arbeit steht zwischen dem ersten funktionierenden Beispiel und einem System, dem Sie deutsche Kundenkorrespondenz anvertrauen? Realistisch sind das fünf Posten.

• Ein Testdatensatz. Ohne gelabelte deutsche Beispieltexte aus Ihrer eigenen Domäne wissen Sie nicht, ob Ihre Konfiguration gut ist. Diesen Datensatz hat niemand herumliegen; er entsteht durch manuelle Arbeit und ist die Voraussetzung für jede Aussage über Qualität.
• Modellauswahl und Schwellenwerte. Kleines oder großes NER-Modell, welche Recognizer aktiv, welcher Score-Schwellwert, welche Kontextwörter. Jede Einstellung verschiebt das Verhältnis von übersehenen zu falsch markierten Stellen, und beide Fehlerarten haben unterschiedliche Kosten.
• Eigene Recognizer. Für Aktenzeichen, Vertrags- und Versichertennummern, interne IDs. Diese Arbeit fällt in jedem Fall an, sie ist kein Argument gegen Presidio.
• Infrastruktur und Latenz. Container, Skalierung, Kapazität, Kaltstarts, Monitoring. Wenn die Erkennung synchron vor jedem Prompt läuft, wird ihre Latenz Teil Ihrer Nutzererfahrung.
• Pflege. Modell- und Bibliotheksversionen ziehen weiter, Abhängigkeiten brechen, und nach jeder Änderung braucht es einen Regressionslauf gegen den Testdatensatz aus Punkt eins. Das ist kein Projekt mit Enddatum, sondern eine Betriebsaufgabe.

Der ehrliche Vergleich lautet also nicht „kostenlos gegen 49 EUR im Monat“, sondern „Personentage plus Infrastruktur gegen einen festen Monatsbetrag plus Abhängigkeit von einem Anbieter“. Ein Team, das ohnehin Modelle betreibt, kommt mit Presidio oft günstiger und flexibler ans Ziel; es hat die teuerste Zutat, die Erfahrung, bereits im Haus. Ein Team ohne diese Zutat kauft mit einer API vor allem den entfallenen Betrieb ein und gibt Kontrolle über das Modell ab. Was in keinem Fall entfällt, ist die Prüfung an eigenen Texten.

Die verbreitete Grundform in Presidio besteht aus zwei Engines. Der Aufruf selbst ist kurz; entscheidend ist, was vorher konfiguriert wurde.

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

# Der Aufruf ist kurz. Die Arbeit steckt in der Konfiguration davor:
# NLP-Engine auf ein deutsches Modell setzen, Kontextwörter übersetzen,
# eigene Recognizer für hauseigene Kennungen registrieren.
analyzer = AnalyzerEngine()

ergebnisse = analyzer.analyze(text=dokument, language="de")
# -> RecognizerResult: entity_type, start, end, score

anonymisiert = AnonymizerEngine().anonymize(
    text=dokument,
    analyzer_results=ergebnisse,
)
print(anonymisiert.text)

# Den Weg zurück – von der LLM-Antwort zum Klartext – bauen Sie selbst:
# Originalwerte aus den Offsets sichern, Tokens vergeben, später ersetzen.

Derselbe Vorgang über die Persona-API, inklusive Modellaufruf und Rückweg. Der API-Key steht als Bearer-Token im Header, Ein- und Ausgabe sind JSON in UTF-8.

import os, requests

API = "https://persona-api.mind-verse.de"
KOPF = {"Authorization": f"Bearer {os.environ['PERSONA_KEY']}"}

dokument = "Bitte prüfen Sie den Vorgang von Jonas Bergmann, Lindenstraße 12, 10969 Berlin. Rückfragen an 0176 22558899."

# 1. Pseudonymisieren, bevor der Text die eigene Infrastruktur verlässt
p = requests.post(f"{API}/v1/pseudonymize", headers=KOPF,
                  json={"text": dokument}, timeout=30).json()

p["masked"]       # "… von ⟨PERSON_1⟩, ⟨ADDRESS_1⟩. Rückfragen an ⟨PHONE_1⟩."
p["spans"]        # [{"label": "private_person", "start": 33, "end": 47, …}, …]
p["mapping"]      # {"⟨PERSON_1⟩": "Jonas Bergmann", …}  – bleibt bei Ihnen
p["sensitivity"]  # 0.0 – 1.0 für den gesamten Text

# 2. Das Sprachmodell sieht nur Pseudonyme
antwort = mein_llm(p["masked"])

# 3. Rückweg: Tokens in der Modellantwort wieder auflösen
final = requests.post(f"{API}/v1/reidentify", headers=KOPF,
                      json={"text": antwort, "mapping": p["mapping"]},
                      timeout=30).json()["text"]

Der Unterschied in den Zeilen ist unspektakulär. Der Unterschied liegt darin, dass im ersten Beispiel die Sprache, die Erkenner, die Schwellenwerte, das Tokenschema und die Speicherung der Zuordnung noch offene Punkte sind, und im zweiten nicht.

Beim Selbstbetrieb von Presidio verlässt der Text Ihre eigene Umgebung nicht. Für diesen Verarbeitungsschritt kommt damit kein zusätzlicher Auftragsverarbeiter hinzu, und eine Frage weniger ist zu klären. Das ist ein echter Vorteil, und er sollte in der Abwägung nicht untergehen. Die übrigen Pflichten der Verarbeitung bleiben davon unberührt, ebenso Verträge, die Sie für die darunterliegende Infrastruktur ohnehin brauchen.

Wer stattdessen eine API einsetzt, fügt einen Auftragsverarbeiter hinzu und muss dieselben Fragen stellen, die auch für jeden LLM-Anbieter gelten: Wo wird verarbeitet, werden Eingaben gespeichert oder zum Training verwendet, gibt es einen AV-Vertrag nach Art. 28 DSGVO, welche Unterauftragsverarbeiter sind beteiligt. Wie man diese Prüfung strukturiert durchführt, steht auf der Seite zum DSGVO-konformen KI-Einsatz.

Für Persona lauten die Antworten: Die Verarbeitung läuft auf dedizierten Servern bei Hetzner in Falkenstein, Deutschland, in nach ISO 27001 zertifizierten Rechenzentren. Zertifiziert ist dabei das Rechenzentrum des Hosters, nicht Persona als Dienst. Die Inferenz läuft auf dieser Hardware, für die Analyse wird kein externer KI-Dienst aufgerufen. Anfragetexte werden nicht gespeichert, nicht inhaltlich protokolliert und nicht für Training verwendet. Kontodaten wie Registrierung, API-Keys und Abrechnung liegen davon getrennt in Frankfurt. Ein AV-Vertrag nach Art. 28 DSGVO ist ab dem Pro-Plan enthalten, und Enterprise-Kunden können den Dienst als Container in der eigenen Umgebung betreiben.

Unabhängig vom gewählten Werkzeug gilt: Pseudonymisierte Daten bleiben nach Erwägungsgrund 26 der DSGVO personenbezogene Daten, solange die Zuordnung mit Zusatzwissen möglich ist. Weder Presidio noch Persona machen eine Verarbeitung „DSGVO-konform“; beide sind technische und organisatorische Maßnahmen im Sinne von Art. 32 DSGVO, die das Risiko senken.

Diese Seite dient der technischen Orientierung und ist keine Rechtsberatung. Ob die beschriebenen Maßnahmen für Ihren Anwendungsfall ausreichen, beurteilen Ihre Datenschutzbeauftragte oder Ihr Rechtsbeistand anhand Ihrer konkreten Verarbeitung.