การทำข้อมูล ML Training ให้สอดคล้อง GDPR: ไม่ต้องเขียนโค้ดเพื่อปิดบัง 10,000 รายการ

การทำข้อมูล ML Training ให้สอดคล้อง GDPR: ปิดบัง 10,000 รายการโดยไม่ต้องเขียนโค้ด

ทีมวิทยาศาสตร์ข้อมูลทุกทีมที่จัดการข้อมูลภายใต้ GDPR เคยเขียนสคริปต์ในลักษณะนี้:

import re
def anonymize_email(text):
    return re.sub(r'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}', '[EMAIL]', text)

นี่ไม่ใช่การปฏิบัติตาม GDPR แต่เป็นเพียงการแทนที่ที่อยู่อีเมล ชุดข้อมูลยังคงมีชื่อ หมายเลขโทรศัพท์ รหัสบันทึกทางการแพทย์ และข้อมูลส่วนบุคคลอีกหลายสิบประเภทที่จะก่อให้เกิดความล้มเหลวด้านการปฏิบัติตามกฎระเบียบ

ช่องว่างระหว่าง "ฉันลบอีเมลออกแล้ว" กับ "ชุดข้อมูลนี้สอดคล้อง GDPR สำหรับ ML training" นั้นกว้างใหญ่ มีนัยสำคัญ และถูกประเมินต่ำเกินไปอย่างสม่ำเสมอ

เหตุใด GDPR จึงจำกัดการใช้ข้อมูล ML Training

หลักการจำกัดวัตถุประสงค์ของ GDPR (มาตรา 5(1)(b)) ระบุว่าข้อมูลส่วนบุคคลอาจเก็บรวบรวมได้เฉพาะเพื่อวัตถุประสงค์ที่กำหนด ชัดเจน และชอบด้วยกฎหมาย และจะต้องไม่ประมวลผลต่อไปในลักษณะที่ไม่สอดคล้องกับวัตถุประสงค์เดิม

ข้อมูลลูกค้าที่เก็บรวบรวมเพื่อการจัดส่งคำสั่งซื้อ ไม่ได้เก็บมาเพื่อฝึก recommendation model ข้อมูลบันทึกสุขภาพที่เก็บรวบรวมเพื่อการรักษา ไม่ได้เก็บมาเพื่อฝึกโมเดลทำนายการกลับเข้ารักษา ข้อมูลแบบสอบถามที่เก็บรวบรวมเพื่อรับข้อเสนอแนะผลิตภัณฑ์ ไม่ได้เก็บมาเพื่อฝึกโมเดลวิเคราะห์ความรู้สึก

การนำข้อมูลเหล่านี้มาใช้ใน ML training ต้องการ:

1. ความยินยอมอย่างชัดแจ้งจากเจ้าของข้อมูลแต่ละรายสำหรับวัตถุประสงค์ ML training (ซับซ้อนในการดำเนินงาน มักเป็นไปไม่ได้ย้อนหลัง)
2. การประเมินผลประโยชน์ที่ชอบธรรมซึ่งแสดงให้เห็นว่าวัตถุประสงค์การฝึกสอดคล้องกับการเก็บรวบรวมเดิม (ไม่แน่นอนทางกฎหมาย ขึ้นอยู่กับ DPA)
3. การทำข้อมูลนิรนาม — ลบหรือแทนที่ข้อมูลส่วนบุคคลจนข้อมูลไม่เป็น "personal data" ตาม GDPR อีกต่อไป

การทำข้อมูลนิรนามที่ถูกต้องคือเส้นทางที่มีความยุ่งยากน้อยที่สุดและมีความแน่นอนทางกฎหมายมากที่สุด ความท้าทายคือการทำให้ถูกต้องและสม่ำเสมอ

ปัญหาของสคริปต์ทำข้อมูลนิรนามแบบเฉพาะกิจ

ทีมวิทยาศาสตร์ข้อมูลที่เขียนสคริปต์ Python แบบครั้งเดียวสำหรับแต่ละชุดข้อมูลใหม่ สร้างปัญหาทบทวีคูณ:

ความครอบคลุมไม่ครบถ้วน: สคริปต์ที่เขียนสำหรับ schema ของชุดข้อมูลหนึ่งพลาดข้อมูลส่วนบุคคลในคอลัมน์ที่เพิ่มมาหลังจากการอัปเดต schema ครั้งล่าสุด ฟิลด์บันทึกทางคลินิกที่เพิ่มมา 6 เดือนก่อน: ไม่อยู่ใน regex pattern

ความไม่สม่ำเสมอระหว่างชุดข้อมูล: ชุดข้อมูล A ถูกทำให้นิรนามด้วย script_v1.py ชุดข้อมูล B ด้วย script_v3.py ชุดข้อมูล C โดยสมาชิกทีมคนอื่นที่ไม่รู้จัก script_v3.py ชุดข้อมูล training ที่รวมกันมีวิธีการทำข้อมูลนิรนามสามแบบที่แตกต่างกัน DPO ไม่สามารถรับรองได้

ไม่มี audit trail: สคริปต์ทำงานแล้ว แต่เปลี่ยนแปลงอะไร? พบ entity อะไรบ้าง? ในแถวไหน? หากไม่มี metadata การประมวลผล การจัดทำเอกสารการปฏิบัติตามกฎระเบียบเป็นไปไม่ได้

Model drift: Pattern regex ที่ใช้ได้กับข้อมูลปี 2023 ไม่สามารถตรวจจับรูปแบบตัวระบุใหม่ที่เปิดตัวในปี 2024

แนวทางการประมวลผลแบบ Batch

ทีมวิทยาศาสตร์ข้อมูลของบริษัท Healthcare AI ต้องทำข้อมูลนิรนาม 8,000 บันทึกผู้ป่วยก่อนที่ทีม US จะเข้าถึงจากสำนักงาน EU ได้ (ข้อจำกัดการถ่ายโอนข้อมูลข้ามพรมแดน Schrems II ใช้บังคับ)

แนวทางดั้งเดิม: วิศวกรข้อมูลเขียนสคริปต์ทำข้อมูลนิรนามใน Python แบบกำหนดเอง เวลา: 2-3 วันในการพัฒนา 1-2 วันในการทดสอบและตรวจสอบกับ DPO 1 วันในการแก้ไข รวม: 4-6 วัน

แนวทาง Batch processing:

1. Export 8,000 รายการเป็น CSV
2. อัปโหลดเพื่อประมวลผลแบบ batch
3. กำหนดค่าประเภท entity: PERSON, EMAIL_ADDRESS, PHONE_NUMBER, US_SSN, MEDICAL_RECORD, DATE_OF_BIRTH, LOCATION
4. เลือกวิธีการ: Replace (แทนที่ด้วยข้อมูลปลอมที่สมจริงเพื่อรักษาโครงสร้างชุดข้อมูลสำหรับ ML training)
5. ประมวลผล: 45 นาทีสำหรับ 8,000 รายการ
6. ดาวน์โหลด CSV ที่ทำข้อมูลนิรนามแล้ว
7. DPO ตรวจสอบ metadata การประมวลผล: 2 ชั่วโมง
8. DPO อนุมัติ การแชร์ข้อมูลดำเนินต่อไป

เวลารวม: ประมวลผล 45 นาที + ตรวจสอบ DPO 2 ชั่วโมง เทียบกับ 4-6 วันสำหรับวิศวกรรม

Replace vs. Redact สำหรับข้อมูล ML Training

การเลือกวิธีการทำข้อมูลนิรนามมีความสำคัญต่อประโยชน์ใช้สอยของ ML:

Redact (การแทนที่ด้วย placeholder): แทนที่ข้อมูลส่วนบุคคลด้วย [REDACTED] หรือ token ที่คล้ายกัน สำหรับโมเดลที่ฝึกสำหรับงาน downstream (sentiment, classification, recommendation) token [REDACTED] จะรบกวนการสร้างแบบจำลองภาษาธรรมชาติ

Replace (การแทนที่ด้วยข้อมูลสังเคราะห์ที่สมจริง): แทนที่ "John Smith" ด้วย "David Chen" (ชื่อจริงแต่แตกต่าง) อีเมล "jsmith@company.com" กลายเป็น "dchen@synthetic.com" ชุดข้อมูลที่ได้รักษาการกระจายภาษาธรรมชาติ — โครงสร้างประโยค การวางตำแหน่ง entity รูปแบบการเกิดร่วมกัน — ซึ่งสำคัญสำหรับการฝึกโมเดล NLP

สำหรับข้อมูล ML training โดยเฉพาะ วิธี Replace คือวิธีที่เหมาะสม

Schrems II และการไหลของข้อมูลข้ามพรมแดน

คำตัดสิน Schrems II (CJEU, 2020) ทำให้ EU-US Privacy Shield เป็นโมฆะ ส่งผลทางปฏิบัติต่อวิทยาศาสตร์ข้อมูล: ข้อมูล training ที่มีต้นกำเนิดจาก EU ไม่สามารถส่งไปยังโครงสร้างพื้นฐาน ML ที่ตั้งอยู่ในสหรัฐอเมริกาได้โดยไม่มีมาตรการคุ้มครองการถ่ายโอนที่เพียงพอ

เหตุยกเว้นสำหรับข้อมูลนิรนาม: ข้อมูลที่ทำให้นิรนามอย่างถูกต้องไม่ใช่ข้อมูลส่วนบุคคลภายใต้ GDPR และไม่อยู่ภายใต้ข้อจำกัดการถ่ายโอน การทำข้อมูลนิรนามที่ถูกต้องจะขจัดปัญหา Schrems II โดยสิ้นเชิง

เอกสารสำหรับการอนุมัติ DPO

เมื่อส่งข้อมูล training ที่ทำให้นิรนามแล้วให้ DPO อนุมัติ ให้จัดเตรียม:

1. คำอธิบายข้อมูลต้นฉบับ: ชุดข้อมูลเดิมคืออะไร วัตถุประสงค์การเก็บรวบรวมคืออะไร ประกอบด้วยประเภทข้อมูลส่วนบุคคลใดบ้าง
2. การกำหนดค่าการทำข้อมูลนิรนาม: ตรวจจับและแทนที่ประเภท entity ใด ใช้วิธีการใด
3. Metadata การประมวลผล: จำนวน entity ที่ตรวจจับต่อรายการ คะแนนความเชื่อมั่นในการตรวจจับ จำนวนรายการที่ประมวลผลทั้งหมด
4. การประเมินความเสี่ยงที่เหลืออยู่: ความน่าจะเป็นที่บุคคลใดบุคคลหนึ่งจะถูกระบุตัวตนซ้ำจากชุดข้อมูลที่ทำให้นิรนามแล้ว
5. วัตถุประสงค์ที่ตั้งใจ: จะฝึกโมเดล ML ใด วัตถุประสงค์การฝึกคืออะไร

สรุป

ข้อมูล ML training ที่สอดคล้อง GDPR สามารถทำได้โดยไม่ต้องสคริปต์แบบเฉพาะกิจ ไม่ต้องล่าช้าด้านวิศวกรรมหลายวัน และไม่ต้องเสียสละประโยชน์ใช้สอยของชุดข้อมูล วิธี Replace ทำข้อมูลนิรนามรักษาคุณสมบัติภาษาธรรมชาติที่ทำให้ข้อมูลมีประโยชน์สำหรับการฝึกโมเดล NLP ในขณะที่ลบคุณสมบัติข้อมูลส่วนบุคคลที่ก่อให้เกิดความรับผิด GDPR

45 นาทีของการประมวลผลแบบ batch คือความแตกต่างระหว่างการตรวจสอบการปฏิบัติตามที่ล่าช้ากำหนดเวลากับการอนุมัติ DPO ที่ตรงไปตรงมา

แหล่งข้อมูล:

• GDPR มาตรา 5, 9, 89: การจำกัดวัตถุประสงค์ ข้อมูลประเภทพิเศษ และมาตรการปกป้องการวิจัย
• CJEU: Schrems II — การถ่ายโอนข้อมูลจาก EU ไปสหรัฐอเมริกา
• European Data Protection Board: แนวทาง ML และ GDPR