TOR โครงการ TH-AI Passport กับประเด็น PDPA
ดร.อุดมธิปก ไพรเกษตร
นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย
ผู้ก่อตั้งสื่อ PDPA Thailand
เมื่อ 2 สัปดาห์ก่อนผมได้รับ TOR โครงการ TH-AI Passport จากเพื่อนท่านหนึ่ง แล้วให้ช่วยวิเคราะห์ในประเด็นที่เกี่ยวข้องกับ PDPA แม้ว่าจะเคยให้ความเห็นเรื่อง TH-AI Passport ในฐานะอนุกรรมการด้านการสื่อสาร โทรคมนาคม และเทคโนโลยีสารสนเทศ สภาผู้บริโภค เมื่อวันที่ 3 มิถุนายน ซึ่งท่านสามารถอ่านได้จาก https://www.tcc.or.th/free-ai-criteria/
และเมื่ออ่าน TOR โครงการ TH-AI Passport อย่างละเอียด ผมพบว่าโครงการมีการประมวลผลข้อมูลส่วนบุคคลขนาดใหญ่เพราะนอกจากมีการยืนยันตัวตนผ่านระบบรัฐ การใช้เลขประจำตัวประชาชนแล้วยังมีการจัดเก็บข้อมูลพฤติกรรมการใช้ Generative AI การประเมินทักษะ การออกใบรับรองดิจิทัล การจัดเก็บ log file การใช้ cloud และการเชื่อมต่อกับผู้ให้บริการ AI หลายราย
สิ่งที่ TOR เขียนไว้ดีแล้ว
TOR ฉบับนี้มีหลายข้อที่เป็นจุดเริ่มต้นที่ดีด้านการคุ้มครองข้อมูลส่วนบุคคล เช่น
มีการระบุชัดว่าโครงการเกี่ยวข้องกับข้อมูลส่วนบุคคลและข้อมูลพฤติกรรมการใช้งาน AI กำหนดให้ข้อมูลถูกจัดเก็บและประมวลผลภายในประเทศ ห้ามโอนข้อมูลออกนอกประเทศโดยไม่ได้รับอนุญาต กำหนดให้ขอความยินยอมตาม PDPA และให้ลบหรือทำลายข้อมูลเมื่อเจ้าของข้อมูลใช้สิทธิตามกฎหมาย
นอกจากนี้ TOR ยังระบุเรื่อง RBAC, Audit Trail, encryption, backup, access control, vulnerability scan, penetration test และมาตรฐานด้าน cloud เช่น ISO/IEC 27001, 27701, 27017 และ 27018 รวมถึงกำหนดให้ cloud provider มี DPO และห้ามผู้รับจ้างนำข้อมูลไปใช้เพื่อกิจการอื่น
ข้อกำหนดเหล่านี้ถือเป็นจุดเริ่มต้นที่ดี แต่ยังมีหลายประเด็นที่ควรเพิ่มเติมเพื่อไม่ให้ PDPA เป็นเพียงข้อกำหนดด้านเทคนิคหรือเอกสารประกอบโครงการเท่านั้น
สิ่งที่ควรเพิ่ม
แม้โครงการจะจัดซื้อจัดจ้างไปแล้ว หากสามารถเพิ่มเอกสารและกลไกด้าน PDPA เพิ่มเติมบางส่วนได้ จะช่วยลดความเสี่ยงและทำให้โครงการเป็นต้นแบบของรัฐในการใช้ AI อย่างรับผิดชอบ
สิ่งที่ควรมีเพิ่มเติม ได้แก่
- Role Mapping ระบุผู้ควบคุมข้อมูล ผู้ประมวลผลข้อมูล ผู้ควบคุมร่วม และผู้ประมวลผลช่วง
- Lawful Basis Mapping แยกตามกิจกรรม ไม่ใช้ consent รวมทุกเรื่อง
- Privacy Notice ตามมาตรา 23 แบบแยกตามกิจกรรม
- Data Processing Agreement ระหว่าง สดช. กับผู้รับจ้าง และข้อตกลงกับ sub-processor
- Data Sharing Agreement หรือ Joint Controller Arrangement กับหน่วยงานที่เชื่อมข้อมูล
- DPIA และ AI Risk Assessment ก่อนเปิดระบบจริง
- Cross-border Transfer Assessment สำหรับ AI vendor, cloud, public cloud และ remote access
- RoPA ตามมาตรา 39 และ processor record ตามมาตรา 40
- DPO Governance ทั้งฝั่ง สดช. ผู้รับจ้างหลัก และ vendor สำคัญ
- Data Subject Rights Workflow รองรับสิทธิของเจ้าของข้อมูลครบถ้วน
- Retention, Deletion และ Anonymization Schedule แยกตามประเภทข้อมูล
- AI Data Governance Policy สำหรับ prompt, uploaded file, chat history, AI Agent, model training และ usage analytics
เนื่องจากผมไม่ได้เกี่ยวข้องกับการดำเนินโครงการ จึงไม่อาจยืนยันได้ว่าโครงการได้จัดทำเอกสารหรือกลไกเหล่านี้แล้วหรือไม่ หากดำเนินการไว้แล้วควรมีการชี้แจงเพิ่มเติมเพื่อสร้างความเชื่อมั่นให้กับประชาชนและสังคม
หัวใจของ TOR นี้คือข้อ 2.2 และข้อมูลพฤติกรรมการใช้ AI
TOR หน้า 2 ข้อ 2.2 ระบุว่าโครงการต้องส่งเสริมให้ข้อมูลส่วนบุคคลและข้อมูลพฤติกรรมการใช้งาน Generative AI ถูกจัดเก็บและประมวลผลภายในประเทศไทย และยกระดับการคุ้มครองข้อมูลส่วนบุคคลตามกฎหมายไทยให้สูงสุด
ข้อความนี้สำคัญ เพราะทำให้เห็นว่าโครงการนี้มีการประมวลผลข้อมูลส่วนบุคคลอย่างชัดเจน ไม่ใช่เพียงข้อมูลลงทะเบียนทั่วไป แต่รวมถึงข้อมูลพฤติกรรมการใช้ AI ซึ่งอาจสะท้อนความสนใจ ความรู้ ความสามารถ คำถาม ปัญหา เอกสารที่ผู้ใช้ส่งเข้าไป และรูปแบบการใช้งาน AI ของแต่ละบุคคล
หากข้อมูลเหล่านี้เชื่อมโยงกลับไปยังบุคคลได้ จึงเป็นข้อมูลส่วนบุคคลตามมาตรา 6 ของ PDPA ดังนั้น TOR ทั้งฉบับจึงควรถูกพิจารณาภายใต้กรอบ PDPA ตั้งแต่ต้น
คำถามที่ต้องตอบให้ได้คือ ใครเป็นผู้ควบคุมข้อมูล ใครเป็นผู้ประมวลผล ใช้ฐานกฎหมายใด แจ้งเจ้าของข้อมูลอย่างไร ส่งต่อให้ใคร เก็บไว้ที่ไหน และลบเมื่อไร
ใครเป็นผู้ควบคุมข้อมูล ใครเป็นผู้ประมวลผล
เมื่อเทียบกับมาตรา 6 ของ PDPA สดช. เป็นผู้ควบคุมข้อมูลส่วนบุคคลหลักของโครงการ เพราะเป็นผู้กำหนดวัตถุประสงค์ กลุ่มเป้าหมาย ระบบที่ต้องมี ข้อมูลที่ต้องจัดเก็บ รายงานที่ต้องส่งมอบ และเงื่อนไขการใช้ข้อมูล
ส่วนผู้รับจ้างหลักควรถูกมองเป็นผู้ประมวลผลข้อมูลส่วนบุคคล เพราะทำหน้าที่พัฒนา จัดหา และให้บริการแพลตฟอร์มตาม TOR เช่น ระบบลงทะเบียน ระบบ Generative AI ระบบการเรียนรู้ dashboard, call center, cloud, security และระบบรายงานผล
อย่างไรก็ตาม โครงการยังเกี่ยวข้องกับหลายฝ่าย เช่น DGA, ThaiD, ฐานข้อมูลนักศึกษา ผู้ให้บริการ Generative AI, cloud, public cloud, call center, survey, ผู้จัดกิจกรรม และ social media platform
ฝ่ายเหล่านี้อาจมีสถานะต่างกัน บางรายเป็น sub-processor บางรายเป็นผู้ควบคุมข้อมูลอิสระ และบางกรณีอาจเป็นผู้ควบคุมข้อมูลร่วม จึงควรมี Role Mapping ที่ชัดเจนก่อนเริ่มประมวลผลข้อมูลจริง
ระบบลงทะเบียน เลขบัตรประชาชน และการยืนยันตัวตนรัฐ
TOR หน้า 5 ข้อ 4.2.1.1 กำหนดให้ระบบลงทะเบียนและยืนยันตัวตนเชื่อมกับระบบทางรัฐของ DGA หรือ ThaiD และตรวจสอบเลขประจำตัวประชาชนเพื่อป้องกันการใช้สิทธิซ้ำ
เรื่องนี้ไม่ใช่เพียงประเด็นเทคนิค เพราะเลขประจำตัวประชาชนเป็นข้อมูลส่วนบุคคลที่มีความเสี่ยงสูง หากรั่วไหลอาจนำไปสู่การสวมรอยหรือความเสียหายอื่นได้
การเชื่อมกับระบบรัฐยังอาจเกี่ยวข้องกับการเก็บข้อมูลจากแหล่งอื่นตามมาตรา 25 และการเปิดเผยหรือใช้ข้อมูลระหว่างหลายหน่วยงานตามมาตรา 27 จึงควรมีข้อตกลงการเชื่อมโยงข้อมูลที่ชัดเจน
นอกจากนี้ การตรวจสอบสิทธิหรือการระงับสิทธิควรมีความโปร่งใส มีช่องทางให้เจ้าของข้อมูลตรวจสอบและแก้ไข หากข้อมูลผิดพลาดจนทำให้ถูกปฏิเสธสิทธิในการใช้บริการ
Consent ไม่ใช่ฐานกฎหมายเดียวของโครงการ
TOR หน้า 5 ข้อ 4.2.1.7(1) กำหนดให้ขอความยินยอมจากผู้ใช้งานก่อนจัดเก็บและประมวลผลข้อมูลส่วนบุคคล โดยเฉพาะข้อมูลพฤติกรรมการใช้งาน
ข้อนี้สะท้อนว่า TOR ให้ความสำคัญกับ PDPA แต่ในเชิงกฎหมายต้องระวังว่า consent ไม่ใช่ฐานกฎหมายเดียวของทุกกิจกรรม
PDPA มาตรา 24 ยังมีฐานกฎหมายอื่น เช่น การปฏิบัติตามกฎหมาย ภารกิจเพื่อประโยชน์สาธารณะ การใช้อำนาจรัฐ การปฏิบัติตามสัญญา หรือประโยชน์โดยชอบด้วยกฎหมาย
กิจกรรมอย่างการลงทะเบียน ตรวจสิทธิ ยืนยันตัวตน ป้องกันสิทธิซ้ำ จัดสรรเครดิต AI จัดทำรายงานผลโครงการ รักษาความปลอดภัย และเก็บ log อาจไม่ควรใช้ consent เป็นฐานหลักทั้งหมด
หากไม่ consent แล้วใช้บริการไม่ได้เลย ความยินยอมนั้นอาจถูกตั้งคำถามว่าเป็นอิสระเพียงพอหรือไม่ ทางที่เหมาะสมคือจัดทำ Lawful Basis Mapping แยกตามกิจกรรม และใช้ consent เฉพาะกิจกรรมที่ไม่จำเป็นต่อบริการหลัก เช่น การใช้ภาพประชาสัมพันธ์รายบุคคล หรือการนำข้อมูลไปใช้พัฒนาโมเดล
Privacy Notice ต้องมาก่อน
เมื่อ TOR ระบุว่ามีการเก็บข้อมูลส่วนบุคคลและข้อมูลพฤติกรรมการใช้ AI โครงการต้องจัดทำ Privacy Notice ตามมาตรา 23 ให้ครบถ้วน
Privacy Notice ไม่ควรเขียนกว้าง ๆ ว่า “เก็บข้อมูลเพื่อดำเนินโครงการ” แต่ควรแยกตามกิจกรรม เช่น การลงทะเบียน การตรวจสิทธิ การใช้ Generative AI การเก็บ prompt, file upload, chat history, การสร้าง AI Agent, การเรียนออนไลน์ การออก e-certificate, dashboard, call center, survey, กิจกรรมประชาสัมพันธ์ และการเก็บ log file
แต่ละกิจกรรมควรระบุให้ชัดว่าเก็บข้อมูลอะไร เพื่ออะไร ใช้ฐานกฎหมายใด เปิดเผยให้ใคร เก็บไว้นานเท่าไร ส่งออกนอกประเทศหรือไม่ เจ้าของข้อมูลมีสิทธิอะไร และติดต่อ DPO ได้อย่างไร
นี่คือความแตกต่างระหว่างการมีเพียง consent checkbox กับการมีระบบคุ้มครองข้อมูลส่วนบุคคลจริง
การใช้ Generative AI และข้อมูลพฤติกรรมที่มีความเสี่ยงสูง
TOR หน้า 6 ข้อ 4.2.2.1 กำหนดให้แพลตฟอร์มรองรับ Generative AI หลายผลิตภัณฑ์ การสนทนา การ upload file การจัดการประวัติสนทนา การสร้าง AI Agent และการสร้างภาพ
ในมุม PDPA ส่วนนี้เป็นพื้นที่ความเสี่ยงสูง เพราะ prompt อาจมีข้อมูลส่วนบุคคลของผู้ใช้หรือบุคคลอื่น ไฟล์ที่ upload อาจมีข้อมูลลูกค้า นักเรียน ผู้ป่วย พนักงาน หรือคู่สัญญา ส่วน chat history อาจสะท้อนความสนใจ ความคิด ปัญหาสุขภาพ ปัญหาทางการเงิน หรือประเด็นละเอียดอ่อนของผู้ใช้
แม้ TOR ไม่ได้ตั้งใจเก็บข้อมูลอ่อนไหว แต่การเปิดให้ประชาชน upload file และพิมพ์ prompt ทำให้มีโอกาสที่ข้อมูลอ่อนไหวตามมาตรา 26 จะเข้าสู่ระบบโดยไม่ตั้งใจ
TOR จึงควรกำหนดมาตรการเฉพาะ เช่น คำเตือนก่อนใช้ระบบ ข้อห้ามนำข้อมูลอ่อนไหวเข้าระบบ data loss prevention, masking หรือ redaction, retention limit และข้อห้ามไม่ให้ vendor ใช้ข้อมูลผู้ใช้เพื่อ train model โดยไม่มีฐานกฎหมายที่ชัดเจน
Dashboard การวิเคราะห์รายบุคคล และ DPIA
TOR หน้า 7 ข้อ 4.2.2.3 และ 4.2.2.4 กำหนดให้ระบบประเมินภัยคุกคาม การใช้งานผิดกฎหมาย การใช้งานผิดวัตถุประสงค์ และความเสี่ยงรายบุคคลหรือรายกลุ่ม รวมถึงวิเคราะห์พฤติกรรมและแนวโน้มการใช้งาน
TOR หน้า 8 ข้อ 4.2.4.6 ยังระบุเรื่องรายงานผลการใช้งาน AI รายงานพฤติกรรมการใช้งาน แนวโน้มรายบุคคลและกลุ่มผู้ใช้งาน รวมถึงรายงานภัยคุกคามหรือความเสี่ยงในการใช้ Generative AI
นี่ไม่ใช่เพียง dashboard จำนวนผู้ใช้ แต่เป็นการวิเคราะห์พฤติกรรมของผู้ใช้ในระดับรายบุคคลและรายกลุ่ม
โครงการจึงต้องตอบให้ได้ว่า การวิเคราะห์ระดับรายบุคคลจำเป็นแค่ไหน ใช้ข้อมูลแบบ aggregate แทนได้หรือไม่ ใครเข้าถึง dashboard ได้ มี audit trail หรือไม่ และหากมีการระงับสิทธิจากข้อมูลหรือคะแนนความเสี่ยง เจ้าของข้อมูลมีช่องทางทบทวนอย่างไร
ในเชิง PDPA ประเด็นนี้เกี่ยวข้องกับมาตรา 23, 24, 37, 39 และ 41 และควรทำ DPIA หรือ Data Protection Impact Assessment แม้ PDPA ไทยยังไม่ได้กำหนด DPIA เป็นหน้าที่ทั่วไปโดยตรง เพราะโครงการที่ใช้ AI กับประชาชนจำนวนมากและมีการวิเคราะห์พฤติกรรมรายบุคคลควรจัดอยู่ในกลุ่มความเสี่ยงสูง
Data Localization ในยุค Generative AI
TOR ระบุเรื่อง Data Localization หลายจุด เช่น ข้อ 2.2 กำหนดให้ข้อมูลส่วนบุคคลและข้อมูลพฤติกรรมการใช้ AI อยู่ในประเทศไทย ข้อ 4.2.1.7(2) กำหนดให้ข้อมูลลงทะเบียนจัดเก็บและประมวลผลในประเทศ และข้อ 11.3.8 กำหนดเรื่องศูนย์ข้อมูลหลักในประเทศไทย
หลักการนี้สอดคล้องกับมาตรา 28 และ 29 ของ PDPA เรื่องการส่งหรือโอนข้อมูลส่วนบุคคลไปต่างประเทศ
อย่างไรก็ตาม ในโลก Generative AI คำถามไม่จบที่ฐานข้อมูลลงทะเบียนอยู่ในไทย แต่ต้องถามต่อว่า prompt ถูกส่งไปที่ไหน ไฟล์ที่ upload ประมวลผลที่ใด chat history, metadata และ telemetry อยู่ประเทศใด มี sub-processor ต่างประเทศหรือไม่ และมี remote access จากต่างประเทศหรือไม่
ดังนั้น Data Localization ควรถูกตรวจสอบในหลายมิติ ทั้งที่เก็บข้อมูล สถานที่ประมวลผล สถานที่เข้าถึงข้อมูล ผู้รับจ้างช่วง และการโอนข้อมูลข้ามประเทศ
DPA, DSA, RoPA และ Processor Record
TOR หน้า 17 ข้อ 4.6 ระบุให้ผู้รับจ้างจัดทำเอกสารด้านกฎหมาย เช่น PDPA และข้อตกลงที่เกี่ยวข้อง แต่สำหรับโครงการขนาดนี้ ยังควรกำหนดให้ชัดเจนขึ้น เช่น
ควรมี Data Processing Agreement ระหว่าง สดช. กับผู้รับจ้างหลัก และระหว่างผู้รับจ้างหลักกับ sub-processor โดยระบุคำสั่งในการประมวลผล ข้อห้ามใช้ข้อมูลนอกวัตถุประสงค์ มาตรการ security การแจ้งเหตุละเมิดข้อมูล การช่วยรองรับสิทธิของเจ้าของข้อมูล การลบหรือคืนข้อมูลเมื่อสิ้นสุดสัญญา และการขออนุมัติ sub-processor
ควรมี Data Sharing Agreement สำหรับการเชื่อมข้อมูลกับ DGA, ThaiD, ฐานข้อมูลนักศึกษา หน่วยงานภายนอก หรือ platform อื่นที่มีสถานะเป็น controller-to-controller
นอกจากนี้ สดช. ควรจัดทำ RoPA ตามมาตรา 39 สำหรับกิจกรรมสำคัญ เช่น ลงทะเบียน ตรวจสิทธิ ใช้งาน AI เก็บ prompt/file/chat history วิเคราะห์พฤติกรรม เรียนออนไลน์ ออก e-certificate, call center, กิจกรรมประชาสัมพันธ์ และเชื่อมต่อผู้ให้บริการภายนอก
ผู้รับจ้างหลักและผู้รับจ้างช่วงก็ควรมี processor record ตามมาตรา 40 เพื่อแสดงว่าประมวลผลข้อมูลอะไร ในนามของใคร เพื่ออะไร และมีมาตรการรักษาความมั่นคงปลอดภัยอย่างไร
Security และเหตุละเมิดข้อมูลส่วนบุคคล
TOR มีข้อกำหนดด้าน security หลายข้อ เช่น RBAC, Audit Trail, encryption, backup/recovery, access control, penetration test, vulnerability scan, attack simulation และมาตรฐาน ISO/IEC 27001, 27701, 27017 และ 27018 สำหรับ cloud
ข้อกำหนดเหล่านี้สอดคล้องกับมาตรา 37 ของ PDPA และกฎหมายลำดับรองเรื่องมาตรการรักษาความมั่นคงปลอดภัย
แต่ TOR ควรเพิ่ม Personal Data Breach Response Procedure ให้ชัดเจน โดยกำหนดขั้นตอนแจ้งเหตุจาก sub-processor ไปยังผู้รับจ้างหลัก จากผู้รับจ้างหลักไปยัง สดช. และจาก สดช. ไปยังสำนักงาน PDPC และเจ้าของข้อมูลในกรณีที่กฎหมายกำหนด
ระบบนี้มีผู้ใช้จำนวนมาก ผู้ให้บริการหลายชั้น และข้อมูลพฤติกรรมจำนวนมาก การตอบสนองเหตุละเมิดข้อมูลจึงต้องเตรียมไว้ก่อนเกิดเหตุ ไม่ใช่รอให้เกิดเหตุแล้วค่อยวางกระบวนการ
สิทธิของเจ้าของข้อมูลและระยะเวลาเก็บรักษา
TOR หน้า 6 ข้อ 4.2.1.7(3) กำหนดให้ระบบลบหรือทำลายข้อมูลเมื่อผู้ใช้ต้องการใช้สิทธิตาม PDPA ซึ่งเป็นจุดเริ่มต้นที่ดี
แต่ PDPA ไม่ได้มีเพียงสิทธิลบข้อมูล เจ้าของข้อมูลยังมีสิทธิรับทราบข้อมูล สิทธิเข้าถึง สิทธิขอสำเนา สิทธิแก้ไข สิทธิคัดค้าน สิทธิขอระงับการใช้ สิทธิถอน consent และสิทธิร้องเรียน
โดยเฉพาะเมื่อระบบมีการวิเคราะห์พฤติกรรมและประเมินความเสี่ยงรายบุคคล เจ้าของข้อมูลควรรู้ได้ว่าข้อมูลใดถูกใช้ และมีช่องทางขอทบทวนหรือแก้ไขหากข้อมูลไม่ถูกต้อง
อีกประเด็นหนึ่งคือ ข้อมูลบางประเภทอาจลบไม่ได้ทันที เช่น log file ข้อมูลที่ต้องเก็บตามกฎหมายจัดซื้อจัดจ้าง หรือข้อมูลที่จำเป็นต่อการตรวจสอบการใช้สิทธิ โครงการจึงควรมี Retention Schedule และ Deletion Exception Matrix แยกตามประเภทข้อมูล
DPO ของ สดช. และผู้รับจ้าง
TOR หน้า 28 ข้อ 11.3.4 ระบุให้ cloud provider มี DPO ตาม PDPA ซึ่งเป็นข้อกำหนดที่ดี แต่ยังไม่ควรหยุดเพียงเท่านี้
โครงการนี้มี สดช. เป็นหน่วยงานรัฐและเป็นผู้ควบคุมข้อมูลส่วนบุคคลหลัก จึงควรมี DPO เข้าร่วมตั้งแต่ช่วงออกแบบและกำกับโครงการ
ผู้รับจ้างหลักที่ประมวลผลข้อมูลประชาชนจำนวนมากและเกี่ยวข้องกับการติดตามพฤติกรรมการใช้ AI ก็ควรมี DPO หรืออย่างน้อย privacy lead ที่มีบทบาทชัดเจน
DPO ควรตรวจ lawful basis, Privacy Notice, RoPA, DPA/DSA, data flow, DPIA, sub-processor, cross-border transfer, security และการรองรับสิทธิของเจ้าของข้อมูล ไม่ใช่มีชื่อไว้เฉพาะในเอกสาร
ข้อมูลส่วนบุคคลในกิจกรรมเกี่ยวกับ Call Center, Survey, กิจกรรม และประชาสัมพันธ์
ข้อมูลส่วนบุคคลของโครงการไม่ได้อยู่เฉพาะในระบบลงทะเบียนและแพลตฟอร์ม AI
TOR หน้า 16 ข้อ 4.4.4 กำหนดให้มี Call Center & Help Desk รับเรื่องร้องเรียนผ่านโทรศัพท์ อีเมล และ chatbot พร้อมกำหนดให้จัดเก็บข้อมูลผู้ใช้บริการอย่างปลอดภัยตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล
TOR หน้า 17 ข้อ 4.5 กำหนดเรื่องการสำรวจความพึงพอใจ ความเชื่อมั่น และผลกระทบเชิงเศรษฐกิจและสังคม
TOR หน้า 9-16 ยังมีเรื่องกิจกรรมประชาสัมพันธ์ งานแถลงข่าว bootcamp, competition, การถ่ายภาพ วิดีโอ live stream และการเผยแพร่ผ่านเว็บไซต์หรือ social media
กิจกรรมเหล่านี้ต้องมี Privacy Notice, lawful basis, retention และมาตรการจำกัดการเข้าถึงข้อมูลเช่นเดียวกับข้อมูลในระบบหลัก
ข้อมูลบุคลากรของผู้รับจ้าง เช่น ชื่อ อายุ เลขประจำตัวประชาชน การศึกษา และประสบการณ์ ที่ใช้ยื่นประกอบข้อเสนอ ก็เป็นข้อมูลส่วนบุคคลเช่นกัน ผู้รับจ้างควรแจ้งบุคลากรของตน และ สดช. ควรกำหนดมาตรการเก็บรักษาและระยะเวลาเก็บอย่างเหมาะสม
ข้อห้ามใช้ข้อมูลนอกวัตถุประสงค์ต้องครอบคลุมผู้ให้บริการ AI
TOR หน้า 17 ข้อ 4.10 กำหนดว่าผู้รับจ้างต้องไม่นำข้อมูลที่เกิดขึ้นในโครงการและข้อมูลของผู้ร่วมโครงการไปใช้เพื่อกิจการอื่นนอกเหนือจากที่ได้รับอนุญาตจาก สดช.
TOR หน้า 30 ข้อ 14 และหน้า 31 ข้อ 15 ยังระบุเรื่องความลับ กรรมสิทธิ์ของข้อมูล และความรับผิดหากละเมิดกฎหมายคุ้มครองข้อมูลส่วนบุคคล
ข้อเหล่านี้ดีในเชิงสัญญา แต่ในบริบท AI ควรเขียนให้ชัดว่า ห้ามนำ prompt, uploaded file, chat history, usage data, metadata, telemetry, assessment result และ dashboard data ไปใช้เพื่อ train model, fine-tune model, improve product, commercial analytics, benchmarking, advertising หรือส่งต่อให้บุคคลภายนอก โดยไม่มีฐานกฎหมายและไม่ได้รับอนุญาตอย่างชัดเจน
ความเสี่ยงของ AI ไม่ใช่แค่ข้อมูลถูกเปิดเผย แต่รวมถึงการนำข้อมูลไปใช้ต่อในระบบหรือโมเดลโดยเจ้าของข้อมูลไม่รู้และตรวจสอบได้ยาก
จาก AI Passport สู่ AI ที่ประชาชนเชื่อมั่นได้
เนื่องจากโครงการ TH-AI Passport นี้ทาง สดช. คาดหวังว่าจะช่วยให้ประชาชนไทยเข้าถึง Generative AI ลดความเหลื่อมล้ำทางดิจิทัล และสร้าง AI literacy ในวงกว้าง
แต่ในอีกด้านหนึ่ง โครงการนี้อาจกลายเป็นจุดรวมข้อมูลพฤติกรรมการใช้ AI ของประชาชนจำนวนมาก
ดังนั้น PDPA จึงไม่ควรถูกมองเป็นภาระของโครงการ แต่ควรถูกใช้เป็นกรอบสร้างความเชื่อมั่นว่า การใช้ AI ผ่านโครงการของรัฐจะไม่ทำให้ข้อมูลของประชาชนถูกติดตาม วิเคราะห์ ส่งต่อ หรือใช้ซ้ำเกินวัตถุประสงค์
หลักที่ควรใช้กับโครงการนี้คือ มีฐานกฎหมายชัดเจน ใช้ข้อมูลเท่าที่จำเป็น ได้สัดส่วน ตรวจสอบได้ และปลอดภัย
คำถามของโครงการนี้จึงไม่ใช่เพียงว่า “รัฐจะทำให้ประชาชนใช้ AI ได้มากขึ้นอย่างไร”
แต่คือ “รัฐจะทำให้ประชาชนใช้ AI ได้ โดยยังมั่นใจว่าข้อมูลส่วนบุคคลของตนได้รับการคุ้มครองอย่างเพียงพอหรือไม่”
เอกสาร TOR TH-AI Passport >>ดาวน์โหลด<<
ดร.อุดมธิปก ไพรเกษตร
นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย
ผู้ก่อตั้งสื่อ PDPA Thailand
ดร.อุดมธิปก ไพรเกษตร
นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย
ผู้ก่อตั้งสื่อ PDPA Thailand
เมื่อ 2 สัปดาห์ก่อนผมได้รับ TOR โครงการ TH-AI Passport จากเพื่อนท่านหนึ่ง แล้วให้ช่วยวิเคราะห์ในประเด็นที่เกี่ยวข้องกับ PDPA แม้ว่าจะเคยให้ความเห็นเรื่อง TH-AI Passport ในฐานะอนุกรรมการด้านการสื่อสาร โทรคมนาคม และเทคโนโลยีสารสนเทศ สภาผู้บริโภค เมื่อวันที่ 3 มิถุนายน ซึ่งท่านสามารถอ่านได้จาก https://www.tcc.or.th/free-ai-criteria/
และเมื่ออ่าน TOR โครงการ TH-AI Passport อย่างละเอียด ผมพบว่าโครงการมีการประมวลผลข้อมูลส่วนบุคคลขนาดใหญ่เพราะนอกจากมีการยืนยันตัวตนผ่านระบบรัฐ การใช้เลขประจำตัวประชาชนแล้วยังมีการจัดเก็บข้อมูลพฤติกรรมการใช้ Generative AI การประเมินทักษะ การออกใบรับรองดิจิทัล การจัดเก็บ log file การใช้ cloud และการเชื่อมต่อกับผู้ให้บริการ AI หลายราย
สิ่งที่ TOR เขียนไว้ดีแล้ว
TOR ฉบับนี้มีหลายข้อที่เป็นจุดเริ่มต้นที่ดีด้านการคุ้มครองข้อมูลส่วนบุคคล เช่น
มีการระบุชัดว่าโครงการเกี่ยวข้องกับข้อมูลส่วนบุคคลและข้อมูลพฤติกรรมการใช้งาน AI กำหนดให้ข้อมูลถูกจัดเก็บและประมวลผลภายในประเทศ ห้ามโอนข้อมูลออกนอกประเทศโดยไม่ได้รับอนุญาต กำหนดให้ขอความยินยอมตาม PDPA และให้ลบหรือทำลายข้อมูลเมื่อเจ้าของข้อมูลใช้สิทธิตามกฎหมาย
นอกจากนี้ TOR ยังระบุเรื่อง RBAC, Audit Trail, encryption, backup, access control, vulnerability scan, penetration test และมาตรฐานด้าน cloud เช่น ISO/IEC 27001, 27701, 27017 และ 27018 รวมถึงกำหนดให้ cloud provider มี DPO และห้ามผู้รับจ้างนำข้อมูลไปใช้เพื่อกิจการอื่น
ข้อกำหนดเหล่านี้ถือเป็นจุดเริ่มต้นที่ดี แต่ยังมีหลายประเด็นที่ควรเพิ่มเติมเพื่อไม่ให้ PDPA เป็นเพียงข้อกำหนดด้านเทคนิคหรือเอกสารประกอบโครงการเท่านั้น
สิ่งที่ควรเพิ่ม
แม้โครงการจะจัดซื้อจัดจ้างไปแล้ว หากสามารถเพิ่มเอกสารและกลไกด้าน PDPA เพิ่มเติมบางส่วนได้ จะช่วยลดความเสี่ยงและทำให้โครงการเป็นต้นแบบของรัฐในการใช้ AI อย่างรับผิดชอบ
สิ่งที่ควรมีเพิ่มเติม ได้แก่
- Role Mapping ระบุผู้ควบคุมข้อมูล ผู้ประมวลผลข้อมูล ผู้ควบคุมร่วม และผู้ประมวลผลช่วง
- Lawful Basis Mapping แยกตามกิจกรรม ไม่ใช้ consent รวมทุกเรื่อง
- Privacy Notice ตามมาตรา 23 แบบแยกตามกิจกรรม
- Data Processing Agreement ระหว่าง สดช. กับผู้รับจ้าง และข้อตกลงกับ sub-processor
- Data Sharing Agreement หรือ Joint Controller Arrangement กับหน่วยงานที่เชื่อมข้อมูล
- DPIA และ AI Risk Assessment ก่อนเปิดระบบจริง
- Cross-border Transfer Assessment สำหรับ AI vendor, cloud, public cloud และ remote access
- RoPA ตามมาตรา 39 และ processor record ตามมาตรา 40
- DPO Governance ทั้งฝั่ง สดช. ผู้รับจ้างหลัก และ vendor สำคัญ
- Data Subject Rights Workflow รองรับสิทธิของเจ้าของข้อมูลครบถ้วน
- Retention, Deletion และ Anonymization Schedule แยกตามประเภทข้อมูล
- AI Data Governance Policy สำหรับ prompt, uploaded file, chat history, AI Agent, model training และ usage analytics
เนื่องจากผมไม่ได้เกี่ยวข้องกับการดำเนินโครงการ จึงไม่อาจยืนยันได้ว่าโครงการได้จัดทำเอกสารหรือกลไกเหล่านี้แล้วหรือไม่ หากดำเนินการไว้แล้วควรมีการชี้แจงเพิ่มเติมเพื่อสร้างความเชื่อมั่นให้กับประชาชนและสังคม
หัวใจของ TOR นี้คือข้อ 2.2 และข้อมูลพฤติกรรมการใช้ AI
TOR หน้า 2 ข้อ 2.2 ระบุว่าโครงการต้องส่งเสริมให้ข้อมูลส่วนบุคคลและข้อมูลพฤติกรรมการใช้งาน Generative AI ถูกจัดเก็บและประมวลผลภายในประเทศไทย และยกระดับการคุ้มครองข้อมูลส่วนบุคคลตามกฎหมายไทยให้สูงสุด
ข้อความนี้สำคัญ เพราะทำให้เห็นว่าโครงการนี้มีการประมวลผลข้อมูลส่วนบุคคลอย่างชัดเจน ไม่ใช่เพียงข้อมูลลงทะเบียนทั่วไป แต่รวมถึงข้อมูลพฤติกรรมการใช้ AI ซึ่งอาจสะท้อนความสนใจ ความรู้ ความสามารถ คำถาม ปัญหา เอกสารที่ผู้ใช้ส่งเข้าไป และรูปแบบการใช้งาน AI ของแต่ละบุคคล
หากข้อมูลเหล่านี้เชื่อมโยงกลับไปยังบุคคลได้ จึงเป็นข้อมูลส่วนบุคคลตามมาตรา 6 ของ PDPA ดังนั้น TOR ทั้งฉบับจึงควรถูกพิจารณาภายใต้กรอบ PDPA ตั้งแต่ต้น
คำถามที่ต้องตอบให้ได้คือ ใครเป็นผู้ควบคุมข้อมูล ใครเป็นผู้ประมวลผล ใช้ฐานกฎหมายใด แจ้งเจ้าของข้อมูลอย่างไร ส่งต่อให้ใคร เก็บไว้ที่ไหน และลบเมื่อไร
ใครเป็นผู้ควบคุมข้อมูล ใครเป็นผู้ประมวลผล
เมื่อเทียบกับมาตรา 6 ของ PDPA สดช. เป็นผู้ควบคุมข้อมูลส่วนบุคคลหลักของโครงการ เพราะเป็นผู้กำหนดวัตถุประสงค์ กลุ่มเป้าหมาย ระบบที่ต้องมี ข้อมูลที่ต้องจัดเก็บ รายงานที่ต้องส่งมอบ และเงื่อนไขการใช้ข้อมูล
ส่วนผู้รับจ้างหลักควรถูกมองเป็นผู้ประมวลผลข้อมูลส่วนบุคคล เพราะทำหน้าที่พัฒนา จัดหา และให้บริการแพลตฟอร์มตาม TOR เช่น ระบบลงทะเบียน ระบบ Generative AI ระบบการเรียนรู้ dashboard, call center, cloud, security และระบบรายงานผล
อย่างไรก็ตาม โครงการยังเกี่ยวข้องกับหลายฝ่าย เช่น DGA, ThaiD, ฐานข้อมูลนักศึกษา ผู้ให้บริการ Generative AI, cloud, public cloud, call center, survey, ผู้จัดกิจกรรม และ social media platform
ฝ่ายเหล่านี้อาจมีสถานะต่างกัน บางรายเป็น sub-processor บางรายเป็นผู้ควบคุมข้อมูลอิสระ และบางกรณีอาจเป็นผู้ควบคุมข้อมูลร่วม จึงควรมี Role Mapping ที่ชัดเจนก่อนเริ่มประมวลผลข้อมูลจริง
ระบบลงทะเบียน เลขบัตรประชาชน และการยืนยันตัวตนรัฐ
TOR หน้า 5 ข้อ 4.2.1.1 กำหนดให้ระบบลงทะเบียนและยืนยันตัวตนเชื่อมกับระบบทางรัฐของ DGA หรือ ThaiD และตรวจสอบเลขประจำตัวประชาชนเพื่อป้องกันการใช้สิทธิซ้ำ
เรื่องนี้ไม่ใช่เพียงประเด็นเทคนิค เพราะเลขประจำตัวประชาชนเป็นข้อมูลส่วนบุคคลที่มีความเสี่ยงสูง หากรั่วไหลอาจนำไปสู่การสวมรอยหรือความเสียหายอื่นได้
การเชื่อมกับระบบรัฐยังอาจเกี่ยวข้องกับการเก็บข้อมูลจากแหล่งอื่นตามมาตรา 25 และการเปิดเผยหรือใช้ข้อมูลระหว่างหลายหน่วยงานตามมาตรา 27 จึงควรมีข้อตกลงการเชื่อมโยงข้อมูลที่ชัดเจน
นอกจากนี้ การตรวจสอบสิทธิหรือการระงับสิทธิควรมีความโปร่งใส มีช่องทางให้เจ้าของข้อมูลตรวจสอบและแก้ไข หากข้อมูลผิดพลาดจนทำให้ถูกปฏิเสธสิทธิในการใช้บริการ
Consent ไม่ใช่ฐานกฎหมายเดียวของโครงการ
TOR หน้า 5 ข้อ 4.2.1.7(1) กำหนดให้ขอความยินยอมจากผู้ใช้งานก่อนจัดเก็บและประมวลผลข้อมูลส่วนบุคคล โดยเฉพาะข้อมูลพฤติกรรมการใช้งาน
ข้อนี้สะท้อนว่า TOR ให้ความสำคัญกับ PDPA แต่ในเชิงกฎหมายต้องระวังว่า consent ไม่ใช่ฐานกฎหมายเดียวของทุกกิจกรรม
PDPA มาตรา 24 ยังมีฐานกฎหมายอื่น เช่น การปฏิบัติตามกฎหมาย ภารกิจเพื่อประโยชน์สาธารณะ การใช้อำนาจรัฐ การปฏิบัติตามสัญญา หรือประโยชน์โดยชอบด้วยกฎหมาย
กิจกรรมอย่างการลงทะเบียน ตรวจสิทธิ ยืนยันตัวตน ป้องกันสิทธิซ้ำ จัดสรรเครดิต AI จัดทำรายงานผลโครงการ รักษาความปลอดภัย และเก็บ log อาจไม่ควรใช้ consent เป็นฐานหลักทั้งหมด
หากไม่ consent แล้วใช้บริการไม่ได้เลย ความยินยอมนั้นอาจถูกตั้งคำถามว่าเป็นอิสระเพียงพอหรือไม่ ทางที่เหมาะสมคือจัดทำ Lawful Basis Mapping แยกตามกิจกรรม และใช้ consent เฉพาะกิจกรรมที่ไม่จำเป็นต่อบริการหลัก เช่น การใช้ภาพประชาสัมพันธ์รายบุคคล หรือการนำข้อมูลไปใช้พัฒนาโมเดล
Privacy Notice ต้องมาก่อน
เมื่อ TOR ระบุว่ามีการเก็บข้อมูลส่วนบุคคลและข้อมูลพฤติกรรมการใช้ AI โครงการต้องจัดทำ Privacy Notice ตามมาตรา 23 ให้ครบถ้วน
Privacy Notice ไม่ควรเขียนกว้าง ๆ ว่า “เก็บข้อมูลเพื่อดำเนินโครงการ” แต่ควรแยกตามกิจกรรม เช่น การลงทะเบียน การตรวจสิทธิ การใช้ Generative AI การเก็บ prompt, file upload, chat history, การสร้าง AI Agent, การเรียนออนไลน์ การออก e-certificate, dashboard, call center, survey, กิจกรรมประชาสัมพันธ์ และการเก็บ log file
แต่ละกิจกรรมควรระบุให้ชัดว่าเก็บข้อมูลอะไร เพื่ออะไร ใช้ฐานกฎหมายใด เปิดเผยให้ใคร เก็บไว้นานเท่าไร ส่งออกนอกประเทศหรือไม่ เจ้าของข้อมูลมีสิทธิอะไร และติดต่อ DPO ได้อย่างไร
นี่คือความแตกต่างระหว่างการมีเพียง consent checkbox กับการมีระบบคุ้มครองข้อมูลส่วนบุคคลจริง
การใช้ Generative AI และข้อมูลพฤติกรรมที่มีความเสี่ยงสูง
TOR หน้า 6 ข้อ 4.2.2.1 กำหนดให้แพลตฟอร์มรองรับ Generative AI หลายผลิตภัณฑ์ การสนทนา การ upload file การจัดการประวัติสนทนา การสร้าง AI Agent และการสร้างภาพ
ในมุม PDPA ส่วนนี้เป็นพื้นที่ความเสี่ยงสูง เพราะ prompt อาจมีข้อมูลส่วนบุคคลของผู้ใช้หรือบุคคลอื่น ไฟล์ที่ upload อาจมีข้อมูลลูกค้า นักเรียน ผู้ป่วย พนักงาน หรือคู่สัญญา ส่วน chat history อาจสะท้อนความสนใจ ความคิด ปัญหาสุขภาพ ปัญหาทางการเงิน หรือประเด็นละเอียดอ่อนของผู้ใช้
แม้ TOR ไม่ได้ตั้งใจเก็บข้อมูลอ่อนไหว แต่การเปิดให้ประชาชน upload file และพิมพ์ prompt ทำให้มีโอกาสที่ข้อมูลอ่อนไหวตามมาตรา 26 จะเข้าสู่ระบบโดยไม่ตั้งใจ
TOR จึงควรกำหนดมาตรการเฉพาะ เช่น คำเตือนก่อนใช้ระบบ ข้อห้ามนำข้อมูลอ่อนไหวเข้าระบบ data loss prevention, masking หรือ redaction, retention limit และข้อห้ามไม่ให้ vendor ใช้ข้อมูลผู้ใช้เพื่อ train model โดยไม่มีฐานกฎหมายที่ชัดเจน
Dashboard การวิเคราะห์รายบุคคล และ DPIA
TOR หน้า 7 ข้อ 4.2.2.3 และ 4.2.2.4 กำหนดให้ระบบประเมินภัยคุกคาม การใช้งานผิดกฎหมาย การใช้งานผิดวัตถุประสงค์ และความเสี่ยงรายบุคคลหรือรายกลุ่ม รวมถึงวิเคราะห์พฤติกรรมและแนวโน้มการใช้งาน
TOR หน้า 8 ข้อ 4.2.4.6 ยังระบุเรื่องรายงานผลการใช้งาน AI รายงานพฤติกรรมการใช้งาน แนวโน้มรายบุคคลและกลุ่มผู้ใช้งาน รวมถึงรายงานภัยคุกคามหรือความเสี่ยงในการใช้ Generative AI
นี่ไม่ใช่เพียง dashboard จำนวนผู้ใช้ แต่เป็นการวิเคราะห์พฤติกรรมของผู้ใช้ในระดับรายบุคคลและรายกลุ่ม
โครงการจึงต้องตอบให้ได้ว่า การวิเคราะห์ระดับรายบุคคลจำเป็นแค่ไหน ใช้ข้อมูลแบบ aggregate แทนได้หรือไม่ ใครเข้าถึง dashboard ได้ มี audit trail หรือไม่ และหากมีการระงับสิทธิจากข้อมูลหรือคะแนนความเสี่ยง เจ้าของข้อมูลมีช่องทางทบทวนอย่างไร
ในเชิง PDPA ประเด็นนี้เกี่ยวข้องกับมาตรา 23, 24, 37, 39 และ 41 และควรทำ DPIA หรือ Data Protection Impact Assessment แม้ PDPA ไทยยังไม่ได้กำหนด DPIA เป็นหน้าที่ทั่วไปโดยตรง เพราะโครงการที่ใช้ AI กับประชาชนจำนวนมากและมีการวิเคราะห์พฤติกรรมรายบุคคลควรจัดอยู่ในกลุ่มความเสี่ยงสูง
Data Localization ในยุค Generative AI
TOR ระบุเรื่อง Data Localization หลายจุด เช่น ข้อ 2.2 กำหนดให้ข้อมูลส่วนบุคคลและข้อมูลพฤติกรรมการใช้ AI อยู่ในประเทศไทย ข้อ 4.2.1.7(2) กำหนดให้ข้อมูลลงทะเบียนจัดเก็บและประมวลผลในประเทศ และข้อ 11.3.8 กำหนดเรื่องศูนย์ข้อมูลหลักในประเทศไทย
หลักการนี้สอดคล้องกับมาตรา 28 และ 29 ของ PDPA เรื่องการส่งหรือโอนข้อมูลส่วนบุคคลไปต่างประเทศ
อย่างไรก็ตาม ในโลก Generative AI คำถามไม่จบที่ฐานข้อมูลลงทะเบียนอยู่ในไทย แต่ต้องถามต่อว่า prompt ถูกส่งไปที่ไหน ไฟล์ที่ upload ประมวลผลที่ใด chat history, metadata และ telemetry อยู่ประเทศใด มี sub-processor ต่างประเทศหรือไม่ และมี remote access จากต่างประเทศหรือไม่
ดังนั้น Data Localization ควรถูกตรวจสอบในหลายมิติ ทั้งที่เก็บข้อมูล สถานที่ประมวลผล สถานที่เข้าถึงข้อมูล ผู้รับจ้างช่วง และการโอนข้อมูลข้ามประเทศ
DPA, DSA, RoPA และ Processor Record
TOR หน้า 17 ข้อ 4.6 ระบุให้ผู้รับจ้างจัดทำเอกสารด้านกฎหมาย เช่น PDPA และข้อตกลงที่เกี่ยวข้อง แต่สำหรับโครงการขนาดนี้ ยังควรกำหนดให้ชัดเจนขึ้น เช่น
ควรมี Data Processing Agreement ระหว่าง สดช. กับผู้รับจ้างหลัก และระหว่างผู้รับจ้างหลักกับ sub-processor โดยระบุคำสั่งในการประมวลผล ข้อห้ามใช้ข้อมูลนอกวัตถุประสงค์ มาตรการ security การแจ้งเหตุละเมิดข้อมูล การช่วยรองรับสิทธิของเจ้าของข้อมูล การลบหรือคืนข้อมูลเมื่อสิ้นสุดสัญญา และการขออนุมัติ sub-processor
ควรมี Data Sharing Agreement สำหรับการเชื่อมข้อมูลกับ DGA, ThaiD, ฐานข้อมูลนักศึกษา หน่วยงานภายนอก หรือ platform อื่นที่มีสถานะเป็น controller-to-controller
นอกจากนี้ สดช. ควรจัดทำ RoPA ตามมาตรา 39 สำหรับกิจกรรมสำคัญ เช่น ลงทะเบียน ตรวจสิทธิ ใช้งาน AI เก็บ prompt/file/chat history วิเคราะห์พฤติกรรม เรียนออนไลน์ ออก e-certificate, call center, กิจกรรมประชาสัมพันธ์ และเชื่อมต่อผู้ให้บริการภายนอก
ผู้รับจ้างหลักและผู้รับจ้างช่วงก็ควรมี processor record ตามมาตรา 40 เพื่อแสดงว่าประมวลผลข้อมูลอะไร ในนามของใคร เพื่ออะไร และมีมาตรการรักษาความมั่นคงปลอดภัยอย่างไร
Security และเหตุละเมิดข้อมูลส่วนบุคคล
TOR มีข้อกำหนดด้าน security หลายข้อ เช่น RBAC, Audit Trail, encryption, backup/recovery, access control, penetration test, vulnerability scan, attack simulation และมาตรฐาน ISO/IEC 27001, 27701, 27017 และ 27018 สำหรับ cloud
ข้อกำหนดเหล่านี้สอดคล้องกับมาตรา 37 ของ PDPA และกฎหมายลำดับรองเรื่องมาตรการรักษาความมั่นคงปลอดภัย
แต่ TOR ควรเพิ่ม Personal Data Breach Response Procedure ให้ชัดเจน โดยกำหนดขั้นตอนแจ้งเหตุจาก sub-processor ไปยังผู้รับจ้างหลัก จากผู้รับจ้างหลักไปยัง สดช. และจาก สดช. ไปยังสำนักงาน PDPC และเจ้าของข้อมูลในกรณีที่กฎหมายกำหนด
ระบบนี้มีผู้ใช้จำนวนมาก ผู้ให้บริการหลายชั้น และข้อมูลพฤติกรรมจำนวนมาก การตอบสนองเหตุละเมิดข้อมูลจึงต้องเตรียมไว้ก่อนเกิดเหตุ ไม่ใช่รอให้เกิดเหตุแล้วค่อยวางกระบวนการ
สิทธิของเจ้าของข้อมูลและระยะเวลาเก็บรักษา
TOR หน้า 6 ข้อ 4.2.1.7(3) กำหนดให้ระบบลบหรือทำลายข้อมูลเมื่อผู้ใช้ต้องการใช้สิทธิตาม PDPA ซึ่งเป็นจุดเริ่มต้นที่ดี
แต่ PDPA ไม่ได้มีเพียงสิทธิลบข้อมูล เจ้าของข้อมูลยังมีสิทธิรับทราบข้อมูล สิทธิเข้าถึง สิทธิขอสำเนา สิทธิแก้ไข สิทธิคัดค้าน สิทธิขอระงับการใช้ สิทธิถอน consent และสิทธิร้องเรียน
โดยเฉพาะเมื่อระบบมีการวิเคราะห์พฤติกรรมและประเมินความเสี่ยงรายบุคคล เจ้าของข้อมูลควรรู้ได้ว่าข้อมูลใดถูกใช้ และมีช่องทางขอทบทวนหรือแก้ไขหากข้อมูลไม่ถูกต้อง
อีกประเด็นหนึ่งคือ ข้อมูลบางประเภทอาจลบไม่ได้ทันที เช่น log file ข้อมูลที่ต้องเก็บตามกฎหมายจัดซื้อจัดจ้าง หรือข้อมูลที่จำเป็นต่อการตรวจสอบการใช้สิทธิ โครงการจึงควรมี Retention Schedule และ Deletion Exception Matrix แยกตามประเภทข้อมูล
DPO ของ สดช. และผู้รับจ้าง
TOR หน้า 28 ข้อ 11.3.4 ระบุให้ cloud provider มี DPO ตาม PDPA ซึ่งเป็นข้อกำหนดที่ดี แต่ยังไม่ควรหยุดเพียงเท่านี้
โครงการนี้มี สดช. เป็นหน่วยงานรัฐและเป็นผู้ควบคุมข้อมูลส่วนบุคคลหลัก จึงควรมี DPO เข้าร่วมตั้งแต่ช่วงออกแบบและกำกับโครงการ
ผู้รับจ้างหลักที่ประมวลผลข้อมูลประชาชนจำนวนมากและเกี่ยวข้องกับการติดตามพฤติกรรมการใช้ AI ก็ควรมี DPO หรืออย่างน้อย privacy lead ที่มีบทบาทชัดเจน
DPO ควรตรวจ lawful basis, Privacy Notice, RoPA, DPA/DSA, data flow, DPIA, sub-processor, cross-border transfer, security และการรองรับสิทธิของเจ้าของข้อมูล ไม่ใช่มีชื่อไว้เฉพาะในเอกสาร
ข้อมูลส่วนบุคคลในกิจกรรมเกี่ยวกับ Call Center, Survey, กิจกรรม และประชาสัมพันธ์
ข้อมูลส่วนบุคคลของโครงการไม่ได้อยู่เฉพาะในระบบลงทะเบียนและแพลตฟอร์ม AI
TOR หน้า 16 ข้อ 4.4.4 กำหนดให้มี Call Center & Help Desk รับเรื่องร้องเรียนผ่านโทรศัพท์ อีเมล และ chatbot พร้อมกำหนดให้จัดเก็บข้อมูลผู้ใช้บริการอย่างปลอดภัยตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล
TOR หน้า 17 ข้อ 4.5 กำหนดเรื่องการสำรวจความพึงพอใจ ความเชื่อมั่น และผลกระทบเชิงเศรษฐกิจและสังคม
TOR หน้า 9-16 ยังมีเรื่องกิจกรรมประชาสัมพันธ์ งานแถลงข่าว bootcamp, competition, การถ่ายภาพ วิดีโอ live stream และการเผยแพร่ผ่านเว็บไซต์หรือ social media
กิจกรรมเหล่านี้ต้องมี Privacy Notice, lawful basis, retention และมาตรการจำกัดการเข้าถึงข้อมูลเช่นเดียวกับข้อมูลในระบบหลัก
ข้อมูลบุคลากรของผู้รับจ้าง เช่น ชื่อ อายุ เลขประจำตัวประชาชน การศึกษา และประสบการณ์ ที่ใช้ยื่นประกอบข้อเสนอ ก็เป็นข้อมูลส่วนบุคคลเช่นกัน ผู้รับจ้างควรแจ้งบุคลากรของตน และ สดช. ควรกำหนดมาตรการเก็บรักษาและระยะเวลาเก็บอย่างเหมาะสม
ข้อห้ามใช้ข้อมูลนอกวัตถุประสงค์ต้องครอบคลุมผู้ให้บริการ AI
TOR หน้า 17 ข้อ 4.10 กำหนดว่าผู้รับจ้างต้องไม่นำข้อมูลที่เกิดขึ้นในโครงการและข้อมูลของผู้ร่วมโครงการไปใช้เพื่อกิจการอื่นนอกเหนือจากที่ได้รับอนุญาตจาก สดช.
TOR หน้า 30 ข้อ 14 และหน้า 31 ข้อ 15 ยังระบุเรื่องความลับ กรรมสิทธิ์ของข้อมูล และความรับผิดหากละเมิดกฎหมายคุ้มครองข้อมูลส่วนบุคคล
ข้อเหล่านี้ดีในเชิงสัญญา แต่ในบริบท AI ควรเขียนให้ชัดว่า ห้ามนำ prompt, uploaded file, chat history, usage data, metadata, telemetry, assessment result และ dashboard data ไปใช้เพื่อ train model, fine-tune model, improve product, commercial analytics, benchmarking, advertising หรือส่งต่อให้บุคคลภายนอก โดยไม่มีฐานกฎหมายและไม่ได้รับอนุญาตอย่างชัดเจน
ความเสี่ยงของ AI ไม่ใช่แค่ข้อมูลถูกเปิดเผย แต่รวมถึงการนำข้อมูลไปใช้ต่อในระบบหรือโมเดลโดยเจ้าของข้อมูลไม่รู้และตรวจสอบได้ยาก
จาก AI Passport สู่ AI ที่ประชาชนเชื่อมั่นได้
เนื่องจากโครงการ TH-AI Passport นี้ทาง สดช. คาดหวังว่าจะช่วยให้ประชาชนไทยเข้าถึง Generative AI ลดความเหลื่อมล้ำทางดิจิทัล และสร้าง AI literacy ในวงกว้าง
แต่ในอีกด้านหนึ่ง โครงการนี้อาจกลายเป็นจุดรวมข้อมูลพฤติกรรมการใช้ AI ของประชาชนจำนวนมาก
ดังนั้น PDPA จึงไม่ควรถูกมองเป็นภาระของโครงการ แต่ควรถูกใช้เป็นกรอบสร้างความเชื่อมั่นว่า การใช้ AI ผ่านโครงการของรัฐจะไม่ทำให้ข้อมูลของประชาชนถูกติดตาม วิเคราะห์ ส่งต่อ หรือใช้ซ้ำเกินวัตถุประสงค์
หลักที่ควรใช้กับโครงการนี้คือ มีฐานกฎหมายชัดเจน ใช้ข้อมูลเท่าที่จำเป็น ได้สัดส่วน ตรวจสอบได้ และปลอดภัย
คำถามของโครงการนี้จึงไม่ใช่เพียงว่า “รัฐจะทำให้ประชาชนใช้ AI ได้มากขึ้นอย่างไร”
แต่คือ “รัฐจะทำให้ประชาชนใช้ AI ได้ โดยยังมั่นใจว่าข้อมูลส่วนบุคคลของตนได้รับการคุ้มครองอย่างเพียงพอหรือไม่”
เอกสาร TOR TH-AI Passport >>ดาวน์โหลด<<
ดร.อุดมธิปก ไพรเกษตร
นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย
ผู้ก่อตั้งสื่อ PDPA Thailand
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.