Anonymisierung und Maskierung von PII vor dem Senden an KI

Ein Unternehmen verbindet ein KI-System mit einem E-Mail-Postfach. Der Assistent soll Kundenanfragen beantworten, Tickets klassifizieren und Antwortvorschläge machen. Die ersten Tests fallen hervorragend aus. Einige Wochen später fragt jemand: Woher wusstest du eigentlich, dass in diesen E-Mails PESEL-Nummern stehen? Gelangen all diese Daten in die Cloud?

Das ist der Moment, in dem die meisten KI-Implementierungen vor der ersten ernsthaften Frage zum Datenschutz stehen. Es ist keine akademische Frage. Die RODO schreibt die Pflicht zur Datenminimierung vor: An das Modell sollte nur so viel Information gesendet werden, wie für die Aufgabenerfüllung notwendig ist. Der Name des Kunden, die Bestellnummer, die PESEL-Nummer, die IP-Adresse, die E-Mail-Adresse – keine dieser Informationen ist erforderlich, damit das Modell die Absicht einer Anfrage klassifiziert oder eine Antwort vorschlägt. Alle sind PII und sollten durch Token ersetzt werden, noch bevor sie gesendet werden.

PII (Personally Identifiable Information) sind alle Informationen, die eine direkte oder indirekte Identifizierung einer bestimmten Person ermöglichen. Im polnischen Recht regelt die RODO den Umfang und umfasst:

• Vor- und Nachname,
• PESEL-Nummer, NIP, Ausweisnummer,
• E-Mail-Adresse und Telefonnummer,
• Wohnadresse,
• IP-Adresse und Sitzungs-IDs,
• biometrische und medizinische Daten (besondere Kategorie, Art. 9 RODO),
• Datenkombinationen, die zusammen eine Person identifizieren, auch wenn keine einzelne Information dies vermag.

Sprachmodelle „merken“ sich Daten nicht im Sinne einer Datenbank. Sie verarbeiten sie jedoch auf Seiten des Anbieters: Der Text gelangt in die Rechenumgebung des Anbieters, wird tokenisiert, vom Modell verarbeitet und eine Antwort wird zurückgegeben. Je nach Vertrag und Konfiguration können die Daten zur Verbesserung des Modells verwendet oder für eine bestimmte Zeit protokolliert werden. Das reicht aus, damit Juristen und Auditoren nach der Rechtsgrundlage für eine solche Übermittlung fragen.

Die Maskierung von PII vor dem Senden löst dieses Problem an der Wurzel: Das Modell sieht [NAME_1], [EMAIL_1], [PESEL_1] anstelle der echten Werte. Die Klassifizierungs- oder Antwortvorschlagsaufgabe wird erfüllt. Die personenbezogenen Daten haben die Infrastruktur nicht verlassen.

Nicht alle Ansätze sind gleichwertig. Es lohnt sich, drei Begriffe zu unterscheiden, da die rechtlichen und technischen Konsequenzen unterschiedlich sind.

In einem typischen RAG-Flow wird Maskierung eingesetzt: PII wird durch Token ersetzt, die Modellantwort wird mit Token zurückgegeben, und eine lokale Schicht stellt den ursprünglichen Kontext dort wieder her, wo er für Aktionen benötigt wird (z. B. Einfügen des Namens in eine E-Mail-Antwort). Die Token-Wert-Map verlässt niemals Ihren Server.

Eine vollständige Anonymisierung ist schwierig und selten in operativen Flows notwendig. Sie eignet sich für Logging, Reporting und Modelltraining: Ein Datensatz ohne Re-Identifizierungsmöglichkeit unterliegt nicht der RODO und kann beliebig verwendet werden.

Eine Standardimplementierung besteht aus vier lokal arbeitenden Komponenten, bevor irgendeine Netzwerkkommunikation zu einem externen LLM stattfindet.

1. PII-Detektor. Eine Bibliothek oder ein Modell (z. B. spaCy NER, Microsoft Presidio, eigene Regex-Regeln) durchsucht den Text und findet alle Abschnitte, die wie PII aussehen. Für polnische Texte bedeutet dies das Erkennen von PESEL (11-stelliger Muster mit Prüfsumme), NIP (10-stellig), Telefonnummern (9-stellige Sequenzen mit Präfixen), E-Mail-Adressen (Regex RFC 5322) und Eigennamen (NER).

2. Tokenizer. Jede gefundene PII wird durch einen Token ersetzt, wobei Typ und Ordnungsnummer im Dokument beibehalten werden: Jan Kowalski → [PERSON_1], [email protected] → [EMAIL_1], 48123456789 → [TELEFON_1]. Wenn dieselbe E-Mail dreimal vorkommt, erhalten alle drei Vorkommen denselben Token.

3. Umkehr-Map. Die Token-Map ({„[PERSON_1]": „Jan Kowalski"}) wird lokal gespeichert (im Sitzungsspeicher oder einer verschlüsselten Datenbank) und niemals an das Modell gesendet.

4. De-Tokenizer. Nach Rückkehr der Antwort vom Modell setzt die lokale Schicht optional die ursprünglichen Werte dort wieder ein, wo eine Aktion erforderlich ist (z. B. Adressierung der Antwort). Wenn die Antwort in ein Audit-Log geht, bleibt sie mit Token.

In unserer Architektur arbeitet diese Schicht als Middleware im LLM-Router. Jeder Modellaufruf durchläuft sie automatisch, ohne Änderungen an der Anwendung.

Nicht jedes Wort muss maskiert werden. Priorisierung nach Risiko:

Praktische Regel: Wenn Daten an die Inference in einem Cloud-Modell gesendet werden, maskieren Sie mindestens die ersten drei Kategorien bedingungslos. Gesundheits- und biometrische Daten sind eine besondere Kategorie nach RODO (Art. 9) — sie erfordern eine separate DPIA und in vielen Fällen ausschließlich lokale Verarbeitung.

Die Maskierung von PII reduziert das Risiko, eliminiert jedoch nicht alle Vektoren. Für besonders sensible Daten (Mitarbeiterakten, medizinische Daten, Verträge mit Vertraulichkeitsklauseln, Daten von Kindern) ist die richtige Antwort Self-Hosting: Das Sprachmodell und das Embedding-Modell laufen auf Ihrer Hardware, keine Anfragen verlassen Ihr internes Netzwerk.

In unserem Stack übernimmt ein lokaler BGE-M3 die Embedding-Schicht für RAG ohne jeglichen ausgehenden Traffic. Generative Modelle können über Ollama auf lokaler GPU laufen oder über einen LLM-Router mit Fallback-Politik: sensible Modi → lokales Modell, Standardmodi → Cloud mit maskiertem PII.

Diese Lösung hat einen Preis: Lokale Modelle sind weniger fortschrittlich als große Cloud-Modelle. Der Unterschied ist akzeptabel für Klassifizierung, Extraktion und semantische Suche. Er ist deutlicher spürbar für komplexes Reasoning. Die Antwort auf die Frage „Reicht Self-Hosting aus?“ hängt vom Aufgabenumfang ab — ausführlicher behandelt dies der Artikel über Firmen-GPT auf Wissensbasis.

Die Implementierung von KI, die personenbezogene Daten verarbeitet, erfordert mehrere Schritte auf rechtlich-formaler Ebene, unabhängig von der Qualität der technischen Maskierung.

Datenschutz-Folgenabschätzung (DPIA). Wenn die Verarbeitung systematisch, in großem Umfang oder mit besonderen Datenkategorien (Gesundheit, Herkunft, biometrische Daten) erfolgt, ist die DPIA gemäß Art. 35 RODO verpflichtend. Die automatische Verarbeitung von Kundenkorrespondenz mit personenbezogenen Daten fällt in der Regel unter die DPIA.

Verzeichnis der Verarbeitungstätigkeiten. Neue KI-Flows müssen im Verzeichnis erfasst werden: Zweck, Rechtsgrundlage, Datenkategorien, Empfänger, Aufbewahrungsfrist, Sicherheitsmaßnahmen.

AI Act (gilt ab 2025/2026). Systeme, die Personen klassifizieren, Kreditwürdigkeit bewerten oder Entscheidungen treffen, die die Rechte von Einzelpersonen beeinflussen, werden als Hochrisikosysteme eingestuft. Sie erfordern Human-Oversight, technische Dokumentation und Registrierung in der EU-Datenbank. Hilfssysteme (Vorschläge für Berater, die vom Menschen genehmigt werden) haben niedrigere Anforderungen. Detaillierte Anforderungen behandelt der Artikel AI Act und RODO 2026.

Auftragsverarbeitungsvertrag (DPA). Wenn Sie ein Cloud-Modell nutzen, auch mit PII-Maskierung, übertragen Sie formal die Verarbeitung an den Anbieter. Ein DPA mit dem Anbieter ist gemäß RODO Art. 28 erforderlich.

Die Maskierung von PII ist ein notwendiges Fundament, aber keine vollständige Antwort auf die Sicherheit. Drei Bereiche, die separate Lösungen erfordern:

Inference-Angriffe. Selbst anonymisierte Daten können eine Re-Identifizierung ermöglichen, wenn der Kontext ausreichend einzigartig ist. Ein Dokument, das „[PERSON_1], Direktor eines Unternehmens in einer kleinen Stadt in Schlesien mit 12 Mitarbeitern“ beschreibt, kann ohne Namen identifizierbar sein. Milderung: Verallgemeinerung des Kontexts in Logs, Einschränkung der Granularität.

Prompt-Injection. Bösartige Anweisungen, die in Eingabedaten versteckt sind, können versuchen, die Token-Map zu extrahieren oder die Maskierung zu umgehen. Die Lösung sind Guardrails, die vor und nach dem Modell arbeiten, beschrieben im Artikel Sicherheit von KI-Agenten.

Model Memorization. Wenn Ihre Daten in das Training des Anbietermodells einfließen, besteht das Risiko, dass das Modell Fragmente Ihrer Dokumente „auswendig lernt“. Bei hochsensiblen Daten ist der einzige sichere Schutz das Deaktivieren der Trainingsoption (Opt-out im API des Anbieters) oder Self-Hosting. Prüfen Sie die Richtlinien des Anbieters vor der Implementierung.

Fügen Sie einen Textausschnitt mit potenziellen personenbezogenen Daten ein, und das Modell zeigt, wie die PII-Maskierungsschicht Daten identifiziert und tokenisiert, bevor sie an das Modell gesendet werden (Playground: PII lokal maskiert, keine Speicherung):

Die RODO schreibt nicht wörtlich die Maskierung vor, aber Art. 5 Abs. 1 lit. c (Datenminimierung) und Art. 25 (Privacy by Design) verlangen gemeinsam, dass nur die notwendigen Daten verarbeitet werden. Das Senden vollständiger personenbezogener Daten an ein Cloud-Modell, wenn die Aufgabe nur die Klassifizierung der Absicht erfordert, verstößt gegen die Minimierung. Die Maskierung von PII ist die einfachste Technik, um diese Anforderung zu erfüllen. Für besondere Datenkategorien (Gesundheit, Biometrie) ist zusätzlich eine DPIA erforderlich.

Die gängigsten Optionen sind Microsoft Presidio (Open Source, erweiterbar um polnische NER- und Regex-Muster), spaCy mit dem Modell pl_core_news_lg (gute Erkennung von Eigennamen und NER) sowie eigene Regex-Regeln für deterministische Identifikatoren (PESEL, NIP, IBAN-Kontonummer). In der Praxis wird eine Kombination eingesetzt: Regex für Identifikatoren mit bekannten Mustern + NER für Namen und Ortsangaben. Keine dieser Bibliotheken ist perfekt, daher lohnt es sich, nach der Maskierung zufällige Stichproben zu überprüfen.

PDF-Dokumente und Bilder sind schwieriger, da PII in Scans, Logos, Fußzeilen oder handschriftlichen Unterschriften eingebettet sein kann. Die OCR-Schicht (OCR) sollte zunächst den Text extrahieren, und erst danach verarbeitet der PII-Detektor diesen, bevor er an das Modell gesendet wird. Für Dokumente mit sehr hoher Sensibilität (Verträge, medizinische Akten) ist ein selbst gehostetes Vision-Modell, das ohne Zugriff auf das externe Netzwerk arbeitet, sicherer.

Bei gut gestalteter Maskierung ist der Einfluss minimal. Klassifizierung der Absicht, Extraktion von Strukturen, semantische Suche und Antwortgenerierung funktionieren mit Token genauso gut wie mit echten Daten, da das Modell Struktur und Kontext verarbeitet, nicht numerische Werte. Probleme entstehen, wenn die Geschäftslogik Werte erfordert (z. B. Altersberechnung anhand des PESEL) — hier sollte die Maskierung nach der Berechnung angewendet werden, nicht vorher.

Der schnellste Weg ist eine Middleware in der LLM-Router-Schicht: Jeder Modellaufruf durchläuft einen PII-Pre-Prozessor und einen De-Tokenisierungs-Post-Prozessor. Die Anwendung muss nichts von der Maskierung wissen. Die Implementierung einer solchen Schicht dauert in der Regel einige Tage bis Wochen, abhängig von der Komplexität der Flows. Einen Umfang- und Kostenrechner finden Sie im ROI-Rechner. Wenn Sie erst die Möglichkeiten erkunden, beginnen Sie mit der Bereitschaftsbewertung.