Katalog / Aufbereitung von Daten und Wissen / PREP-022

Pseudonymisierung von Datensätzen und Exporten vor dem KI-Einsatz

Namen, E-Mail-Adressen, IDs und andere personenbezogene Daten in CRM-Exporten, Tickets, E-Mails und Tabellen werden vor der Weitergabe an ein KI-Werkzeug durch einheitliche Platzhalter ersetzt, sodass Mitarbeitende KI mit echten Daten und deutlich geringerem Risiko nutzen können.

Schneller Erfolg: bewährt, überschaubarer Aufwand, erste Ergebnisse nach Wochen, geringes regulatorisches Risiko.

Bausteine für den EigenbetriebAgenten & AutomatisierungSprachmodell

Jemand exportiert 5.000 Support-Tickets oder eine Kundenliste, fügt sie in ein KI-Werkzeug ein, und personenbezogene Daten verlassen das Unternehmen ohne Rechtsgrundlage, Vertrag oder Löschkonzept. Ein kleiner Vorverarbeitungsschritt findet Namen, E-Mail-Adressen, Telefonnummern, IBANs und Kundennummern, ersetzt sie durch einheitliche Platzhalter und behält die Zuordnungstabelle im eigenen Haus. Die KI sieht „PERSON_017 hat sich zweimal über Rechnung INV_204 beschwert“, die Analystin oder der Analyst kann trotzdem damit arbeiten, und das Ergebnis lässt sich intern zurückführen.

Problem & Nutzen

  • Heute: Mitarbeitende fügen Rohdaten-Exporte in Chatbots ein (Schatten-KI) oder verzichten auf KI, weil die oder der Datenschutzbeauftragte sagt: „keine personenbezogenen Daten“.
  • KI-Nutzen: Einheitliche Platzhalter erhalten Zusammenhänge (gleicher Kunde, gleiches Token), anders als beim Löschen.
  • Ehrlich zur Rechtswirkung: Pseudonymisierte Daten sind nach Art. 4 Nr. 5 DSGVO weiterhin personenbezogene Daten, solange die Zuordnung existiert. Das senkt das Risiko und unterstützt die Datenminimierung (Art. 5 Abs. 1 lit. c, Art. 25), ersetzt aber weder eine Rechtsgrundlage noch einen AVV, wenn ein Auftragsverarbeiter beteiligt ist [1][2].
  • Kein automatischer Detektor findet 100 % der personenbezogenen Daten; die Dokumentation von Presidio sagt das selbst [3]. Planen Sie stichprobenartige Prüfungen durch Menschen ein.

Varianten

  • Tickets/E-Mails: Freitext, der schwierigste Fall. Tabellarische Exporte: Regeln pro Spalte. Analysedatensätze: verallgemeinern (Altersgruppen, Postleitzahlgebiete). Privat: lokale Werkzeuge, bevor etwas in Chatbots eingefügt wird; siehe DOC-018.

So funktioniert es

  1. export (CSV/XLSX/JSON/text)
  2. classify columns (direct identifier | quasi-identifier | free text | harmless)
  3. detect (regex/checksums for IBAN, phone, e-mail + NER for names, addresses)
  4. replace (consistent tokens via keyed hashing or lookup table)
  5. store mapping separately (restricted access, own retention)
  6. review sample + detection report
  7. release pseudonymised file to the AI tool
  8. map results back (optional, internal only)
  • Erkennung: Regeln für IBAN/Telefon/E-Mail plus NER für Namen und Orte. Ersetzung: Gleiche Eingabe ergibt pro Projekt das gleiche Token; verwenden Sie einen geheimen Schlüssel, keinen ungesalzenen Hash (bei E-Mail-Adressen erratbar).
  • Mensch-in-der-Schleife (Human-in-the-Loop): Prüfen Sie vor der ersten Freigabe eine Stichprobe (z. B. 100 Zeilen) und alle unsicheren Treffer.

Datenaufbereitung

Welche Daten: der Export, den Sie tatsächlich an die KI geben wollen, nicht mehr. Beginnen Sie mit einer Zweckbeschreibung („Beschwerdegründe analysieren“) und wählen Sie nur die benötigten Spalten aus.

Wo sie liegen: CRM-/Ticket-Werkzeuge (HubSpot, Zendesk, Odoo), DATEV-/ERP-Exporte, Postfächer in Microsoft 365 oder Google Workspace, Excel-Dateien auf Netzlaufwerken.

Typische Lücken: Namen in Freitext und Signaturen, zitierte Antwortketten, uneinheitliche Schreibweisen und harmlose Felder, die in Kombination eine Person identifizieren.

Schritte (1-3 Tage für den ersten Datensatz): (1) Bezeichner pro Spalte markieren, mit PREP-003 und PREP-005; (2) pro Spalte entscheiden: löschen, ersetzen, verallgemeinern, behalten; (3) die Erkennung auf 200 Zeilen laufen lassen und deutsche Muster (Telefon, IBAN, Steuer-ID) anpassen; (4) die Zuordnungstabelle getrennt mit eingeschränktem Zugriff speichern; (5) im Verzeichnis der Verarbeitungstätigkeiten (Art. 30) und in den KI-Regeln (PREP-024, PREP-025) dokumentieren.

Werkzeuge: Excel/Power Query, Python mit Microsoft Presidio, n8n oder Power Automate für zeitgesteuerte Läufe, Nextcloud oder SharePoint für den zugriffsbeschränkten Speicher. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

  • KMU — Weg C: Kunden-, Personal- und Geschäftsgeheimnisdaten sind sensibel, und ein einfaches Open-Source-Werkzeug (Presidio plus spaCy) läuft auf einem normalen CPU-Server oder Laptop (HW1). Ein kleiner Dienst bedient zudem mehrere spätere Anwendungsfälle (Ticket-Analyse, RAG, Berichtswesen) und schafft so einen Baukasten-Effekt.
  • Großunternehmen — Weg C: Ein gemeinsamer interner Anonymisierungsdienst vor allen KI-Plattformen lässt sich leichter steuern als viele einzelne Skripte; kommerzielle Datenmaskierungs-Suiten sind eine Alternative, wenn sie bereits lizenziert sind.
  • Entwickler — Weg C: Die Bibliotheken sind Open Source und lassen sich in Pipelines und Testdaten-Abläufe einbetten.

Weg A — Kaufen (Standardsoftware)

Microsoft Purview (Vertraulichkeitsbezeichnungen, DLP) oder Google Cloud Sensitive Data Protection blockieren oder markieren sensible Daten vor allem; zum Erzeugen einheitlicher Token für einen Datensatz sind sie weniger geeignet. Sinnvoll, wenn bereits lizenziert. Prüfen Sie EU-Hosting und AVV (GUIDE-010).

Weg B — Auf Cloud-KI-Diensten aufbauen

Azure AI Language PII-Erkennung, Google Sensitive Data Protection oder AWS Comprehend (EU-Regionen) lassen sich aus n8n oder Power Automate aufrufen. Haken: Die Rohdaten gehen vor dem Schutz in die Cloud, sodass für diesen Schritt AVV und Rechtsgrundlage nötig sind. Für die sensibelsten Daten selten richtig.

Weg C — Selbst betreiben (Open Source)

  • Microsoft Presidio (Analyzer + Anonymizer, REST-API, eigene Erkenner) [3], spaCy- oder Transformer-NER-Modelle mit deutscher Unterstützung, optional Ollama mit einem kleinen Modell (etwa 7-8B) für eine zweite Prüfung.
  • Orchestrierung: n8n selbst betrieben (zum Beispiel in einem EU-Rechenzentrum wie Hetzner oder IONOS) oder ein zeitgesteuerter Python-Job; Dateien in Nextcloud.
  • Hardware: HW1; ein CPU-Server verarbeitet Zehntausende Zeilen pro Stunde ohne GPU.
  • Betriebsaufwand: wenige Stunden pro Monat (Musteraktualisierungen, Stichprobenprüfungen).

Weg D — Eigenes Training

Nur für domänenspezifische Entitäten (Patienten-IDs, Projektcodes): ein kleines NER-Modell mit einigen hundert annotierten Beispielen feintunen (PREP-018).

Stand der Technik (2026)

  • Hybride Pipelines (Regeln plus NER plus optional kleines LLM) sind der praktische Standard; deutscher Freitext und Adressen werden oft schlechter erkannt als englische, testen Sie daher mit Ihren eigenen Daten.
  • Die EDPB-Leitlinien 01/2025 zur Pseudonymisierung (Konsultationsfassung vom Januar 2025 angenommen; prüfen Sie, ob der endgültige Text vorliegt) beschreiben Pseudonymisierung als Schutzmaßnahme, betonen, dass „Pseudonymisierungsgeheimnisse“ (Schlüssel, Zuordnungstabellen) getrennt aufbewahrt und geschützt werden müssen, und dass pseudonymisierte Daten personenbezogen bleiben [2].
  • Grenzen und Fehlerbilder: Übersehene Namen (falsch negative Treffer) sind die eigentliche Gefahr; zu starkes Maskieren (falsch positive Treffer) zerstört den Analysewert; Re-Identifizierung über Kombinationen von Merkmalen; Token-Konsistenz über mehrere Dateien kann selbst eine Verknüpfung ermöglichen; LLM-basierte Schwärzung kann halluzinieren oder Daten preisgeben, wenn sie in der Cloud läuft.

Gemeinsame Bausteine & Kombinationen

Aufwand, Kosten & Kennzahlen

  • Weg A: Tage. Weg B: 1-2 Tage plus API-Kosten und AVV-Arbeit. Weg C: etwa 2-5 Tage bis zu einer abgestimmten Pipeline, danach Stunden pro Monat; eine kleine VM kostet einige zehn Euro pro Monat.
  • Kennzahlen: Recall auf einer manuell gekennzeichneten Stichprobe (Zielwert mit der oder dem Datenschutzbeauftragten vereinbaren, bei direkten Bezeichnern typischerweise über 95 %), Anteil der Datensätze, die die Pipeline durchlaufen, gegenüber roh eingefügten, Zahl der Schatten-KI-Vorfälle, eingesparte Stunden bei manuellem Schwärzen.

Menschen & Veränderung

Früh einbinden: Datenschutzbeauftragte(r) (legt fest, was ausreicht, und gibt frei), IT-Sicherheit (Schlüssel, Zuordnungstabelle), Datenverantwortliche, Abteilungsleitungen.

Betriebsrat: kommt darauf an. Das Werkzeug selbst verarbeitet Kunden- und Ticketdaten, doch Tickets und E-Mails enthalten auch Namen von Beschäftigten und Bearbeitungszeiten; sind Beschäftigtendaten betroffen oder protokolliert die Pipeline, wer was exportiert, kann die Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG greifen (die objektive Eignung zur Überwachung genügt). § 90 Abs. 1 Nr. 3 verlangt eine rechtzeitige Unterrichtung, wenn Arbeitsabläufe mit KI geplant werden. Pseudonymisierung erleichtert meist die Einigung, weil sie auch die Beschäftigten schützt (GUIDE-004). Öffentliche Stellen beteiligen den Personalrat.

Datenschutz: Eine DSFA (Art. 35) ist nur wahrscheinlich, wenn die nachgelagerte KI Personen im großen Umfang bewertet oder besondere Kategorien nutzt; AVV für jedes Cloud-KI-Werkzeug, das die Ausgabe erhält (GUIDE-005).

KI-Kompetenz: Art. 4 KI-Verordnung (AI Act) verlangt Maßnahmen, die die KI-Kompetenz der Beschäftigten fördern; vermitteln Sie, was Pseudonymisierung garantiert und was nicht, und welche Daten niemals roh eingefügt werden dürfen (GUIDE-006, GUIDE-007).

Pilot: Bieten Sie das Werkzeug als einfachen, genehmigten Weg an, nicht als Verbot; pilotieren Sie mit einem Team und 1-2 Datensätzen über vier Wochen (GUIDE-008, GUIDE-009).

Menschen behalten die Kontrolle: Eine Person prüft den Erkennungsbericht vor der ersten Freigabe jedes neuen Datentyps.

Risiken, Regulierung & Compliance

  • KI-Verordnung (AI Act): Der Vorverarbeitungsschritt hat minimales Risiko; der nachgelagerte KI-Anwendungsfall bestimmt die Klasse (in der Fassung der Verordnung (EU) 2026/1744 gelten die Pflichten für Hochrisiko nach Anhang III ab dem 2. Dezember 2027; zum Beispiel können HR-Anwendungsfälle hohes Risiko darstellen) [4]. Siehe GUIDE-014.
  • DSGVO: Pseudonymisierte Daten bleiben personenbezogen; Rechtsgrundlage, Zweckbindung, AVV und Verarbeitungsverzeichnis gelten weiterhin [1][2]. Wirklich anonymisierte Daten fallen nicht unter die DSGVO, sind bei Freitext aber schwer zu erreichen.
  • Sicherheit: Schützen Sie die Zuordnungstabelle wie eine Passwortdatenbank; sichern Sie jeden LLM-Schritt gegen Prompt-Injection ab (GUIDE-013).
  • Gegenmaßnahmen: Stichprobenprüfung, Recall-Tests, Aufbewahrungsfristen für Zuordnungen.

Erste Schritte

  1. Wählen Sie einen konkreten Datensatz (zum Beispiel die Support-Tickets des letzten Jahres) und einen Zweck.
  2. Vereinbaren Sie mit der oder dem Datenschutzbeauftragten, welcher Erkennungs-Recall nötig ist und wer die Zuordnungstabelle verwahren darf.
  3. Installieren Sie Presidio (Docker) auf einem kleinen Server, testen Sie es mit 200 Zeilen und ergänzen Sie deutsche Muster.
  4. Binden Sie die Pipeline in einen n8n-Ablauf oder ein Skript mit Prüfschritt und Erkennungsbericht ein.
  5. Veröffentlichen Sie die Regel „Was darf in welches KI-Werkzeug“ (PREP-024) und verweisen Sie die Mitarbeitenden auf diese Pipeline.

Quellen

  1. Regulation (EU) 2016/679 (GDPR), Art. 4(5), 25, 28, 35 — https://eur-lex.europa.eu/eli/reg/2016/679/oj
  2. EDPB — Guidelines 01/2025 on Pseudonymisation (version for public consultation) — https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation_en
  3. Microsoft Presidio — documentation and source — https://microsoft.github.io/presidio/
  4. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  5. n8n documentation (self-hosting) — https://docs.n8n.io/hosting/