อัปเดตสำหรับปี 2026
ช่องว่าง GDPR ที่ซ่อนอยู่
GDPR ไม่มีความชอบด้านภาษา มาตรา 4(1) กำหนดนิยาม "ข้อมูลส่วนบุคคล" โดยไม่ระบุภาษาที่ปรากฏ Steuer-ID เยอรมันได้รับการปกป้องเทียบเท่ากับหมายเลขประกันสังคมของสหรัฐฯ NIR ฝรั่งเศสได้รับการควบคุมเทียบเท่ากับหมายเลข National Insurance ของสหราชอาณาจักร
เครื่องมือตรวจจับ PII ส่วนใหญ่ถูกสร้างขึ้นสำหรับภาษาอังกฤษเท่านั้น
งานวิจัยจาก ACL 2024 พบว่าเครื่องมือ NLP แบบผสมได้คะแนน F1 0.60–0.83 สำหรับ locale ของยุโรป เครื่องมือที่รองรับเฉพาะภาษาอังกฤษได้คะแนนใกล้ศูนย์สำหรับรูปแบบ national ID ที่ไม่ใช่ภาษาอังกฤษ ช่องว่างนี้ชัดเจน เครื่องมืออาจตรวจจับ PII ภาษาอังกฤษได้ 95% แต่พลาด 40–60% ของ PII เยอรมัน ฝรั่งเศส โปแลนด์ หรือดัตช์ในไฟล์เดียวกัน
นี่คือช่องว่าง GDPR จริง ส่งผลต่อเกือบทุกบริษัทระดับโลกที่ใช้เครื่องมือลบข้อมูลที่เน้นภาษาอังกฤษ ดู คู่มือ GDPR ของเราสำหรับข้อมูลเพิ่มเติม
ทำไม PII จึงเฉพาะ locale
การตรวจจับ PII มีสองส่วน
ส่วนแรกคือการสแกนตามรูปแบบ ครอบคลุม ID ที่มีโครงสร้างเช่นหมายเลขภาษีและรูปแบบโทรศัพท์
ส่วนที่สองคือการสแกนตาม NER ครอบคลุม entity ตามบริบทเช่นชื่อและที่อยู่
ทั้งสองส่วนขึ้นอยู่กับ locale
ID ที่มีโครงสร้างแตกต่างตามประเทศ
| ประเทศ | Tax ID | รูปแบบ | การตรวจสอบ |
|---|---|---|---|
| เยอรมนี | Steuer-ID | 11 หลัก | Modulo-11 |
| ฝรั่งเศส | NIR | 15 หลัก + กุญแจ 2 หลัก | INSEE |
| สวีเดน | Personnummer | 10 หลัก | Luhn |
| โปแลนด์ | PESEL | 11 หลัก | Modulo-10 |
| เนเธอร์แลนด์ | BSN | 9 หลัก | Elfproef |
| สเปน | DNI/NIE | 8 หลัก + ตัวอักษร | Modulo-23 |
| อิตาลี | Codice Fiscale | 16 ตัวอักษร | checksum เฉพาะ |
regex ภาษาอังกฤษสำหรับ SSN (NNN-NN-NNNN) จะไม่ตรงกับรูปแบบใดๆ เหล่านี้ แต่ละรูปแบบต้องการ regex ของตัวเอง และตรรกะ checksum ของตัวเอง
NER ต้องการโมเดลพื้นเมือง
ชื่อเยอรมันแตกต่างจากชื่ออังกฤษ "Hans-Dieter Müller" ชัดเจนสำหรับโมเดลเยอรมัน โมเดลที่ฝึกด้วยภาษาอังกฤษมักพลาดชื่อเหล่านี้
false positive ก็เป็นปัญหาเช่นกัน issue tracker ของ Microsoft Presidio แสดงคำเยอรมันที่ถูกจัดประเภทผิดเป็น PII ภาษาอังกฤษ คำว่า "Null" (ภาษาเยอรมันแปลว่า "ศูนย์") ทำให้เกิด false name hits ในโมเดลที่ฝึกด้วยภาษาอังกฤษ ในการใช้งานจริง อัตราข้อผิดพลาดพองตัวเป็น 3 false positives ต่อ entity จริง 1 รายการ
ความเสี่ยงด้านกฎระเบียบ
หน่วยงาน EU ตระหนักถึงปัญหานี้ DPA ระดับชาติหลายแห่งได้ออกแนวทาง:
BfDI เยอรมัน: GDPR มาตรา 5(1)(f) บังคับใช้กับบันทึกทั้งหมด ครอบคลุมข้อมูลที่ไม่ใช่ภาษาอังกฤษที่ประมวลผลโดยเครื่องมือของบุคคลที่สาม
CNIL ฝรั่งเศส: รายงานประจำปี CNIL 2024 แสดงความกังวล เกี่ยวกับเครื่องมือ AI ที่จัดการบันทึกฝรั่งเศสโดยไม่มีการสแกน PII ระดับ locale ฝรั่งเศส
GDPR มาตรา 25: กำหนดให้มีมาตรการรักษาความปลอดภัยที่เหมาะกับบันทึกจริงที่ประมวลผล ซึ่งรวมถึง PII ที่ไม่ใช่ภาษาอังกฤษในการติดตั้งระดับโลก
ความเสี่ยงชัดเจน บริษัทอาจแสดงการตรวจจับ PII 95% บนเนื้อหาภาษาอังกฤษในการตรวจสอบ GDPR แต่หากจัดการบันทึกเยอรมัน ฝรั่งเศส และโปแลนด์ด้วยเครื่องมือเดียวกัน ช่องว่างจะปรากฏ ผู้ตรวจสอบสังเกตเห็น ค่าปรับอาจตามมา ดู หน้ามาตรการรักษาความปลอดภัย ของเราสำหรับวิธีที่เราจัดการเรื่องนี้
การออกแบบสามระดับ
งานวิจัยและการใช้งานจริงเห็นพ้องกับ การออกแบบแบบผสมสามระดับ เป็นแนวทางที่ดีที่สุด
ระดับ 1: โมเดล spaCy พื้นเมือง
spaCy มีโมเดลที่ฝึกแล้วสำหรับ 25 locale ครอบคลุมเยอรมัน ฝรั่งเศส สเปน โปรตุเกส อิตาลี ดัตช์ รัสเซีย จีน ญี่ปุ่น เกาหลี และโปแลนด์ แต่ละโมเดลฝึกบนข้อความพื้นเมือง เรียนรู้ syntax และรูปแบบ entity ของแต่ละ locale
สำหรับภาษาเยอรมัน: de_core_news_lg จัดการคำประสมและรูปแบบชื่อเยอรมัน
สำหรับภาษาฝรั่งเศส: fr_core_news_lg จัดการ entity ฝรั่งเศส ตำแหน่ง และองค์กร
ระดับ 2: Stanza สำหรับ locale เพิ่มเติม
ไลบรารี Stanza ของ Stanford ครอบคลุม locale ที่ไม่อยู่ใน spaCy ได้แก่ โครเอเชีย สโลวีเนีย และยูเครน เพิ่มการครอบคลุมสำหรับกลุ่มภาษา EU ที่ spaCy ไม่รองรับ
ระดับ 3: XLM-RoBERTa สำหรับการครอบคลุมกว้าง
สำหรับ locale ที่ spaCy และ Stanza ขาดโมเดล NER XLM-RoBERTa เติมเต็มช่องว่าง ฝึกบนข้อความ Common Crawl ใน 100 locale บรรลุ F1 cross-lingual 91.4% สำหรับการตรวจจับ PII จัดการการสลับโค้ดได้ดี ซึ่งเป็นคุณสมบัติสำคัญสำหรับเอกสารที่มีข้อความหลาย locale
เยี่ยมชม เอกสารระบบ token เพื่อดูวิธีที่การเรียก API ขยายตัวตามปริมาณหลายภาษา
ประเภท Entity เฉพาะ Locale
โมเดลเพียงอย่างเดียวไม่เพียงพอ การสอดคล้องกับ GDPR ยังต้องการขอบเขตประเภท entity สำหรับ ID เฉพาะประเทศ
National ID EU ตามประเทศ:
- DE: Steuer-ID, Sozialversicherungsnummer, Personalausweisnummer
- FR: NIR, SIREN, SIRET
- PL: PESEL, NIP, REGON
- NL: BSN
- SE: Personnummer, Samordningsnummer
- ES: DNI, NIE, NIF, CIF
- IT: Codice Fiscale, Partita IVA
รูปแบบโทรศัพท์: แต่ละประเทศ EU มีโครงสร้าง prefix เฉพาะ +49, +33 และ +48 แต่ละอันต้องการตรรกะการตรวจสอบของตัวเอง
รูปแบบที่อยู่: รหัสไปรษณีย์แตกต่างกันมาก เยอรมัน PLZ ใช้ 5 หลัก รหัสฝรั่งเศสใช้ 5 หลัก รหัสไปรษณีย์ UK เป็นตัวอักษรผสมตัวเลข
กรณีศึกษาจริง: บริษัทเภสัชกรรมสวิส
บริษัทสวิสประมวลผลสัญญาจ้างงาน แต่ละสัญญาผสมข้อความเยอรมัน ฝรั่งเศส และอังกฤษ เครื่องมือของพวกเขาตั้งค่าสำหรับภาษาเยอรมันเท่านั้น พลาด PII ในส่วนภาษาฝรั่งเศสทั้งหมด
สัญญาของพนักงานที่ประจำเจนีวาประกอบด้วย AVS number ฝรั่งเศส (13 หลัก) IBAN ธนาคารสวิส และชื่อในรูปแบบฝรั่งเศส เครื่องมือที่รองรับเฉพาะเยอรมันพลาดชื่อรูปแบบฝรั่งเศส ไม่พบ AVS number รูปแบบฝรั่งเศส และตรวจจับ IBAN ได้เพียงบางส่วน
แนวทางสามระดับประมวลผลเอกสารทั้งหมด ตรวจจับ locale ต่อส่วนข้อความ ใช้โมเดล NER ที่เหมาะสมสำหรับแต่ละส่วน และตรวจสอบ national ID แต่ละอันด้วยตรรกะประเทศที่ถูกต้อง
เอกสารหลาย Locale ผสมกัน
กรณีที่ยากที่สุดคือการผสม locale ภายในเอกสาร ตัวอย่างเช่น:
- สัญญาภาษาอังกฤษของบริษัทเยอรมันที่มีข้อมูลพนักงานเยอรมัน
- แบบฟอร์มความยินยอม GDPR ภาษาฝรั่งเศสที่มีข้อความความเป็นส่วนตัวภาษาอังกฤษ
- การสนทนาที่ agent ตอบภาษาอังกฤษและลูกค้าเขียนภาษาอาหรับ
XLM-RoBERTa จัดการสิ่งนี้โดยธรรมชาติ ไม่ต้องระบุ locale อย่างชัดเจน ประมวลผลข้อความหลาย locale โดยไม่ต้องแบ่งส่วนก่อน
ขั้นตอนปฏิบัติ
ตรวจสอบการครอบคลุมของเครื่องมือ ถามผู้ให้บริการลบข้อมูลของคุณสำหรับคะแนน F1 ของ locale ที่คุณใช้จริง "รองรับ 20 ภาษา" มักหมายความว่าเครื่องมือส่งข้อความผ่านการแปลเครื่องก่อน นั่นไม่ใช่การสแกนพื้นเมือง
แมปบันทึกกับ locale ทำบัญชีบันทึกที่รวมการกระจาย locale บริษัทระดับโลกที่มี 70% ภาษาอังกฤษ 20% เยอรมัน 10% ฝรั่งเศส เผชิญความเสี่ยงต่างกัน
ทดสอบด้วยตัวอย่าง national ID สร้างชุดทดสอบพร้อมตัวอย่าง 10 รายการของ national ID ที่ใช้ในการดำเนินงานของคุณ — Steuer-ID, NIR, PESEL, BSN และอื่นๆ ตรวจสอบอัตราการตรวจจับ
ทบทวน DPIA ของคุณ ตรวจสอบว่ารวมขอบเขต locale ไว้หรือไม่ DPIA ที่ไม่สมบูรณ์โดยสมมติว่าเป็นบันทึกภาษาอังกฤษเท่านั้นอาจต้องอัปเดต ดำเนินการตอนนี้ อย่ารอให้การตรวจสอบพบช่องว่าง
สำหรับคำจำกัดความประเภท entity ครบถ้วน ดู การอ้างอิง entity และ FAQ สำหรับแผนและอัตราการเรียก API เยี่ยมชม ราคา
engine ตรวจจับ PII ของ anonym.legal ใช้แนวทาง NER หลายภาษาสามระดับ ครอบคลุม 25 locale ที่มีทรัพยากรสูงผ่านโมเดล spaCy พื้นเมือง Stanza เพิ่มการครอบคลุม locale เพิ่มเติม XLM-RoBERTa cross-lingual transformers ขยายขอบเขตถึง 48 locale มีประเภท entity เฉพาะประเทศสำหรับประเทศสมาชิก EU ทั้งหมด