ทำไมต้องมี Compliance Matrix
เอกสารนี้แปลงแนวปฏิบัติของ EU AI Act, NIST AI Risk Management Framework และระบบกำกับ AI ที่กำลังเกิดขึ้นในไทย ให้เป็น รายการฟีเจอร์ที่จับต้องได้สำหรับ AI agent platform โดยจำกัดขอบเขตเฉพาะชั้น "must-have" — ฟีเจอร์ที่หน่วยงานกำกับหรือแนวปฏิบัติรายภาคอ้างถึงแล้วในรูปแบบใดรูปแบบหนึ่ง เพื่อให้แพลตฟอร์มป้องกันตัวเองได้วันนี้ และไม่ต้องออกแบบใหม่เมื่อร่าง พ.ร.บ. AI ของ ETDA กลายเป็นกฎหมาย
ภาพรวมกฎเกณฑ์ (ณ สิงหาคม 2026)
ไทยยังไม่มีกฎหมาย AI ฉบับครอบคลุมที่บังคับใช้ แต่ทิศทางชัดเจนและหน่วยงานกำกับรายภาคเริ่มบังคับใช้ความคาดหวังแล้ว
ร่าง พ.ร.บ. AI (ETDA) — สถานะร่าง เปิดรับฟังความเห็น 2 กรกฎาคม 2026
- โมเดลความเสี่ยงสี่ระดับตามแบบ EU AI Act: ห้ามใช้ / ความเสี่ยงสูง / ต้องขออนุญาต / ต้องเปิดเผย (deepfake, chatbot, Gen-AI)
- ครอบคลุมผู้พัฒนา ผู้ให้บริการ ผู้นำไปใช้ และผู้ให้บริการแพลตฟอร์ม รวมถึงหน่วยงานต่างประเทศที่ให้บริการผู้ใช้ในไทย
- มีความรับผิดแบบเคร่งครัด และข้อกำหนดสัญญา/data localization สำหรับผู้ขายที่ให้บริการหน่วยงานรัฐและ CII
- คาดว่าจะบังคับใช้ภายใน 1–3 ปี
ธนาคารแห่งประเทศไทย — นโยบายบริหารความเสี่ยง AI — มีผลตั้งแต่ 12 กันยายน 2025
- ใช้กับสถาบันการเงินและผู้ให้บริการชำระเงินภายใต้การกำกับของ ธปท.
- ครอบคลุม AI ที่พัฒนาเองและจากบุคคลที่สาม รวมถึง generative AI และ agentic AI
- ตั้งอยู่บนหลัก FEAT: Fairness, Ethics, Accountability, Transparency
- ต้องมีการกำกับโดยคณะกรรมการ/ผู้บริหารระดับสูง ทะเบียน AI การบริหารความเสี่ยงตลอดวงจรชีวิต การ validate โมเดล ความมั่นคงปลอดภัยไซเบอร์ และการเปิดเผยต่อผู้บริโภคพร้อมการทบทวนโดยมนุษย์
คปภ. — แนวปฏิบัติ AI Governance — มีผล 2025
- เน้นการพิจารณารับประกันและการจัดการสินไหมเป็นกระบวนการความเสี่ยงสูง
- กำหนดให้มีมนุษย์อยู่ในวงจรการตัดสินใจสุดท้ายสำหรับ AI ความเสี่ยงสูง
ภาครัฐ — แนวปฏิบัติ สพร. (DGA) — มีผล (ไม่ผูกพัน) และน่าจะมีข้อกำหนด data localization เมื่อร่าง พ.ร.บ. AI บังคับใช้
ข้ามภาคส่วน: PDPA, ร่างแนวปฏิบัติ AI ของ สคส., ไซเบอร์ — ร่างแนวปฏิบัติ สคส. กุมภาพันธ์ 2026 กำหนดให้ทำ DPIA สำหรับ AI ความเสี่ยงสูง และห้ามใช้ข้อมูลลูกค้าฝึกโมเดลบางประเภทโดยไม่ได้รับความยินยอม ส่วนแนวปฏิบัติความมั่นคงปลอดภัย AI ของ สกมช. อ้างอิง ISO/IEC 42001 และ NIST AI RMF
ฟีเจอร์ 9 กลุ่ม (F1–F9)
| # | ฟีเจอร์ | สิ่งที่ทำ |
|---|---|---|
| F1 | AI Inventory & Risk Classification Registry | ทะเบียนกลางพร้อมระดับความเสี่ยง (ห้ามใช้ / สูง / จำกัด / ต่ำ) |
| F2 | Human-in-the-Loop / Oversight Gate & Kill-Switch | จุดอนุมัติก่อนการกระทำผลกระทบสูง (อนุมัติสินเชื่อ ปฏิเสธสินไหม การตั้งราคา) และปุ่มหยุด |
| F3 | Full Audit Trail & Explainability Log | บันทึกเส้นทางการตัดสินใจ prompt, tool call และแหล่งข้อมูล สร้างภาพย้อนหลังได้ |
| F4 | Data Governance Layer | Data lineage, consent, PDPA และการห้ามผู้ขายนำข้อมูลลูกค้าไปฝึกโมเดล |
| F5 | Model & Vendor Risk Management | validate โมเดลเป็นระยะ (ความแม่นยำ อคติ อัตรา hallucination) และทะเบียนความเสี่ยงผู้ขาย |
| F6 | Transparency & Disclosure Controls | ติดป้ายเนื้อหาจาก AI และแจ้งว่ากำลังสื่อสารกับ AI |
| F7 | AI-Specific Security Controls | ตรวจจับ prompt injection ป้องกัน data poisoning สอดคล้อง ISO/IEC 42001 และ NIST AI RMF |
| F8 | Fairness / Bias Monitoring | ทดสอบอคติใน use case ที่กระทบสิทธิลูกค้า |
| F9 | Governance Documentation Generator | สร้าง impact assessment, model card และรายงานพร้อมส่งหน่วยงานกำกับ |
ตาราง matrix ฉบับเต็มในเอกสาร ให้คะแนนแต่ละฟีเจอร์เทียบกับแต่ละแหล่งกฎเกณฑ์ ว่า "ต้องมีแล้ว", "คาดว่าจะต้องมีเร็ว ๆ นี้" หรือ "best practice" — โดย NIST AI RMF ถูกรวมไว้เป็นข้อมูลอ้างอิงแบบสมัครใจ
รูปแบบสถาปัตยกรรมของเครื่องมือ AI Governance
"AI Governance" ไม่ใช่ส่วนประกอบเดียว ระบบ production ที่อยู่ภายใต้การกำกับมักใช้ร่วมกันตั้งแต่สามรูปแบบขึ้นไป:
- API Gateway / Interceptor — reverse proxy ระหว่างแอปกับผู้ให้บริการ LLM บังคับนโยบายกลาง (rate limit, โมเดลที่อนุญาต, PII redaction, ต้นทุน, routing) เหมาะกับ F7 และ F2 เพราะบล็อกได้ก่อนถึงโมเดล
- Embedded LLM Guard — ไลบรารีภายในแอป (เช่น Guardrails AI, LLM Guard, NVIDIA NeMo Guardrails) latency ต่ำ แต่นโยบายกระจายรายแอป
- Specialized Guard Model — classifier เฉพาะทาง (เช่น Lakera Guard, Llama Guard, AWS Bedrock Guardrails) คัดกรอง prompt injection, jailbreak, PII โดยทั่วไปต่ำกว่า 100ms เป็นชั้นที่เชื่อมโยงกับข้อกำหนด "technical robustness" (EU AI Act Art. 15) มากที่สุด แต่ไม่สามารถรับมือทุกความเสี่ยงใน OWASP LLM Top 10 ได้ลำพัง
- Database / Data-Layer Control — สิทธิ์ระดับแถว/คอลัมน์ การเข้ารหัสระดับฟิลด์ และ consent flag ที่ฐานข้อมูลหรือ vector store — ที่นี่คือที่ที่ F4 ถูกบังคับใช้จริง: ไม่ส่งข้อมูลที่ผู้ร้องขอไม่มีสิทธิ์ให้โมเดลตั้งแต่แรก
- UI Guardrails — แบนเนอร์แจ้งว่าเป็น AI ขั้นตอนยืนยันก่อนการกระทำผลกระทบสูง และการแสดงแหล่งอ้างอิง (F6 และ F2) แต่เป็นชั้นที่อ่อนที่สุดหากใช้ลำพัง
ส่วนเสริมรายภาค
- ธนาคาร (ธปท.): รายงานต่อคณะกรรมการตามหลัก FEAT, hook สำหรับร่างประกาศ Digital Channel Security ของ ธปท. (กรกฎาคม 2026), แยกหน้าที่ระหว่างการพัฒนาโมเดลและการอนุมัติใช้งาน
- ประกันภัย (คปภ.): workflow การพิจารณารับประกัน/สินไหมที่ต้องมีมนุษย์ลงนามก่อนการตัดสินใจเชิงลบ และคำอธิบายภาษาที่ผู้บริโภคเข้าใจสำหรับการอุทธรณ์
- ภาครัฐ / CII: ทางเลือก on-premise หรือ sovereign cloud, แม่แบบสัญญาสำหรับข้อกำหนดผู้ขายภาครัฐ และโหมด air-gapped
ลำดับการสร้าง
- Phase 1 — Foundation: F1, F2, F3 (ปลดล็อก pilot ในภาคที่มีการกำกับ)
- Phase 2 — Trust Layer: F4, F8, F6 (จำเป็นสำหรับ go-live)
- Phase 3 — Scale & Differentiate: F5, F7, F9
Gartner Magic Quadrant for AI Governance Platforms (2026)
Gartner เผยแพร่ Magic Quadrant ด้าน AI Governance Platforms ฉบับแรกเมื่อ 16 มิถุนายน 2026 โดยประเมินผู้ขายกว่า 100 ราย และคัดเหลือ 13 ราย — Leaders: IBM (watsonx.governance), ServiceNow (AI Control Tower), Truyo; Visionaries: Credo AI, ModelOp, OneTrust, Monitaur; Challengers: Holistic AI, SAP, Airia; Niche Players: Saidot, Cranium AI, Relyance AI (ตำแหน่งย่อยอาจต่างกันตามแหล่งข้อมูลรอง)
ข้อสรุปเชิงปฏิบัติ: ตำแหน่งใน MQ เป็นตัวกรองรายชื่อที่มีประโยชน์ แต่ไม่ใช่สิ่งทดแทนการประเมินความเหมาะสมกับข้อกำหนดของธนาคาร ประกัน หรือภาครัฐ และสำหรับแพลตฟอร์มที่สร้างเอง audit trail, human-oversight workflow และ data governance มักคุ้มค่าที่จะสร้างเป็นส่วนหนึ่งของแพลตฟอร์ม ขณะที่ prompt-injection detector มักไม่คุ้มที่จะเขียนเองเมื่อมีเครื่องมือระดับ Lakera อยู่แล้ว
เอกสารนี้ไม่ใช่คำแนะนำทางกฎหมาย ร่าง พ.ร.บ. AI ยังอยู่ระหว่างรับฟังความเห็นและอาจเปลี่ยนแปลง ควรตรวจสอบกับที่ปรึกษากฎหมายก่อนตัดสินใจ