Aus der Garage: Kundendaten anonymisieren, bevor die KI sie sieht

Rund 100.000 Support-Tickets, gewachsen über Jahre, voller Wissen, das in keinem Handbuch steht. Genau das Material, aus dem ein gutes KI-Wissenssystem wird. Und voller Namen, E-Mail-Adressen, IBANs, Kundennummern. Wir wollten das eine ohne das andere. Also haben wir eine Regel gebaut: Keine personenbezogene Zeile verlässt das Haus, bevor sie geschwärzt ist.

Aufgebockt

Für ein Kundenprojekt sollten wir über Jahre gewachsenes Support-Wissen durchsuchbar machen. Rund 100.000 Tickets aus dem CRM, dazu etwa 1.000 neue pro Monat. Ein Sprachmodell kann daraus Antworten bauen, wenn es die passenden Tickets als Kontext bekommt. Das Muster dahinter heißt RAG (Retrieval-Augmented Generation): Das Modell schlägt vor dem Antworten in einer Wissensbasis nach, statt frei zu raten.

Der Haken steckt im Rohstoff. Support-Tickets sind ein Minenfeld an personenbezogenen Daten. Namen, Adressen, Telefonnummern, IBANs, Kundennummern, Anlagen-IDs, alles quer durch den Fließtext verstreut. Dazu kommt der Zielort: Das System, in dem die aufbereiteten Tickets landen sollten, läuft auf einer US-Plattform. Für uns eine klare Linie. Dorthin darf kein Rohdatensatz. Personenbezogene Daten bleiben auf EU-kontrollierter Infrastruktur, ohne Ausnahme.

Wo’s klemmt

Der naive Weg wäre, alles zu exportieren und hinterher zu schwärzen. Das ist die falsche Reihenfolge. Wer erst kopiert und dann bereinigt, hat die Rohdaten schon dupliziert, bevor der erste Name fällt.

Der zweite Reflex: “Such nach Mustern und ersetze sie.” Für E-Mail-Adressen und IBANs geht das auf, die folgen einem festen Muster. Bei Namen bricht es. “Müller” und “Tisch” sehen für einen Mustervergleich gleich aus, der eine ist ein Nachname, der andere ein Möbelstück. Ein Name folgt keiner Regel. Man braucht ein Modell, das aus dem Kontext erkennt, dass an dieser Stelle eine Person steht.

Der übliche Werkzeugkasten dafür ist Presidio, ein Open-Source-Framework zur Erkennung personenbezogener Daten, mit spaCy als Sprachmodell darunter. Genau da stand die erste Wand. Das Standardmodell von spaCy für Deutsch ist bei Namen und besonders bei Firmennamen schwach. Es überliest ausgerechnet die Entitäten, die im Support-Alltag ständig auftauchen. Der Standardpfad hätte uns eine Pipeline gebaut, die auf dem Papier funktioniert und in der Praxis Namen durchwinkt.

Der Dreh

Die tragende Einsicht: Schwärzen ist Schichtarbeit, keine einzelne Klinge. Vier Verteidigungslinien, jede fängt, was die vorige durchlässt.

• Feld-Whitelist. Aus dem CRM ziehen wir nur Betreff, Inhalt, Status, Datum, Kategorie. Kontakt-, Telefon- und Adressfelder fragen wir gar nicht erst ab. Was nie ins System kommt, kann nicht lecken.
• Regex fürs Strukturierte. E-Mail, Telefon, IBAN, Kunden- und Bestellnummern folgen festen Mustern und lassen sich zuverlässig sowie sprachunabhängig greifen. Hier hängen wir auch eigene Muster für die kundenspezifischen IDs ein.
• Ein gelerntes Modell fürs Unstrukturierte. Für Namen, Firmen und Orte im Freitext nehmen wir GLiNER, ein NER-Modell (Named Entity Recognition, die Erkennung benannter Entitäten aus dem Kontext). Zero-shot, mehrsprachig, bei deutschen Namen deutlich treffsicherer als das spaCy-Standardmodell. spaCy bleibt drin, aber nur noch für die Tokenisierung. Die eigentliche Erkennung macht GLiNER.
• Ersetzen statt merken. Der Anonymizer tauscht jede erkannte Stelle gegen einen Platzhalter, <PERSON>, <MAIL>. Und hier die bewusste Entscheidung: anonymisieren, nicht pseudonymisieren. Wir speichern keine Zuordnungstabelle, die den Klarnamen zurückholt. Verarbeitung nur im Arbeitsspeicher, geschrieben wird ausschließlich der bereinigte Text. Kein Rohdatensatz ins Log, keiner in den Speicher. Reversibilität ist ein Feature, das wir bewusst nicht wollen, weil es genau das Risiko zurückholt, das wir loswerden wollten.

Was hält

Getestet haben wir an einer Kalibrierung statt am großen Berg: rund 170 Tickets in zwei Paketen, von Hand nachgelesen. Ergebnis: null harte Lecks bei E-Mail, IBAN, Telefon und Adresse. Die Schwärzdichte lag bei knapp hundert geschwärzten Stellen pro 1.000 Wörter. Das ist der Beleg, dass die Maschine arbeitet.

Ehrlich bleibt die Kehrseite, und sie sitzt genau da, wo wir sie erwartet haben: bei den Namen. Eine Handvoll Vornamen pro rund achtzig Tickets rutschte durch, meist aus dem Fließtext. Ein Beispiel, das viel über die Arbeit erzählt: “für Herrn X” wurde nicht geschwärzt, weil unser Anrede-Muster “Herr” kannte, aber nicht den Dativ “Herrn”. Eine einzige fehlende Beugungsform. Umgekehrt schwärzte das Modell zu viel, etwa Gerätemodelle, die wie ein Kürzel aussehen (Typen der Bauart “GW…T”), hielt es für personenbezogen. Beides zeigt dasselbe. Diese Pipeline ist nichts, was man einmal scharf stellt und vergisst. Sie will kalibriert werden, an echten Daten, mit Augen davor.

Die Handreichung, falls ihr vor derselben Aufgabe steht:

• Erst filtern, dann ziehen. Die stärkste Schwärzung ist das Feld, das ihr nie abfragt.
• Regex fürs Strukturierte, ein gelerntes Modell fürs Unstrukturierte. Für Deutsch verlasst euch nicht auf das Standard-spaCy-Modell.
• Braucht ihr Reversibilität nicht zwingend, dann anonymisiert, statt zu pseudonymisieren. Keine Mapping-Tabelle heißt kein zweites Leck.
• Macht den Check zum Gate. Was nicht sauber ist, wird nicht abgelegt.
• Kalibriert an einem kleinen Paket und lest es mit der Hand nach, bevor ihr die volle Menge fahrt. Ein Leck nach 100.000 Tickets bedeutet, alles neu zu fahren.

Der Reflex bei KI-Projekten ist, erst die Daten reinzukippen und den Datenschutz später zu klären. Wir haben es umgekehrt gemacht und zuerst die Schwärzung gebaut. Das kostet eine Kalibrierungsrunde und den ehrlichen Blick auf die Namen, die GLiNER verpasst. Dieser Preis ist kleiner als der eine Rohdatensatz, der bei einem US-Dienst landet und dort nicht mehr einzufangen ist.