AI จัดการความปลอดภัยในโรงงาน: คู่มือ RFP และการตรวจรับกล้อง

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

ข้อสรุปสำหรับผู้บริหาร: จัดซื้อวงจรตั้งแต่การตรวจจับถึงการตอบสนองที่ทดสอบซ้ำได้

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

กล้อง AI ทั่วไปเป็นชั้นสำหรับการสังเกตและยกระดับเหตุ ไม่ได้กลายเป็นฟังก์ชันป้องกันที่ได้รับการจัดระดับความปลอดภัยโดยอัตโนมัติ และไม่ทดแทนการแยกเส้นทางรถกับคน รั้วป้องกัน interlock, light curtain, safety PLC, การฝึกอบรม ป้าย หรือ PPE หากต้องการให้เครื่องหยุดอัตโนมัติ ผู้เชี่ยวชาญที่มีคุณสมบัติต้องออกแบบและตรวจสอบฟังก์ชันความปลอดภัยทั้งระบบ ส่วนประกอบ พฤติกรรมเมื่อขัดข้อง และมาตรฐานที่ใช้ ตามระดับการลดความเสี่ยงที่ต้องการ คะแนนจาก computer vision เพียงอย่างเดียวห้ามถูกใช้เป็นวงจรความปลอดภัย

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

“AI เพื่อความปลอดภัยในโรงงาน” ควรครอบคลุมอะไร

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

กรณีใช้งานที่เหมาะแก่การพิจารณา ได้แก่

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

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

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

กลุ่มบริษัทที่ดำเนินธุรกิจใน EU ต้องประเมิน EU AI Act เพิ่มเติม Article 5(1)(f) ห้าม emotion recognition ในที่ทำงาน ยกเว้นเหตุผลทางการแพทย์หรือความปลอดภัย กฎนี้ไม่ใช่กฎหมายไทย และการตั้งชื่อโครงการว่า “ความปลอดภัย” ไม่ได้ทำให้เข้าเงื่อนไขยกเว้นโดยอัตโนมัติ หากใช้ platform ร่วมกับสาขา EU ให้ตรวจสอบกับฝ่ายกฎหมายท้องถิ่นและ DPO

วาง AI ไว้ในลำดับชั้นของมาตรการควบคุมอย่างถูกต้อง

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

ที่จุดตัดระหว่างรถยกกับคน คำถามแรกไม่ใช่ “AI ตรวจ near miss ได้หรือไม่” แต่คือแยกเส้นทาง ทำทางเดียว ยกเลิกจุดตัด ติดตั้งรั้วหรือประตู และปรับความเร็วหรือทัศนวิสัยได้หรือไม่ เอกสาร powered industrial trucks ของ OSHA ก็เน้นการแยกคนออกจากรถเมื่อทำได้ ทัศนวิสัย การเตือน และระยะปลอดภัย ทั้งนี้ใช้เป็นแหล่งอ้างอิงด้านการควบคุม hazard ไม่ใช่กฎหมายไทย

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

แยก video analytics ทั่วไปออกจาก safety-rated function

ระบบ video analytics ทั่วไปมักประกอบด้วยกล้อง network อเนกประสงค์ edge computer โมเดล AI message broker และ dashboard ซึ่งอาจไม่ได้ออกแบบให้ fail-safe เมื่อเกิด single fault, processing outage, delay หรือ configuration change การวาดกรอบสีแดงบนหน้าจอไม่ได้พิสูจน์ fault detection, diagnostic coverage, redundancy หรือเวลาตอบสนองสูงสุดของฟังก์ชันความปลอดภัย

หาก event จาก AI จะมีผลต่อการหยุดเครื่อง ต้องเริ่มจาก risk assessment และกำหนด required safety function ผู้เชี่ยวชาญต้องกำหนด architecture ของส่วนที่เกี่ยวข้องกับความปลอดภัย ข้อกำหนด performance level หรือ safety integrity และวิธี validation หากเชื่อม AI กับ safety PLC ต้องออกแบบความหมายของ interface ข้อมูลที่อาจสูญหาย วิธีรับมือการขาดการสื่อสาร และวิธีจัดการ score ที่ไม่แน่นอน บทความนี้ไม่ทดแทนวิศวกรรมหรือการรับรองความปลอดภัยเฉพาะเครื่อง

ISO 45001 สนับสนุนระบบจัดการอาชีวอนามัยและความปลอดภัยแบบอิงความเสี่ยงและ PDCA โดย ISO 45001:2018 ได้รับการยืนยันว่า current จากการ review ปี 2024 แต่คาดว่าจะมีฉบับทดแทน จึงไม่ควรอ้างว่า “ฉบับปี 2026” ที่ยังไม่ได้ยืนยันได้ประกาศแล้ว ให้ตรวจฉบับทางการล่าสุดและเงื่อนไขการเปลี่ยนผ่าน ณ เวลาทำสัญญา

Architecture ตั้งแต่กล้อง AI ถึงการตอบสนองและกู้คืน

เส้นทางหลักคือ CAMERA → EDGE INFERENCE → EVENT GATEWAY → ALERT ROUTER → HUMAN RESPONSE โดย EVENT GATEWAY และ ALERT ROUTER ส่งข้อมูลเข้า AUDIT LOG ส่วน SAFETY PLC แยกเป็นกล่องต่างหาก หากเชื่อมต่อ ให้ใช้เฉพาะเส้นประ ENGINEERED INTERFACE พร้อมคำกำกับ NOT AN AI SCORE

CAMERA รับภาพ แต่ field of view, exposure, frame rate, เวลา และ health status ก็ต้องถูกจัดการ EDGE INFERENCE ประเมินวัตถุและความสัมพันธ์ พร้อม model ID, version, confidence, bounding region และ event time EVENT GATEWAY ไม่ควรเปลี่ยนทุก frame ที่สั่นไหวเป็น alarm แต่ต้องรวมผลกับกฎ zone ระยะเวลา ทิศทาง การยับยั้งแจ้งซ้ำ และสถานะอุปกรณ์ เพื่อสร้าง operational event

ALERT ROUTER ส่ง event ตามความรุนแรง เวลา พื้นที่ และกะ ไปยัง andon, mobile device, control room หรือหัวหน้างาน ไม่ควรพึ่ง chat notification ช่องทางเดียว ต้องมี escalation เมื่อส่งไม่สำเร็จ ไม่มี acknowledgement หรือผู้รับไม่อยู่ HUMAN RESPONSE runbook ต้องระบุว่าใครตรวจภาพ ติดต่อหน้างาน หยุดงาน จัดการช่วยเหลือหรือแยกพื้นที่ จัดประเภท false alarm และอนุมัติ restart

AUDIT LOG ไม่ใช่เพียงที่เก็บวิดีโอ ต้องเชื่อม source event, camera/model/rule version, ผู้รับ, delivery result, acknowledgement, การปฏิบัติ และ restart approval ด้วย correlation ID เดียว ควรแยก retention ของ metadata กับ event clip เพื่อให้ตรวจสอบได้โดยไม่เก็บ personal data เกินจำเป็น

รวมความขัดข้องไว้ในสถานการณ์ใช้งาน

โรงงานย่อมพบ network loss, camera obstruction, lens contamination, edge device ร้อนเกิน, clock drift, storage full และ certificate expiry หากระบบแยก “ไม่มีเหตุ” จาก “สังเกตไม่ได้” ไม่ได้ ความเงียบของระบบเองจะเป็นความเสี่ยง

ให้กล้องแต่ละตัวมี heartbeat และ last good frame ตรวจ frozen video, black frame, blur และ field of view ที่ขยับ กำหนดระยะที่ queue จาก edge ไป gateway เก็บ event เมื่อ offline และวิธีรับมือ overflow หาก real-time warning หยุด ให้แสดง degraded mode ต่อหน้างาน และกำหนดเงื่อนไขใช้มาตรการชดเชย เช่น เพิ่มการตรวจตราหรือปิดพื้นที่ เมื่อกู้คืน อย่าส่ง event เก่าจำนวนมากเป็นเหตุฉุกเฉินปัจจุบัน แต่ให้ sync เป็น historical evidence

ตำแหน่งกล้องและความพร้อมข้อมูลต้องมาก่อนการเลือกโมเดล

PoC กล้อง AI ในโรงงานมักประเมินสภาพภาพต่ำเกินไป ที่จุดเดียวกัน กลางวัน/กลางคืน เงาสะท้อนหลังฝนตก แสงย้อนจากประตู พื้นสะท้อน การสั่น เลนส์สกปรก และสินค้าบังคน ทำให้สิ่งที่มองเห็นเปลี่ยนไป ก่อนติดตั้งให้นำ hazard map ซ้อนกับ camera coverage map เพื่อยืนยันว่าตำแหน่งอันตรายและมุมที่จำเป็นต่อการจำแนกตรงกัน

อย่านับแค่จำนวนภาพ “คน” หรือ “รถยก” ให้จัดข้อมูลตาม scenario ได้แก่ เข้าใกล้ แยกออก เดินตามขอบ หยุด ถูกสินค้าบัง หลายวัตถุตัดกัน และเคลื่อนนอกพื้นที่ หาก frame คลุมเครือโดยธรรมชาติ ให้ EHS กับ Operations กำหนดกฎ ไม่บังคับ annotator คนเดียวเดา

ควรตรวจว่ากลุ่มปฏิบัติงานส่วนน้อยมี performance ลดลงหรือไม่ สีชุด รูปร่าง อุปกรณ์ช่วยเคลื่อนไหว เสื้อกันฝน หรือ PPE ของผู้รับเหมาอาจสร้างความต่างด้านการตรวจจับและความไม่เท่าเทียมด้านความปลอดภัย แต่ไม่ใช่เหตุให้เพิ่มการอนุมาน attribute หรือ face recognition ที่ไม่จำเป็น ให้ประมวลเฉพาะ object และ state ที่จำเป็น และเปรียบเทียบ edge processing กับการส่งวิดีโอต่อเนื่องไป external cloud

ตัวชี้วัดตรวจรับ: แยก “accuracy” เป็นตัวชี้วัดปฏิบัติการ

accuracy อาจดูสูงเมื่อข้อมูลส่วนใหญ่เป็นภาวะปกติ หากเหตุอันตรายเกิดน้อย โมเดลที่ตอบ “ไม่มีอันตราย” ตลอดก็อาจได้ตัวเลขดูดี จึงต้องสร้าง confusion matrix ราย scenario และวัด precision, recall, false alarms per camera-hour, latency, coverage, availability และ evidence completeness แยกกัน

• Recall: สัดส่วน test ที่ hazard เกิดจริงและตรวจพบ เน้นการพลาด
• Precision: สัดส่วน event ที่แจ้งว่าอันตรายแล้วถูกต้อง เกี่ยวข้องกับ alarm fatigue
• False alarms per camera-hour: ภาระการทำงานต่อเวลาที่กล้อง active
• Detection latency: เวลาจาก scenario เริ่มถึงสร้าง event ให้ดู p95/p99 ไม่ใช่ค่าเฉลี่ยอย่างเดียว
• Alert-delivery latency: เวลาจากสร้าง event ถึงผู้รับ แยกเวลา inference จากการสื่อสาร
• Coverage / blind-zone rate: สัดส่วนพื้นที่ hazard ที่สังเกตและจำแนกได้หรือไม่ได้อย่างมีประสิทธิผล
• Availability: ช่วงที่ observation, inference และ routing ใช้งานได้ แยก planned/unplanned downtime
• Evidence completeness: สัดส่วนกรณีที่มี event, clip, model/rule version, delivery และ response ครบ

บทความนี้ไม่สามารถกำหนด threshold สากล เพราะขึ้นกับ hazard severity ความเร็วเข้าใกล้ มาตรการชดเชย จำนวนกล้อง และขั้นตอนตอบสนอง RFP ไม่ควรขอ “industry-standard accuracy” แต่ให้กำหนด acceptance gate จาก site-specific risk assessment และตกลง test population กับวิธีใช้ confidence interval

ตัวอย่างโครงสร้าง acceptance gate

รายการต่อไปนี้เป็น project example ไม่ใช่ค่าผ่านสากล

1. EHS บันทึก severity, exposure, avoidability และ existing control ของแต่ละ hazard
2. แบ่ง scenario ตาม day/night, clear/occluded, single/multiple object และสภาพที่เกี่ยวข้อง
3. ตรึง expected event, ผู้รับ, response และ evidence ก่อนทดสอบ
4. ผู้ขายใช้ข้อมูลที่เป็นอิสระจาก training set และส่ง confusion matrix กับ latency percentile
5. scenario สำคัญเน้น miss ส่วน scenario ความรุนแรงต่ำต้องดู false alarm ที่อาจทำให้การปฏิบัติงานล้มเหลว
6. critical negative test ที่ไม่ผ่านห้ามถูกเฉลี่ยกลบ ต้องแก้และทดสอบใหม่

หลัง update โมเดล ให้รัน golden test pack เดิม อย่า release รุ่นที่ overall metric ดีขึ้นแต่กะกลางคืน กล้องบางตัว หรือชุดผู้รับเหมาแย่ลง ใน production ให้ติดตามความสว่าง blur ขนาด object และ event rate เพื่อหา input/performance drift แล้วให้คน review หากไม่มี ground truth ปัจจุบัน operational indicator อย่างเดียวพิสูจน์ไม่ได้ว่าความแม่นยำคงเดิม

กำหนดผลส่งมอบ RFP และความรับผิดชอบพร้อมกัน

AI เฝ้าระวังความปลอดภัยเกี่ยวข้องกับ camera vendor, AI vendor, network/infrastructure, system integrator, EHS, IT/OT, Legal/DPO และ Operations การแบ่งว่า “AI เป็นของ vendor ข้อมูลเป็นของ customer” ทำให้ boundary failure ตกหล่น จึงต้องขอ deliverable และ RACI ใน work package เดียวกัน

หากมี works council หรือ worker representatives ให้เข้าร่วมตั้งแต่การออกแบบ use case และ change control ไม่ใช่เพียงเพื่อขั้นตอนทางกฎหมาย แต่เพื่อกำหนดการคัดค้านเมื่อ false alarm การเข้าถึงภาพ และการป้องกันการใช้ลงโทษรายบุคคลในภาษาที่คนงานเข้าใจ รายงาน ILO เรื่อง AI, digitalization และ OSH กล่าวถึงทั้งศักยภาพการป้องกันของ smart monitoring และความจำเป็นต้องจัดการความเสี่ยงใหม่แบบ proactive/adaptive พร้อม worker participation

สัญญาควรระบุ model/cloud subprocessor, ที่ตั้งข้อมูล, security incident notification, vulnerability response, support hour, export format และการคืนหรือลบข้อมูลเมื่อสิ้นสุด เพื่อลด lock-in ต้องส่งออก event log, configuration, annotation guideline, test pack และ model release history ในรูป machine-readable ได้

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

PoC, FAT และ SAT ต้องมี negative test

PoC ไม่ใช่งานสาธิตกรอบตรวจจับที่สวยงาม แต่ใช้ทดสอบว่า use case และสมมติฐานปฏิบัติการใช้ได้จริง อะไรมองเห็นเมื่อระบบล้มเหลว และภาระงานยอมรับได้หรือไม่ FAT ทดสอบ function, interface และ failure handling ซ้ำได้ด้วย version และข้อมูลคงที่ในสภาพแวดล้อมผู้ขาย SAT ตรวจรับ end-to-end ด้วยกล้อง แสง network อุปกรณ์แจ้ง บุคลากร และกะที่ใกล้ production

acceptance matrix มีแถว DAY, NIGHT, OCCLUSION, NETWORK LOSS, CAMERA BLOCKED และคอลัมน์ DETECT, ALERT, RESPOND, EVIDENCE ทุก cell ปิดด้วย PASS/FAIL ส่วนค่ารายละเอียดเชื่อมไป test report ไม่ใส่เปอร์เซ็นต์ที่แต่งขึ้นในภาพ สำหรับ NETWORK LOSS ห้ามจบว่า “DETECT เป็น N/A” แต่ต้องประเมินการตรวจพบว่าสังเกตไม่ได้ degraded notification มาตรการชดเชย และหลักฐานกู้คืน

อย่างน้อยต้องมี test case ต่อไปนี้

• Positive scenario: เป้าหมายเข้า/ใกล้ตาม zone ทิศทาง และระยะเวลาที่กำหนด
• Boundary: เส้นขอบ ค่า threshold การผ่านสั้น หลายเป้าหมาย และเห็นเพียงบางส่วน
• Negative: การผ่านนอก zone, poster/reflection, รถจอด และงานบำรุงรักษาที่อนุญาตต้องไม่กลายเป็น hazard event
• Occlusion: เสา pallet สินค้า หรือรถอื่นบังเป้าหมายบางส่วน/ทั้งหมด
• Environmental: day/night, การเปลี่ยนไฟ ย้อนแสง ฝน ฝุ่น การสั่น และเลนส์สกปรก
• Network loss: แยก camera–edge, edge–gateway และ gateway–router
• Camera blocked/moved: ตรวจ black frame, frozen video, blur และมุมเปลี่ยน
• Alert delivery: primary route ล้มเหลว backup route, ack timeout และ escalation
• Model rollback: กลับไป approved version เมื่อรุ่นใหม่เกิด regression
• Clock anomaly: รักษาลำดับและ audit เมื่อเวลาคลาด replay ช้า และ event ซ้ำ
• Human response: ผู้รับตรวจ ยับยั้งเหตุ บันทึก และ restart ตาม runbook ได้
• Evidence: สร้าง input, decision, alert, action และ change history ใหม่ได้ด้วย correlation ID เดียว

อย่าปิด FAT/SAT ด้วยคำว่า “ยืนยันบนหน้าจอ vendor” ต้องบันทึก test ID, precondition, input, expected result, actual result, link หลักฐาน, reviewer, date และ software/model/config version เมื่อแก้ failure แล้ว ให้รัน regression set ที่ได้รับผลกระทบด้วย ไม่ใช่เฉพาะกรณีที่เคย fail

วัด response ทั้งเส้นทาง ไม่ใช่ inference เท่านั้น

แยกเวลาจาก hazard เริ่มถึงคนลงมือเป็น T_total = T_capture + T_inference + T_gateway + T_delivery + T_ack + T_action สูตรนี้ใช้เพื่อออกแบบ ค่าอนุญาตต้องมาจาก risk assessment ของ site demo ที่เร็วไม่มีความหมายหากผู้รับกะดึกไม่อยู่ mobile silent หรือไม่กำหนดสิ่งที่ต้องทำหลัง ack

p95/p99 ช่วยให้เห็น tail latency แต่ percentile จาก sample น้อยไม่เสถียร ต้องบันทึกจำนวนครั้ง กะ และ network condition เพื่อไม่ใช้คำว่า “p99” สร้างภาพความน่าเชื่อถือ สำหรับ safety function ที่หยุดเครื่องอัตโนมัติ ค่าเฉลี่ยและ percentile ไม่เพียงพอ ต้องออกแบบและ validate worst-case response time กับ failure behavior ตามมาตรฐานที่ใช้แยกต่างหาก

PDPA ไทยและการกำกับดูแลข้ามพรมแดน

ภาพพนักงานที่ระบุตัวได้อาจเป็นข้อมูลส่วนบุคคล การปฏิบัติตาม PDPA ไทยต้องยืนยัน lawful basis, notice, purpose limitation, minimization, retention, access control, การรองรับเจ้าของข้อมูล, processor/cloud contract, cross-border transfer และ security กับที่ปรึกษากฎหมายไทยหรือ DPO บทความนี้ไม่ใช่คำปรึกษากฎหมายเฉพาะกรณี

ความสำคัญของความปลอดภัยไม่ทำให้การเฝ้าระวังไร้ขอบเขตชอบธรรม ต้องกำหนดพื้นที่ event ผู้ใช้ ระยะเก็บ และ secondary use ไม่ใช่เขียนเพียง “ป้องกันอุบัติเหตุ” เปรียบเทียบการบันทึกต่อเนื่องกับ short event clip, edge anonymization กับ cloud และ object detection โดยไม่ใช้ face recognition

อย่ากำหนด retention ตัวเลขเดียวให้ข้อมูลทุกชนิด raw video อาจเก็บสั้น anonymized statistics นานกว่า และ incident evidence อยู่ภายใต้ formal hold ระยะจริงต้องอิงกฎหมาย ประกัน แรงงาน ลูกค้า และกระบวนการสอบสวน

Thailand และ ILO จัด national workshop เมื่อ 25 มีนาคม 2025 เพื่อปรับปรุงการบันทึกและแจ้งอุบัติเหตุ/โรคจากการทำงาน ห้ามนำจำนวน event จากกล้อง AI ไปเท่ากับสถิติอุบัติเหตุทางการ แต่แนวทางร่วมกันคือใช้คำนิยามชัด จัดการข้อมูลขาดและการแก้ไข และเพิ่มคุณภาพหลักฐานเพื่อการป้องกัน

เปรียบเทียบต้นทุน TCO และ ROI ด้วยสูตร ไม่สร้างราคาตลาด

ต้นทุนกล้อง AI ในโรงงานไม่ได้ขึ้นกับจำนวนกล้องหรือ license เท่านั้น การใช้กล้องเดิม แสง edge compute งาน network, OT integration, labeling, privacy, support ตลอดเวลา และ model update ทำให้ยอดต่างกันมาก RFP ควรเทียบรายการเดียวกันในช่วงที่ผู้ซื้อกำหนด เช่น 3–5 ปี ไม่ใช้ “ราคาทั่วไป” ที่ไม่มีหลักฐาน

TCO = อุปกรณ์เริ่มต้น + ออกแบบ/ติดตั้ง + edge/cloud + integration + data/labeling + FAT/SAT + security/privacy + training + ค่าใช้จ่ายรายปี×จำนวนปี + refresh/retraining + exit cost

Annual benefit = expected avoidable incident loss + เวลาสอบสวนที่ลด + downtime ที่ลด + มูลค่าการจัดสรรงาน patrol ใหม่ + ผลประกัน/ตรวจสอบที่ยืนยันได้

ROI = (benefit ในช่วงประเมิน - TCO) / TCO

สูตรเหล่านี้กำหนดโครง input ไม่ใช่ผลสากล EHS, Finance และ Operations ควรให้ค่าเป็น range ไม่ใช้สมมติฐาน vendor เติมมูลค่าการหลีกเลี่ยงเหตุหรืออัตราลด สำหรับเหตุที่โอกาสต่ำแต่ผลกระทบสูง ใช้ conservative/base/upside scenario จะชัดกว่าค่าเฉลี่ยเดียว

การคูณ PoC ตามจำนวนกล้องก็เสี่ยง เมื่อกล้องเพิ่ม ความหลากหลาย network segment, alert routing, maintenance access และ false-alarm handling อาจโตแบบไม่เป็นเส้นตรง ก่อน controlled scale ให้คำนวณ workload จาก false alarm per camera-hour และ review time per event

BOI ไทยรายงานว่าในครึ่งแรกปี 2026 มีโครงการส่งเสริมการลงทุนที่อนุมัติ 1,300 โครงการ มูลค่าประมาณ THB 1.31 trillion รวมโครงการปรับปรุง machinery, digital technology, automation และ robotics มูลค่า THB 17.2 billion ข้อมูลนี้เป็นบริบทการลงทุน ไม่ได้หมายความว่าโครงการกล้อง AI ทุกโครงการได้รับสิทธิประโยชน์ ต้องตรวจ activity ช่วงเวลา และเงื่อนไขกับ BOI หรือผู้เชี่ยวชาญ

แผน controlled rollout 90 วัน

timeline ตัวอย่างคือ 0–30 MAP HAZARD & DATA → 31–60 POC & NEGATIVE TESTS → 61–90 SAT & GOVERNANCE → CONTROLLED SCALE โดยมี EHS, OPERATIONS, IT/OT, DPO และ VENDOR สนับสนุน นี่ไม่ใช่คำสัญญาว่าจะเสร็จทั้งโรงงานใน 90 วัน แต่เป็นกรอบรวบรวมหลักฐานสำหรับตัดสินใจจัดซื้อและตรวจรับในพื้นที่สำคัญหนึ่งแห่ง

วันที่ 0–30: ตรึง hazard และ data boundary

EHS กับ Operations ทบทวน incident, near miss, traffic และ existing control แล้วเลือกหนึ่งหรือสอง scenario เดินสำรวจเพื่อดูตำแหน่งกล้อง แสง การบดบัง และ maintenance access IT/OT ทำ network zone, edge placement, time sync และ alert interface DPO/Legal ยืนยัน purpose, basis, notice, retention, access และ worker consultation

ผลส่งมอบปลายช่วงคือ use-case sheet ที่อนุมัติ hazard/coverage map, data flow, exclusions, RACI และ test outline ห้ามให้ vendor “ถ่ายก่อนแล้วค่อยฝึก” ก่อนอนุมัติขอบเขตการเก็บ

วันที่ 31–60: รัน PoC และ negative test

เก็บข้อมูลจากกะกลางวัน/กลางคืนที่เป็นตัวแทน ทำ annotation rule และ golden test pack เชื่อม camera, edge, gateway, router แล้วรัน positive, boundary, negative, occlusion, network loss และ camera blocked วัด false alarm per camera-hour, p95/p99 latency, evidence completeness และ operator workload ควบคู่ precision/recall

weekly review ต้องดูว่าการปรับ threshold เพียงซ่อน false alarm หรือการแก้ scenario หนึ่งทำ recall อีก scenario ลดหรือไม่ บันทึก model/rule/config version และเหตุผลทุกครั้ง พร้อมเส้นทาง rollback

วันที่ 61–90: ปิด SAT การฝึก และ governance

ทำ SAT ด้วย network อุปกรณ์แจ้ง กะ และผู้รับที่ใกล้ production ตรวจ acknowledgement, response หน้างาน, escalation, degraded mode, recovery และ rollback ตาม runbook อธิบาย purpose พื้นที่ ข้อห้ามใช้ และช่องทางสอบถามแก่ worker พร้อมฝึก supervisor และ maintenance

ไป controlled scale ต่อเมื่อ critical test ปิดครบ unresolved risk มี owner/กำหนดเวลา privacy/security อนุมัติ และ operation/support พร้อม สำหรับพื้นที่ถัดไป ใช้โครงเดิมแต่เพิ่ม hazard, lighting, traffic, uniform และ vehicle เฉพาะพื้นที่

ใช้ NIST AI RMF กำกับตลอดวงจรชีวิต

NIST AI Risk Management Framework จัดการความเสี่ยง AI ด้วย Govern, Map, Measure, Manage ไม่ใช่ข้อบังคับทางกฎหมายไทย แต่ใช้เป็น governance scaffolding สำหรับ AI โรงงานได้

• Govern: กำหนด policy, owner, approval, competence, vendor duty, worker participation และ record
• Map: ทำความเข้าใจ hazard, user, ผู้ได้รับผล, data flow, existing control และ failure context
• Measure: ทดสอบ scenario metric, กลุ่มปฏิบัติงาน, latency, availability, privacy/security และ human factors
• Manage: จัดลำดับ risk และตัดสินใจ deploy, limit, stop, correct, rollback หรือ retire

อย่าสรุปว่า event จาก AI มากขึ้นแปลว่าความปลอดภัยแย่ลง เพราะอาจเพียงมองเห็นมากขึ้น ในทางกลับกัน event ลดอาจเกิดจาก control ดีขึ้น กล้องสกปรก หรือ threshold เปลี่ยน ต้องเทียบกับ near miss, การสังเกตหน้างาน การเปลี่ยนอุปกรณ์ และ worker feedback

model change, ย้ายกล้อง, layout เปลี่ยน, ชุดหรือรถใหม่ และ software update เป็น trigger ให้ประเมินใหม่ รัน golden test ก่อน/หลัง และหยุด release หากมี critical regression การตรวจสอบต้องเห็นได้ว่าเปลี่ยนเพราะอะไร ใครอนุมัติ และผ่าน test ใด ไม่ใช่แค่ติดตั้ง “รุ่นล่าสุด”

FAQ: คำถามก่อนจัดซื้อ AI เฝ้าระวังความปลอดภัยในโรงงาน

AI เพื่อการจัดการความปลอดภัยคืออะไร?

ระบบที่สังเกตสัญญาณของสถานการณ์อันตรายที่กำหนดจากภาพหรือ sensor แล้วเชื่อมกับการแจ้ง การตอบสนอง และการปรับปรุง กล้อง AI ทั่วไปเป็น observation/escalation layer ไม่ใช่ safety-rated function โดยตัวมันเอง ต้องพิจารณาการกำจัด ทดแทน และ engineering control ก่อน

กล้อง AI แทนรั้วหรือ light curtain ได้หรือไม่?

ไม่ควรสมมติว่าแทนได้ video analytics ทั่วไปไม่ควรแทนการแยก รั้ว interlock, safety PLC หรือ light curtain หากมี automatic stop ผู้เชี่ยวชาญต้องออกแบบและ validate ฟังก์ชันทั้งระบบตาม risk reduction และมาตรฐานที่ใช้

การตรวจจับรถยกกับคนเดินเท้าต้องทดสอบอะไร?

ทดสอบทิศทาง ความเร็ว การตัดกัน การหยุด สินค้าบัง หลายคน day/night และขอบเขต ไม่ใช่ระยะอย่างเดียว ตรวจรับ recall, precision, false alarm per camera-hour, p95/p99 detection/alert latency, coverage, evidence completeness และ human response แยกกัน

ความแม่นยำกี่เปอร์เซ็นต์จึงผ่านสำหรับ AI ความปลอดภัย?

ไม่มีเปอร์เซ็นต์สากล ให้ตั้ง threshold เฉพาะ site จาก hazard severity, avoidability, existing control, response time และสภาพจริง แยก critical-scenario recall, false alarm, latency, availability และ blind zone แทน overall accuracy ค่าเดียว

หาก network ขาดระหว่างตรวจเขตอันตรายต้องทำอย่างไร?

ตรวจ loss of observation แจ้ง degraded mode และเปลี่ยนไปใช้ compensating control เช่น เพิ่ม patrol หรือจำกัดพื้นที่ ทดสอบ offline buffer, resync, old event และ evidence gap ใน FAT/SAT วิธีรักษาความปลอดภัยระหว่างสื่อสารขาดต้องมาจาก risk assessment

ภาพพนักงานอยู่ภายใต้ PDPA ไทยหรือไม่?

ภาพที่ระบุตัวบุคคลได้อาจเป็น personal data ต้องยืนยัน lawful basis, notice, purpose limitation, retention, access, processor/cloud contract, cross-border transfer และ security กับฝ่ายกฎหมายไทยหรือ DPO และป้องกันการนำไป productivity scoring หรือจัดอันดับลงโทษโดยไม่แจ้ง

PoC, FAT และ SAT ต่างกันอย่างไร?

PoC เรียนรู้ว่า use case และสมมติฐานใช้ได้ในสภาพหน้างานหรือไม่ FAT ทำ version/test pack คงที่ซ้ำใน environment ผู้ขาย SAT ตรวจรับ end-to-end ด้วยกล้อง network alert และคนที่ใกล้ production ทั้งสามต้องรวม negative test และ evidence

เปรียบเทียบค่าใช้จ่ายและ ROI ของกล้อง AI อย่างไร?

รวม installation, lighting, edge, network, integration, data/labeling, FAT/SAT, privacy/security, training, operations, retraining และ exit cost ไม่ใช่เฉพาะกล้อง ประเมินเวลาสอบสวน downtime และการจัดสรร patrol เป็น range แล้วทำ sensitivity analysis

สรุป: ทำให้ความปลอดภัยแข็งแรงด้วยหลักฐานการปฏิบัติงาน ไม่ใช่คะแนน AI

การจัดซื้อ AI เพื่อความปลอดภัยในโรงงานต้องได้มากกว่าวิดีโอสาธิต กำหนด hazard, coverage, model decision, alert, human response, recovery, audit และ privacy เป็นวงจรที่ทดสอบซ้ำได้ แล้วทดสอบทั้ง positive และ negative ใน PoC, FAT, SAT วางกล้อง AI เป็นชั้นเสริมใน hierarchy of controls และรักษาเส้นแบ่งกับ safety-rated function ให้ชัด

TOMAS TECH สนับสนุนได้ตั้งแต่การทำแผนที่เส้นทางรถยกและเขตอันตราย ออกแบบ camera/edge, RFP, PoC, FAT/SAT, IT/OT integration ไปจนถึงการปฏิบัติงานที่คำนึงถึง PDPA ไทย สามารถติดต่อเราได้ตั้งแต่ก่อนเลือกผลิตภัณฑ์ หรือเริ่มด้วยการทดสอบ 90 วันในพื้นที่สำคัญหนึ่งแห่ง

แหล่งข้อมูลปฐมภูมิและเอกสารอ้างอิง

• NIST AI Risk Management Framework
• NIST AI RMF Playbook
• OSHA: Powered Industrial Trucks — Pedestrian Traffic
• ISO: Occupational safety and health
• ISO 45001:2018
• ILO: Revolutionizing health and safety — the role of AI and digitalization at work
• ILO: AI-driven intrusive surveillance and loss of autonomy at work
• Thailand MDES: Personal Data Protection Act B.E. 2562 (2019)
• Thailand MDES: เอกสารกฎหมายคุ้มครองข้อมูลส่วนบุคคล
• EU AI Act, Regulation (EU) 2024/1689
• Thailand BOI: ผลการส่งเสริมการลงทุนครึ่งแรกปี 2026
• ILO: Thailand takes action to improve OSH statistics