Privacy Guard: Personenbezogene Daten maskieren.
Diese Seite beschreibt, was technisch passiert, wenn Sie in Coveniq eine Nachricht absenden. Sie ist für Datenschutzbeauftragte, IT-Leitungen und alle geschrieben, die den Schutz nicht glauben, sondern nachprüfen wollen. Sie benennt auch, was der Guard nicht kann.
Was der Guard daraus macht
Die Vorführung
Ihr Text, durch den echten Guard.
Der Platzhalter trägt die Kategorie. Das Modell weiß, dass an dieser Stelle eine Person steht und nicht ein Betrag.
Die Beispiele sind deutsch, weil der Guard auf Deutsch kalibriert ist. Eigenen Text prüfen Sie in jeder Sprache.
Verwenden Sie nur fiktive Testdaten. Ihr Text wird zur Analyse an den Privacy Guard gesendet, nicht an ein Sprachmodell. Höchstens 2.000 Zeichen, zwanzig Prüfungen je Stunde.
Was das Modell liest
Der Guard zählt die Fundstellen der Reihe nach durch. Steht derselbe Name zweimal im Text, bekommt er zwei Nummern.
Die Pipeline
Sieben Stationen bei aktiviertem Privacy Guard
Der Privacy Guard ist ein eigenständiger Dienst in einem eigenen Repository. Die Anwendung ruft ihn über HTTP auf und authentifiziert sich mit einem Token, das ausschließlich serverseitig existiert und den Browser nie erreicht. Sie kennt weder die Erkennungsmodelle noch das Mapping zwischen echtem Wert und Platzhalter.
1
Eingabe
Prompt mit echten Namen, Adressen und Aktenzeichen. Nichts muss vorher geschwärzt werden.
2
Längenprüfung
Die Länge wird geprüft, bevor irgendein Dienst die Nachricht sieht. Grenze: 60.000 Zeichen.
3
Pseudonymisierung
Erkannte personenbezogene Daten werden durch strukturierte Platzhalter ersetzt. Die Erkennung kann Informationen übersehen.
Grenze Ihrer Organisation
4
Wissensraum-Suche
Die semantische Suche läuft mit dem mitigierten Text. Auch der Embedding-Anbieter sieht keine Rohdaten.
5
Modellaufruf
Nur der pseudonymisierte Prompt geht an OpenAI oder Anthropic.
Grenze Ihrer Organisation
6
Deanonymisierung
Die Platzhalter werden zurückgesetzt. Danach prüft der Guard auf durchgesickerte Werte.
7
Speicherung und Ausgabe
Drei getrennte Ebenen werden gespeichert. Nach erfolgreicher Deanonymisierung sieht der Nutzer die Antwort mit den Originalwerten.
Eingabe
Ihr Text, wie Sie ihn geschrieben haben.
Dieses Beispiel zeigt den Unterschied zwischen Originaltext und der Fassung für das Modell.
Der Verweis, der Platzhalter und Originalwert verbindet, lebt genau einen Chat-Turn lang. Er wird in der Datenbank der Anwendung nicht gespeichert. Nach dem Turn gibt es dort keinen Schlüssel mehr, der die beiden zusammenführt.
Was erkannt wird
Fünfzehn Kategorien. Und alles, was Sie ergänzen.
Erweiterbar durch Fine-Tuning, mandantenspezifisch.
Identität
- Person
- E-Mail-Adresse
- Telefonnummer
- IP-Adresse
- URLerkannt, nicht ersetzt
Ort und Zugehörigkeit
- Straße
- Hausnummer
- Postleitzahl
- Ort
- Organisation
Kontext
- Datum und Zeiterkannt, nicht ersetzt
- Nationalität / Religion / Politik
Nie freigebbar
- IBAN
- Kreditkartennummer
- Interne ID
Die drei Kategorien mit Schloss sind von jeder Freigabe ausgenommen, und die Sperre wird serverseitig durchgesetzt. Selbst ein manipulierter Client kann sie nicht umgehen.
Zwei Kategorien erkennt der Guard, ersetzt sie aber nicht: ein Datum allein lässt keinen Rückschluss auf eine Person zu, und was in einer Adresse im Netz steht, fängt der jeweils zuständige Erkenner. Sie leuchten deshalb nie auf.
Die Grenzen
Was der Guard erkennt, ist parametrierbar.
Erkennung personenbezogener Daten arbeitet mit trainierten Modellen und Regeln. Sprache ist kontextabhängig, jede Organisation hat eigene Kürzel und Formate. Deshalb weicht die Erkennung in zwei Richtungen ab: sie schützt zu viel oder zu wenig. Wir benennen beides, weil die Offenheit über die Grenzen das glaubwürdigste Argument ist, das wir haben.
Ein Anbieter, der Ihnen an dieser Stelle Perfektion verspricht, hat entweder nicht gemessen oder sagt nicht die Wahrheit.
Erster Lauf
Bitte prüfen Sie die Route über Google Maps und melden Sie sich bis Freitag.
Zweiter Lauf
Bitte prüfen Sie die Route über Google Maps und melden Sie sich bis Freitag.
Erster Lauf
Der Vorgang läuft unter der Personalnummer EMP-1234, bitte im Protokoll vermerken.
Zweiter Lauf
Der Vorgang läuft unter der Personalnummer [DE_INTERNAL_ID_1], bitte im Protokoll vermerken.
Was der Guard falsch sieht, korrigieren Sie dauerhaft.
Beides melden Ihre Nutzer mit einem Klick. Beides korrigieren Ihre Administratoren dauerhaft.
Zwei Korrekturarten, ein geführter Dialog. Was Nutzer über die Meldefunktion einreichen, sammelt sich in einer Warteschlange. Bestätigt der Administrator eine Meldung, entsteht daraus automatisch eine dauerhafte Korrektur, und es wird festgehalten, wer sie bestätigt hat.
Direkt im Dialog gibt der Administrator einen Beispieltext ein und sieht sofort, welche Stellen das Muster erfasst, bevor er speichert. Kein Ausprobieren im Live-Betrieb.
Kontrolle und Nachweis
Sie stellen ein, wie viel Ihre Leute sehen und entscheiden dürfen.
Den innersten Ring stellt niemand ein. Diese drei Darstellungen beantworten die Fragen, die IT-Leitungen und Datenschutzbeauftragte im Evaluationsgespräch tatsächlich stellen.
Welche Fehler blockieren den Modellaufruf?
Normalfall
- Eingabe
- Privacy Guard
- Modell
- Antwort
Guard antwortet nicht
- Eingabe
- Privacy Guard
- Modell
- Antwort
Beide Läufe zeigen einen aktivierten Guard. Scheitert die Prüfung vor dem Modellaufruf, wird die Anfrage blockiert. Spätere Prüfungen haben eigene Fehlerwege.
Die wichtigsten Fehlerfälle im Überblick:
| Situation | Verhalten der Anwendung |
|---|---|
| Guard nicht erreichbar oder Fehler bei der Pseudonymisierung | Der Modellaufruf findet nicht statt. Der Nutzer bekommt eine Fehlermeldung, keine Antwort. |
| Fehler bei der Deanonymisierung | Der Fehler wird protokolliert; die Antwort wird mit Platzhaltern statt Originalwerten ausgeliefert. |
| Fehler bei der Leak-Prüfung | Wird protokolliert, der Chat läuft weiter. Die Prüfung ist eine Warnung, kein Tor. |
| Leak erkannt | Wird protokolliert. Die Antwort wird ausgeliefert, da der Nutzer die betreffenden Werte selbst eingegeben hat. |
| Nachricht über 60.000 Zeichen | Wird abgelehnt, bevor irgendein Dienst sie sieht. Auch dann, wenn der Guard für den Mandanten abgeschaltet ist. |
Situation
Guard nicht erreichbar oder Fehler bei der Pseudonymisierung
Verhalten der Anwendung
Der Modellaufruf findet nicht statt. Der Nutzer bekommt eine Fehlermeldung, keine Antwort.
Situation
Fehler bei der Deanonymisierung
Verhalten der Anwendung
Der Fehler wird protokolliert; die Antwort wird mit Platzhaltern statt Originalwerten ausgeliefert.
Situation
Fehler bei der Leak-Prüfung
Verhalten der Anwendung
Wird protokolliert, der Chat läuft weiter. Die Prüfung ist eine Warnung, kein Tor.
Situation
Leak erkannt
Verhalten der Anwendung
Wird protokolliert. Die Antwort wird ausgeliefert, da der Nutzer die betreffenden Werte selbst eingegeben hat.
Situation
Nachricht über 60.000 Zeichen
Verhalten der Anwendung
Wird abgelehnt, bevor irgendein Dienst sie sieht. Auch dann, wenn der Guard für den Mandanten abgeschaltet ist.
Jeder Guard-Aufruf ist auf unter zwei Sekunden unter normaler Last ausgelegt. Die Anwendung bricht nach fünf Sekunden ab.
Drei Ebenen der Kontrolle
Außen: Mandanten-Vorgabe
Tenant-Admin
Privacy Guard an, Transparenz an, Prüfung vor dem Senden aus. Gilt für alle Nutzer des Mandanten.
Mitte: Abweichung pro Nutzer
Tenant-Admin unter Mitglieder
Die Prüfung vor dem Senden für die Rechtsabteilung einschalten, ohne sie der ganzen Belegschaft zuzumuten.
Innen: serverseitige Grenze
fest eingebaut, nicht abschaltbar
IBAN, Kreditkarte und interne Kennung sind nie freigebbar. Durchgesetzt auf dem Server, nicht im Browser.
Ein einzelner Nutzer kann den Schutz nicht abschalten. Das ist eine Organisationsentscheidung, keine individuelle.
Drei Inhaltsebenen pro Nachricht
Raw Content
Was der Nutzer eingegeben hat. Referenz, Audit, Anzeige im Chat.
Mitigated Content
Was das KI-Modell gelesen hat. Der Nachweis, was tatsächlich die Plattform verlassen hat.
Final Content
Was der Nutzer erhalten hat. Ausgabe und Archiv.
Getrennt und mandantengebunden in der Plattform gespeichert, für Nachweis und Fehleranalyse. Row Level Security trennt den Zugriff zwischen Organisationen.
FAQ
Die Fragen, die tatsächlich gestellt werden
Nein. Der Privacy Guard wird ausschließlich auf Organisationsebene gesteuert. In der Oberfläche eines Nutzers gibt es keinen Schalter dafür.
Ist der Privacy Guard aktiviert und die Pseudonymisierung schlägt fehl, findet kein Modellaufruf statt. Fehler bei späteren Prüfungen werden unten getrennt beschrieben.
Für jede Nachricht ist getrennt gespeichert, was der Nutzer geschrieben hat und was das Modell gelesen hat. Zusätzlich zeigt die Statistik, wie viele Angaben in welchem Zeitraum geschützt wurden, und das Freigaben-Audit hält jede bewusste Ausnahme fest.
Kalibrierung
Prüfen Sie es an Ihren eigenen Daten.
Der Guard kennt die Kürzel Ihres Hauses noch nicht. In der Einführung bringen Sie sie ihm bei, und die Korrekturen gehören ausschließlich Ihnen.