AI นโยบายความเป็นส่วนตัว ธนาคารปรับใหม่ ลูกค้าต้องรู้อะไร

/in

เมื่อธนาคารเพิ่ม AI ในนโยบายความเป็นส่วนตัว
ลูกค้ารู้อะไรแล้ว และยังควรรู้อะไรอีก

ดร.อุดมธิปก ไพรเกษตร

นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย (TPDPA)
นายกสมาคมผู้ประกอบการพาณิชย์อิเล็กทรอนิกส์ไทย (สมาคมอีคอมเมิร์ซไทย)

อาจารย์สุกฤษ โกยอัครเดช

เลขาธิการและประธานฝ่ายต่างประเทศสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย (TPDPA)

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

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

ช่วงกลางเดือนกันยายนที่ผ่านมา ผมได้รับข้อความจาก KBank Live ผ่าน LINE แจ้งว่า ธนาคารกสิกรไทยได้ปรับปรุงนโยบายการคุ้มครองข้อมูลส่วนบุคคลให้สอดคล้องกับกิจกรรมการประมวลผลข้อมูลส่วนบุคคลและกฎหมายที่เกี่ยวข้อง

การเปลี่ยนแปลงสำคัญที่ธนาคารแจ้งมีสองเรื่อง ได้แก่

  • เพิ่มประเภทข้อมูลส่วนบุคคลที่ธนาคารเก็บรวบรวม เช่น ข้อมูลการใช้งานช่องทางดิจิทัลและข้อมูลที่เกี่ยวข้องกับเทคโนโลยีปัญญาประดิษฐ์ (Artificial Intelligence: AI)
  • เพิ่มรายละเอียดวัตถุประสงค์ในการประมวลผลข้อมูลส่วนบุคคลที่เกี่ยวข้องกับ AI การบริหารความเสี่ยง การป้องกันการทุจริตภายในกลุ่มธุรกิจทางการเงิน และการป้องกันอาชญากรรมทางเทคโนโลยี

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

AI เข้ามาอยู่ตรงไหนในนโยบายฉบับใหม่

เมื่ออ่านนโยบายการคุ้มครองข้อมูลส่วนบุคคลของธนาคาร ซึ่งระบุว่า “ปรับปรุงล่าสุด เดือนสิงหาคม 2569” พบรายละเอียดเกี่ยวกับ AI ที่น่าสนใจหลายประการ

ข้อ 2 เพิ่มประเภทข้อมูลที่เรียกว่า “ข้อมูลเกี่ยวกับการใช้งานผ่านช่องทางดิจิทัลและบริการที่ใช้เทคโนโลยีปัญญาประดิษฐ์”

สำหรับผู้ที่ใช้บริการดังกล่าว ข้อมูลที่ธนาคารอาจเก็บรวบรวมครอบคลุมถึง

  • ข้อความ คำถาม และคำสั่ง หรือพรอมต์ (prompt)
    • รูปภาพ ไฟล์ เอกสาร และเสียง
    • ประวัติการสนทนาและประวัติการใช้งาน
    • บันทึกการใช้งาน (log) พฤติกรรมการใช้งาน และข้อมูลทางเทคนิค
    • ผลการวิเคราะห์ ผลการคาดการณ์ การสรุปข้อมูล และผลลัพธ์ที่ระบบสร้างขึ้น

ข้อ 3 ระบุว่า ธนาคารอาจนำเทคโนโลยีที่มีอยู่ในปัจจุบันหรือที่จะมีเพิ่มเติมในอนาคตมาใช้ ซึ่งรวมถึงแต่ไม่จำกัดเพียงบล็อกเชน (blockchain) ปัญญาประดิษฐ์ (AI) และปัญญาประดิษฐ์แบบรู้สร้าง (Generative AI)

นโยบายยกตัวอย่าง ChatGPT และ Microsoft Copilot รวมถึงแชตบอตที่ใช้ AI และระบบประมวลผลแบบคลาวด์ (Cloud Computing)

ข้อความส่วนนี้ต้องอ่านอย่างระมัดระวัง การยกตัวอย่างชื่อผลิตภัณฑ์ไม่ได้ยืนยันว่า ธนาคารนำผลิตภัณฑ์ทุกตัวที่กล่าวถึงมาใช้ประมวลผลข้อมูลลูกค้าแล้ว

สิ่งที่บอกได้จากนโยบายคือ ธนาคารวางขอบเขตไว้รองรับการนำเทคโนโลยีประเภทดังกล่าวมาใช้ประมวลผลข้อมูลส่วนบุคคล

การใช้ข้อมูลกับ AI แบ่งออกเป็นสองกลุ่มใหญ่ ได้แก่

  1. การใช้ข้อมูลเพื่อให้บริการหรือประมวลผลตามคำขอ รวมถึงการให้คำแนะนำ การตอบคำถาม และการสนับสนุนการให้บริการผ่านระบบอัตโนมัติหรือ AI
  2. การใช้ข้อมูลเพื่อวิเคราะห์ ทดสอบ ตรวจสอบ และปรับปรุงระบบหรือแบบจำลอง รวมถึงการพัฒนาและเพิ่มความแม่นยำ ความปลอดภัย และประสิทธิภาพของระบบ

ข้อ 4 ระบุ “ผู้ให้บริการระบบปัญญาประดิษฐ์” เป็นผู้รับข้อมูลส่วนบุคคลประเภทหนึ่งที่ธนาคารอาจเปิดเผยข้อมูลให้

ส่วนข้อ 5 ระบุว่า ธนาคารอาจส่งหรือโอนข้อมูลส่วนบุคคลไปยังผู้ให้บริการระบบ AI ในต่างประเทศได้ด้วย

ข้อความที่ธนาคารระบุไว้ในนโยบาย

อีกข้อความหนึ่งที่ควรกล่าวถึงคือ ตอนท้ายของเนื้อหาเกี่ยวกับการใช้เทคโนโลยีตามข้อ 3 ธนาคารระบุว่า การดำเนินการดังกล่าว

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

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

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

นี่คือประเด็นที่ผมอยากชวนคิดต่อ

ข้อมูลที่นโยบายยังไม่ได้อธิบายในระดับรายกิจกรรม

เรื่องเวลาเริ่มใช้และความโปร่งใสของการเปลี่ยนแปลง

นโยบายไม่ได้ระบุว่า ธนาคารเริ่มนำ AI มาใช้กับกิจกรรมการประมวลผลแต่ละประเภทเมื่อใด กิจกรรมใดเริ่มใช้งานแล้ว และกิจกรรมใดเป็นแผนงานในอนาคต

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

ผมได้รับข้อความแจ้งวันที่ 14 กันยายน 2569 ขณะที่นโยบายระบุเพียงว่า “ปรับปรุงล่าสุด เดือนสิงหาคม 2569” โดยไม่ได้ระบุวันเริ่มมีผลของนโยบายฉบับนี้

อีกเรื่องหนึ่งคือขอบเขตการใช้ข้อมูลกับแบบจำลองและผู้ให้บริการภายนอก

กรณีการใช้งาน AI (AI use case) แต่ละกรณีใช้ข้อมูลส่วนบุคคลประเภทใด มีวัตถุประสงค์อะไร และอาศัยฐานกฎหมายใด

การใช้ข้อมูลเพื่อ “ปรับปรุงระบบหรือแบบจำลอง” หมายถึงเฉพาะระบบภายในของธนาคาร หรือรวมถึงแบบจำลองของผู้ให้บริการ AI ภายนอกด้วย

ผู้ให้บริการภายนอกสามารถนำข้อมูลของลูกค้าไปใช้เพื่อวัตถุประสงค์ของตนเอง หรือใช้ฝึกและปรับปรุงแบบจำลองของตนได้หรือไม่

สำหรับการโอนข้อมูลไปต่างประเทศ นโยบายระบุว่า หากประเทศปลายทางมีมาตรฐานการคุ้มครองข้อมูลส่วนบุคคลไม่เพียงพอ ธนาคารจะจัดให้มีมาตรการคุ้มครองที่จำเป็นและเหมาะสม เช่น การทำข้อตกลงกับผู้รับข้อมูล หรือการใช้นโยบายการคุ้มครองข้อมูลส่วนบุคคลภายในเครือกิจการหรือเครือธุรกิจ (Binding Corporate Rules: BCR)

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

อีกคำถามหนึ่งคือ ข้อมูลประเภทพรอมต์ ไฟล์ ประวัติการสนทนา และผลลัพธ์จาก AI จะถูกเก็บรักษาไว้นานเท่าใด

นโยบายข้อ 7 กำหนดระยะเวลาเก็บรักษาข้อมูลไว้เป็นการทั่วไป เช่น 5–10 ปีตามกฎหมายป้องกันและปราบปรามการฟอกเงิน และ 10 ปีตามกฎหมายธุรกิจสถาบันการเงิน กฎหมายหลักทรัพย์และตลาดหลักทรัพย์ กฎหมายการบัญชี และกฎหมายภาษีอากร แต่ไม่ได้แยกระยะเวลาเก็บรักษาข้อมูลที่เกิดจากการใช้ AI ไว้เป็นการเฉพาะ

เรื่องที่สามคือบทบาทของ AI ในการตัดสินใจเกี่ยวกับลูกค้า

นโยบายข้อ 3.2.5 ระบุว่า ธนาคารมีการวิเคราะห์และจัดทำแบบจำลอง เช่น การให้คะแนนเครดิต (credit scoring) รวมถึงการประเมิน วิเคราะห์ หรือคาดการณ์ความสนใจ พฤติกรรม รูปแบบการใช้บริการ ความน่าเชื่อถือ และระดับความเสี่ยงของบุคคล หรือการจัดทำข้อมูลประวัติส่วนบุคคล (profiling)

ข้อ 3.2.2 ยังกล่าวถึงการพิจารณาคำขอ การทบทวนคุณภาพเครดิต และการกำหนดวงเงินบัตรหรือสินเชื่อด้วย

ดังนั้น คำถามจึงไม่ใช่ว่า “ธนาคารมีการจัดทำข้อมูลประวัติส่วนบุคคล (profiling) หรือไม่” เพราะนโยบายได้แจ้งไว้แล้ว

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

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

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

กรอบกฎหมายที่เกี่ยวข้อง

การเพิ่มคำว่า “AI” ไว้ในนโยบายเป็นจุดเริ่มต้นที่ดี แต่ลูกค้าทั่วไปอาจยังไม่ทราบว่า ข้อมูลของตนถูกนำไปใช้กับ AI ในกิจกรรมใด และการประมวลผลนั้นอาจส่งผลต่อตนเองอย่างไร

ในทางกฎหมาย หากเป็นเพียงการเปลี่ยนเทคโนโลยีที่ใช้ประมวลผล โดยยังอยู่ภายในวัตถุประสงค์เดิมที่ได้แจ้งไว้ ย่อมต้องพิจารณาข้อเท็จจริงและขอบเขตของการประมวลผลเป็นรายกรณี

แต่หากมีการนำข้อมูลไปใช้เพื่อวัตถุประสงค์ที่แตกต่างจากที่ได้แจ้งไว้เดิม ต้องพิจารณามาตรา 21 แห่งพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562

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

ขณะเดียวกัน ต้องพิจารณาหน้าที่แจ้งรายละเอียดแก่เจ้าของข้อมูลส่วนบุคคลตามมาตรา 23 และหากไม่ได้เก็บรวบรวมข้อมูลจากเจ้าของข้อมูลโดยตรง ต้องพิจารณามาตรา 25 ประกอบด้วย

การจัดทำและทบทวนบันทึกรายการตามมาตรา 39 (ROPA)

อีกประเด็นที่ต้องพิจารณาคือ บันทึกรายการตามมาตรา 39 หรือที่ในทางปฏิบัติมักเรียกว่า บันทึกรายการกิจกรรมการประมวลผลข้อมูลส่วนบุคคล (Record of Processing Activities: ROPA)

เมื่อกิจกรรมการประมวลผลเปลี่ยนไป ROPA เดิมต้องได้รับการทบทวนและปรับให้ตรงกับการดำเนินงานจริง

เหตุที่การนำ AI มาใช้ทำให้ต้องกลับมาทบทวน ROPA เห็นได้จากนโยบายฉบับนี้เอง ซึ่งเพิ่มทั้งประเภทข้อมูลที่เก็บรวบรวม เช่น Prompt ไฟล์ ประวัติการสนทนา บันทึกการใช้งาน และผลลัพธ์ที่ระบบสร้างขึ้น ตลอดจนเพิ่มวัตถุประสงค์ เช่น การให้บริการผ่านระบบอัตโนมัติ การวิเคราะห์ การทดสอบ และการปรับปรุงระบบหรือแบบจำลอง

รายการเหล่านี้สัมพันธ์โดยตรงกับข้อมูลที่มาตรา 39 กำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลต้องบันทึก เช่น ประเภทข้อมูลส่วนบุคคล วัตถุประสงค์ของการเก็บรวบรวม ระยะเวลาการเก็บรักษา สิทธิและเงื่อนไขในการเข้าถึงข้อมูล ตลอดจนคำอธิบายเกี่ยวกับมาตรการรักษาความมั่นคงปลอดภัย หากการใช้ AI ทำให้องค์ประกอบเหล่านี้เพิ่มขึ้นหรือเปลี่ยนแปลง ผู้ควบคุมข้อมูลส่วนบุคคลจึงต้องพิจารณาทบทวนและปรับ ROPA ให้ตรงกับกิจกรรมที่เกิดขึ้นจริง หลักการนี้เป็นหน้าที่ทั่วไปของผู้ควบคุมข้อมูลส่วนบุคคลและไม่ได้หมายความว่าธนาคารยังไม่ได้ดำเนินการ

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

จากนโยบายที่เผยแพร่ต่อสาธารณะ เราไม่สามารถตรวจสอบได้ว่าธนาคารได้ทบทวนหรือปรับ ROPA แล้วหรือไม่ เนื่องจากกฎหมายไม่ได้กำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลต้องเผยแพร่ ROPA ต่อสาธารณะ ดังนั้น ประเด็นนี้จึงควรกล่าวในฐานะหน้าที่ด้านการกำกับดูแลภายในที่ต้องพิจารณาเมื่อกิจกรรมการประมวลผลเปลี่ยนแปลง ไม่ใช่ข้อสรุปว่าธนาคารยังไม่ได้ดำเนินการ

การประเมินผลกระทบด้านการคุ้มครองข้อมูลส่วนบุคคล (Data Protection Impact Assessment: DPIA)

ปัจจุบันพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 ไม่ได้บัญญัติหน้าที่จัดทำการประเมินผลกระทบด้านการคุ้มครองข้อมูลส่วนบุคคล หรือ Data Protection Impact Assessment (DPIA) โดยใช้ถ้อยคำนี้ไว้อย่างชัดแจ้ง

Thailand Data Protection Guidelines 4.0: แนวปฏิบัติการคุ้มครองข้อมูลส่วนบุคคล (TDPG 4.0) ซึ่งจัดทำโดยคณะนิติศาสตร์ จุฬาลงกรณ์มหาวิทยาลัย ได้อธิบายหลักการและวิธีการจัดทำ DPIA ไว้อย่างเป็นระบบ

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

คณะกรรมการคุ้มครองข้อมูลส่วนบุคคลได้ให้ความเห็นชอบ “(ร่าง) แนวทางการดำเนินการด้านการคุ้มครองข้อมูลส่วนบุคคลเกี่ยวกับการพัฒนาและการใช้งานเทคโนโลยีปัญญาประดิษฐ์ (Artificial Intelligence)” ในการประชุมครั้งที่ 8/2569 เมื่อวันที่ 26 สิงหาคม 2569 และมอบหมายให้สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลเผยแพร่และประชาสัมพันธ์ต่อไป

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

ดังนั้น จึงยังไม่ควรกล่าวว่า เพียงองค์กรนำ AI มาใช้ กฎหมายก็บังคับให้ต้องจัดทำ DPIA ทุกกรณี อย่างไรก็ตาม หากระบบประมวลผลข้อมูลจำนวนมาก ข้อมูลส่วนบุคคลที่ละเอียดอ่อน ติดตามพฤติกรรม จัดทำข้อมูลประวัติส่วนบุคคล (profiling) หรือนำผลไปใช้ตัดสินใจเรื่องสำคัญ การจัดทำ DPIA ก่อนเริ่มดำเนินการย่อมเป็นเครื่องมือด้านธรรมาภิบาลที่มีความสำคัญ

DPIA ช่วยให้องค์กรตรวจสอบความจำเป็นและความได้สัดส่วน ประเมินความเสี่ยงต่อเจ้าของข้อมูลส่วนบุคคล และกำหนดมาตรการป้องกันหรือลดความเสี่ยงอย่างเป็นระบบ

การประเมินประโยชน์โดยชอบด้วยกฎหมาย (Legitimate Interest Assessment: LIA)

การประเมินประโยชน์โดยชอบด้วยกฎหมาย หรือ Legitimate Interest Assessment (LIA) เกี่ยวข้องกับกรณีที่องค์กรประสงค์จะอาศัยฐานประโยชน์โดยชอบด้วยกฎหมายตามมาตรา 24(5)

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลไม่ได้กำหนดชื่อ แบบฟอร์ม หรือขั้นตอนการจัดทำ LIA ไว้โดยตรง แต่เงื่อนไขตามมาตรา 24(5) ทำให้ผู้ควบคุมข้อมูลส่วนบุคคลต้องพิจารณาในสาระสำคัญว่า

  • มีประโยชน์โดยชอบด้วยกฎหมายที่ชัดเจน
    • การประมวลผลมีความจำเป็นต่อประโยชน์นั้น
    • สิทธิและเสรีภาพขั้นพื้นฐานของเจ้าของข้อมูลไม่ได้มีความสำคัญเหนือกว่าประโยชน์ดังกล่าว

LIA จึงไม่ใช่เครื่องมือสำหรับกรณีที่องค์กร “ไม่มีฐานกฎหมาย”

หากไม่มีฐานกฎหมายรองรับ การจัดทำ LIA ก็ไม่อาจทำให้การประมวลผลนั้นกลายเป็นการประมวลผลที่ชอบด้วยกฎหมายได้

สิ่งที่สรุปได้ในตอนนี้

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

กรณีนี้แสดงให้เห็นว่า การปฏิบัติตามกฎหมายเป็นพื้นฐาน ส่วนความโปร่งใสและความไว้วางใจอาจต้องอาศัยคำอธิบายเพิ่มเติมที่เหมาะกับลักษณะของผลิตภัณฑ์หรือบริการ

ธนาคารได้แจ้งสาระสำคัญของการเปลี่ยนแปลงนโยบายแล้ว

หากมีคำอธิบายเพิ่มเติมในระดับผลิตภัณฑ์ บริการ หรือกรณีการใช้งาน AI ก็จะช่วยให้ลูกค้าเข้าใจการประมวลผลได้ชัดเจนยิ่งขึ้น

ข้อมูลดังกล่าวอาจครอบคลุมว่า

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

การสื่อสารในลักษณะนี้จะช่วยให้ลูกค้าอ่านเข้าใจ ตรวจสอบ ตัดสินใจ และใช้สิทธิได้จริงครับ

เอกสารประกอบ

  1. นโยบายการคุ้มครองข้อมูลส่วนบุคคลของธนาคารกสิกรไทย
  2. พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562
  3. Thailand Data Protection Guidelines 4.0: แนวปฏิบัติการคุ้มครองข้อมูลส่วนบุคคล
  4. ผลการประชุมคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล ครั้งที่ 8/2569



สิทธิในข้อมูลส่วนบุคคล และเสรีภาพทางการเมือง

/in
สิทธิในข้อมูลส่วนบุคคล และเสรีภาพทางการเมือง
“คนเราสามารถคิดต่างกันได้ และการคิดต่างไม่ควรทำให้บุคคลสูญเสียสิทธิในความเป็นส่วนตัวและการคุ้มครองข้อมูลของตน”
 
อาจารย์มยุรี ชวนชม กรรมการและประธานส่งเสริมการคุ้มครองข้อมูลส่วนบุคคลสมาคมฯ
 
6 ตุลาคม 2519 วันที่สังคมไทยเผชิญความขัดแย้งทางการเมืองอย่างรุนแรง และเกิดเหตุการณ์ที่มหาวิทยาลัยธรรมศาสตร์และพื้นที่โดยรอบ มีผู้เสียชีวิต ผู้บาดเจ็บ และผู้ถูกจับกุมจำนวนมาก
 
6 ตุลาคม ไม่ได้เป็นเพียงเรื่องของประวัติศาสตร์ แต่ยังเป็นบทเรียนสำคัญเกี่ยวกับ สิทธิ เสรีภาพ ความแตกต่างทางความคิด และความปลอดภัยของบุคคลที่มีความคิดเห็นทางการเมือง ซึ่งหากมองในมิติกฎหมายคุ้มครองข้อมูลส่วนบุคคล หรือ PDPA มีประเด็นที่น่าสนใจ คือ ความคิดเห็นทางการเมือง (political opinions) ซึ่งพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 จัดให้เป็น ข้อมูลส่วนบุคคลที่มีความอ่อนไหว (Sensitive Personal Data) ตามมาตรา 26 เช่นเดียวกับข้อมูลเกี่ยวกับเชื้อชาติ ศาสนา สุขภาพ ประวัติอาชญากรรม ข้อมูลสหภาพแรงงาน
 
คำถามสำคัญจึงเกิดขึ้นว่า
เหตุใดกฎหมายจึงต้องให้ความคุ้มครอง “ความคิดเห็นทางการเมือง” ในระดับที่เข้มงวดกว่าข้อมูลส่วนบุคคลทั่วไป?
 
คำตอบคือ ความคิดเห็นทางการเมืองไม่ใช่เพียงข้อมูลทั่วไป แต่สามารถสะท้อน อัตลักษณ์ ความเชื่อ อุดมการณ์ ความสัมพันธ์ทางสังคม และจุดยืนของบุคคลต่ออำนาจรัฐและสังคม และหากข้อมูลดังกล่าวถูกนำไปใช้ในทางที่ไม่เหมาะสม อาจก่อให้เกิดผลกระทบต่อเจ้าของข้อมูลได้อย่างมีนัยสำคัญ
 
1. มาตรา 26 กับ “ความคิดเห็นทางการเมือง”
หลักคิดสำคัญของมาตรา 26 คือ การยกระดับมาตรฐานการคุ้มครองข้อมูลที่อาจกระทบต่อสิทธิและเสรีภาพของบุคคลอย่างรุนแรง ดังนั้น การเก็บรวบรวม ใช้ หรือเปิดเผยข้อมูลประเภทนี้จึงไม่สามารถดำเนินการในลักษณะเดียวกับข้อมูลทั่วไปได้
 
โดยหลัก การประมวลผลข้อมูลส่วนบุคคลที่มีความอ่อนไหวตามมาตรา 26 ต้องมีฐานทางกฎหมายที่เหมาะสม และโดยทั่วไปกฎหมายกำหนดให้ต้องได้รับ ความยินยอมโดยชัดแจ้ง (explicit consent) เว้นแต่จะเข้าข้อยกเว้นตามที่กฎหมายกำหนด
 
ประเด็นนี้มีความสำคัญอย่างยิ่ง เพราะทำให้เราเห็นว่า PDPA ไม่ได้คุ้มครองเพียง “ข้อมูล” ในฐานะข้อมูล แต่กำลังคุ้มครองบุคคลที่เป็นเจ้าของข้อมูลนั้น (Data Subject)
 
2. ทำไม “ความคิดเห็นทางการเมือง” จึงมีความเสี่ยง?
ลองพิจารณาข้อมูลต่อไปนี้
* บุคคลหนึ่งเข้าร่วมกิจกรรมทางการเมือง
* บุคคลหนึ่งเป็นสมาชิกหรือผู้สนับสนุนกลุ่มทางการเมือง
* บุคคลหนึ่งแสดงความคิดเห็นเกี่ยวกับรัฐบาล
* บุคคลหนึ่งแชร์เนื้อหาทางการเมืองบนสื่อสังคมออนไลน์
* บุคคลหนึ่งเข้าร่วมการชุมนุม
* บุคคลหนึ่งลงชื่อสนับสนุนข้อเรียกร้องทางการเมือง
* บุคคลหนึ่งบริจาคเงินให้กิจกรรมหรือองค์กรทางการเมือง
 
ข้อมูลแต่ละประเภทอาจทำให้สามารถอนุมานถึง ความคิดเห็นหรือจุดยืนทางการเมืองของบุคคลได้ และเมื่อข้อมูลเหล่านี้ถูกรวบรวมเข้าด้วยกัน ความเสี่ยงก็อาจเพิ่มขึ้นอย่างมากต่อเจ้าของข้อมูลส่วนบุคคล
ตัวอย่างเช่น ข้อมูลชื่อ + ที่อยู่ + สถานที่ทำงาน + การเข้าร่วมกิจกรรม + ภาพถ่าย + การแสดงความคิดเห็นออนไลน์ อาจทำให้สามารถสร้าง “โปรไฟล์ทางการเมือง” ของบุคคลได้
 
ดังนั้น สิ่งที่ PDPA ให้ความสำคัญคือ “ใครกำลังเก็บข้อมูลนี้ เก็บไปเพื่ออะไร ใช้อย่างไร และใครสามารถเข้าถึงข้อมูลนี้ได้?”
 
3. บทเรียนเรื่อง “ความเสี่ยงของข้อมูลทางการเมือง”
เหตุการณ์ 6 ตุลาคม 2519 เป็นกรณีศึกษาทางประวัติศาสตร์ที่ทำให้เห็นว่าความขัดแย้งทางการเมือง มีผลกระทบต่อชีวิตและเสรีภาพของบุคคลได้อย่างรุนแรง การชุมนุม การแสดงความคิดเห็นทางการเมือง การกล่าวหา การจับกุม และความรุนแรงที่เกิดขึ้นในบริบทของความขัดแย้งทางการเมืองในเวลานั้น
 
ในปัจจุบัน เทคโนโลยีดิจิทัลทำให้ความสามารถในการรวบรวมข้อมูลแตกต่างจากอดีตอย่างมาก ในปี 2519 การติดตามบุคคลอาจต้องอาศัยเอกสาร ภาพถ่าย รายงาน หรือการบันทึกด้วยวิธีการต่าง ๆ แต่ในยุคดิจิทัล ข้อมูลสามารถเกิดขึ้นได้ทุกวินาทีจาก social media + CCTV + Location Data + Facial Recognition + Digital Footprint + Online Registration + Membership Database
 
ข้อมูลจำนวนมากสามารถเชื่อมโยงกันได้อย่างรวดเร็ว และอาจนำไปสู่การสร้างฐานข้อมูลเกี่ยวกับกิจกรรมหรือความคิดเห็นทางการเมืองของบุคคล
นี่คือเหตุผลที่แนวคิดเรื่อง Data Protection มีความสำคัญต่อสังคมประชาธิปไตยในยุคดิจิทัล
 
4. “การมีความคิดเห็นทางการเมืองที่ต่างกัน” ไม่ควรถูกเลือกปฏิบัติ
บุคคลอาจมีความคิดเห็นทางการเมืองแตกต่างจากบุคคลอื่นได้ แต่ต้องไม่ได้ทำให้บุคคลสูญเสียสิทธิในข้อมูลส่วนบุคคลของตน ยิ่งข้อมูลมีความอ่อนไหวมากเท่าใด ผู้ควบคุมข้อมูล (Data Controller) ก็ยิ่งต้องตระหนักถึงความเสี่ยงในการประมวลผลข้อมูลมากขึ้นเท่านั้น
 
หลักการนี้สอดคล้องกับแนวคิดสำคัญของการคุ้มครองข้อมูลส่วนบุคคล นั่นคือ
Privacy ไม่ได้หมายความว่า “ไม่มีใครรู้ข้อมูลของเรา” แต่หมายถึง “เรามีสิทธิที่จะได้รับการคุ้มครองจากการนำข้อมูลของเราไปใช้โดยไม่เหมาะสม”
 
5. ข้อมูลที่เปิดเผยต่อสาธารณะ ไม่ได้แปลว่าใช้ได้โดยไม่มีข้อจำกัด
ผู้ปฏิบัติงาน PDPA ควรระมัดระวังคือ การที่บุคคลโพสต์ความคิดเห็นทางการเมืองใน Facebook, X, TikTok หรือแพลตฟอร์มอื่นด้วยตนเอง ไม่ได้หมายความว่าองค์การสามารถนำข้อมูลดังกล่าวไปเก็บรวบรวม ใช้ หรือสร้างฐานข้อมูลได้อย่างไม่มีข้อจำกัด และแม้จะเป็นข้อมูลที่เปิดเผยต่อสาธารณะ ก็ยังต้องพิจารณา
1. วัตถุประสงค์ของการเก็บข้อมูล
2. ฐานทางกฎหมาย
3. ความจำเป็นและความได้สัดส่วน
4. ขอบเขตของข้อมูล
5. ระยะเวลาในการเก็บรักษา
6. ผู้ที่จะได้รับข้อมูล
7. ความเสี่ยงที่อาจเกิดขึ้นกับเจ้าของข้อมูล
8. มาตรการรักษาความมั่นคงปลอดภัยของข้อมูล โดยเฉพาะเมื่อข้อมูลนั้นสามารถสะท้อนความคิดเห็นทางการเมืองของบุคคลได้
 
6. จาก “6 ตุลา” สู่ “Digital Footprint”
เราจะจดจำประวัติศาสตร์อย่างไร และ จะจัดการกับข้อมูลเกี่ยวกับประวัติศาสตร์และความคิดเห็นทางการเมืองของผู้คนอย่างไร?
ตัวอย่างเช่น ภาพถ่ายจากกิจกรรมทางการเมืองในอดีต บันทึกการเข้าร่วมกิจกรรม รายชื่อผู้เข้าร่วมการสัมมนา รายชื่อสมาชิก หรือข้อความที่บุคคลเคยเผยแพร่ อาจกลายเป็นข้อมูลที่สามารถเชื่อมโยงกลับไปยังความคิดเห็นทางการเมืองของบุคคลได้
 
ในยุคที่ข้อมูลไม่มีวัน “หายไป” ได้ง่าย ๆ สิ่งที่บุคคลเคยโพสต์เมื่อปีก่อนหลายปีก่อน อาจยังถูกค้นหา วิเคราะห์ และเชื่อมโยงกับข้อมูลใหม่ได้ ทำให้แนวคิดเรื่อง Digital Footprint มีความสำคัญมากขึ้น
 
7. สำหรับองค์การ HR และภาครัฐ ความเสี่ยงยิ่งสูงขึ้น
องค์การที่มีข้อมูลของบุคลากรจำนวนมากควรระมัดระวังเป็นพิเศษ เช่น
  • แบบสอบถามความคิดเห็นพนักงาน
  • ข้อมูลกิจกรรมของพนักงาน
  • ข้อมูลสมาชิกองค์กร
  • ภาพถ่ายกิจกรรม
  • การตรวจสอบ Social Media
  • การตรวจสอบประวัติบุคลากร
  • ระบบรักษาความปลอดภัย
  • CCTV
  • การใช้ AI วิเคราะห์ข้อมูลพนักงาน
องค์การต้องระวังไม่ให้กระบวนการเหล่านี้กลายเป็นการสร้าง “Political Profile” ของบุคลากรโดยไม่จำเป็น
โดยเฉพาะในกระบวนการ HR คำถามสำคัญคือ องค์การจำเป็นต้องรู้ความคิดเห็นทางการเมืองของพนักงานเพื่อการบริหารงานหรือไม่?
หากคำตอบคือ “ไม่จำเป็น” ก็ไม่ควรเก็บข้อมูลนั้นเพียงเพราะสามารถเก็บได้ นี่คือหัวใจของแนวคิด Data Minimization
 
8. สำหรับ Data Protection Officer (DPO)
ผู้รับผิดชอบด้านการคุ้มครองข้อมูลส่วนบุคคล หากมีประเด็นความคิดเห็นทางการเมืองที่ต้องถูกเก็บรวบรวม ใช้ ควรถูกนำเข้าสู่กระบวนการ Privacy Risk Assessment ก่อนเก็บข้อมูลควรถามอย่างน้อยว่า
Purpose → Necessity → Lawful Basis → Risk → Security → Retention → Access → Accountability
 
ไม่ใช่ทุกข้อมูลที่องค์การสามารถเก็บได้ จะเป็นข้อมูลที่องค์กรควรเก็บ
และโดยเฉพาะข้อมูลที่สะท้อนความคิดเห็นทางการเมือง การตัดสินใจเก็บข้อมูลควรอยู่บนหลัก ความจำเป็น ความชอบด้วยกฎหมาย ความโปร่งใส และการคุ้มครองสิทธิของเจ้าของข้อมูล
 
ท้ายสุดแล้ว เราจะจดจำอะไรจากเหตุการณ์ทางการเมือง?
ในมุมของ PDPA อาจเพิ่มคำถามอีกข้อหนึ่งว่า
“เราจะป้องกันไม่ให้ข้อมูลส่วนบุคคลกลายเป็นเครื่องมือที่สร้างความเสี่ยงต่อสิทธิและเสรีภาพของคนในสังคมได้อย่างไร?”
 
มาตรา 26 ไม่ใช่เป็นเพียงกฎหมายที่กำหนดให้ “ความคิดเห็นทางการเมือง” เป็น Sensitive Personal Data เท่านั้น แต่เป็นกลไกการสร้าง วัฒนธรรมการเคารพสิทธิในข้อมูลของบุคคล
 
6 ตุลาคมอาจเตือนเราว่า เมื่อความคิดเห็น ความเชื่อ และจุดยืนของบุคคลถูกทำให้กลายเป็น “ข้อมูล” สิ่งที่ต้องระมัดระวังไม่ใช่เพียงข้อมูลนั้นจะถูกเปิดเผยหรือไม่ แต่คือ ข้อมูลนั้นจะถูกนำไปใช้เพื่ออะไร และจะส่งผลอย่างไรต่อสิทธิ เสรีภาพ และศักดิ์ศรีความเป็นมนุษย์ของเจ้าของข้อมูล

วันนี้ ChatGPT มีโฆษณาแล้วในไทย กฎหมาย PDPA และกฎหมายการกำกับแพลตฟอร์มและการยืนยันตัวตนผู้ลงโฆษณา ตามทันหรือไม่?

/in

ดร.อุดมธิปก ไพรเกษตร

นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย (TPDPA)
นายกสมาคมผู้ประกอบการพาณิชย์อิเล็กทรอนิกส์ไทย (สมาคมอีคอมเมิร์ซไทย)

อาจารย์สุกฤษ โกยอัครเดช

เลขาธิการและประธานฝ่ายต่างประเทศสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย (TPDPA)

เผยแพร่วันที่ 5 ตุลาคม พ.ศ. 2569

ในช่วงปลายเดือนกันยายน พ.ศ. 2569 ผู้เขียนได้ทดลองใช้ OpenAI Ads Manager และพบว่าสามารถตั้งค่าบัญชีผู้ลงโฆษณาเป็นประเทศไทย ใช้สกุลเงินบาทและเขตเวลา Bangkok เลือกประเทศไทยเป็นพื้นที่ของแคมเปญ กำหนดงบประมาณ วิธีประมูล URL ปลายทาง สร้างชิ้นงาน และเข้าสู่ขั้นตอนเพิ่มวิธีชำระเงินได้ ข้อเท็จจริงนี้สอดคล้องกับข้อมูลของ OpenAI ที่ระบุว่าประเทศไทยเปิดให้ใช้ Ads Manager แบบบริการตนเองแล้ว

และเมื่อวันที่ 1 ตุลาคม พ.ศ. 2569 ผู้เขียนได้รับตัวอย่างจากผู้ใช้ ChatGPT Go ในประเทศไทยซึ่งพบโฆษณาปรากฏอยู่ใต้คำตอบของ ChatGPT แล้ว ตัวอย่างดังกล่าวเป็นหลักฐานจากการใช้งานจริงว่า การดำเนินธุรกิจของ ChatGPT ในประเทศไทยนั้นไม่ได้มีเพียงระบบบริการแก่ฝั่งผู้ลงโฆษณาเท่านั้น แต่ยังริเริ่มมีการนำเสนอขายสินค้าและบริการในรูปแบบการแสดงโฆษณาแก่ฝั่งผู้ใช้อีกด้วย

ณ วันที่ 1 ตุลาคม พ.ศ. 2569 มีหลักฐานจากการใช้งานจริงว่า ผู้ใช้ ChatGPT Go ในประเทศไทยบางรายเริ่มเห็นโฆษณาแล้ว ขณะที่นโยบายของ OpenAI ระบุกลุ่มผู้ใช้ที่อาจได้รับโฆษณาไว้ในแผน Free และ Go ส่วน Plus, Pro, Business, Enterprise และ Edu ไม่มีโฆษณา และบัญชีที่ OpenAI ระบุว่าเป็นของผู้มีอายุต่ำกว่า 18 ปีจะไม่ถูกแสดงโฆษณา 

จากข้อเท็จจริงดังกล่าว คำถามทางกฎหมายจึงไม่ใช่เพียงว่า ChatGPT มีโฆษณาแล้วหรือไม่ แต่คือกฎหมายไทยใช้บังคับกับกิจกรรมโฆษณาของ OpenAI ในประเทศไทยอย่างไร

ในมุมมองของผู้เขียน มีกรอบกฎหมายอย่างน้อย 3 เรื่องที่ต้องนำมาวิเคราะห์ว่าใช้บังคับกับกิจกรรมของ OpenAI ในประเทศไทยเพียงใด ได้แก่

  1. พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562
  2. พระราชกฤษฎีกาการประกอบธุรกิจบริการแพลตฟอร์มดิจิทัลที่ต้องแจ้งให้ทราบ พ.ศ. 2565 และ
  3. ประกาศคณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์ เรื่อง มาตรการเพื่อป้องกันอาชญากรรมทางเทคโนโลยีสำหรับผู้ให้บริการสื่อสังคมออนไลน์ (ฉบับที่ 2)

การดำเนินการตาม พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 ไม่ได้ใช้บังคับเฉพาะองค์กรที่ตั้งอยู่ในประเทศไทย มาตรา 5 วรรคสองกำหนดให้ว่า PDPA ยังบังคับใช้กรณีที่ผู้ควบคุมข้อมูลส่วนบุคคลหรือผู้ประมวลผลข้อมูลส่วนบุคคลนอกราชอาณาจักรได้มีการเก็บรวบรวม ใช้ หรือเปิดเผยข้อมูลส่วนบุคคลของเจ้าของข้อมูลที่อยู่ในประเทศไทย เมื่อการประมวลผลดังกล่าว มีการนำเสนอขายสินค้าหรือบริการหรือการเฝ้าติดตามพฤติกรรมเจ้าของข้อมูลที่อยู่ในประเทศไทย

ระบบโฆษณาของ OpenAI เกี่ยวข้องกับข้อมูลจากทั้งสองด้าน คือ ข้อมูลของผู้ใช้ ChatGPT ที่อาจถูกนำมาใช้เพื่อเลือกโฆษณาให้สอดคล้องกับบริบทของการสนทนา และข้อมูลจากฝั่งผู้ลงโฆษณาที่ใช้สำหรับการลงโฆษณาและวัดผลของแคมเปญ 

ดังนั้น หากมองในมุม PDPA จึงต้องแยกพิจารณาให้ชัดว่า ข้อมูลแต่ละส่วนมาจากไหน ถูกนำไปใช้อย่างไร และ OpenAI กับผู้ลงโฆษณามีบทบาททางกฎหมายอย่างไรในแต่ละกิจกรรม

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

ข้อมูลจากหน้า OpenAI Ads ภาษาไทยระบุว่า การโฆษณาใน ChatGPT ไม่ได้อาศัยเพียงคีย์เวิร์ด แต่ใช้ “สัญญาณบริบทที่ลึกขึ้น” และสร้างประสบการณ์โฆษณาบนพื้นฐานของ “การสนทนา บริบท และการตัดสินใจแบบเรียลไทม์” ขณะที่ตัวอย่างที่พบจากผู้ใช้ ChatGPT Go ในประเทศไทยก็แสดงให้เห็นว่า ระบบสามารถใช้หัวข้อของบทสนทนาปัจจุบันเพื่อเลือกโฆษณาที่เกี่ยวข้องได้ หรือที่เรียกว่า Contextual Advertising ดังนั้นจึงมีทั้งคำอธิบายจาก OpenAI และหลักฐานจากการใช้งานจริงที่สนับสนุนว่า บริบทของการสนทนาเป็นองค์ประกอบหนึ่งในการเลือกโฆษณา

ประเด็นทาง PDPA จึงไม่ได้อยู่เพียงว่า OpenAI “อ่านข้อความหรือไม่” แต่ต้องพิจารณาว่าข้อมูลหรือสัญญาณใดจากการสนทนาถูกนำมาประมวลผลเพื่อสร้างบริบทสำหรับการโฆษณา ใช้เพื่อวัตถุประสงค์ใด อาศัยฐานกฎหมายใด และกลไกที่ OpenAI เรียกว่า “ทางเลือกและการควบคุม” สอดคล้องกับสิทธิของเจ้าของข้อมูลตามกฎหมายไทยเพียงใด ทั้งนี้ ยังไม่สามารถสรุปจากข้อมูลดังกล่าวว่า OpenAI เปิดใช้การปรับโฆษณาตามประวัติของผู้ใช้ การจับคู่ฐานลูกค้าของผู้ลงโฆษณา หรือเครื่องมือวัดผลโฆษณาในประเทศไทยครบถ้วนแล้วหรือไม่

ฝั่งผู้ลงโฆษณา OpenAI ยังมีเครื่องมือสำหรับสร้างกลุ่มเป้าหมายและวัดผลโฆษณา ซึ่งอาจเกี่ยวข้องกับอีเมล หมายเลขโทรศัพท์ คุกกี้ ตัวระบุออนไลน์ ข้อมูลธุรกรรม หรือข้อมูลเหตุการณ์ภายหลังจากผู้ใช้เห็นหรือคลิกโฆษณา

DPO และตัวแทนในประเทศไทย ประเด็นที่ควรตรวจสอบให้ชัด

ประเด็นเรื่องเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล หรือ Data Protection Officer (DPO) ไม่ได้เพิ่งเกิดขึ้นเมื่อ OpenAI เริ่มให้บริการโฆษณา เพราะลักษณะการให้บริการ ChatGPT เองก็เกี่ยวข้องกับการประมวลผลข้อมูลส่วนบุคคลในวงกว้างอยู่แล้ว แต่การเพิ่มระบบโฆษณา การเลือกโฆษณาตามบริบท และเครื่องมือสำหรับผู้ลงโฆษณา ทำให้กิจกรรมการประมวลผลซับซ้อนขึ้น และทำให้คำถามว่า OpenAI ปฏิบัติหน้าที่ตามมาตรา 41 ของกฎหมายไทยครบถ้วนแล้วหรือไม่มีความสำคัญยิ่งขึ้น

มาตรา 41 แห่งพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 กำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลหรือผู้ประมวลผลข้อมูลส่วนบุคคลต้องจัดให้มีเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (Data Protection Officer: DPO) เมื่อเข้าเงื่อนไขตามกฎหมาย หนึ่งในนั้นคือมาตรา 41(2) ซึ่งครอบคลุมกรณีที่กิจกรรมจำเป็นต้องตรวจสอบข้อมูลส่วนบุคคลหรือระบบอย่างสม่ำเสมอโดยเหตุที่มีข้อมูลส่วนบุคคลเป็นจำนวนมาก

รายละเอียดของมาตรา 41(2) ได้รับการกำหนดเพิ่มเติมใน “ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง การจัดให้มีเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลตามมาตรา 41 (2) แห่งพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 พ.ศ. 2566” 

ซึ่งมีผลใช้บังคับตั้งแต่วันที่ 13 ธันวาคม พ.ศ. 2566 และกำหนดเกณฑ์ข้อมูลส่วนบุคคลจำนวนมากไว้ เช่น กรณีการประมวลผลซึ่งเป็นส่วนหนึ่งของกิจกรรมหลักและมีเจ้าของข้อมูลตั้งแต่ 100,000 รายขึ้นไป รวมถึงบางกรณีของการโฆษณาตามพฤติกรรมผ่านโปรแกรมค้นหาหรือสื่อสังคมออนไลน์ที่มีผู้ใช้งานอย่างกว้างขวาง 

เมื่อพิจารณาลักษณะของ ChatGPT การจัดการบัญชีผู้ใช้ การประมวลผลบทสนทนา Personalization, Memory และระบบโฆษณา ผู้เขียนเห็นว่ามีน้ำหนักสูงมากที่กิจกรรมของ OpenAI ซึ่งอยู่ภายใต้ PDPA ไทยต้องถูกพิจารณาตามมาตรา 41(2)

OpenAI นั้นเปิดเผยอยู่แล้วว่ามี DPO พร้อมระบุช่องทางติดต่อที่ dpo@openai.com  ดังนั้นคำถามไม่ได้อยู่ที่ว่า OpenAI มี DPO หรือไม่ แต่อยู่ที่การปฏิบัติหน้าที่ตามกฎหมายไทยครบถ้วนแล้วหรือยัง โดยเฉพาะการแจ้งข้อมูลเกี่ยวกับ DPO สถานที่ติดต่อ และวิธีการติดต่อให้สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลทราบ

อีกหน้าที่หนึ่งที่ต้องแยกออกจาก DPO คือ “ตัวแทนในราชอาณาจักร” หาก OpenAI เป็นผู้ควบคุมข้อมูลส่วนบุคคลที่อยู่นอกราชอาณาจักรและอยู่ภายใต้มาตรา 5 วรรคสอง มาตรา 37(5) กำหนดให้แต่งตั้งตัวแทนเป็นหนังสือ โดยตัวแทนต้องอยู่ในราชอาณาจักร ทั้งนี้ต้องพิจารณาข้อยกเว้นตามมาตรา 38 ประกอบ

สำหรับ OpenAI การอาศัยข้อยกเว้นตามมาตรา 38 ต้องมีข้อเท็จจริงรองรับ โดยเฉพาะเงื่อนไขที่ว่าการประมวลผลไม่มีลักษณะตามมาตรา 26 และไม่มีข้อมูลส่วนบุคคลเป็นจำนวนมากตามเกณฑ์มาตรา 41(2) เมื่อพิจารณาลักษณะของบริการ OpenAI แล้ว ผู้เขียนเห็นว่าประเด็นนี้ควรถูกตรวจสอบโดยตรง ไม่ควรตั้งสมมติฐานไว้ก่อนว่าได้รับยกเว้น

ดังนั้น ในกรอบ PDPA มีอย่างน้อยสองคำถามที่ควรได้รับคำตอบชัดเจน คือ 

  1. OpenAI ได้แต่งตั้งตัวแทนในราชอาณาจักรตามมาตรา 37(5) แล้วหรือไม่ และ
  2. OpenAI ได้แจ้งข้อมูลเกี่ยวกับ DPO ต่อสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) ตามมาตรา 41 แล้วหรือไม่

ณ วันที่เขียนบทความ ผู้เขียนยังไม่พบข้อมูลสาธารณะที่เพียงพอจะยืนยันสองเรื่องนี้ การไม่พบข้อมูลสาธารณะไม่ใช่หลักฐานว่า OpenAI ไม่ได้ดำเนินการ แต่เป็นข้อเท็จจริงที่สมควรให้ OpenAI และสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลชี้แจงโดยตรง

พระราชกฤษฎีกาการประกอบธุรกิจบริการแพลตฟอร์มดิจิทัลที่ต้องแจ้งให้ทราบ พ.ศ. 2565

ประเด็นถัดมาคือ ChatGPT และบริการโฆษณาของ OpenAI อยู่ในระบบกำกับบริการแพลตฟอร์มดิจิทัลของไทยหรือไม่

กฎหมายฉบับนี้ไม่ได้กำหนดว่าบริการออนไลน์ทุกประเภทต้องแจ้งการประกอบธุรกิจโดยอัตโนมัติ การวิเคราะห์ต้องเริ่มจากนิยาม “บริการแพลตฟอร์มดิจิทัล” ลักษณะการเป็นสื่อกลาง เงื่อนไขตามพระราชกฤษฎีกาฯ และกรณีผู้ประกอบธุรกิจที่อยู่นอกราชอาณาจักรตามมาตรา 10

หากพิจารณา ChatGPT เฉพาะในฐานะ AI Assistant อาจยังมีประเด็นให้ถกเถียงเรื่องลักษณะการเป็นสื่อกลาง แต่ Ads Manager เพิ่มความสัมพันธ์ระหว่างผู้ลงโฆษณา OpenAI และผู้ใช้ ChatGPT ขึ้นอีกชั้นหนึ่ง 

โดยผู้ลงโฆษณาสามารถสร้างแคมเปญ กำหนดงบประมาณ พื้นที่เป้าหมาย ชิ้นงาน และ URL ปลายทาง ขณะที่ OpenAI เป็นผู้บริหารระบบและเลือกนำโฆษณาไปแสดงแก่ผู้ใช้ที่มีสิทธิ์

ข้อเท็จจริงใหม่ที่ผู้ใช้ ChatGPT Go ในประเทศไทยเริ่มเห็นโฆษณาแล้ว ทำให้การประเมินขอบเขตการใช้บังคับของพระราชกฤษฎีกา มีความสำคัญมากขึ้น เพราะขณะนี้มีทั้งฝั่งผู้ลงโฆษณาและฝั่งผู้ใช้ในประเทศไทยอยู่ในระบบเดียวกันแล้ว นอกจากนี้ OpenAI ยังจัดทำหน้า OpenAI Ads ภาษาไทยสำหรับผู้ลงโฆษณา โดยเชิญชวนให้สร้างบัญชี เข้าสู่ Ads Manager และเริ่มโฆษณาใน ChatGPT ข้อเท็จจริงนี้เป็นอีกปัจจัยหนึ่งที่ควรนำมาพิจารณาในการประเมินว่าบริการมีลักษณะมุ่งให้บริการแก่ผู้ใช้หรือผู้ประกอบธุรกิจในประเทศไทยตามมาตรา 10 หรือไม่ แต่ยังไม่ทำให้ข้อสรุปเรื่องการเข้าเกณฑ์บริการแพลตฟอร์มดิจิทัลเกิดขึ้นโดยอัตโนมัติ

การที่ ChatGPT, ChatGPT Ads หรือ Ads Manager เข้าข่าย “บริการแพลตฟอร์มดิจิทัล” ตามพระราชกฤษฎีกาการประกอบธุรกิจบริการแพลตฟอร์มดิจิทัลที่ต้องแจ้งให้ทราบ พ.ศ. 2565 และ OpenAI ในฐานะผู้ประกอบธุรกิจซึ่งอยู่นอกราชอาณาจักรมีลักษณะตามมาตรา 10 OpenAI ย่อมต้องพิจารณาหน้าที่ในการแจ้งการประกอบธุรกิจต่อสำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (สพธอ.) และการแต่งตั้งผู้ประสานงานในราชอาณาจักรตามมาตรา 11 เพื่อประโยชน์ในการแจ้งข้อมูลและปฏิบัติตามกฎหมาย ทั้งนี้ ต้องวินิจฉัยก่อนว่าบริการส่วนใดของ OpenAI เข้านิยามบริการแพลตฟอร์มดิจิทัลตามกฎหมายหรือไม่

ทั้งนี้ “ผู้ประสานงานในราชอาณาจักร” ตามกฎหมายบริการแพลตฟอร์มดิจิทัล เป็นคนละสถานะกับ “ตัวแทนในราชอาณาจักร” ตามมาตรา 37(5) ของพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 แม้ทั้งสองบทบาทจะเกี่ยวข้องกับผู้ประกอบธุรกิจที่อยู่นอกประเทศไทยก็ตาม

ประกาศคณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์ เรื่อง มาตรการเพื่อป้องกันอาชญากรรมทางเทคโนโลยีสำหรับผู้ให้บริการสื่อสังคมออนไลน์ (ฉบับที่ 2)

กฎหมายฉบับที่สามมองอีกด้านหนึ่ง คือแพลตฟอร์มรู้หรือไม่ว่าใครอยู่เบื้องหลังโฆษณาที่ถูกนำมาเสนอขายต่อประชาชน

ประกาศฉบับนี้จะมีผลใช้บังคับวันที่ 1 พฤศจิกายน พ.ศ. 2569 ซึ่งเป็นหนึ่งเดือนหลังบทความนี้เผยแพร่ สาระสำคัญส่วนหนึ่งคือ ผู้ให้บริการสื่อสังคมออนไลน์ที่ให้บริการโฆษณาในประเทศไทยต้องมีมาตรการพิสูจน์ตัวตนผู้กระทำการโฆษณาก่อนเผยแพร่ตามเงื่อนไขที่กำหนด

ประเด็นสำคัญจึงอยู่ที่การตีความว่า ChatGPT Ads เข้าข่าย “ผู้ให้บริการสื่อสังคมออนไลน์” ตามประกาศฉบับนี้หรือไม่ ซึ่งหากเป็นจะทำให้ ChatGPT ต้องดำเนินการตามกฎหมาย แต่หากไม่ ก็กลายเป็นช่องโหว่ของกฎหมายฉบับนี้

ซึ่งความไม่ชัดเจนอยู่ที่ลักษณะของ ChatGPT เอง เพราะบริการหลักไม่ได้เปิดพื้นที่ให้ผู้ใช้สร้างเครือข่ายและเผยแพร่เนื้อหาระหว่างกันในลักษณะเดียวกับ Facebook, TikTok, Instagram หรือ X แต่เป็นบริการสนทนาระหว่างผู้ใช้กับปัญญาประดิษฐ์ (Artificial Intelligence: AI)

การเพิ่มระบบโฆษณาจึงไม่ได้เปลี่ยนลักษณะของ ChatGPT ให้เป็นผู้ให้บริการสื่อสังคมออนไลน์ตามประกาศโดยอัตโนมัติ

จากการทดลองใช้งาน Ads Manager พบว่า OpenAI เก็บหรือแสดงข้อมูลเกี่ยวกับผู้ลงโฆษณา ธุรกิจ แคมเปญ เว็บไซต์ปลายทาง และวิธีชำระเงินในระดับหนึ่ง และยังมีข้อกำหนดด้านโฆษณารวมทั้งกระบวนการ Business Review ของตนเอง

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

จากที่ผู้เขียนทดลองใช้งานระบบ ระบบสามารถไปถึงขั้นเพิ่มวิธีชำระเงินได้ แต่ยังไม่ปรากฏขั้นตอนตรวจบัตรประชาชน หนังสือเดินทาง Digital ID การตรวจใบหน้า หรือการตรวจอำนาจของผู้แทนนิติบุคคลในขั้นตอนที่เห็น

อย่างไรก็ตาม การไม่เห็นขั้นตอนเหล่านี้ในหน้าจอที่ทดลอง ไม่ได้หมายความว่า OpenAI ไม่มีระบบยืนยันตัวตน เพราะอาจมี Business Review หรือกระบวนการ Verification ในอีกขั้นตอนหนึ่งก่อนอนุมัติหรือเผยแพร่แคมเปญ

เมื่อ ChatGPT ทำหน้าที่นำข้อความของบุคคลหนึ่งซึ่งจ่ายเงินค่าโฆษณาไปแสดงแก่ผู้ใช้อีกรายหนึ่ง ความเสี่ยงที่ประกาศต้องการลด เช่น การแอบอ้าง การหลอกลงทุน การใช้โฆษณาเป็นช่องทางอาชญากรรม และการไม่สามารถติดตามตัวผู้ลงโฆษณา ก็สามารถเกิดขึ้นได้เช่นเดียวกัน ด้วยเหตุนี้ ประเด็นว่า ChatGPT Ads อยู่ในขอบเขตของประกาศฉบับที่ 2 หรือไม่ จึงควรได้รับคำชี้แจงจากสำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์หรือคณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์โดยตรง มากกว่าที่ผู้ให้บริการหรือผู้เขียนจะตีความฝ่ายเดียว

กฎหมายไทยกำลังมองคนละด้านของระบบเดียวกัน

หากมองระบบโฆษณาบนแพลตฟอร์มดิจิทัลผ่านกฎหมายไทย จะเห็นว่ากฎหมายแต่ละฉบับไม่ได้ถามคำถามเดียวกัน แต่กำลังมอง คนละมุม ของระบบเดียวกัน

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

พ.ร.ฎ.การประกอบธุรกิจบริการแพลตฟอร์มดิจิทัลที่ต้องแจ้งให้ทราบ พ.ศ. 2565 มองที่ตัวแพลตฟอร์มและผู้ให้บริการ ว่าบริการนั้นอยู่ในขอบเขตที่กฎหมายไทยกำกับหรือไม่ ใครเป็นผู้ให้บริการ ติดต่อได้อย่างไร และได้ทำหน้าที่ตามที่กฎหมายกำหนดครบถ้วนหรือยัง

ส่วน มาตรการป้องกันอาชญากรรมทางเทคโนโลยี มองไปที่อีกด้านหนึ่ง คือ คนที่อยู่หลังโฆษณา โดยถามว่า หากมีการซื้อโฆษณาผ่านแพลตฟอร์ม ผู้ให้บริการรู้หรือไม่ว่าใครเป็นผู้ลงโฆษณา มีการตรวจสอบตัวตนมากน้อยเพียงใด และหากเกิดปัญหาขึ้น จะสามารถสาวกลับไปถึงผู้ลงโฆษณาตัวจริงได้หรือไม่

เมื่อนำทั้งสามเรื่องมารวมกัน ผู้เขียนคิดว่าหลักที่เหมาะกับการกำกับโฆษณาในยุค AI คือ

รู้จักผู้ใช้เท่าที่จำเป็น แต่ต้องรู้จักผู้ลงโฆษณามากพอที่จะตรวจสอบและรับผิดชอบได้

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

ด้านผู้ลงโฆษณา กลับต้องโปร่งใสและตรวจสอบได้มากขึ้น เพราะแพลตฟอร์มควรสามารถตอบได้ว่าใครเป็นผู้ลงโฆษณา บุคคลนั้นเกี่ยวข้องกับนิติบุคคลอย่างไรOpenAI Ads, ลงโฆษณาใน ChatGPT (ภาษาไทย)

https://ads.openai.com/th-TH

 มีอำนาจหรือไม่ และใครต้องรับผิดชอบหากโฆษณาก่อให้เกิดความเสียหาย

บทส่งท้าย

ก่อนหน้านี้ คำถามเรื่อง ChatGPT Ads ในประเทศไทยอาจดูเป็นเรื่องที่ยังมาไม่ถึง แต่เมื่อ Ads Manager เปิดให้ผู้ลงโฆษณาไทยใช้งานได้ และขณะเดียวกันมีหลักฐานว่าผู้ใช้ ChatGPT Go ในประเทศไทยบางรายเริ่มเห็นโฆษณาแล้ว คำถามทางกฎหมายจึงกลายเป็นเรื่องปัจจุบัน

สิ่งที่ควรตรวจสอบต่อไม่ได้มีเพียงว่าโฆษณาจะมีมากขึ้นหรือไม่ แต่คือ OpenAI ใช้ข้อมูลอะไรในการเลือกโฆษณา ได้ปฏิบัติหน้าที่ตาม PDPA ไทยครบถ้วนหรือไม่ อยู่ในระบบกำกับแพลตฟอร์มดิจิทัลของไทยหรือไม่ และเมื่อมีผู้จ่ายเงินเพื่อให้ข้อความหนึ่งถูกนำมาแสดงแก่ประชาชน เราสามารถรู้ได้หรือไม่ว่าใครอยู่เบื้องหลังข้อความนั้น

นี่คือจุดที่ความเป็นส่วนตัว ความรับผิดชอบของแพลตฟอร์ม และการป้องกันอาชญากรรมออนไลน์ เริ่มมาบรรจบกันอย่างชัดเจนในระบบโฆษณาของ AI

แหล่งข้อมูลหลักที่ใช้ตรวจสอบ

OpenAI Help Center, Ads Manager Availability

https://help.openai.com/th-th/articles/20001245-ads-manager-availability

OpenAI Help Center, Ads in ChatGPT

https://help.openai.com/en/articles/20001047-ads-in-chatgpt

OpenAI, Advertising Terms

https://openai.com/policies/advertising-terms/

OpenAI, Ad Tools Terms

https://openai.com/policies/ad-tools-terms/

OpenAI, Ad Tools Data Processing Addendum

https://openai.com/policies/ad-tools-dpa/

OpenAI, Conversion Terms

https://openai.com/policies/conversion-terms/

OpenAI, Ad Policies

https://openai.com/policies/ad-policies/

OpenAI, Privacy Policy

https://openai.com/th-TH/policies/privacy-policy/

การลงโฆษณาใน ChatGPT

https://ads.openai.com/th-TH

สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล, ระบบการแจ้งข้อมูลเกี่ยวกับเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล

https://dpo.pdpc.or.th/registration

ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง การจัดให้มีเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลตามมาตรา 41 (2) แห่งพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 พ.ศ. 2566

https://ratchakitcha.soc.go.th/documents/

สำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์, กฎหมาย/หลักเกณฑ์บริการแพลตฟอร์มดิจิทัล

https://www.etda.or.th/th/regulator/Digitalplatform/

เมื่อ QR Code–Barcode บนบัตรเลือกตั้งไม่ขัดรัฐธรรมนูญ แต่เรื่อง PDPA ยังไม่จบ

/in

ดร.อุดมธิปก ไพรเกษตร นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย

วันที่ 28 กันยายน 2569 ศาลรัฐธรรมนูญมีคำวินิจฉัยกรณีการใช้ QR Code และ Barcode บนบัตรเลือกตั้งสมาชิกสภาผู้แทนราษฎรในการเลือกตั้งวันที่ 8 กุมภาพันธ์ 2569 ประเด็นที่ศาลรับพิจารณาเกี่ยวข้องกับข้อกล่าวอ้างว่า รหัสบนบัตรอาจทำให้สามารถสืบทราบตัวตนของผู้ลงคะแนนและผลการลงคะแนนได้ จนอาจกระทบต่อหลักการออกเสียงลงคะแนนโดยลับตามรัฐธรรมนูญ

สิ่งที่ผมเห็นว่าน่าสนใจไม่น้อยกว่าผลคำวินิจฉัย คือข้อสังเกตของศาลเกี่ยวกับการออกแบบบัตรเลือกตั้งในอนาคต โดยเสนอให้หลีกเลี่ยงเครื่องหมายหรือสัญลักษณ์ที่สามารถเชื่อมโยงข้อมูลระบุตัวผู้มีสิทธิเลือกตั้งกับผลการออกเสียงลงคะแนน และให้มีมาตรการควบคุมการจัดเก็บบัตรอย่างรัดกุม

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

นี่คือจุดที่คำถามตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 หรือ PDPA ซึ่งผมเคยตั้งข้อสังเกตไว้ก่อนหน้านี้ ยังไม่จบ


เมื่อรหัสสามารถเชื่อมกลับถึงบุคคลและการลงคะแนน
มาตรา 6 แห่งพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 กำหนดว่า “ข้อมูลส่วนบุคคล” หมายถึงข้อมูลเกี่ยวกับบุคคลซึ่งทำให้สามารถระบุตัวบุคคลนั้นได้ ไม่ว่าทางตรงหรือทางอ้อม

เพราะฉะนั้น QR Code หรือ Barcode ไม่ได้เป็นข้อมูลส่วนบุคคลเพียงเพราะมีลักษณะเป็นรหัส สิ่งที่ต้องพิจารณาคือ เมื่อนำรหัสดังกล่าวไปเชื่อมโยงกับข้อมูลอื่นแล้ว สามารถทำให้ระบุตัวบุคคลได้หรือไม่

ในกรณีการเลือกตั้งครั้งนี้ ข้อมูลที่เปิดเผยต่อสาธารณะระบุว่า บัตรเลือกตั้งแบบแบ่งเขตสีเขียวใช้ QR Code ส่วนบัตรเลือกตั้งแบบบัญชีรายชื่อสีชมพูใช้ Barcode และมีการรายงานว่ารหัสบนบัตรมีลักษณะเป็นรหัสเฉพาะรายใบ โดยเลขที่ปรากฏสัมพันธ์กับเลขบนต้นขั้วบัตรซึ่งผู้มีสิทธิเลือกตั้งลงชื่อหรือพิมพ์ลายนิ้วมือไว้ Thai PBS Verify ระบุว่า ทั้ง QR Code บนบัตรแบบแบ่งเขตและ Barcode บนบัตรแบบบัญชีรายชื่อในการเลือกตั้งปี 2569 มี Running Number ที่แตกต่างกันในแต่ละใบและตรงกับเลขบนต้นขั้วบัตร ขณะที่ กกต.เองก็ชี้แจงว่าบาร์โค้ดบนบัตรมีหมายเลขตรงกับต้นขั้วบัตรตามขั้นตอนที่กำหนดไว้

ดังนั้น ประเด็นสำคัญไม่ได้อยู่ที่ชื่อของเทคโนโลยีว่าเป็น QR Code หรือ Barcode แต่อยู่ที่ว่า รหัสบนบัตรแต่ละประเภทสามารถทำหน้าที่เป็นตัวเชื่อมระหว่างบัตรเลือกตั้งกับข้อมูลบนต้นขั้วได้หรือไม่ และข้อมูลในเส้นทางดังกล่าวสามารถเชื่อมต่อไปถึงตัวผู้มีสิทธิเลือกตั้งได้เพียงใด

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

การพิจารณาจึงไม่ควรดูเพียงว่ามีข้อมูลอะไรอยู่ภายใน QR Code หรือ Barcode แต่ต้องมองเส้นทางของข้อมูลทั้งหมด หรือ Data Flow ว่าข้อมูลแต่ละชุดสามารถนำมาเชื่อมโยงกันได้ถึงระดับใด

ตรงนี้เกี่ยวข้องโดยตรงกับมาตรา 26 เพราะข้อมูลเกี่ยวกับ “ความคิดเห็นทางการเมือง” เป็นข้อมูลส่วนบุคคลที่มีความอ่อนไหว อย่างไรก็ดี ต้องแยกให้ชัดว่า QR Code หรือ Barcode โดยตัวมันเองไม่ได้เท่ากับข้อมูลความคิดเห็นทางการเมือง แต่หากรหัสเชื่อมไปยังบุคคล และจากบุคคลสามารถเชื่อมต่อไปถึงผลการลงคะแนนได้ ข้อมูลที่เกิดจากการเชื่อมโยงนั้นก็อาจเปิดเผยความคิดเห็นทางการเมืองของบุคคลที่สามารถระบุตัวได้

ประเด็นจึงไม่ใช่เพียงว่า “QR Code หรือ Barcode เก็บข้อมูลอะไร” แต่คือ เมื่อนำข้อมูลทั้งหมดในระบบมาพิจารณาร่วมกันแล้ว สามารถเชื่อมโยงกันได้ถึงระดับใด

ไม่ต้องขอความยินยอม ไม่ได้แปลว่าไม่มีหน้าที่ตาม PDPA

อีกเรื่องหนึ่งที่ควรแยกให้ชัดคือเรื่องความยินยอม

มาตรา 19 วางหลักทั่วไปว่า ผู้ควบคุมข้อมูลส่วนบุคคลจะเก็บรวบรวม ใช้ หรือเปิดเผยข้อมูลส่วนบุคคลไม่ได้ หากเจ้าของข้อมูลไม่ได้ให้ความยินยอมไว้ก่อนหรือในขณะนั้น เว้นแต่พระราชบัญญัตินี้หรือกฎหมายอื่นบัญญัติให้กระทำได้

แต่เมื่อข้อมูลที่ประมวลผลเข้าข่ายข้อมูลส่วนบุคคลตามมาตรา 26 ต้องพิจารณาเงื่อนไขของมาตรา 26 โดยเฉพาะ ซึ่งโดยหลักกำหนดให้ต้องได้รับความยินยอมโดยชัดแจ้ง เว้นแต่เข้าเงื่อนไขข้อยกเว้นที่กฎหมายกำหนด

สำหรับสำนักงานคณะกรรมการการเลือกตั้ง หากการประมวลผลข้อมูลดังกล่าวเป็นการจำเป็นในการปฏิบัติตามกฎหมาย และเข้าองค์ประกอบของข้อยกเว้นตามมาตรา 26 เช่น กรณีประโยชน์สาธารณะที่สำคัญตามมาตรา 26 (5) (จ) กกต.อาจไม่จำเป็นต้องอาศัยความยินยอมโดยชัดแจ้งจากเจ้าของข้อมูล ทั้งนี้ต้องพิจารณากฎหมายที่ให้อำนาจ ความจำเป็นของการประมวลผล วัตถุประสงค์ และมาตรการคุ้มครองในกิจกรรมนั้นโดยเฉพาะ

ผมจึงไม่เห็นว่าคำถามสำคัญของกรณีนี้คือ “กกต.ขอความยินยอมจากผู้มีสิทธิเลือกตั้งแล้วหรือยัง” เพราะในภารกิจตามกฎหมายของ กกต. อาจมีฐานกฎหมายและข้อยกเว้นที่ทำให้ไม่จำเป็นต้องใช้ความยินยอมเป็นฐานในการประมวลผล

แต่การไม่ต้องขอความยินยอม ไม่ได้หมายความว่า กกต.ได้รับยกเว้นจากหน้าที่อื่นตาม PDPA

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

กฎหมายเองก็เชื่อมเรื่องนี้เข้ากับหลักความรับผิดชอบที่ตรวจสอบได้ โดยมาตรา 27 กำหนดให้การใช้หรือเปิดเผยข้อมูลที่เก็บรวบรวมโดยได้รับยกเว้นไม่ต้องขอความยินยอมตามมาตรา 24 หรือมาตรา 26 ต้องถูกบันทึกไว้ในรายการตามมาตรา 39 ด้วย

กล่าวอย่างสั้นที่สุดคือ “ไม่ต้องขอความยินยอม” ไม่เท่ากับ “ไม่ต้องแจ้ง ไม่ต้องบันทึก ไม่ต้องรักษาความมั่นคงปลอดภัย และไม่ต้องแสดงความรับผิดชอบ”


คำถามที่ กกต.ควรตอบ การแจ้ง RoPA ความมั่นคงปลอดภัย และการประเมินความเสี่ยง

สำนักงานคณะกรรมการการเลือกตั้งมีคำแจ้งเกี่ยวกับการประมวลผลข้อมูลส่วนบุคคลสำหรับผู้มีสิทธิเลือกตั้งอยู่แล้ว โดยเมื่อวันที่ 11 มีนาคม 2568 ได้ออก “ประกาศสำนักงานคณะกรรมการการเลือกตั้ง เรื่อง นโยบายความเป็นส่วนตัว สำหรับบุคคลที่เป็นผู้มีสิทธิเลือกตั้ง ผู้มีสิทธิออกเสียงประชามติ ผู้สมัครรับเลือกตั้งและผู้ได้รับเลือกตั้งทุกประเภท ผู้สมัครรับเลือกตั้งและผู้ได้รับเลือกเป็นสมาชิกวุฒิสภา ผู้ถูกจำกัดสิทธิเลือกตั้ง ผู้ถูกเพิกถอนสิทธิเลือกตั้ง ผู้ถูกระงับสิทธิสมัครรับเลือกตั้ง ผู้ถูกเพิกถอนสิทธิสมัครรับเลือกตั้งและผู้ช่วยหาเสียง ของสำนักงานคณะกรรมการการเลือกตั้ง พ.ศ. ๒๕๖๘”

ดังนั้น ประเด็นไม่ใช่ว่า กกต.ไม่มี Privacy Notice แต่คือคำแจ้งที่มีอยู่สะท้อนกิจกรรมการประมวลผลที่เกิดขึ้นจริงเกี่ยวกับ QR Code, Barcode และข้อมูลที่เกี่ยวข้องครบถ้วนหรือไม่
จากเอกสารที่ตรวจสอบ พบว่ามีการระบุข้อมูลส่วนบุคคลหลายประเภท รวมถึงข้อมูลส่วนบุคคลที่มีความอ่อนไหวบางประเภท แต่ยังไม่พบการระบุโดยตรงถึง QR Code, Barcode, รหัสหรือหมายเลขประจำบัตรเลือกตั้ง ความสัมพันธ์ระหว่างรหัสบนบัตรกับต้นขั้ว หรือกิจกรรมการเชื่อมโยงข้อมูลเหล่านี้กับข้อมูลของผู้มีสิทธิเลือกตั้ง Pasted markdown

คำถามตามมาตรา 23 จึงยังคงมีอยู่ว่า ประชาชนได้รับแจ้งเกี่ยวกับกิจกรรมการประมวลผลดังกล่าวอย่างครบถ้วน ชัดเจน และทันเวลาหรือไม่ เรื่องนี้เป็นคนละเรื่องกับความยินยอม แม้ผู้ควบคุมข้อมูลจะมีฐานกฎหมายให้ประมวลผลโดยไม่ต้องขอความยินยอม หน้าที่ด้านความโปร่งใสก็ยังต้องพิจารณาแยกต่างหาก

ส่วน บันทึกรายการกิจกรรมการประมวลผลข้อมูลส่วนบุคคล หรือ Record of Processing Activities: RoPA ตามมาตรา 39 ควรสะท้อนว่าองค์กรกำลังประมวลผลข้อมูลอะไร เพื่ออะไร อย่างไร และภายใต้เงื่อนไขใด

มาตรา 39 กำหนดรายการขั้นต่ำที่ต้องบันทึก เช่น ข้อมูลที่เก็บ วัตถุประสงค์ ระยะเวลาการเก็บรักษา สิทธิและเงื่อนไขในการเข้าถึง การใช้หรือเปิดเผยในกรณีตามที่กฎหมายกำหนด และคำอธิบายเกี่ยวกับมาตรการรักษาความมั่นคงปลอดภัย

สำหรับกรณีนี้ จึงน่าสนใจว่า กิจกรรมที่เกี่ยวข้องกับรหัสบนบัตรเลือกตั้งทั้ง QR Code และ Barcode ต้นขั้ว บัญชีรายชื่อผู้มีสิทธิ การจัดเก็บ การเข้าถึง การใช้ และการตรวจสอบย้อนหลัง ถูกบันทึกไว้ใน RoPA ของ กกต.อย่างไร

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

มาตรา 37 ก็มีความสำคัญในอีกมิติหนึ่ง เพราะกำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลต้องจัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม และทบทวนมาตรการเมื่อจำเป็นหรือเมื่อเทคโนโลยีเปลี่ยนแปลง เพื่อให้ยังคงมีประสิทธิภาพ

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

สำหรับการประเมินผลกระทบด้านการคุ้มครองข้อมูลส่วนบุคคล หรือ Data Protection Impact Assessment: DPIA จากเอกสารที่เปิดเผยต่อสาธารณะและเอกสารที่ผมตรวจสอบอยู่ในขณะนี้ ยังไม่สามารถยืนยันได้ว่า กกต.ได้จัดทำหรือไม่ได้จัดทำ DPIA สำหรับกิจกรรมดังกล่าว และผมยังไม่พบข้อกำหนดเฉพาะที่สามารถยืนยันได้โดยตรงว่ากิจกรรมนี้อยู่ภายใต้ข้อบังคับที่กำหนดให้ต้องจัดทำ DPIA โดยอัตโนมัติ

อย่างไรก็ดี หากพิจารณาจากระดับความเสี่ยงของกิจกรรมนี้ ผมเห็นว่าการจัดทำ DPIA หรือการประเมินความเสี่ยงในระดับที่เทียบเท่า จะช่วยให้สามารถตอบคำถามเรื่องความจำเป็น ความได้สัดส่วน และมาตรการลดความเสี่ยงได้อย่างเป็นระบบ

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

 

จากการปฏิบัติตามกฎหมาย สู่การคุ้มครองข้อมูลตั้งแต่การออกแบบ

สำหรับผม กรณีนี้มีความสำคัญมากกว่าการถามเพียงว่า QR Code หรือ Barcode “ผิดหรือไม่ผิดกฎหมาย”

คำถามที่ลึกกว่านั้นคือ ระบบควรถูกออกแบบให้มีความสามารถในการเชื่อมโยงข้อมูลเช่นนี้ตั้งแต่แรกหรือไม่

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

นี่คือแนวคิดของ Data Protection by Design หรือการคุ้มครองข้อมูลส่วนบุคคลตั้งแต่การออกแบบระบบ

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

สาระสำคัญจึงไม่ใช่เพียงว่า “ยังไม่เกิดเหตุละเมิด” แต่หน่วยงานควรสามารถอธิบายได้ว่า เมื่อเลือกออกแบบระบบแบบนี้แล้ว เหตุผลคืออะไร มีความจำเป็นเพียงใด มีความเสี่ยงอะไร และได้ออกแบบมาตรการป้องกันความเสี่ยงนั้นไว้ตั้งแต่ต้นอย่างไร

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

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

คำวินิจฉัยของศาลรัฐธรรมนูญจึงตอบคำถามหนึ่งไปแล้ว แต่ไม่ได้ทำให้คำถามด้านการคุ้มครองข้อมูลส่วนบุคคลสิ้นสุดลง

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

หากกรณี QR Code และ Barcode บนบัตรเลือกตั้งนำไปสู่คำตอบที่ชัดเจนในเรื่องการแจ้งเจ้าของข้อมูล ฐานกฎหมายและข้อยกเว้นในการประมวลผล RoPA มาตรการรักษาความมั่นคงปลอดภัย การประเมินความเสี่ยง และ Data Protection by Design เรื่องนี้ก็จะมีความหมายมากกว่าเฉพาะบัตรเลือกตั้งครั้งหนึ่ง

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

ย้อนอ่านบทความตอนที่แล้ว:

คลิกเลย -> AiPASS กับองค์กร โอกาสพัฒนาทักษะ AI ของพนักงาน และโจทย์การกำกับการใช้ AI อย่างมีธรรมาภิบาล (ตอนที่ 4)

เมื่อข้อมูลภาครัฐกำลังจะเชื่อมกัน โจทย์คือ “แชร์อย่างไรให้ถูกกฎหมายและยังช่วยประชาชนได้ทันเวลา”

/in

ดร.อุดมธิปก ไพรเกษตร นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย

ผู้ช่วยศาสตราจารย์ ดร.ศิระเชษฐ์ โพธิ์หิรัญ ผู้เชี่ยวชาญด้านการคุ้มครองข้อมูลส่วนบุคคล ความมั่นคงปลอดภัย ธรรมาภิบาลข้อมูลและปัญญาประดิษฐ์ กรรมการสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย (TPDPA)

6 กันยายน 2569
บทความนี้เป็นการวิเคราะห์เชิงวิชาการและเชิงนโยบายจากกฎหมายและข้อมูลที่เปิดเผยต่อสาธารณะ มิใช่ข้อวินิจฉัยทางกฎหมายสำหรับข้อเท็จจริงเฉพาะกรณี

วันที่ 4 กันยายน 2569 มีการประกาศ ระเบียบสำนักนายกรัฐมนตรี ว่าด้วยการแบ่งปันข้อมูลดิจิทัล พ.ศ. 2569 ในราชกิจจานุเบกษา และมีผลใช้บังคับตั้งแต่วันที่ 5 กันยายน 2569 เป็นต้นไป

ระเบียบฉบับนี้นับเป็นความเปลี่ยนแปลงสำคัญของการบริหารข้อมูลภาครัฐ เพราะกำหนดกลไกให้หน่วยงานของรัฐเชื่อมโยงและแบ่งปันข้อมูลดิจิทัลผ่านระบบกลางอย่างเป็นระบบ โดยในระยะเร่งด่วน บัญชีท้ายระเบียบกำหนดชุดข้อมูลด้านการจัดการภัยพิบัติและสถานการณ์ฉุกเฉินไว้ถึง 118 ชุดข้อมูล

เมื่อเห็นตัวเลข 118 ชุดข้อมูล หลายคนอาจตั้งคำถามว่า นี่หมายถึงการนำข้อมูลประชาชนจำนวนมหาศาลเข้าสู่ระบบกลางหรือไม่ และการดำเนินการดังกล่าวจะขัดกับพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 หรือ PDPA
หรือเปล่า

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

นี่คือจุดที่ธรรมาภิบาลข้อมูล (Data Governance) และการคุ้มครองข้อมูลส่วนบุคคล (Data Protection) ต้องทำงานร่วมกัน

118 ชุดข้อมูลไม่ได้เป็นข้อมูลส่วนบุคคลทั้งหมด

สิ่งที่ต้องเข้าใจก่อนคือ ข้อมูลทั้ง 118 ชุดไม่ได้เป็นข้อมูลส่วนบุคคลทั้งหมด

ข้อมูลจำนวนมากเกี่ยวข้องกับสภาพแวดล้อมและโครงสร้างพื้นฐาน เช่น ระดับน้ำ ข้อมูลอุตุนิยมวิทยา เส้นทางคมนาคม ระบบไฟฟ้า โทรคมนาคม พื้นที่เสี่ยงภัย แผนที่ และข้อมูลทรัพยากรน้ำ

แต่ในบัญชีเดียวกันก็มีข้อมูลที่เกี่ยวข้องกับประชาชนโดยตรง เช่น ทะเบียนราษฎร ผู้ประกันตน กลุ่มเปราะบาง เกษตรกร และผู้สูญหาย ซึ่งหากสามารถระบุตัวบุคคลได้ ย่อมเป็นข้อมูลส่วนบุคคลตามนิยามในมาตรา 6 ของ PDPA

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

ดังนั้น สิ่งที่หน่วยงานต้องทำคือจำแนกให้ได้ว่า ใน 118 ชุดข้อมูลนั้น ชุดใดไม่มีข้อมูลส่วนบุคคล ชุดใดมีข้อมูลส่วนบุคคล และชุดใดมีข้อมูลส่วนบุคคลที่มีความอ่อนไหว พร้อมทั้งระบุฐานกฎหมายและมาตรการคุ้มครองของแต่ละกรณีให้ชัดเจน

เมื่อจำแนกข้อมูลได้ถูกต้อง วิธีบริหารความเสี่ยงตาม PDPA ก็จะชัดเจนขึ้นตามไปด้วย

ระเบียบแบ่งปันข้อมูลไม่ได้ทำให้ PDPA หายไป

การมีระเบียบสำนักนายกรัฐมนตรีฉบับนี้ไม่ได้หมายความว่า หน่วยงานรัฐสามารถใช้หรือเปิดเผยข้อมูลส่วนบุคคลได้โดยไม่ต้องคำนึงถึง PDPA

การประมวลผลข้อมูลส่วนบุคคลยังต้องมีฐานกฎหมายรองรับ และการใช้หรือเปิดเผยต้องอยู่ภายใต้วัตถุประสงค์ที่สอดคล้องกับฐานการประมวลผลและข้อจำกัดตามกฎหมาย

สำหรับหน่วยงานรัฐ ฐานกฎหมายที่อาจเกี่ยวข้องไม่ได้มีเพียงความยินยอมตามมาตรา 19 แต่อาจรวมถึงกรณีจำเป็นเพื่อป้องกันหรือระงับอันตรายต่อชีวิต ร่างกาย หรือสุขภาพตามมาตรา 24(2) การปฏิบัติภารกิจเพื่อประโยชน์สาธารณะหรือการใช้อำนาจรัฐตามมาตรา 24(4) และการปฏิบัติตามกฎหมายตามมาตรา 24(6) ทั้งนี้ต้องพิจารณาตามภารกิจ วัตถุประสงค์ และข้อเท็จจริงของแต่ละกิจกรรม

หน่วยงานจึงควรตอบให้ได้ว่า กิจกรรมการประมวลผลแต่ละกิจกรรมอาศัยฐานใดตาม PDPA และกฎหมายที่กำหนดอำนาจหน้าที่ของหน่วยงาน

การทำ ตารางฐานกฎหมาย (Legal Basis Matrix) จึงมีความสำคัญ เพราะช่วยเชื่อมระหว่างชุดข้อมูล วัตถุประสงค์ อำนาจหน้าที่ และฐานการประมวลผลเข้าด้วยกัน

ข้อมูลสุขภาพไม่จำเป็นต้องใช้ Consent เสมอไป แต่ก็ไม่ได้หมายความว่าจะใช้ได้ทุกกรณี

ข้อมูลสุขภาพเป็นข้อมูลส่วนบุคคลที่มีความอ่อนไหวตามมาตรา 26 และอยู่ภายใต้เงื่อนไขที่เข้มงวดกว่าข้อมูลส่วนบุคคลทั่วไป

อย่างไรก็ตาม มาตรา 26 มีข้อยกเว้นจากการขอความยินยอมโดยชัดแจ้งหลายกรณี เช่น การป้องกันหรือระงับอันตรายต่อชีวิต ร่างกาย หรือสุขภาพในกรณีที่เจ้าของข้อมูลไม่สามารถให้ความยินยอมได้ ตลอดจนการดำเนินการบางประเภทเกี่ยวกับการรักษาพยาบาล ระบบสุขภาพ และประโยชน์สาธารณะด้านสาธารณสุขภายใต้เงื่อนไขที่กฎหมายกำหนด

เพราะฉะนั้น การเกิดภัยพิบัติไม่ได้หมายความว่าจะสามารถใช้ข้อมูลสุขภาพได้ทุกกรณีโดยอัตโนมัติ แต่ต้องตรวจสอบว่าเข้าเงื่อนไขของข้อยกเว้นตามมาตรา 26 ที่เกี่ยวข้องจริงหรือไม่

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

หลักที่ควรใช้จึงเป็น การใช้ข้อมูลเท่าที่จำเป็นต่อวัตถุประสงค์

ถ้าการช่วยเหลือจำเป็นต้องรู้ตัวบุคคล ก็ควรใช้ข้อมูลที่ระบุตัวได้เท่าที่จำเป็น แต่ถ้าการวิเคราะห์สถานการณ์ไม่จำเป็นต้องรู้ว่าเป็นใคร ก็ควรลดรายละเอียด ใช้ข้อมูลนามแฝง หรือใช้ข้อมูลรวมตามความเหมาะสม

แนวทางนี้สอดคล้องกับมาตรา 22 ของ PDPA ซึ่งกำหนดให้การเก็บรวบรวมข้อมูลส่วนบุคคลต้องจำกัดเท่าที่จำเป็นภายใต้วัตถุประสงค์อันชอบด้วยกฎหมาย หรือหลัก Data Minimization

การ “เชื่อมระบบ” ไม่เท่ากับ “เปิดเผยข้อมูลตลอดเวลา”

บัญชีท้ายระเบียบไม่ได้กำหนดให้ข้อมูลทุกชุดถูกนำส่งเข้าสู่ระบบกลางด้วยรูปแบบเดียวกัน

ข้อมูลบางชุดต้องเชื่อมและนำส่งตามที่กำหนด ขณะที่บางกลุ่ม โดยเฉพาะข้อมูลเกี่ยวกับประชาชนหรือสุขภาพ มีลักษณะให้เตรียมระบบสำหรับการเชื่อมโยงไว้ และนำส่งเมื่อเกิดเงื่อนไข เช่น มีการประกาศภัยพิบัติหรือสถานการณ์ฉุกเฉิน

จึงต้องแยก ความพร้อมในการเชื่อมต่อระบบ ออกจาก การเปิดเผยข้อมูลจริง

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

หากจะเรียกให้จำง่าย ผมเรียกหลักนี้ว่า

Always Connected, Conditionally Released — ระบบพร้อมเชื่อม แต่เปิดข้อมูลเมื่อมีเหตุและมีสิทธิ

แนวคิดนี้ควรเป็นหลักสำคัญประการหนึ่งของการออกแบบระบบแบ่งปันข้อมูลภาครัฐ

BDI เป็น Processor หรือ Controller?

อีกคำถามสำคัญตามหลัก PDPA คือสถานะของ สถาบันข้อมูลขนาดใหญ่ (องค์การมหาชน) หรือ BDI

ระเบียบกำหนดให้มีการจัดทำข้อตกลงการประมวลผลข้อมูล (Data Processing Agreement) กับสำนักงาน แต่ชื่อของข้อตกลงเพียงอย่างเดียวไม่สามารถกำหนดสถานะของ BDI ตาม PDPA ได้

สถานะต้องพิจารณาจากข้อเท็จจริงของการประมวลผล

หาก BDI ดำเนินการตามคำสั่งหรือในนามของผู้ควบคุมข้อมูล ก็มีลักษณะของผู้ประมวลผลข้อมูลส่วนบุคคล (Data Processor)

แต่หากในกิจกรรมใด BDI เป็นผู้มีอำนาจตัดสินใจเกี่ยวกับวัตถุประสงค์หรือวิธีการสำคัญของการประมวลผล ก็ต้องพิจารณาสถานะผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) ในกิจกรรมนั้น

หากมีหลายหน่วยงานร่วมกันกำหนดวัตถุประสงค์หรือวิธีการประมวลผล ก็ต้องพิจารณาความสัมพันธ์และกำหนดหน้าที่ความรับผิดของแต่ละฝ่ายให้ชัดเจน

ประเด็นนี้มีความสำคัญ เพราะระเบียบเปิดให้ระบบกลางทำได้มากกว่าการรับและส่งข้อมูล เช่น การแปลงสภาพข้อมูล การสร้างข้อมูลรวม การวิเคราะห์ รวมถึงการสร้างผลลัพธ์ในรูป Dashboard หรือแบบจำลองปัญญาประดิษฐ์

ดังนั้น การกำหนดสถานะของ BDI ควรวิเคราะห์เป็นรายกิจกรรม ไม่ควรกำหนดสถานะเดียวครอบคลุมทั้งระบบ

หน่วยงานจึงควรจัดทำ ตารางบทบาทในการประมวลผล เพื่อให้เห็นว่า ในแต่ละกิจกรรมใครเป็นผู้ควบคุมข้อมูล ผู้ประมวลผลข้อมูล ผู้รับข้อมูล หรือหน่วยงานผู้ครอบครองข้อมูล และใครต้องรับผิดชอบเรื่องใด

สิ่งที่ต้องระวังไม่ใช่เพียงข้อมูลรั่ว แต่คือการใช้ข้อมูลผิดวัตถุประสงค์

เมื่อพูดถึงการแบ่งปันข้อมูล คนจำนวนมากมักกังวลว่าข้อมูลจะรั่วหรือไม่ ซึ่งเรื่องความมั่นคงปลอดภัยเป็นเรื่องสำคัญแน่นอน

แต่ยังมีความเสี่ยงอีกด้านหนึ่ง คือ ข้อมูลไม่ได้รั่วออกจากระบบ แต่ถูกนำไปใช้เกินกว่าวัตถุประสงค์ที่กฎหมายรองรับ

ตัวอย่างเช่น ข้อมูลสุขภาพอาจถูกใช้เพื่อช่วยเหลือประชาชนในเหตุภัยพิบัติ โดยมีฐานกฎหมายรองรับ แต่เมื่อเหตุการณ์สิ้นสุดลง ข้อมูลชุดเดียวกันกลับถูกนำไปวิเคราะห์พฤติกรรมประชาชน หรือใช้ประกอบการตัดสินใจเรื่องอื่นที่ไม่มีฐานกฎหมายรองรับ

แม้ข้อมูลจะไม่เคยรั่วออกจากระบบ ก็อาจเกิดปัญหาการปฏิบัติตาม PDPA ได้

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

หลังเหตุฉุกเฉิน อย่าคิดว่าต้อง “ลบทั้งหมดทันที”

เมื่อภัยพิบัติสิ้นสุดลง หลักสำคัญคือไม่ควรเก็บข้อมูลไว้ต่อไปโดยไม่มีความจำเป็น

แต่การกำหนดให้ลบข้อมูลทั้งหมดทันทีอาจไม่เหมาะสมในทุกกรณี เพราะข้อมูลบางส่วนอาจยังจำเป็นต่อการเยียวยา การพิสูจน์สิทธิ การตรวจสอบย้อนหลัง การประเมินผลการตอบสนองต่อเหตุการณ์ หรือการปฏิบัติหน้าที่ตามกฎหมายอื่น

แนวทางที่เหมาะสมกว่าคือ การทบทวนการเก็บรักษาข้อมูลหลังสิ้นสุดเหตุการณ์ (Post-event Retention Review)

เมื่อเหตุการณ์จบลง หน่วยงานควรตรวจสอบว่า ข้อมูลใดยังจำเป็นต้องเก็บ ข้อมูลใดสามารถลดรายละเอียดได้ ข้อมูลใดควรทำให้ไม่สามารถระบุตัวบุคคล และข้อมูลใดหมดความจำเป็นจนควรลบหรือทำลาย

นี่คือการบริหารระยะเวลาจัดเก็บตามวัตถุประสงค์และความจำเป็น ไม่ใช่การกำหนดว่าจะ “เก็บทั้งหมด” หรือ “ลบทั้งหมด” ด้วยหลักเดียวกัน

หน่วยงานรัฐต้องทำอะไรในเวลาที่เหลือ?

ด้วยบทเฉพาะกาลของระเบียบกำหนดกรอบเวลาค่อนข้างสั้น หน่วยงานที่อยู่ในบัญชีท้ายระเบียบต้องดำเนินการเชื่อมโยงและนำข้อมูลเข้าสู่ระบบกลางภายใน 60 วัน และหากยังไม่มีความพร้อม ต้องประสานกับสำนักงานภายใน 15 วัน เพื่อกำหนดแนวทางและแผนการดำเนินงาน

เวลาในช่วงนี้จึงไม่ควรถูกใช้เฉพาะกับการพัฒนา API หรือการเชื่อมต่อทางเทคนิค

DPO ทีมกฎหมาย ทีมข้อมูล ทีมเทคโนโลยีสารสนเทศของหน่วยงานต่าง ๆ และ BDI ควรทำงานร่วมกันอย่างน้อยใน 5 เรื่อง

หนึ่ง ต้องรู้ว่ามีข้อมูลอะไรอยู่จริง

หน่วยงานต้องทำแผนผังข้อมูลให้ถึงระดับรายการข้อมูล ไม่ควรพิจารณาเพียงชื่อฐานข้อมูล เพราะความเสี่ยงจำนวนมากเกิดขึ้นในระดับ Data Element เช่น เลขประจำตัว ที่อยู่ ตำแหน่งที่อยู่ ข้อมูลสุขภาพ หรือข้อมูลที่สามารถนำไปเชื่อมโยงกับฐานอื่นแล้วระบุตัวบุคคลได้

สอง ต้องรู้ว่าใช้ฐานกฎหมายใด

ทุกการแบ่งปันต้องตอบได้ว่า ส่งข้อมูลอะไร เพื่ออะไร ให้ใคร อาศัยอำนาจตามกฎหมายใด และมีเงื่อนไขในการนำส่งเมื่อใด

สาม ต้องกำหนดบทบาทและความรับผิดชอบให้ชัด

ต้องทราบว่าในแต่ละกิจกรรม ใครเป็นผู้ควบคุมข้อมูล ผู้ประมวลผลข้อมูล ผู้รับข้อมูล หรือหน่วยงานผู้ครอบครองข้อมูล และใครมีหน้าที่รับผิดชอบต่อเจ้าของข้อมูลและต่อหน่วยงานกำกับดูแล

สี่ ต้องประเมินความเสี่ยงก่อนใช้งานจริง

กิจกรรมที่มีความเสี่ยงสูง เช่น การเชื่อมข้อมูลสุขภาพ ข้อมูลกลุ่มเปราะบาง การรวมข้อมูลจากหลายฐาน หรือการใช้ปัญญาประดิษฐ์ ควรผ่านการประเมินผลกระทบด้านการคุ้มครองข้อมูลส่วนบุคคล (Data Protection Impact Assessment: DPIA) และการประเมินความมั่นคงปลอดภัยที่เหมาะสม

ห้า ต้องมีขั้นตอนสำหรับเหตุฉุกเฉินไว้ก่อนเกิดเหตุ

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

เพราะเมื่อภัยพิบัติเกิดขึ้นจริง เราไม่มีเวลามาประชุมเพื่อตีความกฎหมายและกำหนดสิทธิกันใหม่

Data Governance กับ PDPA ไม่ได้อยู่คนละฝั่ง

ระเบียบฉบับนี้มีเป้าหมายที่เข้าใจได้ชัดเจน ภาครัฐไม่ควรต้องรอหนังสือราชการหลายวันกว่าจะทราบว่าพื้นที่ใดกำลังน้ำท่วม หรือประชาชนกลุ่มใดต้องได้รับการช่วยเหลือก่อน

แต่ความรวดเร็วไม่จำเป็นต้องแลกกับการคุ้มครองสิทธิ

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

สิ่งที่เราต้องการจึงเป็น การแบ่งปันข้อมูลที่มี Privacy และ Accountability อยู่ในการออกแบบตั้งแต่ต้น

ระเบียบสำนักนายกรัฐมนตรี ว่าด้วยการแบ่งปันข้อมูลดิจิทัล พ.ศ. 2569 จึงไม่ควรถูกมองว่าเป็นเพียงโครงการเชื่อมฐานข้อมูลของรัฐ

หากดำเนินการอย่างเหมาะสม นี่อาจเป็นจุดเริ่มต้นสำคัญของธรรมาภิบาลข้อมูลภาครัฐรูปแบบใหม่ของประเทศไทย

แต่หากเร่งเชื่อมระบบก่อน โดยยังตอบไม่ได้ว่าใช้ข้อมูลเพื่ออะไร อาศัยฐานกฎหมายใด ใครมีสิทธิเข้าถึง และใครรับผิดชอบ การมีเทคโนโลยีที่เชื่อมข้อมูลได้รวดเร็วก็อาจไม่ได้แก้ปัญหา

เพราะท้ายที่สุด หน่วยงานยังต้องตอบคำถามพื้นฐานให้ได้ว่า “ใครมีสิทธิใช้ข้อมูลนี้เพื่ออะไร และเพราะอะไร?”

ซึ่งคำถามนี้ควรมีคำตอบที่ชัดเจน ก่อนข้อมูลชุดแรกถูกส่งผ่านระบบกลาง

 

ย้อนอ่านบทความตอนที่แล้ว:

คลิกเลย -> AiPASS กับองค์กร โอกาสพัฒนาทักษะ AI ของพนักงาน และโจทย์การกำกับการใช้ AI อย่างมีธรรมาภิบาล (ตอนที่ 4)

AiPASS กับองค์กร โอกาสพัฒนาทักษะ AI ของพนักงาน และโจทย์การกำกับการใช้ AI อย่างมีธรรมาภิบาล

/in

AiPASS กับองค์กร โอกาสพัฒนาทักษะ AI ของพนักงาน
และโจทย์การกำกับการใช้ AI อย่างมีธรรมาภิบาล

ดร.อุดมธิปก ไพรเกษตร นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย

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

ดร.ณัฏฐ์ ธนวนกุล ประธานฝ่ายมาตรฐานการคุ้มครองข้อมูลส่วนบุคคล สมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย

เมื่อโครงการ TH-AI Passport และแพลตฟอร์ม AiPASS เริ่มได้รับความสนใจจากสาธารณชนมากขึ้น พวกเราได้รับคำถามของผู้บริหารและเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (Data Protection Officer: DPO) ไม่ใช่แค่ประเด็นว่า “พนักงานควรสมัครหรือไม่” แต่ขยับไปสู่คำถามสำคัญกว่า คือ “องค์กรควรสนับสนุนให้พนักงานใช้ AiPASS หรือไม่ และหากใช้ องค์กรควรกำกับอย่างไร”

คำถามนี้ควรแยกออกเป็นสองเรื่องตั้งแต่ต้น เรื่องแรกคือ การเปิดโอกาสให้พนักงานใช้ AiPASS เพื่อเรียนรู้และพัฒนาทักษะด้านปัญญาประดิษฐ์ (Artificial Intelligence: AI) ส่วนเรื่องที่สองคือ การนำ AiPASS มาใช้ทำงานจริงขององค์กร ซึ่งอาจเกี่ยวข้องกับข้อมูล ระบบงาน ลูกค้า พนักงาน หรือบุคคลอื่น

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

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

1. AiPASS เป็นโอกาสขององค์กรในการพัฒนาความรู้เท่าทันและทักษะการใช้ AI (AI Literacy)
องค์กรควรเปิดโอกาสให้พนักงานเรียนรู้และทดลองใช้ AI เพราะความรู้เท่าทันและความสามารถในการใช้ AI (AI Literacy) กำลังเป็นทักษะพื้นฐานของคนทำงาน เช่นเดียวกับทักษะดิจิทัลที่องค์กรต้องพัฒนาอย่างต่อเนื่อง และ AiPASS สามารถเป็นหนึ่งในเครื่องมือสำหรับการเรียนรู้ดังกล่าวได้
สิ่งที่องค์กรควรมุ่งหวังไม่ใช่เพียงให้พนักงาน “ใช้ AI เป็น” ในความหมายว่าเขียนคำสั่ง (Prompt) ได้ แต่ต้องเข้าใจด้วยว่า AI ทำอะไรได้ อะไรทำไม่ได้ คำตอบใดต้องตรวจสอบ และมีความเสี่ยงอะไรอยู่เบื้องหลัง เช่น การสร้างข้อมูลที่ผิดแต่ดูน่าเชื่อถือ (Hallucination) ความเป็นส่วนตัว (Privacy) ความมั่นคงปลอดภัยไซเบอร์ (Cybersecurity) และลิขสิทธิ์ (Copyright)

ในช่วงเริ่มต้น ควรให้พนักงานเรียนรู้จากงานความเสี่ยงต่ำ เช่น การระดมความคิด การร่างข้อความทั่วไป การสรุปข้อมูลสาธารณะ การแปลภาษา การทดลองเขียน Prompt หรือการสร้างเนื้อหาที่ไม่ใช้ข้อมูลส่วนบุคคลและข้อมูลลับขององค์กร เนื่องจาก “การอนุญาตให้ใช้ AI ไม่ได้แปลว่าอนุญาตให้นำข้อมูลทุกอย่างเข้า AI”

2. “เรียนรู้ AI” กับ “ใช้ AI ทำงาน” เป็นคนละเรื่อง
เส้นแบ่งสำคัญเกิดขึ้นทันทีเมื่อพนักงานไม่ได้ใช้ AiPASS เพื่อทดลองส่วนตัวหรือเรียนรู้จากข้อมูลสาธารณะ แต่ใช้เพื่อทำงานตามหน้าที่ขององค์กร เช่น ร่างเอกสารจากข้อมูลลูกค้า สรุปข้อมูลพนักงาน วิเคราะห์ข้อมูลที่องค์กรถือครอง หรือใช้ผลลัพธ์จาก AI เป็นส่วนหนึ่งของกระบวนการตัดสินใจ

กรณีดังกล่าว การที่พนักงานเป็นผู้ลงทะเบียนบัญชีหรือเป็นผู้พิมพ์ Prompt ด้วยตนเอง ไม่ได้ทำให้กิจกรรมนั้นกลายเป็นเรื่องส่วนตัวของพนักงาน หากพนักงานใช้ AiPASS ตามวัตถุประสงค์และหน้าที่ที่องค์กรกำหนด องค์กรยังคงต้องรับผิดชอบต่อการประมวลผลข้อมูลที่เกิดขึ้นในกิจกรรมนั้น
หากมีข้อมูลส่วนบุคคลเข้ามาเกี่ยวข้อง องค์กรต้องพิจารณาหน้าที่ตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (Personal Data Protection Act: PDPA) ของตนเอง เช่น
– วัตถุประสงค์ของการประมวลผลตามมาตรา 21
– การเก็บรวบรวมเท่าที่จำเป็นตามมาตรา 22
– การแจ้งประกาศความเป็นส่วนตัวตามมาตรา 23 หรือมาตรา 25
– ฐานกฎหมายตามมาตรา 24 หรือมาตรา 26 สำหรับข้อมูลส่วนบุคคลอ่อนไหว
– การใช้หรือเปิดเผยตามมาตรา 27
– การส่งหรือโอนข้อมูลไปต่างประเทศตามมาตรา 28 และ 29
– การรักษาความมั่นคงปลอดภัยตามมาตรา 37 และ
– การรองรับสิทธิของเจ้าของข้อมูลส่วนบุคคลตามมาตรา 19, 20, 30-34 และ 36

หลักสำคัญคือ “ฐานกฎหมายของแพลตฟอร์มไม่ใช่ฐานกฎหมายขององค์กร” การที่ผู้ให้บริการแพลตฟอร์มมีวัตถุประสงค์และฐานกฎหมายสำหรับการประมวลผลของตนเอง ไม่ได้ทำให้องค์กรสามารถนำข้อมูลลูกค้า คู่ค้า พนักงาน หรือบุคคลอื่นเข้าแพลตฟอร์มได้โดยอัตโนมัติ เพราะวัตถุประสงค์และฐานกฎหมายสำหรับการประมวลผลขององค์กรย่อมแตกต่างไปจากผู้ให้บริการแพลตฟอร์มตามภารกิจหรือบริบทที่แตกต่างกัน

สำหรับ AiPASS ข้อมูลส่วนบุคคลและข้อมูลลับควรถูกจำกัดไว้เป็นค่าเริ่มต้น

ในเชิงนโยบายขององค์กร สำหรับการใช้ AiPASS กับงานจริง ข้อมูลส่วนบุคคลและข้อมูลลับขององค์กรควรถูกกำหนดเป็น “จำกัดการนำเข้าไว้เป็นค่าเริ่มต้น” (Restricted by Default) กล่าวคือ ไม่ให้นำเข้าโดยปริยาย จนกว่ากรณีการใช้งาน (Use Case) นั้นจะได้รับการประเมินและอนุมัติเป็นการเฉพาะ และองค์กรเห็นว่ามีมาตรการควบคุมที่เหมาะสม จนอยู่ในระดับความเสี่ยงตามเกณฑ์ที่ยอมรับได้

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

3. บัญชีผูกกับพนักงาน แต่ความรับผิดชอบยังอยู่ที่องค์กร
สำนักงานคณะกรรมการดิจิทัลเพื่อเศรษฐกิจและสังคมแห่งชาติ (สดช.) ระบุสถานะของตนเป็นผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) สำหรับการดำเนินโครงการและแพลตฟอร์ม AiPASS ขณะเดียวกัน หากองค์กรกำหนดให้พนักงานใช้ AiPASS เพื่อดำเนินกิจกรรมขององค์กรที่มีการประมวลผลข้อมูลส่วนบุคคล องค์กรก็เป็น Data Controller สำหรับกิจกรรมขององค์กรนั้น

จึงต้องแยกให้ชัดว่า การประมวลผลใดเกิดขึ้นเพื่อวัตถุประสงค์ของแพลตฟอร์ม และการประมวลผลใดเกิดขึ้นเพื่อวัตถุประสงค์ขององค์กร ทั้งสองฝ่ายต่างมีความรับผิดชอบต่อกิจกรรมการประมวลผลที่ตนเป็นผู้กำหนดวัตถุประสงค์และวิธีการ โดยไม่ควรถือโดยอัตโนมัติว่า AiPASS เป็นผู้ประมวลผลข้อมูลส่วนบุคคล (Data Processor) ขององค์กรในทุกกรณี

ประเด็นสำคัญที่องค์กรต้องพิจารณาเพิ่มเติมคือ จากการตรวจสอบระบบโดยผู้เขียน ณ วันที่ 26 สิงหาคม 2569 ระบบ AiPASS ไม่มีระบบควบคุมสำหรับผู้ดูแลระดับองค์กร (Enterprise Admin Control) องค์กรจึงไม่มีระบบบริหารจัดการจากส่วนกลาง (Admin Console) สำหรับบริหารบัญชีพนักงานหรือตรวจสอบบันทึกการใช้งานระดับองค์กร (Audit Log) กำหนดวงจรการเก็บหรือลบข้อมูล หรือจัดการบัญชีและข้อมูลในรูปแบบเดียวกับบริการ AI ที่ออกแบบมาสำหรับองค์กร (Enterprise) ซึ่ง “การไม่มีเครื่องมือควบคุมระดับองค์กร (Enterprise Control) ไม่ได้ทำให้องค์กรมีหน้าที่น้อยลง แต่ทำให้องค์กรต้องออกแบบมาตรการควบคุมขององค์กร (Organizational Control) ให้ชัดเจนยิ่งขึ้น”

การมีมาตรการด้านความเป็นส่วนตัวของแพลตฟอร์มจึงไม่ควรถูกตีความว่าแพลตฟอร์มนั้นเหมาะกับกรณีการใช้งานระดับองค์กร (Enterprise Use Case) ทุกประเภท สิ่งที่องค์กรต้องถามต่อคือ เมื่อองค์กรไม่มีเครื่องมือควบคุมระดับองค์กรบนแพลตฟอร์ม องค์กรจะควบคุมส่วนที่อยู่ในอำนาจของตนเองอย่างไร

4. เมื่อแพลตฟอร์มไม่มีเครื่องมือควบคุมระดับองค์กร องค์กรต้องสร้างระบบกำกับของตนเอง
การกำกับดูแลเรื่องนี้ไม่ใช่การห้ามใช้ AiPASS แบบเหมารวม แต่คือการสร้าง “มาตรการควบคุมทดแทน” (Compensating Controls) ภายนอกแพลตฟอร์ม เพื่อให้การใช้ AiPASS โดยพนักงาน แต่เพื่อประโยชน์ขององค์กรยังอยู่ภายใต้กติกาและความรับผิดชอบที่องค์กรกำหนดได้

4.1 ใช้บัญชีอีเมลที่องค์กรควบคุม (Organization-controlled Email Account) เป็นมาตรการควบคุมทดแทน
หากองค์กรสนับสนุนให้พนักงานเข้าร่วมโครงการและต้องการให้ใช้ AiPASS เพื่อทำงานขององค์กร ควรกำหนดให้ลงทะเบียนด้วยบัญชีอีเมลที่องค์กรเป็นผู้จัดหา ลงทะเบียน เป็นเจ้าของ และสามารถบริหารวงจรชีวิตของบัญชีได้ ไม่ว่าจะเป็นอีเมลภายใต้โดเมนขององค์กร หรือบัญชี Google, Microsoft หรือ Apple ที่องค์กรสร้างและควบคุม แม้บัญชีนั้นจะใช้บริการแบบไม่มีค่าใช้จ่ายก็ตาม

ไม่ควรใช้อีเมลส่วนตัวที่พนักงานเป็นเจ้าของเพื่อทำงานขององค์กร เพราะเมื่อเปลี่ยนหน้าที่ พ้นสภาพพนักงาน หรือมีเหตุที่ต้องยุติสิทธิ องค์กรจะควบคุมช่องทางที่ผูกกับการใช้งานได้ยากขึ้น

มาตรการนี้ไม่ใช่ Admin Control ของ AiPASS แต่เป็น Organizational Control ที่องค์กรสร้างขึ้นเอง และเนื่องจาก AiPASS มีการยืนยันตัวตนของผู้ใช้ บัญชีที่ใช้ทำงานควรเป็นบัญชีของพนักงานแต่ละราย ไม่ใช่บัญชีร่วม และไม่ควรแชร์รหัสผ่าน (Password) หรือข้อมูลรับรองการเข้าถึง (Credential) ระหว่างกัน

4.2 อนุมัติ Use Case ไม่ใช่อนุมัติเพียงชื่อเครื่องมือ
การประกาศว่า “ใช้ AiPASS ได้” หรือ “ห้ามใช้ AiPASS” เป็นคำสั่งที่กว้างเกินไป เพราะเครื่องมือเดียวกันอาจใช้กับงานที่มีความเสี่ยงต่างกันมาก ตั้งแต่การถามคำถามทั่วไป การวาดภาพ หรือการร่างข้อความจากข้อมูลสาธารณะ ไปจนถึงการอัปโหลดข้อมูลลูกค้าเพื่อวิเคราะห์
องค์กรจึงควรอนุมัติวิธีใช้ ไม่ใช่อนุมัติเพียงชื่อเครื่องมือ (Approve the Use Case, not just the Tool) โดยพิจารณาอย่างน้อย 5 เรื่องพร้อมกัน ได้แก่

การใช้งาน (Use Case) ว่า…ใช้ AI ทำอะไร?
ข้อมูล (Data) ว่า…ใช้ข้อมูลประเภทใด?
โมเดล (Model) ว่า…ใช้โมเดลหรือผู้ให้บริการใด?
ผู้ตรวจสอบและผู้รับผิดชอบ (Human) ว่า…เป็นใคร?
ความเสี่ยง (Risk) ว่า…หากผิดพลาดหรือข้อมูลรั่วไหลจะเกิดผลกระทบอะไร?

4.3 กำหนดกติกาเรื่องการใช้ข้อมูลขององค์กร
กรอบ Green-Amber-Red คือกติกาใช้งานภายในองค์กร ไม่ใช่กรอบที่ทำให้ข้อมูลทุกประเภท “ใช้ผ่าน AiPASS” ได้โดยอัตโนมัติ
• Green คือข้อมูลที่ใช้ได้หากเป็นข้อมูลสาธารณะ งานระดมความคิด การแปล การสร้างโครงร่าง หรือเนื้อหาที่ไม่เกี่ยวกับข้อมูลส่วนบุคคลและข้อมูลลับ โดยยังต้องตรวจสอบผลลัพธ์ก่อนใช้
• Amber คือข้อมูลภายในองค์กรระดับทั่วไปที่ไม่ใช่ความลับ ข้อมูลสังเคราะห์ (Synthetic Data) หรือข้อมูลส่วนบุคคลที่ผ่านการทำข้อมูลแฝง (Pseudonymization) แล้ว สามารถใช้ได้ตามเงื่อนไขและแนวปฏิบัติที่องค์กรกำหนดไว้เฉพาะ
• Red คือการจำกัดการนำเข้าข้อมูลไว้เป็นค่าเริ่มต้น (Restricted by Default) เมื่อเกี่ยวข้องกับข้อมูลส่วนบุคคล ข้อมูลส่วนบุคคลอ่อนไหว ข้อมูลสุขภาพตาม PDPA ข้อมูลทางการเงิน ความลับทางการค้า เอกสารสัญญาที่เป็นความลับ ซอร์สโค้ด (Source Code) ที่สำคัญ รวมถึงข้อมูลที่องค์กรยังไม่ได้ประเมิน ส่วนรหัสผ่าน (Password) ข้อมูลรับรองการเข้าถึง (Credential) กุญแจ API (API Key) และกุญแจส่วนตัว (Private Key) ควรกำหนดเป็นข้อมูลที่ห้ามนำเข้าสู่ระบบ AI โดยเด็ดขาด

หากมีการทำข้อมูลแฝง (Pseudonymisation) ต้องเข้าใจว่าไม่เท่ากับการทำข้อมูลนิรนาม (Anonymisation) การลบเพียงชื่อหรือเลขประจำตัวไม่ได้ทำให้ข้อมูลพ้นจากการเป็นข้อมูลส่วนบุคคลโดยอัตโนมัติ หากยังสามารถเชื่อมโยงกลับไปหาบุคคลได้


4.4 ต้องมีนโยบาย การกำกับโดยมนุษย์ และกระบวนการรับมือเหตุการณ์
องค์กรควรมีนโยบายการใช้งาน AI ที่ยอมรับได้ (AI Acceptable Use Policy) ระบุว่าเครื่องมือใดใช้ได้ ใช้กับงานอะไร ข้อมูลใดนำเข้าได้ ข้อมูลใดต้องขออนุมัติ ผลลัพธ์ต้องตรวจสอบอย่างไร บัญชีใดได้รับอนุญาต และหากนำข้อมูลผิดประเภทเข้าสู่ระบบต้องแจ้งใคร

Use Case ที่มีผลกระทบสูง เช่น การคัดกรองผู้สมัครงาน การประเมินพนักงาน การประเมินเครดิต หรือการใช้ข้อมูลสุขภาพ ควรได้รับการประเมินผลกระทบและควบคุมให้เหมาะสมกับระดับความเสี่ยง เช่น การประเมินผลกระทบด้านการคุ้มครองข้อมูลส่วนบุคคล (Data Protection Impact Assessment: DPIA) หรือการประเมินผลกระทบด้าน AI และ Privacy ตามบริบทของกิจกรรมและบริบทขององค์กร

องค์กรควรกำหนดการกำกับโดยมนุษย์ (Human Oversight) โดยเฉพาะการใช้ AI ในการตัดสินใจที่มีผลสำคัญต่อบุคคล และหากองค์กรมี Use Case จำนวนมาก ในหลายส่วนงาน การจัดทำทะเบียนกรณีการใช้ AI (AI Use Case Register) จะช่วยให้สามารถติดตามเจ้าของงาน ระดับความเสี่ยง และมาตรการควบคุมได้อย่างเป็นระบบและตรวจสอบได้

สำหรับ AiPASS องค์กรอาจมีทะเบียนบัญชี AI ที่ได้รับอนุมัติ (Approved AI Account Register) เพิ่มเติม เพื่อบันทึกว่าใครได้รับอนุญาตให้ใช้บัญชีใด เพื่อ Use Case ใด อยู่ภายใต้หน่วยงานใด และเมื่อใดต้องทบทวนหรือยุติสิทธิ

หากพนักงานเผลอส่งข้อมูลที่ไม่ควรนำเข้าสู่ AI ต้องมีขั้นตอนการรับมือเหตุการณ์ (Incident Response) ที่ชัดเจน ให้หยุดส่งข้อมูลเพิ่มเติม เก็บข้อเท็จจริง แจ้งฝ่ายที่เกี่ยวข้อง เช่น ฝ่ายความมั่นคงปลอดภัยสารสนเทศ DPO หรือฝ่ายกฎหมาย และประสานผู้ให้บริการเพื่อจำกัดหรือลบข้อมูลเท่าที่ทำได้ หากเข้าข่ายเหตุละเมิดข้อมูลส่วนบุคคล (Personal Data Breach) ต้องประเมินหน้าที่ตามมาตรา 37(4) ของ PDPA (ซึ่งการที่องค์กรทำความเข้าใจแผนภาพการไหลของข้อมูล (Data Flow) ตั้งแต่จุดที่พิมพ์ Prompt ข้อมูลวิ่งผ่านโมเดลใด ไปจนถึงเซิร์ฟเวอร์ปลายทาง จะช่วยให้ประเมินขอบเขตผลกระทบได้อย่างแม่นยำ)

หากเหตุละเมิดมีความเสี่ยงต่อสิทธิและเสรีภาพของบุคคล ต้องแจ้งสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) โดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ทราบเหตุเท่าที่สามารถกระทำได้ และหากมีความเสี่ยงสูงต่อสิทธิและเสรีภาพของบุคคล นอกจากต้องแจ้ง สคส. แล้วยังต้องแจ้งเจ้าของข้อมูลส่วนบุคคลโดยไม่ชักช้าด้วย


4.5 จะใช้ AiPASS ต้องคิดถึงวันจบโครงการตั้งแต่วันเริ่มใช้
อีกประเด็นที่องค์กรไม่ควรมองข้ามคือ “แผนยุติหรือเปลี่ยนผ่านการใช้งาน (Exit Plan)” เมื่อโครงการ TH-AI Passport สิ้นสุดลง หรือเงื่อนไขการให้บริการเปลี่ยนไป องค์กรต้องตอบให้ได้ว่า ข้อมูลขององค์กรที่เคยถูกนำไปใช้กับ AiPASS จะจัดการอย่างไร บัญชีจะถูกยุติหรือเปลี่ยนผ่านอย่างไร และหากมีระบบหรือกระบวนการทำงานอื่นเชื่อมโยงกับ AI จาก AiPASS จะย้าย หยุด หรือทดแทนอย่างไร

ธรรมาภิบาลที่ดีจึงไม่ควรคิดเพียงเรื่องการเริ่มใช้งาน (Onboarding) ว่าจะเริ่มใช้ AI อย่างไร แต่ต้องคิดถึงการยุติสิทธิหรือพ้นสภาพผู้ใช้งาน (Offboarding) และการยุติหรือเปลี่ยนผ่านระบบ (Exit) ตั้งแต่ต้นด้วย


5. เริ่มจากโครงการนำร่อง (Pilot) แล้วค่อยขยาย ไม่เปิดทุกงานพร้อมกัน
องค์กรที่ต้องการใช้ AiPASS หรือปัญญาประดิษฐ์เชิงสร้างสรรค์ (Generative AI) เพื่อเพิ่มประสิทธิภาพ ไม่ควรเริ่มจากการเปิดใช้กับทุกงานและทุกข้อมูลพร้อมกัน แต่ควรเริ่มจาก Use Case ความเสี่ยงต่ำ 3–5 เรื่อง ในระดับ Green เช่น การร่างเอกสารจากข้อมูลทั่วไป การสรุปข้อมูลสาธารณะ การแปลภาษา หรือการระดมความคิด

หากเป็นโครงการนำร่อง (Pilot) ในนามองค์กร ควรใช้บัญชีอีเมลที่องค์กรควบคุมตั้งแต่เริ่มต้น เพื่อให้รูปแบบการทดลองสอดคล้องกับวิธีที่จะใช้จริงเมื่อขยายผล และควรกำหนดเจ้าของ Use Case ผู้ตรวจสอบผลลัพธ์ และประเภทข้อมูลที่อนุญาตให้ใช้ตั้งแต่ต้น

จากนั้นจึงวัดผลจากการใช้งานจริงว่า AI ช่วยประหยัดเวลาหรือเพิ่มคุณภาพงานเพียงใด เกิดการสร้างข้อมูลที่ผิดแต่ดูน่าเชื่อถือ (Hallucination) มากน้อยเพียงใด มีการนำข้อมูลผิดประเภทเข้าสู่ระบบหรือไม่ การกำกับโดยมนุษย์ (Human Oversight) เพียงพอหรือไม่ และที่สำคัญ องค์กรสามารถกำกับการใช้งานได้จริงเพียงใด และมีแผนยุติหรือเปลี่ยนผ่านการใช้งาน (Exit Plan) อย่างไร?

เมื่อเข้าใจทั้งประโยชน์และข้อจำกัดแล้ว จึงค่อยขยายไปสู่ Use Case ที่ซับซ้อนขึ้น การขยายผลจึงไม่ใช่เพียงเรื่อง “AI ทำงานได้ดีแค่ไหน” แต่รวมถึง “องค์กรควบคุมการใช้ AI ได้ดีแค่ไหน” ด้วย

สรุปคำถาม 7 ข้อที่ผู้บริหารควรถามก่อนให้ใช้ AiPASS ทำงานขององค์กร
• Use Case นี้ใช้ AI ทำอะไร และใครเป็นเจ้าของงาน?
• จะนำข้อมูลประเภทใดเข้าไป และมีข้อมูลส่วนบุคคล (Personal Data) หรือข้อมูลลับหรือไม่?
• ข้อมูลและ Prompt จะไหลไปที่ใด ผ่านโมเดลหรือผู้ให้บริการใด และองค์กรเข้าใจการไหลของข้อมูล (Data Flow) เพียงพอหรือยัง?
• พนักงานใช้บัญชีใด และบัญชีนั้นอยู่ภายใต้การควบคุมขององค์กรหรือไม่?
• ใครตรวจสอบผลลัพธ์จาก AI (AI Output) และใครรับผิดชอบเมื่อนำผลลัพธ์ไปใช้?
• หากส่งข้อมูลผิด เกิดเหตุการณ์ผิดปกติ (Incident) หรือพนักงานพ้นสภาพ องค์กรจะจัดการอย่างไร?
• ถ้าโครงการสิ้นสุดหรือเงื่อนไขเปลี่ยน องค์กรมี Exit Plan สำหรับข้อมูล บัญชี และระบบที่เชื่อมโยงแล้วหรือยัง?
จุดยืนของสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย (TPDPA)

ในด้านการพัฒนาความรู้และทักษะ เราสนับสนุนให้องค์กรเปิดโอกาสให้พนักงานเรียนรู้และทดลองใช้ AI และ AiPASS สามารถเป็นหนึ่งในเครื่องมือสำหรับสร้าง AI Literacy ได้
แต่การสนับสนุนให้เรียนรู้ AI ไม่ได้หมายความว่าองค์กรรับรองให้ใช้แพลตฟอร์มกับข้อมูลทุกประเภทโดยไม่มีเงื่อนไข เมื่อพนักงานใช้ AiPASS เพื่อทำงานขององค์กร ความรับผิดชอบขององค์กรไม่ได้หายไปตามรูปแบบของบัญชี องค์กรจึงต้องกำหนด Use Case ประเภทข้อมูล บัญชีที่อนุญาต วิธีตรวจสอบผลลัพธ์ และผู้รับผิดชอบให้ชัดเจน

สำหรับ AiPASS โดยเฉพาะ ข้อจำกัดจากการไม่มีระบบควบคุมสำหรับผู้ดูแลระดับองค์กร และเงื่อนไขของโครงการต้องถูกนำมาพิจารณา หากองค์กรจะใช้ AiPASS ในการทำงาน องค์กรต้องสร้างระบบกำกับของตนเอง โดยบัญชีอีเมลที่องค์กรควบคุม (Organization-controlled Email Account) เป็นเพียงหนึ่งในมาตรการสำคัญ และต้องทำงานร่วมกับนโยบาย การควบคุม Use Case การควบคุมข้อมูล การกำกับโดยมนุษย์ การรับมือเหตุการณ์ และ Exit Plan

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

แหล่งข้อมูลที่ใช้ตรวจสอบ
• พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 — ราชกิจจานุเบกษา
• ประกาศความเป็นส่วนตัวแพลตฟอร์ม AiPASS ภายใต้โครงการ TH-AI Passport ฉบับ 1.0 มีผลใช้บังคับวันที่ 19 สิงหาคม 2569 — https://de.aipass.net/privacy-policy
• การตรวจสอบคุณสมบัติและการทำงานของระบบ AiPASS โดยผู้เขียน ณ วันที่ 26 สิงหาคม 2569 สำหรับประเด็น Enterprise Admin Control
• ข้อกำหนดและเงื่อนไขสำหรับประชาชนที่เข้าร่วมโครงการ TH-AI Passport มีผลใช้บังคับวันที่ 19 สิงหาคม 2569 — https://de.aipass.net/term-and-cond-th
• เว็บไซต์และคำถามที่พบบ่อยของโครงการ TH-AI Passport — https://de.aipass.net/ และ https://de.aipass.net/faq
เอกสารสาธารณะของ AiPASS ที่ใช้ตรวจสอบเป็นข้อมูลล่าสุด ณ วันที่ 26 สิงหาคม 2569

หมายเหตุ: เอกสาร เงื่อนไข และความสามารถของแพลตฟอร์มอาจมีการปรับปรุง องค์กรควรตรวจสอบฉบับล่าสุดก่อนใช้กับข้อมูลจริงหรือ Use Case ที่มีความเสี่ยงสูง

เมื่อพนักงานเริ่มใช้ AiPASS: องค์กรพร้อมรับมือความเสี่ยงด้าน PDPA แล้วหรือยัง?

ก้าวแรกของการกำหนดนโยบาย AI ภายในองค์กรให้สอดคล้องกับกฎหมาย ไม่ใช่การออกคำสั่งห้ามใช้งาน แต่คือการสร้าง “ภูมิคุ้มกันด้านความเป็นส่วนตัว” ให้แก่พนักงาน เจาะลึกประเด็นที่ผู้ใช้งานต้องตั้งคำถามกับตนเอง ตั้งแต่วัตถุประสงค์ในการประมวลผล ไปจนถึงความเสี่ยงของการส่งต่อข้อมูลส่วนบุคคลผ่านแพลตฟอร์ม

ย้อนอ่านบทความตอนที่แล้ว:

คลิกเลย -> สร้างความตระหนักรู้เรื่องความเป็นส่วนตัว จาก AiPASS: คำถามที่ต้องถามตนเองก่อนใช้ (ตอนที่ 3)

สร้างความตระหนักรู้เรื่องความเป็นส่วนตัว จาก AiPASS คำถามที่ต้องถามตนเองก่อนใช้

/in

ดร.อุดมธิปก ไพรเกษตร นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย

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

อาจารย์มยุรี ชวนชม ประธานฝ่ายคุ้มครองข้อมูลส่วนบุคคล สมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย

ช่วงนี้มีคนถามพวกเราบ่อย ๆ ว่า
“ควรสมัคร AiPASS ไหม?”

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

แต่คำถามที่สำคัญกว่าคือ

“ก่อนสมัครใช้งาน คุณรู้หรือไม่ว่า จะเกิดอะไรขึ้นกับข้อมูลของคุณ?” เพราะการที่คุณสมัครใช้งานปัญญาประดิษฐ์ใด ๆ ไม่ว่าจะมาจาก ผู้ให้บริการ (Provider) เจ้าใด ไล่มาตั้งแต่ ChatGPT ของค่าย OpenAI, Gemini ของค่าย Alphabet, Claude ของค่าย Anthropic มิใยต้องเอ่ยถึง AiPASS ของค่ายรัฐบาลไทยนั้น

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

ในมุมมองที่ปรึกษา สมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย (TPDPA) จึงอยากชวนให้คุณผู้อ่านทุกคนในฐานะเจ้าของข้อมูลส่วนบุคคล (Data Subject) ถามตัวเองด้วย 9 ข้อที่สมาคมฯ มองว่าสำคัญ ก่อนสมัครใช้บริการ AiPASS เพื่อสร้างสังคม Smart Consumers หรือ ผู้บริโภคที่รู้เท่าทัน เข้าใจสิทธิของตนเอง และรู้จักคิดก่อนใช้ AI

1. บริการนี้คุ้มกับข้อมูลส่วนบุคคลและความเป็นส่วนตัวที่คุณต้องให้หรือไม่?

เมื่อเปิดอ่าน ประกาศความเป็นส่วนตัว (Privacy Notice) 
https://de.aipass.net/privacy-policy-th ลองถามตัวเองก่อนว่า คุณต้องการบริการนี้จริงหรือไม่? เพื่อให้ได้ประโยชน์นั้น คุณต้องให้ข้อมูลส่วนบุคคลอะไรบ้าง? ข้อมูลส่วนบุคคลบางประเภทนั้น จำเป็นต่อการใช้บริการ AI หรือไม่?
และที่สำคัญถามตัวเองก่อนว่า “ประโยชน์ที่ได้รับ คุ้มกับข้อมูลส่วนบุคคลที่ต้องเปิดเผยหรือไม่?”

2. ใครเป็นคนรับผิดชอบข้อมูลส่วนบุคคลของคุณ?

ตาม พรบ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 หรือ PDPA ผู้ที่กำหนดวัตถุประสงค์และวิธีการเก็บ ใช้ หรือเปิดเผยข้อมูลส่วนบุคคล คือ ผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) ส่วนผู้ให้บริการด้านเทคนิคบางรายอาจเป็น ผู้ประมวลผลข้อมูลส่วนบุคคล (Data Processor)

สิ่งที่คุณทั้งในฐานะผู้ใช้บริการและฐานะเจ้าของข้อมูลส่วนบุคคลนั้นควรทราบว่า “ถ้าเกิดปัญหากับข้อมูลของฉัน ใครคือผู้รับผิดชอบ?” สามารถติดต่อใครได้ที่ไหน?

3. ระบบเก็บรวบรวมข้อมูลส่วนบุคคลอะไรเกี่ยวกับตัวคุณเพิ่มอีก?

ระหว่างใช้งานนั้น AI จะเก็บรวบรวมประวัติการสนทนา Log ข้อมูลอุปกรณ์ และพฤติกรรมการใช้งาน รวมถึงข้อมูลที่ระบบวิเคราะห์หรืออนุมาน (Inferred Data) ขึ้น
อย่าถามเพียงว่า “ตอนสมัครต้องกรอกอะไร?” แต่ควรถามว่า
“หลังจากเริ่มใช้แล้ว ระบบจะมีการเก็บรวบรวมข้อมูลส่วนบุคคลเพิ่มขึ้นอีก?”

4. ระบบนำข้อมูลของคุณไปใช้ทำอะไร?

ข้อมูลส่วนบุคคลประเภทเดียวกันอาจถูกนำไปใช้เพื่อหลายวัตถุประสงค์ เช่น เพื่อให้บริการ รักษาความมั่นคงปลอดภัย ตรวจสอบการใช้งาน วิเคราะห์หรือปรับปรุงระบบ รวมถึงการวิจัยหรือพัฒนา AI

หากผู้ให้บริการ (Provider) มีการประมวลผลในลักษณะดังกล่าว การให้ข้อมูลส่วนบุคคลเพื่อรับบริการไม่ได้หมายความว่าคุณต้องยอมให้ระบบใช้ข้อมูลนั้นเพื่อทุกวัตถุประสงค์โดยอัตโนมัติ นี่คือแนวคิดเรื่อง การใช้ข้อมูลตามวัตถุประสงค์ที่กำหนด (Purpose Limitation)

เวลาอ่าน Privacy Notice จึงควรดูทั้งว่า “เขาเก็บอะไร” และ “นำไปใช้เพื่ออะไร รวมถึงเรามีทางเลือกหรือไม่?”

5. ข้อมูลส่วนบุคคลของคุณถูกเปิดเผยให้ใครบ้าง และไปที่ไหน?
ในประกาศความเป็นส่วนตัวของ AiPASS นั้นมีการเปิดเผยข้อมูลส่วนบุคคลแก่บุคคลภายนอก ถึง 6 หน่วยงาน ได้แก่
(1) ผู้ให้บริการโมเดล AI (AI Model Providers)
(2) ระบบวิเคราะห์ของบุคคลที่สาม
(3) หน่วยงานบังคับใช้กฎหมาย
(4) ผู้ให้บริการคลาวด์ / ผู้ประมวลผลข้อมูล
(5) คู่สัญญา / ผู้ให้บริการภายนอก
(6) หน่วยงานภายนอกหรือหน่วยงานรัฐหรือเอกชนที่มีการเชื่อมโยงข้อมูลหรือแลกเปลี่ยนข้อมูลกับ สดช.

บางกรณี Prompt หรือไฟล์อาจถูกส่งไปประมวลผลในระบบหรือถูกส่งไปต่างประเทศ

PDPA ไม่ได้ห้ามการโอนข้อมูลไปต่างประเทศในลักษณะห้ามแบบเบ็ดเสร็จเด็ดขาด (Absolute Prohibition) แต่การโอนต้องเป็นไปตามเงื่อนไขที่กฎหมาย PDPA กำหนด

ในฐานะที่คุณเป็นผู้ใช้ คุณควรรู้เท่าที่ตรวจสอบได้ว่า
“ข้อมูลอะไรถูกส่งให้ใคร เพื่ออะไร และประมวลผลที่ใด?”
คำว่า “ข้อมูลเก็บอยู่ในประเทศไทย” จึงไม่ได้หมายความโดยอัตโนมัติว่าไม่มีข้อมูลส่วนใดออกไปประมวลผลนอกประเทศไทย เพราะสถานที่เก็บข้อมูลกับสถานที่ประมวลผลอาจไม่ใช่ที่เดียวกัน

6. ระบบเก็บข้อมูลของคุณไว้นานแค่ไหน
ข้อมูลส่วนบุคคลแต่ละประเภทอาจมีระยะเวลาเก็บรักษาแตกต่างกัน จึงควรดู ระยะเวลาเก็บรักษาข้อมูล (Retention Period) และวิธีลบข้อมูลของบริการในประกาศความเป็นส่วนตัว

สิ่งสำคัญคือต้องเข้าใจว่า
“ลบบัญชี ≠ ข้อมูลทุกประเภทถูกลบทันที”
ข้อมูลส่วนบุคคลบางประเภทอาจจำเป็นต้องเก็บต่อช่วงหนึ่งเพื่อปฏิบัติตามกฎหมาย รักษาความมั่นคงปลอดภัย ตรวจสอบ หรือจัดการข้อพิพาท

7. คุณมีสิทธิอะไร และใช้สิทธิอย่างไร
PDPA ให้สิทธิแก่คุณในฐานะเจ้าของข้อมูลส่วนบุคคล (Data Subject) ภายใต้หลักเกณฑ์และเงื่อนไขของ PDPA คุณอาจมีสิทธิที่จะขอเข้าถึง ขอแก้ไข ขอให้ลบ ทำลาย คัดค้านการประมวลผล หรือถอนความยินยอม ทั้งนี้สิทธิเหล่านี้มีเงื่อนไขและข้อยกเว้นตามกฎหมาย PDPA เป็นเรื่อง ๆ ไป

หากผู้ให้บริการ (Provider) นำข้อมูลส่วนบุคคลของคุณไปใช้เพื่อการวิจัย การวิเคราะห์ หรือการปรับปรุงระบบ ผู้ให้บริการก็ต้องมีกลไกในการจัดการหรือรองรับการใช้สิทธิจากคุณ หรือเสนอทางเลือกอื่น ในกรณีที่คุณในฐานะเจ้าของข้อมูลส่วนบุคคลไม่ประสงค์จะให้ข้อมูลส่วนบุคคลบางประเภท

8. กรณีมีปัญหา คุณจะติดต่อใคร?
Privacy Notice ที่ดีควรทำให้คุณในฐานะประชาชนทราบว่าจะติดต่อใครเมื่อมีปัญหา ไม่ว่าจะเป็นช่องทางของผู้ควบคุมข้อมูลส่วนบุคคลหรือเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (Data Protection Officer: DPO) ในกรณีที่องค์กรมีหรือกฎหมายกำหนดให้ต้องมี
หากต้องการแก้ไขข้อมูล คัดค้านการใช้ข้อมูล หรือพบความผิดปกติ แต่หาไม่เจอว่าจะติดต่อใคร นั่นก็เป็นข้อมูลหนึ่งที่ใช้ประกอบการตัดสินใจว่าเราจะเชื่อใจบริการนั้นมากน้อยเพียงใด

ซึ่งในประกาศความเป็นส่วนตัวของ AiPASS ระบุว่า สำนักงานคณะกรรมการดิจิทัลเพื่อเศรษฐกิจและสังคมแห่งชาติ (สดช.) คือผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) ในขณะที่ช่องทางการติดต่อ เจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) อยู่ที่งานอีเมลงานสารบรรณ saraban@bde.go.th

9. ข้อมูลที่คุณจะพิมพ์ลงไปใน AiPASS จำเป็นต่อผลลัพธ์ หรือไม่?
นี่อาจเป็นคำถามที่สำคัญที่สุดในบรรดาคำถามทั้งหมด

ในการใช้ AI ลองตรวจสอบตัวคุณเองด้วยคำถามย่อยดังนี้

ข้อมูลส่วนบุคคลที่คุณกำลังจะ prompt จำเป็นต่อผลลัพธ์หรือไม่?

สิ่งที่ prompt เป็นข้อมูลส่วนบุคคลของคุณหรือของคนอื่น?
เป็นข้อมูลส่วนบุคคลลักษณะพิเศษหรือไม่? ข้อมูลส่วนบุคคลลักษณะพิเศษ เช่น ข้อมูลสุขภาพ ข้อมูลศาสนา หรือพฤติกรรมทางเพศ ควรได้รับการพิจารณาก่อนเปิดเผยเพราะอาจนำไปสู่การเลือกปฏิบัติ หรือ อันตรายแก่สุขภาพชีวิตของเจ้าของข้อมูลส่วนบุคคล

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

หลักคิดง่าย ๆ คือ ใช้ AI ได้ แต่ไม่จำเป็นต้องใส่ทุกอย่างให้ AI รู้ แนวคิดนี้ตรงกับหลักการใช้ข้อมูลเท่าที่จำเป็น (Data Minimisation)

จาก AiPASS สู่ Privacy Literacy
หากคุณถามพวกเราว่า “ควรสมัคร AiPASS ไหม?”
คำตอบที่คุณได้รับคงไม่ใช่เพียง Yes หรือ No

เหนือกว่าคำว่า ควร หรือ ไม่ควรนั้น อยู่ที่คุณควรใช้โอกาสนี้ฝึกถามคำถามเกี่ยวกับข้อมูลส่วนบุคคลของตัวเองให้มากเพื่อให้เกิด ความรู้และความเข้าใจในการปกป้อง ควบคุม และจัดการข้อมูลส่วนบุคคลของตนเองในโลกดิจิทัล เพื่อป้องกันความเสี่ยงจากการถูกขโมยข้อมูลหรือนำไปใช้ในทางที่ผิด ซึ่งเรียกว่า “Privacy Literacy” ซึ่งเป็น หนึ่งในทักษะดิจิทัล (Digital Skill) ที่คุณในฐานะผู้ใช้งาน Ai ในฐานะ ประชาชน และในฐานะเจ้าของข้อมูลส่วนบุคคลต้องมี ไม่เฉพาะก่อนใช้ AiPASS แต่ก่อนใช้ AI และบริการดิจิทัลทุกระบบ

ศึกษาบทวิเคราะห์ต่อเนื่องในชุดโครงการ AiPASS & PDPA

หลังจากทำความเข้าใจการปกป้องสิทธิและความตระหนักรู้ในระดับบุคคลแล้ว ท่านสามารถศึกษาความเชื่อมโยงในมิตินโยบายภาครัฐและการกำกับดูแลระดับองค์กรได้ดังนี้:

ย้อนอ่านตอนที่ 2 (มิติการกำกับดูแลและ Privacy Notice ภาครัฐ):

คลิกเลย -> จากโครงการ TH-AI Passport สู่ AiPASS: อ่าน TOR และ Privacy Notice เมื่อวันนี้โจทย์สำคัญของ PDPA ภาครัฐคือ “ความเชื่อมั่น”

เจาะลึกการแปลงข้อกำหนดทางเทคนิคใน TOR สู่แบบแจ้งการประมวลผลข้อมูลส่วนบุคคล พร้อมประเด็นข้อกังวลเรื่อง Data Center และการส่งข้อมูลข้ามแดน

อ่านต่อตอนที่ 4 (มิติการบริหารความเสี่ยงและธรรมาภิบาลระดับองค์กร):

คลิกเลย -> AiPASS กับองค์กร: โอกาสพัฒนาทักษะ AI ของพนักงาน และโจทย์การกำกับการใช้ AI อย่างมีธรรมาภิบาล

เมื่อพนักงานนำ AiPASS มาใช้ในการทำงาน องค์กรควรมีกรอบนโยบาย AI Governance อย่างไรเพื่อป้องกันข้อมูลความลับทางธุรกิจและข้อมูลลูกค้าไม่ให้รั่วไหล

จากโครงการ TH-AI Passport สู่ AiPASS อ่าน TOR และ Privacy Notice เมื่อวันนี้โจทย์สำคัญของ PDPA ภาครัฐคือ “ความเชื่อมั่น”

/in

ดร.อุดมธิปก ไพรเกษตร
นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย
ผู้ก่อตั้งสื่อ PDPA Thailand

เมื่อวันที่ 7 กรกฎาคม 2569 ผมเคยเขียน บทความวิจารณ์ TOR โครงการ TH-AI Passport ในมุมของพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA)

https://tpdpa.or.th/tor-th-ai-passport-pdpa-analysis/

ตอนนั้นผมตั้งคำถามหลายเรื่อง ตั้งแต่ใครเป็นผู้ควบคุมข้อมูล ใช้ฐานกฎหมายอะไร ข้อมูลจะถูกส่งไปไหน ไปจนถึงการใช้ Prompt, File และข้อมูลพฤติกรรมของผู้ใช้

วันที่ 19 สิงหาคม 2569 โครงการเปิดให้ลงทะเบียนล่วงหน้าผ่าน AiPASS และมีเอกสารเพิ่มเติมให้ศึกษา ทั้ง Terms and Conditions, Privacy Notice ฉบับที่ 1.0 และ FAQ ทำให้หลายคำถามที่เคยมีเริ่มเห็นคำตอบมากขึ้น

ภายหลังมีการเผยแพร่รายละเอียดของสัญญาแก้ไขเพิ่มเติม ทำให้ทราบว่า TOR เป็นเอกสารแนบท้ายสัญญา ผนวก 1 ของสัญญาหลัก และมีการแก้ไข TOR บางข้อผ่านสัญญาแก้ไขเพิ่มเติม ขณะที่ข้อความในสัญญาหลักที่ไม่ได้แก้ไขยังคงมีผลผูกพันต่อไป

อย่างไรก็ตาม ผมยังไม่ได้เห็นสัญญาหลักและเอกสารแนบท้ายทั้งหมด การวิเคราะห์ในบทความนี้จึงไม่ควรนำ TOR หรือสัญญาแก้ไขเพิ่มเติมเพียงส่วนใดส่วนหนึ่งมาสรุปว่าการดำเนินงานผิดสัญญา แต่จะใช้เอกสารเหล่านี้ประกอบกับ Terms and Conditions, Privacy Notice และ FAQ เพื่อพิจารณาเฉพาะประเด็นที่เกี่ยวข้องกับการคุ้มครองข้อมูลส่วนบุคคล

อีกเรื่องที่ต้องแยกให้ชัดคือ TH-AI Passport เป็นชื่อโครงการ ส่วน AiPASS เป็นแพลตฟอร์มภายใต้โครงการ ดังนั้นบทความนี้ไม่ได้พยายามสรุปว่าโครงการผิด PDPA หรือผิดสัญญา แต่จะดูว่า จากสิ่งที่เปิดเผยต่อประชาชน วันนี้มีคำตอบเรื่องข้อมูลส่วนบุคคลแค่ไหน และยังมีอะไรที่ควรอธิบายให้ชัดขึ้น

1.หลายคำถามจาก TOR วันนี้มีคำตอบแล้ว

เรื่องแรกที่ชัดขึ้นคือ ใครเป็นผู้ควบคุมข้อมูล โดย Terms and Conditions ข้อ 4 และ Privacy Notice ข้อ 1.2 ระบุว่า สดช. เป็นผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) เรื่องนี้จึงไม่ต้องคาดเดาเหมือนตอนอ่าน TOR

Privacy Notice ยังแยกวัตถุประสงค์ ประเภทข้อมูล ระยะเวลาเก็บ ผู้รับข้อมูล การส่งข้อมูลต่างประเทศ และสิทธิของเจ้าของข้อมูลไว้ละเอียดกว่าที่เห็นใน TOR มาก ถือว่าเป็นพัฒนาการที่ดี

แต่ยังมีบางจุดที่ควรทำให้สอดคล้องกัน เช่น บางวัตถุประสงค์เขียนว่าใช้ทั้งฐานสัญญาและฐานภารกิจเพื่อประโยชน์สาธารณะ แต่ระบุมาตรา 24(4) เพียงมาตราเดียว ขณะที่ฐานสัญญาอยู่ในมาตรา 24(3) ส่วนการวิจัยและพัฒนา National LLM ปัจจุบัน Privacy Notice ระบุมาตรา 24(4) จึงควรอธิบายให้ชัดว่าการวิจัยดังกล่าวอยู่ภายใต้ภารกิจของ สดช. อย่างไร และมีส่วนใดที่ต้องพิจารณาฐานการวิจัยตามมาตรา 24(1) เพิ่มเติมหรือไม่

สำหรับผม ประเด็นเหล่านี้แก้ได้ด้วยการทำ Lawful Basis Mapping ให้ตรงกับการทำงานจริง และยังไม่ใช่เหตุที่จะสรุปว่าโครงการใช้ข้อมูลได้หรือไม่ได้

2.ข้อมูลไม่ได้อยู่แค่ในระบบ AiPASS และความรับผิดชอบก็ไม่ได้อยู่ที่ผู้รับจ้างหลักเพียงรายเดียว

สิ่งที่สำคัญกว่า Privacy Notice คือ เมื่อข้อมูลเดินทางต่อไปหาองค์กรอื่น ใครรับผิดชอบอะไรในแต่ละช่วง

ผู้รับจ้างหลักซึ่งพัฒนาและดูแลระบบน่าจะเป็นผู้ประมวลผลข้อมูลส่วนบุคคล (Data Processor) ในกิจกรรมที่ทำตามคำสั่งของ สดช. มาตรา 40 กำหนดหน้าที่ไว้ทั้งการทำตามคำสั่ง การรักษาความมั่นคงปลอดภัย การแจ้ง Data Controller เมื่อเกิดเหตุละเมิด และการจัดทำบันทึกกิจกรรมการประมวลผล ดังนั้นหน้าที่ของผู้รับจ้างไม่ได้มีแค่ทำให้ระบบใช้งานได้ แต่ต้องทำให้ข้อมูลถูกใช้ตามคำสั่งและวัตถุประสงค์ที่กำหนดด้วย

Privacy Notice ข้อ 4.4 ก็ระบุว่าผู้ให้บริการระบบหรือ Cloud ที่ประมวลผลตามคำสั่งของโครงการเป็น Data Processor ขณะที่ TOR ข้อ 4.10 ห้ามผู้รับจ้างนำข้อมูลของโครงการไปใช้เพื่อกิจการอื่นนอกเหนือจากที่ สดช. อนุญาต แต่การให้ผู้รับจ้างดำเนินการไม่ได้ทำให้หน้าที่ของ สดช. ในฐานะ Data Controller หายไป สดช. ยังต้องกำกับและสามารถพิสูจน์ได้ว่าผู้รับจ้างทำตามสิ่งที่ได้รับมอบหมายจริง

เรื่องนี้สำคัญเพราะ FAQ ระบุว่า AiPASS เชื่อม AI จาก 14 ค่าย มากกว่า 30 โมเดล และโครงการยังอาจมี Cloud ผู้จัดอบรม Call Center ผู้จัดกิจกรรม หรือบริษัทที่ดูแลระบบบางส่วนเข้ามาเกี่ยวข้อง ผู้ให้บริการเหล่านี้อาจเป็น Sub-processor หากประมวลผลตามคำสั่งที่ส่งต่อมาจากผู้รับจ้างหลัก หรืออาจมีสถานะอื่นในบาง Processing Activity หากใช้ข้อมูลเพื่อวัตถุประสงค์ที่ตนกำหนดเอง

ดังนั้น DPA ระหว่าง สดช. กับผู้รับจ้างหลักต้องเข้มพอที่จะทำให้ข้อกำหนดเรื่องการใช้ข้อมูล การรักษาความปลอดภัย การลบข้อมูล การแจ้งเหตุละเมิด และการห้ามนำข้อมูลไปใช้ต่อ ไหลลงไปถึงผู้ให้บริการในทุกทอดได้จริง ผู้รับจ้างหลักก็ควรรู้ว่า Sub-processor มีใครบ้าง ได้ข้อมูลอะไร เก็บที่ไหน ใครเข้าถึงได้ และเมื่อจบงานต้องลบหรือคืนข้อมูลอย่างไร ทั้งนี้ Processor มีหน้าที่จัดทำบันทึกตามมาตรา 40(3) อยู่แล้ว ส่วน Processor/Sub-processor Register เป็นเครื่องมือกำกับที่ช่วยให้ตรวจสอบสายการประมวลผลได้ง่ายขึ้น

อีกกลุ่มหนึ่งที่ต้องแยกออกมาคือสมาคม สถานศึกษา หรือหน่วยงานที่ช่วยประชาสัมพันธ์หรือรวบรวมผู้สมัคร หากเพียงส่ง Link หรือ QR Code แล้วประชาชนสมัคร AiPASS เอง ก็แทบไม่มีการแบ่งปัน Personal Data ระหว่างองค์กร แต่ถ้ามีการรวบรวมรายชื่อส่งเข้าโครงการ หรือมีคะแนน ผลการเรียน หรือข้อมูลการใช้บริการส่งกลับไปยังต้นสังกัด ก็เกิด Data Sharing ขึ้นแล้ว และต้องตอบให้ได้ว่าแต่ละฝ่ายมีบทบาทอะไร ใช้ฐานกฎหมายใด ใช้ข้อมูลเพื่อวัตถุประสงค์อะไร และได้แจ้งเจ้าของข้อมูลไว้อย่างไร

แต่การมีผู้รับจ้างหรือผู้รับจ้างช่วงไม่ได้ทำให้หน้าที่ของ สดช. ในฐานะ Data Controller หายไป ขณะเดียวกันผู้รับจ้างและผู้รับจ้างช่วงก็มีหน้าที่ของตนตามบทบาทและ Processing Activity ที่ทำจริง

3.ส่งข้อมูลไปต่างประเทศ ควรอธิบายให้ชัด

อีกประเด็นที่ถูกตั้งคำถามมากคือ Data Localization กับการส่งข้อมูลไปต่างประเทศ

TOR มีทั้งวัตถุประสงค์ให้ข้อมูลส่วนบุคคลและข้อมูลพฤติกรรมการใช้ AI ถูกจัดเก็บและประมวลผลในประเทศไทย ข้อกำหนดเฉพาะให้ข้อมูลการลงทะเบียนอยู่ในประเทศไทย และกำหนดให้ Main Data Center ตั้งอยู่ในประเทศไทย ขณะที่ Privacy Notice ระบุว่า Prompt และ File อาจถูกส่งไปประมวลผลกับ AI Provider ต่างประเทศ จึงมีคนตั้งข้อสังเกตว่าการทำงานแบบนี้อาจไม่สอดคล้องกับ TOR

จากรายละเอียดสัญญาแก้ไขเพิ่มเติมที่เผยแพร่ ไม่ปรากฏว่ามีการแก้ข้อความใน TOR ส่วนที่ผมยกมาวิเคราะห์เรื่องการจัดเก็บและประมวลผลข้อมูลในประเทศไทย ดังนั้น เมื่อทราบแล้วว่า TOR เป็นส่วนหนึ่งของสัญญา คำถามเรื่อง Cross-border Processing จึงไม่ใช่เพียงเรื่องที่ Privacy Notice ต้องอธิบายตาม PDPA แต่ยังควรอธิบายด้วยว่าการดำเนินงานดังกล่าวสอดคล้องกับข้อกำหนดในสัญญาทั้งชุดอย่างไร

สิ่งที่ควรชี้แจงให้ประชาชนเข้าใจได้ง่ายคือ ข้อมูลประเภทใดอยู่ในประเทศไทย ข้อมูลประเภทใดถูกส่งออก Provider ใดรับข้อมูล ประมวลผลที่ Region ไหน เก็บไว้นานเท่าใด และใช้กลไกตามมาตรา 28 หรือ 29 ของ PDPA อย่างไร เพราะ PDPA ไม่ได้ห้ามการส่งข้อมูลไปต่างประเทศโดยเด็ดขาด แต่กำหนดเงื่อนไขและมาตรการที่ต้องปฏิบัติตาม

ขณะเดียวกัน การปฏิบัติให้ถูกต้องตาม PDPA กับการปฏิบัติให้สอดคล้องกับสัญญาเป็นคนละเรื่องกัน การส่งข้อมูลอาจผ่านเงื่อนไขตาม PDPA แต่ยังต้องตรวจอีกชั้นว่าสอดคล้องกับสัญญาที่ลงนามจริงหรือไม่

ถ้าอธิบาย Data Flow ตรงนี้ได้ชัด ความกังวลเรื่อง “ข้อมูลออกนอกประเทศ” จะลดลงมาก เพราะคนจะเห็นภาพว่าอะไรออก อะไรไม่ออก และออกไปเพื่อทำอะไร

4.National LLM ต้องแยกจากการที่ AI Provider นำข้อมูลไป Train

ใน TOR เดิมผมยังไม่พบเรื่อง National LLM โดยตรง แต่ Terms and Conditions และ Privacy Notice ปัจจุบันระบุชัดว่า ข้อมูลที่เกิดจากการใช้ AiPASS อาจถูกนำไปใช้เพื่อการวิจัยและพัฒนา รวมถึงการพัฒนา National LLM

อย่างไรก็ตาม ไม่ควรตีความว่าระบบจะนำ Prompt หรือ Chat ที่ยังระบุตัวบุคคลได้ไป Train National LLM โดยตรง เพราะ Terms ข้อ 9.2 ระบุว่า User Content ที่ใช้เพื่อ National LLM จะใช้เฉพาะข้อมูลที่ผ่าน De-identification หรือ Anonymization แล้ว

สิ่งที่ควรอธิบายคือ จากข้อมูลที่เกิดขึ้นระหว่างใช้ AiPASS ไปจนถึง Dataset สำหรับ National LLM มีขั้นตอนอย่างไร Anonymization เกิดเมื่อใด และกรณีที่ Terms ข้อ 6.8 กล่าวถึง Pseudonymisation มีการใช้ข้อมูลลักษณะนี้ในขั้นตอนใด

ส่วน Sensitive Personal Data ยิ่งต้องอธิบายให้ชัด เพราะ Privacy Notice ระบุว่า หากผู้ใช้ป้อนเข้ามา จะใช้เพียงเพื่อสร้างคำตอบ ดังนั้นข้อมูลประเภทนี้ก็ควรถูกกันออกจาก Research หรือ National LLM ด้วย

อีกเรื่องที่ต้องแยกคือ FAQ ระบุว่า AI Provider ถูกห้ามนำข้อมูลของผู้ใช้ไป Train Model ของตน ซึ่งเป็นคนละเรื่องกับการที่โครงการนำข้อมูลที่ผ่านกระบวนการตามที่กำหนดไปพัฒนา National LLM อย่างไรก็ดี FAQ ใช้ถ้อยคำว่ามีข้อตกลงห้าม AI Provider นำข้อมูลไป Train Model ขณะที่ Terms ข้อ 6.8 ใช้ถ้อยคำว่า Opt-out ในทุกกรณีที่ Provider เปิดให้ดำเนินการได้ ถ้อยคำสองส่วนนี้จึงควรอธิบายให้ตรงกัน ทั้งนี้ Terms ข้อ 6.8 ยังให้สิทธิผู้ใช้คัดค้านการประมวลผลเพื่อพัฒนาโมเดล จึงควรอธิบายด้วยว่าเมื่อผู้ใช้คัดค้านแล้วมีผลต่อ Data Pipeline อย่างไร

5.Prompt Monitoring และ Temporary Chat เป็นเรื่องที่ต้องอธิบายมากกว่าแค่ Privacy Notice

Privacy Notice วัตถุประสงค์ข้อ 13 ระบุถึงการตรวจสอบการใช้งานที่อาจขัดต่อกฎหมาย ความสงบเรียบร้อย หรือความมั่นคง และระบุว่าอาจมี Human Review ก่อนจำกัดสิทธิหรือส่งข้อมูลต่อ

ข้อมูลนี้เพียงพอให้ประชาชนตั้งคำถาม แต่ยังไม่เพียงพอให้สรุปว่า “เจ้าหน้าที่อ่านทุก Prompt”

สิ่งที่ควรอธิบายคือ ระบบตรวจทุกข้อความหรือเฉพาะบางกรณี ใช้อะไรเป็น Trigger เจ้าหน้าที่เห็นข้อมูลแค่ไหน ใครมีสิทธิเปิดดู และการเปิดดูทุกครั้งมี Audit Trail หรือไม่

อีกเรื่องที่ควรอธิบายคือ หากผู้ใช้ต้องการตรวจสอบว่าข้อมูลของตนถูกเปิดเผยหรือส่งต่อให้หน่วยงานใด จะสามารถขอข้อมูลดังกล่าวได้ในขอบเขตใดตาม PDPA

Temporary Chat ก็มีประเด็นคล้ายกัน Privacy Notice ระบุว่าสามารถเก็บข้อมูลการสนทนาไว้ภายใน 1 ปี แม้ชื่อ Temporary อาจทำให้คนทั่วไปเข้าใจว่าไม่เก็บหรือเก็บเพียงช่วงสั้น ๆ

เรื่องนี้จึงไม่ใช่แค่ Retention Policy แต่เป็นเรื่องการสื่อสารด้วย แม้ Privacy Notice จะบอกระยะเวลาเก็บแล้ว แต่ยังควรอธิบายให้ผู้ใช้เข้าใจว่า Temporary Chat ต่างจาก Chat ปกติอย่างไร และคำว่า Temporary หมายถึงอะไรในทางปฏิบัติ

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

6.ปัญหาใหญ่ของโครงการนี้ ณ ตอนนี้ อาจไม่ใช่ Privacy Notice แต่คือ Privacy Trust

เมื่อมองทุกประเด็นรวมกัน ผมคิดว่ากิจกรรมประมวลผลหลายอย่างของ AiPASS ไม่ใช่เรื่องผิดปกติ การยืนยันตัวตน การเก็บ Log การส่ง Prompt ไปยัง AI Provider การตรวจจับ Abuse หรือการเก็บข้อมูลไว้ระยะหนึ่ง เป็นสิ่งที่พบได้ในบริการดิจิทัลทั่วไป

คำถามที่สำคัญกว่าคือ ทำไปเพื่ออะไร จำเป็นแค่ไหน ใครเข้าถึง และตรวจสอบได้หรือไม่

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

ความเสี่ยงจึงไม่ได้มีเฉพาะ Hacker แต่รวมถึงคนที่ “มีสิทธิ” เข้าถึงข้อมูลด้วย

ตรงนี้ผมอยากเห็นมากกว่าคำว่า “ระบบมีมาตรฐานความปลอดภัย” แต่อยากรู้ว่าใครเปิดดูข้อมูลได้ เปิดดูได้เมื่อไร ทุกการเข้าถึงถูกบันทึกหรือไม่ มีการทบทวนสิทธิหรือไม่ และถ้ามีคนใช้ข้อมูลผิดวัตถุประสงค์ ระบบจะตรวจพบและจัดการอย่างไร รวมถึงประชาชนที่ลงทะเบียนใช้บริการมีสิทธิอะไรบ้างตาม PDPA

เพราะนี่คือสิ่งที่จะสร้างความเชื่อมั่นได้มากกว่า Privacy Notice ที่ยาวขึ้นอีกหลายหน้า

นอกจากนี้ผมยังเห็นว่า การจัดการโครงการที่เกี่ยวกับข้อมูลส่วนบุคคลของรัฐควรนำหลัก Privacy by Design / by Default มาใช้ รวมถึงการทำ DPIA อย่างจริงจัง ซึ่งจะมีประโยชน์มากกับโครงการลักษณะนี้ เพราะมีทั้งการเชื่อมตัวตน การใช้ AI หลาย Provider, National LLM, Cross-border Processing, Profiling และ Content Monitoring หากโครงการได้ทำแล้ว ไม่จำเป็นต้องเปิดเผยทั้งฉบับ แต่อาจเปิดเผย Summary ว่าประเมินเรื่องอะไร พบความเสี่ยงอะไร และมีมาตรการลดความเสี่ยงอย่างไร

และจากเอกสารสาธารณะที่ผมตรวจสอบได้จนถึงขณะนี้ ยังไม่เห็นข้อมูลว่าเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล หรือ DPO ของ สดช. ได้มีบทบาทหรือให้คำแนะนำเกี่ยวกับการคุ้มครองข้อมูลส่วนบุคคลของโครงการนี้อย่างไร

7.ในฐานะสมาคมวิชาชีพ ผมยังอยากได้คำตอบจาก สดช. 6 เรื่อง

  1. เมื่อ TOR เป็นส่วนหนึ่งของสัญญาหลักและมีสัญญาแก้ไขเพิ่มเติมแล้ว ข้อกำหนดเรื่อง Personal Data, Data Localization, Cross-border Processing และ AI Provider เมื่ออ่านเอกสารสัญญาทั้งชุดประกอบกันควรตีความและนำไปปฏิบัติอย่างไร
  2. Data Flow จริงเป็นอย่างไร ใครเข้าถึง Prompt, File, Conversation และข้อมูลระบุตัวตนได้ ข้อมูลถูกส่งต่อให้ผู้รับจ้างช่วงหรือหน่วยงานใดบ้าง มีข้อมูลอะไรส่งกลับไปยังสมาคม สถานศึกษา หรือต้นสังกัดหรือไม่ และทุกการเข้าถึงตรวจสอบย้อนหลังได้หรือไม่
  3. DPA ระหว่าง สดช. กับผู้รับจ้างครอบคลุม AI Provider, Cloud และ Sub-processor ทุกทอดหรือไม่ รวมถึงเรื่อง No-training, Breach Notification การลบข้อมูล และการกำกับว่าผู้รับจ้างช่วงใช้ข้อมูลได้เพียงใด
  4. ข้อมูลจาก AiPASS ถูกคัดเลือกและผ่าน De-identification หรือ Anonymization ณ จุดใดก่อนนำไปพัฒนา National LLM, Sensitive Personal Data ถูกกันออกอย่างไร และเมื่อผู้ใช้คัดค้านการใช้ข้อมูลเพื่อพัฒนาโมเดล ระบบดำเนินการอย่างไร
  5. Temporary Chat, Content Monitoring และคำว่า “จำเป็นเพื่อประโยชน์สาธารณะ” มีหลักเกณฑ์ในทางปฏิบัติอย่างไร ไม่ใช่เพียงเขียนไว้ใน Privacy Notice
  6. มีการทำ DPIA แล้วหรือไม่ และหากทำแล้ว สามารถเปิดเผยสาระสำคัญในระดับที่ประชาชนเข้าใจได้หรือไม่

สำหรับผม การที่โครงการยังไม่ตอบคำถามเหล่านี้ ไม่ใช่เหตุให้สรุปว่า AiPASS ทำผิด PDPA แต่ก็คงไม่เหมาะที่จะบอกประชาชนว่าไม่มีอะไรต้องกังวล

เมื่อ Privacy Notice มีหน้าที่บอกประชาชนว่าจะทำอะไรกับข้อมูล ส่วน Accountability คือการพิสูจน์ว่าสิ่งที่บอกนั้นเกิดขึ้นจริง และ Trust จะเกิดขึ้นก็ต่อเมื่อประชาชนเชื่อได้ว่า ข้อมูลของเขาจะถูกใช้ตามวัตถุประสงค์ คนที่ไม่ควรเห็นจะไม่เห็น คนที่มีสิทธิเห็นจะเปิดดูได้เฉพาะเมื่อมีเหตุ และทุกอย่างตรวจสอบย้อนหลังได้

ดังนั้น สิ่งที่โครงการควรทำต่ออาจไม่ใช่เขียน Privacy Notice ให้ยาวขึ้น แต่คืออธิบายเรื่องที่ประชาชนกำลังกังวลให้ชัด และแสดงให้เห็นว่าระบบจริงทำตามสิ่งที่บอกไว้อย่างไร

ถ้า TH-AI Passport ทำเรื่องนี้ได้ โครงการนี้อาจไม่เพียงช่วยให้คนไทยเข้าถึง AI แต่ยังเป็นตัวอย่างว่าโครงการ AI ของรัฐจะใช้ข้อมูลไปพร้อมกับสร้างความเชื่อมั่นของประชาชนได้อย่างไร

หมายเหตุ: บทความนี้วิเคราะห์จาก TOR รายละเอียดสัญญาแก้ไขเพิ่มเติมในส่วนที่เผยแพร่ รวมถึง Terms and Conditions, Privacy Notice และ FAQ ที่ผู้เขียนสามารถและการแถลงข่าวของโครงการนี้ของ สดช. ซึ่งตรวจสอบได้ถึงวันที่ 23 สิงหาคม 2569 หากมีข้อมูลหรือเอกสารเพิ่มเติมที่ทำให้ข้อเท็จจริงเปลี่ยนแปลง ผู้เขียนพร้อมปรับปรุงเนื้อหาให้ถูกต้องต่อไป

ศึกษาบทวิเคราะห์ต่อเนื่องในชุดโครงการ AiPASS & PDPA

การทำความเข้าใจมิติด้านการคุ้มครองข้อมูลส่วนบุคคลของโครงการ AiPASS อย่างรอบด้าน จำเป็นต้องมองทั้งในระดับโครงสร้างนโยบาย สัญญาจ้าง และการตระหนักรู้ของผู้ใช้งาน:

ย้อนอ่านตอนที่ 1 (มิติสัญญาจัดซื้อจัดจ้างภาครัฐ):

คลิกเลย -> TOR โครงการ TH-AI Passport กับประเด็น PDPA: เผย 12 สิ่งที่ควรเพิ่มเพื่อยกระดับความปลอดภัยข้อมูลประชาชน

ร่วมทบทวนจุดเริ่มต้นจากการวิเคราะห์ร่าง TOR ข้อกังวลเรื่องการบันทึกประวัติและพฤติกรรมการพิมพ์ (Prompt) และข้อเสนอแนะ 12 ประการในการกำกับดูแลผู้รับจ้าง

อ่านต่อตอนที่ 3 (มิติการคุ้มครองสิทธิสำหรับผู้ใช้งาน):

คลิกเลย -> สร้างความตระหนักรู้เรื่องความเป็นส่วนตัว จาก AiPASS คำถามที่ต้องถามตนเองก่อนใช้

เมื่อระบบเปิดให้ใช้งานจริง ประชาชนในฐานะเจ้าของข้อมูลส่วนบุคคลควรเตรียมตัวอย่างไร? เช็กลิสต์คำถามสำคัญด้าน Privacy ที่ทุกคนควรพิจารณาก่อนเริ่มป้อนคำสั่งและส่งข้อมูลเข้าสู่ระบบ AI ภาครัฐ

การเลิกจ้างลูกจ้างด้วยระบบ AI ของ Meta การปะทะกันระหว่างสิทธิของนายจ้างกับสิทธิความเป็นส่วนตัวสากล

/in

โดย นางสาวมยุรี ชวนชม
กรรมการและประธานฝ่ายส่งเสริมสิทธิ
สมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย

เมื่อ AI ไม่ได้เป็นเพียงเครื่องมือ แต่กลายเป็น “ผู้ตัดสินชะตากรรม” ของลูกจ้าง

ปัญญาประดิษฐ์ (Artificial Intelligence หรือ AI) ที่จากเดิมใช้เพื่อสนับสนุนการตัดสินใจของผู้บริหาร (Decision Support System) กลายเป็นการพัฒนาไปสู่ระบบที่สามารถวิเคราะห์ ประเมิน และเสนอผลการตัดสินใจแทนมนุษย์ในหลายกระบวนการ ไม่ว่าจะเป็นการสรรหาบุคลากร การประเมินผลการปฏิบัติงาน การกำหนดค่าตอบแทน ตลอดจนการเลิกจ้างลูกจ้าง แม้ AI จะช่วยเพิ่มประสิทธิภาพ ลดต้นทุน และลดอคติของมนุษย์ในบางกรณี แต่เมื่อระบบดังกล่าวเข้าไปมีบทบาทในการกำหนด “อนาคตของชีวิตคน” คำถามสำคัญจึงมิใช่เพียงว่า AI มีความแม่นยำเพียงใด แต่คือ AI มีความยุติธรรมเพียงพอหรือไม่

ข่าวใหญ่ช่วงนี้คือเรื่องที่ลูกจ้างของ Meta Platforms Inc. (หรือ Facebook) หลายสิบคนร่วมกันยื่นฟ้องบริษัท ต่อศาลรัฐบาลกลางสหรัฐอเมริกา ในประเด็นที่ว่าบริษัทใช้ระบบ AI ภายในองค์กรในการประเมินและคัดเลือกลูกจ้างที่จะถูกเลิกจ้างจำนวนหลายพันคน โดยระบบดังกล่าวอาศัยข้อมูลพฤติกรรมการทำงาน เช่น การใช้งานคอมพิวเตอร์ จำนวนครั้งของการกดแป้นพิมพ์ (Keystroke) ระยะเวลาการออนไลน์ และกิจกรรมต่าง ๆ ในระบบของบริษัท ก่อนนำข้อมูลเหล่านั้นไปจัดอันดับลูกจ้างโดยอัตโนมัติ ซึ่งส่งผลกระทบต่อลูกจ้างที่อยู่ระหว่างลาคลอด ลาป่วย หรือมีข้อจำกัดด้านสุขภาพ จนถูกจัดอยู่ในกลุ่มที่มี “ผลงานต่ำ” ทั้งที่เป็นการใช้สิทธิตามกฎหมาย

กรณีดังกล่าวจึงมิใช่เพียงข้อพิพาทระหว่างนายจ้างและลูกจ้างหรือการเลิกจ้างทั่วไป แต่สะท้อนให้เห็นถึงการปะทะกันระหว่าง สิทธิของนายจ้างในการบริหารจัดการองค์กร กับ สิทธิในความเป็นส่วนตัวและศักดิ์ศรีความเป็นมนุษย์ ซึ่งได้รับการรับรองภายใต้กฎหมายสิทธิมนุษยชนและกฎหมายคุ้มครองข้อมูลส่วนบุคคลทั่วโลก

 

สิทธิของนายจ้างในการบริหารจัดการองค์กร สิทธิที่มีขอบเขตไม่ใช่อำนาจที่ไร้ขีดจำกัด

ในการบริหารงาน นายจ้างย่อมมีสิทธิบริหารจัดการกิจการ (Managerial Prerogative) ซึ่งครอบคลุมถึงการกำหนดนโยบายองค์กร การประเมินผลการปฏิบัติงาน การโยกย้ายตำแหน่ง และการเลิกจ้างเพื่อประสิทธิภาพขององค์กร สิทธิดังกล่าวมีพื้นฐานมาจากเสรีภาพในการประกอบธุรกิจ (Freedom to Conduct Business) ซึ่งได้รับการรับรองในหลายประเทศ รวมทั้งเป็นหลักการสำคัญของเศรษฐกิจเสรี

ในยุคดิจิทัลที่นำ AI เข้ามาช่วยประเมินประสิทธิภาพของลูกจ้างจึงถือเป็นวิวัฒนาการทางเทคโนโลยีที่องค์กรจำนวนมากเลือกใช้ เนื่องจากสามารถประมวลผลข้อมูลจำนวนมหาศาลได้รวดเร็วกว่ามนุษย์ ลดต้นทุน และสร้างมาตรฐานเดียวกันในการประเมิน อย่างไรก็ตามสิทธิของนายจ้างมิใช่สิทธิสัมบูรณ์ (Absolute Right)

หลักนิติรัฐ (Rule of Law) กำหนดให้การใช้อำนาจของนายจ้างต้องอยู่ภายใต้หลัก

  1. ความจำเป็น (Necessity) และความได้สัดส่วน (Proportionality) 
  2. ความโปร่งใส (Transparency) และความรับผิดชอบ (Accountability) 
  3. การไม่เลือกปฏิบัติ (Non-discrimination) ตามหลักสิทธิมนุษยชนสากล

หากการใช้ AI ทำให้เกิดผลกระทบต่อสิทธิขั้นพื้นฐานของลูกจ้าง สิทธิดังกล่าวย่อมต้องถูกจำกัด

 

สิทธิความเป็นส่วนตัว ไม่สิ้นสุดเมื่อเข้าสู่สถานที่ทำงาน

ในอดีตนายจ้างจำนวนไม่น้อยมีความเชื่อว่า เมื่อลูกจ้างใช้อุปกรณ์ของบริษัท นายจ้างย่อมมีสิทธิตรวจสอบทุกกิจกรรมได้โดยไม่มีข้อจำกัด แนวคิดดังกล่าวกำลังถูกท้าทายในยุคปัจจุบัน สิทธิในความเป็นส่วนตัว (Right to Privacy) ได้รับการรับรองเป็นสิทธิมนุษยชนขั้นพื้นฐานตาม ข้อ 12 ของปฏิญญาสากลว่าด้วยสิทธิมนุษยชน (Universal Declaration of Human Rights หรือ UDHR) และ ข้อ 17 ของกติการะหว่างประเทศว่าด้วยสิทธิพลเมืองและสิทธิทางการเมือง (International Covenant on Civil and Political Rights หรือ ICCPR) ซึ่งห้ามมิให้บุคคลถูกแทรกแซงความเป็นส่วนตัวโดยพลการหรือโดยมิชอบด้วยกฎหมาย 

สำหรับประเทศไทย รัฐธรรมนูญแห่งราชอาณาจักรไทย พุทธศักราช 2560 มาตรา 32 รับรองว่า บุคคลย่อมมีสิทธิในความเป็นอยู่ส่วนตัว เกียรติยศ ชื่อเสียง และครอบครัว และการกระทบต่อสิทธิดังกล่าวจะกระทำมิได้ เว้นแต่โดยอาศัยอำนาจตามกฎหมาย

ในด้านการคุ้มครองข้อมูลส่วนบุคคลไทย พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) กำหนดหลักการสำคัญหลายประการ ได้แก่

          มาตรา 19 กำหนดหลักเกณฑ์เกี่ยวกับการขอความยินยอม ซึ่งต้องกระทำโดยชัดแจ้ง เป็นอิสระ และสามารถถอนความยินยอมได้

          มาตรา 23 กำหนดให้ผู้ควบคุมข้อมูลต้องแจ้งรายละเอียดการเก็บ ใช้ หรือเปิดเผยข้อมูลส่วนบุคคล (Privacy Notice)

          มาตรา 24 กำหนดฐานกฎหมายในการประมวลผลข้อมูลส่วนบุคคลโดยไม่ต้องอาศัยความยินยอม เช่น ประโยชน์โดยชอบด้วยกฎหมาย (Legitimate Interests) แต่ต้องไม่กระทบสิทธิและเสรีภาพขั้นพื้นฐานของเจ้าของข้อมูลเกินสมควร

          มาตรา 26 กำหนดข้อจำกัดเกี่ยวกับการประมวลผลข้อมูลส่วนบุคคลที่มีความอ่อนไหว (Sensitive Personal Data) เช่น ข้อมูลสุขภาพ ความพิการ หรือข้อมูลชีวภาพ ซึ่งต้องได้รับการคุ้มครองในระดับที่เข้มงวดยิ่งขึ้น

หลักการสำคัญคือบุคคลมิได้สูญเสียสิทธิในความเป็นส่วนตัวเพียงเพราะเข้าสู่สถานที่ทำงาน ดังนั้นการเก็บข้อมูลพฤติกรรมการทำงานของลูกจ้าง จึงต้องอยู่ภายใต้หลักการคุ้มครองข้อมูลส่วนบุคคลด้วย ไม่ว่าจะเป็นเวลาเข้าออกระบบ ประวัติการใช้อินเทอร์เน็ต ตำแหน่งที่ตั้ง (Location Data) การกดแป้นพิมพ์ การบันทึกหน้าจอ การติดตาม Mouse Movement การวิเคราะห์ Productivity Score ข้อมูลเหล่านี้ล้วนเป็น “ข้อมูลส่วนบุคคล” ที่สามารถเชื่อมโยงถึงตัวบุคคลได้

เมื่อ AI วิเคราะห์ข้อมูลดังกล่าวอย่างต่อเนื่อง นักกฎหมายยุโรปเรียกว่า Workplace Surveillance หรือการเฝ้าระวังลูกจ้างด้วยเทคโนโลยี ซึ่งสร้างผลกระทบต่อเสรีภาพ ความเป็นส่วนตัว และศักดิ์ศรีความเป็นมนุษย์โดยตรง ดังนั้นแม้นายจ้างจะอาศัยฐานประโยชน์โดยชอบด้วยกฎหมายในการติดตามการทำงานของลูกจ้าง แต่ก็ต้องพิสูจน์ได้ว่าการเก็บข้อมูลมีความจำเป็น ได้สัดส่วน และไม่กระทบต่อสิทธิขั้นพื้นฐานของลูกจ้างเกินสมควร

 

เมื่อ AI กลายเป็น “ผู้พิพากษา”

ประเด็นที่น่ากังวลที่สุดในคดี Meta ไม่ใช่เพียงการเก็บข้อมูลแต่คือการปล่อยให้ AI เป็นผู้จัดอันดับลูกจ้างโดยอัตโนมัติระบบอัลกอริทึมไม่สามารถเข้าใจบริบทของมนุษย์ได้เหมือนมนุษย์ด้วยกัน AI ไม่สามารถแยกแยะได้ว่า ลูกจ้างกำลังลาคลอด ลูกจ้างกำลังรักษาโรคมะเร็ง ลูกจ้างใช้สิทธิลาป่วยตามกฎหมาย ลูกจ้างเป็นผู้พิการที่ได้รับการคุ้มครองตามกฎหมาย เมื่อระบบวัดเพียง “กิจกรรมบนหน้าจอ” บุคคลที่ไม่มีการใช้งานคอมพิวเตอร์ย่อมได้รับคะแนนต่ำโดยอัตโนมัติ และอาจถูกจัดอยู่ในกลุ่มเสี่ยงต่อการเลิกจ้าง นี่คือสิ่งที่เรียกว่า Automation Bias และ Algorithmic Discrimination คือ อัลกอริทึมมิได้มีอคติด้วยตนเอง แต่เรียนรู้จากข้อมูลที่มนุษย์ป้อนเข้าไป หากข้อมูลตั้งต้นมีอคติหรือเลือกตัวชี้วัดที่ไม่เหมาะสม AI ก็จะขยายอคตินั้นให้รุนแรงยิ่งขึ้น ในบริบทของการจ้างงาน ผลลัพธ์ดังกล่าวอาจนำไปสู่การเลือกปฏิบัติต่อกลุ่มเปราะบาง ทั้งสตรีมีครรภ์ ผู้พิการ และผู้ที่ใช้สิทธิตามกฎหมายแรงงาน ซึ่งถือเป็นการละเมิดหลักความเสมอภาคและศักดิ์ศรีความเป็นมนุษย์อย่างมีนัยสำคัญ

 

กฎหมายการคุ้มครองข้อมูลส่วนบุคคล ระหว่าง GDPR , PDPA (ไทย) และกฎหมายของสหรัฐอเมริกา

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

 

สหภาพยุโรป GDPR กับหลักการ “มนุษย์ต้องเป็นผู้ตัดสินใจขั้นสุดท้าย”

สหภาพยุโรปถือเป็นเขตอำนาจที่ให้ความสำคัญกับสิทธิของเจ้าของข้อมูลส่วนบุคคลมากที่สุด โดยเฉพาะ Article 22 ของ GDPR ซึ่งกำหนดให้บุคคลมีสิทธิที่จะไม่ตกอยู่ภายใต้การตัดสินใจที่อาศัยการประมวลผลอัตโนมัติเพียงอย่างเดียว (Automated individual decision-making, including profiling) หากการตัดสินใจนั้นก่อให้เกิดผลกระทบทางกฎหมายหรือผลกระทบที่มีนัยสำคัญต่อบุคคล

การเลิกจ้างถือเป็นการตัดสินใจที่ส่งผลกระทบโดยตรงต่อสิทธิในการทำงาน รายได้ สวัสดิการ และศักดิ์ศรีความเป็นมนุษย์ ดังนั้น หาก Meta ใช้ AI เป็นผู้คัดเลือกลูกจ้างโดยไม่มีการทบทวนอย่างแท้จริงจากผู้บริหารที่เป็นมนุษย์ (Meaningful Human Review) การดำเนินการดังกล่าวอาจขัดต่อ Article 22 ของ GDPR ได้อย่างชัดเจน 

นอกจากนี้ GDPR ยังยึดหลักความโปร่งใส (Transparency) และ การเก็บข้อมูลเท่าที่จำเป็น (Data Minimization) ซึ่งกำหนดให้องค์กรต้องแจ้งให้ลูกจ้างทราบอย่างชัดเจนว่ามีการเก็บข้อมูลประเภทใด ใช้เพื่อวัตถุประสงค์อะไร และเก็บเท่าที่จำเป็นเท่านั้น การติดตามการกดแป้นพิมพ์ การเคลื่อนไหวของเมาส์ หรือการบันทึกพฤติกรรมการทำงานอย่างละเอียด จึงอาจถูกมองว่าเป็นการเฝ้าระวังที่เกินความจำเป็น (Excessive Workplace Surveillance)

ภายใต้กรอบของ GDPR ประเด็นคำถามสำคัญคือ “AI มีสิทธิเป็นผู้ตัดสินอนาคตของมนุษย์หรือไม่”

 

ประเทศไทย PDPA กับความท้าทายของการกำกับดูแล AI

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

          หลักฐานทางกฎหมายในการประมวลผลข้อมูล (Lawful Basis) 

          หลักความโปร่งใส (Transparency) 

          หลักจำกัดวัตถุประสงค์ (Purpose Limitation) 

           หลักความจำเป็นและได้สัดส่วน (Necessity and Proportionality) 

          หลักความมั่นคงปลอดภัยของข้อมูล (Security) 

หากองค์กรเก็บข้อมูลพฤติกรรมลูกจ้างผ่านระบบติดตามการใช้งานคอมพิวเตอร์โดยไม่ได้แจ้งให้ทราบล่วงหน้า หรือไม่มีนโยบาย Workplace Privacy Policy ที่ชัดเจน ย่อมมีความเสี่ยงต่อการฝ่าฝืน PDPA ได้ ยิ่งไปกว่านั้นข้อมูลเกี่ยวกับสุขภาพ การลาป่วย หรือความพิการของลูกจ้างถือเป็น ข้อมูลส่วนบุคคลที่มีความอ่อนไหว (Sensitive Personal Data) หากนำข้อมูลดังกล่าวมาใช้เป็นปัจจัยในการลดคะแนนหรือเลิกจ้าง ย่อมอาจขัดต่อมาตรา 26 ของ PDPA และอาจนำไปสู่การเลือกปฏิบัติอย่างไม่เป็นธรรม

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

 

สหรัฐอเมริกากับการคุ้มครองผ่านกฎหมายลูกจ้างมากกว่ากฎหมายข้อมูลส่วนบุคคล

สหรัฐอเมริกาต่างจาก EU หรือประเทศไทย เพราะยังไม่มีพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลระดับประเทศที่ครอบคลุมทุกภาคส่วน ทำให้นายจ้างมีอำนาจค่อนข้างกว้างในการติดตามการใช้งานอุปกรณ์ของบริษัท อย่างไรก็ตามการใช้อำนาจดังกล่าวไม่ได้หมายความว่าจะสามารถเลือกปฏิบัติต่อลูกจ้างได้

กฎหมายเกี่ยวกับลูกจ้างของสหรัฐอเมริกา เช่น พระราชบัญญัติการลาเพื่อครอบครัวและสุขภาพ (Family and Medical Leave Act (FMLA) และพระราชบัญญัติคนพิการของอเมริกา Americans with Disabilities Act (ADA) ห้ามมิให้นายจ้างใช้ข้อมูลเกี่ยวกับการลาป่วย การลาคลอด หรือความพิการมาเป็นเหตุในการลดคะแนนหรือเลิกจ้างลูกจ้าง นอกจากนี้หลายรัฐ เช่น แคลิฟอร์เนีย โคโลราโด และอิลลินอยส์ ได้เริ่มออกกฎหมายเฉพาะเพื่อกำกับดูแลระบบ Automated Decision Systems โดยกำหนดให้องค์กรต้องตรวจสอบความลำเอียง (Algorithmic Bias Audit) และประเมินผลกระทบต่อสิทธิมนุษยชนก่อนนำ AI มาใช้ในเรื่องการจ้างงาน

 

Human in the loop หลักการที่โลกยอมรับ

AI ไม่ควรเป็น “ผู้ตัดสิน” แต่ควรเป็น “ผู้ช่วยตัดสิน” หลัก Human in the loop จึงได้รับการยอมรับทั้งใน GDPR, OECD AI Principles, UNESCO Recommendation on the Ethics of AI และ EU AI Act โดยมี 3 หลักการดังนี้

  1. AI สามารถเสนอผลการวิเคราะห์ได้ แต่มนุษย์ต้องเป็นผู้ใช้ดุลยพินิจขั้นสุดท้าย 
  2. ผู้ได้รับผลกระทบต้องมีสิทธิอุทธรณ์หรือขอให้มีการทบทวนโดยมนุษย์ 
  3. องค์กรต้องอธิบายเหตุผลของการตัดสินใจได้ (Explainability) 

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

 

บทสรุป

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

แม้ AI จะช่วยเพิ่มประสิทธิภาพ ลดต้นทุน และสนับสนุนการตัดสินใจได้อย่างมีนัยสำคัญ แต่เมื่อการตัดสินใจนั้นกระทบต่อสิทธิในการทำงาน ความเป็นส่วนตัว และศักดิ์ศรีความเป็นมนุษย์ การปล่อยให้อัลกอริทึมเป็นผู้ตัดสินเพียงลำพังย่อมไม่สอดคล้องกับหลักสิทธิมนุษยชนสากล

อนาคตของการกำกับดูแล AI ไม่ได้อยู่ที่การห้ามใช้เทคโนโลยี หากแต่อยู่ที่การออกแบบระบบที่มี ความโปร่งใส ความรับผิดชอบ การตรวจสอบได้ และการมีมนุษย์ร่วมรับผิดชอบในการตัดสินใจ (Human in the loop)

ท้ายที่สุด เทคโนโลยีควรเป็นเครื่องมือที่ยกระดับศักยภาพของมนุษย์และเคารพ ศักดิ์ศรี สิทธิ และความเป็นธรรม ของทุกคนในองค์กร

โดย นางสาวมยุรี ชวนชม
กรรมการและประธานฝ่ายส่งเสริมสิทธิ
สมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย

 

เมื่อ AI ไม่ได้เป็นเพียงเครื่องมือ แต่กลายเป็น “ผู้ตัดสินชะตากรรม” ของลูกจ้าง

ปัญญาประดิษฐ์ (Artificial Intelligence หรือ AI) ที่จากเดิมใช้เพื่อสนับสนุนการตัดสินใจของผู้บริหาร (Decision Support System) กลายเป็นการพัฒนาไปสู่ระบบที่สามารถวิเคราะห์ ประเมิน และเสนอผลการตัดสินใจแทนมนุษย์ในหลายกระบวนการ ไม่ว่าจะเป็นการสรรหาบุคลากร การประเมินผลการปฏิบัติงาน การกำหนดค่าตอบแทน ตลอดจนการเลิกจ้างลูกจ้าง แม้ AI จะช่วยเพิ่มประสิทธิภาพ ลดต้นทุน และลดอคติของมนุษย์ในบางกรณี แต่เมื่อระบบดังกล่าวเข้าไปมีบทบาทในการกำหนด “อนาคตของชีวิตคน” คำถามสำคัญจึงมิใช่เพียงว่า AI มีความแม่นยำเพียงใด แต่คือ AI มีความยุติธรรมเพียงพอหรือไม่

ข่าวใหญ่ช่วงนี้คือเรื่องที่ลูกจ้างของ Meta Platforms Inc. (หรือ Facebook) หลายสิบคนร่วมกันยื่นฟ้องบริษัท ต่อศาลรัฐบาลกลางสหรัฐอเมริกา ในประเด็นที่ว่าบริษัทใช้ระบบ AI ภายในองค์กรในการประเมินและคัดเลือกลูกจ้างที่จะถูกเลิกจ้างจำนวนหลายพันคน โดยระบบดังกล่าวอาศัยข้อมูลพฤติกรรมการทำงาน เช่น การใช้งานคอมพิวเตอร์ จำนวนครั้งของการกดแป้นพิมพ์ (Keystroke) ระยะเวลาการออนไลน์ และกิจกรรมต่าง ๆ ในระบบของบริษัท ก่อนนำข้อมูลเหล่านั้นไปจัดอันดับลูกจ้างโดยอัตโนมัติ ซึ่งส่งผลกระทบต่อลูกจ้างที่อยู่ระหว่างลาคลอด ลาป่วย หรือมีข้อจำกัดด้านสุขภาพ จนถูกจัดอยู่ในกลุ่มที่มี “ผลงานต่ำ” ทั้งที่เป็นการใช้สิทธิตามกฎหมาย

กรณีดังกล่าวจึงมิใช่เพียงข้อพิพาทระหว่างนายจ้างและลูกจ้างหรือการเลิกจ้างทั่วไป แต่สะท้อนให้เห็นถึงการปะทะกันระหว่าง สิทธิของนายจ้างในการบริหารจัดการองค์กร กับ สิทธิในความเป็นส่วนตัวและศักดิ์ศรีความเป็นมนุษย์ ซึ่งได้รับการรับรองภายใต้กฎหมายสิทธิมนุษยชนและกฎหมายคุ้มครองข้อมูลส่วนบุคคลทั่วโลก

สิทธิของนายจ้างในการบริหารจัดการองค์กร สิทธิที่มีขอบเขตไม่ใช่อำนาจที่ไร้ขีดจำกัด

ในการบริหารงาน นายจ้างย่อมมีสิทธิบริหารจัดการกิจการ (Managerial Prerogative) ซึ่งครอบคลุมถึงการกำหนดนโยบายองค์กร การประเมินผลการปฏิบัติงาน การโยกย้ายตำแหน่ง และการเลิกจ้างเพื่อประสิทธิภาพขององค์กร สิทธิดังกล่าวมีพื้นฐานมาจากเสรีภาพในการประกอบธุรกิจ (Freedom to Conduct Business) ซึ่งได้รับการรับรองในหลายประเทศ รวมทั้งเป็นหลักการสำคัญของเศรษฐกิจเสรี

ในยุคดิจิทัลที่นำ AI เข้ามาช่วยประเมินประสิทธิภาพของลูกจ้างจึงถือเป็นวิวัฒนาการทางเทคโนโลยีที่องค์กรจำนวนมากเลือกใช้ เนื่องจากสามารถประมวลผลข้อมูลจำนวนมหาศาลได้รวดเร็วกว่ามนุษย์ ลดต้นทุน และสร้างมาตรฐานเดียวกันในการประเมิน อย่างไรก็ตามสิทธิของนายจ้างมิใช่สิทธิสัมบูรณ์ (Absolute Right)

หลักนิติรัฐ (Rule of Law) กำหนดให้การใช้อำนาจของนายจ้างต้องอยู่ภายใต้หลัก

  1. ความจำเป็น (Necessity) และความได้สัดส่วน (Proportionality) 
  2. ความโปร่งใส (Transparency) และความรับผิดชอบ (Accountability) 
  3. การไม่เลือกปฏิบัติ (Non-discrimination) ตามหลักสิทธิมนุษยชนสากล

หากการใช้ AI ทำให้เกิดผลกระทบต่อสิทธิขั้นพื้นฐานของลูกจ้าง สิทธิดังกล่าวย่อมต้องถูกจำกัด

 

สิทธิความเป็นส่วนตัว ไม่สิ้นสุดเมื่อเข้าสู่สถานที่ทำงาน

ในอดีตนายจ้างจำนวนไม่น้อยมีความเชื่อว่า เมื่อลูกจ้างใช้อุปกรณ์ของบริษัท นายจ้างย่อมมีสิทธิตรวจสอบทุกกิจกรรมได้โดยไม่มีข้อจำกัด แนวคิดดังกล่าวกำลังถูกท้าทายในยุคปัจจุบัน สิทธิในความเป็นส่วนตัว (Right to Privacy) ได้รับการรับรองเป็นสิทธิมนุษยชนขั้นพื้นฐานตาม ข้อ 12 ของปฏิญญาสากลว่าด้วยสิทธิมนุษยชน (Universal Declaration of Human Rights หรือ UDHR) และ ข้อ 17 ของกติการะหว่างประเทศว่าด้วยสิทธิพลเมืองและสิทธิทางการเมือง (International Covenant on Civil and Political Rights หรือ ICCPR) ซึ่งห้ามมิให้บุคคลถูกแทรกแซงความเป็นส่วนตัวโดยพลการหรือโดยมิชอบด้วยกฎหมาย 

สำหรับประเทศไทย รัฐธรรมนูญแห่งราชอาณาจักรไทย พุทธศักราช 2560 มาตรา 32 รับรองว่า บุคคลย่อมมีสิทธิในความเป็นอยู่ส่วนตัว เกียรติยศ ชื่อเสียง และครอบครัว และการกระทบต่อสิทธิดังกล่าวจะกระทำมิได้ เว้นแต่โดยอาศัยอำนาจตามกฎหมาย

ในด้านการคุ้มครองข้อมูลส่วนบุคคลไทย พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) กำหนดหลักการสำคัญหลายประการ ได้แก่

          มาตรา 19 กำหนดหลักเกณฑ์เกี่ยวกับการขอความยินยอม ซึ่งต้องกระทำโดยชัดแจ้ง เป็นอิสระ และสามารถถอนความยินยอมได้

          มาตรา 23 กำหนดให้ผู้ควบคุมข้อมูลต้องแจ้งรายละเอียดการเก็บ ใช้ หรือเปิดเผยข้อมูลส่วนบุคคล (Privacy Notice)

          มาตรา 24 กำหนดฐานกฎหมายในการประมวลผลข้อมูลส่วนบุคคลโดยไม่ต้องอาศัยความยินยอม เช่น ประโยชน์โดยชอบด้วยกฎหมาย (Legitimate Interests) แต่ต้องไม่กระทบสิทธิและเสรีภาพขั้นพื้นฐานของเจ้าของข้อมูลเกินสมควร

          มาตรา 26 กำหนดข้อจำกัดเกี่ยวกับการประมวลผลข้อมูลส่วนบุคคลที่มีความอ่อนไหว (Sensitive Personal Data) เช่น ข้อมูลสุขภาพ ความพิการ หรือข้อมูลชีวภาพ ซึ่งต้องได้รับการคุ้มครองในระดับที่เข้มงวดยิ่งขึ้น

หลักการสำคัญคือบุคคลมิได้สูญเสียสิทธิในความเป็นส่วนตัวเพียงเพราะเข้าสู่สถานที่ทำงาน ดังนั้นการเก็บข้อมูลพฤติกรรมการทำงานของลูกจ้าง จึงต้องอยู่ภายใต้หลักการคุ้มครองข้อมูลส่วนบุคคลด้วย ไม่ว่าจะเป็นเวลาเข้าออกระบบ ประวัติการใช้อินเทอร์เน็ต ตำแหน่งที่ตั้ง (Location Data) การกดแป้นพิมพ์ การบันทึกหน้าจอ การติดตาม Mouse Movement การวิเคราะห์ Productivity Score ข้อมูลเหล่านี้ล้วนเป็น “ข้อมูลส่วนบุคคล” ที่สามารถเชื่อมโยงถึงตัวบุคคลได้

เมื่อ AI วิเคราะห์ข้อมูลดังกล่าวอย่างต่อเนื่อง นักกฎหมายยุโรปเรียกว่า Workplace Surveillance หรือการเฝ้าระวังลูกจ้างด้วยเทคโนโลยี ซึ่งสร้างผลกระทบต่อเสรีภาพ ความเป็นส่วนตัว และศักดิ์ศรีความเป็นมนุษย์โดยตรง ดังนั้นแม้นายจ้างจะอาศัยฐานประโยชน์โดยชอบด้วยกฎหมายในการติดตามการทำงานของลูกจ้าง แต่ก็ต้องพิสูจน์ได้ว่าการเก็บข้อมูลมีความจำเป็น ได้สัดส่วน และไม่กระทบต่อสิทธิขั้นพื้นฐานของลูกจ้างเกินสมควร

 

เมื่อ AI กลายเป็น “ผู้พิพากษา”

ประเด็นที่น่ากังวลที่สุดในคดี Meta ไม่ใช่เพียงการเก็บข้อมูลแต่คือการปล่อยให้ AI เป็นผู้จัดอันดับลูกจ้างโดยอัตโนมัติระบบอัลกอริทึมไม่สามารถเข้าใจบริบทของมนุษย์ได้เหมือนมนุษย์ด้วยกัน AI ไม่สามารถแยกแยะได้ว่า ลูกจ้างกำลังลาคลอด ลูกจ้างกำลังรักษาโรคมะเร็ง ลูกจ้างใช้สิทธิลาป่วยตามกฎหมาย ลูกจ้างเป็นผู้พิการที่ได้รับการคุ้มครองตามกฎหมาย เมื่อระบบวัดเพียง “กิจกรรมบนหน้าจอ” บุคคลที่ไม่มีการใช้งานคอมพิวเตอร์ย่อมได้รับคะแนนต่ำโดยอัตโนมัติ และอาจถูกจัดอยู่ในกลุ่มเสี่ยงต่อการเลิกจ้าง นี่คือสิ่งที่เรียกว่า Automation Bias และ Algorithmic Discrimination คือ อัลกอริทึมมิได้มีอคติด้วยตนเอง แต่เรียนรู้จากข้อมูลที่มนุษย์ป้อนเข้าไป หากข้อมูลตั้งต้นมีอคติหรือเลือกตัวชี้วัดที่ไม่เหมาะสม AI ก็จะขยายอคตินั้นให้รุนแรงยิ่งขึ้น ในบริบทของการจ้างงาน ผลลัพธ์ดังกล่าวอาจนำไปสู่การเลือกปฏิบัติต่อกลุ่มเปราะบาง ทั้งสตรีมีครรภ์ ผู้พิการ และผู้ที่ใช้สิทธิตามกฎหมายแรงงาน ซึ่งถือเป็นการละเมิดหลักความเสมอภาคและศักดิ์ศรีความเป็นมนุษย์อย่างมีนัยสำคัญ

 

กฎหมายการคุ้มครองข้อมูลส่วนบุคคล ระหว่าง GDPR , PDPA (ไทย) และกฎหมายของสหรัฐอเมริกา

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

สหภาพยุโรป GDPR กับหลักการ “มนุษย์ต้องเป็นผู้ตัดสินใจขั้นสุดท้าย”

สหภาพยุโรปถือเป็นเขตอำนาจที่ให้ความสำคัญกับสิทธิของเจ้าของข้อมูลส่วนบุคคลมากที่สุด โดยเฉพาะ Article 22 ของ GDPR ซึ่งกำหนดให้บุคคลมีสิทธิที่จะไม่ตกอยู่ภายใต้การตัดสินใจที่อาศัยการประมวลผลอัตโนมัติเพียงอย่างเดียว (Automated individual decision-making, including profiling) หากการตัดสินใจนั้นก่อให้เกิดผลกระทบทางกฎหมายหรือผลกระทบที่มีนัยสำคัญต่อบุคคล

การเลิกจ้างถือเป็นการตัดสินใจที่ส่งผลกระทบโดยตรงต่อสิทธิในการทำงาน รายได้ สวัสดิการ และศักดิ์ศรีความเป็นมนุษย์ ดังนั้น หาก Meta ใช้ AI เป็นผู้คัดเลือกลูกจ้างโดยไม่มีการทบทวนอย่างแท้จริงจากผู้บริหารที่เป็นมนุษย์ (Meaningful Human Review) การดำเนินการดังกล่าวอาจขัดต่อ Article 22 ของ GDPR ได้อย่างชัดเจน 

นอกจากนี้ GDPR ยังยึดหลักความโปร่งใส (Transparency) และ การเก็บข้อมูลเท่าที่จำเป็น (Data Minimization) ซึ่งกำหนดให้องค์กรต้องแจ้งให้ลูกจ้างทราบอย่างชัดเจนว่ามีการเก็บข้อมูลประเภทใด ใช้เพื่อวัตถุประสงค์อะไร และเก็บเท่าที่จำเป็นเท่านั้น การติดตามการกดแป้นพิมพ์ การเคลื่อนไหวของเมาส์ หรือการบันทึกพฤติกรรมการทำงานอย่างละเอียด จึงอาจถูกมองว่าเป็นการเฝ้าระวังที่เกินความจำเป็น (Excessive Workplace Surveillance)

ภายใต้กรอบของ GDPR ประเด็นคำถามสำคัญคือ “AI มีสิทธิเป็นผู้ตัดสินอนาคตของมนุษย์หรือไม่”

 

ประเทศไทย PDPA กับความท้าทายของการกำกับดูแล AI

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

          หลักฐานทางกฎหมายในการประมวลผลข้อมูล (Lawful Basis) 

          หลักความโปร่งใส (Transparency) 

          หลักจำกัดวัตถุประสงค์ (Purpose Limitation) 

           หลักความจำเป็นและได้สัดส่วน (Necessity and Proportionality) 

          หลักความมั่นคงปลอดภัยของข้อมูล (Security) 

หากองค์กรเก็บข้อมูลพฤติกรรมลูกจ้างผ่านระบบติดตามการใช้งานคอมพิวเตอร์โดยไม่ได้แจ้งให้ทราบล่วงหน้า หรือไม่มีนโยบาย Workplace Privacy Policy ที่ชัดเจน ย่อมมีความเสี่ยงต่อการฝ่าฝืน PDPA ได้ ยิ่งไปกว่านั้นข้อมูลเกี่ยวกับสุขภาพ การลาป่วย หรือความพิการของลูกจ้างถือเป็น ข้อมูลส่วนบุคคลที่มีความอ่อนไหว (Sensitive Personal Data) หากนำข้อมูลดังกล่าวมาใช้เป็นปัจจัยในการลดคะแนนหรือเลิกจ้าง ย่อมอาจขัดต่อมาตรา 26 ของ PDPA และอาจนำไปสู่การเลือกปฏิบัติอย่างไม่เป็นธรรม

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

 

สหรัฐอเมริกากับการคุ้มครองผ่านกฎหมายลูกจ้างมากกว่ากฎหมายข้อมูลส่วนบุคคล

สหรัฐอเมริกาต่างจาก EU หรือประเทศไทย เพราะยังไม่มีพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลระดับประเทศที่ครอบคลุมทุกภาคส่วน ทำให้นายจ้างมีอำนาจค่อนข้างกว้างในการติดตามการใช้งานอุปกรณ์ของบริษัท อย่างไรก็ตามการใช้อำนาจดังกล่าวไม่ได้หมายความว่าจะสามารถเลือกปฏิบัติต่อลูกจ้างได้

กฎหมายเกี่ยวกับลูกจ้างของสหรัฐอเมริกา เช่น พระราชบัญญัติการลาเพื่อครอบครัวและสุขภาพ (Family and Medical Leave Act (FMLA) และพระราชบัญญัติคนพิการของอเมริกา Americans with Disabilities Act (ADA) ห้ามมิให้นายจ้างใช้ข้อมูลเกี่ยวกับการลาป่วย การลาคลอด หรือความพิการมาเป็นเหตุในการลดคะแนนหรือเลิกจ้างลูกจ้าง นอกจากนี้หลายรัฐ เช่น แคลิฟอร์เนีย โคโลราโด และอิลลินอยส์ ได้เริ่มออกกฎหมายเฉพาะเพื่อกำกับดูแลระบบ Automated Decision Systems โดยกำหนดให้องค์กรต้องตรวจสอบความลำเอียง (Algorithmic Bias Audit) และประเมินผลกระทบต่อสิทธิมนุษยชนก่อนนำ AI มาใช้ในเรื่องการจ้างงาน

 

Human in the loop หลักการที่โลกยอมรับ

AI ไม่ควรเป็น “ผู้ตัดสิน” แต่ควรเป็น “ผู้ช่วยตัดสิน” หลัก Human in the loop จึงได้รับการยอมรับทั้งใน GDPR, OECD AI Principles, UNESCO Recommendation on the Ethics of AI และ EU AI Act โดยมี 3 หลักการดังนี้

  1. AI สามารถเสนอผลการวิเคราะห์ได้ แต่มนุษย์ต้องเป็นผู้ใช้ดุลยพินิจขั้นสุดท้าย 
  2. ผู้ได้รับผลกระทบต้องมีสิทธิอุทธรณ์หรือขอให้มีการทบทวนโดยมนุษย์ 
  3. องค์กรต้องอธิบายเหตุผลของการตัดสินใจได้ (Explainability) 

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

 

บทสรุป

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

แม้ AI จะช่วยเพิ่มประสิทธิภาพ ลดต้นทุน และสนับสนุนการตัดสินใจได้อย่างมีนัยสำคัญ แต่เมื่อการตัดสินใจนั้นกระทบต่อสิทธิในการทำงาน ความเป็นส่วนตัว และศักดิ์ศรีความเป็นมนุษย์ การปล่อยให้อัลกอริทึมเป็นผู้ตัดสินเพียงลำพังย่อมไม่สอดคล้องกับหลักสิทธิมนุษยชนสากล

อนาคตของการกำกับดูแล AI ไม่ได้อยู่ที่การห้ามใช้เทคโนโลยี หากแต่อยู่ที่การออกแบบระบบที่มี ความโปร่งใส ความรับผิดชอบ การตรวจสอบได้ และการมีมนุษย์ร่วมรับผิดชอบในการตัดสินใจ (Human in the loop)

ท้ายที่สุด เทคโนโลยีควรเป็นเครื่องมือที่ยกระดับศักยภาพของมนุษย์และเคารพ ศักดิ์ศรี สิทธิ และความเป็นธรรม ของทุกคนในองค์กร

TOR โครงการ TH-AI Passport กับประเด็น PDPA

/in

ดร.อุดมธิปก ไพรเกษตร
นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย
ผู้ก่อตั้งสื่อ 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 อย่างรับผิดชอบ

สิ่งที่ควรมีเพิ่มเติม ได้แก่

  1. Role Mapping ระบุผู้ควบคุมข้อมูล ผู้ประมวลผลข้อมูล ผู้ควบคุมร่วม และผู้ประมวลผลช่วง
  2. Lawful Basis Mapping แยกตามกิจกรรม ไม่ใช้ consent รวมทุกเรื่อง
  3. Privacy Notice ตามมาตรา 23 แบบแยกตามกิจกรรม
  4. Data Processing Agreement ระหว่าง สดช. กับผู้รับจ้าง และข้อตกลงกับ sub-processor
  5. Data Sharing Agreement หรือ Joint Controller Arrangement กับหน่วยงานที่เชื่อมข้อมูล
  6. DPIA และ AI Risk Assessment ก่อนเปิดระบบจริง
  7. Cross-border Transfer Assessment สำหรับ AI vendor, cloud, public cloud และ remote access
  8. RoPA ตามมาตรา 39 และ processor record ตามมาตรา 40
  9. DPO Governance ทั้งฝั่ง สดช. ผู้รับจ้างหลัก และ vendor สำคัญ
  10. Data Subject Rights Workflow รองรับสิทธิของเจ้าของข้อมูลครบถ้วน
  11. Retention, Deletion และ Anonymization Schedule แยกตามประเภทข้อมูล
  12. 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  >>ดาวน์โหลด<<

จากข้อสังเกตในร่าง TOR สู่การเปิดตัวแพลตฟอร์ม “AiPASS” จริงในปัจจุบัน

ข้อเสนอแนะทั้ง 12 ประการเพื่อยกระดับความปลอดภัยข้อมูลส่วนบุคคลถูกนำไปปรับใช้จริงหรือไม่? ร่วมเจาะลึกมิติต่อเนื่องเมื่อร่างข้อกำหนดทางเทคนิคถูกแปลงเป็นแบบแจ้งการประมวลผลข้อมูลส่วนบุคคล (Privacy Notice) ท่ามกลางประเด็นเรื่องที่ตั้ง Data Center และการสร้างความเชื่อมั่นของประชาชนต่อบริการ AI ภาครัฐ

อ่านบทวิเคราะห์ตอนถัดไป:

คลิกเลย -> จากโครงการ TH-AI Passport สู่ AiPASS : อ่าน TOR และ Privacy Notice เมื่อวันนี้โจทย์สำคัญของ PDPA ภาครัฐคือ “ความเชื่อมั่น”

ดร.อุดมธิปก ไพรเกษตร
นายกสมาคมผู้ตรวจสอบและให้คำปรึกษาการคุ้มครองข้อมูลส่วนบุคคลไทย
ผู้ก่อตั้งสื่อ PDPA Thailand

ติดต่อสมาคม

สถานที่ติดต่อ: เลขที่ 18/44 ถนนพัฒนาชนบท 3 แขวงคลองสองต้นนุ่น เขตลาดกระบัง กรุงเทพมหานคร 10520

Privacy Notice