# ISO/IEC 42001:2023 คืออะไร และใช้ Pentest พิสูจน์ความพร้อมของ AIMS อย่างไร

Locale: `th`

Source: `/th/compliance/iso-42001-ai-management/`

สารบัญ

1. [ภาพรวม](/th/compliance/iso-42001-ai-management/#topic-overview)
2. [AIMS ทำงานเป็นวงจรอย่างไร](/th/compliance/iso-42001-ai-management/#aims-core-framework)
3. [Annex A เปลี่ยนความเสี่ยง AI ให้เป็น Control ที่ตรวจสอบได้อย่างไร](/th/compliance/iso-42001-ai-management/#annex-a-controls)
4. [ISO/IEC 23894 ช่วยระบุความเสี่ยงที่ Checklist ทั่วไปมองไม่เห็น](/th/compliance/iso-42001-ai-management/#iso-23894-risk-management)
5. [ทำไม AI Pentest และ Red Teaming จึงเป็นหลักฐานสำคัญของ AIMS](/th/compliance/iso-42001-ai-management/#technical-verification-and-testing)
6. [ชุดหลักฐานที่ช่วยให้ผู้บริหารและผู้ตรวจประเมินตัดสินใจได้](/th/compliance/iso-42001-ai-management/#audit-ready-evidence)
7. [ตารางเปรียบเทียบข้อกำหนด](/th/compliance/iso-42001-ai-management/#compliance-matrix)
8. [ประเมินความพร้อม](/th/compliance/iso-42001-ai-management/#compliance-readiness-checklist)
9. [คำถามที่พบบ่อย](/th/compliance/iso-42001-ai-management/#compliance-faq)
10. [หัวข้อที่เกี่ยวข้อง](/th/compliance/iso-42001-ai-management/#related-compliance-frameworks)

# ISO/IEC 42001:2023 คืออะไร และใช้ Pentest พิสูจน์ความพร้อมของ AIMS อย่างไร

หากองค์กรใช้ AI ใน Production นโยบายเพียงอย่างเดียวไม่พอ หน้านี้สรุป ISO/IEC 42001:2023 และ ISO/IEC 23894:2023 พร้อมวิธีเปลี่ยนความเสี่ยงให้เป็นหลักฐานจาก AI Pentest และ Red Teaming ที่ผู้บริหารและผู้ตรวจประเมินใช้ตัดสินใจได้

สรุปภาพรวมข้อกำหนด

กลุ่มเป้าหมายที่บังคับใช้

องค์กรที่พัฒนา ให้บริการ หรือประยุกต์ใช้ระบบ AI ในกระบวนการธุรกิจ

ความถี่ในการทดสอบ

ก่อน Go-live, หลัง Significant Change และตามรอบที่กำหนดจาก Risk Treatment Plan

ขอบเขตการทดสอบ

AIMS, AI Inventory, Data, Model, Application, Agent, Third-party และ Control ที่เลือกใน SoA

ความเสี่ยงหากไม่ปฏิบัติตาม

Audit Nonconformity, หลักฐาน Control ไม่เพียงพอ, ช่องโหว่ AI และ Residual Risk ที่ผู้บริหารไม่เห็น

## AIMS ทำงานเป็นวงจรอย่างไร

ISO/IEC 42001:2023 เป็นมาตรฐานระบบบริหารที่ใช้กับองค์กรซึ่งพัฒนา ให้บริการ หรือใช้ระบบ AI โดยเชื่อมการกำกับดูแล ความเสี่ยง และหลักฐานตลอดวงจร Plan-Do-Check-Act

[![วงจร AIMS: จากความเสี่ยงสู่การปรับปรุง: วางแผน → ดำเนินการ → ตรวจสอบ → ปรับปรุง](/assets/compliance/aims-management-th-v1.webp)](/assets/compliance/aims-management-th-v1.webp)

**วงจร AIMS: จากความเสี่ยงสู่การปรับปรุง**

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

1. **วางแผน** — กำหนดบริบท เป้าหมาย และความเสี่ยง
2. **ดำเนินการ** — ใช้กระบวนการและมาตรการที่เลือก
3. **ตรวจสอบ** — ติดตาม วัดผล ตรวจประเมิน และทบทวน
4. **ปรับปรุง** — แก้ไขและยกระดับระบบบริหาร

- Clause 4 ถึง 10 ครอบคลุมบริบทองค์กร ความเป็นผู้นำ การวางแผน การสนับสนุน การดำเนินงาน การประเมินสมรรถนะ และการปรับปรุงตาม Harmonized Structure
- Clause 6.1.2 และ 6.1.3 กำหนดกระบวนการประเมินและจัดการความเสี่ยง AI รวมถึง Risk Treatment Plan และ Statement of Applicability ที่อธิบายเหตุผลของ Control ที่เลือกใช้
- Clause 8.2 ถึง 8.4 ทำให้การประเมินความเสี่ยง การจัดการความเสี่ยง และการประเมินผลกระทบเป็นกิจกรรมที่ต้องเกิดจริงตามรอบและเมื่อระบบเปลี่ยนอย่างมีนัยสำคัญ
- มาตรฐานไม่ได้รับรองว่าโมเดลปลอดภัยโดยอัตโนมัติ AIMS ที่ดีต้องเชื่อม Policy, Control Owner, เกณฑ์ยอมรับ และหลักฐานจากระบบจริงเข้าด้วยกัน

## Annex A เปลี่ยนความเสี่ยง AI ให้เป็น Control ที่ตรวจสอบได้อย่างไร

Annex A มี Control อ้างอิง 38 รายการใน 9 กลุ่มตั้งแต่ A.2 ถึง A.10 องค์กรต้องเลือก Control จากความเสี่ยง อธิบายการรวมและการยกเว้นใน SoA และพิสูจน์ว่า Control ทำงานจริง

- A.5 ครอบคลุมการประเมินผลกระทบของระบบ AI ต่อบุคคล กลุ่มบุคคล และสังคม โดย ISO/IEC 42005:2025 เป็นแนวทางเสริมสำหรับทำ Impact Assessment ให้เป็นระบบ
- A.6 ครอบคลุมวัตถุประสงค์การพัฒนา ข้อกำหนด การทวนสอบ การนำขึ้นใช้งาน การปฏิบัติงาน การติดตาม เอกสารทางเทคนิค และ Event Log ตลอดวงจรชีวิต
- A.7 ครอบคลุมการจัดการข้อมูล การคัดเลือก Data Quality, Data Provenance และการเตรียมข้อมูล ซึ่งเป็นฐานของการป้องกัน Data Poisoning และการประเมิน Bias
- A.10 ครอบคลุมลูกค้า ผู้ให้บริการ และบุคคลภายนอก จึงต้องตรวจทั้ง Model API, Cloud AI, Dataset, Plugin และ Dependency ที่อยู่นอกการควบคุมโดยตรง

## ISO/IEC 23894 ช่วยระบุความเสี่ยงที่ Checklist ทั่วไปมองไม่เห็น

ISO/IEC 23894:2023 ให้แนวทางจัดการความเสี่ยงสำหรับองค์กรที่พัฒนา ผลิต นำขึ้นใช้งาน หรือใช้ระบบ AI และช่วยนำการบริหารความเสี่ยงเข้าไปอยู่ในกิจกรรมประจำขององค์กร

- เริ่มจากบริบท วัตถุประสงค์ ผู้มีส่วนได้ส่วนเสีย และผลกระทบก่อนเลือกวิธีวัด ทำให้ทีมไม่ใช้คะแนนช่องโหว่แบบเดียวแทนความเสี่ยงด้าน Safety, Privacy, Bias และ Business Impact
- พิจารณาความไม่โปร่งใส Data Quality, Model Drift, ความสามารถที่เปลี่ยนหลัง Fine-tuning, Human Oversight และ Dependency ที่อาจสร้างความเสี่ยงใหม่
- บันทึก Assumption, Limit, Risk Owner, เกณฑ์ยอมรับ และ Residual Risk เพื่อให้ผลทดสอบเชื่อมกับการอนุมัติปล่อยระบบและการตัดสินใจของฝ่ายบริหาร
- ใช้ ISO/IEC 23894 เป็นแนวทางเสริมของ AIMS ไม่ใช่ใบรับรองแยก และปรับวิธีประเมินให้เหมาะกับบริบทของแต่ละองค์กร

## ทำไม AI Pentest และ Red Teaming จึงเป็นหลักฐานสำคัญของ AIMS

ISO/IEC 42001 ไม่ได้กำหนดวิธี Pentest หรือรอบทดสอบตายตัว แต่กำหนดให้บริหารความเสี่ยง ประเมินประสิทธิผล และเก็บหลักฐาน การทดสอบอิสระจึงเป็นวิธีพิสูจน์ Control ทางเทคนิคที่น่าเชื่อถือ

[![จากความเสี่ยง AI สู่หลักฐาน: กำหนดขอบเขต → ออกแบบการทดสอบ → ทดสอบและบันทึก → แก้ไขและทดสอบซ้ำ](/assets/compliance/aims-test-evidence-th-v1.webp)](/assets/compliance/aims-test-evidence-th-v1.webp)

**จากความเสี่ยง AI สู่หลักฐาน**

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

1. **กำหนดขอบเขต** — AI Inventory และ Data Flow
2. **ออกแบบการทดสอบ** — Risk Scenario และเกณฑ์สำเร็จ
3. **ทดสอบและบันทึก** — Test Case, Version และ Log
4. **แก้ไขและทดสอบซ้ำ** — Owner, Remediation และ Retest

- ทดสอบ Direct Prompt Injection, Indirect Prompt Injection, RAG Poisoning, Sensitive Data Disclosure, Model Extraction และการหลบเลี่ยง Guardrail ตาม Threat Model ของระบบจริง
- สำหรับ Agent ให้ทดสอบ Least Privilege, Tool Allowlist, Human Approval, Credential Scope, Memory Poisoning, Output Handling และความสามารถในการหยุดการทำงานที่ผิดปกติ
- เก็บผลเชิงประจักษ์ เช่น Test Case, Prompt, Model Version, Dataset Version, Success Rate, Severity, Log และหลักฐาน Retest เพื่อให้ตรวจสอบย้อนหลังได้
- กำหนดรอบจากความเสี่ยงและการเปลี่ยนแปลง เช่น ก่อน Go-live หลังเปลี่ยน Model หรือ Prompt เมื่อเพิ่ม RAG Source และเมื่อเพิ่ม Tool หรือสิทธิ์ของ Agent

## ชุดหลักฐานที่ช่วยให้ผู้บริหารและผู้ตรวจประเมินตัดสินใจได้

รายงานที่ดีไม่จบที่รายการช่องโหว่ แต่ต้องแสดงว่า Risk ใดถูกทดสอบ Control ใดล้มเหลว ใครเป็นเจ้าของการแก้ไข และ Residual Risk หลัง Retest อยู่ในระดับที่องค์กรยอมรับหรือไม่

[![หลักฐานที่ใช้ตัดสินใจใน AIMS: กำหนดขอบเขต → ประเมินความเสี่ยงและโอกาส → ดำเนินกระบวนการ → ประเมินผลและหลักฐาน → ทบทวนและปรับปรุง](/assets/compliance/guide-iso-42001-ai-management-audit-ready-evidence-th-v1.webp)](/assets/compliance/guide-iso-42001-ai-management-audit-ready-evidence-th-v1.webp)

**หลักฐานที่ใช้ตัดสินใจใน AIMS**

หลักฐานช่วยให้ผู้บริหารตัดสินใจและปรับปรุง AIMS อย่างต่อเนื่อง

1. **กำหนดขอบเขต** — ระบุระบบ AI กระบวนการ และผู้เกี่ยวข้อง
2. **ประเมินความเสี่ยงและโอกาส** — เข้าใจผลกระทบตามบริบท
3. **ดำเนินกระบวนการ** — ใช้นโยบายและมาตรการที่เลือก
4. **ประเมินผลและหลักฐาน** — ตรวจว่ากระบวนการทำงานตามเป้าหมาย
5. **ทบทวนและปรับปรุง** — ใช้ผลตัดสินใจและปรับ AIMS

- เริ่มด้วย AIMS Scope, AI Inventory, Data Flow, Trust Boundary, Model Dependency, ผู้ใช้งาน และสิทธิ์ของ Agent เพื่อป้องกันการทดสอบตกหล่น
- เชื่อม Finding กับ Risk Register, SoA, Risk Treatment Plan, Impact Assessment และเกณฑ์ Go-live โดยไม่อ้างว่าผล Pentest เพียงครั้งเดียวทำให้องค์กรได้รับการรับรอง
- แยก Finding ของ Application, Infrastructure, Model, Data และ Agent พร้อมระบุ Business Impact และเส้นทางโจมตีที่พิสูจน์ได้
- ปิดวงจรด้วย Remediation Owner, Due Date, Retest Evidence, Risk Acceptance และการนำบทเรียนกลับเข้าสู่ Management Review

## ตารางเปรียบเทียบข้อกำหนดและการทดสอบความปลอดภัย

สรุปรายละเอียดประกาศ บทบัญญัติ และขอบเขตการทดสอบความปลอดภัยที่จำเป็น

| ประกาศ และข้อกำหนด | สาระสำคัญ | ขอบเขตการทดสอบ | รอบเวลาทดสอบ |
| --- | --- | --- | --- |
| **Clause 6.1.2 และ 6.1.3** | การประเมินและการจัดการความเสี่ยงระบบ AI | ประเมินความเสี่ยงเชิงเทคนิคของระบบ AI และจัดทำแผนจัดการความเสี่ยง (Risk Treatment Plan) | ตามรอบที่กำหนดและเมื่อมี Significant Change ตาม Clause 8.2 และ 8.3 |
| **Annex A.6** | Control ตลอดวงจรชีวิตระบบ AI | กำหนด Requirement, Verification, Validation, Deployment, Monitoring, Technical Documentation และ Event Log | ก่อน Go-live และเมื่อ Model, Prompt, Data, Tool หรือ Architecture เปลี่ยน |
| **Clause 9.1 และ 10.2** | การประเมินประสิทธิผลและ Corrective Action | กำหนดสิ่งที่ต้องติดตาม วิธีวัด เกณฑ์ประเมิน และหลักฐานว่าการแก้ไข Risk หรือ Finding มีประสิทธิผล | ติดตามตาม Risk และทดสอบซ้ำหลัง Remediation |
| **Annex A.7** | การกำกับดูแลและตรวจสอบที่มาของข้อมูล (Data Provenance) | ตรวจ Data Selection, Data Quality, Data Provenance, Preparation และความเสี่ยง Data Poisoning | เมื่อรับ เตรียม เปลี่ยน หรือใช้ Dataset สำหรับ Training, Fine-tuning และ RAG |

### เครื่องมือประเมินความพร้อม

คลิกเลือกรายการที่องค์กรของท่านได้ดำเนินการแล้ว เพื่อคำนวณระดับความพร้อมเบื้องต้น

0%

กำหนด AIMS Scope, AI Inventory, Policy, Role และ Risk Owner ตามบริบทขององค์กร
          
          
            
            จัดทำ AI Risk Assessment, Risk Treatment Plan, SoA และ Impact Assessment ที่เชื่อมโยงกัน
          
          
            
            กำหนด Requirement, Acceptance Criteria และหลักฐาน Verification กับ Validation ก่อน Go-live
          
          
            
            ตรวจ Data Selection, Data Quality, Data Provenance, Privacy, Bias และ Data Poisoning ตาม Annex A.7
          
          
            
            ทำ AI Pentest หรือ Red Teaming ตาม Threat Model และเก็บ Model Version, Prompt, Test Case, Log และ Result
          
          
            
            ติดตาม Production Behavior, Model Drift, Incident, Remediation, Retest และ Residual Risk อย่างต่อเนื่อง

ประเมินความพร้อม

เลือกรายการด้านบนเพื่อประเมินผล

[ปรึกษาผู้เชี่ยวชาญ และขอใบเสนอราคา](/th/#contact)

## คำถามที่พบบ่อย (FAQ)

คำถามและข้อสงสัยสำคัญเกี่ยวกับข้อกำหนดและการตรวจประเมินตามมาตรฐาน

### ISO/IEC 42001 บังคับให้องค์กรทำ AI Penetration Testing หรือไม่?

มาตรฐานไม่ได้กำหนดวิธี Pentest หรือรอบความถี่ตายตัว แต่กำหนดให้ประเมินความเสี่ยง เลือก Control วัดประสิทธิผล และเก็บหลักฐาน AI Pentest และ Red Teaming จึงเป็นวิธีสำคัญในการพิสูจน์ Control ทางเทคนิค

### ISO/IEC 42001 และ ISO/IEC 23894 ต่างกันอย่างไร?

ISO/IEC 42001 เป็นมาตรฐานระบบบริหารที่มีข้อกำหนดสำหรับ AIMS และใช้รับรองได้ ส่วน ISO/IEC 23894 เป็นแนวทางบริหารความเสี่ยง AI ที่องค์กรปรับใช้ตามบริบทและไม่มีระบบรับรองแยก

### ผล Pentest ครั้งเดียวทำให้องค์กรพร้อมรับรอง ISO/IEC 42001 หรือไม่?

ไม่ ผล Pentest เป็นหลักฐานส่วนหนึ่ง องค์กรยังต้องมี AIMS Scope, Policy, Risk Assessment, SoA, Impact Assessment, Monitoring, Internal Audit, Management Review, Corrective Action และหลักฐานการปรับปรุงต่อเนื่อง

## หัวข้อและกฎหมายกำกับดูแลที่เกี่ยวข้อง

- [
                แนวปฏิบัติ AI Security Guidelines ของ สกมช.
                
              ](/th/compliance/ncsa-ai-security-guidelines/)
- [
                NIST AI RMF 1.0 คืออะไร และวางแผนทดสอบ GenAI อย่างไร
                
              ](/th/compliance/nist-ai-rmf/)
- [
                ISO/IEC 27001:2022 ต้องทำ Penetration Testing ไหม
                
              ](/th/compliance/iso-27001/)
- [
                Google SAIF 2.0 คืออะไร และป้องกัน AI Agent อย่างไร
                
              ](/th/compliance/google-saif/)

เปิดภาพขนาดเต็มเพื่อซูม

## เอกสารต้นทางฉบับทางการ

ตรวจสอบสถานะ ISO/IEC 42001:2023, ISO/IEC 23894:2023 และมาตรฐาน AI ที่เกี่ยวข้องได้จากเว็บไซต์ ISO

[ไปยังแหล่งทางการ ](https://www.iso.org/sectors/it-technologies/ai)

## ต้องการทำ Pentest ให้สอดคล้องกับข้อกำหนดเหล่านี้?

เล่าขอบเขตระบบและข้อกำหนดที่ต้องปฏิบัติตามให้เราฟัง ทีม STH จะช่วยประเมินแนวทางและจัดทำใบเสนอราคาให้

[ขอใบเสนอราคา Pentest](/th/#contact)

อัปเดตล่าสุด 7 ตุลาคม 2569