ความเสี่ยงที่ “ควรรับ” กับความเสี่ยงที่ “ไม่ควรแตะ”#

ก่อนจะไปถึง 4 ทางเลือก ขอวางกรอบความคิดให้ตรงกันก่อนครับ มาตรฐานสากลแยกความเสี่ยงออกเป็นสองกอง:

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

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

ภาพรวม 4 ทาง — แล้วเลือกทางไหนเมื่อไหร่#

ผมขอวางตารางสรุปของตัวเองไว้ตรงนี้ก่อน เป็นแผนที่ให้ทั้งครึ่งแรก แล้วค่อยลงรายละเอียดทีละทาง

ทีนี้คำถามที่ทุกคนถามคือ — “แล้วจะรู้ได้ยังไงว่าควรเลือกทางไหน?” วิธีคิดที่ผมว่าง่ายที่สุดคือมองสองแกน: โอกาสเกิด (probability) กับ ผลกระทบถ้าเกิด (impact) แล้ววางลงในตาราง 4 ช่อง

1
                  ผลกระทบต่ำ          ผลกระทบสูง
2
              ┌──────────────────┬──────────────────┐
3
 โอกาสเกิดสูง │       ลด          │      เลี่ยง        │
4
              │   (Mitigate)      │     (Avoid)       │
5
              ├──────────────────┼──────────────────┤
6
 โอกาสเกิดต่ำ │       รับ          │       โอน         │
7
              │    (Accept)       │  (Transfer/Share) │
8
              └──────────────────┴──────────────────┘

อ่านตารางนี้แบบเจ้าของกิจการครับ:

• โอกาสเกิดต่ำ + ผลกระทบต่ำ → รับ เกิดยาก เกิดแล้วก็ไม่เจ็บ จะลงทุนแก้ทำไม แค่จับตาไว้
• โอกาสเกิดสูง + ผลกระทบต่ำ → ลด เกิดบ่อยแต่ไม่หนัก ใส่การ์ดลดความถี่ลงได้ก็คุ้ม
• โอกาสเกิดสูง + ผลกระทบสูง → เลี่ยง เกิดบ่อยและเกิดทีเจ็บหนัก — แบบนี้อย่าไปเสี่ยง ถอยดีกว่า
• โอกาสเกิดต่ำ + ผลกระทบสูง → โอน เกิดยากแต่ถ้าเกิดทีคือหายนะ — แบบนี้ซื้อประกัน/แบ่งความรับผิดไว้ดีที่สุด

ผมอยากให้ดูตารางนี้เป็น “ตัวช่วยคิดตั้งต้น” นะครับ ไม่ใช่กฎตายตัว ของจริงมันมีบริบทเยอะกว่านี้ แต่มันช่วยให้เจ้าของจับทางถูกว่า “ความเสี่ยงตัวนี้ควรเอนไปทางไหน” ก่อนจะลงรายละเอียด ทีนี้เราเดินทีละทางเลยครับ

ทางที่ 1 — รับ (Accept): “อยู่กับมัน แต่ไม่ใช่ปล่อยทิ้ง”#

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

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

• การเฝ้าระวัง (monitoring) — ต้องวางวิธีติดตามตัวเลขไว้ ว่าความเสี่ยงนี้ยังอยู่ในเส้นที่เรารับได้ไหม หรือเริ่มขยับเกินเส้น เพื่อให้เรารู้ตัวก่อนมันบานปลาย
• การทบทวนเป็นระยะ (regular reviews) — ต้องกลับมาดูซ้ำตามรอบ ว่าความเสี่ยงที่เคย “รับได้” เมื่อปีก่อน วันนี้ยังรับได้อยู่ไหม เพราะโลกเปลี่ยน ข้อมูลเปลี่ยน ความเสี่ยงก็เปลี่ยน

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

สิ่งที่เปลี่ยนไปเมื่อเป็น AI: ความเสี่ยง AI หลายตัว “ขยับเองได้” โดยที่เราไม่ได้แตะอะไรเลย เพราะ AI เรียนรู้และเสื่อมตามเวลา (model drift) วันนี้ false positive 5% เดือนหน้าอาจกลายเป็น 12% เพราะพฤติกรรมลูกค้าเปลี่ยน นี่แหละคือเหตุผลที่การ “รับ” ความเสี่ยง AI ต้องผูกกับ monitoring ที่จริงจังกว่าความเสี่ยง IT ทั่วไป — เพราะตัวที่เรารับไว้ มันไม่อยู่นิ่ง

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

ทางที่ 2 — เลี่ยง (Avoid): “บางที ทางที่ฉลาดที่สุดคือไม่เริ่ม”#

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

จุดที่อยากให้เข้าใจ — การเลี่ยงไม่ใช่ความขี้ขลาด มันคือการตัดสินใจอย่างมีข้อมูล (informed decision) ครับ และมันมีราคาของมันเองที่เรียกว่า “ต้นทุนค่าเสียโอกาส” (opportunity loss) คือเราอาจพลาดประโยชน์ที่ AI ตัวนั้นจะให้ได้ ดังนั้นมันไม่ใช่การตัดสินใจที่ทำลอยๆ ต้องผ่านการประเมินอย่างละเอียดก่อนว่า “ประโยชน์ที่จะเสียไป กับอันตรายที่จะรับมา อันไหนหนักกว่า”

ตัวอย่างกับ AI (สมมติ): บริษัทข้ามชาติขนาดใหญ่แห่งหนึ่งกำลังคิดจะเอา AI มาคัดกรองและจัดอันดับผู้สมัครงานอัตโนมัติ ฟังดูดีมาก ประหยัดเวลา HR มหาศาล แต่พอประเมินลึกๆ พบว่า AI แบบนี้มีความเสี่ยงสูงมากที่จะ “เลือกปฏิบัติ” โดยไม่ตั้งใจ — เช่น เอนเอียงตามเพศ อายุ หรือเชื้อชาติที่ซ่อนอยู่ในข้อมูลเก่า ซึ่งถ้าเกิดขึ้นจริง = ค่าปรับ + ฟ้องร้อง + ชื่อเสียงพัง บริษัทจึงตัดสินใจ เลี่ยง ไม่เอา AI ตัวนี้มาใช้คัดคนเลย

สิ่งที่เปลี่ยนไปเมื่อเป็น AI: ตรงนี้กฎหมายเข้ามาช่วยตัดสินใจให้เราในบางกรณีครับ — EU AI Act (กฎหมาย AI ของสหภาพยุโรป ที่บังคับใช้กับใครก็ตามที่ระบบ AI ไปกระทบพลเมือง EU แม้บริษัทจะอยู่นอก EU) จัดความเสี่ยง AI เป็น 4 ระดับ และระดับบนสุดคือ “ความเสี่ยงที่ยอมรับไม่ได้” (unacceptable risk) เช่น ระบบให้คะแนนทางสังคม (social scoring) หรือระบบที่บิดเบือนพฤติกรรมคน — พวกนี้กฎหมายสั่ง “ห้ามใช้” ไปเลย พูดอีกแบบคือ บางความเสี่ยง AI ถูกบังคับให้ “เลี่ยง” โดยกฎหมาย ไม่ใช่ทางเลือกของเราด้วยซ้ำ การรู้ว่า use case ของเราตกอยู่ในระดับไหนของ EU AI Act จึงสำคัญมากสำหรับบริษัทที่มีลูกค้าหรือพนักงานในยุโรป

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

ทางที่ 3 — ลด (Mitigate): “ใช้ต่อได้ แต่ต้องใส่การ์ด”#

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

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

• แก้ที่ข้อมูลสอน (update training data) — ปรับข้อมูลที่ใช้สอนโมเดลให้สมดุลและเป็นตัวแทนของคนทุกกลุ่มอย่างเป็นธรรม
• ปรับตัวอัลกอริทึม (improve the algorithm) — ปรับพารามิเตอร์หรือใส่ตรรกะควบคุมความเป็นธรรม (fairness controls) เพื่อลดอคติ
• เพิ่มกลไกความปลอดภัย (add safety features) — บังคับให้มี คนคุมในวง (Human-in-the-Loop / HITL) สำหรับการตัดสินใจสำคัญ และตั้งสัญญาณเตือนเมื่อ AI ตัดสินใจหลุดจากรูปแบบปกติ

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

สิ่งที่เปลี่ยนไปเมื่อเป็น AI: การ์ดที่ทรงพลังที่สุดสำหรับ AI คือ “คน” ครับ — Human-in-the-Loop คือการบังคับให้มีคนเป็นด่านตัดสินใจสุดท้ายในเรื่องที่กระทบคนจริง นี่คือสิ่งที่ความเสี่ยง IT ทั่วไปไม่ค่อยต้องคิดมาก แต่กับ AI กลายเป็นหัวใจ เพราะ AI “ตอบผิดอย่างมั่นใจ” ได้ ถ้าไม่มีคนคั่นกลาง ความผิดพลาดเดียวจะถูกขยายเป็นพันเคสในพริบตา อีกประเด็นคือ การ “ลด” ความเสี่ยง AI มักไม่ใช่ทำครั้งเดียวจบ ต้องทำซ้ำเรื่อยๆ เพราะโมเดลเสื่อมและข้อมูลเปลี่ยน — การ์ดที่เคยพอเมื่อปีก่อน ปีนี้อาจไม่พอแล้ว

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

ทางที่ 4 — โอน (Transfer/Share): “แบ่งภาระให้คนอื่นช่วยแบก”#

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

วิธีโอนความเสี่ยงมีหลักๆ 3 แบบ:

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

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

ของจริง — 4 ทางนี้ไม่ได้เลือกแค่ทางเดียว#

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

เริ่มด้วย ลด (ใส่ HITL + ปรับข้อมูล) → จากนั้น รับ ความเสี่ยงที่เหลือ (residual risk) ที่ลดต่อไม่คุ้มแล้ว โดยตั้ง monitoring ไว้ → แล้ว โอน ส่วนที่เหลือบางก้อนไปให้ประกันรับ

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

และทั้งหมดนี้ควรถูกเขียนไว้เป็นเอกสารชัดเจน ฝังอยู่ในกลยุทธ์จัดการความเสี่ยงรวมของบริษัท ไม่ใช่อยู่แค่ในหัวใครคนใดคนหนึ่ง เพราะนี่คือสิ่งที่จะช่วยสร้างความเชื่อใจ (trust) ในระบบ AI ของเรา และแสดงให้เห็นว่าเราจริงจังกับหลักความปลอดภัย ความเป็นธรรม และความรับผิดชอบ — ซึ่งเป็นหัวใจของกรอบอย่าง EU AI Act และ NIST AI RMF (กรอบจัดการความเสี่ยง AI ของสถาบันมาตรฐานสหรัฐฯ ที่เป็นแบบสมัครใจ ไม่บังคับ) ที่เราคุยกันในตอนก่อนๆ

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

ทำไมต้อง “มองล่วงหน้า” ทั้งที่ยังไม่เกิดเหตุ#

ครึ่งแรกเราคุยกันว่า “เจอความเสี่ยงแล้วจะจัดการยังไง” แต่มีคำถามที่ลึกกว่าและมาก่อนนั้น — “แล้วเราจะ ‘เจอ’ ความเสี่ยงพวกนั้นได้ยังไง ในเมื่อมันยังไม่เกิด?”

นี่คือหน้าที่ของ การมองความเสี่ยงล่วงหน้า (threat modeling) ครับ กลับไปที่ภาพพนักงานใหม่ — เจ้าของที่เก๋าจะไม่รอให้พนักงานทำพลาดก่อนแล้วค่อยคิดว่าจะรับมือยังไง เขาจะนั่งคิดล่วงหน้าตั้งแต่วันแรกว่า “ตำแหน่งนี้ คนแบบไหนจะมาหลอกเขาได้ เขาจะเผลอทำอะไรเสียหายได้บ้าง ใครได้ประโยชน์ถ้าเขาพลาด” การคิดแบบนี้กับระบบ AI นี่แหละคือ threat modeling

threat modeling ทำสามอย่างหลักๆ:

1. วาดภาพย่อของระบบ — ทำให้เห็นว่าระบบ AI ของเรามีชิ้นส่วนอะไรบ้าง ข้อมูลไหลไปทางไหน
2. วาดโปรไฟล์คนร้าย — ใครจะมาโจมตี เป้าหมายเขาคืออะไร ใช้วิธีไหน เก่งแค่ไหน
3. ทำบัญชีรายการภัยที่เป็นไปได้ — รวบรวมว่ามีภัยอะไรบ้างที่อาจเกิดกับระบบนี้

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

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

จุดที่อยากย้ำอีกที — threat modeling ไม่ใช่งานหาตัวคนร้ายแบบสืบสวน (attribution) เราไม่ต้องรู้ว่าใครชื่ออะไรอยู่ที่ไหน เราแค่ต้องเข้าใจ “ประเภท” ของคนร้ายและวิธีของเขาให้พอจะวางการ์ดได้ถูกจุด และข่าวดีคือ การ์ดหนึ่งตัวมักกันได้หลายภัยพร้อมกัน — เช่น การ์ดที่กันแฮกเกอร์ระดับรัฐได้ ก็มักกันอาชญากรไซเบอร์ทั่วไปได้ด้วย ตรงนี้ควรจดไว้ใน threat model เพราะมันแปลว่าเราลงทุนการ์ดเดียวได้ผลหลายต่อ คุ้มมาก

มุมผู้บริหาร: threat modeling ไม่ใช่เรื่องของ “ทีมเทคนิคไปทำกันเอง” นะครับ ผลลัพธ์ของมันคือ บัญชีจัดลำดับว่าควรกลัวอะไรก่อน ซึ่งตรงนั้นเจ้าของต้องอยู่ในห้องด้วย เพราะ “อะไรคือทรัพย์สินที่มีค่าที่สุดที่เราต้องปกป้อง” เป็นคำถามทางธุรกิจ ไม่ใช่คำถามทางเทคนิค

เครื่องมือมองภัยมีหลายตัว — แต่ละตัวถนัดคนละแบบ#

ทีนี้ การจะ “มองภัยล่วงหน้า” อย่างเป็นระบบ เขามีวิธีการ (methods) เป็นแบบแผนให้เลือกใช้หลายตัว แต่ละตัวพัฒนามาจากคนละโจทย์ บางตัวมองภาพรวม บางตัวเน้นคน บางตัวเน้นความเป็นส่วนตัว ไม่มีตัวไหนสมบูรณ์แบบครอบคลุมทุกอย่าง ของจริงเขาเลยมัก ผสมหลายตัว เข้าด้วยกันเพื่อให้เห็นภัยรอบด้าน

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

อ่านตารางนี้แล้วน่าจะเห็นรูปแบบชัดเจนอย่างหนึ่ง — เครื่องมือเก่าทุกตัว (STRIDE, PASTA, LINDDUN, Trike, VAST, OCTAVE) ล้วนมีจุดอ่อนข้อเดียวกัน คือ “มองไม่เห็นภัยเฉพาะของ AI” เพราะมันถูกออกแบบมาในยุคที่ยังไม่มี AI agent ตัดสินใจเอง ยังไม่มีการวางยาข้อมูลสอนโมเดล ยังไม่มีการหลอกโมเดลด้วย input ที่แต่งมาเฉพาะ

นี่คือเหตุผลที่มีคนพยายามสร้างตัวใหม่อย่าง MAESTRO ขึ้นมาเพื่ออุดช่องนี้โดยเฉพาะ — มันถูกออกแบบมาให้คิดถึงโลกที่ AI หลายตัวทำงานร่วมกัน ตัดสินใจเองได้ และอาจถูกหลอกด้วยวิธีที่ระบบเก่าไม่เคยเจอ แต่ก็ต้องเข้าใจว่ามันยังใหม่และกำลังพัฒนาอยู่ ยังไม่นิ่งเท่าของเก่า

เจ้าของกิจการควรเอาเรื่องนี้ไปใช้ยังไง (โดยไม่ต้องเป็นเทคนิค)#

ผมเข้าใจว่าตารางข้างบนดูเป็นเรื่องของทีมเทคนิคมาก แต่ในมุมเจ้าของกิจการ ผมสรุปสิ่งที่ต้องเอาไปใช้จริงเหลือแค่ไม่กี่ข้อครับ:

ข้อแรก — อย่าเชื่อใจ threat model เก่าที่ทำก่อนมี AI ถ้าบริษัทเคยทำ threat modeling ด้วย STRIDE หรือตัวอื่นไว้ตั้งแต่ก่อนเอา AI เข้ามา ของเดิมนั้น “มองไม่เห็น” ภัยใหม่ของ AI เลย ต้องรื้อมาเติมมุม AI โดยเฉพาะ — เช่น “ถ้ามีคนวางยาข้อมูลที่เราใช้สอนโมเดลล่ะ?” “ถ้ามีคนแต่ง input มาหลอกให้ AI ตัดสินใจผิดล่ะ?” คำถามพวกนี้ระบบเก่าไม่ได้ถาม

ข้อสอง — ผสมเครื่องมือ อย่ายึดตัวเดียว ถ้าธุรกิจเราเสี่ยงเรื่องข้อมูลส่วนบุคคลหนัก ควรเอามุม privacy ของ LINDDUN มาผสม ถ้าเราอยากจัดลำดับภัยตามผลกระทบธุรกิจ เอา PASTA มาช่วย ถ้าเราใช้ AI agent ที่ตัดสินใจเอง ต้องเริ่มมองมุมของ MAESTRO ไม่มีตัวไหนตัวเดียวจบ

ข้อสาม — ต้องเติมมุมที่ระบบเทคนิคมักลืม ตำราย้ำเรื่องนี้และผมเห็นด้วยมาก — threat modeling แบบเดิมมักลืมเรื่อง จริยธรรม ความเป็นส่วนตัว และสิทธิมนุษยชน ซึ่งไม่ใช่ภัยทางเทคนิคแต่เป็นภัยที่ทำบริษัทพังได้พอกัน เจ้าของต้องเป็นคนผลักให้สามเรื่องนี้เข้าไปอยู่ในการมองภัยด้วย เพราะทีมเทคนิคมักโฟกัสแต่เรื่องระบบล่ม/ข้อมูลรั่ว

ข้อสี่ — เดี๋ยวนี้ AI ช่วยทำ threat modeling ได้ มีเครื่องมือที่เอา AI มาช่วยสร้างสถานการณ์ภัยตามกรอบมาตรฐาน (เช่นตัวที่ชื่อ STRIDE GPT หรือ IriusRisk) ซึ่งช่วยทุ่นแรงทีมได้ แต่ — ย้ำเหมือนเดิมทั้งซีรีส์ — AI ช่วยร่างได้ แต่คนต้องเป็นคนตัดสินใจสุดท้าย ว่าภัยไหนจริง ภัยไหนสำคัญ อย่าให้ AI มาบอกเราว่าควรกลัวอะไร ในเมื่อตัว AI เองนั่นแหละคือสิ่งที่เรากำลังพยายามมองภัย

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

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

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

อย่างแรก — ทุกความเสี่ยง AI ต้องมีคำเดียวกำกับว่าเราเลือกทางไหน รับ (อยู่กับมัน + เฝ้าดู) / เลี่ยง (ไม่เอาเลย) / ลด (ใส่การ์ด) / โอน (แบ่งภาระให้คนอื่นแบก) ถ้าเขียนคำกำกับไม่ออก แปลว่ายังไม่เคยตัดสินใจจริง

อย่างที่สอง — ตัดสินใจง่ายขึ้นด้วยสองแกน: โอกาสเกิด × ผลกระทบ เกิดยากเจ็บน้อย=รับ / เกิดบ่อยเจ็บน้อย=ลด / เกิดบ่อยเจ็บหนัก=เลี่ยง / เกิดยากเจ็บหนัก=โอน และของจริงมักผสมหลายทาง (ลดก่อน → รับส่วนที่เหลือ → โอนบางก้อน)

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

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

ถ้าจะสรุปแบบที่เจ้าของกิจการน่าจะพยักหน้าตาม — “กับพนักงาน AI เก่งๆ ของเรา เราต้องทำสองอย่างเสมอ: คิดล่วงหน้าว่าเขาจะพลาดตรงไหนได้ (threat modeling) แล้วตัดสินใจไว้ก่อนว่าถ้าเขาพลาดจริง เราจะรับ-เลี่ยง-ลด-หรือโอน (risk response) — และทั้งสองอย่างนี้เราต้องเป็นคนตัดสินใจเอง ไม่ใช่ยกให้คนอื่นคิดแทน” นั่นแหละครับคือหัวใจของการเป็นเจ้าของความเสี่ยง AI ตัวจริง

ตอนหน้าเราจะเจาะลึกขึ้นไปอีกขั้น — จากการ “มองภัยแบบกว้างๆ” ไปสู่การดู ภูมิทัศน์ภัยของ AI (AI threat landscape) ว่าจริงๆ แล้วภัยที่จ้องระบบ AI ของเราหน้าตาเป็นยังไงบ้างแบบเจาะลึก แล้วเราจะวางกลยุทธ์ลดภัย (mitigation) ทีละเรื่องยังไง ไว้เจอกันครับ

อ้างอิงเนื้อหา: AAISM — Domain 2: Section 2.5 (AI Risk Response Strategies: Accept / Avoid / Mitigate / Transfer-Share), 2.6 (AI Threat Modeling) แหล่งสาธารณะที่อ้างถึงโดยตรง: NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023 (ฟังก์ชัน Govern/Map/Measure/Manage) · EU Artificial Intelligence Act (การจัดระดับความเสี่ยง 4 ขั้น) · OWASP Top 10 for LLM Applications · MITRE ATLAS (ภัยฝั่ง adversarial machine learning) · กรอบ threat modeling สาธารณะ: STRIDE, PASTA, LINDDUN, Trike, VAST, OCTAVE · MAESTRO — K. Huang, “Agentic AI Threat Modeling Framework: MAESTRO,” Cloud Security Alliance, 2025