Der Weg zum Modell führt durch den Guard.
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.
Der Text geht zur Analyse an den Privacy Guard. Er wird dort nicht gespeichert und nicht an ein Sprachmodell weitergegeben. 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, jede einzelne Nachricht
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
Alle personenbezogenen Entitäten werden durch strukturierte Platzhalter ersetzt.
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. Der Nutzer sieht die vollständige Antwort.
Eingabe
Ihr Text, wie Sie ihn geschrieben haben.
Was das Modell sieht, kann Ihre Daten nicht verraten. Es sieht sie nie.
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.
Wenn der Schutz ausfällt, fällt die Anfrage aus
Normalfall
- Eingabe
- Privacy Guard
- Modell
- Antwort
Guard antwortet nicht
- Eingabe
- Privacy Guard
- Modell
- Antwort
Beide Läufe starten gleich. Der Unterschied entsteht an der zweiten Station: der Fehlerfall ist Blockieren, nicht Durchlassen. Ein Ausfall der Schutzschicht kostet eine Antwort, er kostet nie Ihre Daten.
Dieselbe Regel für jeden weiteren Fehlerfall, vollständig aufgeführt:
| 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 Chat-Vorgang wird abgebrochen. |
| 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. |
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 gespeichert, mandantengebunden, für Nachweis und Fehleranalyse. Alle drei Ebenen liegen in der Datenbank des Mandanten, abgesichert durch Row Level Security. Sie verlassen die Plattform nicht.
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.
Dann findet der Modellaufruf nicht statt. Der Nutzer bekommt eine Fehlermeldung. Ein Ausfall der Schutzschicht führt nie dazu, dass ungeschützte Daten durchgehen.
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.
Ja. Genau deshalb gibt es Fine-Tuning. Nutzer melden Fehlerkennungen mit einem Klick, Administratoren bestätigen sie mit einem Klick, und die Korrektur gilt dauerhaft und ausschließlich für Ihre Organisation. Anbieter, die an dieser Stelle Perfektion behaupten, haben das Problem nicht gemessen.
Dafür gibt es zwei Wege. Kurzfristig gibt der Nutzer die Angabe in der Prüfung vor dem Senden frei, sofern die Organisation das erlaubt und es keine besonders schutzbedürftige Kategorie ist. Dauerhaft trägt der Administrator eine Korrektur ein, und der Fall tritt nicht wieder auf.
Nur eingeschränkt und nur nachvollziehbar. Bankverbindungen, Kreditkartennummern und interne Kennungen sind grundsätzlich nicht freigebbar, durchgesetzt auf dem Server. Jede andere Freigabe wird mit Nutzer, Zeitpunkt und Wert protokolliert. Und die Funktion ist standardmäßig aus.
Nein. Korrekturen gelten mandantenspezifisch. Alle Daten sind auf Datenbankebene mandantengebunden, durchgesetzt durch Row Level Security, nicht durch Filterlogik in der Anwendung.
Nein. Es laufen dieselben Modelle wie überall: die aktuellen Spitzenmodelle von Anthropic und OpenAI, dazu deren schnellere Varianten für einfachere Aufgaben. Welche Modelle angebunden sind, halten wir aktuell, und Ihre Administratoren wählen je Assistent aus. Der Unterschied liegt darin, was die Modelle zu sehen bekommen. Die Platzhalter sind typisiert und nummeriert, das Modell erkennt also Rollen und Beziehungen im Text.
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.