PDPA และการปฏิบัติตามกฎหมาย AI ในไทย: คู่มือองค์กรปี 2026

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล (PDPA) ของไทย มีผลบังคับใช้เต็มรูปแบบตั้งแต่มิถุนายน 2565 สองปีผ่านมา องค์กรส่วนใหญ่ได้จัดการข้อกำหนดที่ชัดเจน ได้แก่ แบนเนอร์คุกกี้ แบบฟอร์มยินยอม และกระบวนการคำร้องจากเจ้าของข้อมูล

แต่ระบบ AI นำเสนอความท้าทายที่แตกต่างออกไปโดยพื้นฐาน เมื่อระบบ AI ประมวลผลข้อมูลส่วนบุคคล ไม่ว่าจะเป็นการบริการลูกค้า การตรวจจับการฉ้อโกง การวิเคราะห์ทางการแพทย์ หรือการคัดกรอง HR การปฏิบัติตาม PDPA ไม่สามารถทำได้ด้วยแบนเนอร์ยินยอมเพียงอย่างเดียว แต่ต้องการ การรับประกันทางสถาปัตยกรรม ที่ฝังอยู่ในวิธีที่ระบบ AI ให้เหตุผล จัดเก็บ และดำเนินการบนข้อมูล

คู่มือนี้อธิบายสิ่งที่ PDPA กำหนดให้กับระบบ AI จุดที่การใช้งานส่วนใหญ่ขาดพร่อง และวิธีที่สถาปัตยกรรม Constitutional AI แก้ไขความต้องการเหล่านี้ในเชิงโครงสร้าง

สิ่งที่ PDPA กำหนดให้กับระบบ AI

ฐานกฎหมายสำหรับการประมวลผล

ภายใต้มาตรา 19 ของ PDPA การประมวลผลข้อมูลส่วนบุคคลใดๆ ต้องมีฐานกฎหมาย สำหรับระบบ AI ฐานที่เกี่ยวข้องที่สุดได้แก่

• ความยินยอม (มาตรา 19(1)): เจ้าของข้อมูลได้ให้ความยินยอมอย่างชัดแจ้ง ซึ่งต้องเป็นการเฉพาะเจาะจง ได้รับข้อมูลเพียงพอ และสามารถถอนได้
• ความจำเป็นตามสัญญา (มาตรา 19(3)): การประมวลผลจำเป็นสำหรับการปฏิบัติตามสัญญา
• ประโยชน์ที่ชอบด้วยกฎหมาย (มาตรา 19(6)): ประโยชน์ที่ชอบด้วยกฎหมายของผู้ควบคุม โดยสมดุลกับสิทธิ์ของเจ้าของข้อมูล

ช่องว่างการปฏิบัติตาม AI: ระบบ AI หลายระบบประมวลผลข้อมูลส่วนบุคคลภายใต้ "ประโยชน์ที่ชอบด้วยกฎหมาย" โดยไม่บันทึกการประเมินประโยชน์ที่ชอบด้วยกฎหมาย (LIA) หรือการทดสอบความสมดุล หากระบบ AI ตัดสินใจอัตโนมัติที่กระทบต่อบุคคล (การอนุมัติสินเชื่อ การคัดกรองการจ้างงาน) นี้อาจไม่ผ่านมาตรฐานประโยชน์ที่ชอบด้วยกฎหมายหากไม่มีเอกสารชัดเจน

การลดข้อมูลให้น้อยที่สุด

มาตรา 22 ของ PDPA กำหนดให้ข้อมูลส่วนบุคคลที่ประมวลผลต้อง "เพียงพอ เกี่ยวข้อง และจำกัดเฉพาะที่จำเป็น" ชุดข้อมูลการฝึกอบรม AI และคลังข้อมูลการปฏิบัติงานมักละเมิดหลักการนี้โดยการรักษา:

• บันทึกการสนทนาที่เกินกว่าที่จำเป็นสำหรับการให้บริการ
• ข้อมูลโปรไฟล์ที่ละเอียดกว่าที่การตัดสินใจต้องการ
• ข้อมูลจากเจ้าของข้อมูลที่ได้ขอลบแล้ว

สิทธิ์การอธิบายการตัดสินใจอัตโนมัติ

ภายใต้มาตรา 33 ของ PDPA เจ้าของข้อมูลมีสิทธิ์ขอคำอธิบายการตัดสินใจที่กระทำโดยการประมวลผลอัตโนมัติเพียงอย่างเดียว ซึ่งมีผลกระทบโดยตรงต่อระบบ AI ที่:

• อนุมัติหรือปฏิเสธใบสมัคร
• ให้คะแนนความน่าเชื่อถือทางเครดิต
• กรองผู้สมัครงาน
• จัดลำดับความสำคัญคำขอบริการลูกค้า

ข้อกำหนดการปฏิบัติตาม: คุณต้องสามารถอธิบายเป็นคำที่เจ้าของข้อมูลเข้าใจได้ว่าทำไมระบบ AI ถึงตัดสินใจนี้โดยเฉพาะ ไม่ใช่การอธิบายทั่วไปว่าโมเดลทำงานอย่างไร

การเก็บข้อมูลและการลบ

มาตรา 22 ของ PDPA กำหนดให้ข้อมูลส่วนบุคคลเก็บรักษาได้เฉพาะตราบเท่าที่จำเป็น สำหรับระบบ AI สิ่งนี้สร้างความท้าทายเฉพาะ: การเก็บข้อมูลการฝึกอบรม vs. การเก็บข้อมูลการปฏิบัติงาน vs. การเก็บบันทึกการอนุมาน เป็นสามไทม์ไลน์ที่แตกต่างกันซึ่งต้องจัดการอย่างอิสระ

ช่องว่างการปฏิบัติตาม PDPA ทั่วไปในระบบ AI

ช่องว่าง 1: การไหลของข้อมูลที่มองไม่เห็น

การปรับใช้ AI ส่วนใหญ่ใช้ API ของ LLM ของบุคคลที่สาม (OpenAI, Anthropic, Google) เมื่อข้อมูลส่วนบุคคลถูกส่งไปยัง API เหล่านี้:

• ข้อมูลออกจากเขตอำนาจของไทย (การถ่ายโอนข้ามพรมแดน)
• มาตรา 28 ของ PDPA กำหนดให้ประเทศปลายทางต้องมีมาตรฐานการคุ้มครองที่เพียงพอหรือมีการป้องกันที่เหมาะสม
• การปรับใช้ส่วนใหญ่ขาดเอกสารของการถ่ายโอนข้ามพรมแดนนี้

ช่องว่าง 2: ไม่มีเส้นทางการตรวจสอบสำหรับการตัดสินใจอัตโนมัติ

เมื่อระบบ AI ปฏิเสธใบสมัครสินเชื่อหรือตั้งค่าสถานะธุรกรรมว่าน่าสงสัย มาตรา 33 ของ PDPA กำหนดให้อธิบายได้ หากไม่มีเส้นทางการตรวจสอบที่มีโครงสร้างซึ่งบันทึก:

• ข้อมูลอินพุตที่ AI ใช้
• กระบวนการให้เหตุผลที่ใช้
• ผลลัพธ์ที่ผลิต
• เวลาที่ตัดสินใจ

...เป็นไปไม่ได้ที่จะให้คำอธิบายตามมาตรา 33 เมื่อถูกร้องขอ

ช่องว่าง 3: ความละเอียดของความยินยอม

ระบบ AI มักประมวลผลข้อมูลส่วนบุคคลพร้อมกันหลายวัตถุประสงค์ (การปรับแต่ง การตรวจจับการฉ้อโกง การให้บริการ) ความยินยอมแบบครอบคลุมเดียวไม่ตอบสนองข้อกำหนดของ PDPA สำหรับความยินยอมที่เฉพาะเจาะจงและได้รับข้อมูลเพียงพอ

ช่องว่าง 4: ไม่มีการรองรับสิทธิ์การลบอย่างเป็นระบบ

เมื่อเจ้าของข้อมูลใช้สิทธิ์การลบ (มาตรา 33 ของ PDPA) ระบบ AI ส่วนใหญ่ที่ใช้ vector database คลังการฝัง หรือน้ำหนักโมเดลที่ปรับแต่งแล้ว ไม่สามารถลบข้อมูลเฉพาะของบุคคลนั้นได้ในทางเทคนิค นี่คือความล้มเหลวในการปฏิบัติตามเชิงโครงสร้างที่ไม่สามารถแก้ไขได้ด้วยนโยบาย แต่ต้องการการออกแบบสถาปัตยกรรมใหม่

วิธีที่ Constitutional AI ตอบสนองข้อกำหนด PDPA

แนวทางของ RCT Labs ต่อการปฏิบัติตามกฎหมาย AI เป็นเชิงสถาปัตยกรรม ไม่ใช่เชิงขั้นตอน แทนที่จะเพิ่มการปฏิบัติตามเป็นเลเยอร์บนระบบ AI ที่มีอยู่ Constitutional AI ฝังข้อกำหนดการปฏิบัติตามเข้าไปในตรรกะการทำงานพื้นฐานของระบบ

สถาปัตยกรรม FDIA: ที่มาของข้อมูลในตัว

สมการ FDIA F = (D^I) × A รวมการวัดคุณภาพข้อมูล (D) เป็นตัวแปรหลัก ในบริบท PDPA คุณภาพข้อมูลรวม การตรวจสอบฐานกฎหมาย ระบบตรวจสอบว่าข้อมูลที่ประมวลผลมีฐานกฎหมายที่บันทึกไว้ก่อนการเรียก LLM ใดๆ

นี่ไม่ใช่การตรวจสอบนโยบายที่สามารถหลีกเลี่ยงได้ แต่เป็นข้อจำกัดทางคณิตศาสตร์: หากคะแนนที่มาของข้อมูลต่ำกว่าเกณฑ์ ประตู FDIA จะปฏิเสธคำขอ AI จะไม่ประมวลผลข้อมูล

RCTDB: เส้นทางการตรวจสอบที่สมบูรณ์สำหรับทุกการตัดสินใจ

การตัดสินใจ AI ทุกอย่างใน RCT Ecosystem ถูกบันทึกลงใน RCTDB ซึ่งเป็นสคีมาหน่วยความจำสากล 8 มิติ พร้อมที่มาครบถ้วน:

• แบบสอบถามต้นฉบับ (ทำให้ไม่ระบุตัวตนได้ตามที่กำหนด)
• คะแนนที่มาของข้อมูล (ฐานกฎหมาย สถานะความยินยอม อายุข้อมูล)
• คะแนน FDIA (ค่า D, I, A)
• โมเดลที่ใช้
• ผลลัพธ์ที่ผลิต
• เวลาประทับ

เมื่อเจ้าของข้อมูลขอคำอธิบายภายใต้มาตรา 33 ของ PDPA เส้นทางการตรวจสอบจะให้บันทึกที่สมบูรณ์และมีโครงสร้างของการตัดสินใจ ไม่ใช่การสร้างใหม่ภายหลัง

ประตู Architect: ต้องการการอนุญาตจากมนุษย์

ตัวแปร FDIA Architect (A) ทำให้มั่นใจว่าการตัดสินใจอัตโนมัติที่มีความเสี่ยงสูง (ซึ่งกระทบต่อเจ้าของข้อมูลอย่างมีนัยสำคัญ) ไม่สามารถทำได้โดยไม่มีการอนุญาตจากมนุษย์ เมื่อ A = 0 จะไม่มีผลลัพธ์ AI ใดผลิตออกมา

สำหรับการปฏิบัติตาม PDPA หมายความว่า:

• การตัดสินใจสินเชื่อ: A ถูกตั้งค่าต่ำกว่า 1.0 เจ้าหน้าที่สินเชื่อมนุษย์ต้องยืนยันก่อนสื่อสารการตัดสินใจ
• การคัดกรอง HR: A ถูกตั้งค่าต่ำกว่า 1.0 ผู้ตรวจสอบมนุษย์ต้องอนุมัติผลการคัดกรองที่ AI สร้างขึ้น
• การคัดแยกทางการแพทย์: A ถูกตั้งค่าเป็น 0.3 AI คัดกรอง แพทย์คลินิกตัดสินใจ

JITNA Protocol: การควบคุมการถ่ายโอนข้ามพรมแดน

โปรโตคอล JITNA รวมการแยกโซนข้อมูลที่ป้องกันไม่ให้ข้อมูลส่วนบุคคลถูกส่งผ่านขอบเขตเขตอำนาจโดยไม่ได้รับการอนุญาตชัดเจน เมื่อแพ็กเก็ต JITNA มีข้อมูลส่วนบุคคลที่ถูกแท็กว่าอยู่ภายใต้ PDPA:

• แพ็กเก็ตถูกตั้งค่าสถานะด้วย metadata เขตอำนาจ
• การส่งผ่านข้ามพรมแดนต้องได้รับการอนุมัติชัดเจนในส่วนหัวของแพ็กเก็ต
• การถ่ายโอนข้ามพรมแดนทั้งหมดถูกบันทึกด้วยเส้นทางการตรวจสอบ RCTDB

Delta Engine: สิทธิ์การลบอย่างเป็นระบบ

เนื่องจาก RCTDB ใช้สคีมา append-only พร้อมบันทึกที่เชื่อมโยงด้วย UUID บันทึกเจ้าของข้อมูลสามารถถูก tombstone ด้วยการเข้ารหัส ต่างจาก vector database ที่ไม่สามารถลบข้อมูลเฉพาะของบุคคลได้ง่าย RCTDB associtaes ข้อมูลส่วนบุคคลทั้งหมดกับ subject_uuid การลบตั้งค่า Flag tombstone บนบันทึกทั้งหมดที่เชื่อมโยงกับ UUID นั้น ป้องกันการอ่านในอนาคตโดยไม่ลบห่วงโซ่การเข้าถึงบันทึก

เปรียบเทียบ: AI ทั่วไป vs. Constitutional AI สำหรับ PDPA

| ข้อกำหนด PDPA | การปรับใช้ AI ทั่วไป | Constitutional AI (RCT Labs) | |---|---|---| | การตรวจสอบฐานกฎหมาย | นโยบายด้วยตนเอง มักไม่มีเอกสาร | คะแนนคุณภาพข้อมูล FDIA รวมการตรวจสอบที่มา | | เส้นทางการตรวจสอบ | การบันทึก ad-hoc ถ้ามี | RCTDB: สมบูรณ์ มีโครงสร้าง ทุกการตัดสินใจ | | ความสามารถอธิบายมาตรา 33 | การสร้างใหม่ภายหลัง | คะแนน FDIA + บันทึกแพ็กเก็ต JITNA = คำอธิบายที่มีโครงสร้าง | | การควบคุมการถ่ายโอนข้ามพรมแดน | การจัดการข้อยกเว้นด้วยตนเอง | metadata เขตอำนาจโปรโตคอล JITNA | | สิทธิ์การลบ | ไม่สามารถทำได้ในทางเทคนิค (vector stores) | รูปแบบ tombstone RCTDB (เชื่อมโยง UUID) | | การอนุญาตมนุษย์สำหรับ AI ความเสี่ยงสูง | ตัวเลือกเพิ่มเติม | ประตู FDIA Architect (ตัวแปร A) | | การบังคับลดข้อมูล | นโยบายเท่านั้น | คะแนนคุณภาพข้อมูล FDIA ลงโทษข้อมูลส่วนเกิน |

คำถามที่พบบ่อย

PDPA ใช้กับระบบ AI ที่ไม่ได้เก็บข้อมูลโดยตรงหรือไม่?

ใช่ PDPA ใช้กับนิติบุคคลใดๆ ที่ ประมวลผล ข้อมูลส่วนบุคคล รวมถึงการวิเคราะห์ ใช้ จัดเก็บ หรือส่ง หากระบบ AI ของคุณรับข้อมูลส่วนบุคคลจากแหล่งใดๆ (รวมถึงจากองค์กรอื่น) ภาระผูกพัน PDPA จะบังคับใช้

การใช้ Foreign LLM API เป็นการถ่ายโอนข้ามพรมแดน PDPA หรือไม่?

ใช่ การส่งข้อมูลส่วนบุคคลไปยัง API ที่ตั้งอยู่นอกไทย (OpenAI, Anthropic, Google) ถือเป็นการถ่ายโอนข้ามพรมแดนภายใต้มาตรา 28-29 ของ PDPA คุณต้องการการตัดสินใจความเพียงพอสำหรับประเทศปลายทาง หรือการป้องกันที่เหมาะสมเช่น Standard Contractual Clauses (SCCs)

โทษสำหรับการไม่ปฏิบัติตาม PDPA ในระบบ AI คืออะไร?

โทษทางปกครองสูงสุด 5 ล้านบาทต่อการละเมิด (มาตรา 82 ของ PDPA) โทษอาญาสำหรับการเปิดเผยข้อมูลที่ละเอียดอ่อนโดยเจตนา ความเสียหายต่อชื่อเสียงจากการบังคับใช้สาธารณะมักมีค่าใช้จ่ายมากกว่าค่าปรับ

ควรนำ Constitutional AI มาใช้เพื่อการปฏิบัติตาม PDPA เมื่อไร?

ยิ่งเร็วยิ่งดี การปรับปรุงการปฏิบัติตามเชิงสถาปัตยกรรมให้กับระบบ AI ที่มีอยู่มีค่าใช้จ่ายสูงกว่าการสร้างด้วยข้อจำกัดตามรัฐธรรมนูญตั้งแต่ต้นอย่างมีนัยสำคัญ

สรุป

การปฏิบัติตาม PDPA สำหรับระบบ AI เป็นความท้าทายเชิงสถาปัตยกรรม ไม่ใช่เชิงนโยบาย ข้อกำหนดหลัก ได้แก่ การตรวจสอบฐานกฎหมาย เส้นทางการตรวจสอบ ความสามารถอธิบาย การควบคุมข้ามพรมแดน และสิทธิ์การลบ ไม่สามารถตอบสนองได้ด้วยแบนเนอร์ยินยอมและประกาศความเป็นส่วนตัวเพียงอย่างเดียว

Constitutional AI ใช้แนวทางตรงข้าม: ฝังการปฏิบัติตามเข้าไปในข้อจำกัดทางคณิตศาสตร์และโครงสร้างของระบบ เพื่อให้ AI ไม่สามารถทำงานนอกข้อจำกัดเหล่านั้นได้โดยไม่คำนึงถึงพฤติกรรมของผู้ใช้หรือโมเดล

การนำไปใช้ของ RCT Labs ซึ่งประกอบด้วย FDIA gating, เส้นทางการตรวจสอบ RCTDB, การควบคุมเขตอำนาจ JITNA และการอนุญาต Architect ตอบสนองข้อกำหนด PDPA หลักในเชิงสถาปัตยกรรม ไม่ใช่เชิงขั้นตอน

บทความนี้ผลิตโดย RCT Labs Research Desk และตรวจสอบโดย อิทธิฤทธิ์ แสงโกว ผู้ก่อตั้ง RCT Labs บทความนี้ให้ข้อมูลทั่วไปเท่านั้น และไม่ถือเป็นคำแนะนำทางกฎหมาย ควรปรึกษาทนายความผู้เชี่ยวชาญด้านการคุ้มครองข้อมูลของไทยสำหรับแนวทางการปฏิบัติตามเฉพาะ