ร่าง พ.ร.บ. AI ของไทย: คนจ้างทำระบบควรถามผู้พัฒนาอะไรก่อนร่างกลายเป็นกฎหมาย

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

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

ร่างนี้คืออะไร และเรารู้อะไรเกี่ยวกับมันจริง

ข่าวของฐานเศรษฐกิจ ลงวันที่ 17 กรกฎาคม 2569 รายงานว่า สำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (ETDA) กำลังจัดทำ (ร่าง) พระราชบัญญัติว่าด้วยปัญญาประดิษฐ์ พ.ศ. .... โดยอ้างถึงการผลักดันของกระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม ข่าวเดียวกันระบุว่าร่างมีเจ็ดหมวด (ดูข่าวของฐานเศรษฐกิจ)

1. บททั่วไป รวมถึงบทนิยาม

2. การส่งเสริมการพัฒนาและการใช้ AI เช่น การทดสอบในสภาพแวดล้อมควบคุม การแบ่งปันข้อมูล มาตรฐาน และการรับรอง

3. การควบคุมความเสี่ยง รวมถึงการใช้งานที่ต้องห้าม เช่น การเลือกปฏิบัติโดยไม่เป็นธรรม ระบบ AI ความเสี่ยงสูง การใช้ในภาครัฐ ความโปร่งใสของเนื้อหาที่ AI สร้าง เช่น deepfake และการคุ้มครองผู้บริโภค

4. การบังคับใช้ ซึ่งผู้กำกับดูแลสั่งให้แก้ไขได้ และหากไม่ปฏิบัติตามอาจสั่งระงับบริการหรือการใช้งาน

5. เหตุร้ายแรง ซึ่งเปิดทางให้ระงับชั่วคราวหรือเรียกคืนระบบ

6. การกำกับดูแลในกรณีที่ไม่อยู่ภายใต้หน่วยงานเฉพาะด้านเพียงหน่วยเดียว

7. บทกำหนดโทษ รวมถึงความรับผิดทางแพ่งและโทษปรับทางปกครอง

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

ทำไมคนจ้างทำระบบจึงควรสนใจ ทั้งที่ยังเป็นแค่ร่าง

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

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

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

คำถามห้าข้อที่ถามผู้พัฒนาได้ก่อนเซ็นสัญญา

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

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

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

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

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

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

เขียนลงสัญญาอย่างไรโดยไม่เสี่ยงเขียนผิดตามร่าง

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

• ผู้พัฒนาต้องส่งบัญชีฟังก์ชัน AI พร้อมงานที่ทำ ผู้ให้บริการภายนอก และประเภทข้อมูลที่ส่งออก เป็นส่วนหนึ่งของเอกสารส่งมอบ และปรับปรุงทุกครั้งที่เพิ่มหรือเปลี่ยนฟังก์ชัน

• ฟังก์ชัน AI ต้องปิดได้เป็นรายตัว โดยไม่กระทบฟังก์ชันหลักอื่น และผู้ว่าจ้างถือสิทธิ์ปิดเอง

• ระบบต้องบันทึกร่องรอยการทำงานของ AI ตามรายการที่ตกลงกัน และเก็บตามระยะเวลาที่ผู้ว่าจ้างกำหนด

• ผู้พัฒนาต้องแจ้งเมื่อเปลี่ยนโมเดลหรือผู้ให้บริการที่อยู่ข้างหลัง เพราะพฤติกรรมของระบบอาจเปลี่ยนโดยที่โค้ดของผู้ว่าจ้างไม่เปลี่ยนสักบรรทัด

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

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

เรื่องที่ผู้พัฒนาเองก็ควรตอบได้

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

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

ข้อจำกัดที่ต้องบอกตรง ๆ

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

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

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

ข้อโต้แย้งที่ได้ยินบ่อย

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

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

จะเริ่มตรงไหน

1. รวบรวมสัญญาและข้อเสนอที่มีฟังก์ชัน AI อยู่ ทั้งที่กำลังร่างและที่ใช้อยู่แล้ว อย่าลืมซอฟต์แวร์สำเร็จรูปที่เพิ่มฟังก์ชันใหม่ในการอัปเดต

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

3. ทดลองปิดฟังก์ชัน AI หนึ่งตัวในสภาพแวดล้อมทดสอบ แล้วดูว่าระบบอื่นทำงานต่อได้ไหม จดสิ่งที่พังไว้

4. ตรวจว่าระบบเก็บ log ของฟังก์ชัน AI หรือไม่ และถ้าเก็บ มีข้อมูลส่วนบุคคลอยู่ในนั้นแค่ไหน

5. นัดฝ่ายกฎหมายอ่านร่างตัวเต็มพร้อมกับตารางคำตอบ และกำหนดวันทบทวนเมื่อมีข่าวความคืบหน้าของร่าง

สรุป

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

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส