ตั้งหลักก่อน — AI ก็คือพนักงานใหม่ที่อาจทำพังได้#

ทั้งซีรีส์นี้ผมชวนมองว่า AI = พนักงานใหม่เก่งสุดๆ คนหนึ่งที่เราต้องกำกับ ไม่ใช่เครื่องจักรวิเศษที่เปิดแล้วลืมได้

ทีนี้ลองคิดต่อครับ พนักงานเก่งแค่ไหนก็มีวันทำพลาด แล้วพอเป็นพนักงานที่ “ทำงานเร็วมากและทำพร้อมกันเป็นพันงาน” เวลาพลาดที มันก็พลาดเป็นพันงานในพริบตา นี่แหละคือเหตุผลที่การรับมือเหตุของ AI ไม่เหมือนการรับมือเหตุไอทีทั่วไป

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

1
        เตรียมพร้อม (Prepare)
2
              ↓
3
     รู้ตัว + แจ้งเหตุ (Identify & Report)
4
              ↓
5
        ประเมิน (Assess)
6
              ↓
7
       รับมือ (Respond) ── ปิดกั้น → กำจัด → กู้คืน
8
              ↓
9
   ทบทวนหลังเหตุ (Postincident Review)
10
              ↓
11
        (วนกลับไปเตรียมพร้อมที่ดีขึ้น)

โครงนี้หน้าตาเหมือนการรับมือเหตุไซเบอร์ทั่วไปที่หลายคนคุ้นอยู่แล้ว (และผมแนะนำให้ไปอ่านตอน CyberSec EP.46 ถ้ายังไม่แม่น) แต่พอตัวที่ก่อเรื่องเป็น AI ทุกขั้นมันมีจุดที่ “ยากกว่าเดิม” ซ่อนอยู่ ตอนนี้เราจะเดินไปทีละขั้น แล้วชี้ว่าตรงไหนคือสิ่งที่เจ้าของกิจการต้องตัดสินใจหรือออกแบบไว้ล่วงหน้า

ก่อนเริ่ม ขอแยกให้เห็นภาพก่อนว่า “เหตุของ AI” หน้าตาเป็นยังไง เพราะมันไม่ใช่แค่ “ระบบล่ม” แบบที่เราคุ้น

ขั้นที่ 1 — เตรียมพร้อม (Prepare): งานที่ต้องทำ “ตอนยังไม่เกิดเรื่อง”#

ข้อแรกที่อยากย้ำกับเจ้าของกิจการ — การเตรียมพร้อมคือขั้นที่คุ้มค่าที่สุด เพราะมันเป็นขั้นเดียวที่เราทำได้ตอนหัวยังเย็น ไม่มีไฟลนก้น พอเกิดเรื่องจริงทุกอย่างจะวุ่นวายเกินกว่าจะมานั่งคิดว่า “เอ๊ะ ใครควรรับเรื่องนะ”

หลายบริษัทมี “แผนรับมือเหตุ” (Incident Response Plan) อยู่แล้วสำหรับเรื่องไอทีทั่วไป — แต่ปัญหาคือ เกือบทุกที่ยังไม่ได้ปรับแผนนั้นให้รองรับเหตุที่เกิดจาก AI โดยเฉพาะ เหตุ AI มีความเสี่ยงเพิ่มเข้ามาที่แผนเดิมไม่ครอบคลุม เช่น

• AI สร้างผลลัพธ์ที่ทำร้ายสังคม/ลูกค้า (เช่น ตอบข้อมูลผิดจนคนเสียหาย)
• ข้อมูลลับหรือข้อมูลส่วนบุคคลรั่วออกมาจาก “ชุดข้อมูลที่ใช้สอน AI”
• AI ทำนายผิด มโน (hallucinate) หรือเอนเอียงจนตัดสินใจผิดพลาด

แผนที่ “พร้อมรับมือ AI” ต้องคิดเผื่อความเสี่ยงเพิ่มเติมพวกนี้ และเผื่อผลกระทบต่อ “ตัวคน” ด้วย ไม่ใช่แค่ผลกระทบต่อระบบ

ขั้นเตรียมพร้อมมี 3 ชิ้นที่เจ้าของต้องวางไว้ก่อน:

ขั้นที่ 2 — รู้ตัว + แจ้งเหตุ (Identify & Report): ขั้นที่ AI ทำให้ “ยากกว่าเดิม”#

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

AI ทำงานบนความน่าจะเป็น (probability) — มันถูกออกแบบมาให้ “ผิดได้บ้าง” ฟังดูแปลกแต่จริง ผู้สร้าง AI ไม่ได้ตั้งใจทำให้มัน “แม่น 100%” เพราะโมเดลที่แม่นเป๊ะกับข้อมูลเก่าเกินไป (เรียกว่า overfit) จะใช้กับข้อมูลใหม่ไม่ได้เลย พูดง่ายๆ คือ AI ที่ดี = AI ที่ “ผิดบ้างเป็นเรื่องปกติ”

ทีนี้ปัญหาคือ — ถ้า AI ผิดได้เป็นปกติ แล้วเราจะรู้ได้ยังไงว่าตอนไหน “ผิดแบบปกติ” กับตอนไหน “ผิดเพราะถูกโจมตี/เกิดเหตุ”?

นี่คือคำถามที่เจ้าของกิจการต้องช่วยทีมตอบ และคำตอบคือต้อง ตั้งเส้นแบ่ง (threshold) ไว้ล่วงหน้า ว่า “ผิดเกินระดับไหน ถึงนับเป็นเหตุที่ต้องรับมือ” — เช่น chatbot ตอบผิด 1 ใน 1,000 ครั้งอาจถือว่าปกติ แต่ถ้าจู่ๆ ตอบผิดพุ่งเป็น 1 ใน 10 ภายในชั่วโมงเดียว นั่นแหละสัญญาณว่ามีเหตุ

ขั้นที่ 3 — ประเมิน (Assess): เก็บข้อเท็จจริงให้ครบ เร็ว แต่ไม่ทำลายหลักฐาน#

พอรู้ว่าเกิดเหตุแล้ว ขั้นต่อไปคือ เก็บข้อเท็จจริง เพื่อปะติดปะต่อว่า เกิดเมื่อไหร่ ขอบเขตแค่ไหน กระทบอะไรบ้าง — ขั้นนี้ต้องทำให้เร็วที่สุด แต่ระวังอย่าทำพังหลักฐานระหว่างทาง (เช่น อย่าเพิ่งลบ log อย่าเพิ่งล้างข้อมูลก่อนเก็บสำเนาไว้)

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

ชุดคำถามที่ต้องตอบให้ได้ในขั้นนี้:

• เหตุหยุดแล้วหรือยังเกิดอยู่? (chatbot ยังตอบผิดอยู่ไหม หรือเราปิดไปแล้ว)
• ข้อเท็จจริงคืออะไร?
  • ใครได้รับผลกระทบ และเกิดความเสียหาย/ผลเสียอะไร? (ลูกค้ากี่ราย เสียเงินไหม เสียชื่อเสียงแค่ไหน)
  • รู้เรื่องเมื่อไหร่? — ข้อนี้สำคัญมากเพราะ กฎหมายหลายฉบับนับเวลาแจ้งเหตุจากวันที่ “รู้” (เช่น ต้องแจ้งภายในกี่ชั่วโมง/วัน) ถ้าจดเวลาผิด อาจกลายเป็นเรื่องผิดกฎหมายซ้อนเข้าไปอีก
  • เกิดอะไรขึ้นกันแน่? (รายละเอียดของเหตุ)
  • AI ตัวไหนและข้อมูลชุดไหนโดนกระทบ?
  • ผู้โจมตีใช้วิธีอะไร?
• อะไรที่ยังไม่รู้ และต้องรู้อะไรเพิ่มถึงจะกลับมาทำงานได้อย่างปลอดภัย?

มุมผู้บริหาร: ในขั้นนี้คำถามที่ผู้บริหารต้องถามดังๆ คือ “เรารู้เรื่องนี้ตั้งแต่เมื่อไหร่ และมีข้อมูลส่วนบุคคลของลูกค้าเกี่ยวข้องไหม?” เพราะสองอย่างนี้เป็นตัวตัดสินว่าเราต้อง “แจ้งใครภายในเมื่อไหร่ตามกฎหมาย” (โยงกับ PDPA และกฎหมาย AI ที่เล่าในตอนก่อนๆ) ถ้าตอบช้าหรือตอบผิด ความเสียหายทางกฎหมายอาจหนักกว่าตัวเหตุเองเสียอีก

ขั้นที่ 4 — รับมือ (Respond): ปิดกั้น → กำจัด → กู้คืน#

ขั้นนี้คือขั้น “ลงมือดับไฟ” แบ่งเป็น 3 จังหวะที่คนทำไอทีคุ้นกันดี — ปิดกั้น (containment), กำจัด (eradication), กู้คืน (recovery) ตรรกะเดิมยังใช้ได้ครับ แต่กับ AI มันได้ผลน้อยลงและยากขึ้น เพราะ AI ซับซ้อนและทำงานบนความน่าจะเป็น ไม่ใช่ตรรกะตายตัวแบบซอฟต์แวร์ธรรมดา

ขั้นที่ 5 — ทบทวนหลังเหตุ (Postincident Review): เปลี่ยนจาก “ตั้งรับ” เป็น “เตรียมรุก”#

พอไฟดับแล้ว ห้ามจบแค่นั้นครับ ขั้นสุดท้ายคือนั่งลงทบทวนว่า “เกิดอะไรขึ้น เราพลาดตรงไหน คราวหน้าทำดีกว่านี้ได้ยังไง” — เป้าหมายคือขยับจากท่า “รอให้เกิดแล้วค่อยแก้” (reactive) ไปสู่ “เตรียมพร้อมไว้ก่อน” (proactive)

สิ่งที่ควรทบทวนหลังเหตุ AI โดยเฉพาะ:

• การเตรียมข้อมูล (data preprocessing) — มีรูรั่วให้ข้อมูลเสียเข้ามาได้ตรงไหน
• การ์ดความปลอดภัย ที่มี เพียงพอไหม
• การทดสอบเชิงรุก (adversarial testing) — เราลองโจมตี AI ตัวเองมากพอไหม ก่อนปล่อยใช้
• การควบคุมข้อมูลเข้า-ออก ของ AI
• ความเป็นธรรมของผลลัพธ์ — เหตุนี้เผยอคติอะไรซ่อนอยู่ไหม
• สภาพแวดล้อมการควบคุมของผู้ให้บริการ AI — ถ้าเราใช้ AI ของเจ้าอื่น เหตุนี้เผยว่า vendor หละหลวมตรงไหน

มุมผู้บริหาร: คำถามปิดท้ายที่ผู้บริหารควรถามในห้องทบทวนคือ “ถ้าเหตุนี้เกิดซ้ำพรุ่งนี้ เราจะรับมือได้ดีกว่าเดิมจริงไหม — และถ้าไม่ ขาดอะไร?” แล้วเอาคำตอบนั้นกลับไปอัปเดต “ขั้นเตรียมพร้อม” ให้วงจรมันหมุนกลับไปแข็งแรงขึ้น นี่แหละความหมายของลูกศรที่วนกลับในแผนภาพต้นตอน

อีกด้านของเหรียญ — เมื่อ AI กลายเป็น “ผู้ช่วยดับไฟ” เสียเอง#

ที่ผ่านมาเราพูดถึง AI ในฐานะ “ตัวก่อเหตุ” แต่มีอีกมุมที่เจ้าของกิจการควรรู้ — AI เอามาช่วย “รับมือเหตุ” ได้ด้วย (AI-Powered Incident Response) คือเอา AI มาช่วยทีมความปลอดภัยตรวจจับ วิเคราะห์ และตอบสนองเหตุได้เร็วขึ้น

ลองเทียบการรับมือเหตุแบบเดิม (คนทำมือ) กับแบบมี AI ช่วย:

AI ช่วยงานรับมือเหตุได้ผ่านความสามารถพวกนี้ — รวบและจัดระเบียบข้อมูลจากหลายแหล่ง (data ingestion & normalization), ตรวจจับความผิดปกติ (anomaly detection), เชื่อมโยงเหตุการณ์เพื่อจับการโจมตีหลายขั้น (event correlation), คัดกรองเหตุอัตโนมัติ (triage), หาสาเหตุต้นตอเร็วขึ้น, สั่งตอบสนองอัตโนมัติ (เช่น ตัดระบบที่ติดเชื้อ บล็อก IP ร้าย), และเรียนรู้จากเหตุเดิมเพื่อเก่งขึ้นเรื่อยๆ

เชื่อมกับเรื่องใหญ่ — ความต่อเนื่องของธุรกิจ (Business Continuity)#

ตลอดตอนนี้มีคำถามหนึ่งวนอยู่ในหัวเจ้าของตลอด — “แล้วระหว่างที่ AI ปิดอยู่ ธุรกิจฉันจะเป็นยังไง?”

นี่คือจุดที่การรับมือเหตุ AI ต้องไปจับมือกับ แผนความต่อเนื่องธุรกิจ (BCP) และแผนกู้คืนจากภัยพิบัติ (DRP) — พื้นฐานสองเรื่องนี้ผมเล่าไว้ละเอียดแล้วใน CISA D4.40 — BCP/DRP/RPO/RTO ตอนนี้ขอชี้เฉพาะมุมที่เป็นของ AI:

จำกับดักจากขั้น “ปิดกั้น” ได้ไหมครับ — บางทีปิดเฉพาะส่วนไม่ได้ ต้องปิดทั้งตัว AI พอ AI เป็นหัวใจของงานบางอย่าง (เช่น chatbot รับออเดอร์, AI คัดกรองคำขอ) การปิดมันก็เท่ากับ “งานส่วนนั้นหยุด” คำถามที่เจ้าของต้องตอบไว้ล่วงหน้าจึงเป็น:

• ถ้า AI ตัวนี้ต้องปิดกะทันหันหลายชั่วโมง/หลายวัน เรามี “แผนสำรองแบบใช้คนทำแทน” ไหม? — เช่น chatbot ล่ม มีทีมคนตอบลูกค้าสำรองไหม
• เรายอมให้บริการส่วนที่พึ่ง AI หยุดได้นานแค่ไหน ก่อนธุรกิจเจ็บหนัก? (นี่คือแนวคิด RTO ที่เล่าในตอนนั้น)
• ถ้าต้องย้อนโมเดล/ข้อมูลกลับไปเวอร์ชันก่อนถูกวางยา เราเก็บสำรองเวอร์ชันสะอาดไว้ไหม และย้อนได้เร็วแค่ไหน? (นี่คือแนวคิด backup + RPO ในเวอร์ชัน AI)

มุมผู้บริหาร: หัวใจของ business continuity สำหรับ AI สรุปเป็นประโยคเดียว — “อย่าให้ธุรกิจพึ่ง AI จนถ้ามันล้มแล้วเราล้มตาม” เรื่องไหนที่ AI ทำแล้วถ้าหยุดเท่ากับธุรกิจหยุด ต้องมีแผนสำรอง (คนทำแทน / โมเดลสำรอง / เวอร์ชันสะอาดให้ย้อนกลับ) เสมอ มองง่ายๆ เหมือนพนักงานเก่งที่สุดในทีม — ต่อให้เก่งแค่ไหน เราก็ไม่ควรให้ทั้งบริษัทพังถ้าเขาลาออกกะทันหันใช่ไหมครับ AI ก็เหมือนกัน

สรุปสั้นๆ ให้ตัวเองจำได้#

อ่านมาถึงตรงนี้ ขอจดกันลืมไว้สี่อย่างครับ

อย่างแรก — เหตุ AI ไม่ดับไฟแดงเตือน มันไม่ “ล่ม” แต่ “ตอบผิดอย่างมั่นใจ” เพราะ AI ผิดได้เป็นปกติอยู่แล้ว เราจึงต้องตั้งเส้นแบ่งและวัด baseline ไว้ ถึงจะรู้ว่าตอนไหน “ผิดปกติจริง”

อย่างที่สอง — เตรียมตอนหัวเย็นคุ้มที่สุด ระบุทีม (รวมคนข้อมูล/privacy/จริยธรรม ไม่ใช่แค่ IT), เขียนแผนสื่อสาร, เก็บเอกสารกำกับโมเดล และซ้อมแบบเฉพาะของ AI ไว้ก่อนเกิดเหตุ

อย่างที่สาม — เหตุ AI มักไม่มีปุ่ม “แก้แล้วจบ” containment/eradication/recovery ใช้ได้แต่ยากและแพงกว่าเดิม บางเหตุกำจัดไม่หมด ต้องใส่การ์ดรอบๆ + เฝ้าระวังต่อเนื่องแทน และอย่ารีบเปิด AI กลับมาก่อนทดสอบการ์ดใหม่และได้อนุมัติครบ

อย่างที่สี่ — AI เป็นได้ทั้งคนก่อเหตุและคนดับไฟ เอามาช่วยรับมือเหตุได้ (เร็ว ประหยัดคน) แต่ต้องมีคนคุม เริ่มจากให้มัน “แนะนำ” ก่อนค่อยให้ “ทำเอง” และอย่าลืมผูกทุกอย่างเข้ากับแผนความต่อเนื่องธุรกิจ — อย่าให้ธุรกิจพึ่ง AI จนล้มตามมันได้

ถ้าจะสรุปแบบที่เจ้าของกิจการน่าจะพยักหน้าตาม — “AI ก็เหมือนพนักงานเก่งที่สุดในทีม วันที่เขาทำพลาด เราต้องรู้ก่อน หยุดความเสียหายได้ และมีคนทำแทนได้ ถ้าวางสามอย่างนี้ไว้ ก็ไม่ต้องกลัววันที่เขาพลาด” นั่นแหละครับคือหัวใจของการรับมือเหตุ AI ในมุมคนบริหาร

ตอนหน้าเราจะปิดท้าย Domain 1 ด้วยการมองภาพรวมทั้งหมดที่ผ่านมา — เอาทุกชิ้นส่วนที่เล่ามาตั้งแต่ governance, นโยบาย, ความเสี่ยง, ไปจนถึงการรับมือเหตุ มาร้อยให้เห็นว่า “โปรแกรมความปลอดภัย AI ทั้งระบบ” ในมือเจ้าของกิจการหน้าตาเป็นยังไง ไว้เจอกันครับ

อ้างอิงเนื้อหา: AAISM — Domain 1: Section 1.16 (Prepare), 1.17 (Identify and Report), 1.18 (Assess), 1.19 (Respond), 1.20 (Postincident Review), 1.21 (Traditional vs. AI-Powered Incident Response) แหล่งสาธารณะที่อ้างถึงโดยตรง: ISO/IEC 27035-1:2023 (กระบวนการจัดการเหตุความมั่นคงปลอดภัยสารสนเทศ) · EU Artificial Intelligence Act · GDPR · พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA)