คุณไม่ได้เริ่มจากศูนย์
องค์กรขนาดกลางถึงใหญ่ในไทยส่วนใหญ่มีโครงสร้างพื้นฐานอย่าง SSE/SASE, Identity, DLP, SIEM และ ITSM อยู่แล้ว ซึ่งครอบคลุม AI Governance ได้บางส่วน งานที่แท้จริงคือ รู้ว่าอะไรนำมาใช้ได้ ปิดช่องว่างที่เป็น AI-native และเลือกแนวทาง Manual, Build หรือ Buy ในแต่ละด้าน
ตัวเลขที่สะท้อนความเร่งด่วน (ตามที่อ้างในเอกสาร):
- 61% ขององค์กรไทยนำ AI มาใช้แล้ว เพิ่มจาก 47% ในหนึ่งปี (Deloitte 2026)
- 4.2 ล้าน กรณีการละเมิดข้อมูลรั่วไหลจาก Generative AI ที่ Zscaler ติดตามได้ในหนึ่งปี
- 91,000+ ความพยายามโจมตีที่เกี่ยวข้องกับ AI ที่ ThaiCERT บันทึกไว้ ช่วงปลายปี 2025–2026
- USD 670K ค่าใช้จ่ายในการแก้ไขเหตุละเมิดจาก "Shadow AI" ที่ไม่ได้รับการจัดการหนึ่งครั้งในปี 2026
สองเส้นโค้งที่กำลังไล่กันทัน
ด้านการใช้งาน: ธุรกิจไทยที่ใช้ AI อย่างสม่ำเสมอ 43% (เพิ่มจาก 32%), แรงงานไทยที่ถูกจัดเป็น "Frontier Professionals" 32% (สองเท่าของค่าเฉลี่ยโลก), คะแนนความพร้อมดิจิทัลของไทย 2.12/4 (เพิ่มจาก 1.56)
ด้านกฎเกณฑ์:
- ก.ย. 2025 — นโยบายบริหารความเสี่ยง AI ของ ธปท. มีผลบังคับใช้
- ต.ค. 2025 — สกมช. (NCSA) เผยแพร่แนวปฏิบัติความมั่นคงปลอดภัย AI ฉบับแรกของไทย
- 2025 — แนวปฏิบัติ AI Governance ของ คปภ. มีผลกับบริษัทประกัน
- ก.ค. 2026 — ETDA เปิดรับฟังความเห็นร่าง พ.ร.บ. AI
พ.ร.บ.การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 ขยายหน้าที่รายงานเหตุการณ์ไปถึงเหตุการณ์ด้าน AI ในหน่วยงาน CII ทั้งเจ็ดภาคส่วนแล้ว
แผนที่ F1–F10
| # | ฟังก์ชัน | หน้าที่ |
|---|---|---|
| F1 | AI Inventory & Risk Classification | ทะเบียนกลางของ AI agent/use case ทุกตัว พร้อมระดับความเสี่ยง |
| F2 | Human Oversight Gate & Kill-Switch | จุดอนุมัติก่อน AI ดำเนินการที่มีผลกระทบสูง |
| F3 | Audit Trail & Explainability Log | บันทึกที่แก้ไขไม่ได้ของเส้นทางการตัดสินใจและแหล่งข้อมูล |
| F4 | Data Governance Layer | Data lineage, consent และการควบคุมการใช้ข้อมูลลูกค้าของผู้ขาย |
| F5 | Model & Vendor Risk Management | การ validate โมเดลเป็นระยะและทะเบียนความเสี่ยงบุคคลที่สาม |
| F6 | Transparency & Disclosure Controls | ติดป้ายเนื้อหาจาก AI และแจ้งชัดว่ากำลังคุยกับ AI |
| F7 | AI-Specific Security Controls | ตรวจจับ prompt injection และ runtime guardrails |
| F8 | Fairness / Bias Monitoring | ทดสอบอคติใน use case ที่กระทบสิทธิลูกค้า |
| F9 | Governance Documentation Generator | สร้าง impact assessment และรายงานพร้อมตรวจอัตโนมัติ |
| F10 | Incident Reporting & Regulatory Notification | แจ้งหน่วยงานกำกับเมื่อเกิดเหตุร้ายแรงภายในเวลาที่กำหนด |
F10 ถูกเพิ่มเข้ามาหลังทบทวนระบบกฎหมายไซเบอร์ของไทย และแตกต่างจากการเก็บ log ของ F3: F3 ถามว่า "เราสร้างภาพเหตุการณ์ย้อนหลังได้ไหม" ส่วน F10 ถามว่า "เรามีหน้าที่ต้องแจ้งหน่วยงานกำกับภายในเวลาที่กำหนดหรือไม่"
F10: สองระบอบ หนึ่งข้อกำหนด — รายงานให้ทันเวลา
| ไทย — สกมช. / พ.ร.บ.ไซเบอร์ | EU AI Act — Article 73 | |
|---|---|---|
| ใครต้องรายงาน | ผู้ให้บริการ CII (ธนาคาร โทรคมนาคม พลังงาน สุขภาพ ฯลฯ) | ผู้ให้บริการระบบ AI ความเสี่ยงสูง |
| ระยะเวลา | สกมช. กำหนดตามความรุนแรง | 2 / 10 / 15 วันตามความรุนแรง |
| กลไก | ไม่กำหนด — รายงานแบบ manual ได้ | ไม่กำหนด — อนุญาตรายงานเบื้องต้นที่ไม่สมบูรณ์ |
| บทลงโทษ | คำสั่งให้ปฏิบัติตาม พ.ร.บ.ไซเบอร์ | ปรับสูงสุด €15M หรือ 3% ของรายได้ทั่วโลก |
ทั้งสองระบอบไม่ได้บังคับให้ทำเป็นระบบอัตโนมัติ — กระบวนการ manual ที่มีเอกสารพร้อมแม่แบบเตรียมไว้ล่วงหน้าก็เพียงพอ
สิ่งที่คุณน่าจะมีอยู่แล้ว
- SSE / SASE Web Gateway → F7 (บางส่วน) — เช่น Zscaler, Netskope, Palo Alto Prisma Access, Cloudflare
- SSO / IAM → F2 (บางส่วน) — เช่น Microsoft Entra ID, Okta, Ping Identity
- Data Security DLP / CASB → F4 (ส่วนใหญ่) — เช่น Microsoft Purview, Forcepoint, Symantec, Netskope
- SIEM / SOAR → F3 (บางส่วน) — เช่น Microsoft Sentinel, Splunk, IBM QRadar
- ITSM → F10 (บางส่วน — ภายในเท่านั้น) — เช่น ManageEngine ServiceDesk Plus, ServiceNow, Jira Service Management
ช่องว่างที่เป็น AI-native
- F1 ทะเบียน AI: เริ่มแบบ manual ด้วย spreadsheet หรือ SharePoint list (agent, เจ้าของ, วัตถุประสงค์, ข้อมูลที่เข้าถึง, ระดับความเสี่ยง) หรือใช้เครื่องมือเฉพาะ เช่น Microsoft Purview AI Hub, Credo AI, IBM watsonx.governance, OneTrust
- F2 Oversight & Kill-Switch: เริ่มจากข้อกำหนดการอนุมัติโดยผู้ตรวจที่ระบุชื่อ หรือใช้ Power Automate, ServiceNow Workflow และแพลตฟอร์ม AI runtime ที่มี approval gate
- F7 Prompt Injection & Runtime Security: ผู้ขายด้านความปลอดภัยรายใหญ่สี่รายมีความสามารถนี้ — Check Point (Lakera), Palo Alto Networks (Prisma AIRS), Fortinet (FortiAIGate), F5 (AI Gateway พร้อม MCP Gateway) ซึ่งครอบคลุม F7 ได้ดี แต่ไม่ครอบคลุม F1, F8, F9 ด้วยตัวเอง
- F8 Fairness: Fairlearn ของ Microsoft หรือความสามารถ model-drift/fairness ของ OneTrust
- F9 Documentation: เริ่มด้วยแม่แบบ (EU AI Act, NIST AI RMF) หรือ Microsoft Purview Compliance Manager ที่มีแม่แบบกฎเกณฑ์กว่า 360 รายการ
- F10 Incident Reporting: ไม่ต้องซื้อซอฟต์แวร์ใหม่ — map ระดับความรุนแรงใน ITSM กับเกณฑ์ สกมช./Article 73, เตรียมแม่แบบการแจ้งล่วงหน้า และเชื่อม ticket ITSM กับ audit trail ของ F3
ข้อสรุป: ไม่มีกลุ่มเครื่องมือใดครอบคลุมทั้งกรอบ — ผู้ขายด้านความปลอดภัยเด่นใน F3/F4/F7, เครื่องมือ governance เด่นใน F5/F6/F8/F9 ส่วน F2 และ F10 ยังต้องพึ่งกระบวนการ manual ไม่ว่างบประมาณเท่าไร
Manual, Build หรือ Buy
- ระยะเริ่มต้น (งบจำกัด ไม่อยู่ในภาคกำกับ/CII): Manual-first — spreadsheet สำหรับ F1, นโยบายอนุมัติสำหรับ F2, DLP/SSE เดิมสำหรับ F4/F7, เอกสาร map ความรุนแรงสำหรับ F10
- กำลังเติบโต (งบปานกลาง มี security stack แล้ว): ขยายของที่มี — เพิ่มโมดูล AI ให้ SSE/SASE และ DLP, เชื่อม ITSM กับ workflow engine สำหรับ F2, ใช้ Purview Compliance Manager สำหรับ F9
- อยู่ภายใต้การกำกับ (ธนาคาร ประกัน CII หรือมีธุรกรรมกับ EU): ลงทุนแพลตฟอร์มเฉพาะ — governance platform (F1, F5, F8, F9) คู่กับ runtime AI security (F7) คุ้มค่าเมื่อความเสี่ยงค่าปรับสูงกว่าต้นทุนแพลตฟอร์ม
ห้าสิ่งที่ทำได้ทันทีเช้าวันจันทร์
- ตรวจสอบก่อนจัดซื้อ — map SSE/SASE, IAM, DLP, SIEM, ITSM กับ F1–F10 ก่อนประเมินผู้ขายใหม่
- F2 และ F10 มักขาดหายไป — ทั้งสองต้องมี workflow เชิงรุก ไม่ใช่แค่ log
- กระบวนการ manual ตอบโจทย์ F10 ได้วันนี้ — สกมช., EU AI Act, ธปท. และ คปภ. กำหนดผลลัพธ์ ไม่ได้กำหนดกลไก
- ให้ระดับความเสี่ยงกำหนดระดับการลงทุน — SME ในประเทศมีเกณฑ์ต่างจากธนาคารที่ ธปท. กำกับ
- ภูมิทัศน์นี้เปลี่ยนเร็ว — ทบทวนการ map นี้ทุกปี
ข้อมูลอ้างอิงแหล่งกฎเกณฑ์สาธารณะและเอกสารผู้ขาย ณ กันยายน 2026 ไม่ใช่คำแนะนำทางกฎหมายหรือการรับรองผลิตภัณฑ์