Dies ist eine maschinelle Übersetzung des englischen Originaldokuments. Im Falle von Widersprüchen zwischen dieser Übersetzung und der englischen Originalversion ist die englische Version maßgeblich. Englische Originalversion lesen
On-Device-Pseudonymisierer: Entwickelt und benchmarked
2026-05-22 · Caiioo Team
Wir wollten das Datenschutzproblem von KI-Systemen lösen, die mit echten personenbezogenen Daten trainiert werden und diese speichern. „Zero Data Retention“-Richtlinien und Vereinbarungen verringern das Risiko, sind aber voller Ausnahmen. Sie besagen im Wesentlichen: „Wir speichern keine Ihrer Prompts oder Ausgaben, außer für: (hier lange Liste von Ausnahmen einfügen: Sicherheitszwecke, staatliche Überwachung, Aufbewahrungspflichten bei Rechtsstreitigkeiten, Produktentwicklung, Fehlerprotokolle, Verbesserung der Dienste...)“
Um dies zu lösen, haben wir einen Filter für persönliche Daten entwickelt, der auf dem eigenen Rechner des Nutzers läuft, die Nachricht sieht, bevor sie das Gerät verlässt, und dieselbe Antwort zurückgibt, die der Nutzer erhalten hätte, wenn sie ganz ohne Filter getippt worden wäre.
Also haben wir einen gebaut. Die nächste Version von Caiioo wird den Pseudonymisierer enthalten. Er ist über das Schild-Symbol im Agenten-Chat sowie in den Einstellungen zugänglich.
Dieses Whitepaper skizziert die Beweggründe, die Architektur, den Evaluierungsprozess und die Designprinzipien hinter unserem Datenschutz-Filtersystem.
Was wir uns vorgenommen haben
Allgemeiner Datenschutz durch Datenminimierung. Wenn ein Nutzer mit einem Remote-Modell chattet, benötigt das Modell keinen echten Namen, keine Privatadresse, keine echte E-Mail oder die Telefonnummer eines Kunden, um die Frage des Nutzers zu beantworten. Es benötigt die Form der Frage, und diese muss wie eine echte Frage aussehen, damit das LLM die Anfrage nicht als Test verwirft. Der Filter entfernt daher echte Identifikatoren aus den an die KI gesendeten Daten und fügt die echten Werte auf dem Rückweg wieder ein. Das Modell sieht synthetische Namen und Identifikatoren; der Nutzer sieht die echte Konversation.
Unterstützung bei der HIPAA-Compliance. Ein zweiter Modus zielt auf die 18 Identifikatoren der HIPAA Safe Harbor-Regel (§164.514) und die weniger restriktive Limited Data Set-Variante ab. Ein Kliniker, ein Administrator im Gesundheitswesen oder jeder, der an einem betroffenen Workflow arbeitet, kann mit einem Allzweckmodell über reale Fälle sprechen, ohne geschützte Gesundheitsinformationen (PHI) an die KI zu senden. Wir sind nicht der Compliance-Beauftragte der betroffenen Stelle – aber wir können die Ebene sein, die verhindert, dass PHI den Laptop überhaupt erst verlässt. Unsere Evaluierungen liefern messbare Benchmarks, die Organisationen nutzen können, um die Eignung des Filters für ihre Compliance- und Datenschutzstandards zu bewerten. Alle Datenschutz- und Sicherheitsmaßnahmen sind Ermessensentscheidungen, die in der Verantwortung des Nutzers oder der Nutzerorganisation liegen.
Wir haben uns für beides entschieden, da das Engineering identisch ist und der PHI-Anwendungsfall technisch gesehen sogar einfacher ist, da er eindeutige benannte Entitäten verwendet, die leichter zu schwärzen sind als die allgemeineren Daten in der Kategorie „Persönliche Daten“. Die HIPAA-Filterung wird zudem dadurch begünstigt, dass sie in der Regel auf Englisch oder Spanisch erfolgt. Wir erkennen Identifikatoren, ersetzen sie durch stabile Pseudonyme und Ersatz-Identifikatoren im gleichen Format, stellen sie auf dem Rückweg wieder her und protokollieren niemals die echten Werte. Die Zuordnung zwischen den synthetischen Informationen und den echten Informationen verbleibt ausschließlich auf dem Gerät des Nutzers, sodass der Nutzer in den Antworten des Agenten echte Informationen lesen kann. Lediglich die Kategorieliste und das Policy Gate ändern sich zwischen den Modi.
Warum Regex plus Machine Learning und nicht nur eines von beiden
In unserem Pseudonymisierer kommen zwei Hauptfiltertechnologien zum Einsatz: eine deterministische Mustererkennungssprache namens Regex und trainierte Machine Learning-Modelle.
Regex ist unschlagbar bei Oberflächenformaten. Eine E-Mail-Adresse hat eine bestimmte Form ([email protected]). Das gilt auch für eine IP, eine Kreditkarte, eine IBAN, eine VIN, eine SSN (XXX-XX-XXXX) oder einen API-Key. Wenn das Format verlässlich ist, erfasst Regex es deterministisch, jedes Mal, ohne Modelllast und ohne Inferenzkosten.
Regex ist jedoch hoffnungslos überfordert mit dem Kontext. „Sarahs Diagramm vom letzten Dienstag“ enthält eine Person und ein Datum, aber keines von beiden lässt sich allein anhand des Formats unterscheiden. „Der Patient in der Ulmenstraße 14“ enthält eine Adresse, die sich mit tausend Nicht-Adressen überschneidet. „Ihre MRN lautet 7741032“ benötigt die Wörter um die Zahl herum, um überhaupt eine Bedeutung zu haben.
Ein kleines, fein abgestimmtes Sprachmodell übernimmt den Kontext – bei unserem handelt es sich um einen speziell trainierten 110M-Parameter-Encoder, der aus einem multilingualen Tiny Language Model destilliert wurde. Es liest den Satz, nicht den Teilstring, und ist klein genug, um extrem schnell auf einem Gerät, sogar auf einem Mobiltelefon, zu laufen.
Die Benchmarks verdeutlichen die komplementären Stärken der beiden Ebenen. Wir haben die beiden Ebenen isoliert getestet, um sicherzustellen, dass jede tatsächlich ihren Beitrag leistet. Auf dem PrivacyBench-PD-Fragensatz mit 150 Fragen, bei dem die Fragen und Antworten explizit NICHT zum Trainieren des Modells verwendet wurden, ergaben sich folgende Werte:
| Ebene | Erfasste PII | Erfassungsrate |
|---|---|---|
| Nur Regex | 205 / 670 | 30,6 % |
| Nur ML | 516 / 670 | 77,0 % |
| Beide (Produktion) | 625 / 670 | 93,3 % |
Regex allein übersieht drei Viertel der Identifikatoren, da die meisten Identifikatoren in realer Prosa nicht strukturiert sind. ML allein übersieht 16 Prozentpunkte, die die Regex-Ebene erfasst hätte – Dinge, die rein über ihre Form definiert sind (eine Kreditkarte sieht aus wie eine Kreditkarte; das Modell hat hier kein zusätzliches Signal beizutragen). Zusammen decken sie ab, was keine der beiden Ebenen allein bewältigen kann.
Ein tieferer Blick darauf, wo jede Ebene entscheidend ist: Über denselben Datensatz hinweg wurden 16 Testwerte nur durch Regex erfasst (E-Mails, IPs, Finanzkonten, strukturierte IDs) und 327 wurden nur durch ML erfasst (Namen, kontextuelle Identifikatoren, multilinguale Formulierungen).
Klein, intelligent, schnell – und läuft überall
Wir mussten den Filter auf dem Gerät zum Laufen bringen, was eine technische Herausforderung war.
Er muss klein sein, da unsere App auf vielen Systemen lokal läuft: in einer Browser-Erweiterung, einer macOS-App, einer iOS-App, einer Android-App oder unter Windows und Linux. Das Paket ist etwa 113 MB pro Modell groß. Es gibt zwei Modelle – eines für allgemeine personenbezogene Daten, eines für geschützte Gesundheitsinformationen – und der Safe-Harbor-Modus lässt beide parallel laufen. Unter diesen ist ein Low-End-Android-Gerät am wenigsten leistungsfähig, dennoch funktioniert unser System einwandfrei.
Er muss intelligent sein, da falsch-negative Ergebnisse echte Daten an ein Remote-LLM durchsickern lassen und falsch-positive Ergebnisse die Konversation ruinieren. Namen müssen geschwärzt werden; Pronomen dürfen es nicht. Die E-Mail des Arztes in einem weitergeleiteten Thread sollte geschwärzt werden; die Fußzeile [email protected] wahrscheinlich nicht.
Er muss schnell sein, da er direkt im Weg jeder Nachricht sitzt, die der Nutzer sendet oder empfängt. Wir haben den Round-Trip-Overhead auf unter 200 ms auf einem einzelnen CPU-Thread gemessen, hauptsächlich Tokenisierung. Auf WebGPU und auf Apples Neural Engine ist er winzig im Vergleich zur Netzwerklatenz des LLM-Aufrufs selbst.
Er muss in mehreren Laufzeitumgebungen laufen, da Caiioo plattformübergreifend ist. Dasselbe System läuft in Chrome-Erweiterungen, macOS und iOS, Android sowie auf Windows und Linux. Ein Erkennungsmodell, eine Regex-Bibliothek, ein Merger, eine Richtlinie – identisches Verhalten auf jeder Oberfläche, auf der Caiioo läuft.
Die Ergebnisse
Nach mehreren Test- und Trainingsrunden haben wir uns für die 16. Version unserer Modelle entschieden. Unten aufgeführt sind drei Benchmarks, die jeweils unterschiedliche Aspekte messen.
Unser eigener Testdatensatz, 150 Fragen, die das Modell noch nie gesehen hat
Bevor wir gegen öffentliche Benchmarks getestet haben, ließen wir unseren Personal Data Filter gegen einen internen Testdatensatz laufen, den wir bewusst nicht in die Trainingsdaten aufgenommen haben – der Detektor hat also keine dieser Fragen zuvor gesehen. 150 Fragen, aufgeteilt in vier Gruppen (Code-Snippets, Dokumentprosa, absichtlich ungewöhnliche Formulierungen und 10 nicht-englische Sprachen), plus eine „negative“ Gruppe, die keinerlei private Daten enthält (ein Plausibilitätscheck, um sicherzustellen, dass wir nicht zu viel schwärzen). Kombinierte Regex + ML Pipeline:
| Sub-bench | Erkannt | Quote |
|---|---|---|
| code_bench | 69 / 74 | 93,2 % |
| doc_bench | 233 / 247 | 94,3 % |
| generalization_bench | 123 / 133 | 92,5 % |
| multilingual_bench | 200 / 216 | 92,6 % |
| Alle 4 positiven Benches | 625 / 670 | 93,3 % |
(Die negative Gruppe enthielt keine privaten Daten, die zu finden gewesen wären. Der Filter maskierte eine Sache, die er nicht hätte maskieren sollen – konsistent mit den Präzisionswerten weiter unten.)
Die Bewertung ist streng: Jedes erwartete private Datenelement muss vollständig aus der maskierten Ausgabe verschwinden, damit die Frage gewertet wird. Es gibt keine Teilpunkte oder ein „nah genug dran“. Das ist härter als Benchmarks, die ein anderes LLM als Richter einsetzen (LLM-Richter neigen dazu, großzügig zu sein). Direkt vergleichbare Zahlen gegenüber anderen Systemen finden Sie im Head-to-Head-Abschnitt weiter unten.
PrivacyBenchHIPAA — 40 Gesundheitsfragen
Jede Frage listet geschützte Gesundheitsinformationen auf, die geschwärzt werden müssen (Namen, medizinische Rekordnummern usw.) UND Signale, die beibehalten werden müssen (Daten, Geografie, Alter, wenn unter 90 – die HIPAA Limited Data Set Regel). Der Bewerter prüft beide Richtungen: Haben wir entfernt, was wir hätten entfernen sollen, und haben wir unberührt gelassen, was wir hätten unberührt lassen sollen?
| Modus | PHI geschwärzt | Beibehaltene behalten |
|---|---|---|
| Limited Data Set (Daten / Geografie / Alter ≤89 bewahren) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (alles schwärzen, einschließlich Daten) | 99 / 104 (95,2 %) | — |
Der Limited Data Set Submodus schneidet bei diesem Benchmark perfekt ab. Safe Harbor – wo mehr zu schwärzen ist und somit mehr Gelegenheiten für Fehler bestehen – deckt 95,2 % ab.
Ergebnisse nach Kategorien auf unseren eigenen Daten, 200 Proben pro Modus
Öffentliche Benchmarks werfen alles in einen Topf. Unsere internen Testdaten schlüsseln die Ergebnisse nach Kategorien auf (Namen, E-Mails, Adressen usw.) und lassen jede auf drei Arten laufen: nur Regex, nur ML und beides zusammen. Das sagt uns genau, welche Technologie welche Art von Identifikator erkennt – und wo die eine die andere benötigt. Letzter Durchlauf, 2026-05-20:
Zusammenfassung über alle drei Filtermodi
| Modus | Kombinierter Recall | Präzision | F2 | Proben |
|---|---|---|---|---|
| Personal Data filter | 97,3 % | 97,8 % | 97,4 | 200 |
| HIPAA filter — Limited Data Set | 92,3 % | 92,3 % | 92,3 | 200 |
| HIPAA filter — Safe Harbor | 91,9 % | 91,5 % | 91,8 | 200 |
Diese Zahlen schließen URLs aus, die wir bewusst unberührt lassen – das Zerstören einer URL würde nachgelagerte Aktionen wie „diesen Link öffnen“ oder „diese Seite abrufen“ unmöglich machen. Mehr dazu im Abschnitt zum Workflow weiter unten.
Das Gesamtbild vor den Tabellen pro Kategorie: In jedem Modus werden die Identifikatoren, die tatsächlich eine Person identifizieren, in oder nahe 100 % der Fälle erkannt. Namen, E-Mails, Telefonnummern, Postanschriften, staatliche IDs, biometrische IDs, präzise Geolokalisierung, medizinische Rekordnummern, Geburtsdaten, Sozialversicherungsnummern – in jeder Probe, in jedem Test erkannt. Die Kategorien, in denen wir unter 100 % rutschen, sind vorhersehbar: Geräte-IDs (riesige Vielfalt an Formaten in realem Text), diverse institutionelle IDs (Kundennummern, Mitarbeiter-IDs – gleiches Problem) und Fotos (ein reiner Textfilter kann nicht sehen, was in einem Bild ist). Nichts davon ist der „Name auf einer Akte“ oder die „E-Mail in einem Entwurf“, der für Datenlecks tatsächlich von Bedeutung ist. Die Kategorien mit hohem Risiko sind die zuverlässigen.
Personal Data filter
Sortiert nach kombiniertem Recall (bester zuerst), dann nach Risikostufe (T1 = am sensibelsten).
| Kategorie | Stufe | Regex Recall | ML Recall (roh) | Kombinierter Recall | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| email_address | T1 | 100,0 % (20/20) | 100,0 % (20/20) | 100,0 % | 20 |
| government_id | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| person_name | T1 | 13,3 % (4/30) | 96,7 % (29/30) | 100,0 % | 30 |
| phone_or_fax | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| postal_address | T1 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| precise_geolocation | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| birth_date | T2 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| ip_address | T2 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| online_handle | T2 | 40,0 % (4/10) | 100,0 % (10/10) | 100,0 % | 10 |
| vehicle_id | T2 | 50,0 % (5/10) | 100,0 % (10/10) | 100,0 % | 10 |
| authentication_secret | T4 | 40,0 % (4/10) | 100,0 % (10/10) | 100,0 % | 10 |
| financial_account | T1 | 90,0 % (18/20) | 100,0 % (20/20) | 90,0 % | 20 |
| institutional_id | T3 | 80,0 % (8/10) | 90,0 % (9/10) | 90,0 % | 10 |
| device_id | T3 | 40,0 % (4/10) | 50,0 % (5/10) | 80,0 % | 10 |
Beim Vergleich zeigt sich, dass sich das zweischichtige Design auszahlt. Postanschriften, Geburtsdaten und Personennamen erzielen allein mit Regex Werte von 0–13 % – es gibt kein Muster, das passt, sodass nur das ML-Modell sie erfassen kann. E-Mails, Telefonnummern, IPs, staatliche IDs, biometrische IDs und präzise Geolokalisierung erreichen allein mit Regex 100 % – Oberflächenformate, die das ML-Modell quasi geschenkt bekommt. Online-Handles, Fahrzeug-IDs und Authentifizierungsgeheimnisse sind gemischt: Regex erfasst die Standardformen, ML den Rest. Der kombinierte Recall erreicht oder übertrifft in jeder Kategorie die jeweils stärkere Einzelschicht.
Geräte-IDs und diverse institutionelle IDs sind die Kategorien unter 100 %, und wir wissen warum: Diese haben die größte Vielfalt an Formaten in realem Text. Wir sind lieber ehrlich bei den Kategorien, in denen der Recall sinkt, als vorzugeben, der Filter sei überall perfekt.
HIPAA filter — Limited Data Set submode
Der Limited Data Set Submodus bewahrt Daten, Geografie und Alter von 89 Jahren oder jünger per Design – das sind die Signale, die HIPAA einer Organisation erlaubt, für legitime klinische Forschung und Betriebsabläufe zu behalten.
| Kategorie | Stufe | Regex Recall | ML Recall (roh) | Kombinierter Recall | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100,0 % (12/12) | 100,0 % (12/12) | 100,0 % | 12 |
| email_address | T1 | 100,0 % (13/13) | 100,0 % (13/13) | 100,0 % | 13 |
| medical_record_number | T1 | 100,0 % (26/26) | 100,0 % (26/26) | 100,0 % | 26 |
| person_name | T1 | 15,4 % (4/26) | 100,0 % (26/26) | 100,0 % | 26 |
| phone_or_fax | T1 | 100,0 % (13/13) | 100,0 % (13/13) | 100,0 % | 13 |
| social_security_number | T1 | 100,0 % (12/12) | 100,0 % (12/12) | 100,0 % | 12 |
| account_number | T2 | 0,0 % (0/13) | 100,0 % (13/13) | 100,0 % | 13 |
| health_plan_id | T2 | 0,0 % (0/13) | 100,0 % (13/13) | 100,0 % | 13 |
| ip_address | T2 | 100,0 % (12/12) | 100,0 % (12/12) | 100,0 % | 12 |
| license_number | T2 | 0,0 % (0/12) | 100,0 % (12/12) | 100,0 % | 12 |
| vehicle_id | T2 | 25,0 % (3/12) | 100,0 % (12/12) | 100,0 % | 12 |
| device_id | T3 | 41,7 % (5/12) | 100,0 % (12/12) | 100,0 % | 12 |
| photo | T2 | 0,0 % (0/12) | 0,0 % (0/12) | 0,0 % | 12 |
Fotos sind ein bekannter Schwachpunkt – ein reiner Textfilter kann nicht sehen, was in einem Bild ist. Bild-PHI ist ein separates Problem, für das wir noch keine Lösung ausgeliefert haben. Jede andere Kategorie in diesem Modus liegt bei 100 %.
HIPAA filter — Safe Harbor submode
Safe Harbor entfernt alles, was der Limited Data Set Submodus beibehalten hätte – Daten, Alter über 89, Geografie. Um die strengste Abdeckung zu erreichen, lässt er beide Filtermodelle parallel laufen: das HIPAA-spezifische und das allgemeine für persönliche Daten.
| Kategorie | Stufe | Regex Recall | ML Recall (roh) | Kombinierter Recall | Gold n |
|---|---|---|---|---|---|
| age_over_89 | T1 | 100,0 % (18/18) | 0,0 % (0/18) | 100,0 % | 18 |
| biometric_id | T1 | 100,0 % (9/9) | 100,0 % (9/9) | 100,0 % | 9 |
| email_address | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| medical_record_number | T1 | 100,0 % (20/20) | 100,0 % (20/20) | 100,0 % | 20 |
| person_name | T1 | 20,0 % (4/20) | 100,0 % (20/20) | 100,0 % | 20 |
| phone_or_fax | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| social_security_number | T1 | 90,0 % (9/10) | 100,0 % (10/10) | 100,0 % | 10 |
| account_number | T2 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| general_date | T2 | 100,0 % (27/27) | 29,6 % (8/27) | 100,0 % | 27 |
| health_plan_id | T2 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| ip_address | T2 | 100,0 % (9/9) | 100,0 % (9/9) | 100,0 % | 9 |
| license_number | T2 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| vehicle_id | T2 | 10,0 % (1/10) | 100,0 % (10/10) | 100,0 % | 10 |
| device_id | T3 | 22,2 % (2/9) | 88.9 % (8/9) | 77,8 % | 9 |
| photo | T2 | 0,0 % (0/9) | 0,0 % (0/9) | 0,0 % | 9 |
Die zwei interessanten Zeilen sind allgemeine Daten (Regex 100 %, ML 30 %) und Alter über 89 (Regex 100 %, ML 0 %). Wir lassen bewusst Regex beides in Safe Harbor handhaben: Daten haben ein Muster, das Regex jedes Mal erfasst, und wir möchten nicht, dass ein probabilistisches Modell einen numerischen Schwellenwert wie „>89“ infrage stellt. Eine deterministische Regel ist zuverlässiger, als das ML-Modell zu bitten, dieselbe Regel zu lernen.
Gesamtzahlen über alle Kategorien
Alles zusammengerechnet: Wie schneidet die volle Pipeline (Regex + ML zusammen) im Vergleich zu einer der Schichten allein ab?
| Modus | Schichten | Recall | Präzision | F2 |
|---|---|---|---|---|
| Personal Data | nur Regex | 65,8 % | 93,0 % | 69,9 % |
| Personal Data | nur ML | 95,4 % | 92,4 % | 94,8 % |
| Personal Data | beide (voll) | 96,9 % | 98,0 % | 97,1 % |
| Limited Data Set | nur Regex | 55,9 % | 95,0 % | 60,9 % |
| Limited Data Set | nur ML | 92,9 % | 84,5 % | 91,0 % |
| Limited Data Set | beide (voll) | 92,9 % | 89,3 % | 92,1 % |
| Safe Harbor | nur Regex | 58,9 % | 93,6 % | 63,6 % |
| Safe Harbor | nur ML | 82,4 % | 88,3 % | 83,5 % |
| Safe Harbor | beide (voll) | 92,4 % | 88,9 % | 91,7 % |
Die Zeile „voll“ des Personal Data Filters schlägt beide Einzelschicht-Versionen in jeder Metrik – die Kombination von Regex (für Oberflächenformate) mit dem ML-Modell (für den Kontext) bietet tatsächlich etwas, das keine Schicht allein leisten kann. Die 97,3 % Schlagzeile weiter oben in diesem Beitrag ist die Zahl, die widerspiegelt, was ein echter Benutzer erhält. Die Zahl in der obigen Tabelle ist nur deshalb etwas niedriger, weil sie die URL-Kategorie enthält, die wir bewusst beibehalten, um Links und Tool-Aufrufe nicht zu zerstören.
Head-to-Head gegen andere dedizierte Privacy-Filter
Der faire Vergleich für einen On-Device, nahezu verzögerungsfreien Privacy-Filter wie unseren ist der Vergleich mit anderen On-Device, nahezu verzögerungsfreien Privacy-Filtern – nicht gegen riesige Cloud-gehostete LLMs, die Sekunden pro Nachricht benötigen und einen Netzwerk-Roundtrip erfordern. Wir haben jedes System dieser Klasse gegen dieselben Testdatensätze mit denselben Matching-Regeln laufen lassen. Gleicher Standard für alle.
Die Vergleichsklasse:
- openai/privacy-filter — OpenAIs quelloffener, dedizierter Privacy-Filter. Etwa 50 Millionen Parameter, klein genug, um in jedem modernen Browser zu laufen.
- piiranha-v1 — ein Detektor mit 278 Mio. Parametern von iiiorg. Seine Lizenz beschränkt ihn auf Forschung und Evaluierung (wir können ihn messen, aber er darf nicht kommerziell ausgeliefert werden).
- Microsoft Presidio — der am weitesten verbreitete Open-Source-Redaktor, der traditionelles Pattern-Matching mit einem kleinen Sprachmodell für den Kontext kombiniert.
- GLiNER PII family — eine Familie kleiner, universeller Entity-Klassifikatoren. Knowledgator liefert Varianten in small (~44M), base (~86M) und large (~304M); NVIDIA veröffentlichte im Oktober 2025 eine 570M-Variante.
- Caiioo in allen drei Modi (Personal Data, HIPAA Limited Data Set, HIPAA Safe Harbor).
Recall über alle fünf Testdatensätze, sortiert mit Caiioo zuerst:
| System | PrivacyBench PD-25 | Caiioo synthetic PD-200 | PrivacyBenchHIPAA-40 | Caiioo synthetic PHI-200 | Multilingual PD-40 (10 Locales) |
|---|---|---|---|---|---|
| Caiioo — Personal Data | 96,2 % (76/79) | 99,0 % (198/200) | — | — | 92,6 % (200/216) |
| Caiioo — HIPAA Limited Data Set | — | — | 100,0 % (79/79) | 100,0 % (200/200) | — |
| Caiioo — HIPAA Safe Harbor | — | — | 100,0 % (79/79) | 100,0 % (200/200) | — |
| openai/privacy-filter (50M) | 96,2 % (76/79) | 83,0 % (166/200) | 93,7 % (74/79) | 77,0 % (154/200) | 94,9 % (205/216) |
| gliner_pii_nvidia (570M) | 94,9 % (75/79) | 85,5 % (171/200) | 84,8 % (67/79) | 85,0 % (170/200) | 76,9 % (166/216) |
| gliner_pii_large (~304M) | 72,2 % (57/79) | 86,5 % (173/200) | 84,8 % (67/79) | 93,0 % (186/200) | 50,0 % (108/216) |
| gliner_pii_base (~86M) | 87,3 % (69/79) | 66,0 % (132/200) | 74,7 % (59/79) | 66,0 % (132/200) | 51,4 % (111/216) |
| gliner_pii_small (~44M) | 88,6 % (70/79) | 84,5 % (169/200) | 91,1 % (72/79) | 83,0 % (166/200) | 68,5 % (148/216) |
| Microsoft Presidio | 82,3 % (65/79) | 76,5 % (153/200) | 84,8 % (67/79) | 76,5 % (153/200) | 69,0 % (149/216) |
| piiranha-v1 (~278M) | 60,8 % (48/79) | 58,5 % (117/200) | 43,0 % (34/79) | 47,0 % (94/200) | 82,4 % (178/216) |
Caiioo führt die Klasse der dedizierten Filter bei den beiden größten Tests (PD-200 und PHI-200) an, liegt bei den öffentlichen Benchmarks gleichauf oder vorn und belegt bei Multilingual den zweiten Platz. Beim kleinsten Test (PrivacyBench PD-25, nur 25 Fragen) liegen Caiioo und openai/privacy-filter mit 96,2 % gleichauf. Bei Multilingual führt openai/privacy-filter weiterhin mit 94,9 %, während Caiioo bei 92,6 % liegt – die Sprache, in der wir am meisten zurückliegen, ist Chinesisch; überall sonst liegen wir an oder nahe der Spitze. Wenn mehrsprachige Abdeckung geschäftskritisch ist, ist openai/privacy-filter eine vernünftige Alternative. Für die meisten anderen Workloads in dieser Klasse ist es Caiioo.
Das HIPAA-Ergebnis ist das Highlight. Beide Caiioo HIPAA-Modi erreichten 100 % Recall in jedem HIPAA-Test – jeder Patientenname, jede medizinische Rekordnummer, jedes Geburtsdatum, jede Kontonummer wird erfasst. Das zweitbeste System ist openai/privacy-filter mit 93,7 % bei PrivacyBenchHIPAA – eine Lücke von 6,3 Punkten in einem Benchmark, bei dem jeder Fehler eine reale Offenlegung bedeutet.
Eine zweite Zahl, die man beachten sollte: Über-Schwärzung – das Maskieren von Dingen, die eigentlich keine privaten Daten waren. Über-Schwärzung ist kein Datenschutzschaden, sondern ein Usability-Kostenfaktor. Wenn zu viele Dinge maskiert werden, verschlechtert sich die Argumentation des LLM und die zurückgegebene Antwort wird minderwertig. Caiioo maskiert unnötigerweise 1–24 Mal über die Testdatensätze hinweg. Presidio: 10–51. NVIDIAs GLiNER: 31–64 allein bei den HIPAA-Tests. Präzision ist genauso wichtig wie Recall, wenn das Ziel die bestmögliche Antwort bei geringstmöglicher Exposition ist.
Was ist mit der Verwendung eines Frontier LLM als Filter?
Sie können das – und beim rohen Recall gewinnen sie. Große Allzweck-LLMs (Llama 3.1 8B, Gemma 4, Qwen 3.5 9B und ähnliche), die entweder in der Cloud oder lokal laufen, können 95–100 % in jedem Test erreichen, einschließlich Multilingual. Das ist eine echte Option für Benutzer, die maximalen Recall benötigen und bereit sind, dafür zu zahlen.
Die Nachteile sind jedoch real:
- Es ist langsam. Sekunden pro Nachricht statt Millisekunden. Der Filter sitzt vor jeder Nachricht, die der Benutzer sendet.
- Entweder verlässt die Nachricht den Rechner des Benutzers oder das Modell tut es. Um in der Cloud zu filtern, muss die Nachricht dorthin gesendet werden – was den Zweck zunichtemacht. Um auf dem Gerät zu filtern, muss ein 1–17 GB großes Modell heruntergeladen werden.
- Es kann ausgetrickst werden. Ein generatives Modell kann mitten in der Nachricht dazu überredet werden, nicht zu schwärzen (ein „Prompt Injection“-Angriff). Ein kleiner Klassifikator wie unserer kann das nicht.
- Gleicher Input, unterschiedlicher Output. Generative Modelle geben nicht immer zweimal dieselbe Antwort. Das macht den Roundtrip kaputt – das Maskieren auf dem Hinweg und das Demaskieren auf dem Rückweg beruht darauf, dass derselbe reale Wert immer demselben Fake-Wert zugeordnet wird.
Caiioo ist für die andere Seite dieses Kompromisses gebaut: ein winziger, vorhersehbarer Sub-Sekunden-Filter, der im Composer läuft, bevor der Benutzer auf Senden drückt, und der innerhalb einer Konversation immer denselben Fake-Wert für denselben realen Wert erzeugt, damit der Roundtrip kohärent bleibt. Die obige Vergleichstabelle ist der Äpfel-mit-Äpfeln-Vergleich für diese Art von Anwendungsfall.
Der Beweis liegt im Detail
Benchmarks sind ein Ausgangspunkt, kein Ziel. Der Filter ist fest in Caiioos neue Funktion integriert: den Pseudonymizer — die Komponente, die sich tatsächlich zwischen dem Composer und dem Modell befindet.
Hier ist der Ablauf, wenn der Benutzer auf Senden drückt.
- Erkennen. Die Regex-Ebene wird zuerst ausgeführt — sie ist deterministisch und mikrosekundenschnell. Das ML-Modell wird als Nächstes auf den verbleibenden Teil angewendet. Wenn sich die beiden Ebenen bei demselben Textabschnitt überschneiden, gilt eine einfache Regel: Regex gewinnt bei Oberflächenformaten, ML gewinnt beim Kontext.
- Tagging von Selbst vs. Anderen. Caiioo trennt Identifikatoren, die sich auf den Benutzer beziehen, von Identifikatoren, die sich auf andere Personen beziehen. Der Benutzer kann wählen, ob nur einer oder beide geschwärzt werden sollen. Namen, die der Benutzer einem persönlichen Wörterbuch hinzugefügt hat, zählen immer als „selbst“.
- Ersetzen. Jeder reale Wert erhält ein stabiles, stilistisch passendes Pseudonym. „Sarah Goldberg“ wird zu „Maya Hartwell“ — und bleibt „Maya Hartwell“ während der gesamten Konversation, damit die Argumentation des Modells über diese Person nicht über verschiedene Runden hinweg fragmentiert. Eine Real-zu-Fake-Nachschlagetabelle wird auf dem Gerät des Benutzers gespeichert, verschlüsselt mit einem Schlüssel aus dem Keychain der Plattform.
- Senden. Das Modell erhält eine vollständig gefälschte Nachricht. Kein realer Identifikator überquert jemals das Netzwerk, und unser Audit-Log zeichnet nur Zählwerte auf — niemals die Werte selbst.
- Wiederherstellen. Die Streaming-Antwort wird bei der Ankunft zurückgemappt. „Maya Hartwell“ in der Antwort des Modells wird zu „Sarah Goldberg“, bevor sie den Bildschirm erreicht, dargestellt mit einem kleinen leuchtenden Pill-Indikator, damit der Benutzer auf einen Blick sehen kann, was geschützt wurde.
- Auch Tool-Argumente wiederherstellen. Wenn das Modell ein Tool aufruft — eine E-Mail sendet, ein Ticket erstellt, in ein Dokument schreibt — und die Argumente Fälschungen enthalten, setzen wir die realen Werte wieder ein, bevor das Tool ausgeführt wird. Das Modell argumentiert über Fälschungen; die Aktion verwendet den realen Wert.
Dem Filter ist es egal, welcher AI-Dienst verwendet wird. Er läuft ab, bevor die Nachricht das Modell erreicht, sodass OpenRouter, Anthropic, Google, OpenAI und ein lokales Ollama alle die gleiche maskierte Payload erhalten. Das Hinzufügen eines neuen Providers öffnet die Datenschutzlücke nicht erneut.
Wen er schützt
Den Nutzer. Name, E-Mail, Adresse, Telefonnummer, IP und biometrische Identifikatoren eines Nutzers – die Dinge, die zusammengefasst eine Person für einen Aggregator identifizierbar machen – verlassen das Gerät niemals, wenn der Filter aktiviert ist.
Die Personen, über die der Nutzer spricht. Die meisten Datenschutz-Tools konzentrieren sich auf die Person, die tippt, aber was sie ignorieren, ist der „Gesellschaftsvertrag“ – die Tatsache, dass wir alle eine Verantwortung gegenüber anderen sowie gegenüber uns selbst tragen. Die Übermittlung von „Bitte analysieren Sie das Verhalten von Herrn Saunders auf Inkompetenz“ an ein LLM, wo es auf unbestimmte Zeit in Systemprotokollen aufgezeichnet werden kann, ist unverantwortlich (und potenziell diffamierend). Ein LLM um Hilfe bei einer Google-Tabelle zu bitten, die 1.000 Geschäftskontakte enthält, hinterlässt all diese Daten im Fliegenfänger der Datenspeicherung (in unterschiedlichem Maße, je nach der tatsächlich geltenden „Zero Data Retention“). Der Filter von Caiioo deckt auch Dritte ab: den Kunden, für den ein Vertrag entworfen wird, den Patienten, dessen Akte analysiert wird, den Kollegen, dessen E-Mail in den Kontext kopiert wurde. Sie haben nicht zugestimmt, dass ein Remote-LLM ihre Identifikatoren sieht. Der Filter respektiert das standardmäßig; der Nutzer kann auf „nur ich selbst“ oder „nur andere“ umschalten, wenn ein Workflow dies erfordert.
Einheiten – Unternehmen, Krankenhäuser, Firmen. Kontonummern, Lizenznummern, medizinische Aktennummern, finanzielle Routing-Details, interne IDs, API-Schlüssel, Kundenlisten. Ein Unternehmen hat das gleiche Interesse an Datenminimierung wie eine Person. Ein Kliniker, der Caiioo verwendet, um einen Entlassungsbericht zu entwerfen, sendet die medizinische Aktennummer des Patienten nicht an OpenAI. Ein Anwalt sendet die Kontonummer des Mandanten nicht an Anthropic. Ein Support-Ingenieur sendet den API-Schlüssel aus dem Protokoll des Kunden nicht an Google. Der Filter fragt nicht, ob der Identifikator zu einer Person oder einer Einheit gehört – er behält ihn einfach auf dem Gerät.
Maximaler Nutzen, minimale Exposition
Der springende Punkt ist, dass der Nutzer den Filter nicht spüren sollte.
Die meisten Datenschutz-Tools erzwingen eine Wahl: aggressiv schwärzen und zusehen, wie die Antwort des Modells schlechter wird, oder den Prompt nutzbar halten und zusehen, wie das Datenschutzversprechen erodiert. Wir haben diesen Kompromiss abgelehnt. Das Modell erhält weiterhin einen vollständig formulierten Prompt – es sieht einen Namen, einen Ort, ein Datum, eine medizinische Aktennummer, alles an den richtigen grammatikalischen Positionen. Es sieht nur gefälschte Werte. Seine Argumentation ist identisch; nur die Zeichenfolgen sind bereinigt.
Stabile Substitution ist das, was dies ermöglicht. Da derselbe reale Wert innerhalb einer Konversation immer demselben gefälschten Wert zugeordnet wird – über die Nachricht des Nutzers, das Tool-Ergebnis, das auf diesen Namen verweist, bis hin zur früheren Antwort des Modells, die ihn erwähnte –, hat das Modell eine kohärente Person, einen Ort oder eine Sache, über die es nachdenken kann. Mehrstufige Konversationen werden nicht durcheinandergebracht. Tool-Aufrufe brechen nicht ab. Sub-Agenten erben die Map der übergeordneten Konversation und bleiben über die gesamte Aufgabe hinweg konsistent.
Die Ausgabe, die der Nutzer sieht, ist die echte Konversation. Die Daten, die der Anbieter sieht, sind eine kohärente Fiktion. Die Arbeit findet in der Lücke zwischen diesen beiden Ansichten statt, und das Ziel – das einzige Ziel – ist es, diese Lücke unsichtbar zu machen.
Ein Datenschutzfilter, der im Weg steht, wird ausgeschaltet. Ein Datenschutzfilter, der im Workflow verschwindet, ist der einzige, den es sich zu veröffentlichen lohnt.
Das ist der Maßstab, nach dem wir gebaut haben.