Referenz statt Reproduktion

Das Versprechen, das die meisten Anbieter nicht einlösen

„Wir pseudonymisieren Ihre Daten" ist einer der beliebtesten Sätze im Datenschutz-Marketing — und einer der am wenigsten geprüften. Denn Pseudonymisierung braucht per Definition eine Zuordnung, die sich wieder auflösen lässt: Irgendwo muss stehen, wofür «Person 1» eigentlich steht, sonst wäre der Platzhalter am Ende der Sitzung nur noch Datenmüll. Die spannende Frage ist nicht, ob diese Zuordnung existiert. Sie muss existieren. Die spannende Frage ist, wie sie aussieht — und was passiert, wenn sie in die falschen Hände gerät.

Die naheliegende, bequeme Lösung ist eine Tabelle: Platzhalter links, Klartext rechts. Name, Adresse, Telefonnummer, alles fein säuberlich in einer Datenbank. Genau diese Tabelle baut JiCo nicht — aus einem einfachen Grund: Eine solche Tabelle ist selbst wieder ein vollwertiger PII-Bestand. Man hätte das Problem, das man lösen wollte, gerade neu erschaffen, nur an einer anderen Stelle im System.

Zwei Fälle, zwei Antworten

JiCo unterscheidet zwischen zwei Arten von Personendaten, weil sie sich technisch fundamental unterscheiden — und behandelt sie entsprechend verschieden.

Für Jira-Entitäten — den Bearbeiter eines Tickets, den Melder, jemanden, der in einem Kommentar erwähnt wird — kennt JiCo bereits ein stabiles, eindeutiges Merkmal: die Jira-ID. Diese Referenz zu speichern, statt des Namens, trägt keine Adresse, kein Geburtsdatum, keine Kontaktdaten. Sie ist ein Zeiger, kein Inhalt. Wer diesen Zeiger auflösen will, um herauszufinden, wer sich dahinter verbirgt, braucht ohnehin bereits Zugriff auf Jira selbst — das Mapping reproduziert also nichts, was ein Angreifer nicht auch direkt aus dem System holen könnte, wenn er dort schon drin ist.

Für alles andere — eine Telefonnummer, die frei im Ticket-Text auftaucht, ein Name im Kommentar eines Kollegen, der selbst kein Jira-Benutzer ist — gibt es diese stabile Referenz nicht. Hier bleibt nur, den tatsächlichen Wert zu speichern, aber verschlüsselt mit AES-256 und gebunden an genau den einen Auftrag, für den er gebraucht wird. Kein globaler Schlüsselbund, kein Bestand, der über Aufträge hinweg wächst.

Warum überhaupt etwas gespeichert werden muss

Man könnte fragen: Warum nicht einfach gar nichts merken? Jede Sitzung startet leer, jeder Platzhalter verfällt sofort. Das wäre der radikalste Schutz — und er würde für ein interaktives Gespräch mit einem Assistenten sogar funktionieren, weil dort Frage und Antwort in derselben Sitzung liegen.

Er würde aber jeden Auftragsbetrieb unmöglich machen. Ein Nachtlauf, der 400 Tickets durchgeht und morgens eine verdichtete Freigabe-Mappe vorlegt, braucht die Zuordnung zwischen Platzhalter und Ursprung noch Stunden später, wenn ein Mensch am nächsten Morgen tatsächlich entscheidet — lange nachdem das Modell den Platzhalter zuletzt gesehen hat. Ohne ein Mapping, das diese Zeitspanne überlebt, gäbe es keinen Nachtlauf, keine Warteschlange, keine automatisierte Vorprüfung. Nur Einzelanfragen, eine nach der anderen, mit einem Menschen, der die ganze Zeit daneben sitzt.

96 Stunden, und keine Stunde länger als nötig

Beide Mapping-Arten — die Jira-Referenz wie das verschlüsselte Freitext-Mapping — verfallen automatisch nach 96 Stunden. Häufig sogar deutlich früher: Sobald über den letzten offenen Vorschlag eines Auftrags entschieden ist, wird das zugehörige Mapping gelöscht, ganz gleich, wie viel von den 96 Stunden noch übrig gewesen wäre. Ein Auftrag, dessen Mapping bereits abgelaufen ist, wird nicht stillschweigend mit veralteten Daten weiterbearbeitet — er gilt als hinfällig und muss neu angestossen werden.

Diese Frist ist keine willkürliche Zahl. Sie ist die Antwort auf die Frage, wie lange ein Mensch realistisch braucht, um eine nächtliche Freigabe-Mappe zu sichten und zu entscheiden — plus einen Puffer, aber keinen Blankoscheck.

Was im Audit-Trail steht — und was ausdrücklich nicht

Ein Detail, das leicht übersehen wird, wenn man nur auf die Existenz eines Audit-Trails schaut, nicht auf seinen Inhalt: Dieses Mapping steht in keinem Fall im Audit-Trail. Der Audit-Trail belegt, dass redigiert wurde und wie viel, aufgeschlüsselt nach Typ — Anzahl der erkannten Namen, Anzahl der maskierten Telefonnummern, so etwas. Er belegt nicht was konkret redigiert wurde. Wer den Audit-Trail liest, um zu verstehen, was ein Modell im Lauf einer Woche gesehen hat, bekommt eine Bilanz, keine Klartext-Liste. Für den tatsächlichen Inhalt bräuchte er weiterhin entweder Zugriff auf Jira direkt oder auf das eine, befristete Mapping eines noch laufenden Auftrags.

Eine feste Zahl statt einer vagen Absicht

Die Länge dieser Frist — 96 Stunden, nicht „möglichst kurz" oder „so lange wie nötig" — ist selbst schon bemerkenswert, weil sie überhaupt eine konkrete, nachprüfbare Zahl ist und keine vage Absichtserklärung. Länger zu speichern wäre technisch bequemer gewesen: ein Auftrag, der liegen bleibt, weil eine Freigabe erst später fällt, würde dann einfach unbegrenzt weiterlaufen. Genau diese Bequemlichkeit ist aber der Punkt, an dem Datensparsamkeit anfängt, real etwas zu kosten, statt nur eine Überschrift in einem Compliance-Dokument zu bleiben: Je länger ein Mapping existiert, desto länger existiert irgendwo eine Datei, die sich — mit dem richtigen Schlüssel — zu einer Re-Identifikation zusammensetzen ließe. Eine feste, kurze Frist ist damit selbst schon eine Aussage: nicht „wir versprechen, sparsam zu sein", sondern eine Zahl, die sich im Code nachlesen und im Verhalten des Systems beobachten lässt, statt nur in einem Prospekt zu stehen.

Die Grenze, die auch für das Modell selbst gilt

Ein letztes Detail, das oft übersehen wird, weil es kontraintuitiv klingt: Das Modell bekommt in keinem der beiden Fälle die Jira-ID zu Gesicht — nur den Platzhalter. Man könnte meinen, die ID sei doch harmlos genug, um sie als Trostpreis durchzureichen, wenn schon kein Klartextname erlaubt ist. Genau das tut JiCo nicht. Die Referenz existiert ausschließlich, damit JiCo selbst am Ende der Sitzung wieder auflösen kann, wer gemeint war — nicht, damit das Modell ein stabiles, über mehrere Tickets hinweg wiedererkennbares Merkmal einer Person bekommt. Wäre die ID im Modellkontext sichtbar, hätte man dem Modell genau das Werkzeug in die Hand gegeben, mit dem es Personen über verschiedene Anfragen hinweg wiedererkennen und verknüpfen könnte — und genau das soll die Schleuse verhindern, nicht nur den Namen selbst verstecken.