PromptShieldpromptShieldpromptShield
In Aktion erlebenFunktionenSo funktioniert'sKI-WorkflowsSorgenfreiheitLizenzverwaltungCompliance-Überwachung
PreiseHerunterladen
Entwickler
ÜberblickAPI-DokumentationAPI-Schlüssel
FAQ
Anmelden
  1. Startseite
  2. Blog
  3. Engineering
Engineering2026-06-08· 9 Min. Lesezeit

Warum wir unsere eigene Engine für personenbezogene Daten gebaut haben, statt Presidio auszuliefern

Microsoft Presidio ist eines der besten Open-Source-Toolkits für personenbezogene Daten, das es gibt. Wir haben seinen Quellcode gelesen, wir haben daraus gelernt, und wir haben uns trotzdem entschieden, es nicht auszuliefern. Dies ist die ehrliche Begründung.

Die Kurzfassung: Presidio findet personenbezogene Daten innerhalb eines Blocks aus Text. promptShield tut etwas Engeres und Konkreteres – es nimmt ein PDF auf dem Gerät eines Menschen, ohne Internetverbindung, und lässt den Nutzer einen Namen auf der Seite anklicken und zusehen, wie er geschwärzt wird. Beide Aufgaben drehen sich um „personenbezogene Daten finden“, also klingen sie nach derselben Arbeit. Sie sind es nicht. Und die Unterschiede zwischen ihnen sind genau die Stellen, an denen wir unsere ganze Zeit damit verbracht hätten, Presidio zu etwas zu zwingen, wofür es nie gebaut wurde.

Es geht hier also nicht darum, das Rad um seiner selbst willen neu zu erfinden. Wir brauchten wirklich ein anderes Rad. Hier ist der Grund.

Was wir ausliefern, ist kein Textstrom

Presidio denkt in reinem Text: Sie geben ihm eine Zeichenkette, und es reicht eine Liste von Positionen zurück – „die Zeichen 40 bis 51 sind ein Name“. Das ist perfekt, wenn Sie Chatnachrichten oder eine Datenbankspalte durchsuchen, wo Text einfach Text ist. Für uns ist es der falsche Ausgangspunkt, denn unser Nutzer betrachtet keine Zeichenkette. Er betrachtet eine Seite.

Eine PDF-Seite ist keine Textzeile – sie ist ein Layout. Wörter sitzen in Kästen an bestimmten Koordinaten. Ein einzelner Name kann über zwei Zeilen getrennt, über zwei Spalten verteilt oder sogar gedreht sein. Und der Nutzer schwärzt nicht „die Zeichen 40 bis 51“ – er schwärzt ein Rechteck auf der Seite, die er vor sich sieht. Für uns sind das Finden des Namens und das Wissen, wo er auf der Seite sitzt, deshalb nicht zwei getrennte Schritte, die wir zusammenkleben könnten. Es ist derselbe Schritt.

So sieht das in der Praxis aus. Wenn unsere Pipeline „Pierre Dubois“ findet, umgebrochen zwischen dem Ende einer Zeile und dem Anfang der nächsten, muss sie diesen einen Namen in zwei Rechtecke verwandeln und beide schwärzen. Wenn sie einen Namen auf Seite 1 findet, merkt sie ihn sich und schwärzt ihn auf Seite 4 automatisch, damit der Prüfer nicht dieselbe Person elfmal von Hand markieren muss. Presidio hat von all dem keinen Begriff – es kennt nur Positionen in einer Zeichenkette. Um es zum Laufen zu bringen, hätten wir es in so viel Seiten- und Layout-Code einwickeln müssen, dass Presidio den kleinen, leichten Teil erledigt hätte und unser eigener Code alles, was tatsächlich schwierig ist.

Wir betreiben nicht ein Modell. Wir betreiben fünf Schichten, die abstimmen.

In Presidio arbeitet jeder Erkenner für sich, und Sie sammeln einfach alles zusammen, was sie finden. Das ist flexibel, hat aber einen Haken: Wenn auch nur ein Erkenner zu vorschnell ist, landen all seine Fehlalarme in Ihren Ergebnissen. Ihre Genauigkeit wird auf die Ihres lautesten Erkenners heruntergezogen.

Wir haben einen anderen Ansatz gewählt: Unsere Erkenner müssen sich untereinander einig sein. Fünf von ihnen laufen über dieselbe Seite:

  • Regex — hochpräzise strukturierte Muster (Sozialversicherungsnummer, IBAN, E-Mail, Telefon, Unternehmenskennungen), mit einem Kontextfenster, sodass eine bloße neunstellige Zahl keine Sozialversicherungsnummer ist, sofern die umgebenden Wörter es nicht sagen.
  • spaCy — statistische Modelle pro Sprache, je eines für 7 Sprachen.
  • GLiNER — Zero-Shot-Entitätserkennung für Typen, die die trainierten Modelle verfehlen.
  • Transformer-Erkennung — transformer-gestützte Erkennung dort, wo die kleineren Modelle zu wenig finden.
  • LLM — optional, lokales GGUF oder eine entfernte API, für die kontextlastigen Grenzfälle.

Statt nur zusammenzutragen, was sie finden, lassen wir sie abstimmen. Wenn zwei Erkenner dasselbe markieren, vertrauen wir ihm mehr; wenn drei übereinstimmen, noch mehr. Etwas, das nur ein einziger nervöser Erkenner entdeckt hat, muss eine viel höhere Hürde nehmen, bevor wir es dem Nutzer zeigen. Diese Abstimmungslogik – wie wir Übereinstimmung gewichten, überlappende Treffer zusammenführen und Ergebnisse über Seiten hinweg tragen – ist das Produkt. Daher kommt unsere Genauigkeit tatsächlich. Presidio gibt Ihnen die Erkenner, überlässt die Ermessensentscheidung, wie sie zu versöhnen sind, aber bewusst Ihnen. Und diese Ermessensentscheidung zu schreiben heißt, den Großteil einer Engine zu schreiben – also haben wir das Ganze geschrieben.

Es muss mit gezogenem Netzwerkkabel laufen

promptShield ist eine offline arbeitende Desktop-Anwendung. Das ganze Versprechen lautet, dass Ihre Dokumente niemals Ihr Gerät verlassen – kein Cloud-Hin-und-Her, kein API-Schlüssel, kein „wir versprechen, wir protokollieren es nicht“. Das ist eine harte Bedingung, und sie formt die Abhängigkeitsfrage neu.

Presidio kann ebenfalls lokal laufen – aber so nutzen es die meisten Leute tatsächlich nicht. Um eine gute Genauigkeit herauszuholen, ist der übliche Weg, es an die Cloud-Sprachdienste von Microsoft oder Amazon anzuschließen. Das sind genau die Cloud-Aufrufe, die wir versprochen haben, niemals zu machen. Bleibt Presidios vollständig lokale Option, die auf kleineren, leichteren Modellen beruht – und das ist zufällig genau die Konfiguration, die wir in unserem Benchmark gemessen haben, jene, die Finanzdokumente mit Falsch-Positiven überschwemmt.

Und es geht tiefer als die Genauigkeit. Wir müssen jedes KI-Modell in den Installer der Anwendung packen und es auf dem Gerät des Nutzers ausführen. Jedes Modell muss gebündelt, auf eine Version festgenagelt, auf Manipulation geprüft, in den Speicher geladen und – der Teil, vor dem Sie niemand warnt – sauber wieder entladen werden. Unter Windows weigert sich Windows schlicht, die Dateien zu löschen, wenn ein Nutzer ein Sprachpaket entfernt, während noch irgendein Teil dieses Modells im Speicher gehalten wird. Also pflegen wir sorgfältig eine Liste jeder Stelle, an der ein Modell noch geladen sein könnte, über alle fünf Erkenner hinweg, und geben sie alle frei, bevor wir irgendetwas löschen. Diese Art von Hauswirtschaft funktioniert nur, wenn wir genau steuern, wie und wann jedes Modell geladen wird. Eine Drittanbieter-Engine, die ihre eigenen Modelle nach ihrem eigenen Zeitplan lädt, würde ständig darüber stolpern.

Die Rauschfilterung ist der eigentliche Burggraben – und er gehört uns

In unserem direkten Vergleich gab das Standard-Presidio 666 Treffer auf einem Korpus von 14 Dokumenten aus; wir gaben 252 auf denselben Dokumenten aus. Die Differenz ist fast vollständig Rauschen, das wir filtern und das eine Standardinstallation nicht filtert: Ländernennungen in Gerichtsstandsklauseln („unterliegt dem Recht Frankreichs“), URLs in Fußzeilen, Funktionsbezeichnungen, die für Namen gehalten werden, generische Abteilungsbegriffe, die als Organisationen markiert werden, dieselbe Person in drei überlappende Treffer zersplittert.

Jeder einzelne dieser Filter funktioniert über alle sieben Sprachen hinweg, ist gegen echte Verträge und Finanzausweise abgestimmt und läuft innerhalb des Abstimmungsschritts – wo er sowohl gewichten kann, wie zuversichtlich die Erkenner sind, als auch, wo der Text tatsächlich auf der Seite sitzt. Sie könnten all das als Erweiterungen nachbauen, die auf Presidio aufgeschraubt sind. Aber dann betreibt Presidio nur noch die Erkenner, während alles, was unsere Ausgabe sauber macht – die Filterung, die Abstimmung, das Seitenbewusstsein – immer noch Code ist, den wir selbst schreiben mussten. Wir würden eine große Abhängigkeit mit uns herumtragen, vor allem, um große Teile davon abzuschalten.

Was wir aufgegeben haben

Das war nicht umsonst, und es wäre unehrlich, etwas anderes vorzugeben.

  1. Wir bekommen Presidios Erkenner-Breite nicht geschenkt. Seine Community liefert Erkenner für Entitätstypen und Sprachen, die wir nicht gebaut haben. Jeden, den wir wollen, schreiben und testen wir selbst.
  2. Wir tragen unsere eigene Wartung. Wenn eine Transformer-Bibliothek eine brechende Änderung ausliefert, ist das unser Problem zu schlucken – es gibt keinen Upstream, bei dem man ein Ticket eröffnet und wartet. Ein paar davon haben wir geschluckt.
  3. Wir können uns nicht auf Presidios Namen stützen. „Gebaut auf Microsoft Presidio“ ist eine Glaubwürdigkeitsabkürzung in einem Beschaffungsgespräch. Wir haben sie gegen „hier ist unser reproduzierbarer Benchmark“ eingetauscht – mehr Arbeit und weniger geliehene Markenkraft.

Wann Sie stattdessen zu Presidio greifen sollten

Wenn Ihr Problem nach einem dieser Punkte aussieht, ist Presidio sehr wahrscheinlich die richtige Wahl, und etwas Eigenes zu bauen wäre Verschwendung:

  • Sie durchsuchen Textströme – Chatprotokolle, Datenbankspalten, API-Nutzlasten – und keine abgegrenzten, gelayouteten Dokumente.
  • Sie wollen Kontrolle auf Bibliotheksebene innerhalb eines größeren Python-DLP-Systems und übernehmen die Präzisionsabstimmung gern selbst.
  • Sie können ein Cloud-Backend zur Entitätserkennung nutzen (Azure, AWS) und wollen eine einzige Abstraktion für personenbezogene Daten über mehrere Anbieter.
  • Sie brauchen Breite an Entitätstypen und Sprachen mehr als eine saubere Prüfer-Erfahrung auf einer festen Dokumentklasse.

Presidio ist das bessere Werkzeug für einen großen, vielfältigen Ausschnitt der Welt der Erkennung personenbezogener Daten. Wir sind nicht in diesem Ausschnitt.

Die eigentliche Entscheidungsregel

Hier ist der Test, den wir angewandt haben, und der, den wir jedem empfehlen würden, der zwischen „die Bibliothek übernehmen“ und „die Engine bauen“ abwägt:

Wenn die Abhängigkeit den leichten Teil erledigen würde und Sie den schwierigen Teil darauf schreiben würden, übernehmen Sie keine Bibliothek – Sie übernehmen eine Einschränkung.

Für uns machen die schwierigen Teile – zu wissen, wo Text auf der Seite sitzt, fünf Erkenner abstimmen zu lassen, KI-Modelle offline zu verwalten, Rauschen über sieben Sprachen zu filtern – den Großteil des Produkts aus, und sie sind alle eng miteinander verflochten. Presidio hätte ganz unten gesessen und die Erkenner betrieben, während jede Entscheidung, die wirklich zählte, in unserem eigenen Code fiel. Also haben wir auch diese unterste Schicht geschrieben – und am Ende eine Engine erhalten, bei der wir jedes Teil verstehen, sie vollständig offline ausliefern und sie gegen genau die Arten von Dokumenten abstimmen, die unsere Nutzer tatsächlich schwärzen.

Wir wurden von Presidio inspiriert. Wir hatten nur ein anderes Dokument zu schwärzen.

Teilen

KI-gestützte Dokument-Anonymisierung. Erkennen und schwärzen Sie sensible Daten offline, mit vollständiger Privatsphäre.

Produkt

  • Chrome extension

Konto

Rechtliches

Canada flagProudly Canadian
promptShield Inc. · 222, Wayman, Gaspé (QC) G4X 1T1, Canada · D-U-N-S® 243371918 · IP geolocation by DB-IP
© 2026 promptShield inc. Alle Rechte vorbehalten.
promptShieldpromptShieldpromptShield
Funktionen
Preise
Herunterladen
Entwickler
So funktioniert's
KI-Workflows
Sorgenfreiheit
vs Microsoft Presidio
Alternativen
Blog
Team
Anmelden
Registrieren
Dashboard
Datenschutzerklärung
Nutzungsbedingungen
Sicherheit
Auftragsverarbeitung (DPA)
Erstattungsrichtlinie
Kontakt
Wechselkurse