ปัญหา Quasi-PII
GDPR มาตรา 4 กำหนด "ข้อมูลส่วนตัว" ว่าเป็น "ข้อมูลใดๆ ที่เกี่ยวข้องกับบุคคลธรรมดาที่ระบุหรือ ระบุได้" คำสำคัญคือ "ระบุได้" — ไม่ใช่เฉพาะที่ระบุตัวตนในปัจจุบัน แต่รวมถึงที่สามารถระบุตัวตนได้ผ่านการประมวลผลเพิ่มเติม ค่าที่ไม่ได้ระบุตัวตนโดยตรงแต่ระบุตัวตนได้เมื่อรวมกับข้อมูลอื่น เรียกว่า quasi-identifier
ตัวอย่างตัวระบุภายในที่เป็น PII
ตัวระบุ HR:
EMP-2024-001234— รหัสพนักงานHR-DEPT-042-L3— รหัสแผนก/ระดับBADGE-A7B3C2— รหัสบัตรผ่าน
ตัวระบุ IT:
USR-JD-042— username ของระบบ (ตัวย่อชื่อ)DEV-MACHINE-JohnD— ชื่อเครื่องที่มีชื่อผู้ใช้
ตัวระบุเชิงพาณิชย์:
CUST-EU-DE-2024-08234— รหัสลูกค้า (เข้ารหัสประเทศ/ปีการเข้าร่วม)ORDER-ACCT-1234-SMITH— รหัสคำสั่งซื้อ (มีชิ้นส่วนชื่อ)
ทำไม 34% ของค่าปรับ GDPR เกี่ยวข้องกับ Quasi-Identifiers
ข้อผิดพลาดที่พบบ่อย:
- ทำให้ไม่ระบุตัวตนบางส่วน: แก้ไข SSN และชื่อ แต่ไม่แก้ไขรหัสพนักงาน ซึ่งเชื่อมโยงกลับไปยังฐานข้อมูล HR
- ชุดข้อมูลวิเคราะห์ที่เชื่อมได้: เผยแพร่ "ข้อมูลที่ไม่ระบุตัวตน" ที่ยังคงรหัสภายในซึ่งสามารถ join กับระบบอื่นได้
- บันทึก shared กับ external auditors: รหัสภายในในบันทึกทำให้ผู้ตรวจสอบภายนอกสามารถระบุบุคคลได้หากพวกเขาเข้าถึงฐานข้อมูลอ้างอิง
การสร้าง Custom Entity Types โดยไม่ต้องเขียนโค้ด
anonym.legal รองรับ custom entity types ผ่าน pattern configuration:
ตัวอย่าง: รหัสพนักงาน EMP-YYYY-NNNNNN
Pattern: EMP-\d{4}-\d{6}
Type: EMPLOYEE_ID
Score: 0.9
ตัวอย่าง: รหัสลูกค้า CUST-CC-YY-NNNNN
Pattern: CUST-[A-Z]{2}-\d{2}-\d{5}
Type: CUSTOMER_ID
Score: 0.85
ขั้นตอนการสร้าง Custom Entities:
- ระบุรูปแบบตัวระบุภายในของคุณ
- ทดสอบ pattern กับชุดตัวอย่าง
- กำหนด confidence threshold
- บูรณาการใน pipeline การทำให้ไม่ระบุตัวตน
กรณีใช้งาน: ชุดข้อมูลการวิเคราะห์ HR
บริษัทต้องการแชร์ข้อมูล HR สำหรับการวิเคราะห์เงินเดือน ข้อมูลมี:
- ชื่อพนักงาน (PII มาตรฐาน — ตรวจจับได้ง่าย)
- รหัสพนักงาน EMP-2024-XXXXXX (quasi-PII เฉพาะ)
- รหัสแผนก DEPT-XXXXXX (quasi-PII เฉพาะ)
เมื่อไม่มี custom entity detection รหัสพนักงานและแผนกผ่านโดยไม่ถูกตรวจจับ ทำให้ข้อมูล "ที่ไม่ระบุตัวตน" ยังคงสามารถเชื่อมได้กับระบบ HR
แหล่งที่มา: