So darf eine KI mit deinen Kundendaten arbeiten, ohne die DSGVO zu brechen

Das klingt harmlos, bis der Datenschutz fragt

„Frag einfach dein CRM" ist eine der besten Demos, die man einem Betrieb zeigen kann. Du tippst „welche Kunden aus Husum haben seit März nichts mehr bestellt" und bekommst eine saubere Liste. Alle nicken, alle wollen das haben.

Das Problem steckt nicht im Chat, sondern in dem, was dabei passiert. Sobald Namen, Adressen, Telefonnummern, Rechnungsbeträge oder gar Gesundheits- und Personaldaten an ein Cloud-Modell gehen, ist das eine Verarbeitung personenbezogener Daten. Dann brauchst du eine Rechtsgrundlage, einen Auftragsverarbeitungsvertrag mit dem Anbieter, und bei vielen Anbietern landet die Anfrage in einem Drittland. Der schöne Chat ist der einfache Teil. Ihn so zu bauen, dass du ihn einem Kunden verantwortbar hinstellen kannst, ist der eigentliche Teil.

Der erste Reflex ist meistens der falsche

Die häufigste Antwort darauf ist: dann betreiben wir das Modell eben lokal, dann verlässt nichts das Haus. Das ist legitim, ich habe selbst darüber geschrieben, wann sich lokale Modelle lohnen. Aber lokal ist teurer, oft schwächer und löst gar nicht die Frage, um die es hier geht.

Denn die Frage ist nicht wo das Modell läuft, sondern was es zu sehen bekommt. Auch ein lokales Modell will man nicht ungefiltert mit Klarnamen und Kontonummern füttern, sobald Logs, Backups oder ein zweiter Dienst ins Spiel kommen. Wer beim Hosting stehenbleibt, hat den falschen Hebel angefasst.

Maskieren, bevor das Modell etwas sieht

Der richtige Hebel heißt Pseudonymisierung. Die DSGVO meint damit, personenbezogene Daten so zu verarbeiten, dass sie ohne eine separat aufbewahrte Zuordnung keiner Person mehr zugeordnet werden können (Art. 4 Nr. 5). Übersetzt für den Betrieb: zwischen deine Daten und das Modell gehört eine kleine Schleuse, die echte Werte durch Platzhalter ersetzt. Genau so eine Schleuse baue ich gerade in ein lokales CRM ein, und sie hat drei Schichten.

• Harte Muster per Regex. IBAN, E-Mail, Telefonnummer, Steuer- und Kundennummer haben ein festes Format. Die fängst du mit Mustererkennung ab, eindeutig, schnell, kostet nichts. Das ist die Schicht, mit der du anfängst.
• Namen und Orte per Erkennungs-Tool. Personennamen, Adressen, Firmen erkennt man nicht über ein festes Muster, sondern über den Kontext. Dafür gibt es fertige offene Werkzeuge. Microsoft Presidio zum Beispiel macht genau das, frei und unter MIT-Lizenz, und nutzt dafür sprachliche Modelle statt nur Regex.
• Reversible Tokenisierung. Jeder echte Wert wird gegen einen Platzhalter getauscht, die Zuordnungstabelle bleibt lokal und getrennt liegen. Kommt die Antwort vom Modell zurück, setzt die Schleuse die echten Werte wieder ein. Das Modell hat nie einen Klarnamen gesehen, du arbeitest trotzdem mit den richtigen Daten weiter.

Was wirklich am Modell ankommt

An einem Satz wird der Unterschied am schnellsten klar. Aus einer CRM-Notiz wird auf dem Weg zum Modell das hier:

Das Modell formuliert seine Antwort mit den Platzhaltern, beim Zurückspielen werden sie wieder aufgelöst. Selbst wenn die Anfrage durch ein Cloud-Modell in einem Drittland läuft, hat dieser Dienst nie einen echten Namen, eine echte Adresse oder eine echte Belegnummer verarbeitet. Genau das ist der Punkt, an dem aus „Chat mit dem CRM" etwas wird, das man einem Kunden hinstellen kann.

Wo es nicht reicht, ehrlich gesagt

Die Schleuse ist kein Freifahrtschein, und es wäre unseriös, sie als einen zu verkaufen.

• Die Erkennung ist nicht perfekt. Presidio schreibt das selbst in die Doku: Es gibt keine Garantie, dass jede sensible Stelle gefunden wird. Freitext-Notizen, Tippfehler, ungewöhnliche Namen rutschen durch. Du brauchst Stichproben und musst mit Restfehlern rechnen.
• Pseudonymisierung ist keine Anonymisierung. Solange die Zuordnungstabelle existiert, bleiben die Daten personenbezogen. Der Auftragsverarbeitungsvertrag mit dem Modellanbieter wird dadurch nicht überflüssig. Der Aufwand und das Risiko sinken aber deutlich, weil das echte Material das Haus nicht verlässt.
• Kontext verrät auch ohne Namen. „Der Bäcker im 800-Seelen-Dorf, der letzte Woche gekündigt hat" braucht keinen Klarnamen, um eindeutig zu sein. Gegen Re-Identifikation über den Kontext hilft keine Mustererkennung, nur Zurückhaltung bei dem, was du überhaupt in die Anfrage packst.

Ich weiß noch nicht, ob jeder Betrieb alle drei Schichten braucht. Wer nur strukturierte Stammdaten abfragt, kommt oft mit Regex und getrennter Zuordnung weit. Sobald aber Freitext im Spiel ist, Notizen, Mails, Gesprächsprotokolle, reicht die Mustererkennung allein nicht mehr, dann gehört die zweite Schicht dazu.

Fazit

Wenn du eine KI auf deine Kundendaten lassen willst, ist die wichtigste Komponente nicht das Modell und nicht der Chat, sondern die Schleuse davor. Fang klein an: Mustererkennung für die eindeutigen Felder, eine getrennt liegende Zuordnungstabelle, ein sauberer Auftragsverarbeitungsvertrag. Die Namens- und Orterkennung baust du dazu, sobald Freitext mitspielt. Und versprich niemandem hundert Prozent, auch dir selbst nicht. Wer die Schleuse überspringt, baut eine hübsche Demo, die er keinem Kunden verantwortbar hinstellen kann. Wer sie baut, hat den Teil gelöst, an dem die meisten KI-Projekte im Mittelstand hängenbleiben.

Quellen: DSGVO Art. 4 Nr. 5 (Pseudonymisierung) und Art. 32 (Sicherheit der Verarbeitung). Werkzeug: Microsoft Presidio (offen, MIT-Lizenz). Eigene Erfahrung aus dem Bau einer solchen Schleuse für ein lokales CRM, Juni 2026.