§ DOCUMENTATION

PII-Erkennung

Prüfsummenvalidierte nationale Ausweise für USA, EU und Indien sowie optionales Namen- und Adress-NER. Zwei Stufen: Strukturierte Ausweise blockieren synchron; Namen und Adressen sind ein optionaler, latenzgebundener NER-Durchlauf.

§ 01

Abdeckung

Region	Erkannte Typen	Stufe
US	SSN, credit card (Luhn), phone, email, IP (octet-bounded), date of birth	Tier-1
India	Aadhaar (Verhoeff), PAN, GSTIN	Tier-1
EU / UK	IBAN (mod-97), UK NINO, Spanish DNI/NIE, Italian Codice Fiscale, German IdNr, French INSEE	Tier-1
Alle Regionen	Namen (PERSON), Adressen (LOCATION), Organisationen — Presidio + GLiNER	Tier-2 (opt-in)

§ 02

Zwei Stufen – aus gutem Grund

Stufe 1 — deterministisch + Prüfsumme. Sub-Millisekunden-Mustererkenner, jeweils durch eine Prüfsumme gesichert, sofern eine existiert (Luhn für Karten, Verhoeff für Aadhaar, mod-97 für IBAN, ISO 7064 für die deutsche IdNr usw.). Immer synchron; hält Fehlalarme gering, weil ein Kandidat tatsächlich validieren muss.

Stufe 2 — Namen-/Adress-NER. Microsoft Presidio mit einem GLiNER-Recognizer (urchade/gliner_multi_pii-v1, Apache-2.0) erkennt PERSON-, LOCATION- und ORGANIZATION-Entitäten. Opt-in pro Richtlinie über sync_ner: Das Modell wird beim Start vorgeladen, der Aufruf wird per Redis nach Eingabe-Hash gecacht, parallel zur Regelschleife ausgeführt, hart zeitbegrenzt und durch den failure_mode der Richtlinie gesteuert.

§ 03

Fehlalarm-Schutzmaßnahmen

Typ	Schutzmaßnahme
`credit_card`	Luhn-Prüfsumme — eine zufällige 16-stellige Folge besteht den Test nicht.
`ip_address`	Jedes Oktett muss im Bereich 0–255 liegen — Versionszeichenketten wie 1.2.3.400 werden ignoriert.
`aadhaar / iban / …`	Prüfsummenvalidierung vor der Wertung als Treffer.

§ 04

Eine PII-Access-Richtlinie erstellen

Strukturierte Ausweise in denied_pii_types blockieren synchron. Fügen Sie sync_ner: true hinzu, um auch Namen/Adressen per Tier-2-NER abzulehnen. Kombinieren Sie dies mit failureMode: "fail_closed" für eine compliance-taugliche Kontrolle, die blockiert, wenn ein Detektor nicht verfügbar ist.

curl -X POST https://api.execlave.com/api/v1/policies \  -H "Authorization: Bearer $EXECLAVE_API_KEY" \  -H "Content-Type: application/json" \  -d '{    "name": "Block National IDs + Names",    "policyType": "pii_access",    "enforcementMode": "block",    "failureMode": "fail_closed",    "ruleDefinition": {      "denied_pii_types": ["ssn", "credit_card", "aadhaar", "iban", "person", "address"],      "allowed_pii_types": ["email"],      "mask_output": true,      "log_access": true,      "sync_ner": true    }  }'

§ 05

Häufig gestellte Fragen

Welche nationalen Ausweisdokumente erkennt Execlave?

US-Sozialversicherungsnummern und (Luhn-geprüfte) Kreditkarten; indische Aadhaar (Verhoeff-Prüfsumme), PAN und GSTIN; EU-IBAN (mod-97), britische National Insurance Number, spanische DNI/NIE, italienische Codice Fiscale, deutsche IdNr und französische INSEE. Auch E-Mail-Adressen, Telefonnummern, IP-Adressen und Geburtsdaten werden erkannt. Jeder Ausweistyp mit Prüfsumme wird vor der Wertung als Treffer validiert, was Fehlalarme gering hält.

Kann Execlave Namen und Postadressen erkennen, nicht nur strukturierte Ausweise?

Ja, über optionales Tier-2-NER. Wenn eine pii_access-Richtlinie sync_ner: true setzt und einen Namen-/Adresstyp (person, address, organization) ablehnt, führt Execlave Microsoft Presidio mit einem GLiNER-Recognizer aus, um PERSON-, LOCATION- und ORGANIZATION-Entitäten zu erkennen. Die Latenz ist begrenzt: Das Modell wird einmalig vorgeladen, der Aufruf wird per Eingabe-Hash gecacht, parallel zur Regelmaschine ausgeführt und durch den failure_mode der Richtlinie gesteuert.

Verursacht das breite Kreditkarten-/IP-Muster Fehlalarme?

Nein. Kreditkartenkandidaten müssen die Luhn-Prüfsumme bestehen, und IP-Kandidaten müssen in jedem Oktett den Bereich 0–255 einhalten – Versionszeichenketten wie 1.2.3.400 werden daher nicht als IPs gemeldet. Prüfsummengesteuerte nationale Ausweise (Aadhaar, IBAN, Codice Fiscale usw.) zählen nur, wenn ein gefundener Kandidat tatsächlich validiert.

Ist das Namen-/Adress-NER standardmäßig auf dem Hot Path aktiv?

Nein. Strukturierte, prüfsummenvalidierte Ausweise werden immer synchron erkannt. Das Namen-/Adress-NER ist standardmäßig deaktiviert und läuft nur, wenn eine Richtlinie explizit mit sync_ner: true einwilligt – und selbst dann überschneidet es sich mit der Regelschleife, ist hart zeitbegrenzt und folgt dem failure_mode der Richtlinie bei Fehlern, sodass das synchrone Durchsetzungsbudget erhalten bleibt.