ISO 42001 กับ NIST AI RMF องค์กรไทยควรเริ่มอันไหนก่อน

สมมติว่าบริษัทซอฟต์แวร์ไทยแห่งหนึ่งได้รับแบบสอบถามคู่ค้าจากลูกค้าในยุโรป มีช่องให้กรอกว่า "องค์กรของท่านใช้กรอบธรรมาภิบาล AI ใด" แล้วยกตัวอย่างไว้สองชื่อ คือ ISO/IEC 42001 กับ NIST AI RMF

คนที่ต้องตอบมักเป็น DPO หรือหัวหน้าไอทีที่ดูแล PDPA อยู่แล้ว และไม่แน่ใจว่าต้องทำทั้งสองอย่างไหม ต้องจ้างที่ปรึกษาไหม หรือแค่เขียนว่า "สอดคล้อง" ก็พอ บทความนี้เทียบให้เห็นทีละประเด็น จากดัชนีตัวมาตรฐานในคลังของเรา และบันทึกของทีม AIPDPA ที่อ่านคู่มือต่างประเทศมาแล้ว

ISO 42001 กับ NIST AI RMF ต่างกันตรงไหน

ต่างกันที่ สถานะ เป็นหลัก ISO/IEC 42001 เป็นมาตรฐานระบบบริหารจัดการที่ผู้ตรวจอิสระออกใบรับรองให้ได้ ส่วน NIST AI RMF เป็นกรอบที่ NIST ของสหรัฐฯ ออกให้ใช้โดยสมัครใจ ไม่มีใบรับรอง และองค์กรเลือกทำเฉพาะบางข้อได้

รูปแบบเอกสารก็ต่างกัน ISO 42001 ใช้โครงเดียวกับ ISO 9001 และ ISO/IEC 27001 คือ Clause 4–10 ตามวงจร Plan-Do-Check-Act แล้วเพิ่ม Annex A ที่มีมาตรการควบคุม 38 ข้อ ส่วน NIST เขียนเป็น "ผลลัพธ์ที่ต้องได้" 72 ข้อ แบ่งเป็นสี่ฟังก์ชัน GOVERN, MAP, MEASURE และ MANAGE โดยไม่บอกว่าต้องทำเอกสารหน้าตาแบบไหน

ตารางนี้ดัดแปลงจากคู่มือประยุกต์ของทีม AIPDPA (ดูคู่มือเริ่มต้น ISO 42001) ซึ่งเป็นบันทึกของทีม ไม่ใช่ข้อความของ ISO หรือ NIST จุดที่ควรจำคือคอลัมน์ขวาสุด เพราะเป็นคอลัมน์เดียวที่ไม่ทำแล้วมีผลทางกฎหมาย

ISO 42001 บังคับให้มีอะไรที่ NIST ไม่บังคับ

ISO 42001 ต้องการเอกสารที่ผู้ตรวจหยิบดูได้ สามชิ้นที่บันทึกของทีมชี้ว่าเป็นแกนของการตรวจรับรอง คือนโยบาย AI ที่ผู้บริหารสูงสุดอนุมัติ (ข้อ 5.2) เอกสาร Statement of Applicability หรือ SoA ที่บอกว่าเลือกมาตรการ Annex A ข้อไหนและไม่เลือกข้อไหนเพราะอะไร และการประเมินผลกระทบของระบบ AI ต่อบุคคลและสังคม

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

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

ผลในทางปฏิบัติคือ องค์กรที่ทำตาม ISO จะได้กองเอกสารที่ตรวจได้ ส่วนองค์กรที่ทำตาม NIST จะได้ความเข้าใจว่าต้องควบคุมอะไร แต่ต้องคิดรูปแบบหลักฐานเอง บันทึกของทีมเตือนไว้ว่า การประกาศว่า "ทำตาม AI RMF" โดยไม่บอกว่าทำข้อไหน ไม่มีความหมายและอาจเป็นการกล่าวอ้างเกินจริง

บริษัทที่ซื้อ AI มาใช้ ต้องทำครบทุกข้อไหม

ไม่ต้อง และนี่คือจุดที่หลายบริษัทเสียแรงเปล่ามากที่สุด ทั้งสองกรอบเขียนให้ครอบคลุมทั้งคนที่ สร้าง โมเดลและคนที่ นำมาใช้ แต่องค์กรไทยส่วนใหญ่อยู่ฝั่งหลัง คือซื้อ ChatGPT, Copilot หรือระบบคัดใบสมัครจากผู้ให้บริการ

ฝั่ง ISO: เขียนเหตุผลลงใน SoA

บันทึกของทีมระบุว่าราวครึ่งหนึ่งของหมวด A.6 (วงจรชีวิตระบบ) และเกือบทั้งหมวด A.7 (ข้อมูลสำหรับระบบ AI) เป็นงานของผู้พัฒนาโมเดล องค์กรที่เป็นผู้ใช้ทำเองไม่ได้ ที่ที่ถูกต้องคือเขียนลงใน SoA ว่าข้อนั้น "ไม่ใช้ เพราะเราเป็นผู้ใช้ ไม่ได้พัฒนาโมเดล" คู่มือต่างประเทศที่ทีมอ่านเห็นตรงกันว่าผู้ตรวจรับเหตุผลแบบนี้ได้ถ้าเขียนชัด

• ต้องทำเองแน่ ๆ: A.2 นโยบาย AI · A.3 บทบาทและช่องทางแจ้งข้อห่วงใย · A.4 ทะเบียนทรัพยากรและระบบ · A.5 ประเมินผลกระทบ · A.8 แจ้งผู้ใช้และสื่อสารเหตุการณ์ · A.9 การใช้งานอย่างรับผิดชอบและการกำกับโดยมนุษย์ · A.10 ผู้ให้บริการภายนอก
• ส่วนใหญ่เขียนว่าไม่ใช้ได้: A.6.1–A.6.2 ส่วนที่เป็นการออกแบบและพัฒนาโมเดล · A.7 การได้มาและเตรียมข้อมูลฝึก
• ข้อควรระวัง: ถ้าองค์กรปรับแต่งโมเดลด้วยข้อมูลของตัวเอง (fine-tune) หรือทำระบบ RAG เอง หมวด A.7 บางข้อจะกลับมาเกี่ยวทันที

ฝั่ง NIST: เลือกทำ 12 ข้อก่อน

NIST เขียนไว้เองว่าองค์กรเลือกทำเฉพาะบางหมวดได้ตามทรัพยากร ทีม AIPDPA จึงคัด 12 ข้อที่คุ้มแรงที่สุดสำหรับองค์กรที่ใช้ AI ของคนอื่นและมีงาน PDPA อยู่แล้ว ลำดับข้างล่างเป็นความเห็นของทีม ไม่ใช่ลำดับที่ NIST กำหนด

1. GOVERN 2.1 ระบุชื่อผู้รับผิดชอบเรื่อง AI ให้ DPO ถือไปก่อนก็ได้
2. GOVERN 1.6 ทำทะเบียนระบบ AI ระบบละหนึ่งบรรทัด
3. GOVERN 1.3 แบ่งระดับความเสี่ยงสามชั้นพร้อมเกณฑ์
4. GOVERN 1.2 นโยบายการใช้ AI หนึ่งหน้า (แนวทางเขียนนโยบาย GenAI)
5. GOVERN 6.1 เกณฑ์จัดซื้อและข้อสัญญากับผู้ให้บริการ
6. GOVERN 3.2 เขียนว่าใครมีอำนาจแก้หรือยกเลิกผลของ AI
7. GOVERN 4.3 นิยามเหตุการณ์ AI แล้วต่อเข้าแผนแจ้งเหตุละเมิดเดิม
8. MAP 3.2 ถามว่าใครเสียหายได้ เสียหายอะไร เมื่อไร อย่างไร
9. MEASURE 2.8 เก็บ log การใช้งานและการแก้ผลโดยคน
10. MEASURE 3.3 เปิดช่องให้โต้แย้งผลและนับสถิติ
11. MANAGE 2.4 เขียนเกณฑ์ปิดระบบไว้ล่วงหน้า
12. MANAGE 4.3 ทะเบียนเหตุการณ์และทะเบียนการเปลี่ยนแปลง

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

ผู้ให้บริการ AI ภายนอก สองกรอบพูดเรื่องเดียวกันไหม

พูดเรื่องเดียวกัน และเป็นเรื่องที่ทั้งสองกรอบกับกฎหมายไทยมาบรรจบกันชัดที่สุด NIST ให้ทั้งหมวด GOVERN 6 กับเรื่องความเสี่ยงจากบุคคลที่สาม รวมถึงความเสี่ยงละเมิดทรัพย์สินทางปัญญาของคนอื่น

ฝั่ง ISO แยกเรื่องนี้ไว้เป็นหมวด A.10 ทั้งหมวด ว่าด้วยการแบ่งความรับผิดชอบ ผู้ให้บริการ และลูกค้า

สำหรับองค์กรไทย ทั้ง A.10 และ GOVERN 6 ลงเอยที่เอกสารชิ้นเดียว คือข้อตกลงกับผู้ให้บริการ ถ้าผู้ให้บริการ AI ประมวลผลข้อมูลส่วนบุคคลแทนเรา พ.ร.บ.คุ้มครองข้อมูลฯ มาตรา 40 วรรคสาม บังคับให้ผู้ควบคุมข้อมูลจัดทำข้อตกลงไว้แล้ว ตรงนี้กรอบสากลกับกฎหมายไทยเรียกร้องสิ่งเดียวกัน

ข้อตกลงฉบับนี้จึงทำงานสามหน้าที่พร้อมกัน คือทำตามมาตรา 40 เป็นหลักฐานของ A.10 และตอบ GOVERN 6.1 ข้อที่ควรเขียนเพิ่มสำหรับ AI โดยเฉพาะมีอยู่ในบทความ ถามผู้ให้บริการ AI อย่างไร

เมื่อไรถึงคุ้มที่จะขอใบรับรอง ISO 42001

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

เรื่องเวลาและเงิน บันทึกของทีมยกตัวเลขของบริษัทที่ปรึกษาสหรัฐฯ รายหนึ่ง (rhymetec 2024) ว่าทำเองใช้ราว 6–11 เดือนขึ้นไป ทีมเตือนเองว่าเป็นตัวเลขตลาดสหรัฐฯ จากผู้ขายบริการ ใช้ดูลำดับขนาดได้ แต่ใช้วางแผนไม่ได้ ราคาในไทยต้องขอใบเสนอราคาจากหน่วยรับรองในประเทศ

ทำไมต้องเติม NIST แม้จะเลือก ISO แล้ว

เพราะ ISO ตอบว่า ใคร รับผิดชอบและ ทบทวนเมื่อไร ได้ดี แต่ไม่ค่อยบอกว่าต้องวัดอะไร ส่วน NIST มีหมวด MEASURE ทั้งหมวดเรื่องการทดสอบความน่าเชื่อถือ ความปลอดภัย ความเป็นส่วนตัว และอคติ ตัวอย่างเช่นเรื่องความเป็นธรรม

พ.ร.บ.คุ้มครองข้อมูลฯ ไม่ได้บอกว่าต้องวัดอคติของระบบที่ตัดสินเรื่องคน ช่องว่างนี้ NIST เติมให้ได้ แต่ต้องระวังหนึ่งเรื่อง ถ้าจะเก็บข้อมูลศาสนา เชื้อชาติ หรือความพิการเพื่อทดสอบอคติ ข้อมูลเหล่านี้เป็นข้อมูลอ่อนไหว ต้องหาฐานทางกฎหมายก่อน ความตั้งใจดีไม่ใช่ฐานทางกฎหมาย

ทางที่บันทึกของทีมแนะนำจึงเป็นสามชั้น ใช้ PDPA เป็นฐานเพราะบังคับอยู่แล้ว ใช้โครง ISO 42001 เป็นกระดูกสันหลังของเอกสารและรอบทบทวน แล้วใช้ NIST เติมว่าแต่ละมาตรการต้องวัดอะไร คู่มือของทีมมีตารางจับคู่ทั้งสองกรอบเกือบข้อต่อข้อ เช่น ISO A.4 คู่กับ GOVERN 1.6 และ ISO A.10 คู่กับ GOVERN 6, MAP 4 และ MANAGE 3

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

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

งานส่วนที่ทับกันระหว่างสองกรอบกับ PDPA ทำในระบบเดียวได้ AIPDPA มีทะเบียนระบบ AI และ AI Risk Radar ที่วางกฎหมายไทย NIST AI RMF และ ISO 42001 ไว้ในหน้าเดียว ลองตรวจความเสี่ยง AI ฟรี ก่อนตัดสินใจก็ได้ ถ้าบริษัทมีลูกค้าในยุโรปด้วย อ่านต่อที่ EU AI Act กับธุรกิจไทย

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

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

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