การบังคับใช้พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล (PDPA) ของประเทศไทยได้เข้าสู่ขั้นตอนที่จริงจังอย่างแท้จริง ระหว่างปี 2567 ถึง 2568 บริษัทที่มีมาตรการรักษาความปลอดภัยข้อมูลไม่เพียงพอถูกปรับโทษทางปกครองนับล้านบาท ในขณะที่ PDPC เปิดตัวระบบเฝ้าระวังอัตโนมัติ 24 ชั่วโมงที่เรียกว่า “Eagle Eye” หากบริษัทญี่ปุ่นของท่านยังคง “รอดูสถานการณ์” เกี่ยวกับการปฏิบัติตาม PDPA ถึงเวลาแล้วที่ต้องทบทวนแนวทางใหม่
PDPA คืออะไร? — ภาพรวม “GDPR ของไทย”
ข้อมูลพื้นฐาน
PDPA (พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล) ประกาศใช้ในเดือนพฤษภาคม พ.ศ. 2562 และมีผลบังคับใช้อย่างเต็มรูปแบบเมื่อวันที่ 1 มิถุนายน พ.ศ. 2565 หลังจากถูกเลื่อนออกไปสองครั้งเนื่องจากสถานการณ์โควิด-19 ปัจจุบันบังคับใช้อย่างสมบูรณ์แบบในฐานะพันธกรณีทางกฎหมาย
หน่วยงานกำกับดูแลคือ PDPC (คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล) ซึ่งรับผิดชอบการบังคับใช้ การสืบสวน และการจัดทำแนวปฏิบัติ
เปรียบเทียบสามกฎหมาย: ญี่ปุ่น / ไทย / สหภาพยุโรป
| รายการ | ญี่ปุ่น (APPI) | ไทย (PDPA) | สหภาพยุโรป (GDPR) |
|---|---|---|---|
| บังคับใช้เต็มรูปแบบ | 2548 (แก้ไข 2565) | มิถุนายน 2565 | พฤษภาคม 2561 |
| ขอบเขตนอกอาณาเขต | มี | มี | มี |
| ฐานทางกฎหมาย | ระบุวัตถุประสงค์ + ความยินยอม | 6 ฐาน (แบบ GDPR) | 6 ฐาน |
| ข้อกำหนด DPO | ไม่บังคับ | บังคับสำหรับการประมวลผลขนาดใหญ่ | บังคับในบางเงื่อนไข |
| กำหนดแจ้งการรั่วไหล | โดยทันที (ไม่มีกำหนดเวลาชัดเจน) | ภายใน 72 ชั่วโมง | ภายใน 72 ชั่วโมง |
| โทษปรับสูงสุด | 100 ล้านเยน | 5 ล้านบาท | 4% ของยอดขายทั่วโลก |
ประเด็นสำคัญ: PDPA มีโครงสร้างใกล้เคียง GDPR มากกว่า APPI ของญี่ปุ่น การปฏิบัติตามกฎหมายคุ้มครองข้อมูลของญี่ปุ่นเพียงอย่างเดียวไม่เพียงพอสำหรับ PDPA
แนวคิดหลัก 3 ประการ
ผู้ควบคุมข้อมูล (Data Controller): นิติบุคคลที่กำหนดวัตถุประสงค์และวิธีการประมวลผลข้อมูลส่วนบุคคล บริษัทลูกของญี่ปุ่นในไทยโดยทั่วไปถือเป็นผู้ควบคุมข้อมูล
ผู้ประมวลผลข้อมูล (Data Processor): นิติบุคคลที่ประมวลผลข้อมูลส่วนบุคคลในนามและตามคำสั่งของผู้ควบคุม เช่น ผู้ให้บริการไอที ผู้ให้บริการคลาวด์ บริษัทเอาท์ซอร์สด้านเงินเดือน ที่สำคัญ: ในคดีบังคับใช้ ผู้ประมวลผลถูกปรับสูงกว่าผู้ควบคุมในบางกรณี (ดูรายละเอียดด้านล่าง)
ข้อมูลที่มีความอ่อนไหว (Sensitive Data): เชื้อชาติ/ชาติพันธุ์ ความคิดเห็นทางการเมือง ความเชื่อทางศาสนา ประวัติอาชญากรรม ข้อมูลสุขภาพ ข้อมูลชีวมิติ (ลายนิ้วมือ ม่านตา) พฤติกรรมทางเพศ/รสนิยม ห้ามประมวลผลโดยค่าเริ่มต้น อนุญาตเฉพาะเมื่อมีความยินยอมอย่างชัดแจ้งหรือฐานทางกฎหมายอื่น
การบังคับใช้มาถึงแล้ว — บทเรียนจากคดีโทษปรับใหญ่
2567: โทษปรับครั้งใหญ่ครั้งแรก (7 ล้านบาท)
ในปี 2567 PDPC ได้กำหนดโทษปรับทางปกครอง 7 ล้านบาท (ประมาณ 200,000 ดอลลาร์) แก่ผู้ค้าปลีกเทคโนโลยีรายใหญ่ ซึ่งเป็นโทษสูงสุดในประวัติ PDPA ในขณะนั้น
การละเมิดหลักสามประการ:
- ไม่แต่งตั้ง DPO ทั้งที่ดำเนินการประมวลผลข้อมูลส่วนบุคคลในระดับใหญ่
- มาตรการรักษาความปลอดภัยไม่เพียงพอ ทำให้เกิดการรั่วไหลของข้อมูลส่วนบุคคล
- ไม่แจ้ง PDPC ภายใน 72 ชั่วโมง หลังพบการรั่วไหล
“ไม่รู้ว่าต้องทำ” ไม่ใช่ข้อแก้ตัวที่ใช้ได้สำหรับพันธกรณีเหล่านี้
สิงหาคม 2568: 5 คดี 8 คำสั่ง — คลื่นการบังคับใช้
ในเดือนสิงหาคม 2568 PDPC ประกาศคดีบังคับใช้พร้อมกัน 5 คดี รวม 8 คำสั่งทางปกครอง ครอบคลุมหลายภาคส่วน:
| คดี | องค์กร | โทษปรับ (บาท) | การละเมิดหลัก |
|---|---|---|---|
| คดีที่ 1 | หน่วยงานรัฐ | 153,120 | ว่าจ้างผู้ประมวลผลที่ไม่มีคุณสมบัติโดยไม่มีสัญญา ความปลอดภัยไม่เพียงพอ ข้อมูล ~200,000 รายการรั่วไหล |
| คดีที่ 1 | ผู้ให้บริการ (ผู้ประมวลผล) | 153,120 | ถูกลงโทษร่วม |
| คดีที่ 2 | โรงพยาบาลเอกชน | 1,210,000 | กำจัดเวชระเบียนไม่ถูกต้อง ข้อมูลผู้ป่วย 1,000+ รายรั่วไหล |
| คดีที่ 2 | ผู้รับจ้างทำลาย (บุคคล) | 16,940 | จัดการเวชระเบียนไม่เหมาะสม |
| คดีที่ 3 | ผู้ค้าปลีกเทคโนโลยี | 7,000,000 | ไม่แต่งตั้ง DPO มาตรการรักษาความปลอดภัยไม่เพียงพอ ไม่รายงานการรั่วไหล |
| คดีที่ 4 | บริษัทเครื่องสำอาง | 2,500,000 | มาตรการรักษาความปลอดภัยไม่เพียงพอ ไม่รายงานการรั่วไหล |
| คดีที่ 5 | ผู้ค้าปลีกของเล่น (ผู้ควบคุม) | 500,000 | กำกับดูแลระบบจองที่เอาท์ซอร์สไม่เพียงพอ |
| คดีที่ 5 | บริษัทระบบจอง (ผู้ประมวลผล) | 3,000,000 | มาตรการรักษาความปลอดภัยไม่เพียงพอบนระบบที่ประมวลผลข้อมูลปริมาณมาก |
(ที่มา: DLA Piper Privacy Matters, กันยายน 2568)
บทเรียนสำคัญ 2 ประการ
บทเรียนที่ 1: ผู้ประมวลผลถูกปรับสูงกว่าผู้ควบคุม
ในคดีที่ 5 ผู้ควบคุม (ผู้ค้าปลีกของเล่น) ถูกปรับ 500,000 บาท ขณะที่ผู้ประมวลผล (บริษัทระบบจอง) ถูกปรับ 3,000,000 บาท — มากกว่า 6 เท่า “เราแค่เป็นผู้ให้บริการ” ไม่ได้หมายความว่ารับผิดชอบน้อยกว่า
บทเรียนที่ 2: ไม่มีภาคส่วนหรือขนาดใดได้รับการยกเว้น
โรงพยาบาล บริษัทเครื่องสำอาง ผู้ค้าปลีกของเล่น หน่วยงานรัฐ — คดีปี 2568 ครอบคลุมหลายภาคส่วน “เราไม่ใช่บริษัทเทคโนโลยี” หรือ “เราไม่ได้ประมวลผลข้อมูลมาก” ไม่ใช่เหตุผลที่ใช้ได้
PDPC Eagle Eye — ยุคเฝ้าระวังอัตโนมัติ 24 ชั่วโมง
เปลี่ยนจากตั้งรับเป็นเชิงรุก
PDPC จัดตั้ง ฝ่าย Eagle Eye และใช้งาน Eagle Eye Crawler ระบบที่สแกน URL อย่างต่อเนื่องเพื่อตรวจหาสัญญาณการรั่วไหลของข้อมูลตลอด 24 ชั่วโมง รวมถึงทั้งเว็บปกติและดาร์กเว็บ PDPC ไม่ได้รอรับเรื่องร้องเรียนอีกต่อไป — หน่วยงานค้นหาการละเมิดด้วยตัวเอง
ความหมายสำหรับบริษัทญี่ปุ่น
Eagle Eye Crawler เฝ้าดูเป็นพิเศษ:
- เว็บไซต์และแอปที่ไม่มีหรือมีนโยบายความเป็นส่วนตัวไม่เพียงพอ
- ข้อมูลส่วนบุคคลที่เปิดเผยโดยไม่ตั้งใจเนื่องจากการตั้งค่าควบคุมการเข้าถึงผิดพลาด
- ข้อมูลส่วนบุคคลที่ปรากฏในชุดข้อมูลที่รั่วไหลทางออนไลน์
การมีเว็บไซต์ภาษาญี่ปุ่นไม่ได้ให้ความคุ้มครอง หากองค์กรของท่านให้บริการในประเทศไทย PDPA ใช้บังคับ
ปริมาณเรื่องร้องเรียนเพิ่มขึ้น
ศูนย์ PDPA ของ PDPC รับเรื่องร้องเรียนที่เกี่ยวกับ PDPA 2,672 เรื่อง ณ เดือนมกราคม 2569 (ประกาศใน Data Privacy Day 2569) สามประเภทการละเมิดที่พบบ่อยที่สุด: ไม่ปฏิบัติตามหลักความจำเป็นในการเก็บข้อมูล เก็บข้อมูลโดยไม่มีฐานทางกฎหมาย และใช้/เปิดเผยข้อมูลโดยไม่มีฐานทางกฎหมาย
AI × PDPA — ความเสี่ยงที่มักถูกมองข้าม
”องค์กรที่ใช้ AI มีพันธกรณีทั้งหมดของผู้ควบคุมข้อมูล”
PDPC ได้เผยแพร่แนวปฏิบัติฉบับร่างเกี่ยวกับการคุ้มครองข้อมูลส่วนบุคคลในการพัฒนาและใช้งาน AI โดยกำหนดหลักการที่ชัดเจน:
องค์กรที่ใช้ AI = ผู้ควบคุมข้อมูลที่มีพันธกรณีทั้งหมดภายใต้ PDPA
หากบริษัทของท่านป้อนข้อมูลลูกค้าหรือข้อมูลพนักงานเข้าสู่เครื่องมือ AI เช่น ChatGPT หรือ CRM อัตโนมัติ องค์กรของท่านกำลังทำหน้าที่เป็นผู้ควบคุมข้อมูลที่สั่งการให้ AI ประมวลผลข้อมูลส่วนบุคคล “AI เป็นคนทำ” ไม่ใช่ข้อแก้ตัวที่ใช้ได้
AI Vendor อยู่ตรงไหน?
ผู้ให้บริการ AI โดยทั่วไปถือเป็นผู้ประมวลผลข้อมูล อย่างไรก็ตาม หากผู้ให้บริการใช้ข้อมูลของลูกค้าเพื่อวัตถุประสงค์ของตนเอง เช่น การฝึกหรือปรับปรุงโมเดล AI อาจถูกจัดประเภทใหม่เป็นผู้ควบคุมข้อมูล สัญญากับผู้ให้บริการ AI ควรระบุอย่างชัดเจนว่าผู้ให้บริการใช้ข้อมูลของท่านอย่างไร พร้อมสนับสนุนด้วยสัญญาการประมวลผลข้อมูล (DPA)
สำหรับภาพรวมกฎระเบียบ AI ของไทย โปรดดูบทความของเราเกี่ยวกับกรอบกฎระเบียบ AI ไทย 2569
การโอนข้อมูลข้ามแดน — การส่งข้อมูลไปสำนักงานใหญ่ญี่ปุ่นปลอดภัยหรือไม่?
กฎของ PDPA เกี่ยวกับการโอนข้ามแดน
PDPA จำกัดการโอนข้อมูลส่วนบุคคลออกนอกประเทศไทย ประเทศปลายทางต้องมี “ระดับการคุ้มครองที่เพียงพอ” ตามที่ PDPC กำหนด
ณ เดือนมีนาคม 2569 PDPC ยังไม่ได้เผยแพร่รายชื่อประเทศที่ได้รับการรับรองอย่างเป็นทางการ สถานะของญี่ปุ่นยังไม่แน่นอน
ทางเลือกเชิงปฏิบัติ
มีสามแนวทางในระหว่างที่รายการการรับรองความเพียงพอยังรอดำเนินการ:
- ข้อกำหนดสัญญามาตรฐาน (SCC): ทำสัญญาที่มีข้อกำหนดที่ PDPC รับรองระหว่างองค์กรผู้ส่งและผู้รับ เป็นแนวทางที่ปฏิบัติได้จริงที่สุด
- กฎของบรรษัทที่มีผลผูกพัน (BCR): กฎภายในสำหรับการโอนข้อมูลภายในกลุ่มบริษัท เหมาะสำหรับบริษัทข้ามชาติขนาดใหญ่
- ความยินยอมอย่างชัดแจ้ง: ขอความยินยอมจากเจ้าของข้อมูลเป็นรายกรณี ไม่เหมาะกับการใช้ขนาดใหญ่
ความเสี่ยงที่บริษัทญี่ปุ่นมักมองข้าม
พื้นที่ที่มักถูกมองข้ามคือ ข้อมูลพนักงานที่ส่งไปสำนักงานใหญ่ญี่ปุ่น ข้อมูลเงินเดือน การประเมินผลงาน บันทึกการเข้างาน — หากองค์กรรวมศูนย์ข้อมูล HR ในระบบที่ตั้งอยู่ในญี่ปุ่น การโอนเหล่านั้นอยู่ภายใต้กฎการโอนข้ามแดนของ PDPA
7 สิ่งที่บริษัทญี่ปุ่นควรทำทันที
① จัดทำและเผยแพร่ประกาศความเป็นส่วนตัว (Privacy Notice)
จัดทำประกาศความเป็นส่วนตัวแยกต่างหากสำหรับลูกค้าและพนักงาน โดยระบุข้อมูลที่เก็บรวบรวม วัตถุประสงค์ ฐานทางกฎหมาย และผู้ที่ข้อมูลจะถูกโอนให้ เผยแพร่บนเว็บไซต์ แอป หรือแจกจ่ายภายใน พิจารณาจัดทำเวอร์ชันภาษาไทย
② จัดทำ ROPA (บันทึกกิจกรรมการประมวลผล)
ROPA บันทึกกิจกรรมการประมวลผลทุกอย่างที่องค์กรดำเนินการ: ข้อมูลอะไร ทำไม อย่างไร แบ่งปันกับใคร เก็บนานแค่ไหน นี่คือรากฐานของงานปฏิบัติตามกฎระเบียบอื่นๆ ทั้งหมด
③ ตรวจสอบว่าต้องแต่งตั้ง DPO หรือไม่
ต้องแต่งตั้ง DPO ภายใต้มาตรา 41 ของ PDPA หากองค์กรของท่าน:
- ประมวลผลข้อมูลส่วนบุคคลในระดับใหญ่เป็นกิจกรรมหลัก
- ประมวลผลข้อมูลที่มีความอ่อนไหวในระดับใหญ่
- ติดตามพฤติกรรมของบุคคลอย่างเป็นระบบในระดับใหญ่
หน้าที่ DPO อาจเอาท์ซอร์สให้ผู้เชี่ยวชาญภายนอก โดยต้องรับประกันความเป็นอิสระและลงทะเบียนกับ PDPC
④ จัดทำแผนรับมือการรั่วไหลของข้อมูล (กฎ 72 ชั่วโมง)
ภายใต้มาตรา 37(4) ของ PDPA องค์กรต้องแจ้ง PDPC ภายใน 72 ชั่วโมง หลังพบการรั่วไหล จัดทำแผนรับมือเหตุการณ์ล่วงหน้าที่ระบุว่าใครทำอะไรนับจากเมื่อพบการรั่วไหล
⑤ ประเมินผลกระทบ PDPA สำหรับเครื่องมือ AI
ทบทวนเครื่องมือ AI ทุกชิ้นที่ใช้ในการดำเนินงาน เช่น AI เชิงสร้างสรรค์ ระบบอัตโนมัติ CRM เครื่องมือคัดกรอง HR จากมุมมอง PDPA: ท่านป้อนข้อมูลส่วนบุคคลหรือไม่? มี DPA กับผู้ให้บริการ AI หรือไม่? ผู้ให้บริการใช้ข้อมูลของท่านเพื่อฝึกโมเดลหรือไม่?
⑥ จัดทำสัญญาการประมวลผลข้อมูล (DPA)
ผู้ให้บริการหรือผู้รับเหมาทุกรายที่ประมวลผลข้อมูลส่วนบุคคลในนามของท่านต้องครอบคลุมด้วย DPA ซึ่งรวมถึงผู้ให้บริการไอที ผู้ให้บริการคลาวด์ ผู้ประมวลผลเงินเดือน บริษัทโลจิสติกส์ คดีบังคับใช้ปี 2568 แสดงให้เห็นว่าองค์กรที่ไม่มี DPA กับผู้ประมวลผลถูกลงโทษ
⑦ จัดตั้งฐานทางกฎหมายสำหรับการโอนข้ามแดน
ตรวจสอบว่าข้อมูลส่วนบุคคลใดไหลไปสำนักงานใหญ่ญี่ปุ่น (บันทึกพนักงาน ข้อมูลลูกค้า ข้อมูลการขาย) และรับประกันว่าการไหลแต่ละครั้งมีฐานทางกฎหมาย โดยปกติผ่าน SCC การจัดทำแผนที่ข้อมูลเป็นจุดเริ่มต้น
คำถามที่พบบ่อย
คำถาม: เรามีพนักงาน 20 คน PDPA ใช้บังคับกับเราหรือไม่?
ใช้บังคับ ต่างจาก APPI ของญี่ปุ่น PDPA ไม่มีเกณฑ์ขนาด องค์กรใดๆ ที่ประมวลผลข้อมูลส่วนบุคคลในประเทศไทยถูกครอบคลุม
คำถาม: เราปฏิบัติตาม APPI ของญี่ปุ่น เพียงพอสำหรับ PDPA หรือไม่?
ไม่เพียงพอ PDPA มีโครงสร้างใกล้เคียง GDPR มากกว่า ข้อกำหนดสำคัญที่แตกต่างจาก APPI ได้แก่ การแต่งตั้ง DPO (สำหรับผู้ประมวลผลขนาดใหญ่) การแจ้งการรั่วไหลภายใน 72 ชั่วโมง และการระบุฐานทางกฎหมายเฉพาะ
คำถาม: บทบาท DPO สามารถเอาท์ซอร์สให้บริษัทภายนอกได้หรือไม่?
ได้ หน้าที่ DPO อาจดำเนินการโดยผู้เชี่ยวชาญภายนอก DPO ต้องมีความเชี่ยวชาญเพียงพอด้านกฎหมายคุ้มครองข้อมูล อยู่ในตำแหน่งที่เป็นอิสระ และลงทะเบียนกับ PDPC
คำถาม: เราจัดการข้อมูลบริษัทลูกไทยในระบบสำนักงานใหญ่ญี่ปุ่น มีปัญหาหรือไม่?
ถือเป็นการโอนข้อมูลข้ามแดนที่อยู่ภายใต้ข้อจำกัดของ PDPA ณ เดือนมีนาคม 2569 ญี่ปุ่นยังไม่ได้รับการรับรองความเพียงพอจาก PDPC ดังนั้นท่านต้องมีฐานทางกฎหมายทางเลือก ซึ่งปฏิบัติได้จริงที่สุดคือ Standard Contractual Clauses
คำถาม: โทษปรับสูงสุดภายใต้ PDPA คือ 5 ล้านบาทใช่ไหม?
เพดานโทษปรับทางปกครองคือ 5 ล้านบาท แต่นั่นไม่ใช่ทั้งหมด โทษทางอาญา (สูงสุด 1 ล้านบาท และ/หรือจำคุกไม่เกิน 1 ปี) ใช้กับความผิดบางประเภทที่เกี่ยวข้องกับข้อมูลที่มีความอ่อนไหว ความรับผิดทางแพ่งสำหรับความเสียหายจริง — บวกค่าเสียหายเชิงลงโทษสูงสุดสองเท่าของความเสียหายจริง — ก็อาจถูกกำหนดได้เช่นกัน
บทสรุป: หน้าต่างของการ “รอดูสถานการณ์” ได้ปิดลงแล้ว
ผ่านคลื่นการบังคับใช้ปี 2567–2568 และการใช้งานการเฝ้าระวังอย่างต่อเนื่องของ Eagle Eye PDPC ได้ส่งสัญญาณที่ชัดเจน: องค์กรที่ไม่ปฏิบัติตามกฎกลายเป็นเป้าหมายของการบังคับใช้
สำหรับบริษัทญี่ปุ่น สี่ลำดับความสำคัญเร่งด่วนที่สุดคือ: ① เผยแพร่ประกาศความเป็นส่วนตัว ② จัดทำ ROPA ③ กำหนดขั้นตอนรับมือการรั่วไหลภายใน 72 ชั่วโมง และ ④ สร้างฐานทางกฎหมายสำหรับการโอนข้ามแดนไปญี่ปุ่น
เราให้คำแนะนำด้านการปฏิบัติตาม PDPA จากมุมมองของทั้งกฎหมายญี่ปุ่นและไทย รวมถึงการร่างประกาศความเป็นส่วนตัว การจัดตั้ง DPO การจัดโครงสร้างการโอนข้ามแดน และการประเมินความเสี่ยงเครื่องมือ AI กรุณาติดต่อเราได้อย่างอิสระ
บทความนี้มีวัตถุประสงค์เพื่อให้ข้อมูลทั่วไปเกี่ยวกับระบบกฎหมายของประเทศไทย และไม่ถือเป็นคำแนะนำทางกฎหมายภายใต้กฎหมายไทย สำหรับกรณีเฉพาะ กรุณาปรึกษาผู้เชี่ยวชาญที่มีใบอนุญาตทนายความไทย สำนักงานของเราทำงานร่วมกับทนายความไทยของ JTJB International Lawyers