อัปเดตเฟิร์มแวร์และโมเดลกล้อง AI ต้องตรวจอะไรก่อนกด

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

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

บทความนี้ว่าด้วยสิ่งที่ควรตรวจก่อนและหลังอัปเดตเฟิร์มแวร์หรือโมเดล AI ของกล้อง โดยอ้างแนวปฏิบัติความมั่นคงปลอดภัยระบบกล้องวงจรปิดที่ใช้ AI ของ สกมช. ฉบับ 1.0.0 (29 กันยายน 2569) ข้อ 3.4 เป็นหลัก ร่วมกับข้อ 3.5 3.6 3.7 และ 3.10 ส่วนเรื่องการจดจำใบหน้าและข้อมูลชีวมิติ ดู กล้อง AI จดจำใบหน้าและข้อมูลชีวมิติ

ทำไมอัปเดตกล้อง AI ไม่ใช่แค่กดแล้วเสร็จ?

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

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

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

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

ก่อนกดอัปเดต ต้องรู้อะไรบ้าง?

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

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

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

รายการนี้กว้างกว่าที่หลายคนคิด การเปลี่ยนค่าการตรวจจับหรือเกณฑ์ตัดสินใจเพียงตัวเลขเดียวก็นับเป็นการเปลี่ยนแปลงที่ควรพิจารณา ไม่ต้องรอให้เป็นเฟิร์มแวร์ทั้งก้อน

เมื่อไรเป็นการเปลี่ยนแปลง "ที่มีนัยสำคัญ"

เอกสารนิยามคำนี้ไว้ในข้อ 3.4.7 และบอกว่าเมื่อเกิดขึ้น ควรทบทวนหรือประเมินผลกระทบและความเสี่ยงใหม่ตามข้อ 3.1 ก่อนหรือหลังการเปลี่ยน แล้วแต่ลักษณะและความเร่งด่วน

เหตุการณ์ไหนต้องทดสอบหรือทบทวนอะไรก่อนใช้จริง?

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

ต้องทดสอบอะไรก่อน และทวนสอบอะไรหลังอัปเดต?

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

สำหรับระบบที่มีผลกระทบสูง เอกสารแนะให้กำหนดเกณฑ์ทดสอบและผู้มีอำนาจอนุมัติให้เหมาะกับความเสี่ยงก่อนนำเข้าระบบจริง ส่วนหลังอัปเดต ข้อ 3.4.4 ให้ทวนสอบว่าระบบยังอยู่ในสถานะที่อนุมัติไว้ (Approved State)

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

ชุดคลิปทดสอบ วิธีง่ายที่สุดที่จับความเปลี่ยนได้

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

ข้อ 3.5.3 ยกตัวอย่างสิ่งที่ควรเฝ้า ได้แก่ การแจ้งเตือนผิด (False Positive) การตรวจไม่พบ (False Negative) การจำแนกผิด และการระบุบุคคลผิด และเตือนว่าเมื่อสมรรถนะเปลี่ยนมาก ให้หาสาเหตุก่อนปรับค่าเกณฑ์

อัปเดตแล้วระบบเปลี่ยนพฤติกรรมเงียบ ๆ จับได้อย่างไร?

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

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

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

ตารางต่อไปนี้เป็นสถานการณ์สมมติสี่แบบที่ควรสังเกต พร้อมสิ่งที่ควรตรวจ การตีความเป็นของทีม AIPDPA

เฟิร์มแวร์ที่จะกดอัปเดตน่าเชื่อถือแค่ไหน?

ข้อ 3.7 ของแนวปฏิบัติบอกว่าความน่าเชื่อถือไม่ได้ดูแค่คุณสมบัติตอนซื้อ แต่ดูตลอดอายุการใช้งาน ตั้งแต่การพัฒนาอย่างปลอดภัย การออกชุดปรับปรุงความปลอดภัย การบริหารช่องโหว่ ไปจนถึงการสนับสนุนจนสิ้นอายุ

ตารางในข้อ 3.7.1 ยกตัวอย่างว่า ผลิตภัณฑ์ควรมีกลไกตรวจความถูกต้องและแหล่งที่มาของเฟิร์มแวร์หรือชุดปรับปรุงก่อนติดตั้ง เช่น การลงลายมือชื่อรหัสดิจิทัล (Code Signing) สำหรับผู้ซื้อ คำถามที่ถามผู้ขายได้คือ เฟิร์มแวร์นี้ลงลายมือชื่อหรือไม่ และโหลดจากช่องทางไหนของผู้ผลิต

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

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

ถ้าผู้ให้บริการเปลี่ยนโมเดลฝั่งเขา เราไม่ได้กดเอง จะรู้ได้อย่างไร?

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

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

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

วันอัปเดตจริงควรเรียงลำดับอย่างไร?

ไทม์ไลน์ต่อไปนี้เป็นข้อเสนอของทีม AIPDPA ที่เรียงขั้นตามหลักของข้อ 3.4 (ระบุ ประเมิน ทดสอบ อนุมัติ นำไปใช้ ทวนสอบ เฝ้าระวัง) แนวปฏิบัติ สกมช. ไม่ได้กำหนดระยะเวลาของแต่ละขั้น ช่วงเวลาที่ใส่ไว้จึงเป็นเพียงตัวอย่างให้ปรับตามขนาดระบบ

1. ก่อนวันอัปเดต: ระบุสถานะ
   จดรุ่นเฟิร์มแวร์ ซอฟต์แวร์ โมเดล AI ค่าตั้งที่กระทบ AI และระบบที่เชื่อมต่อ สำรองค่าตั้งปัจจุบัน และเก็บชุดคลิปทดสอบพร้อมผลของ AI ก่อนเปลี่ยนแนวปฏิบัติ สกมช. ข้อ 3.4.1
2. ก่อนวันอัปเดต: ประเมิน
   อ่านบันทึกการเปลี่ยนแปลงของผู้ผลิต ดูว่าเฟิร์มแวร์นี้แตะโมเดล ค่าตั้ง สิทธิ หรือการเชื่อมต่อส่วนไหน และจัดว่าเป็นการเปลี่ยนที่มีนัยสำคัญหรือไม่ข้อ 3.4.2 · ข้อ 3.4.7
3. ก่อนวันอัปเดต: ทดสอบกับกล้องตัวเดียว
   ลงเฟิร์มแวร์กับกล้องทดสอบหรือกล้องตัวที่ความเสี่ยงต่ำสุดก่อน แล้วทดสอบตามรายการในข้อ 3.4.3ข้อ 3.4.3
4. ก่อนวันอัปเดต: อนุมัติและเตรียมถอย
   ผู้มีอำนาจอนุมัติ ตกลงเงื่อนไขว่าผลแบบไหนต้องถอย และเตรียมไฟล์เฟิร์มแวร์เดิมไว้ข้อ 3.4.3 · ข้อ 3.4.4
5. วันอัปเดต
   ทำในช่วงที่การใช้งานกระทบน้อย ลงทีละกลุ่มกล้อง ไม่ลงพร้อมกันทั้งหมดถ้าทำได้ และจดเวลา ผู้ทำ และรุ่นก่อนหลังข้อ 3.5.1
6. ทันทีหลังอัปเดต
   ทวนสอบว่าระบบอยู่ในสถานะที่อนุมัติ ค่าตั้งความปลอดภัยและสิทธิไม่เปลี่ยน AI ให้ผลตรงชุดคลิปทดสอบ การบันทึกเหตุการณ์ยังทำงาน ถ้าพบความผิดปกติสำคัญ ให้จำกัดผลหรือถอยกลับข้อ 3.4.4
7. ช่วงเฝ้าระวังหลังอัปเดต
   เฝ้าอัตราแจ้งเตือนผิดและตรวจไม่พบ เปรียบกับก่อนอัปเดต ถ้าตัวเลขเปลี่ยนมาก หาสาเหตุก่อนปรับเกณฑ์ข้อ 3.5.2 · ข้อ 3.5.3
8. ปิดงาน
   บันทึกผลตรวจ ผู้รับผิดชอบ และสิ่งที่ต้องทำต่อ ใช้ระบบตั๋วหรือใบตรวจที่มีอยู่ได้ ไม่ต้องสร้างแบบฟอร์มใหม่ หากย้อนตรวจสอบได้ข้อ 3.6.5

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

ระบบ AIPDPA ช่วยได้ตรงทะเบียนระบบ AI ที่ลงรุ่นและผู้รับผิดชอบไว้ และประเมินความเสี่ยงของ AI ตามกรอบสากล ดูตัวอย่างได้ในบัญชีตัวอย่าง

ใครรับผิดชอบเนื้อหานี้?

เรียบเรียงโดยทีมกฎหมาย AIPDPA · ผู้รับผิดชอบเนื้อหา ภูวรา ครอบตะคุ ทนายความ · เนติบัณฑิตไทย · ที่ปรึกษากฎหมายเทคโนโลยีและทรัพย์สินทางปัญญา

ใบอนุญาตทนายความ 477/2558 · เนติบัณฑิตไทย · นิติศาสตรมหาบัณฑิต กฎหมายทรัพย์สินทางปัญญาและสารสนเทศ (เหรียญทอง)