Dokumente anonymisieren & schwärzen (DSGVO)

Bevor ein Vertrag, eine Gerichtsakte, eine Personalakte, eine IFG-Auskunft, ein Auskunftsersuchen (DSAR) oder ein Trainingskorpus die Organisation verlassen darf, müssen personenbezogene und vertrauliche Angaben entfernt werden. Das von Hand mit schwarzen Kästen zu tun, ist langsam und fehleranfällig, und schlecht umgesetzte Schwärzung ist eine klassische Ursache für Datenlecks. KI erkennt Namen, Adressen, Kennungen, Gesundheitsdaten und kontextabhängige Identifikatoren, wendet echte (unwiderrufliche) Schwärzung oder konsistente Pseudonyme an und überlässt die endgültige Beurteilung einem menschlichen Prüfer.

Problem & Nutzen

• Heute: Mitarbeitende oder Rechtsassistenten durchsuchen Dokumente per Auge, ziehen Kästen in einem PDF-Werkzeug auf und prüfen erneut per Sichtkontrolle. Typische Anlässe: Antworten auf Informationszugangs- und Auskunftsersuchen (DSAR), Veröffentlichung von Gerichts- und Verwaltungsentscheidungen, Weitergabe von Verträgen an Dritte, Übergabe von Dokumenten an externe KI-Werkzeuge oder Dienstleister, Aufbau von Test-/Trainingsdatensätzen sowie Aufbewahrung und Nachnutzung von Akten für die Forschung.
• KI-Nutzen: gleichbleibend hohe Trefferquote (Recall) über Tausende Seiten, kontextbewusste Erkennung (ein indirekter Identifikator wie „die einzige Finanzchefin des Werks Ansbach" wird von regulären Ausdrücken nicht erfasst), geringerer Prüfaufwand und ein nachvollziehbares Protokoll darüber, was entfernt wurde und warum.
• Wichtige rechtliche Unterscheidung: Anonymisierte Daten fallen nur dann aus der DSGVO heraus, wenn Personen mit Mitteln, die nach allgemeinem Ermessen wahrscheinlich genutzt werden, nicht mehr identifizierbar sind; pseudonymisierte Daten bleiben personenbezogen und erfordern, dass die zusätzlichen Informationen (Schlüssel) getrennt aufbewahrt werden. Die EDSA-Leitlinien 01/2025 formalisieren dies mit dem Konzept einer „Pseudonymisierungsdomäne", innerhalb derer eine Zuordnung verhindert werden muss [2].
• Verlässliche öffentliche Zahlen zur Zeitersparnis werden hier nicht genannt; messen Sie Ihre eigene Ausgangsbasis (siehe Kennzahlen).

Varianten

• Öffentlicher Sektor / Gerichte: Veröffentlichung von Entscheidungen, IFG- und Transparenzportal-Freigaben, Akten für Archive; konsistente Pseudonyme („A.", „B."), damit der Text lesbar bleibt.
• Recht & eDiscovery: Schwärzung von privilegierten Inhalten und personenbezogenen Daten vor der Herausgabe (siehe DOC-021).
• Gesundheitswesen / Forschung: De-Identifizierung von Entlassbriefen und Berichten (siehe DOC-007); Datumsverschiebung und Verallgemeinerung statt Löschung.
• Personal: anonymisierte Bewerbungen und Schwärzung von Personalakten (der spätere Entscheidungsschritt ist ein eigener, möglicherweise hochriskanter Anwendungsfall).
• KI-Hygiene im Unternehmen: Maskierung personenbezogener Daten in Prompts, RAG-Korpora und Protokollen vor LLM-Aufrufen (siehe SEC-017, DOC-014).
• Kundenservice-Transkripte: Schwärzung von Anruf- und Chat-Transkripten (Text-PII auf ASR-Ausgabe).
• Private Nutzung: Schwärzen persönlicher Dokumente, bevor sie veröffentlicht oder an Vermieter, Forum oder Behörde geschickt werden; lokale Werkzeuge bevorzugt (siehe PERS-016).
• Bilder/Video in Dokumenten: Gesichter, Unterschriften, Kfz-Kennzeichen in Scans (Objekterkennung; für Video siehe VIS-030).

So funktioniert es

1. Eingang (PDF / Scan / Office / E-Mail)
2. Text- und Layout-Extraktion (digitale Textebene oder OCR; Begrenzungsrahmen behalten)
3. Erkennung (Regeln/Prüfsummen für IBAN, Steuer-ID, Telefon; NER-Modell; LLM/VLM für kontextuelle und indirekte Identifikatoren; Detektor für Unterschrift/Gesicht/Stempel auf Seitenbildern)
4. Richtlinien-Engine (je Zweck: entfernen / maskieren / verallgemeinern / durch konsistentes Pseudonym ersetzen)
5. menschliche Prüfung (markierte Kandidaten, annehmen/ablehnen, übersehene Stellen ergänzen)
6. echte Schwärzung (darunterliegenden Text, Bilder und Metadaten löschen; Seite rastern oder neu aufbauen)
7. Verifikation (Text aus der Ausgabe erneut extrahieren, Detektoren erneut laufen lassen, Metadaten/Anhänge/OCR-Ebene prüfen)
8. Freigabe + Audit-Protokoll; Schlüsseltresor für die Pseudonym-Zuordnung (falls umkehrbar)

• Erkennungs-Ensemble: Die Trefferquote (Recall) ist wichtiger als die Präzision. Kombinieren Sie deterministische Erkenner (Luhn, IBAN mod-97, Prüfsumme der Steuer-ID), ein NER-Modell und optional einen LLM-Durchlauf für Kontext („mein Nachbar, der in der Bäckerei in der Hauptstraße arbeitet").
• Schwärzung ist ein Dokumententechnik-Problem, nicht nur ein KI-Problem: Ein schwarzes Rechteck über lebendem Text ist keine Schwärzung. Der Ausgabe müssen die ursprüngliche Textebene, versteckte Ebenen, Kommentare, Versionsverlauf, eingebettete Dateien und XMP-/Metadaten fehlen.
• Mensch-in-der-Schleife (Human-in-the-Loop): Stichprobe oder vollständige Prüfung je nach Risiko; verpflichtende Prüfung bei Veröffentlichung und bei besonderen Kategorien personenbezogener Daten (Art. 9 DSGVO).
• LLM-Vorsicht: Senden Sie das ungeschwärzte Dokument nicht an ein externes LLM, nur um die personenbezogenen Daten zu finden; nutzen Sie lokale oder in der EU gehostete Erkennung für die erste Stufe.

Datenaufbereitung

Die zu anonymisierenden Dokumente sind Verträge, Fallakten, Personal- und Patientenakten, Korrespondenz, Tickets und Exporte. Sie liegen typischerweise im DMS, auf Dateiablagen, in Postfächern und als Papierscans. Typische Lücken sind reine Bild-Scans ohne Textebene, gemischte Sprachen, Handschrift, Tabellen und Formulare mit personenbezogenen Daten an unerwarteten Stellen, keine Liste dessen, was als vertraulich gilt, und unklare Zugriffsrechte auf die Quellordner.

Aufbereitungsschritte: - Je Zweck als Regelwerk festlegen, was entfernt werden muss (Namen, IBAN, Gesundheitsdaten, Geschäftsgeheimnisse), siehe PREP-024 und PREP-019. - Scans zuerst per OCR verarbeiten (Tesseract, PaddleOCR, Docling), siehe PREP-006. - 30-50 repräsentative Dokumente auswählen und von Mitarbeitenden die korrekten Schwärzungen markieren lassen; das ist der Testdatensatz für den Recall, siehe PREP-018. - Unternehmensspezifische Begriffe (Kundennamen, Produktcodes) als Sperr- und Positivlisten ergänzen, siehe PREP-015. - Die Rechtsgrundlage für den Schwärzungszweck prüfen, siehe PREP-025.

Grober Aufwandsanteil: etwa 15 Prozent; das Regelwerk und der Testdatensatz sind wichtiger als die Technik. Werkzeuge: Presidio, GLiNER, spaCy. Siehe auch GUIDE-003 und DATA-023.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg C, weil der Inhalt per Definition sensibel ist, Presidio, GLiNER und Docling auf bescheidener Hardware laufen und ein Schwärzungsdienst viele Anwendungsfälle bedienen kann.
• Großunternehmen: Weg C, weil die Schwärzung vor anderen KI-Pipelines sitzt und ein gemeinsamer interner Dienst seitenbasierte Gebühren vermeidet und keine unbearbeiteten personenbezogenen Daten nach außen gibt.
• Entwickler: Weg C, weil quelloffene Detektoren direkt eingebettet und angepasst werden können.
• Öffentlicher Sektor: Weg C, weil Behörden personenbezogene Daten nicht an Cloud-Dienste Dritter senden dürfen und eine nachweisbar unwiderrufliche Schwärzung brauchen.
• Privat: Weg A, weil Desktop-PDF-Werkzeuge mit Schwärzfunktion die gelegentliche Nutzung ohne Einrichtung abdecken.

Weg A — Kaufen (Standardsoftware)

• PDF-/DMS-Werkzeuge: Adobe Acrobat (Schwärzen-Werkzeug, Suchen-und-Entfernen, „Dokument bereinigen") für kleine Volumina; DMS/ECM-Anbieter und eDiscovery-Plattformen (z. B. Relativity Redact) mit KI-gestützter Schwärzung. Viele deutsche DMS-Produkte bieten Schwärzungsmodule; prüfen Sie EU-Hosting und ob unwiderrufliche Entfernung garantiert wird.
• Datenschutz-/DLP-Suiten: Microsoft Purview, Google Sensitive Data Protection (Klassifizierung und De-Identifizierung) sowie spezialisierte Anbieter für PII-Schwärzung (z. B. Private AI, Redactable). Prüfen Sie Datenresidenz, AVV und ob Dokumente für das Modelltraining des Anbieters verwendet werden.
• Weg A wählen, wenn: geringes bis mittleres Volumen, Standarddokumenttypen, keine Integration in die eigene Pipeline nötig. Testen Sie immer mit Ihren eigenen schwierigen Fällen (Scans, Tabellen, Handschrift, deutsche Adressen).

Weg B — Auf Cloud-KI-Diensten aufbauen

• Verwaltete PII-Dienste: Azure AI Language PII-Erkennung (Text, Konversation und native Dokumentschwärzung für PDF/DOCX/TXT mit JSON-Metadaten; EU-Regionen) [3]; Amazon Comprehend PII-Erkennung und -Schwärzung (nur Englisch/Spanisch, daher schwach für Deutsch) [4]; Google Sensitive Data Protection (De-Identifizierungs- Transformationen). Prüfen Sie die Sprachabdeckung je Dienst; die Qualität für Deutsch muss getestet werden.
• OCR mit Geometrie: Mistral OCR (EU-Anbieter; Begrenzungsrahmen pro Block und Konfidenzwerte in aktuellen OCR-Modellen), um Textstellen auf der Seite zu lokalisieren [5]; Azure Document Intelligence, Google Document AI.
• Kontextueller Durchlauf: ein in der EU gehostetes LLM (Mistral, Azure OpenAI/EU-Datenzone, Claude oder Gemini über EU- Regionen) für indirekte Identifikatoren, mit strukturierter Ausgabe (Textstelle, Kategorie, Begründung).
• Orchestrierung: n8n/Power Automate/eigener Dienst; PDF-Schwärzungsbibliothek (PyMuPDF apply_redactions, pikepdf, Apache PDFBox), um Inhalte wirklich zu löschen.
• Weg B wählen, wenn: Sie Pipeline-Integration und gute Qualität für Deutsch brauchen und einen Auftragsverarbeiter unter AVV akzeptieren können.

Weg C — Selbst betreiben (Open Source)

• Erkennung: Microsoft Presidio (Analyzer, Anonymizer, Image Redactor, Modul für strukturierte Daten; spaCy-/Stanza-/ Transformers-Engines; Docker/Kubernetes) [1]; GLiNER Zero-Shot-NER (Apache-2.0, CPU-fähig) einschließlich PII-Varianten wie gliner_multi_pii-v1 [6]; deutsche spaCy-Modelle; feingetuntes NER der BERT-Klasse (text-classifier).
• Parsing/OCR: Docling (MIT, IBM Research, LF AI & Data) [7], PaddleOCR, Tesseract, olmOCR für Scans.
• Kontextueller Durchlauf: LLM/VLM mit offenen Gewichten (Qwen3-Familie, Mistral-Modelle, Gemma) über vLLM oder Ollama.
• Schwärzungs-Engine: PyMuPDF/pikepdf/PDFBox, danach Verifikation durch erneute Extraktion.
• Hardware: HW1 für Pipelines aus Regeln + GLiNER; HW2 (eine GPU mit 24–32 GB) für OCR + ein mittelgroßes LLM; Dokumente verlassen nie das Haus — die stärkste Antwort für Gerichte, Krankenhäuser und Behörden.
• Betriebsaufwand: mäßig; die Hauptarbeit sind die Feinabstimmung der Richtlinie, Evaluierungsdatensätze und der Verifikationsschritt.

Weg D — Eigenes Training

Lohnt sich für domänenspezifische Identifikatoren (klinische Notizen, Gerichtsakten, Text mit deutschen Dialekten/vielen Abkürzungen) oder sehr hohes Volumen. Ein NER-/Encoder-Modell mit einigen Tausend manuell annotierten Seiten feintunen; Korrekturen der Prüfenden aus dem Produktivbetrieb sind die natürlichen Trainingsdaten. Synthetischer Text mit personenbezogenen Angaben (siehe DATA-005) kann den Start erleichtern, aber ein echter zurückgehaltener Testdatensatz ist unerlässlich. Öffentliche Annotationssätze wie die ai4privacy-Sammlungen oder der Text Anonymization Benchmark (Gerichtsentscheidungen) helfen bei der Evaluierung, sind aber nicht auf die deutsche Verwaltung zugeschnitten.

Stand der Technik (2026)

• Mehrstufige Erkennung (Regeln + NER + LLM) ist die Norm; Zero-Shot-Span-Modelle wie GLiNER und kleine LLMs erreichen oder übertreffen inzwischen klassische reguläre Ausdrücke/NER bei unbekannten Entitätstypen, zu den Kosten einer CPU oder einzelnen GPU [6].
• Layout-bewusste Werkzeuge: Moderne Parser liefern Begrenzungsrahmen je Block/Wort, sodass erkannte Textstellen direkt auf Seiten- koordinaten für die Schwärzung abgebildet werden [5][7].
• Indirekte Identifikatoren und Re-Identifizierungsrisiko bleiben der schwierige Teil: Direkte Identifikatoren (Namen, Kennungen) sind einigermaßen gelöst; Quasi-Identifikatoren (seltener Beruf, Ereignis, Ort-Datum-Kombinationen) erfordern Kontext, Risiko- bewertung und oft Verallgemeinerung. Forschungs-Benchmarks zur Textanonymisierung unterscheiden aus diesem Grund direkte von Quasi-Identifikatoren.
• Fehlerbilder: übersehene Namen in Scans schlechter Qualität oder Handschrift; nicht-lateinische oder mit Bindestrich geschriebene Namen; Fehlalarme bei Firmennamen und Personen des öffentlichen Lebens; inkonsistente Pseudonyme über Dokumente hinweg; LLMs, die Textstellen umschreiben statt zu kopieren; Schwärzung, die Text in der Ebene, OCR-Ebene, den Metadaten oder Vorschaubildern zurücklässt.
• Behaupten Sie niemals „anonymisiert" ohne eine Bewertung des Re-Identifizierungsrisikos; automatisierte Schwärzung ist ein Werkzeug zur Risiko- minderung, und ein dokumentierter Prüfschritt entscheidet, ob das Ergebnis anonym oder lediglich pseudonymisiert ist.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (ocr-docparse + text-classifier + llm-general): DOC-014 (Parsing für RAG: vor der Indexierung schwärzen), DOC-003 Formulare, DOC-007 medizinische Akten, DOC-009 Vertragsanalyse; ein OCR-/VLM-Server (HW2/HW3) bedient alle.
• Naheliegende Kombinationen: DOC-021 (eDiscovery und DSAR-Prüfung: Schwärzung als letzter Schritt vor der Herausgabe), SEC-017 (Erkennung sensibler Daten, DLP: finden, wo personenbezogene Daten liegen, dann schwärzen), SEC-018 (DSAR und Verzeichnis von Verarbeitungstätigkeiten), PERS-016 (private Anträge auf Datenschutzrechte), VIS-030 (Verpixeln von Gesichtern und Kennzeichen in Bildern), DATA-005 (synthetische Daten als Alternative zu geschwärzten Daten).
• Gemeinsame Bausteine: guardrails-PII-Filter für LLM-Prompts, ein Schlüsseltresor für Pseudonym-Zuordnungen, eine Prüfoberfläche mit Annehmen/Ablehnen und Audit-Protokoll, ein annotierter Evaluierungsdatensatz je Dokumenttyp.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; Lizenz pro Nutzer oder pro Seite.
• Weg B: 1–3 Monate inkl. Prüfoberfläche, Verifikation und Integration; API-Kosten pro Seite sind meist gering im Vergleich zum Prüfaufwand.
• Weg C: 2–4 Monate; ein GPU-Server oder CPU-Cluster, dazu Pflege von Erkennern und Richtlinie.
• Weg D: +2–3 Monate für Annotation und Training.
• Kennzahlen: Recall direkter Identifikatoren auf einem zurückgehaltenen Datensatz (Ziel nahe 100 % vor menschlicher Prüfung), Präzision, Prüfminuten pro 100 Seiten, Anteil der Dokumente mit manueller Nachbesserung, bei Audits nach der Freigabe gefundene Leckvorfälle, Quote verbliebenen Texts in der Verifikation (sollte 0 sein), Durchlaufzeit von DSAR-/IFG-Anfragen.

Menschen & Veränderung

Beziehen Sie zuerst die Geschäftsleitung und die/den Datenschutzbeauftragte(n) ein: Anonymisierung ist eine DSGVO-Maßnahme, aber das Werkzeug selbst verarbeitet personenbezogene Daten, daher sind Rechtsgrundlage, AVV für jeden externen Auftragsverarbeiter und gegebenenfalls eine DSFA zu klären. IT und IT-Sicherheit richten den Dienst und das Audit-Protokoll ein; Abteilungsleitungen und Endanwender (Recht, Personal, Registratur, Kommunikation) legen fest, was entfernt werden muss, und prüfen die Ergebnisse.

Betriebsrat: meist nein, weil das Werkzeug auf Dokumenten arbeitet, nicht auf dem Verhalten von Beschäftigten. Es hängt davon ab, ob das Audit-Protokoll personenbezogen ausgewertet wird oder Personalakten massenhaft verarbeitet werden; dann greift § 87 Abs. 1 Nr. 6 BetrVG, da das BAG die objektive Eignung zur Überwachung als ausreichend ansieht, und § 90 Abs. 1 Nr. 3 verlangt rechtzeitige Information. In Behörden wird der Personalrat beteiligt.

Fördern Sie die KI-Kompetenz (Art. 4 KI-Verordnung): Mitarbeitende müssen wissen, dass die Erkennung probabilistisch ist, dass der Recall nie 100 Prozent beträgt und dass jedes zur Veröffentlichung bestimmte Dokument eine menschliche Prüfung braucht, bei Freigaben mit hohem Risiko idealerweise im Vier-Augen-Prinzip. Starten Sie mit einem Team und einem Dokumenttyp als Pilot, messen Sie übersehene Stellen und veröffentlichen Sie das Regelwerk. Typische Sorge: trügerische Sicherheit. Begegnen Sie ihr, indem Sie Recall-Zahlen zeigen, die Prüfenden die Kontrolle behalten lassen und nie automatisch veröffentlichen. Leitfäden: GUIDE-005, GUIDE-006, GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko (ein Datenschutzwerkzeug, nicht in Anhang III; die Pflicht zur KI-Kompetenz nach Art. 4 gilt); keine Praxis nach Art. 5 [8]. Wird nur dann Teil eines Hochrisiko-Kontexts, wenn es z. B. in Entscheidungssysteme von Gerichten oder der Personalabteilung eingebettet ist; der Schwärzungsschritt selbst macht sie nicht dazu.
• DSGVO: Die Verarbeitung zum Zweck der Schwärzung ist selbst eine Verarbeitung personenbezogener Daten (Art. 6, und Art. 9 für besondere Kategorien); Datenminimierung (Art. 5 Abs. 1 Buchst. c) und Datenschutz durch Technikgestaltung (Art. 25) stützen den Anwendungsfall. Anonymisierung erfordert, dass eine Identifizierung nach allgemeinem Ermessen nicht wahrscheinlich ist; Pseudonymisierung nimmt Daten nicht aus dem Anwendungsbereich der DSGVO [2]. Die EuGH-Rechtsprechung (EDSB/SRB, C-413/23 P, 2025) betont, dass die Identifizierbarkeit von den Mitteln des Empfängers abhängen kann — prüfen Sie den Urteilstext, bevor Sie sich darauf stützen.
• Sektorregeln: IFG-Gesetze und Regeln zur Veröffentlichung von Gerichtsentscheidungen; ärztliche Schweigepflicht (§ 203 StGB) und Regeln zu Patientendaten; Geschäftsgeheimnisse (GeschGehG); GoBD und Aufbewahrungspflichten stehen im Konflikt mit Löschung — das Original in einem zugriffsbeschränkten Archiv halten und nur die geschwärzte Kopie freigeben.
• Risiken und Gegenmaßnahmen: übersehene Identifikatoren (Recall-Ziel, doppelte Prüfung bei Veröffentlichung); Scheinschwärzung (Seite neu aufbauen, Ausgabetext verifizieren, Metadaten entfernen); Datenabfluss über LLMs (lokale/EU-Erkennung, AVV, kein Training mit Eingaben); Re-Identifizierung durch Verknüpfung (verallgemeinern, Risikobewertung, eingeschränkte Freigabe); Kompromittierung des Pseudonym-Schlüssels (separater Tresor, Zugriffskontrolle, Schlüssel je Domäne).

Erste Schritte

1. Zwecke und Empfänger festlegen (Veröffentlichung, Dritte, interne KI-Nutzung) und je Zweck eine Entitätsrichtlinie schreiben.
2. 100–200 repräsentative Seiten inkl. Scans zusammenstellen und die Referenzwerte (Ground Truth) annotieren; Recall/Präzision für eine Basislösung (Presidio oder Azure PII) und für eine GLiNER-/LLM-Variante berechnen.
3. Die Schwärzungsausgabe korrekt aufbauen (Textebene löschen, Metadaten entfernen) und einen automatisierten Verifikationsschritt ergänzen, der Text aus dem Ergebnis erneut extrahiert.
4. Eine Prüfoberfläche mit Konfidenzschwellen, Stichproben und Audit-Protokoll ergänzen; im Schattenbetrieb neben dem manuellen Prozess laufen lassen.
5. Die Entscheidung Anonymisierung vs. Pseudonymisierung, die DSFA (falls nötig) und das Schlüsselmanagement dokumentieren.

Quellen

1. Microsoft Presidio documentation (analyzer, anonymizer, image redactor, deployment) - https://presidio.dataprivacystack.org/ (accessed 2026-10)
2. EDPB, Guidelines 01/2025 on Pseudonymisation (pseudonymisation domain; public consultation Jan-Mar 2025) - https://www.edpb.europa.eu/system/files/2025-01/edpb_guidelines_202501_pseudonymisation_en.pdf and https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation_en (accessed 2026-10)
3. Microsoft Learn, Azure Language PII detection overview (text, conversation, native-document PII) - https://learn.microsoft.com/en-us/azure/ai-services/language-service/personally-identifiable-information/overview (accessed 2026-10)
4. AWS, Amazon Comprehend: Detecting PII entities (English/Spanish) - https://docs.aws.amazon.com/comprehend/latest/dg/how-pii.html (accessed 2026-10)
5. Mistral AI docs, Document AI / OCR (mistral-ocr-latest, block bounding boxes, confidence scores) - https://docs.mistral.ai/capabilities/document_ai/basic_ocr/ (accessed 2026-10)
6. GLiNER (zero-shot NER, Apache-2.0, PII variants) - https://github.com/urchade/GLiNER (accessed 2026-10)
7. Docling (IBM Research / LF AI & Data, MIT) - https://github.com/docling-project/docling (accessed 2026-10)
8. EU AI Act Article 5, prohibited practices - https://artificialintelligenceact.eu/article/5/ (accessed 2026-10)