Ein Tool, 45 Länder: 260+ Entitäten
Globale Plattformen verarbeiten personenbezogene Daten aus vielen Ländern gleichzeitig. Jedes Land hat eigene ID-Formate. Jedes Format hat eigene Regeln. Ein einzelnes Erkennungstool muss alle abdecken. Die meisten Tools tun das nicht.
Das Problem der Identifikator-Fragmentierung
Ein Marktplatz mit Verkäufern aus 45 Ländern erhält sehr unterschiedliche Onboarding-Dokumente. Ein brasilianischer Verkäufer reicht eine CPF ein. Sie hat 11 Stellen. Zwei davon sind Prüfstellen. Sie verwenden eine spezifische Gewichtungsformel. Ein indischer Verkäufer reicht eine PAN ein. Sie hat 10 Zeichen. Buchstaben und Ziffern stehen an festen Positionen. Ein deutscher Verkäufer reicht eine Steuer-ID ein. Sie hat 11 Stellen und eine Luhn-Prüfsumme. Ein niederländischer Verkäufer reicht eine BSN ein. Sie hat 9 Stellen und nutzt Modulo-11-Validierung.
Jedes Format hat eine andere Länge und Struktur. Ein Regex für ein Format passt nicht auf die anderen. Ein breites „10–12-stelliges" Muster erkennt zu viel. Es markiert Preise, Daten und Referenznummern. Falsch-Positive wachsen bei großem Maßstab schnell.
Die Lücke: 40 Identifikatoren
Die meisten Enterprise-PII-Tools liefern etwa 40 Identifikatortypen. Typische Beispiele:
- US-Sozialversicherungsnummer
- US-Reisepassformat
- US-Führerschein
- Generische Kreditkartenformate mit Luhn-Validierung
- E-Mail-Adressen
- Telefonnummern im NANP-Format
- IP-Adressen
Diese decken die nordamerikanische Compliance gut ab. Globale Anforderungen erfüllen sie nicht.
Die Lücke nach Regionen
Südamerika: Brasilianische CPF und CNPJ verwenden Prüfsummenalgorithmen der brasilianischen Finanzbehörde. Argentinische CUIT verwendet eine andere Gewichtungsformel. Kolumbianische NIT hat eine eigene Validierungsmethode. Keine davon passt zu US-Mustern.
Asien: Indische PAN, Aadhaar, GSTIN und Wähler-ID haben jeweils ein eigenes Format. Die japanische My Number hat 12 Stellen. Südkoreanische Einwohnerregistriernummer und chinesische Personalausweis-ID benötigen jeweils eigene Erkennungsmodule.
EU-Mitgliedstaaten: Vollständige EU-Abdeckung erfordert IBAN-Formate für alle 27 Mitgliedstaaten. Jeder hat eine landesspezifische Länge und Struktur. Außerdem werden nationale ID-Formate benötigt. Dazu gehören deutsche Steuer-ID, französische NIR, niederländische BSN, polnischer PESEL und schwedischer Personnummer. Ebenfalls enthalten: slowenische EMŠO, kroatische OIB, bulgarische EGN und rumänische CNP.
Was 260+ Entitätstypen abdecken
Eine Bibliothek mit 260+ Entitäten deckt alle nationalen IDs der 27 EU-Mitgliedstaaten ab. Sie validiert alle EU-IBAN-Formate. Sie deckt südamerikanische IDs ab: brasilianische CPF und CNPJ, argentinische CUIT, kolumbianische NIT. Sie deckt asiatische IDs ab: indische PAN, Aadhaar, GSTIN, japanische My Number, koreanische RRN. Sie deckt britische IDs ab: NI-Nummer, NHS-Nummer, NINO-Varianten. Sie deckt medizinische IDs ab: US NPI, DEA-Nummern, Krankenhaus-MRN-Formate. Sie deckt Finanz-IDs ab: SWIFT-Codes, BIC-Formate, Kontonummernmuster.
Warum Erkennungsabdeckung eine Compliance-Frage ist
Jeder Rechtsrahmen verlangt, dass seine Identifikatoren gefunden und geschützt werden. Die DSGVO deckt Daten von EU-Verkäufern ab. LGPD deckt Daten brasilianischer Verkäufer ab. Indiens DPDP-Gesetz deckt indische Verkäuferdaten ab.
„Angemessener Schutz" bedeutet, dass das Tool den Identifikator gefunden hat. Eine übersehene Aadhaar-Nummer ist kein Konfigurationsfehler. Es ist ein Abdeckungsfehler. Für globale Plattformen ist diese Lücke der Unterschied zwischen teilweiser Compliance und echtem Schutz.
Ein einzelner Einsatz mit 260+ Entitätsabdeckung bewältigt alle Jurisdiktionen. Keine separaten regionalen Tools. Keine getrennten Verarbeitungs-Pipelines. Keine manuelle Anreicherung für Formate, die ein 40-Erkennungs-Tool verpasst.
Mehr dazu, wie die Abdeckung den DSGVO-Pflichten entspricht: DSGVO-Compliance-Ressourcen. Für Audit-Trail und Update-Richtlinien: Sicherheits- und Compliance-Details.