แผนรับมือเหตุจาก AI คือแผนรับมือเหตุเดิมขององค์กรที่เพิ่มสามเรื่องที่แผนเดิมไม่มี คือ ประเภทเหตุที่เกิดเฉพาะกับ AI เช่น prompt injection และเอเจนต์ทำเกินสิทธิ์ ขั้นตอนหยุดหรือปิดระบบ AI ได้ทันที และช่องทางแจ้งผู้ให้บริการ AI นาฬิกาตามกฎหมายไทยยังเป็นชุดเดิม ถ้ามีข้อมูลส่วนบุคคลรั่ว ต้องแจ้ง สคส. โดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ทราบเหตุ ตาม PDPA มาตรา 37 (4) ถ้าแจ้งไม่ทันต้องแจ้งโดยเร็วไม่เกิน 15 วันนับแต่ทราบเหตุพร้อมชี้แจงเหตุผล และถ้าองค์กรเป็นหน่วยงานโครงสร้างพื้นฐานสำคัญทางสารสนเทศ (CII) เหตุไซเบอร์ที่มีนัยสำคัญต้องรายงาน สกมช. ภายใน 24 ชั่วโมง เรื่องที่องค์กรส่วนใหญ่ยังไม่พร้อมคือการหยุดระบบ ISACA พบในปี 2026 ว่า 56% ของผู้ตอบไม่รู้ว่าต้องใช้เวลานานเท่าไรจึงจะหยุดระบบ AI ได้เมื่อเกิดเหตุ และมีเพียง 12% ที่มีขั้นตอนปิดหรือ override ระบบ AI เป็นลายลักษณ์อักษรและทดสอบสม่ำเสมอ บทความนี้มีแม่แบบแผนหกขั้น ตารางนาฬิกาตามกฎหมาย ฟิลด์ขั้นต่ำของรายงานเหตุตาม NIST และช่องทางแจ้งผู้ให้บริการทั้งสี่ราย
ข้อมูลตรวจจาก PDPA ในราชกิจจานุเบกษา เอกสารความเห็นของ สคส. ประกาศ กกม. และเอกสารของ NIST, OWASP และผู้ให้บริการ เมื่อ 24 ต.ค. 2026 บทความนี้ไม่ใช่คำปรึกษาทางกฎหมาย
เหตุจาก AI คืออะไร
OECD นิยาม เหตุจาก AI (AI incident) ว่าเหตุการณ์ที่การพัฒนา การใช้ หรือความผิดพลาดของระบบ AI ก่อความเสียหายจริงทั้งทางตรงและทางอ้อม เช่น ต่อสุขภาพ โครงสร้างพื้นฐานสำคัญ สิทธิของบุคคล หรือทรัพย์สิน ส่วน AI hazard คือเหตุการณ์ที่อาจนำไปสู่ความเสียหายได้ ในงานจริงควรรายงานทั้งสองแบบ เพราะ hazard ที่แก้ทันคือเหตุที่ไม่ต้องเกิด
| ประเภทเหตุ | ตัวอย่าง | อ้างอิงใน OWASP Top 10 for LLM 2025 |
|---|---|---|
| คำสั่งแฝง | เอกสารหรืออีเมลที่ AI อ่านมีคำสั่งให้ส่งข้อมูลออก | LLM01 Prompt Injection |
| ข้อมูลอ่อนไหวรั่ว | AI ตอบด้วยข้อมูลของลูกค้ารายอื่น หรือพนักงานวางข้อมูลลับลงเครื่องมือที่ไม่อนุมัติ | LLM02 Sensitive Information Disclosure |
| เอเจนต์ทำเกินสิทธิ์ | เอเจนต์ลบไฟล์ ส่งอีเมล หรือสั่งซื้อโดยไม่มีคนอนุมัติ | LLM06 Excessive Agency (ฉบับ 2026 ขยับขึ้นเป็นอันดับ 3) |
| ข้อมูลผิดถูกนำไปใช้ | ตัวเลขหรือข้อกฎหมายที่ AI สร้างขึ้นถูกส่งให้ลูกค้า | LLM09 Misinformation |
| ค่าใช้จ่ายพุ่ง | เอเจนต์วนเรียก API จนค่าใช้งานเกินงบ | LLM10 Unbounded Consumption |
ภัยเหล่านี้ตรงกับที่ สกมช. ระบุในแนวปฏิบัติ AI Security Guidelines และวิธีป้องกันก่อนเกิดเหตุดูที่ความปลอดภัยของ AI ในองค์กร
นาฬิกาตามกฎหมายไทย
| เมื่อเกิด | ต้องแจ้งใคร | ภายในเมื่อไร | ที่มา |
|---|---|---|---|
| ข้อมูลส่วนบุคคลรั่ว และมีความเสี่ยงต่อสิทธิของบุคคล | สคส. | โดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ทราบเหตุ | PDPA มาตรา 37 (4) |
| แจ้ง สคส. ไม่ทัน 72 ชั่วโมง | สคส. พร้อมชี้แจงเหตุผล | โดยเร็ว ไม่เกิน 15 วันนับแต่ทราบเหตุ | ประกาศ สคส. เรื่องการแจ้งเหตุละเมิด พ.ศ. 2565 ตามความเห็นของ สคส. |
| การละเมิดมีความเสี่ยงสูงต่อสิทธิของบุคคล | เจ้าของข้อมูล พร้อมแนวทางเยียวยา | โดยไม่ชักช้า | PDPA มาตรา 37 (4) |
| หน่วยงาน CII เกิดเหตุภัยคุกคามไซเบอร์ที่มีนัยสำคัญ | สกมช. และหน่วยงานกำกับ | สกมช. ภายใน 24 ชั่วโมง ส่งข้อมูลเท่าที่มีก่อนได้ · หน่วยงานกำกับตามเวลาที่กำหนด | ประกาศ กกม. เรื่องการรายงานภัยคุกคามทางไซเบอร์ พ.ศ. 2566 |
สคส. อธิบายว่านาฬิกาเริ่มเดินเมื่อการตรวจสอบเบื้องต้นทำให้เชื่อได้ตามสมควรว่าเกิดการละเมิด และแจ้งเป็นระยะได้ หน้าที่ตาม PDPA ทั้งหมดดูที่PDPA กับการใช้ AI
แม่แบบแผนหกขั้น
- ตรวจพบและแจ้งภายใน ใครก็แจ้งได้ผ่านช่องทางเดียว และไม่ลงโทษผู้แจ้งเหตุที่ตัวเองทำพลาด
- ประเมินเบื้องต้น มีข้อมูลส่วนบุคคลเกี่ยวข้องไหม ระบบเป็น CII ไหม ถ้าใช่ เริ่มนับเวลาตามตารางด้านบน
- หยุดความเสียหาย ปิดสิทธิ์ของเอเจนต์ ถอนการเชื่อมต่อ หรือปิดระบบ AI ตามเกณฑ์ที่ตกลงไว้ล่วงหน้า NIST แนะนำให้มีแผนปิดระบบและเกณฑ์ที่ชัดว่าเมื่อไรต้องปิด
- แจ้งภายนอก สคส. สกมช. เจ้าของข้อมูล และผู้ให้บริการ AI ตามที่เกี่ยวข้อง
- แก้และกู้คืน แก้ต้นเหตุ เช่น จำกัดสิทธิ์ เพิ่มการกรองข้อมูลนำเข้า แล้วจึงเปิดระบบอีกครั้ง
- ทบทวนหลังเหตุ บันทึกทั้งเหตุที่เกิดและเหตุที่เกือบเกิด แล้วปรับนโยบายและการอบรม
ฟิลด์ขั้นต่ำของรายงานเหตุ
| ฟิลด์ | ตัวอย่างสิ่งที่กรอก |
|---|---|
| รหัสและชื่อระบบ | เอเจนต์ตอบคำถามลูกค้า ใช้ Claude ผ่าน API |
| ชื่อเหตุและผู้แจ้ง | เอเจนต์ส่งข้อมูลคำสั่งซื้อให้ลูกค้าผิดราย · แจ้งโดยทีมบริการลูกค้า |
| วันที่เกิดและวันที่ทราบ | วันที่และเวลา เพื่อนับ 72 ชั่วโมงและ 24 ชั่วโมง |
| ข้อมูลที่เกี่ยวข้อง | ประเภทข้อมูลและจำนวนรายการโดยประมาณ |
| คำอธิบายและผลกระทบ | เกิดอะไร กระทบใคร และกระทบอย่างไร |
| ผู้ได้รับผลกระทบ | ลูกค้า พนักงาน หรือคู่ค้า |
| การหยุดและการแก้ | ปิดอะไร เมื่อไร และแก้ต้นเหตุอย่างไร |
ช่องทางแจ้งผู้ให้บริการ AI
| ผู้ให้บริการ | ช่องโหว่ด้านความปลอดภัย | ปัญหาด้านความปลอดภัยของโมเดลหรือการใช้ในทางที่ผิด |
|---|---|---|
| Anthropic | แบบฟอร์มแจ้งช่องโหว่ตาม Responsible Disclosure Policy | usersafety@anthropic.com และแบบฟอร์มรายงานเนื้อหาของ Claude |
| Microsoft | MSRC Researcher Portal หมวด Copilot และ AI | MSRC หมวด AI derived harm และ Reporting Portal สำหรับการใช้บริการ AI ในทางที่ผิด |
| OpenAI | Trust Portal ซึ่งพาไปที่ bugcrowd.com/openai | ดูช่องทางล่าสุดในศูนย์ช่วยเหลือของ OpenAI |
| AI Vulnerability Reward Program ที่ bughunters.google.com | แจ้งผ่าน feedback ในผลิตภัณฑ์ |
เหตุไซเบอร์ทั่วไปแจ้ง ThaiCERT ได้ที่ 02-114-3531 ตลอด 24 ชั่วโมง
แหล่งอ้างอิง
- พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 ราชกิจจานุเบกษา
- เอกสารให้คำปรึกษา ฉบับที่ 46 สคส.
- ประกาศ กกม. เรื่องหลักเกณฑ์และวิธีการรายงานภัยคุกคามทางไซเบอร์ พ.ศ. 2566 ราชกิจจานุเบกษา
- NIST AI 600-1 Generative AI Profile NIST (ก.ค. 2024)
- Defining AI incidents OECD
- OWASP Top 10 for LLM Applications และ ประกาศฉบับ 2026 OWASP
- AI Security Gap ISACA (5 พ.ค. 2026)
- Responsible Disclosure Policy Anthropic, Trust Portal OpenAI และ ThaiCERT สกมช.
อ่านต่อ
ถ้ายังไม่มีนโยบาย AI ให้เริ่มที่นโยบาย AI สำหรับองค์กรไทย และถ้าพนักงานใช้เครื่องมือที่ไม่อนุมัติอยู่ดูShadow AI ในองค์กร