ความปลอดภัย AI Agent ในโรงงาน: การออกแบบ OT, RFP และการรับมอบ

ความปลอดภัย AI Agent ในโรงงานเริ่มจากคำถามเรื่องขอบเขต ไม่ใช่คะแนนความสามารถของโมเดล: Agent อ่านอะไรได้ เปลี่ยนอะไรได้ และจุดใดต้องถูกหยุดโดยคนหรือระบบควบคุมแบบ deterministic เสมอ คำตอบผิดของ chatbot อาจจบอยู่บนหน้าจอ แต่ Agent ที่มีเครื่องมือเชื่อมใบงานซ่อมบำรุง แผน ERP คำสั่ง MES, PLC หรือหุ่นยนต์ สามารถทำให้ความผิดพลาดลามไปสู่การหยุดผลิต คุณภาพผิดข้อกำหนด หรือความเสียหายของเครื่องจักร บทความนี้ช่วยผู้บริหารโรงงาน ทีม OT/IT และผู้จัดซื้อในไทยออกแบบระดับความสามารถ สิทธิ์ขั้นต่ำ การอนุมัติ การแบ่งเครือข่าย kill switch หลักฐาน audit และ FAT/SAT อย่างเป็นระบบ

คำตอบสั้น: สร้างความปลอดภัย OT ของ AI Agent ไว้นอกโมเดล

จุดเริ่มต้นที่ปลอดภัยไม่ใช่การเชื่อ LLM ให้ทำหน้าที่เป็นอุปกรณ์นิรภัย โมเดลอาจเสนอหรือวางแผนการทำงาน แต่ไม่ควรเป็นผู้ตัดสินสุดท้ายเรื่องสิทธิ์ ช่วงค่า ลำดับคำสั่ง สถานะเครื่อง การหยุดฉุกเฉิน หรือพฤติกรรม fail-safe ต้องคง Safety PLC, Safety Instrumented System (SIS), วงจรนิรภัยที่ผ่านการรับรอง interlock ของเครื่อง และความรับผิดชอบของมนุษย์ให้เป็นอิสระจากโมเดล

การออกแบบที่ใช้งานจริงต้องรวมการควบคุมเก้าด้าน:

1. ตัวตน เจ้าของ วัตถุประสงค์ และวันหมดอายุที่ไม่ซ้ำกันของ Agent แต่ละตัว
2. ระดับความสามารถที่แยกการอ่าน การแนะนำ การเขียนแบบจำกัด และการสั่งงานโดยตรง
3. สิทธิ์ขั้นต่ำต่อเครื่องมือ ทรัพย์สิน ข้อมูล ช่วงเวลา และช่วงค่าที่อนุญาต
4. การแยกเอกสารหรือข้อมูลภายนอกที่ไม่น่าเชื่อถือออกจากเครื่องมือสั่งงาน
5. บริการอนุมัติและการแบ่งหน้าที่สำหรับงานความเสี่ยงสูง
6. interlock แบบ deterministic และ safe state ที่อยู่นอกโมเดล
7. AI Agent kill switch ที่เพิกถอนการสั่งงานได้ทันที
8. telemetry ที่เชื่อมคำสั่ง บริบท tool call การอนุมัติ และผลลัพธ์
9. rollback, incident response, change control และการส่งมอบหลักฐาน

คำแนะนำสำหรับภาคการผลิตของ Google Cloud ลงวันที่ 14 กันยายน 2026 เสนอให้ฝัง security ตลอดวงจรชีวิต Agent รวมการมองเห็น IT/OT จัดทำตัวตนและทะเบียน Agent และตรวจจับ Agent ที่ไม่ได้รับอนุญาต ข้อเหล่านี้เป็นคำแนะนำของผู้ให้บริการที่มีประโยชน์ แต่ไม่ใช่มาตรฐานกลางหรือใบรับรองความปลอดภัยของผลิตภัณฑ์ โรงงานต้องใช้ร่วมกับ risk assessment ของตน ข้อกำหนดผู้ผลิตเครื่องจักร functional safety, cybersecurity และกฎหมายท้องถิ่น

AI Agent ในโรงงานต่างจาก chatbot อย่างไร

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

บทความ “agentic factory” ของ Google Cloud วันที่ 10 กันยายน 2026 อธิบาย Agent ที่เชื่อมบริบทดิจิทัลกับการกระทำทางกายภาพภายใต้การกำกับของมนุษย์ บทความรายงานในฐานะกรณีของ Google/GE ว่า GE Appliances มี Agent ที่ปรับแต่งมากกว่า 800 ตัว และ Agent ประสานซัพพลายเออร์มากกว่า 600 รายช่วยลด backorder ที่รายงานไว้ 25% ตัวเลขนี้เป็นขององค์กรและ use case นั้น ไม่ใช่การรับประกันผลลัพธ์ทั่วไป ตัวอย่าง FANUC ที่เชื่อมคำสั่งภาษาธรรมชาติกับการเคลื่อนไหวของเครื่องก็เป็นกรณีของผู้ขาย ไม่ใช่หลักฐานว่าทุกโรงงานพร้อมใช้ระบบอัตโนมัติแบบ closed loop

แยกขอบเขตการทำงานสามประเภท

บทความนี้เน้นรอยต่อระหว่างงานติดกับ OT และการสั่งงาน OT ไม่เสนอให้ LLM แทน Safety PLC หรือ SIS AI อาจแนะนำให้หยุด แต่กลไก deterministic ที่ผ่านการรับรองยังต้องเป็นผู้รับผิดชอบการหยุดเพื่อความปลอดภัย

กำหนดระดับความสามารถสี่ระดับในสัญญา

NIST เสนอแนวคิดจำแนกเครื่องมือของ Agent ตามหน้าที่และรูปแบบการเข้าถึง ได้แก่ read-only, constrained write และ write รวมถึงสภาพแวดล้อมที่เชื่อถือหรือไม่เชื่อถือ และระบุแขนหุ่นยนต์กับเครื่องมือในโรงงานหรือห้องทดลองเป็นส่วนขยายทางกายภาพ ระดับ L0–L3 ด้านล่างเป็นการสังเคราะห์ของ TOMAS TECH สำหรับการจัดซื้อภาคการผลิต ไม่ใช่ชื่อระดับทางการของ NIST

อย่าอนุมัติ “AI Agent” ทั้งก้อน Agent ตัวเดียวอาจอ่านข้อมูล vibration ที่ L0 เปิดใบงานที่ L2 และไม่มีสิทธิ์เขียน PLC การยกระดับต้องระบุ use case, เครื่องจักร, action, เวลา และ version ของ model, prompt, policy และ tool เพื่อป้องกันการเพิ่ม connector แล้วทำให้ L2 กลายเป็น L3 โดยไม่รู้ตัว

Threat model: อย่ามองเฉพาะ hallucination

MITRE ATLAS “OpenClaw Investigation” ปี 2026 เป็น case study ของเครื่องมือ Agent หนึ่งตัว เอกสารกล่าวถึง prompt smuggling, indirect prompt injection, การถูกโจมตีผ่าน third-party skill หรือ supply chain, context/memory poisoning, การขโมย credential และ tool invocation ที่อันตราย ไม่ควรเหมารวมผลของผลิตภัณฑ์เดียวกับทุก Agent แต่สามารถแปลงเป็นคำถามควบคุมในการจัดซื้อได้

OWASP GenAI Security Project ระบุในประกาศวันที่ 1 กันยายน 2026 ว่า LLM Top 10 ฉบับปี 2026 นำหลักฐานจากเหตุการณ์จริงมารวมไว้ และเปิดตัว Agent Control Standard เป็นแนวทางบังคับใช้การควบคุมขณะทำงาน เอกสารสาธารณะเหล่านี้ช่วยจัดโครงสร้าง threat และ execution control แต่ไม่ใช่การรับรอง functional safety ของเครื่องจักร เนื้อหาด้านล่างจึงใช้ร่วมกับ machine state, interlock และ safe state เฉพาะโรงงาน

1. คำสั่งที่ไม่น่าเชื่อถือเข้าสู่เส้นทางสั่งงาน

PDF ซ่อมบำรุง อีเมล เว็บ supplier portal, QR และข้อความอิสระใน log อาจมีคำสั่งภาษาธรรมชาติ หากโมเดลแยก “ข้อมูลอ้างอิง” จาก “คำสั่ง” ไม่ได้ ข้อความที่ค้นพบอาจชักนำ tool call ป้ายเตือนไม่พอ session ที่อ่านข้อมูลไม่น่าเชื่อถือต้องไม่มีความสามารถเรียก write tool ในเชิงเทคนิค

2. สิทธิ์มากเกินไปและการใช้ credential ร่วมกัน

บัญชีบริการ ERP, MES หรือ OT ที่กว้างทำให้ไม่รู้ว่า Agent ใดเป็นผู้กระทำ ห้ามใส่ secret ใน prompt หรือ model context ให้ tool broker ออก token อายุสั้นที่จำกัดเป้าหมาย action ช่วงค่า และจำนวนครั้ง อย่าสืบทอดสิทธิ์ทั้งหมดของผู้ใช้ให้ Agent โดยอัตโนมัติ เพราะสิ่งที่คนทำได้อย่างถูกต้องไม่จำเป็นต้องเป็นสิ่งที่ Agent ต้องทำได้

3. Memory ถูกปนเปื้อนและสถานะล้าสมัย

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

4. Supply chain ของ model, skill และ connector

ความสามารถจริงขึ้นกับ model API, agent framework, plugin หรือ MCP server, library, container, connector และ prompt template ต้องควบคุมไม่เพียง SBOM แต่รวม version ที่อนุญาต signature/hash แหล่งที่มา ผู้อนุมัติ ผลทดสอบ และ version สำหรับ rollback

5. การกระทำทางกายภาพที่ไม่ปลอดภัยจากบริบทขาดหาย

คำสั่งที่ดูสมเหตุผลอาจอันตรายเมื่อ sensor หาย นาฬิกาคลาด เครื่องอยู่ maintenance mode มี lockout/tagout ตำแหน่งชิ้นงานผิด หรือมีคนอยู่ในพื้นที่ ห้ามใช้ “confidence” ของโมเดลเป็นการตัดสินความปลอดภัย กฎ deterministic ต้องปฏิเสธเมื่อสัญญาณบังคับหายหรือคุณภาพไม่ดี

6. ที่มาและความรับผิดชอบหายไป

ข้อความว่า “AI ตัดสินใจ” ไม่พอสำหรับสอบสวน ต้องเชื่อมคำขอต้นทาง ข้อมูลที่อ่านและเวลา model/prompt/tool version ข้อเสนอ policy decision ผู้อนุมัติ คำสั่งจริง และผลตอบกลับจากเครื่องด้วย correlation ID พร้อมจำกัดการคัดลอก secret และข้อมูลส่วนบุคคลเข้า log กำหนดสิทธิ์และ retention

Target architecture: วาง execution broker ระหว่าง AI กับ OT

หลีกเลี่ยงการให้ Agent เปิด session ตรงถึง PLC หรือหุ่นยนต์ ลำดับอ้างอิงคือ AI AGENT → API GATE → OT DMZ → PLC/ROBOT เส้นทาง APPROVAL แยกไว้พักคำสั่งความเสี่ยงสูง ส่วน SAFE STOP ต้องไม่ผ่านโมเดลและเชื่อม safety layer แบบ deterministic ของโรงงาน

Agent identity และ registry

ทะเบียนต้องมีเจ้าของ วัตถุประสงค์ ระดับ รุ่นโมเดล เครื่องมือ site, data classification ผู้รับผิดชอบ วันหมดอายุ และวันที่ทบทวนล่าสุด ขณะทำงานให้บันทึก Agent ผู้เรียกหรือ service, session และ tool version broker ต้องปฏิเสธตัวตนที่ไม่ลงทะเบียนหรือหมดอายุ

แยกเส้นทางอ่านกับเขียน

หากทำได้ ให้อ่าน Historian, MES และฐานข้อมูลคุณภาพผ่าน read-only replica หรือ outbound API และพิจารณา one-way transfer/data diode สำหรับ use case ที่เหมาะสม ใช้ network, credential และ endpoint คนละชุดสำหรับ write แม้ต้อง real time ก็เปิดเฉพาะ tag หรือฟังก์ชันที่กำหนดผ่าน broker ไม่ใช่สิทธิ์กว้าง

API gate และ tool broker

ไม่ให้ SQL ทั่วไป shell หรือการดาวน์โหลดโปรแกรม PLC แก่ Agent แต่เปิด business action แคบ เช่น “สร้างร่างใบงานซ่อม” หรือ “ขอค่าความเร็ว Line 3” broker ตรวจ schema, type, unit, range, machine mode, rate, concurrency, เวลา และ command ID ซ้ำ คำสั่งต้องมี idempotency เพื่อ retry แล้วไม่ทำงานทางกายภาพซ้ำ

Approval service และการแบ่งหน้าที่

การอนุมัติไม่ใช่คำว่า “OK” คลุมเครือในแชต ต้องตรึง asset ค่าปัจจุบัน ค่าเสนอ ส่วนต่าง เหตุผล ผลกระทบ และอายุใน approval object แยกผู้ขอจากผู้อนุมัติ และผู้แก้ model จากผู้ promote production หาก input หรือสภาพเครื่องเปลี่ยนอย่างมีนัยสำคัญ ให้ approval หมดอายุและประเมินใหม่

OT DMZ และ segmentation

แยก cloud/IT, OT DMZ, cell/area และ equipment network ระบุทิศทางกับปลายทางที่อนุญาต ห้าม traffic ใด ๆ จาก AI platform เข้า OT โดยเสรี DMZ ทำ protocol conversion, policy enforcement, queue, rate limit และ audit เมื่อสื่อสารขาด ให้ทำตามนโยบายของ use case คือหยุด คงสถานะ หรือให้ local control ทำต่อ ไม่ใช่ให้โมเดลเดา

Deterministic interlock

อุณหภูมิ แรงดัน ความเร็ว ประตู guard การตรวจคน machine mode และ lockout/tagout ต้องประเมินใน PLC, Safety PLC, SIS หรือ controller แม้คำสั่ง AI อยู่ในช่วงปกติ interlock หน้างานต้องยังปฏิเสธได้ Agent ไม่มีสิทธิ์ปิด safeguard

Safe state และ AI Agent kill switch

Kill switch ไม่ใช่แค่ปิดแอป ต้องหยุด tool call ใหม่ เพิกถอน token แยก queue ที่รอ กำหนดวิธี complete/cancel งานระหว่างทำ คืนอำนาจให้ local control แจ้งผู้รับผิดชอบ และควบคุมการอนุมัติก่อน restart

Safe state ต่างกันตามเครื่อง การหยุด conveyor ทันทีอาจทำของตก เตาอาจหยุดฉับพลันไม่ได้ batch อาจต้องจบอย่างควบคุม ทีมวิศวกรรม ปฏิบัติการ safety, quality และ maintenance ต้องตกลง transition ที่นำไปใช้โดยไม่พึ่ง AI

สร้าง permission matrix ตามหลัก AI Agent least privilege

ชื่อ role อย่างเดียวหยาบเกินไป ต้องกำหนด subject, tool, action, target, condition, approval, limit และ expiry

ทดสอบด้านลบด้วย line อื่น tag นอกช่วง เวลาผิด เกิน rate approval หมดอายุ unit ผิด sensor หาย ID ซ้ำ และลำดับย้อนกลับ หลักฐาน FAT/SAT ต้องแสดงว่าคำขอถูกปฏิเสธก่อนถึง OT

สิ่งที่ Industrial AI RFP ต้องกำหนด

1. รายการ tool และ action ทั้งหมด

ให้ผู้เสนอระบุ tool มาตรฐาน ตัวเลือก และ third party พร้อมประเภท read/write ข้อมูล เป้าหมาย protocol, credential, service ที่พึ่งพา และ network path หาก Agent ค้นหา สร้าง หรือติดตั้ง tool ขณะทำงานได้ ให้ตอบกลไกอนุมัติ signature และ sandbox

2. Trust boundary และ data flow

ให้วาดผู้ใช้ เอกสารภายนอก RAG, model, memory, broker, IT, OT DMZ และเครื่องจักร ระบุ input ใดไม่น่าเชื่อถือ และปิด write tool อย่างไรหลัง input นั้นเข้าสู่ session

3. Identity และ permission

แยกตัวตนคน Agent, service และ tool กำหนด credential อายุสั้น secret storage, rotation, emergency revoke, ขอบเขตแยก site และ segregation of duties การเปลี่ยน permission โดย admin ต้องถูก audit เช่นกัน

4. Supply chain ของ model และ skill

ขอ model/version, hosting, เงื่อนไข training/retention, framework, skill, connector, dependency, SBOM, signature, vulnerability response, support life, change notice และ rollback ยืนยันว่า auto update ไม่ข้าม production gate

5. Audit และ replay

การเก็บ prompt ทุกตัวอาจสร้างคลังข้อมูลอ่อนไหวใหม่ จึงต้องกำหนดหลักฐานที่จำเป็น redaction, access, retention, clock sync, correlation ID, tamper resistance, SIEM, search/export และวิธี reconstruct ไปพร้อมกัน

6. Emergency stop, recovery และ rollback

ขอขั้นตอนปิด Agent เพิกถอน token แยก queue ใช้ OT local/manual แจ้งเหตุ และเกณฑ์ restart ระบุหน่วย rollback กับเวลาสำหรับ model, prompt, policy, tool, configuration, memory และ connector

7. Incident response และ change control

แบ่งความรับผิดชอบด้าน detection, containment, evidence preservation, equipment safety, communication, root cause และ corrective action การเปลี่ยนความเสี่ยงสูงต้องทำ FAT/SAT ซ้ำ ส่วน emergency change ต้องมี post-approval ภายในกำหนด

8. หลักฐานส่งมอบ

ให้ architecture, permission matrix, threat model, test record, residual risk, ข้อจำกัดที่ทราบ ตัวอย่าง log, restore test, training record, runbook และ component inventory เป็น deliverable ตามสัญญา คำว่า “รองรับ” ไม่ใช่หลักฐาน ต้องมี configuration, policy, API schema และ negative-test log

ภาพรวมโครงการอ่านได้ในคู่มือติดตั้ง AI Agent ส่วนการออกแบบข้อมูลและ privacy ดูสภาพแวดล้อม Generative AI ที่ปลอดภัย บทความนี้เจาะ OT และผลทางกายภาพจากคู่มือทดสอบรับมอบ AI Agent

FAT/SAT: พิสูจน์การปฏิเสธและ safe state

FAT ตรวจ design, configuration และ boundary ในสภาพแวดล้อมผู้ขาย SAT ทำซ้ำใน network, machine mode, operator, clock, load และ procedure ของ site จริง การทดสอบนี้ไม่แทน functional-safety certification หรือการตรวจตามกฎหมาย แต่พิสูจน์ว่าเส้นทาง AI ไม่ข้าม safeguard เดิม

เก็บ prerequisite, data, version, ผู้รับผิดชอบ expected/actual, machine-readable log, deviation, correction และ retest อย่าตัดสินด้วย pass percentage อย่างเดียว การข้าม boundary ระดับวิกฤตเพียงหนึ่งครั้งอาจเป็น release stop

แผนดำเนินการ 90 วัน

เก้าสิบวันเป็นกรอบตัวอย่าง ไม่ใช่คำมั่น หากต้องดัดแปลงเครื่อง ประเมิน functional safety ปฏิบัติตามกฎหมาย หรือรอ shutdown ต้องเพิ่มเวลา

วันที่ 0–15: กำหนด use case และ hazard boundary

สำรวจ site, asset, user, data และ tool เดินตรวจ interlock, emergency stop, manual operation และ failure recovery เริ่ม L0/L1 เป็นค่าเริ่มต้น บันทึกเหตุผลเฉพาะงานที่ต้องใช้ L2 แต่งตั้งเจ้าของจาก operations, maintenance, safety, quality, OT, IT, cyber และ legal

วันที่ 16–30: ทำ identity, network และ permission

สร้าง Agent registry, ID เฉพาะ, token อายุสั้น, tool allowlist, read-only path, OT DMZ และ correlated log จำกัด write API เป็น business action แคบ ตรวจ schema, range, unit, target, rate และเวลา ทำ tabletop exercise สำหรับ kill switch และ safe state

วันที่ 31–60: ประเมิน L0/L1 ด้วยข้อมูลโรงงาน

ทดสอบที่มา ความใหม่ ข้อมูลหาย ค่าผิดปกติ และ machine mode ด้วยข้อมูลคล้าย production ประเมินทั้งคุณภาพคำแนะนำ ความสามารถของ operator ในการพบคำแนะนำผิด การทำงานเมื่อ load สูง หลายภาษา การลบ memory และ audit search รวม injection จากเอกสารไม่น่าเชื่อถือ

วันที่ 61–75: FAT/SAT สำหรับ L2 ที่จำกัด

เลือกหนึ่ง action ที่อนุมัติ หนึ่งกลุ่ม asset และหนึ่งช่วงเวลา ทดสอบคำสั่งซ้ำ ลำดับย้อน network loss, approval เก่า rate limit, asset ผิด sensor หาย และ kill switch อย่าเพิ่ม L3 โดยไม่มี safety case และอนุมัติผู้บริหารแยกต่างหาก

วันที่ 76–90: ยกระดับ ดำเนินต่อ หรือหยุดตามหลักฐาน

ทบทวน defect ค้าง residual risk ภาระปฏิบัติการ training ความครบ log และ recovery time ตัดสิน “คง L0/L1” “ยกระดับ L2 แบบจำกัด” “ดำเนินต่อแบบมีเงื่อนไข” “ทดสอบใหม่” หรือ “หยุด” ตั้ง review 30, 60, 90 วันหลัง go-live และ trigger retest เมื่อ model/tool เปลี่ยน

ตัวอย่าง risk score แบบโปร่งใส

ตัวอย่างนี้เป็นสมมติฐานเพื่ออธิบาย ไม่ใช่ threshold ทางการของ OWASP AIVSS AIVSS v0.8 เป็นวิธีให้คะแนนช่องโหว่ที่เน้น agentic AI และใช้เสริม framework อื่น โครงการจริงต้องตรวจวิธีล่าสุดและเกณฑ์ขององค์กร

สมมติ likelihood 1–5, impact 1–5 และ risk score = likelihood × impact ช่วงคะแนน 1–25

Impact ในแถวที่สองยังเป็น 5 เพราะสมมติอย่างอนุรักษนิยมว่าความรุนแรงเมื่อเกิดเหตุไม่ได้ลดลง แม้ likelihood ลด ต้องบันทึกผู้ยอมรับ residual risk อย่าประกาศความปลอดภัยจากผลรวมหรือค่าเฉลี่ย โดยข้อห้าม functional safety กฎหมาย และ absolute gate ของบริษัทมาก่อน

สิ่งที่ต้อง monitor หลัง go-live

ความแม่นยำโมเดลไม่พอตรวจ boundary drift ให้ติดตาม Agent ไม่ได้รับอนุญาต tool call ถูกปฏิเสธ permission change, approval latency/expiry, การใช้ข้อมูลเก่า การลดระดับเมื่อ signal หาย command ซ้ำ การซ้อม kill switch ช่องว่าง log การเปลี่ยน model/skill การแทรกแซงด้วยมือ และ rollback

อย่าใช้ denial จำนวนมากเป็นเหตุขยายสิทธิ์อัตโนมัติ เพราะอาจหมายถึง workflow ผิด training ไม่พอ การโจมตี หรือ configuration drift denial ลดลงก็ไม่ใช่การปรับปรุงหาก audit evidence หาย ทุกเดือนให้เทียบ registry กับ network route, tool และ credential จริง แล้วลบความสามารถที่ไม่ใช้

ความผิดพลาดที่พบบ่อย

• ให้ admin ใน PoC: ข้อยกเว้นชั่วคราวจะกลายเป็นฐาน production ต้องทดสอบ least privilege ตั้งแต่ PoC
• คิดว่าคนอนุมัติแล้วปลอดภัย: คนอาจพลาด unit ค่าล้าสมัย หรือ machine state ต้องมีทั้ง approval UI และ deterministic validation
• คิดว่า kill switch คือปิด process: token ที่ออกแล้ว queue งานระหว่างทำ และการคืนเครื่องยังคงอยู่
• เก็บทุกอย่างใน log: secret และข้อมูลส่วนบุคคลจะเป็นความเสี่ยงใหม่ เก็บหลักฐานขั้นต่ำที่ป้องกันและ reconstruct ได้
• ผ่านที่เดียวแล้ว rollout ทุกโรงงาน: asset, process, network และ procedure ต่างกัน ต้องอนุญาตราย use case/site
• ให้ AI แก้ Safety PLC: ทำลายความเป็นอิสระของ safety layer ต้องห้าม AI ปิด safeguard

Checklist การนำไปใช้

ก่อน RFP

• [ ] แยก IT assistance, OT-adjacent และ OT execution
• [ ] จัดทุก use case เป็น L0–L3
• [ ] คง Safety PLC, SIS, interlock และความรับผิดชอบคนอย่างอิสระ
• [ ] ทำรายการ tool, data, credential, network และ supplier
• [ ] นิยาม safe state กับขอบเขต kill switch ราย asset

ก่อน FAT/SAT

• [ ] ใช้ Agent ID เฉพาะและ capability authorization มีอายุ
• [ ] แยก read/write path และ credential
• [ ] write ผ่าน business API ที่ allowlist
• [ ] approval ตรึงขอบเขต ส่วนต่าง อายุ และหมดอายุเมื่อ state เปลี่ยน
• [ ] ทดสอบ injection, missing signal, stale context, network loss, duplicate และ stop
• [ ] reconstruct request ถึง equipment response จาก log ได้

ก่อน production

• [ ] ไม่มี critical boundary bypass ที่ยังไม่แก้
• [ ] สาธิต token revoke, queue isolation และ manual recovery
• [ ] สาธิต rollback model, policy, tool และ memory
• [ ] operations, OT, IT, cyber, safety และ quality อนุมัติหลักฐาน
• [ ] กำหนด trigger FAT/SAT ซ้ำและ review 30/60/90 วัน

FAQ: ความปลอดภัย AI Agent ในโรงงาน

เริ่มต้นเชื่อม AI Agent กับ PLC โดยตรงได้หรือไม่?

ไม่แนะนำ เริ่ม L0 read และ L1 advise เพื่อพิสูจน์คุณภาพข้อมูล ที่มา audit และ operation หากต้องเขียน ให้เริ่ม L2 ผ่าน business API จำกัด การอนุมัติ ช่วงค่า การตรวจ machine state, idempotency และ safety layer อิสระ ไม่ใช่ generic PLC access

RBAC ปกติเพียงพอสำหรับ AI Agent least privilege หรือไม่?

โดยทั่วไปไม่พอ ต้องเพิ่ม asset, action, range, unit, time, rate, data freshness, approver และ session expiry และพิสูจน์การปฏิเสธด้วย negative test

AI Agent kill switch เหมือน emergency stop หรือไม่?

ไม่เหมือน Kill switch ฝั่ง AI ปิด tool call, credential, queue และ session ส่วน emergency stop และ safe shutdown ของเครื่องเป็นหน้าที่ของวงจรนิรภัย PLC, SIS หรือกลไก deterministic ที่ผ่านการรับรอง ต้องกำหนดการเชื่อมโยงของสองชั้น

ถ้ามีคนอนุมัติ L3 จะปลอดภัยหรือไม่?

การอนุมัติอย่างเดียวไม่รับประกัน เพราะมี display omission, fatigue, stale data และ unit error ต้องมี safety layer อิสระ broker, state validation, limit, monitoring, stop และ recovery หลาย use case ควรตัดสินใจไม่ใช้ L3

ใช้คะแนน OWASP AIVSS ตัดสิน go/no-go ได้หรือไม่?

คะแนนช่วยเปรียบเทียบและสนทนา แต่ไม่แทน functional safety กฎหมาย เงื่อนไขผู้ผลิต หรือข้อห้ามบริษัท ต้องบันทึก version วิธี สมมติฐาน หลักฐาน และเจ้าของ residual risk

FAT/SAT นี้แทน functional-safety certification หรือไม่?

ไม่แทน เป็นการทดสอบ boundary, permission, denial, safe state และ evidence ของ AI Agent ส่วนการประเมินและรับรอง functional safety การตรวจตามกฎหมาย และขั้นตอนหน้างานยังต้องทำแยก

สรุป: พิสูจน์ว่าหยุดได้ก่อนเพิ่มความสามารถ

ยิ่ง AI Agent เข้าใกล้การกระทำทางกายภาพ มูลค่าและผลกระทบยิ่งสูง ต้องแยก L0 Observe, L1 Advise, L2 Constrained execute และ L3 Direct execute ราย use case ออกแบบ identity, tool allowlist, read/write separation, OT DMZ, approval, deterministic interlock, safe state, kill switch และ audit ก่อนให้สิทธิ์ RFP ต้องขอหลักฐานว่าการกระทำต้องห้ามถูกปฏิเสธ ความขัดข้องเข้าสู่พฤติกรรมปลอดภัย และ reconstruct ประวัติได้ ยกระดับเฉพาะ use case ที่ผ่าน negative FAT/SAT และมีผู้ยอมรับ residual risk อย่างชัดเจน

TOMAS TECH ช่วยตั้งแต่แนวคิด AI Agent ที่เชื่อม OT การจัดระดับความสามารถ threat model, Industrial AI RFP การออกแบบ network/permission และแผนหลักฐาน FAT/SAT สามารถติดต่อเราได้ตั้งแต่ก่อนเลือกผลิตภัณฑ์หรือขณะยังประเมิน L0/L1

แหล่งอ้างอิงหลัก

• Google Cloud, “A manufacturing blueprint for secure agentic AI” (14 Sep 2026): https://cloud.google.com/transform/a-manufacturing-blueprint-for-secure-agentic-ai
• Google Cloud, “Inside the agentic factory” (10 Sep 2026): https://cloud.google.com/transform/agentic-factory-manufacturing-new-age-of-autonomy-industrial-ai
• OWASP GenAI Security Project, “2026 Top 10 for LLM Applications” announcement (1 Sep 2026): https://genai.owasp.org/2026/09/01/owasp-genai-security-project-unveils-2026-top-10-for-llm-applications-new-agent-control-standard-and-sponsors-as-community-tops-30000-members/
• NIST, “Lessons Learned from the Consortium: Tool Use in Agent Systems” (Aug 2025): https://www.nist.gov/news-events/news/2025/08/lessons-learned-consortium-tool-use-agent-systems
• MITRE ATLAS, “OpenClaw Investigation” (9 Feb 2026): https://www.mitre.org/sites/default/files/2026-02/PR-26-00176-1-MITRE-ATLAS-OpenClaw-Investigation.pdf
• OWASP, AIVSS v0.8 project page: https://aivss.owasp.org/

บทความนี้เป็นแนวทางทั่วไปด้านการดำเนินการและจัดซื้อ อ้างอิงข้อมูลสาธารณะที่ตรวจถึงวันที่ 19 กันยายน 2026 ไม่แทนการรับรอง functional safety เฉพาะเครื่อง การปฏิบัติตามกฎหมาย หรือการรับประกัน cybersecurity