กล่องดำคืออะไร และทำไมมันถึงน่ากลัวกว่าบั๊กธรรมดา#

เริ่มจากความจริงที่ทำใจยากที่สุดก่อนครับ — AI สมัยใหม่บางตัว ตัดสินใจได้ แต่บอกไม่ได้ว่าทำไม

โดยเฉพาะ AI กลุ่มที่ใช้ “โครงข่ายประสาทเทียมหลายชั้น” (neural network — เลียนแบบสมองคน) และ “การเรียนรู้เชิงลึก” (deep learning — DL: AI ที่ซ้อนชั้นการคำนวณลึกหลายชั้น) ยิ่งมันเก่ง ยิ่งมันซับซ้อน ก็ยิ่งเปิดฝาเข้าไปดูข้างในแล้วเข้าใจไม่ได้ว่ามันคิดยังไง อาการนี้เขาเรียกว่า ปัญหากล่องดำ (black box problem) — เห็นแต่ “ป้อนอะไรเข้าไป” กับ “ได้อะไรออกมา” แต่ตรงกลางมืดสนิท

ทำไมเรื่องนี้ถึงสะเทือนใจคนทำงานความปลอดภัยและคนบริหารมากเป็นพิเศษ? เพราะมันพลิกหลักคิดเดิมที่เราใช้กับซอฟต์แวร์มาตลอด ลองเทียบให้เห็นภาพครับ:

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

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

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

”AI เป็นของทดลอง” — ทำไมเราต้องคิดต่างจากซอฟต์แวร์เดิม#

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

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

Explainability กับ Interpretability — ต่างกันยังไง และเราต้องสนใจตัวไหน#

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

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

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

• คำอธิบายแบบ “ถ้าเปลี่ยนตรงนี้จะเป็นยังไง” (Counterfactual explanations) — เช่น “ถ้าลูกค้ารายนี้มีรายได้เพิ่มอีกห้าพันบาท ระบบจะอนุมัติ” — เป็นวิธีอธิบายที่ลูกค้าเข้าใจง่ายที่สุด เพราะมันบอกว่า “ต้องแก้อะไรถึงจะผ่าน”
• การเน้นว่าปัจจัยไหนสำคัญ (Feature visualization) — ทำให้เห็นภาพว่าโมเดลให้ความสำคัญกับปัจจัยอะไรมากน้อย
• การยกตัวอย่างเคสที่มีอิทธิพล (Influential instance) — ชี้ว่า “ข้อมูลตัวอย่างไหนตอนสอน ที่มีผลต่อคำตอบนี้มากที่สุด”

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

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

การจดเอกสาร “ความโปร่งใส” และ “ความทึบ” — งานเอกสารที่ห้ามมองข้าม#

นี่คือ control แรกที่เป็นรูปธรรมที่สุดในเรื่อง Trust และเป็นจุดที่เจ้าของสั่งให้เกิดได้เลย — การจดเป็นเอกสาร (documentation)

ตำราบอกชัดว่ามีของสามอย่างที่ต้องจด ผมเรียงให้เป็นเช็คลิสต์:

1. จดว่าข้อมูลที่ใช้ และข้อมูลที่ AI สร้างออกมา มาจากไหน ไปไหน (transparency of data) — โปร่งใสว่าข้อมูลไหลยังไงในระบบ
2. จดว่าโมเดลถูกออกแบบมายังไง (model design) — และเพราะ AI มีระดับการทำงานอัตโนมัติสูง เอกสารส่วนนี้จะ “ละเอียดมาก” ซึ่งเป็นเรื่องปกติ ไม่ใช่ทำเกินจำเป็น
3. จดสิ่งที่เราไม่รู้ (documenting the unknown) — ข้อนี้คือหัวใจ และเป็นจุดที่คนมักลืม

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

ฟังดูแปลก แต่มันสำคัญมากในมุมบริหารและกฎหมาย เพราะ:

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

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

ผมจัดความสัมพันธ์ของเอกสารทั้งหมดให้เห็นเป็นแผนภาพง่ายๆ ครับ:

1
ข้อมูลเข้า ──►  [ ตัวโมเดล AI ]  ──►  คำตอบ/การตัดสินใจ
2
   │                  │                      │
3
   ▼                  ▼                      ▼
4
จดที่มา-ที่ไป     จดการออกแบบ         จดเหตุผล (ถ้าได้)
5
ของข้อมูล         ของโมเดล              + จด "สิ่งที่อธิบายไม่ได้"
6
                                          ◄── นี่คือจุดที่คนลืม

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

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

กับดักที่เจ้าของมักพลาดเรื่อง Trust#

ก่อนข้ามไปเรื่องความปลอดภัย ขอเตือนกับดักที่เห็นบ่อยครับ:

• กับดักที่ 1 — “ระบบมันแม่นยำ 95% แล้วจะอธิบายทำไม” — ความแม่นยำ (accuracy) กับ ความอธิบายได้ (explainability) คนละเรื่องกันสิ้นเชิง โมเดลแม่นยำมากแต่อธิบายไม่ได้เลยก็มี และในงานที่กระทบสิทธิคน (สินเชื่อ การจ้างงาน) กฎหมายหลายประเทศบังคับว่าต้องอธิบายได้ ต่อให้แม่นแค่ไหนก็ตาม
• กับดักที่ 2 — เชื่อว่า “ผู้ขายบอกว่าอธิบายได้ = อธิบายได้จริง” — โดยเฉพาะของแบบ AI สำเร็จรูปเช่าใช้ (AIaaS) ที่เราไม่เห็นข้างใน ต้องขอดูตัวอย่างคำอธิบายจริงก่อนเซ็นสัญญา
• กับดักที่ 3 — คิดว่ากล่องดำเป็นปัญหาของ “AI ตัวใหญ่ๆ” เท่านั้น — จริงๆ AI ที่เรียนรู้แบบไม่มีคนกำกับ (unsupervised learning — เช่นระบบจับความผิดปกติในข้อมูล) ก็มีปัญหาอธิบายผลได้ยากเหมือนกัน ตำราถึงแนะนำให้มี “คนคั่น” (HITL) มาช่วยตรวจความถูกต้องของผลด้วย ซึ่งจะโยงไปส่วนถัดไปพอดี

ความปลอดภัยทางกายภาพ (Physical Safety) — AI ที่ขยับของในโลกจริง#

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

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

สำหรับเจ้าของกิจการไทย เรื่องนี้ไม่ใช่นิยายวิทยาศาสตร์เลยครับ — โรงงานที่เริ่มใช้หุ่นยนต์ขนของ (AGV), คลังสินค้าที่ใช้แขนกลหยิบของ, ร้านอาหารที่ใช้หุ่นยนต์เสิร์ฟ — ทุกตัวคือ AI ที่ขยับของในที่ที่มีคน ทั้งนั้น

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

นี่คือ control ที่เจ้าของต้องใส่ใน “เงื่อนไขการจัดซื้อ” ตั้งแต่แรก ไม่ใช่ของแถมที่ค่อยขอทีหลัง

ความเป็นตัวของตัวเองของ AI (Agency / Autonomy) — และคำถามเรื่องใครรับผิด#

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

ข้อแรกสำคัญที่สุดสำหรับคนบริหาร — ความรับผิดชอบ (accountability) ไม่เคยโอนไปอยู่ที่ AI ครับ มันอยู่ที่บริษัทและที่ตัวเราเสมอ ต่อให้ AI ตัดสินใจเอง 100% เวลาเกิดเรื่อง คนที่ถูกฟ้องคือบริษัท ไม่ใช่ตัวซอฟต์แวร์ การเข้าใจข้อนี้คือจุดเริ่มต้นของการตั้ง control ที่ถูกต้อง

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

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

การใช้ AI ในทางร้าย — ตัวตนปลอม และ Deepfake#

อีกมุมของความปลอดภัยคือ “คนเอา AI ไปใช้ทำร้ายคนอื่น” ตำราเน้นสองเรื่อง:

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

2. Deepfake — วิดีโอหรือเสียงปลอมที่ AI สร้างขึ้น เหมือนจริงจนแยกแทบไม่ออก เอาหน้าคนจริงมาขยับปาก ดัดเสียงให้พูดในสิ่งที่ไม่เคยพูด

ตรงนี้ตำราอธิบายกลไกเบื้องหลังไว้ ซึ่งน่าสนใจในมุมเจ้าของ — มันใช้เทคนิคที่เรียกว่า GAN (โครงข่ายสองตัวประลองกัน) หลักการคือเอา AI สองตัวมาแข่งกัน:

• ตัวหนึ่งมีหน้าที่ “ปลอม” คอยพยายามสร้างภาพคนปลอมให้เนียนที่สุด
• อีกตัวมีหน้าที่ “จับผิด” คอยพยายามแยกว่าภาพไหนจริง ภาพไหนปลอม

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

ในมุมเจ้าของกิจการไทย deepfake แปลเป็นความเสี่ยงจริงสองแบบ — (ก) คนปลอมเป็นเรา (ปลอมเสียง CEO โทรสั่งโอนเงิน, ปลอมวิดีโอผู้บริหารพูดเรื่องเสียๆ หาย) และ (ข) ระบบยืนยันตัวตนของเราถูกหลอก (ระบบสแกนหน้าเปิดบัญชี ถูกป้อนวิดีโอปลอม) ทั้งสองแบบกระทบชื่อเสียงและการเงินโดยตรง

ผมจัดความเสี่ยง deepfake กับ control ที่เจ้าของวางได้เลย เป็นตารางครับ:

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

เจาะ: บันทึกและเฝ้าดู (Logging & Monitoring)#

ทำไมเรื่องนี้สำคัญเป็นพิเศษกับ AI กลุ่ม deep learning? เพราะมันคือกลุ่มที่ซับซ้อนและเข้าใจยากที่สุด (ข้อมูลมหาศาล คำนวณหลายมิติ) ตำราจึงบอกว่า โมเดลที่ซับซ้อนพวกนี้ “ต้องถูกทำให้โปร่งใสด้วยการบันทึกเส้นทางการตัดสินใจอย่างละเอียด” — จด “ห่วงโซ่ความคิด (chain of thought)” ของมันไว้ว่ามันเดินผ่านเส้นทางไหนในโครงข่ายบ้าง

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

ในมุมเจ้าของ คำถามที่ต้องตอบเรื่อง log ไม่ใช่ “มี log ไหม” (ส่วนใหญ่มี) แต่เป็น “log ของเราดีพอจะใช้ตอนเกิดเหตุจริงไหม” ซึ่งมีสามเงื่อนไขที่คนชอบลืม:

• เก็บครบไหม — เก็บทั้ง input, เส้นทางการตัดสิน, และ output หรือเก็บแค่ผลสุดท้าย (ซึ่งย้อนหาสาเหตุไม่ได้)?
• เก็บนานพอไหม — เหตุ AI บางอย่างกว่าจะรู้ตัวก็ผ่านไปหลายเดือน ถ้า log ถูกลบทุก 7 วัน พอจะสอบสวนก็ไม่เหลืออะไรให้ดู
• แก้ไขไม่ได้ใช่ไหม — log ที่คนแก้ย้อนหลังได้ ใช้เป็นหลักฐานไม่ได้ ต้องเป็น log ที่ “เขียนแล้วแก้ไม่ได้” (write-once) ถึงจะเชื่อถือได้ในเชิงกฎหมาย

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

เจาะ: การมองเห็น AI (AI Observability)#

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

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

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

มุมผู้บริหาร: logging กับ observability ฟังดูเป็นเรื่องเทคนิคของฝ่ายไอที แต่จริงๆ มันคือ “กล้องวงจรปิดของ AI” ครับ — ไม่มีเจ้าของร้านคนไหนเปิดร้านโดยไม่ติดกล้อง เพราะวันเกิดเหตุจะได้ย้อนดูได้ การปล่อย AI ทำงานโดยไม่มี log และไม่มีเครื่องมือเฝ้าดู ก็เหมือนเปิดร้านโดยไม่มีกล้องเลย — ประหยัดตอนแรก แต่วันเกิดเรื่องคือหายนะ

หลักการ และตัวอย่างที่ตำรายกมา#

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

หัวใจของ HITL ที่ตำราเน้นคือ — มันไม่ใช่แค่ “มีคนนั่งดูเฉยๆ” แต่ต้อง ออกแบบให้วงจรการทำงาน (workflow) ของ AI หยุดรอการอนุมัติจากคน ในเงื่อนไขที่กำหนดไว้ชัดเจน ก่อนจะเดินต่อได้ — คือมันเป็น control ที่ฝังในระบบ ไม่ใช่แค่นโยบายบนกระดาษ

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

1
ลูกค้ายื่นกู้ ──► AI ประเมิน ──► คะแนนความเสี่ยง
2
                                      │
3
                  ┌───────────────────┼───────────────────┐
4
                  ▼                    ▼                    ▼
5
            คะแนนดีมาก            คะแนนก้ำกึ่ง           คะแนนแย่ /
6
            (ปลอดภัย)            หรือถูกปฏิเสธ           เคสพิเศษ
7
                  │                    │                    │
8
            AI อนุมัติเอง         ⏸ หยุดรอคนเคาะ        ⏸ หยุดรอคนเคาะ
9
            (เร็ว)               (HITL ตรงนี้)         (HITL ตรงนี้)

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

ข้อแลกเปลี่ยนที่เจ้าของต้องรู้ — HITL ทำให้ “ช้าลง”#

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

นี่คือการตัดสินใจระดับเจ้าของล้วนๆ ผมจัดกรอบช่วยตัดสินใจให้ครับ:

หลักง่ายๆ คือ — ยิ่งความเสียหายสูงและกู้คืนยาก ยิ่งต้องมีคนคั่น ส่วนงานที่พลาดแล้วแก้ง่าย ปล่อยให้ AI วิ่งเองเพื่อแลกความเร็วได้

HITL กับ AITL — สลับบทบาทคนกับ AI#

ตำราแนะนำคำใหม่ที่กำลังมาคู่กับ HITL คือ AI-in-the-Loop (AITL) — ฟังดูคล้ายแต่กลับด้านกันครับ ผมเทียบให้เห็นชัด:

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

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

มุมผู้บริหาร: เวลาทีมหรือผู้ขายพูดว่า “ระบบนี้มี Human-in-the-Loop นะครับ” อย่าเพิ่งสบายใจ ให้ถามต่อสองข้อ — (1) “คนคั่นตรงไหนบ้าง คั่นทุกเคสหรือบางเคส และใช้เงื่อนไขอะไรตัดสินว่าเคสไหนต้องคั่น?” และ (2) “คนที่คั่นมีข้อมูลพอจะ ‘เคาะอย่างมีความหมาย’ ไหม หรือแค่กดปุ่ม OK ตามที่ AI บอก?” — เพราะ HITL ที่คนแค่กด OK ตามทุกครั้ง ไม่ต่างอะไรกับไม่มีคนคั่นเลย เป็นแค่ตรายางให้ AI

กับดักของ HITL ที่เจอบ่อย#

• กับดัก “ตรายาง” (rubber-stamping) — มีคนคั่นแต่คนนั้นกด OK ตาม AI ทุกครั้งโดยไม่ได้ดูจริง เพราะงานเยอะ/เชื่อ AI เกินไป — แก้ด้วยการให้ข้อมูลคนตรวจเพียงพอ และสุ่มตรวจคุณภาพการตัดสินของคนคั่นเองด้วย
• กับดัก “คั่นจนอืด” — เอาคนไปคั่นทุกขั้นจนระบบช้าไม่ต่างจากทำมือ ทำให้คนทั้งองค์กรเลิกใช้ — แก้ด้วยการเลือกคั่นเฉพาะจุดเสี่ยงสูงตามตารางข้างบน
• กับดัก “คั่นผิดคน” — เอาคนที่ไม่มีความรู้พอมาเคาะคำตัดสินที่ต้องใช้ความเชี่ยวชาญ (เช่นให้ธุรการเคาะคำวินิจฉัยทางการแพทย์) — คนคั่นต้องมีอำนาจและความรู้พอจะคัดค้าน AI ได้จริง

กับดักของ Safety ที่เจ้าของมักพลาด#

ปิดท้ายส่วน control ด้วยกับดักที่เห็นบ่อยเหมือนกันครับ:

• กับดัก “เปิด AI ก่อน ค่อยคิดเรื่องคุมทีหลัง” — เอา AI มาใช้งานจริงไปก่อน แล้วค่อยมาวาง log/observability/HITL ทีหลังเมื่อมีปัญหา — แต่หลายเรื่อง (โดยเฉพาะ log การตัดสินใจย้อนหลัง) ถ้าไม่เปิดไว้ตั้งแต่วันแรก ก็ย้อนเก็บไม่ได้ ข้อมูลที่ควรใช้สอบสวนหายไปแล้ว
• กับดัก “มี log แต่ไม่มีใครดู” — เก็บ log มหาศาลแต่ไม่มีคนหรือเครื่องมือคอยดู ก็เหมือนติดกล้องวงจรปิดแล้วไม่เคยเปิดดูจอ — observability ที่ดีต้องมี “การแจ้งเตือน” ไม่ใช่แค่ “การเก็บ”
• กับดัก “ปล่อยให้ AI มีสิทธิ์มากเกินงาน” — ให้ AI เข้าถึง/แก้ไขได้มากกว่าที่งานต้องการ (เช่น AI ช่วยตอบลูกค้า แต่ดันมีสิทธิ์เข้าถึงฐานข้อมูลการเงินทั้งหมด) — ยิ่งให้สิทธิ์มาก ความเสียหายตอนมันพลาดหรือถูกหลอกก็ยิ่งกว้าง หลักคิดเดิมเรื่อง “ให้สิทธิ์เท่าที่จำเป็น” (least privilege) ใช้กับ AI ได้เหมือนกัน

โยงกลับกรอบสากล — control พวกนี้ไม่ใช่เราคิดเอง#

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

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