การนำ ISO 42001 มาใช้ใน 90 วันสำหรับโรงงานไทย

สำหรับผู้ผลิตในไทยและอาเซียนที่กำลังพิจารณาการนำ ISO 42001 มาใช้ คำถามแรกไม่ควรเป็นเพียง “จะขอการรับรองได้เร็วแค่ไหน” แต่ควรเป็นว่าองค์กรอธิบายได้หรือไม่ว่าใช้ AI ใด เพื่อวัตถุประสงค์อะไร ใครรับผิดชอบ และควบคุมความเสี่ยงอย่างไร บทความนี้เสนอแนวทาง 90 วันสำหรับผู้บริหาร ฝ่าย IT คุณภาพ ตรวจสอบ และหน้างาน เพื่อจัดทำทะเบียน AI แบ่งความรับผิดชอบ ประเมินผลกระทบ และรวบรวมหลักฐานจากผู้ให้บริการ ครอบคลุมทั้ง Generative AI ระบบตรวจสอบด้วยภาพ การพยากรณ์ และ Predictive Maintenance โดยไม่ตั้งสมมติฐานว่าทุกองค์กรต้องขอการรับรอง

ISO/IEC 42001 คืออะไร และ AIMS ควรทำหน้าที่อย่างไร

ISO/IEC 42001:2023 กำหนดข้อกำหนดของระบบการจัดการปัญญาประดิษฐ์ หรือ Artificial Intelligence Management System (AIMS) สำหรับองค์กรที่พัฒนา ให้บริการ หรือใช้ AI จึงไม่ได้จำกัดเฉพาะบริษัทผู้สร้างโมเดล โรงงานที่ซื้อบริการ AI บนคลาวด์แล้วนำมาใช้ในงานผลิตหรือสำนักงานก็อยู่ในกลุ่มที่นำมาตรฐานนี้ไปประยุกต์ได้ คำอธิบายอย่างเป็นทางการของ ISO กล่าวถึงภาวะผู้นำ นโยบายและวัตถุประสงค์ การบริหารความเสี่ยง AI ธรรมาภิบาลข้อมูลและวงจรชีวิต ความโปร่งใส การประเมินและติดตาม รวมถึงการปรับปรุงอย่างต่อเนื่อง

มาตรฐานนี้ไม่ใช่เกณฑ์วัดประสิทธิภาพของโมเดลตัวเดียว และไม่ใช่เช็กลิสต์สำเร็จรูป องค์กรต้องนำกรอบระบบการจัดการไปปรับตามบริบท ผู้มีส่วนได้เสีย กรณีใช้งาน และขนาดของผลกระทบ หากมี ISO 9001 หรือ ISO/IEC 27001 อยู่แล้ว สามารถเชื่อมกับการควบคุมเอกสาร การจัดการผู้ขาย การตรวจสอบภายใน Management Review และ Corrective Action ได้ แต่การมีระบบเดิมไม่ได้ทำให้ละเว้นความเสี่ยงเฉพาะของ AI เช่น คำตอบผิด Automation Bias หรือ Model Drift ได้

การรับรอง ISO/IEC 42001 เป็นเรื่องสมัครใจ ISO เป็นองค์กรผู้พัฒนามาตรฐาน ไม่ใช่หน่วยรับรอง หากเลือกขอการรับรอง การตรวจประเมินจะดำเนินการโดยหน่วยรับรองอิสระ จึงไม่ควรกล่าวว่า “AI ได้รับการรับรองจาก ISO” หรือ “กฎหมายบังคับให้ทุกบริษัทต้องมี ISO 42001” โดยไม่มีหลักฐานเฉพาะ ผู้บริหารควรพิจารณาความต้องการลูกค้า เงื่อนไขประมูล นโยบายกลุ่มบริษัท กฎระเบียบ และความเสี่ยงทางธุรกิจก่อนตัดสินใจว่า Third-party Certification จำเป็นหรือไม่

ในประเทศไทย สำนักงานมาตรฐานผลิตภัณฑ์อุตสาหกรรมระบุว่า มตช. 42001-2567 ได้ประกาศในราชกิจจานุเบกษาเมื่อวันที่ 17 กรกฎาคม 2024 การดำเนินงานในไทยจึงควรตรวจทั้งมาตรฐานแห่งชาติและข้อกำหนดด้านสัญญา ข้อมูลส่วนบุคคล แรงงาน ความปลอดภัย คุณภาพ และความลับทางธุรกิจ การมี AIMS ไม่ได้ยืนยันโดยอัตโนมัติว่าปฏิบัติตามกฎหมายที่เกี่ยวข้องครบทุกฉบับ

เหตุใดโรงงานไทยและอาเซียนจึงต้องมี AI Management System

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

ปัญหาที่พบได้ในองค์กรหลายประเทศ ได้แก่

• สำนักงานใหญ่ซื้อบริการ AI แต่โรงงานไทยไม่ทราบเงื่อนไขการใช้และการเก็บข้อมูลอย่างครบถ้วน
• PoC วัด Accuracy แล้ว แต่ไม่มีเกณฑ์รับมือประสิทธิภาพเสื่อมและเกณฑ์หยุดระบบหลังใช้งานจริง
• พนักงานนำแบบ Drawing ใบเสนอราคา หรือข้อมูลลูกค้าเข้า AI สาธารณะ
• ผู้ขายเปลี่ยนโมเดลโดยองค์กรไม่เก็บบันทึกการเปลี่ยนแปลงและการทดสอบซ้ำ
• ฝ่ายคุณภาพทราบว่ามี AI แต่ตรวจสอบ Input, Override และการตัดสินใจขั้นสุดท้ายของมนุษย์ไม่ได้
• ใช้ขั้นตอนเดียวในหลายประเทศ ทั้งที่ภาษา วิธีทำงาน และข้อกำหนดข้อมูลแตกต่างกัน

คุณค่าของการนำ ISO 42001 มาใช้คือการเปลี่ยนเรื่องเหล่านี้จาก “ปัญหาของทีม AI” เป็นการตัดสินใจทางธุรกิจที่บริหารได้ ตัววัดสำคัญไม่ใช่จำนวนเอกสาร แต่คือการอนุมัติ เปลี่ยนแปลง ติดตาม ระงับ และยกเลิก AI มีเหตุผลและหลักฐานที่ทำซ้ำได้หรือไม่

Roadmap 90 วันสำหรับการนำ ISO 42001 มาใช้

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

วันที่ 1–15: กำหนดขอบเขตและความรับผิดชอบของผู้บริหาร

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

แต่งตั้ง Executive Sponsor, AIMS Manager, Business Owner, System Owner, Data Owner, Risk Assessor และ Internal Auditor การควบหลายบทบาททำได้ แต่ไม่ควรออกแบบให้คนคนเดียวประเมินและอนุมัติตนเองทั้งหมด ตัวอย่างเช่น Production Engineering อาจเป็นเจ้าของระบบตรวจสอบภาพ ขณะที่ Quality อนุมัติเกณฑ์การปล่อยสินค้า และผู้เชี่ยวชาญ Security กับ Privacy ตรวจความเสี่ยงของตน

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

วันที่ 16–30: สร้างทะเบียน AI และค้นหา Shadow AI

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

ไม่ควรเริ่มจาก IT Asset Register อย่างเดียว ให้เทียบข้อมูลจัดซื้อ SaaS ค่าใช้จ่าย Browser Extension พีซีโรงงาน Edge Device กล้องตรวจสอบ และบัญชี AI ที่พนักงานเปิดเอง คำถามสำรวจควรถามถึงเครื่องมือที่จัดประเภท พยากรณ์ สร้างข้อความ ตรวจภาพ หรือแนะนำการตัดสินใจโดยอัตโนมัติ ไม่ใช่ถามเพียงว่า “ใช้ AI หรือไม่”

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

วันที่ 31–45: ทำ AI Impact Assessment และ AI Risk Management

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

ISO/IEC 42005:2025 ให้แนวทางสำหรับ AI System Impact Assessment โดยพิจารณาผลต่อบุคคล กลุ่ม และสังคม ไม่ใช่เฉพาะความเสียหายขององค์กร หากวิเคราะห์วิดีโอพนักงาน ควรพิจารณาความเหมาะสมของการเฝ้าติดตาม การแจ้งให้ทราบ สิทธิ์เข้าถึง อายุข้อมูล และผลเสียจากการอนุมานผิด หากเป็นการตรวจสอบภาพ ต้องประเมินความเสียหายลูกค้าจาก Defect ที่หลุด การทิ้งงานจาก False Reject ความเปลี่ยนแปลงจากแสงหรือวัสดุ และความเสี่ยงที่คนเชื่อ AI โดยไม่ตรวจ

Workshop ระบบละ 60–90 นาทีสามารถดำเนินตามลำดับนี้:

1. นิยามการตัดสินใจที่ AI สนับสนุนหรือทำอัตโนมัติในหนึ่งประโยค
2. ระบุคน ผลิตภัณฑ์ กระบวนการ สิทธิ และสัญญาที่ได้รับผลกระทบ
3. สร้าง Scenario ปกติ ผิดพลาด ถูกใช้ในทางที่ผิด และระบบไม่พร้อมใช้
4. แยกสาเหตุจากข้อมูล โมเดล UI คน เครื่องจักร และผู้ขาย
5. เชื่อมมาตรการป้องกัน ตรวจจับ ตอบสนอง และกู้คืน
6. บันทึก Residual Risk ผู้อนุมัติ กำหนดเวลา และตัวชี้วัด

แม้ใช้ Matrix “ผลกระทบ × โอกาสเกิด” ก็ไม่ควรให้คะแนนอนุมัติแทนคน เหตุการณ์โอกาสต่ำแต่เกี่ยวกับการเสียชีวิต บาดเจ็บรุนแรง หรือผลทางกฎหมายสำคัญต้องเสนอผู้บริหารแยกต่างหาก Scenario สั้น ๆ ที่อธิบายในภาษาไทย อังกฤษ หรือภาษาที่พนักงานใช้จริง มักช่วยการปฏิบัติมากกว่าคะแนนซับซ้อน

วันที่ 46–60: รวบรวมหลักฐานผู้ขายและจัดการข้อมูล

การซื้อ AI ภายนอกไม่ได้โอนความรับผิดชอบทั้งหมดไปยัง Vendor ควรจัดหลักฐานแยกตามช่วงก่อนซื้อ ติดตั้ง เปลี่ยนแปลง และเกิดเหตุ ตรวจ Service Specification ข้อจำกัดการใช้ การใช้และลบข้อมูล ที่ตั้ง Hosting Access Control, Subprocessor, Model-change Notification, ข้อมูลประสิทธิภาพ, Incident Notice, Log และการจัดการข้อมูลเมื่อเลิกบริการ

ข้อความว่า “ใช้ AI อย่างมีจริยธรรม” ไม่ใช่หลักฐานที่เพียงพอ ต้องตรวจว่ากรณีใช้ของเราอนุญาต Input ใด ใครตรวจ Output และเก็บ Log อะไร หากบริการ Black Box ไม่เปิดเผยโครงสร้างภายใน ยังลดความเสี่ยงได้ด้วย Acceptance Test, Output Constraint, Human Review, Periodic Evaluation, Fallback และ Stop Criteria ให้บันทึกหลักฐานที่ขอไม่ได้เป็น Supplier Risk อย่างตรงไปตรงมา

แยก Training Data, Evaluation Data, Production Input, Generated Output และ Monitoring Log พร้อมบันทึกแหล่งที่มา สิทธิ์ คุณภาพ ความเป็นตัวแทน การเปลี่ยนแปลง การเก็บ การลบ และ Access ในโรงงานที่ใช้ไทย อังกฤษ ญี่ปุ่น และเวียดนาม โมเดลที่ทดสอบภาษาเดียวอาจให้ผลไม่เท่ากัน จึงควรเก็บผลประเมินตามภาษา โรงงาน ผลิตภัณฑ์ และสภาวะเครื่อง

แนวทางควบคุม Generative AI เพิ่มเติมดูได้จาก การสร้างสภาพแวดล้อม Generative AI ที่ปลอดภัย และหาก AI Agent สามารถลงมือทำงาน ควรเชื่อมสิทธิ์ การอนุมัติ Log และ Exception กับกระบวนการตาม ธรรมาภิบาล Workflow ของ AI Agent

วันที่ 61–75: เดินระบบติดตาม การเปลี่ยน และ Incident

AIMS จะไม่ทำงานหากจบที่เอกสาร ให้เชื่อม Request, Risk Assessment, Approval, Release, Monitoring, Incident, Suspension และ Retirement เป็นวงจรเดียว กำหนดทั้งเงื่อนไขจาก PoC ไป Production และ Trigger ที่ต้องถอยจาก Production กลับสู่การระงับ

ตัวชี้วัดควรครอบคลุมทั้ง Technical Performance, Business Result และ Control Effectiveness สำหรับ Vision Inspection ควรแยก Miss Rate ตาม Defect, False Reject, Manual Override, สภาพแสง ล็อตวัสดุ และ Model Version สำหรับ Generative AI อาจติดตามเหตุการณ์ข้อมูลต้องห้าม อัตราการแก้ Output อัตราตรวจแหล่งอ้างอิง รายงาน Hallucination การทำงานเกินสิทธิ์ และ Training Completion

ขั้นตอน Incident ต้องบอกว่าใครหยุด AI ได้ ใช้งาน Manual Process ใดแทน เก็บ Log ใด รายงานใคร และขออะไรจากผู้ขาย ผู้บริหารควรอนุมัติ Fallback กับผลต่อแผนผลิตไว้ล่วงหน้า เพื่อไม่ให้หน้างานซ่อนความผิดปกติเพราะกลัวหยุดไลน์

Change Control ไม่ได้ครอบคลุมเฉพาะ Model Version การเปลี่ยน Prompt, Threshold, Camera, Lighting, Material, UI, กลุ่มเป้าหมาย วัตถุประสงค์ Data Connection หรือ Terms ของผู้ขายก็ต้องพิจารณาประเมินซ้ำ แบ่งเป็นสามระดับ—Document Review, Focused Retest และ Full Impact Assessment—ตามนัยสำคัญของการเปลี่ยน

วันที่ 76–90: Internal Audit และ Management Review

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

Management Review ควรครอบคลุมจำนวน AI ระบบผลกระทบสูง เหตุการณ์ ตัวชี้วัด ข้อร้องเรียน ปัญหาผู้ขาย Corrective Action ทรัพยากร และการเปลี่ยนกฎหมายหรือลูกค้า จากนั้นผู้บริหารตัดสินใจว่าจะดำเนินต่อ จำกัด ลงทุนเพิ่ม ระงับ ขยายขอบเขต หรือเตรียมขอการรับรอง พร้อมบันทึก Owner และ Deadline

ผลงานวันที่ 90 คือหลักฐานว่ามีการวางแผน ปฏิบัติ ประเมิน และปรับปรุงแล้วอย่างน้อยหนึ่งรอบ ไม่ใช่คำประกาศว่า “พร้อมรับรอง” หากเลือกการรับรอง ให้สอบถามหน่วยรับรองโดยตรงเรื่อง Scope ระยะเวลาการเดินระบบ ตาราง และ Competence ทั้งนี้ ISO/IEC 42006:2025 ระบุข้อกำหนดสำหรับหน่วยงานที่ตรวจและรับรอง AIMS ซึ่งใช้ประกอบการพิจารณาได้ ส่วน ISO/IEC 42003 ไม่ควรถูกอ้างว่าเป็นคู่มือใช้งานที่ตีพิมพ์แล้ว เพราะรายการ ISO ปัจจุบันยังแสดงงานที่เกี่ยวข้องว่าอยู่ระหว่างพัฒนา

แบ่งความรับผิดชอบแบบ RACI ให้ใช้งานจริง

ฝ่าย IT ไม่สามารถตัดสินผลกระทบธุรกิจเพียงฝ่ายเดียว และฝ่ายผลิตอาจมองไม่ครบเรื่อง Security, Data และ Supplier ควรใส่ชื่อคนจริงในแต่ละระบบ:

• Executive Sponsor: นโยบาย ขอบเขต ทรัพยากร และการยอมรับความเสี่ยงร้ายแรง
• AIMS Manager: ทะเบียน การประชุม การตรวจ และการปรับปรุง
• Business Owner: วัตถุประสงค์ ขั้นตอน การตัดสินใจของคน และผลลัพธ์
• System Owner: Architecture, Access, Log, Change, Stop และ Recovery
• Data Owner: ความเหมาะสม คุณภาพ การเก็บ และสิทธิ์เข้าถึงข้อมูล
• Quality/Safety: ผลต่อสินค้า คน เครื่อง และ Acceptance Criteria
• Legal/Compliance: สัญญา Privacy แรงงาน คำกล่าวอ้าง และกฎระเบียบ
• Procurement: Due Diligence หลักฐาน การแจ้งเปลี่ยน และ Subprocessor
• User: ปฏิบัติตามเงื่อนไขและรายงานความผิดปกติ
• Internal Audit: ประเมิน Conformity และ Effectiveness อย่างเป็นอิสระ

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

ทำเอกสาร AI Governance ให้น้อยแต่ใช้จริง

ความล้มเหลวที่พบบ่อยคือสร้าง Policy Template จำนวนมากโดยไม่เชื่อมงาน เริ่มจากชุดขั้นต่ำที่บูรณาการได้:

1. ขอบเขต นโยบาย และวัตถุประสงค์ AIMS
2. ทะเบียน AI และ AI System Card
3. Impact/Risk Assessment
4. Workflow ขอใช้ อนุมัติ เปลี่ยน ระงับ และเลิกใช้
5. หลักฐาน Data และ Supplier
6. Monitoring, Incident และ Complaint Record
7. Training และ Competence Record
8. Internal Audit, Corrective Action และ Management Review

ใช้ ISO 9001, ISO/IEC 27001, Privacy, Product Safety และ Procurement ที่มีอยู่เมื่อเหมาะสม เพิ่มคำถาม AI ใน Supplier Assessment และเพิ่มการเปลี่ยน Model, Data, Prompt ใน Change Control Workflow คำขอเดียวที่ส่งต่อไปยังผู้ตรวจที่เกี่ยวข้องมีประโยชน์กว่าการเพิ่มเลขที่เอกสาร

ความสัมพันธ์กับ NIST AI RMF, ISO/IEC 42005 และ EU AI Act

NIST AI RMF 1.0

NIST AI RMF 1.0 เป็นกรอบสมัครใจที่จัดฟังก์ชันเป็น Govern, Map, Measure และ Manage ปัจจุบัน NIST กำลังปรับปรุง AI RMF 1.0 และเมื่อ 7 เมษายน 2026 ได้เผยแพร่ Concept Note สำหรับ Critical Infrastructure Profile จึงควรติดตามการแก้ไข แทนการคัดลอกข้อความปัจจุบันไปตรึงใน Procedure สามารถใช้ ISO/IEC 42001 เป็นโครงระบบบริหาร และใช้ทรัพยากร NIST ขยาย Risk Scenario กับ Measurement ได้ ทั้งสองกรอบเสริมกันแต่ไม่ใช่สิ่งเดียวกัน

ISO/IEC 42005 สำหรับ AI Impact Assessment

ISO/IEC 42005:2025 ให้แนวทางการประเมินผลกระทบของระบบ AI ให้ทำเป็นกิจกรรมตลอด Lifecycle ไม่ใช่แบบฟอร์มก่อนเปิดระบบครั้งเดียว เมื่อวัตถุประสงค์ ผู้ได้รับผล ข้อมูล สภาพแวดล้อม หรือผู้ขายเปลี่ยน ควรทบทวนและเชื่อมผลไปยังทะเบียน Risk Treatment, Acceptance Test, User Information และ Monitoring

EU AI Act Article 17

Article 17 กำหนดให้ Provider ของ High-risk AI มีระบบบริหารคุณภาพที่จัดทำเป็นเอกสาร ครอบคลุมกลยุทธ์การปฏิบัติตาม การออกแบบ พัฒนา ทดสอบ Data Management บันทึก ความรับผิดชอบ Post-market Monitoring และ Corrective Action แต่การรับรอง ISO/IEC 42001 ไม่เท่ากับการปฏิบัติตาม EU AI Act โดยอัตโนมัติ ต้องประเมินบทบาทขององค์กร การจัดประเภทระบบ และความสัมพันธ์กับตลาด EU แยกต่างหาก โรงงานไทยอาจเกี่ยวข้องผ่านห่วงโซ่อุปทาน EU ได้ แต่ไม่ควรสรุปเรื่อง Extraterritorial Application โดยไม่ตรวจผลิตภัณฑ์ สัญญา และข้อเท็จจริงทางกฎหมาย

เลือกหน่วยรับรองหรือบริษัทที่ปรึกษาอย่างไร

หากตัดสินใจขอการรับรอง ให้ตรวจ Competence ด้าน AIMS ประสบการณ์อุตสาหกรรมและภูมิภาค ภาษา Scope ตาราง และ Accreditation Status ของหน่วยรับรอง สำหรับบริษัทที่ปรึกษา ไม่ควรซื้อคำสัญญาว่า “ผ่านแน่นอน” แต่ควรดูว่าทีมเข้าใจ AI ในโรงงานและฝังมาตรการลงในระบบเดิมได้หรือไม่

คำถามที่ใช้เปรียบเทียบ ได้แก่ วิธีสำรวจหน้างานไทยหลายภาษา วิธีแยก AI พัฒนาเองกับ SaaS วิธีเชื่อม Impact Assessment กับ Quality/Safety/Security วิธีใช้เอกสาร ISO เดิม วิธีรับมือเมื่อ Vendor ให้ข้อมูลไม่พอ วิธีพัฒนา Auditor และสิ่งที่จะยังใช้ได้หากชะลอการรับรอง อ่านเกณฑ์จัดซื้อเพิ่มเติมได้ที่ วิธีเลือกบริษัทที่ปรึกษา AI ในประเทศไทย และตรวจ NDA, Data Transfer, Subcontractor รวมถึงการใช้ Generative AI ของที่ปรึกษาก่อนส่งหลักฐาน

ประเมินค่าใช้จ่ายและกำลังคนอย่างมีสมมติฐาน

ค่าใช้จ่ายขึ้นกับจำนวนและความหลากหลายของ AI ความพร้อมของระบบเดิม หลักฐานผู้ขาย ภาษา จำนวนสถานที่ และการรวม Certification มากกว่าจำนวนพนักงานเพียงอย่างเดียว ให้แยกใบเสนอราคาตามงาน ได้แก่ Scoping, Inventory, Impact Workshop, Procedure/Workflow, Technical Control/Logging, Training, Internal Audit, Certification Audit, Translation, Travel และ Annual Operation

ตัวเลขประมาณต้องระบุว่าเป็นสมมติฐาน ตัวอย่าง: สมมติขอบเขตมี AI 12 ระบบ ใช้เฉลี่ย 6 คน-ชั่วโมงต่อระบบสำหรับตรวจทะเบียนและ Impact Assessment และใช้ 160 คน-ชั่วโมงสำหรับขั้นตอนร่วม การอบรม และ Internal Audit กำลังคนภายในเบื้องต้นเท่ากับ 12 ระบบ × 6 คน-ชั่วโมง + 160 คน-ชั่วโมง = 232 คน-ชั่วโมง ตัวเลขนี้เป็นสมมติฐานวางแผน ไม่ใช่ราคาตลาดหรือค่ามาตรฐาน งาน Validation ระบบผลกระทบสูง Data Cleanup, Technical Remediation, Translation และ Certification ต้องประเมินเพิ่ม

ข้อผิดพลาดที่พบบ่อย

ย้อนแผนจากวัน Audit ก่อนทำทะเบียน

Template ไม่ช่วยกำหนด Risk, Owner และ Monitoring หากยังไม่รู้ว่ามี AI ใดจริง ต้องทำทะเบียนภายใน 30 วันแรกและเลือกตัวอย่างแทนระบบทุกแบบ

ใช้การควบคุมระดับเดียวกับ AI ทุกชนิด

สรุปประชุมกับการปล่อยสินค้าให้ผลกระทบต่างกัน ควรปรับ Review, Approval และ Monitoring ตามผลกระทบ ข้อมูล และสิทธิ์การทำงาน พร้อมเก็บเหตุผลของ Low-risk Classification

ใช้คำกล่าวของ Vendor แทนการประเมินตนเอง

รายงาน Third Party มีประโยชน์แต่ไม่สะท้อนข้อมูล คน และกระบวนการของโรงงาน ผู้ใช้ระบบต้องกำหนด Acceptance Test และเงื่อนไขปฏิบัติเอง

อธิบายความปลอดภัยด้วย Average Accuracy เท่านั้น

ค่าเฉลี่ยสูงอาจซ่อน Critical Defect ที่ตรวจไม่พบหรือผลต่ำในบางสภาพ ต้องใช้ตัวชี้วัดแยกเงื่อนไข ผลของข้อผิดพลาด Human Check และ Stop Criteria ร่วมกัน

จัดอบรมครั้งเดียวแล้วถือว่ามี Competence

ผู้ใช้ทั่วไป Business Owner, Developer, Procurement และ Auditor ต้องการความรู้ต่างกัน ควรเก็บผลทดสอบความเข้าใจ แบบฝึก และ Refresh Training

FAQ เกี่ยวกับการนำ ISO 42001 มาใช้

ISO/IEC 42001 คืออะไร?

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

บริษัทไทยจำเป็นต้องขอ ISO 42001 หรือไม่?

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

ISO เป็นผู้รับรองบริษัทหรือไม่?

ไม่ใช่ ISO พัฒนามาตรฐาน ส่วนหน่วยรับรองอิสระทำการตรวจเมื่อองค์กรเลือกขอการรับรอง

AI Impact Assessment ต่างจาก Risk Assessment อย่างไร?

Impact Assessment มองผลต่อบุคคล กลุ่ม องค์กร และสังคม ส่วน Risk Assessment วิเคราะห์ Scenario ที่ไม่แน่นอน โอกาส มาตรการ และ Residual Risk ในการปฏิบัติ ควรเชื่อมผลกระทบไปสู่ Risk Treatment และ Monitoring

ใช้ ISO 9001 หรือ ISO/IEC 27001 เดิมได้หรือไม่?

ได้ในส่วน Document Control, Supplier, Audit และ Corrective Action แต่ยังต้องเพิ่ม AI Inventory, Impact, Human Oversight และการเปลี่ยน Model/Data อย่างชัดเจน

จำกัด Scope แรกเฉพาะ Generative AI ได้หรือไม่?

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

ขอการรับรองได้ภายใน 90 วันหรือไม่?

Roadmap นี้มุ่งสร้างระบบปฏิบัติ ไม่ใช่รับประกัน Certification ตารางจริงขึ้นกับความพร้อม Finding และหน่วยรับรอง

ISO/IEC 42001 เท่ากับปฏิบัติตาม EU AI Act หรือไม่?

ไม่เท่ากัน AIMS อาจช่วยจัดหลักฐานและ Quality Management แต่ยังต้องประเมินระบบและบทบาททางกฎหมายตาม EU AI Act แยกต่างหาก

สรุป: สิ่งที่ควรเหลือหลัง 90 วัน

ผลลัพธ์ที่มีค่าที่สุดไม่ใช่ใบรับรองหรือกอง Policy แต่คือทะเบียน AI ที่ผู้บริหารเห็นได้ ความรับผิดชอบที่มีชื่อบุคคล Impact Assessment ตามกรณีใช้ หลักฐานผู้ขาย และบันทึกจริงของการเปลี่ยน ติดตาม และระงับ หากนำขอบเขตเล็กหนึ่งขอบเขตผ่าน Internal Audit และ Management Review องค์กรจะมี AI Governance ที่ใช้งานได้ ไม่ว่าจะขอการรับรองภายหลังหรือไม่

TOMAS TECH ช่วยเชื่อมการนำ ISO 42001 มาใช้กับระบบคุณภาพและ Information Security เดิม รวมถึง AI, MES และ IoT จริงในโรงงานไทย สามารถ ติดต่อเรา เพื่อเริ่มจาก Scope Review, AI Inventory Workshop หรือ Pilot หนึ่งระบบได้ แม้ยังไม่ได้ตัดสินใจเรื่องการรับรอง

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

• ISO, “ISO 42001 explained: What it is and why it matters”: https://www.iso.org/home/insights-news/resources/iso-42001-explained-what-it-is.html
• ISO, ISO/IEC 42001:2023: https://www.iso.org/standard/42001
• สมอ., มตช. 42001-2567 (ประกาศ 17 กรกฎาคม 2024): https://service.tisi.go.th/license/web/index.php?ifdr=159&r=site/viewnac
• ISO, ISO/IEC 42005:2025: https://www.iso.org/standard/42005
• NIST, AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• EUR-Lex, Regulation (EU) 2024/1689, Article 17: https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng
• ISO/IEC JTC 1/SC 42 catalogue: https://www.iso.org/committee/6794475/x/catalogue/