Aufbau einer GDPR-konformen KI für den Kundenservice: Entfernen von PII UND benutzerdefinierten Identifikatoren vor der Übermittlung an KI-Anbieter
Ihr Kundenserviceteam nutzt einen KI-Assistenten, um Antworten zu entwerfen, die Ticket-Historie zusammenzufassen und Lösungen vorzuschlagen. Die KI ist gut. Die Produktivität ist gestiegen. Dann überprüft Ihr DSB die Implementierung.
In die KI-Oberfläche eingefügte Kundenmitteilungen enthalten:
- Kundenname: "Hallo, ich bin Sarah Johnson und meine Bestellung..."
- E-Mail-Adresse: "Bitte senden Sie mir eine E-Mail an sarah.j@gmail.com"
- Bestell-ID: "ORD-4521893 ist noch nicht angekommen"
Der Name und die E-Mail sind personenbezogene Daten. Die Bestell-ID ist ebenfalls personenbezogen – sie ist mit Sarah Johnson in Ihrem Bestellverwaltungssystem verknüpft, auf das der KI-Anbieter zugreifen kann, wenn er Daten für mehrere Kunden verarbeitet, oder sie schafft ein Risiko der Wiederidentifizierung, wenn die KI-Trainingsdaten jemals offengelegt werden.
Sie senden personenbezogene Daten an einen externen KI-Anbieter ohne eine gültige rechtliche Grundlage oder angemessene Sicherheitsvorkehrungen. Dies ist ein Verstoß gegen die GDPR.
Warum Bestell-IDs personenbezogene Daten sind
Die Definition personenbezogener Daten in der GDPR ist absichtlich weit gefasst: "alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen." Eine Person ist identifizierbar, wenn sie "direkt oder indirekt, insbesondere durch Bezugnahme auf einen Identifikator, identifiziert werden kann."
Eine Bestell-ID (ORD-4521893) ist ein indirekter Identifikator. Allein identifiziert sie Sarah Johnson nicht. Aber in Kombination mit Ihrer Bestellverwaltungsdatenbank – auf die der KI-Anbieter möglicherweise Zugriff hat oder nicht – identifiziert sie sie mit Sicherheit.
Das Pseudonymisierungskonzept des GDPR-Artikels 4(5) findet hier Anwendung: Bestell-IDs sind Pseudonyme, die zusätzliche Informationen (die Bestelldatenbank) für die Wiederidentifizierung erfordern. Wenn die Organisation, die den Pseudonymschlüssel kontrolliert (Sie, der Datenverantwortliche), dieses Pseudonym an einen externen KI-Anbieter sendet, teilen Sie pseudonyme Daten, die möglicherweise wieder identifizierbar sind.
Die rechtliche Analyse: Pseudonyme Daten, die an einen Dritten gesendet werden, der nicht über den Schlüssel verfügt, sind vor der Wiederidentifizierung durch diesen Dritten geschützt – aber Sie haben dennoch personenbezogene Daten geteilt, die eine rechtliche Grundlage und eine DPA-Vereinbarung erfordern.
Die Standard-Anonymisierungs-Lücke
Support-Teams, die die GDPR-Compliance für ihre KI-Tools umsetzen, setzen häufig Standard-PII-Erkennung ein:
Was entfernt wird:
- Kundennamen (PERSON-Entity-Erkennung) ✓
- E-Mail-Adressen (EMAIL_ADDRESS-Erkennung) ✓
- Telefonnummern (PHONE_NUMBER-Erkennung) ✓
- Kreditkartennummern (CREDIT_CARD-Erkennung) ✓
Was bleibt:
- Bestell-IDs (ORD-XXXXXXX-Format – nicht in der Standard-Entity-Bibliothek) ✗
- Kontonummern (ACC-XXXXXXXX-XX-Format) ✗
- Ticketreferenznummern (TKT-XXXXX-Format) ✗
- Interne Benutzer-IDs (UUID oder benutzerdefiniertes Format) ✗
- Abonnement-IDs (SUB-XXXXXXXX-Format) ✗
Die anonymisierte Nachricht sieht so aus: "Hallo, ich bin [PERSON_1] und meine Bestellung ORD-4521893 ist noch nicht angekommen. Bitte senden Sie mir eine E-Mail an [EMAIL_1]."
Die Bestell-ID bleibt. Jeder, der weiß, dass es sich um ORD-4521893 handelt (was buchstäblich jeder in Ihrer Organisation mit CRM-Zugriff ist), kann sofort den Kunden identifizieren, auf den sich diese Nachricht bezieht. Die Anonymisierung ist unvollständig.
Chrome-Erweiterung: Echtzeit-Erkennung benutzerdefinierter Identifikatoren
Für Supportmitarbeiter, die webbasierte KI-Tools (Claude, ChatGPT, Gemini) direkt in ihrem Browser verwenden, bietet die Chrome-Erweiterung eine Echtzeit-Anonymisierung an der Eingabestelle:
- Der Supportmitarbeiter kopiert die Kundenmitteilung in die Zwischenablage oder tippt sie in die KI-Oberfläche ein
- Die Chrome-Erweiterung erkennt, dass das Ziel eine KI-Plattform ist
- Standard-PII wird automatisch erkannt und ersetzt
- Benutzerdefinierte Entity-Muster (Bestell-IDs, Kontonummern in Ihrem spezifischen Format) werden mithilfe der gespeicherten Teamkonfiguration erkannt
- Der Mitarbeiter sieht die anonymisierte Nachricht in der KI-Oberfläche – niemals die ursprünglichen PII
Die benutzerdefinierte Entity-Konfiguration (ORD-XXXXXXX-Muster) wird einmal vom DSB oder Compliance-Team festgelegt und auf alle Teammitglieder angewendet, die die Erweiterung verwenden. Einzelne Mitarbeiter müssen die technischen Einzelheiten dessen, was anonymisiert wird, nicht kennen – sie fügen die Nachricht ein, sie ist sauber.
MCP-Server: API-Ebene Erkennung für integrierte Tools
Für Kundenservice-Plattformen, die KI über API-Integrationen (Intercom mit KI-Antworten, Zendesk mit KI-Entwürfen) verwenden, bietet der MCP-Server Middleware-Anonymisierung:
Integrationsfluss:
- Kundenmitteilung wird in der Support-Plattform empfangen
- Bevor sie an das KI-Modell weitergeleitet wird: Nachricht wird über den MCP-Anonymisierungsendpunkt geleitet
- Anonymisierung wird angewendet (Standard + benutzerdefinierte Entities)
- Anonymisierte Nachricht wird an das KI-Modell gesendet
- KI-Antwort wird generiert (keine PII-Exposition)
- Antwort wird an die Support-Plattform zurückgegeben, der Mitarbeiter überprüft und bearbeitet
Diese Integration ist für die Supportmitarbeiter transparent – der Workflow bleibt unverändert. Die Anonymisierung erfolgt auf der API-Ebene, ohne dass eine Aktion des Mitarbeiters erforderlich ist.
Connector-Konfiguration: Definieren Sie benutzerdefinierte Entities einmal in der MCP-Konfiguration. Alle API-Aufrufe über den MCP wenden automatisch die vollständige Entity-Erkennung einschließlich benutzerdefinierter Muster an.
DSB-Implementierungscheckliste
Für den DSB, der die Implementierung der KI-unterstützten Kundenbetreuung überprüft:
1. Inventarisieren Sie alle Daten, die an die KI fließen:
- Direkte Einfügung/Eingabe (browserbasierte KI-Tools)
- API-Aufrufe (KI in die Support-Plattform integriert)
- Dateianhänge (wenn Mitarbeiter Screenshots oder Dokumente hochladen)
2. Identifizieren Sie alle Identifikatortypen in Kundenmitteilungen: Standard-PII: Namen, E-Mails, Telefone (standardmäßig abgedeckt) Benutzerdefinierte Identifikatoren: Bestell-IDs, Kontonummern, Ticketnummern (erfordern benutzerdefinierte Konfiguration)
3. Konfigurieren Sie benutzerdefinierte Entity-Muster: Für jedes benutzerdefinierte Identifikatorformat: Definieren Sie das Muster, testen Sie es mit Beispielnachrichten, speichern Sie es in der Teamvorgabe
4. Implementieren Sie die Anonymisierung auf geeigneten Ebenen: Browserbasierte KI: Chrome-Erweiterung mit Teamvorgabe API-integrierte KI: MCP-Server oder API-Ebenen-Vorverarbeitung
5. Dokumentieren Sie für ROPA: Halten Sie fest, dass die Verarbeitung durch die KI im Kundenservice automatisierte PII-Anonymisierung verwendet, einschließlich der erkannten benutzerdefinierten Identifikatoren. Dies ist die Dokumentation der technischen Sicherheitsvorkehrung.
6. Validieren Sie mit Testszenarien: Senden Sie Testnachrichten, die alle Identifikatortypen enthalten, durch die implementierte Anonymisierung. Überprüfen Sie, ob alle Identifikatoren entfernt wurden, bevor sie das KI-Modell erreichen.
Beispiel aus der Praxis: SaaS-Kundenservice
Das Kundenserviceteam eines SaaS-Unternehmens verwendet Claude (über ihre interne KI-Plattform), um Supportantworten zu entwerfen. Kundenmitteilungen enthalten:
- Kundennamen und E-Mails
- Bestell-IDs (ORD-XXXXXXX-Format)
- Abonnement-IDs (SUB-XXXXXXXX-Format)
- Funktionsflag-Namen (enthalten manchmal interne Kundenidentifikatoren)
Vor der GDPR-Überprüfung: Alle Nachrichteninhalte wurden direkt an das KI-Modell gesendet, einschließlich Bestell- und Abonnement-IDs.
Nach der Implementierung der benutzerdefinierten Entity-Erkennung:
- ORD-XXXXXXX und SUB-XXXXXXXX-Muster wurden als benutzerdefinierte Entities konfiguriert
- Chrome-Erweiterung wurde dem Support-Team mit gemeinsamer Vorgabe bereitgestellt
- DSB hat verifiziert: Testnachrichten durch das System zeigen, dass alle Identifikatoren entfernt wurden
Änderung des Support-Workflows: Null. Mitarbeiter fügen Nachrichten wie zuvor ein. Die Anonymisierung ist für sie unsichtbar. Der DSB hat die Dokumentation der technischen Sicherheitsvorkehrung.
Fazit
Eine GDPR-konforme KI für den Kundenservice erfordert mehr als das Entfernen von Namen und E-Mails. Bestell-IDs, Kontonummern und Ticketreferenzen sind personenbezogene Daten, die von Standard-PII-Tools übersehen werden. Die Compliance-Lücke zwischen "wir anonymisieren PII vor der KI" und "wir anonymisieren tatsächlich alle Identifikatoren" wird mit der Konfiguration benutzerdefinierter Entities geschlossen.
Die Lösung ist nicht komplex: Definieren Sie die Identifikatorformate Ihrer Organisation, testen Sie sie mit Beispielnachrichten, setzen Sie sie im Team um. Der DSB kann dies an einem Nachmittag konfigurieren. Der fortlaufende Compliance-Vorteil – alle Kunden-PII werden vor der externen KI-Verarbeitung entfernt – ist dauerhaft.
Quellen: