AI Security ในโรงงานอุตสาหกรรม: เมื่อ AI ที่ปกป้องสายการผลิต กลายเป็นเป้าหมายของผู้โจมตี

เมื่อ AI เข้ามาอยู่ในสายการผลิต ใครจะเป็นคนเฝ้า AI ของคุณ?

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

รายงานดัชนีภัยคุกคามไซเบอร์ระดับโลกปี 2025 ระบุว่าอุตสาหกรรมการผลิตครองสัดส่วนการโจมตีทางไซเบอร์ถึง 17% ของทั้งหมดในปี 2025 เพิ่มขึ้นจาก 9% เมื่อปีก่อน ขณะที่ผลสำรวจผู้ผลิตทั่วโลกช่วงต้นปี 2026 พบว่า 40% ของผู้ผลิตส่วนใหญ่ระบุว่าความมั่นคงปลอดภัยไซเบอร์เป็นอุปสรรคอันดับ 1 ของการนำ AI มาใช้ — พวกเขามองเห็นความเสี่ยง แต่ทางออกที่ถูกต้องไม่ใช่การใช้ AI ให้น้อยลง หากคือการออกแบบระบบ AI ที่ “ปลอดภัยตั้งแต่ต้นทาง” (Security by Design)

AI ในโรงงานถูกโจมตีได้จากทางไหนบ้าง?

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

ทำไมเครื่องมือความปลอดภัยแบบเดิมจับไม่ได้?

เหตุผลแรกคือ ลายเซ็น (signature) ไม่มีอยู่ — การโจมตี AI ไม่ได้ส่งพัคเก็ตที่ผิดปกติ ไม่มีไฟล์แปลกปลอม และไม่มีพฤติกรรมเครือข่ายที่หนักผิดปกติ สิ่งที่เปลี่ยนไปคือ “การกระจายของค่าความน่าจะเป็น” ในเลเยอร์สุดท้ายของโมเดลเท่านั้น เหตุผลที่สองคือ ความเสียหายสะสมช้า — model poisoning อาจใช้เวลาหลายสัปดาห์กว่าผลกระทบจะปรากฏเป็นตัวเลข scrap rate ที่เพี้ยน ซึ่งมักถูกอธิบายว่าเป็นความผันผวนปกติของกระบวนการผลิต

มาตรการป้องกัน 6 ชั้นที่ควรทำตามลำดับ

1. จัดทำ AI Asset Inventory — เขียนทะเบียนโมเดล AI ทุกตัวในโรงงาน: ทำหน้าที่อะไร ใช้ข้อมูลอะไร ใครเป็นเจ้าของ และตัดสินใจแทนคนมากแค่ไหน สิ่งที่มองไม่เห็นคือสิ่งที่ป้องกันไม่ได้
2. ควบคุมเวอร์ชันและลายเซ็นโมเดล — เก็บไฟล์โมเดลใน repository ที่มี access control เข้ารหัสและตรวจสอบ hash ทุกครั้งก่อน deploy ลง edge device ด้วยแนวทางเดียวกับที่ทำกับ firmware
3. แยกโซนเครือข่ายของระบบ AI — วาง inference server ไว้ในโซนที่แยกจากทั้ง IT และ control network ตามแนวทาง IEC 62443 แล้วควบคุมการสื่อสารด้วย allowlist
4. ควบคุมคุณภาพข้อมูลเข้าโมเดล — ตรวจสอบ provenance ของข้อมูลเทรนและข้อมูล inference แยกสิทธิ์การเขียนข้อมูลออกจากผู้ใช้ทั่วไป และตั้งระบบแจ้งเตือนเมื่อการกระจายข้อมูลเข้า (input distribution) เล็ดออกจากช่วงปกติ
5. เฝ้าระวังพฤติกรรมโมเดลต่อเนื่อง — ติดตามค่าความมั่นใจเฉลี่ย อัตราการเปลี่ยนการตัดสินใจ และ drift metrics เช่น PSI อย่างสม่ำเสมอ การที่โมเดลมั่นใจผิดๆ อย่างสม่ำเสมอคือสัญญาณของการถูกโจมตี ไม่ใช่แค่ model drift
6. กำหนด Human-in-the-loop สำหรับการตัดสินใจที่สำคัญ — การสั่งหยุดเครื่องจักร การเปลี่ยนพารามิเตอร์ที่กระทบความปลอดภัย ควรผ่านการยืนยันจากวิศวกรเสมอ AI แนะนำได้ แต่ต้องไม่เป็นผู้ถือกุญแจสุดท้าย

ประสบการณ์ภาคสนาม: ทีมงาน Honey Corporation พบว่าโครงการ AI ในโรงงานที่ล้มเหลวส่วนใหญ่ไม่ได้ล้มที่ความแม่นยำของโมเดล แต่ล้มที่การไม่มีใครรับผิดชอบโมเดลหลังวัน go-live การวาง AI governance ไว้ล่วงหน้าจึงสำคัญพอๆ กับความแม่นยำของ AI เอง

Key Takeaways

• การโจมตี AI ในโรงงานไม่ได้มากับ malware แต่มากับการบิดเบือนข้อมูลและกระบวนการตัดสินใจ ซึ่งเครื่องมือ signature-based ตรวจไม่พบ
• รายงานภัยคุกคามระดับโลกชี้ว่าอุตสาหกรรมการผลิตโดนโจมตี 17% ของทั้งหมดในปี 2025 (เพิ่มจาก 9% ปีก่อน) และ 40% ของผู้ผลิตยังมองว่า security เป็นอุปสรรค์อันดับ 1 ของการใช้ AI
• Model poisoning และ data evasion ทำให้ความเสียหายสะสมแบบเงียบๆ คล้าย model drift — ต้องเฝ้าระวัง drift metrics ควบคู่กับ security monitoring
• ป้องกัน 6 ชั้นเริ่มจาก AI asset inventory → ควบคุมเวอร์ชันโมเดล → แยกโซนตาม IEC 62443 → คุมข้อมูลเข้า → เฝ้าพฤติกรรมโมเดล → human-in-the-loop
• AI governance ที่ดีไม่ได้ชะลอโครงการ AI แต่ทำให้โครงการอยู่รอดหลัง go-live และผ่านการตรวจสอบจากลูกค้าและผู้กำกับดูแล
• คำถามที่ควรถามวันนี้: ถ้าโมเดลตรวจคุณภาพถูกโจมตีเมื่อวาน องค์กรจะรู้ได้จากสัญญาณใด ถ้าตอบไม่ได้ แปลว่ายังไม่มีระบบเฝ้าระวัง AI ที่แท้จริง