Welcher Schutzweg passt zu welchem Vorgang?
Pseudonymisieren vs. anonymisieren vs. lokal rechnen
Drei Wege, Kundendaten aus dem Prompt zu halten. Sie lösen unterschiedliche Probleme, und die häufigste Fehlentscheidung besteht darin, den falschen für die eigene Aufgabe zu wählen.
Kurz eingeordnet.
Pseudonymisierung erhält Bezüge für die Verarbeitung, Anonymisierung verhindert die Rückübersetzung und lokale Modelle halten personenbezogene Daten im eigenen Netz.
Inhalt 6 Kapitel
Pseudonymisieren vs. anonymisieren vs. lokal rechnen
Worum es geht
Wer vertrauliche Unterlagen mit einem Sprachmodell bearbeiten will, hat drei Wege, und sie sind keine Geschmacksfrage:
- Pseudonymisieren. Personenbezogene Angaben werden durch Platzhalter ersetzt, bevor die Anfrage das Haus verlässt; die Zuordnung bleibt gespeichert, damit die Antwort zurückübersetzt werden kann.
- Anonymisieren. Der Personenbezug wird irreversibel entfernt, meist durch Vergröbern und Zusammenfassen von Merkmalen. Eine Rückübersetzung gibt es nicht, und das ist der Zweck.
- Lokal rechnen. Ein selbst betriebenes Modell verarbeitet die Daten im eigenen Netz; nichts geht hinaus.
Die Entscheidung fällt nicht am Schutzniveau, sondern an der Aufgabe.
Vergleich
| Dimension | Pseudonymisieren | Anonymisieren | Lokal rechnen |
|---|---|---|---|
| Rückübersetzung möglich | ja, kontrolliert | nein, konstruktionsbedingt | entfällt |
| DSGVO-Status der Daten | weiterhin personenbezogen | bei belastbarer Umsetzung nicht mehr | personenbezogen, bleibt intern |
| Antwortqualität | hoch, Modellwahl frei | sinkt mit dem Grad der Vergröberung | begrenzt durch das eigene Modell |
| Typische Aufgabe | zusammenfassen, formulieren, einordnen | auswerten, weitergeben, veröffentlichen | alles, wo Qualität nachrangig ist |
| Aufwand beim Aufbau | mittel: Erkennung, Prüfung, Zuordnung | hoch: Merkmalsanalyse, Risikobewertung | hoch: Hardware, Betrieb, Modellpflege |
| Laufender Aufwand | Prüfung je Vorgang | einmalig je Datensatz | Wartung, Aktualisierung |
| Braucht weiterhin AVV | ja | in der Regel nein | entfällt |
| Wo es kippt | übersehene Fundstelle | Restrisiko der Re-Identifikation | Modell zu schwach für die Aufgabe |
Was die Entscheidung tatsächlich trägt
Wer formulieren, zusammenfassen oder einordnen lassen will, braucht
Pseudonymisierung. Das Modell muss die Bezüge im Text verstehen, auch wenn
es die Personen nicht kennt. Deshalb sind fallbezogen stabile Platzhalter der
entscheidende Punkt: Wenn dieselbe Person im ganzen Dokument PERSON-A12
heißt, bleibt die Aussage „A12 hat dreimal reklamiert” erhalten. Wer alle
Namen durch dasselbe <PERSON> ersetzt, wie es einfache Maskierungsdienste
tun, zerstört genau diese Information und wundert sich über die schlechtere
Antwort.
Wer auswerten oder Daten weitergeben will, braucht Anonymisierung. Eine Statistik über Reklamationsgründe soll nicht rückrechenbar sein, und eine Zuordnungstabelle wäre hier nicht das Sicherheitsnetz, sondern das Risiko. Der Preis ist Genauigkeit: Wohnort wird zur Region, Datum zum Monat, Betrag zur Klasse. Ein bestandener statistischer Test ist dabei eine Risikobewertung, keine Garantie – wer ihn als „DSGVO-anonym” ausweist, überdehnt ihn.
Ein lokales Modell löst das Datenproblem, aber nicht das Qualitätsproblem. Es ist die naheliegende Antwort und in der Praxis die häufigste Enttäuschung: Was auf dem eigenen Server läuft, liegt bei anspruchsvolleren Aufgaben deutlich hinter den kommerziellen Modellen. Für Klassifikation und Textbausteine reicht es, für die Auswertung eines Vertragswerks meist nicht. Dazu kommen Betrieb und Modellpflege als dauerhafte Aufgabe.
Die Kombination ist der Normalfall
In der Praxis schließen sich die Wege nicht aus. Ein tragfähiges Setup nutzt lokale Modelle für einfache, häufige Aufgaben, ein Gateway mit Pseudonymisierung für die Fälle, in denen Qualität zählt, und Anonymisierung dort, wo Zahlen das Haus verlassen. Die Frage ist nicht, welcher Weg der sicherste ist, sondern welcher zu welchem Vorgang gehört.
Was in keinem Fall trägt
Von Hand schwärzen. Es entfernt zuverlässig das Offensichtliche und übersieht das Rekonstruierbare: die Kombination aus Postleitzahl, Vertragsnummer und Datum, aus der sich dieselbe Person wieder zusammensetzen lässt. Und es skaliert nicht – bei der dritten Rechnung am Tag wird es nachlässig gemacht oder gar nicht.
Vertiefung
- Pseudonymisierung & Anonymisierung – wie die Erkennung technisch aufgebaut ist und wo sie versagt
- Privacy Gateway – ein umgesetztes Beispiel mit gemessener Erkennungsqualität
- DSGVO & KI – Datenklassen, Ampel-Logik, formale Pflichten