1.1 จัดกลุ่มแบบหยาบ — โมเดล 4 ระดับ (แรงบันดาลใจจาก EU AI Act)#

วิธีที่ง่ายที่สุดในการเริ่ม คือจัดกลุ่ม AI เป็น “ระดับ” ตามว่ามันกระทบคนได้แรงแค่ไหน กฎหมาย EU AI Act ของยุโรปเขาวางเกณฑ์นี้ไว้ชัดเจน และเป็นโมเดลที่บริษัททั่วโลกหยิบมาใช้เป็นจุดตั้งต้นได้ดี เพราะมันให้ “ภาษากลาง” ที่ทั้งฝ่ายธุรกิจและฝ่ายเทคนิคเข้าใจตรงกันว่า AI ตัวไหนต้องคุมเข้ม ตัวไหนปล่อยได้

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

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

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

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

1.2 จัดระดับแบบตีเป็นเงิน — FAIR-AIR 5 ขั้น#

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

ตรงนี้แหละที่มีกรอบคิดชื่อ FAIR-AIR เข้ามาช่วย มันคือการเอาวิธีคิดความเสี่ยงแบบ FAIR (ที่ตีความเสี่ยงออกมาเป็น “ตัวเงิน”) มาปรับใช้กับความเสี่ยงของ AI โดยเฉพาะ ประโยชน์ใหญ่สุดคือ มันแปลความเสี่ยงของ AI ให้กลายเป็นภาษาที่ผู้บริหารและบอร์ดเข้าใจทันที นั่นคือ “เงิน” ไม่ใช่ศัพท์เทคนิคที่คนนอกฟังไม่รู้เรื่อง

FAIR-AIR เดินเป็น 5 ขั้นต่อเนื่องกัน ผมขอเล่าด้วยภาษาคน พร้อมตัวอย่างสมมติร้อยตลอด เพื่อให้เห็นว่าแต่ละขั้นเจ้าของต้องตอบอะไร:

1
  1. ตั้งบริบท   →   2. ตีกรอบ   →   3. ตีเป็นเงิน   →   4. จัดลำดับ+รับมือ   →   5. ตัดสินใจ
2
  (Contextualize)   (Scope)        (Quantify)         (Prioritize/Treat)        (Decision)
3
   ถามทำไม          เลือกจุดที่      คิดว่าเสียได้        เรียงตัวไหนก่อน          เอาเงินไป
4
   ทำเพื่อใคร        สำคัญสุดมาดู     กี่บาท              + จะทำยังไง             ลงตรงไหนคุ้มสุด

มาดูทีละขั้น โดยสมมติว่าเรากำลังประเมิน AI อนุมัติวงเงินสินเชื่อหน้าร้านของเจ้าของกิจการคนนั้น:

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

ขั้นที่ 2 — ตีกรอบ (Scope): เลือก “จุดที่สำคัญที่สุด” มาดูก่อน AI ตัวหนึ่งมีจุดเสี่ยงได้ร้อยจุด ถ้าจะดูหมดคงไม่จบ ขั้นนี้คือเลือกว่า “อะไรคือสิ่งที่เราต้องปกป้องที่สุด” (ข้อมูลลูกค้า? ความเป็นธรรมในการอนุมัติ? ชื่อเสียงบริษัท?) แล้วดูว่า “ภัยที่จะมากระทบสิ่งนั้นคืออะไร” จากนั้นถึงสร้างเป็น สถานการณ์ความเสี่ยง (risk scenario) ที่ชัดเจน เช่น “AI อนุมัติเอนเอียงต่อลูกค้าบางกลุ่มจากข้อมูลเทรนที่ไม่สมดุล จนเกิดการเลือกปฏิบัติ”

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

ขั้นที่ 4 — จัดลำดับ + วางแผนรับมือ (Prioritize/Treat): “ตัวไหนทำก่อน” พอทุกสถานการณ์มีตัวเลขเงินแล้ว เอามาเรียงได้เลยว่าตัวไหนเสี่ยงเป็นเงินมากสุด ควรทำก่อน ขั้นนี้ยังช่วยมองออกว่า “อะไรคือตัวขับความเสี่ยงหลัก” ของแต่ละสถานการณ์ ถ้าตัวขับคือ “ข้อมูลเทรนไม่สมดุล” การรับมือก็ต้องไปแก้ที่ข้อมูล ไม่ใช่ไปซื้อประกัน

ขั้นที่ 5 — ตัดสินใจ (Decision Making): “เอาเงินไปลงตรงไหนคุ้มสุด” ขั้นสุดท้าย เจ้าของ/บอร์ดเอาภาพทั้งหมดมาตัดสินใจว่า จะลงทุนคุมความเสี่ยงตรงไหนถึงจะให้ผลตอบแทนคุ้มสุด — เพราะงบมีจำกัด เราต้องเลือกใช้กับจุดที่ลดความเสี่ยง (ที่ตีเป็นเงินแล้ว) ได้มากที่สุดต่อบาทที่จ่าย

จุดที่ทำให้ FAIR-AIR ทรงพลังในมือเจ้าของกิจการ คือมันเปลี่ยนบทสนทนาจาก “ทีมเทคนิคบอกว่า AI ตัวนี้เสี่ยง” (ซึ่งฟังแล้วก็ได้แต่พยักหน้า) เป็น “สถานการณ์เสี่ยงตัวนี้ ถ้าเกิด เราเสียประมาณ X ล้านบาทต่อปี และลงทุนคุม Y บาทลดได้ครึ่งหนึ่ง” แบบหลังนี่แหละตัดสินใจได้

ขอเทียบสองแนวทางให้เห็นชัดว่าใช้ตอนไหนดี:

ในทางปฏิบัติ บริษัทส่วนใหญ่ ใช้ทั้งคู่ — เริ่มด้วย 4 ระดับเพื่อคัดว่าตัวไหน “น่าเป็นห่วง” แล้วเอาเฉพาะตัวที่ตกช่องเสี่ยงสูงไปทำ FAIR-AIR ต่อเพื่อตีเป็นเงิน ไม่ต้องลงแรง quantify กับ spam filter

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

2.1 FRIA — ประเมินว่า AI จะไปลิดรอนสิทธิคนไหม#

FRIA (Fundamental Rights Impact Assessment) คือการประเมินก่อนเอา AI เสี่ยงสูงไปใช้ ว่ามันจะไป “กระทบสิทธิขั้นพื้นฐาน” ของคนหรือเปล่า กฎ EU AI Act บังคับให้ทำกับ AI เสี่ยงสูง โดยเฉพาะที่ใช้โดยหน่วยงานรัฐหรือเอกชนที่ให้บริการสาธารณะ

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

กระบวนการ FRIA ในภาษาคน คือการตอบ 6 คำถามนี้ให้ครบก่อนเปิดใช้ AI:

มีสองจุดที่เจ้าของต้องจำ:

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

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

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

2.2 Conformity Assessment — ตรวจว่า AI สร้างมาถูกหลักไหม#

Conformity Assessment (การตรวจความสอดคล้อง) คือการพิสูจน์ว่า AI สร้างและทำงาน ตรงตามกฎ/มาตรฐานที่กำหนด EU AI Act (มาตรา 43) บังคับให้ทำกับ AI เสี่ยงสูงทุกตัว และต้องทำใหม่ทุกครั้งที่มี “การแก้ไขใหญ่”

วิธีคิดง่ายๆ คือ Conformity Assessment เหมือน “การตรวจสภาพรถก่อนวิ่งบนถนน” มันตรวจว่ารถคันนี้สร้างมาตามมาตรฐานความปลอดภัย เอกสารครบ มีระบบดูแลคุณภาพ ก่อนจะปล่อยให้วิ่งจริง ของ AI ก็เหมือนกัน ตรวจสองอย่างหลัก:

1. ระบบบริหารคุณภาพ ของผู้สร้าง (เขามีกระบวนการที่น่าเชื่อถือไหม)
2. เอกสารเทคนิค (ออกแบบยังไง ทดสอบยังไง ผลเป็นไง)

มันตรวจได้สองทาง คือ ผู้สร้างตรวจตัวเอง (self-assessment) หรือ ให้ผู้เชี่ยวชาญอิสระจากข้างนอกมาตรวจ ขึ้นกับว่าเป็น AI ประเภทไหนและใช้มาตรฐานอะไร

ประเด็นที่อยากให้เจ้าของกิจการสังเกต ในมุม EU AI Act ภาระนี้ตกที่ “ผู้สร้าง AI” (provider) ไม่ใช่ “ผู้เอาไปใช้” (เรา/deployer) แต่ถ้าเราซื้อ AI สำเร็จมาใช้ เรื่องนี้แปลว่า เราต้องถาม vendor ว่า “AI ตัวนี้ผ่าน conformity assessment แล้วหรือยัง ขอดูหลักฐานหน่อย” เพราะถ้า vendor ทำไม่ครบ แล้วเราเอามาใช้จนเกิดเรื่อง เราก็เดือดร้อนด้วย

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

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

2.3 PIA — ประเมินว่าข้อมูลส่วนบุคคลปลอดภัยไหม#

PIA (Privacy Impact Assessment) คือการวิเคราะห์ว่า ข้อมูลส่วนบุคคล ถูก เก็บ / ใช้ / แบ่งปัน / ดูแลรักษา อย่างไรในขอบเขตที่เรากำหนด เป็นกระบวนการที่มีแบบแผนเพื่อหา “ความเสี่ยงต่อความเป็นส่วนตัว” และวางแผนลดมัน ขอบเขตของมันครอบได้ทั้งกระบวนการเชิงกายภาพ เชิงบริหาร และเชิงเทคนิค

PIA มีเป้าหมายหลัก 4 ข้อ ผมแปลเป็นภาษาคน:

จุดสำคัญ PIA ต้องทำตาม “วิธีมาตรฐาน” (จากกฎหมายหรือมาตรฐานอุตสาหกรรม) เพื่อให้ทำซ้ำได้และได้ผลสม่ำเสมอทุกครั้ง ไม่ใช่ต่างคนต่างทำตามใจ และ ต้องทำ PIA ใหม่ทุกครั้งที่มีการเปลี่ยนแปลงที่กระทบการใช้ข้อมูล ข่าวสำคัญคือ “การเอา AI เข้ามาใช้” ถือเป็นการเปลี่ยนแปลงที่ต้องทำ PIA ใหม่ (เช่นเดียวกับเทคโนโลยีใหม่อื่นๆ อย่าง blockchain, RPA, IoT)

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

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

• อคติของอัลกอริทึม — AI เลือกปฏิบัติกับคนบางกลุ่มโดยไม่ตั้งใจ
• ความเสี่ยงจากการอนุมาน (inference) — AI “เดา” ข้อมูลอ่อนไหวของคนได้ ทั้งที่คนไม่เคยให้ข้อมูลนั้นตรงๆ (เช่น เดาสุขภาพจากพฤติกรรมการซื้อ)
• อธิบายไม่ได้ (lack of explainability) — AI ตัดสินใจแบบที่ไม่มีใครอธิบายได้ว่าทำไม ทำให้ “ตรวจสอบว่าทำถูกกฎความเป็นส่วนตัวไหม” ยากมาก

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

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

3.1 ใครเป็นคนตั้งเส้น — และทำไมต้องเป็นคนนั้น#

คำตอบชัดเจนและสำคัญมาก เจ้าของกิจการและ/หรือคณะกรรมการบริหาร (governing body) เป็นคนรับผิดชอบในการตั้ง “ระดับความเสี่ยงที่ยอมรับได้ (risk appetite)” และ “ระดับที่ทนได้ก่อนเกินขีด (tolerance)” ไม่ใช่ทีมไอที ไม่ใช่ผู้ตรวจ ไม่ใช่ที่ปรึกษา

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

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

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

3.2 ตั้งเส้นจากอะไร — 6 ปัจจัยที่ต้องชั่งน้ำหนัก#

การตั้งเส้นไม่ใช่การ “เดาเอา” แต่มันคือการชั่งน้ำหนักหลายปัจจัยพร้อมกัน 6 ปัจจัยที่ต้องเอามาวางบนตาชั่ง:

สังเกตว่าหลายปัจจัยมัน “ดึงกันคนละทาง” คุณค่าบอกว่า “เสี่ยงหน่อยเถอะ มันคุ้ม” แต่ข้อบังคับกฎหมายบอกว่า “ห้ามเกินเส้นนี้” หน้าที่ของเจ้าของคือหาจุดสมดุลที่ลงตัวที่สุด ไม่ใช่ฟังปัจจัยเดียว

เรื่องที่ต้องไม่ลืม เรื่อง compliance นี่บางทีมัน “ไม่ใช่ทางเลือก” ถ้ามีกฎหมายบังคับ (เช่น กฎคุ้มครองข้อมูล หรือกฎเฉพาะอุตสาหกรรม) เส้นความเสี่ยงของเราจะถูก “ตรึง” ไว้ที่ระดับที่กฎหมายยอมแล้ว เราตั้งหลวมกว่านั้นไม่ได้ ต่อให้ใจอยากเสี่ยงก็ตาม

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

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

3.3 เกินเส้นแล้วทำไง — เกริ่นทางสู่การรับมือ#

พอมีเส้นแล้ว คำถามต่อไปคือ “แล้วเวลาความเสี่ยงตัวไหนมันเกินเส้น เราทำอะไรได้บ้าง” คำตอบคือทางเลือกในการรับมือ 4 แบบ ที่หลายคนคุ้นจากความเสี่ยงทั่วไป (รับ / เลี่ยง / ลด / โอน) ซึ่งผมปูพื้นไว้ใน CISA Domain 2.17 แล้ว

ขอเกริ่นสั้นๆ เพราะตอนหน้าจะเจาะเรื่องนี้เต็มๆ ในมุม AI ทั้ง 4 ทางเลือกยังใช้กับ AI ได้เหมือนเดิม แต่มี “มุมเพิ่ม” ที่ AI ทำให้ซับซ้อนขึ้น:

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

และในความเป็นจริง ทางเลือกทั้ง 4 ไม่ได้ใช้ทีละอัน บ่อยครั้งบริษัทเริ่มด้วย “ลด” (ใส่มาตรการ) แล้ว “รับ” ความเสี่ยงที่เหลือ (residual) โดยเฝ้าดู แล้วยัง “โอน” ส่วนที่เหลืออีกทอดผ่านประกัน สามอย่างซ้อนกันใน AI ตัวเดียว