สารบัญ
- เกิดอะไรขึ้นกับการแบ่งปันข้อมูลดิจิทัลภาครัฐ
- ทำไมข้อมูลสุขภาพจึงเป็นจุดที่ต้องระวัง
- ปัญหาไม่ได้อยู่ที่ Consent อย่างเดียว
- BDI เป็น Processor หรืออาจมีบทบาทมากกว่านั้น
- ผลกระทบต่อประเทศไทยและบริษัทเอกชนที่รับงานรัฐ
- สิ่งที่หน่วยงานควรทำต่อ
- มุมมองผู้เชี่ยวชาญ
- แหล่งอ้างอิง
เกิดอะไรขึ้นกับการแบ่งปันข้อมูลดิจิทัลภาครัฐ
ประเทศไทยกำลังเดินหน้าให้หน่วยงานของรัฐสามารถแบ่งปัน แลกเปลี่ยน และเชื่อมโยงข้อมูลผ่านระบบกลาง โดยระเบียบสำนักนายกรัฐมนตรีว่าด้วยการแบ่งปันข้อมูลดิจิทัล พ.ศ. 2569 มีผลใช้บังคับแล้ว และกำหนดกรอบการดำเนินงานสำหรับหน่วยงานรัฐ รวมถึงชุดข้อมูลที่เกี่ยวข้องกับการจัดการภัยพิบัติและสถานการณ์ฉุกเฉิน
ข้อมูลที่อยู่ในภาคผนวกมีจำนวน 118 ชุด และ BDI หรือสถาบันข้อมูลขนาดใหญ่ มีบทบาทเป็นศูนย์กลางในการรองรับการเชื่อมโยงข้อมูลของหน่วยงานรัฐ
เหตุผลในเชิงนโยบายเข้าใจได้ไม่ยาก
เมื่อเกิดน้ำท่วม ไฟป่า หรือภัยพิบัติ เจ้าหน้าที่ไม่ควรต้องเริ่มจากศูนย์ด้วยการถามใหม่ว่าใครอยู่ตรงไหน ใครเป็นผู้ป่วยติดเตียง หรือใครเป็นกลุ่มเปราะบาง หากข้อมูลที่จำเป็นสามารถนำมาใช้ได้อย่างถูกต้องและรวดเร็ว การช่วยเหลือประชาชนก็มีโอกาสตรงจุดมากขึ้น
แต่ปัญหาคือ “ข้อมูลที่มีประโยชน์” กับ “ข้อมูลที่สามารถนำไปใช้ได้โดยไม่มีเงื่อนไข” เป็นคนละเรื่องกัน
และนี่คือจุดที่ PDPA เข้ามาเกี่ยวข้อง
ทำไมข้อมูลสุขภาพจึงเป็นจุดที่ต้องระวัง
ข้อมูลสุขภาพ เช่น ประวัติการรักษา โรคประจำตัว ผลตรวจทางการแพทย์ หรือข้อมูลเกี่ยวกับความพิการ อยู่ในกลุ่มข้อมูลส่วนบุคคลที่มีความอ่อนไหวตามมาตรา 26 ของ PDPA
ความหมายง่าย ๆ คือ ข้อมูลประเภทนี้ต้องได้รับการดูแลอย่างเข้มงวดกว่าข้อมูลทั่วไป
หลายคนเห็นคำว่า “ภัยพิบัติ” แล้วอาจคิดทันทีว่า ถ้าเป็นการช่วยชีวิตประชาชน ก็น่าจะส่งข้อมูลได้ทั้งหมด
ในทางกฎหมายไม่ควรคิดแบบนั้น
สิ่งที่ต้องถามก่อนคือ ฐานทางกฎหมายสำหรับการเก็บ ใช้ หรือเปิดเผยข้อมูลคืออะไร มีอำนาจตามกฎหมายอื่นรองรับหรือไม่ วัตถุประสงค์ที่ใช้ข้อมูลตรงกับวัตถุประสงค์ที่หน่วยงานแจ้งไว้หรือไม่ และข้อมูลที่ส่งไป “จำเป็น” มากน้อยแค่ไหน
พูดง่าย ๆ คือ ไม่ใช่เพียงถามว่า
“ส่งได้ไหม?”
แต่ต้องถามว่า
“ส่งข้อมูลอะไร ส่งให้ใคร ส่งไปเพื่ออะไร และต้องส่งมากแค่ไหน?”
ปัญหาไม่ได้อยู่ที่ Consent อย่างเดียว
หนึ่งในประเด็นที่คนอ่านข่าว PDPA มักเข้าใจผิด คือเห็นคำว่า “ไม่มี Consent” แล้วสรุปทันทีว่า “ผิด PDPA”
ความจริงซับซ้อนกว่านั้น
กฎหมายไม่ได้กำหนดว่าการประมวลผลข้อมูลส่วนบุคคลทุกกรณีต้องอาศัยความยินยอมเป็นทางเลือกเดียว หน่วยงานของรัฐอาจมีฐานกฎหมายอื่นรองรับในบางกรณีได้ แต่ฐานนั้นต้องตรวจสอบให้ตรงกับกิจกรรมจริงและข้อกฎหมายที่ใช้บังคับ
ยิ่งเป็นข้อมูลตามมาตรา 26 ยิ่งต้องดูเงื่อนไขเฉพาะอย่างละเอียด
ดังนั้น ประเด็นของการแบ่งปันข้อมูลดิจิทัลภาครัฐจึงไม่ควรลดรูปเหลือเพียง “ขอ Consent หรือไม่ขอ Consent”
หัวใจจริงอยู่ที่การพิสูจน์ให้ได้ว่า การแบ่งปันข้อมูลครั้งนั้นมีฐานทางกฎหมายที่รองรับ มีวัตถุประสงค์ชัดเจน และใช้ข้อมูลเท่าที่จำเป็น
รู้จักคำนี้ก่อน
Data Mapping
แผนที่ของข้อมูลในองค์กร บอกว่าข้อมูลมาจากไหน อยู่ที่ใคร ถูกส่งต่อไปที่ไหน และใครสามารถเข้าถึงได้
RoPA
เอกสารที่บันทึกกิจกรรมการประมวลผลข้อมูลส่วนบุคคลขององค์กร เพื่อให้รู้ว่าองค์กรกำลังเก็บ ใช้ หรือเปิดเผยข้อมูลอะไรและด้วยเหตุผลใด
DPIA
การประเมินผลกระทบด้านการคุ้มครองข้อมูลส่วนบุคคลก่อนเริ่มกิจกรรมที่มีความเสี่ยงสูง
DSA หรือ Data Sharing Agreement
ข้อตกลงระหว่างฝ่ายที่แบ่งปันข้อมูล เพื่อกำหนดว่าแบ่งปันอะไร ใช้เพื่ออะไร ใครเข้าถึงได้ เก็บไว้นานเท่าไร และเกิดเหตุผิดพลาดแล้วใครต้องรับผิดชอบ
สิ่งเหล่านี้ไม่ใช่คำศัพท์สวย ๆ สำหรับใส่ในเอกสารราชการ แต่เป็นเครื่องมือที่ช่วยตอบคำถามสำคัญว่า “ข้อมูลของประชาชนกำลังเดินทางไปทางไหน”
แล้ว BDI เป็น Processor หรืออาจมีบทบาทมากกว่านั้น?
นี่อาจเป็นประเด็นที่สำคัญที่สุดของเรื่อง
ตามหลัก PDPA ผู้ควบคุมข้อมูล คือฝ่ายที่มีอำนาจตัดสินใจเกี่ยวกับการเก็บ ใช้ หรือเปิดเผยข้อมูล ส่วนผู้ประมวลผลข้อมูลทำงานตามคำสั่งหรือในนามของผู้ควบคุมข้อมูล
แต่ในโลกจริง การติดป้ายว่าองค์กรหนึ่งเป็น “Processor” ไม่ได้ทำให้มันกลายเป็น Processor โดยอัตโนมัติ
ต้องดูว่าองค์กรนั้นทำอะไรจริง
ถ้า BDI เพียงรับข้อมูลตามคำสั่งของหน่วยงานเจ้าของข้อมูลและประมวลผลตามขอบเขตที่กำหนด บทบาทแบบ Processor ก็อาจมีเหตุผล
แต่ถ้าในทางปฏิบัติมีอำนาจกำหนดว่าข้อมูลจะถูกนำไปใช้อย่างไร เลือกวิธีการประมวลผลที่มีนัยสำคัญ คัดกรองข้อมูล หรือมีอำนาจตัดสินใจในสาระสำคัญ การวิเคราะห์บทบาททางกฎหมายก็อาจต้องละเอียดกว่านั้น
ไทยโพสต์รายงานประเด็นนี้โดยอ้างบทความของผู้อำนวยการฝ่ายสื่อสารองค์กรของ PDPC ซึ่งตั้งข้อสังเกตถึงความแตกต่างระหว่างบทบาทที่กำหนดไว้กับบทบาทที่เกิดขึ้นจริงในการบริหารข้อมูล
นี่คือเหตุผลว่า ทำไมการทำสัญญา DPA อย่างเดียวอาจไม่เพียงพอในบางโครงการ
เพราะสัญญาจะเขียนว่าอย่างไรเป็นเรื่องหนึ่ง
แต่พฤติกรรมจริงของแต่ละฝ่ายเป็นอีกเรื่องหนึ่ง
ผลกระทบต่อประเทศไทย: เรื่องนี้ไม่ได้หยุดอยู่ที่หน่วยงานรัฐ
ผลกระทบที่น่าจับตาคือ เรื่องนี้จะลากไปถึงบริษัทเอกชนจำนวนมากที่รับงานด้านเทคโนโลยีจากภาครัฐ ไม่ว่าจะเป็นบริษัทพัฒนาระบบ ผู้ดูแลฐานข้อมูล ผู้ให้บริการ Cloud ผู้รับจ้างทำ API ผู้ดูแลระบบสำรองข้อมูล หรือบริษัทที่ทำ Data Integration ให้หน่วยงานราชการ
เดิมบริษัทเหล่านี้อาจมองว่าตัวเองเป็นเพียง “ผู้รับจ้างด้าน IT” แต่เมื่อระบบของบริษัทเป็นส่วนหนึ่งของการรับ ส่ง หรือประมวลผลข้อมูลประชาชน บริษัทก็ไม่ควรมองเรื่องข้อมูลส่วนบุคคลเป็นเพียงข้อกำหนดทางเทคนิคใน TOR อีกต่อไป
ตัวอย่างง่าย ๆ คือ หน่วยงานรัฐสั่งให้บริษัทเชื่อมฐานข้อมูลโรงพยาบาลเข้ากับระบบกลาง
ฝ่าย IT อาจมองโจทย์เพียงว่า API ต้องเชื่อมได้ภายในกำหนด
แต่ฝ่ายกฎหมายจะต้องถามเพิ่มว่า ข้อมูลที่ส่งคืออะไร มีข้อมูลสุขภาพอยู่หรือไม่ ใครเป็นผู้กำหนดว่าจะส่งฟิลด์ใด ใครอนุมัติการเข้าถึง มีการเก็บสำเนาไว้หรือไม่ Log ถูกเก็บนานเท่าใด และบริษัทสามารถนำข้อมูลไปใช้เพื่อทดสอบระบบได้หรือไม่
คำถามเหล่านี้มีผลกับทั้งสัญญา ระบบ และความรับผิดชอบเมื่อเกิดเหตุผิดพลาด
อีกเรื่องที่ไม่ควรมองข้ามคือ “ความเชื่อมั่นของประชาชน”
ประชาชนจำนวนมากไม่ได้สนใจว่าใครเป็น Controller หรือ Processor เขาสนใจเพียงคำถามง่าย ๆ ว่า
“ทำไมรัฐถึงมีข้อมูลสุขภาพของฉันหลายหน่วยงาน?”
และ
“ถ้าข้อมูลหลุด ใครรับผิดชอบ?”
นี่จึงเป็นเรื่องของกฎหมายควบคู่กับเรื่องความเชื่อมั่นต่อภาครัฐ
ในอีกด้านหนึ่ง การแบ่งปันข้อมูลก็มีประโยชน์จริง หากออกแบบอย่างถูกต้อง เพราะประเทศไทยจะมีโอกาสลดการกรอกข้อมูลซ้ำ ลดการทำงานแบบต่างคนต่างเก็บ และตอบสนองต่อเหตุการณ์ฉุกเฉินได้เร็วขึ้น แนวคิดเรื่องการเชื่อมโยงข้อมูลจึงไม่ได้ขัดกับ PDPA โดยตัวมันเอง
ปัญหาคือ “การเชื่อมข้อมูลโดยไม่ออกแบบความรับผิดชอบให้ชัดเจน”
ดังนั้น มุมที่ควรจับตาในประเทศไทยต่อจากนี้ไม่ใช่เพียงว่า 118 ชุดข้อมูลจะเชื่อมได้ทันหรือไม่ แต่คือหน่วยงานและผู้รับจ้างจะสามารถตอบคำถามเรื่องสิทธิ อำนาจ และความรับผิดชอบของแต่ละฝ่ายได้หรือไม่
สิ่งที่ควรทำต่อ
หน่วยงานที่อยู่ในขอบเขตควรเริ่มจากการทำรายการข้อมูลจริง ไม่ใช่เริ่มจากการแก้เอกสาร
- ตรวจว่า 118 ชุดข้อมูลใดอยู่ในความรับผิดชอบของหน่วยงาน และชุดใดมีข้อมูลส่วนบุคคลหรือข้อมูลสุขภาพ
- ทำ Data Mapping ให้เห็นเส้นทางตั้งแต่ต้นทางถึง BDI รวมถึงระบบของผู้รับจ้างภายนอกที่เกี่ยวข้อง
- ทบทวน RoPA และประเมินว่ากิจกรรมดังกล่าวมีความเสี่ยงสูงจนควรทำ DPIA หรือไม่
- ตรวจบทบาทของแต่ละฝ่ายใหม่ว่าใครเป็น Controller, Joint Controller หรือ Processor โดยดูจากการทำงานจริง ไม่ใช่ดูจากชื่อที่อยู่บนสัญญาเพียงอย่างเดียว
- ตรวจ Privacy Notice และข้อตกลงแบ่งปันข้อมูลให้สอดคล้องกับวัตถุประสงค์จริง รวมถึงกำหนดสิทธิการเข้าถึง การเก็บรักษา การรักษาความปลอดภัย และความรับผิดชอบเมื่อเกิดเหตุผิดพลาด
สำหรับกรอบเวลา เรื่องนี้ไม่ควรรอจนถึงวันสุดท้าย เพราะระเบียบที่มีผลใช้บังคับกำหนดให้หน่วยงานที่เกี่ยวข้องดำเนินการเชื่อมโยงและนำส่งข้อมูลภายในกรอบ 60 วัน และหากไม่พร้อม ต้องมีการแจ้งภายใน 15 วันตามเงื่อนไขที่กำหนด
มุมมองผู้เชี่ยวชาญ
“ผมมองว่าเรื่องนี้ไม่ใช่ปัญหาว่า ‘รัฐจะแชร์ข้อมูลได้หรือไม่ได้’ แต่ต้องตอบให้ชัดก่อนว่า ข้อมูลอะไร ใครเป็นคนตัดสินใจ และเอาไปใช้ทำอะไร เพราะถ้าตอบสามเรื่องนี้ไม่ได้ ต่อให้ระบบเชื่อมกันสำเร็จ ปัญหาทางกฎหมายก็ยังไม่จบ”
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
แหล่งอ้างอิง
ไทยโพสต์ (Thaipost) — บทความ “ศึกสองกฎหมาย! เมื่อ ‘ระเบียบรัฐบาล 2569’ ชนกับ ‘PDPA’ ภาครัฐต้องทำอะไรบ้าง” เผยแพร่ 9 กันยายน 2569 โดยบทความระบุผู้เขียนจากสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)
กระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม (MDES) — แหล่งรวบรวมกฎหมายของกระทรวง ซึ่งระบุ “ระเบียบสำนักนายกรัฐมนตรี ว่าด้วยการแบ่งปันข้อมูลดิจิทัล พ.ศ. 2569” ไว้ในหมวดกฎหมายที่เกี่ยวข้องกับสถาบันข้อมูลขนาดใหญ่
ตรวจสอบรายการกฎหมายจากกระทรวงดิจิทัลฯ
ประชาชาติธุรกิจ — รายงานรายละเอียดของระเบียบ รวมถึงกรอบ 60 วันและเงื่อนไขการแจ้งกรณีไม่พร้อม
อ่านรายละเอียดระเบียบและกรอบเวลา
คำอธิบายศัพท์สั้น
PDPA = กฎหมายคุ้มครองข้อมูลส่วนบุคคลของไทย
BDI = สถาบันข้อมูลขนาดใหญ่ ซึ่งมีบทบาทด้านระบบกลางสำหรับการแบ่งปันข้อมูลดิจิทัลของภาครัฐ
DPIA = การประเมินผลกระทบด้านการคุ้มครองข้อมูลส่วนบุคคลก่อนทำกิจกรรมที่มีความเสี่ยง
RoPA = เอกสารที่บันทึกว่าองค์กรเก็บ ใช้ หรือเปิดเผยข้อมูลส่วนบุคคลอะไรบ้าง
Data Mapping = การทำแผนที่ให้เห็นว่าข้อมูลมาจากไหน ไปที่ไหน และใครเข้าถึงได้
Processor = ผู้ที่ประมวลผลข้อมูลตามคำสั่งหรือในนามของผู้ควบคุมข้อมูล
Joint Controller = กรณีที่สองฝ่ายหรือมากกว่านั้นมีส่วนร่วมในการกำหนดวัตถุประสงค์หรือวิธีการประมวลผลข้อมูล
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย
หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
