Back to BlogGDPR & Compliance

German PII Detection for DSGVO Compliance

BfDI reported 27,829 breach notifications in 2024 — Germany's all-time record. 65% of German firms use tools with inadequate German PII support.

March 6, 20269 minute read
Germany BfDIDACH complianceSteuer-ID detectionGerman language PIIDSGVO technical

Deutschsprachige PII-Erkennung für die DSGVO-Compliance

Stand: 2026

Deutschland meldete 2024 insgesamt 27.829 Datenschutzverletzungen an den BfDI und die 16 Landesdatenschutzbehörden — ein neuer Höchststand. Das entspricht 31 % aller DSGVO-Meldungen in der EU. Diese Zahlen zeigen nicht nur eine aktive Meldekultur. Sie zeigen auch eine technische Lücke: 65 % der deutschen Unternehmen nutzen PII-Erkennungstools, die unzureichende Unterstützung für die deutsche Sprache bieten.

Dreistufige Durchsetzung in Deutschland

Die DSGVO-Durchsetzung in Deutschland ist komplex. Sie verteilt sich auf 17 Behörden.

BfDI (Bundesbeauftragter): Zuständig für Bundesbehörden, Telekommunikation, Postdienstleister und bundesländerübergreifende Organisationen.

16 Landesdatenschutzbehörden: Jedes Bundesland hat eine eigene Behörde mit unabhängigen Durchsetzungsbefugnissen. Die aktivsten Behörden:

  • Bayern – BayLDA: Gilt als eine der technisch anspruchsvollsten Datenschutzbehörden der EU. Auditierte 2024 über 250 Organisationen.
  • Hamburg: Pionier bei der Durchsetzung gegen US-Plattformbetreiber.
  • Baden-Württemberg – LfDI BW: Erließ die erste KI-spezifische DSGVO-Orientierung in Deutschland.

Unternehmen in Deutschland können gleichzeitig auf Bundes- und Landesebene kontrolliert werden. Das erhöht den Dokumentationsbedarf erheblich.

DACH-Komplexität: Drei Rechtsrahmen, eine Sprache

Deutschsprachige Organisationen im DACH-Raum arbeiten unter drei verschiedenen Rechtsrahmen.

Deutschland: EU-DSGVO mit BfDI und Landesdatenschutzbehörden. Spezifische Identifikatoren: Steueridentifikationsnummer (11 Stellen), Personalausweisnummer (10 Zeichen), IBAN im DE-Format.

Österreich: EU-DSGVO mit DSB-Durchsetzung. Österreichische Identifikatoren: Sozialversicherungsnummer (SVNR, 10 Stellen), eAT (elektronischer Aufenthaltstitel), FinanzOnline-Nummer.

Schweiz: revDSG (seit September 2023 in Kraft) — kein EU-DSGVO, aber eng daran angelehnt. Schweizer Identifikatoren: AHV-Nummer (13 Stellen, Format 756.XXXX.XXXX.XX), UID (Unternehmensidentifikation).

Wer in allen drei Ländern tätig ist, braucht ein PII-Tool, das deutschsprachigen Text und alle drei nationalen Identifikatoren verarbeitet. Hinzu kommt das Liechtensteinische DSG als vierter Rahmen.

Deutsche Identifikatoren im Detail

Steueridentifikationsnummer (Steuer-ID): 11-stellige Steuer-ID, die deutschen Einwohnern ab Geburt zugewiesen wird. Erstes Zeichen darf nicht null sein. Eine Prüfziffer am Ende wird per Modulo-Algorithmus berechnet. Kommt in allen deutschen Steuer-, Beschäftigungs- und Finanzdokumenten vor.

Personalausweisnummer: Format LNNNNNNNC (1 Buchstabe + 8 Ziffern + 1 Prüfzeichen). Das Prüfzeichen ergibt sich aus einem gewichteten Summenalgorithmus. Jeder deutsche Staatsbürger und jeder EU-Bürger mit Wohnsitz in Deutschland hat eine Personalausweisnummer.

Sozialversicherungsnummer (SV-Nummer): Format NNDDMMYYAAAA (2-stellige Gebietskennziffer + Geburtsdatum + 2 Buchstaben des Nachnamens + Prüfziffer). Wird in Beschäftigungs- und Rentenunterlagen verwendet.

Deutsche IBAN: Format DE + 2 Prüfziffern + 8-stellige Bankleitzahl (BLZ) + 10-stellige Kontonummer. Neben der IBAN-Mod-97-Prüfung ist auch das BLZ-Format zu validieren.

Krankenversicherungsnummer (KVNr): 10-stellige Nummer (1 Buchstabe + 9 Ziffern). Der Buchstabe kennzeichnet den Versicherer; die Ziffern enthalten eine Prüfziffer.

Die 65-%-Tool-Lücke

Laut BfDI-Erhebung 2024 nutzen 65 % der deutschen Unternehmen PII-Tools mit mangelhafter Deutschunterstützung. Konkrete Schwachstellen:

Steuer-ID-Erkennung: Muster werden ohne Prüfziffervalidierung abgeglichen. Das erzeugt viele Falschpositive bei beliebigen 11-stelligen Zahlenfolgen in deutschen Dokumenten.

Personalausweis-Erkennung: Fehler treten auf, wenn das Format ohne explizite Bezeichnung „Personalausweis" erscheint. Die kontextuelle Erkennung erfordert deutschsprachiges NER, um den Dokumenttyp korrekt zu bestimmen.

Deutsche Namenserkennung: Auf englischsprachigen Texten trainierte NLP-Modelle erkennen deutsche Namen schlecht. Besonders betroffen: zusammengesetzte Namen (Hans-Wilhelm, Anna-Katharina) und Umlaute (Müller, Schröder, Böhm).

Deutsche Adressformate: Straße, Platz, Weg und Gasse unterscheiden sich strukturell von englischen Adressformaten. Englische Parser produzieren bei deutschen Adressen systematische Fehler.

Der Compliance-Standard für BfDI, BayLDA und andere deutsche Datenschutzbehörden lautet: deutschsprachiges NER (spaCy de_core_news oder gleichwertig), Steuer-ID- und Personalausweis-Erkennung mit Prüfsummenvalidierung, SVNR-Unterstützung für österreichische Dokumente und AHV-Nummer-Unterstützung für Schweizer Dokumente.

Mehr zu mehrsprachigen Erkennungsproblemen findet sich im Leitfaden zur mehrsprachigen PII-Erkennung für DSGVO-Compliance. Technische Durchsetzungsschwerpunkte der BfDI sind im technischen BfDI-Leitfaden für deutsche Unternehmen dokumentiert. Zu deutschen nationalen Steuer-IDs und EU-weiten Identifikatoren siehe den Leitfaden zur EU-Steuer-ID-PII-Erkennung.

When This Approach Has Limits

Deutschsprachiges NER mit Prüfziffervalidierung für Steuer-ID und Personalausweis ist der richtige Weg, um die 65-%-Tool-Lücke zu schließen — der Kernansatz ist solide. Doch Grenzen bleiben und sollten klar benannt werden.

Die Erkennungsgenauigkeit begrenzt das Ergebnis. Ein Tool entfernt nur, was es als sensibel erkennt. Steuer-ID, Personalausweisnummer und SVNR profitieren von der Prüfsummenprüfung, doch Freitextfelder, OCR-Ausgaben und uneinheitliche Schreibweisen erzeugen weiterhin falsch-negative Treffer. Zusammengesetzte Namen wie Hans-Wilhelm und Umlaute in Müller oder Schröder bleiben fehleranfällig. Die verbleibende Falsch-Negativ-Rate setzt die obere Grenze des Schutzes — testen Sie gegen einen zurückgehaltenen Satz Ihrer eigenen Dokumente, bevor Sie sich auf die Ausgabe verlassen.

Die DACH-Mehrsprachigkeit verlangt pro Rahmen eigene Konfiguration und Tests. Vier Rechtsrahmen — DSGVO in Deutschland und Österreich, revDSG in der Schweiz, DSG in Liechtenstein — bedeuten unterschiedliche Identifikatoren: deutsche Steuer-ID, österreichische SVNR im Format NNDDMMYYAAAA und Schweizer AHV-Nummer im Format 756.XXXX.XXXX.XX. Ein für deutschen Text trainiertes Modell überträgt seine Genauigkeit nicht automatisch auf österreichische oder Schweizer Dokumente. Jedes Format braucht eigene Prüflogik und einen separaten, an realen Landesdaten gehaltenen Abnahmetest.

Pseudonymisiert ist nicht anonymisiert. Werden direkte Identifikatoren entfernt, können Quasi-Identifikatoren wie Postleitzahl, Geburtsdatum und Beruf eine Person in Kombination weiterhin re-identifizieren. Solche Ausgabe ist pseudonymisiert, nicht anonymisiert, und bleibt damit nach DSGVO im Anwendungsbereich — mit den rechtlichen Folgen, die diese Unterscheidung trägt. Zudem prüfen BfDI, BayLDA und die Landesbehörden die gesamte Organisation, nicht ein einzelnes Tool; juristische und menschliche Prüfung bleibt erforderlich.

Quellen

Limitations / When this doesn't apply

Die Erkennungsgenauigkeit begrenzt das Ergebnis. Steuer-ID, Personalausweisnummer und SVNR profitieren von der Prüfsummenprüfung, doch Freitextfelder, OCR-Ausgaben und uneinheitliche Schreibweisen erzeugen weiterhin falsch-negative Treffer; zusammengesetzte Namen wie Hans-Wilhelm und Umlaute in Müller oder Schröder bleiben fehleranfällig. Testen Sie gegen einen zurückgehaltenen Satz eigener Dokumente, bevor Sie sich auf die Ausgabe verlassen.

Die DACH-Mehrsprachigkeit verlangt pro Rechtsrahmen eigene Konfiguration und Tests: deutsche Steuer-ID, österreichische SVNR (NNDDMMYYAAAA) und Schweizer AHV-Nummer (756.XXXX.XXXX.XX) unterscheiden sich, und ein für deutschen Text trainiertes Modell überträgt seine Genauigkeit nicht automatisch.

Pseudonymisiert ist nicht anonymisiert: Quasi-Identifikatoren wie Postleitzahl, Geburtsdatum und Beruf können eine Person in Kombination weiterhin re-identifizieren, sodass die Ausgabe nach DSGVO im Anwendungsbereich bleibt. BfDI, BayLDA und die Landesbehörden prüfen die gesamte Organisation, nicht ein einzelnes Tool. Dieser Beitrag ist eine allgemeine, sich entwickelnde Orientierung — keine Rechtsberatung und kein Ersatz für anwaltlichen Rat.

Ready to protect your data?

Start anonymizing PII with 285+ entity types across 48 languages.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our company HQ is in Saarbrücken, Germany. Our servers run in Hetzner's Falkenstein datacenter.

Hetzner holds ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.