บทนำ
DPO ไทยกำลังถูกมองต่างไปจากเดิม จากเดิมที่หลายองค์กรสนใจเพียงว่า “แต่งตั้งใครเป็น DPO” ร่างแนวทางของสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล หรือ PDPC ที่นำเสนอเมื่อ 7 กรกฎาคม 2569 กำลังชี้ให้เห็นอีกคำถามที่สำคัญกว่า คือ เมื่อแต่งตั้งแล้ว DPO คนนั้นมีอิสระ มีข้อมูล และมีช่องทางรายงานปัญหาถึงผู้บริหารจริงหรือไม่
ประเด็นนี้ยังอยู่ในสถานะ “ร่าง” ไม่ใช่กฎใหม่ที่ใช้แทนกฎหมายทันที แต่มีความสำคัญในทางปฏิบัติ เพราะเป็นสัญญาณว่าหน่วยงานกำกับกำลังคาดหวังให้บทบาท DPO ทำงานจริงมากกว่าการมีชื่ออยู่ในเอกสารองค์กร
DPO ไทย 2569 กำลังเปลี่ยนจาก “มีชื่อ” เป็น “ทำงานได้จริง”
ร่างแนวทาง DPO ไทยปี 2569 เน้นว่า DPO ต้องสามารถทำหน้าที่ได้อย่างเป็นอิสระ เข้าถึงข้อมูลและทรัพยากรที่จำเป็น และมีทางรายงานตรงถึงผู้บริหารระดับสูงเมื่อเกิดปัญหา จึงไม่ควรประเมินความพร้อมของ DPO จากคำสั่งแต่งตั้งเพียงใบเดียว
พูดง่าย ๆ คือ องค์กรต้องตอบให้ได้ว่า “ถ้า DPO พบความเสี่ยงจริง ๆ เขาสามารถพูดกับคนที่ตัดสินใจสูงสุดได้หรือไม่” เพราะถ้าคำตอบคือไม่ได้ การมี DPO ก็อาจไม่ช่วยให้องค์กรจัดการความเสี่ยงได้ตามที่ตั้งใจ
ใครบ้างที่ต้องแต่งตั้ง DPO ตาม PDPA
ภายใต้ PDPA มาตรา 41 การมี DPO ไม่ได้บังคับทุกองค์กร แต่กำหนดกรณีที่ผู้ควบคุมข้อมูลส่วนบุคคลหรือผู้ประมวลผลข้อมูลส่วนบุคคลต้องจัดให้มี DPO เช่น หน่วยงานของรัฐที่อยู่ในข่าย กิจกรรมที่ต้องตรวจสอบข้อมูลหรือระบบอย่างสม่ำเสมอเพราะมีข้อมูลส่วนบุคคลจำนวนมาก และกรณีที่กิจกรรมหลักเกี่ยวข้องกับข้อมูลตามมาตรา 26 ตามหลักเกณฑ์ที่เกี่ยวข้อง
- หน่วยงานรัฐบางประเภท — ต้องพิจารณาตามประกาศที่เกี่ยวข้อง
- การติดตามหรือวิเคราะห์ข้อมูลอย่างสม่ำเสมอในวงกว้าง — อาจเข้าข่ายตามหลักเกณฑ์
- การประมวลผลข้อมูลอ่อนไหวเป็นกิจกรรมหลักในวงกว้าง — ต้องพิจารณาข่ายตามกฎหมาย
- ตัวแทนขององค์กรต่างประเทศบางกรณี — ร่างแนวทางระบุให้พิจารณาเพิ่มเติม
“100,000 คน” หมายความว่าอะไร และทำไมอย่ารีบตีความว่าเป็นเส้นตาย
ตัวเลข 100,000 คนที่ถูกพูดถึงในร่างแนวทางควรถูกอ่านว่าเป็นแนวทางประกอบการพิจารณาว่าการประมวลผลอาจมีขนาดใหญ่ ไม่ใช่สูตรง่าย ๆ ว่า “ต่ำกว่า 100,000 คนไม่ต้องมี DPO และเกิน 100,000 คนต้องมี DPO ทันที”
จุดนี้สำคัญมากสำหรับธุรกิจที่กำลังทำ CRM, loyalty program, e-commerce, analytics, health-tech หรือระบบติดตามพฤติกรรม เพราะความ “ใหญ่” ของการประมวลผลไม่ได้มีแค่จำนวนคน แต่เกี่ยวกับลักษณะของการติดตาม วิเคราะห์ และความเสี่ยงของข้อมูลที่องค์กรนำมาใช้ด้วย
DPO ต้องรายงานใคร และองค์กรต้องให้อะไรบ้าง
DPO ไทยที่ทำงานจริงควรมีเวลา งบประมาณ บุคลากร เครื่องมือ และสิทธิ์เข้าถึงข้อมูลที่จำเป็นต่อการทำหน้าที่ และเมื่อเกิดปัญหาในการปฏิบัติหน้าที่ต้องมีทางรายงานไปยังผู้บริหารสูงสุดได้โดยตรง ประเด็นนี้สอดคล้องกับแนวคิดใน PDPA มาตรา 42 ที่กำหนดหน้าที่ของ DPO และหน้าที่ขององค์กรในการสนับสนุนการทำงาน
สิ่งที่องค์กรควรดูจึงไม่ใช่แค่ “ใครเป็น DPO” แต่ต้องดูสายบังคับบัญชาด้วย เช่น DPO ต้องขออนุมัติจากคนที่เป็นเจ้าของระบบก่อนจึงจะตรวจสอบระบบนั้นได้หรือไม่ หรือ DPO มีสิทธิ์เข้าถึงข้อมูลที่จำเป็นต่อการตรวจสอบจริงหรือไม่
ใครเสี่ยงเกิด Conflict of Interest เมื่อเป็น DPO
ร่างแนวทางเตือนเรื่องผลประโยชน์ทับซ้อน โดยเฉพาะบุคคลที่มีหน้าที่กำหนดวัตถุประสงค์หรือวิธีการประมวลผลข้อมูลอยู่แล้ว เช่น CEO, COO, CFO, หัวหน้าการตลาด หรือหัวหน้า HR เพราะคนกลุ่มนี้อาจต้องเป็นทั้งผู้ตัดสินใจและผู้ตรวจสอบการตัดสินใจของตัวเอง
Conflict of Interest = ผลประโยชน์ทับซ้อน หมายถึงสถานการณ์ที่บุคคลต้องตรวจสอบงานที่ตัวเองเป็นผู้ตัดสินใจหรือเป็นเจ้าของกระบวนการนั้นอยู่ด้วย จึงเกิดคำถามเรื่องความเป็นกลาง
สำหรับฝ่าย IT ก็ไม่ได้แปลว่า “คน IT ห้ามเป็น DPO” เสมอไป ร่างแนวทางแยกความแตกต่างระหว่างเจ้าหน้าที่ IT ที่ทำหน้าที่สนับสนุนทั่วไป กับผู้บริหาร IT ที่มีอำนาจตัดสินใจว่าระบบใดจะเก็บข้อมูลอะไร หรือจะรวมข้อมูลไว้ที่ใด ซึ่งรายหลังอาจเกิดความขัดกันของบทบาทได้
DPO กับ ROPA, DPIA และเหตุละเมิดข้อมูล ต้องเชื่อมกันอย่างไร
DPO ไทยที่มีประสิทธิภาพไม่ควรทำงานแยกเป็นห้องเดียวกับเอกสาร PDPA แต่ควรเชื่อมกับระบบงานจริงขององค์กร ตั้งแต่การทำ ROPA การประเมินโครงการใหม่ การใช้สิทธิของเจ้าของข้อมูล ไปจนถึงการรับมือเหตุละเมิดข้อมูล เพราะข้อมูลที่ DPO ใช้ตรวจสอบต้องมาจากการทำงานจริง ไม่ใช่เอกสารที่ทำเสร็จเพียงครั้งเดียวแล้วไม่อัปเดต
ROPA = Record of Processing Activities คือ บันทึกว่าบริษัทเก็บ ใช้ เปิดเผยข้อมูลอะไร เพื่ออะไร ใครเกี่ยวข้อง และข้อมูลไปอยู่ที่ไหน
DPIA = Data Protection Impact Assessment คือ การประเมินผลกระทบด้านการคุ้มครองข้อมูลก่อนทำโครงการหรือระบบที่อาจมีความเสี่ยงสูง
Data Breach = เหตุละเมิดข้อมูลส่วนบุคคล เช่น ข้อมูลถูกเปิดเผยโดยไม่ตั้งใจ ระบบถูกเจาะ หรือข้อมูลถูกส่งไปยังผู้ที่ไม่มีสิทธิ์ได้รับข้อมูล
จุดเสี่ยงของธุรกิจไทย: มี DPO แต่ DPO ไม่สามารถ “หยุด” ปัญหาได้
จุดที่น่าจับตาที่สุดของร่างแนวทางฉบับนี้จึงไม่ใช่รายชื่อผู้ที่ควรเป็น DPO แต่คือ “โครงสร้างการตัดสินใจ” ขององค์กร เพราะเมื่อ DPO พบความเสี่ยงแล้ว ประเด็นสำคัญคือ DPO มีสิทธิ์ส่งเรื่องไปถึงใคร มีหลักฐานอะไรบ้าง และองค์กรตอบสนองต่อคำแนะนำอย่างไร
ถ้าผู้บริหารตัดสินใจไม่ทำตามคำแนะนำของ DPO ร่างแนวทางระบุให้มีการบันทึกเหตุผลเป็นลายลักษณ์อักษร นี่เป็นรายละเอียดเล็ก ๆ ที่มีความหมายในเชิง governance เพราะมันเปลี่ยนคำถามจาก “เราเคยมี DPO หรือไม่” เป็น “เราจัดการกับคำเตือนของ DPO อย่างไร”
DPO แบบ In-house, Outsource หรือ Group DPO ต่างกันอย่างไร
PDPA และร่างแนวทางรองรับรูปแบบการจัด DPO หลายแบบ แต่ทุกรูปแบบต้องรักษาหลักการเรื่องความเป็นอิสระ การเข้าถึง และความสามารถในการติดต่อได้จริง
- In-house DPO — เหมาะกับองค์กรที่มีระบบข้อมูลซับซ้อนและต้องการให้ DPO เข้าใจธุรกิจอย่างลึก แต่ต้องระวังไม่ให้ DPO เป็นผู้ตัดสินใจเรื่องการประมวลผลเอง
- Outsourced DPO — เหมาะกับองค์กรที่ไม่มีบุคลากรเฉพาะด้าน แต่ต้องกำหนดสิทธิ์การเข้าถึง ขอบเขตงาน ผู้ประสานงาน และขั้นตอน escalation ให้ชัด
- Group DPO — ใช้ร่วมกันในกลุ่มบริษัทได้ แต่แต่ละบริษัทต้องติดต่อ DPO ได้ง่าย และ DPO ต้องเข้าใจบริบทของแต่ละธุรกิจ
- Voluntary DPO — องค์กรที่แต่งตั้งเองแม้ไม่อยู่ในข่ายบังคับก็ควรจัดให้บทบาทและมาตรฐานการทำงานเป็นระบบ
ผลกระทบต่อประเทศไทย: เรื่องนี้ไม่ใช่แค่เรื่องของฝ่ายกฎหมาย
สำหรับประเทศไทย ผลกระทบของร่างแนวทาง DPO อยู่ที่การเปลี่ยน PDPA จาก “งานเอกสาร” ไปสู่ “งานบริหาร” มากขึ้น เมื่อองค์กรใช้ข้อมูลกับ CRM, HR, กล้องวงจรปิด, การวิเคราะห์พฤติกรรม, ระบบ AI หรือบริการบนคลาวด์มากขึ้น การทำงานของ DPO จะหลีกเลี่ยงการแตะระบบปฏิบัติการจริงได้ยากขึ้น
ในมุมธุรกิจ SME ปัญหาที่เกิดขึ้นได้ง่ายคือการตั้ง DPO แบบประหยัดที่สุด แต่ไม่ออกแบบอำนาจหรือกระบวนการให้ DPO ทำงานได้จริง เมื่อเกิดคำขอใช้สิทธิ เหตุข้อมูลรั่ว หรือการตรวจสอบภายใน จึงกลับมาพบว่าองค์กรไม่รู้ว่าข้อมูลอยู่ที่ไหน ใครเป็นคนตัดสินใจ และใครมีสิทธิ์อนุมัติการแก้ไขปัญหา
ในมุมองค์กรขนาดใหญ่ ความท้าทายจะเพิ่มขึ้นเมื่อมีหลายบริษัท หลายระบบ และหลายหน่วยงาน เพราะ DPO คนเดียวอาจต้องมองเห็นข้อมูลทั้งกลุ่ม แต่ในขณะเดียวกันต้องไม่กลายเป็นผู้มีอำนาจกำหนดวิธีใช้ข้อมูลเองจนเกิด conflict of interest
ในมุมประชาชน จุดสำคัญคือ “ติดต่อ DPO ได้จริงหรือไม่” เพราะ PDPA ไม่ได้มีไว้เฉพาะให้บริษัทเก็บเอกสาร แต่มีไว้เพื่อให้เจ้าของข้อมูลมีช่องทางใช้สิทธิและได้รับการคุ้มครองอย่างเป็นระบบ การมีชื่อ DPO อยู่ใน privacy notice แต่ไม่มีคนตอบ ไม่มีระบบส่งต่อ หรือไม่สามารถเข้าถึงหน่วยงานที่เกี่ยวข้องได้ ย่อมไม่ใช่ภาพของ data governance ที่แข็งแรง
สิ่งที่องค์กรควรตรวจตอนนี้
องค์กรควรใช้ช่วงที่แนวทางยังอยู่ในขั้นร่างเพื่อตรวจโครงสร้าง DPO ก่อน ไม่จำเป็นต้องรอให้เกิดปัญหาหรือรอวันที่มีการตรวจสอบจริง
- ตรวจว่าองค์กรเข้าข่ายต้องมี DPO ตามมาตรา 41 และประกาศที่เกี่ยวข้องหรือไม่ อย่าใช้จำนวนลูกค้าอย่างเดียวเป็นคำตอบ
- ตรวจสายรายงานของ DPO ว่าสามารถยกระดับปัญหาไปยังผู้บริหารสูงสุดได้จริงหรือไม่
- ตรวจ Conflict of Interest ว่า DPO เป็นผู้ตัดสินใจเรื่องวัตถุประสงค์หรือวิธีการประมวลผลข้อมูลเองหรือไม่
- ตรวจการเข้าถึงข้อมูล เครื่องมือ บุคลากร และเวลาที่ DPO มีอยู่จริง ไม่ใช่เฉพาะสิ่งที่ระบุในคำสั่งแต่งตั้ง
- ตรวจว่า DPO เชื่อมกับ ROPA, DPIA, การใช้สิทธิของเจ้าของข้อมูล และแผนรับมือ Data Breach หรือไม่ พร้อมเก็บหลักฐานการตัดสินใจที่สำคัญ
มุมมองผู้เชี่ยวชาญ
“เรื่องสำคัญไม่ใช่แค่มี DPO แต่คือ DPO ต้องเห็นปัญหา พูดกับคนที่ตัดสินใจได้ และมีหลักฐานว่าองค์กรรับมือกับคำเตือนนั้นอย่างไร ถ้าสามอย่างนี้ไม่มี ชื่อ DPO ก็อาจเป็นแค่ชื่อในเอกสาร”
แหล่งอ้างอิง
Tilleke & Gibbins — Thailand’s New Draft Guidance on Data Protection Officers
Mondaq — Thailand’s New Draft Guidance On Data Protection Officers
PDPC Portal — ข้อมูลการแจ้ง DPO และเงื่อนไขตามมาตรา 41
อ้างอิงกฎหมาย: พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 41 และมาตรา 42
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
