สารบัญ
AAISM Series — คู่มือคุม AI ในมุมคนบริหาร (ไม่ใช่มุมผู้ตรวจ) ตอนที่ 36 / Domain 3 — AI Technologies & Controls (เทคโนโลยีและการควบคุม) ซีรีส์นี้เล่าจากมุม “เจ้าของกิจการ / CISO ที่เอา AI มาใช้จริง” ว่าต้องตัดสินใจอะไรและรับความเสี่ยงเอง (สารบัญเต็มจะตามมา)
ตอนก่อนๆ ใน Domain 3 เราเดินไล่ดู control ทางเทคนิคมาเยอะมาก — ตั้งแต่ออกแบบสถาปัตยกรรม คุมข้อมูล คุม model ไปจนถึง control ความปลอดภัยรอบๆ AI ทั้งหลาย พอเล่ามาถึงตรงนี้ เจ้าของกิจการหลายคนน่าจะเริ่มรู้สึกว่า “control มันก็เป็นเรื่องของระบบ ของเครื่องมือ ของทีม IT สินะ”
ตอนนี้อยากชวนหยุดคิดสักนิด เพราะ control ที่จะพูดถึง มันไม่ใช่ซอฟต์แวร์ ไม่ใช่ firewall ไม่ใช่เครื่องมือใดๆ เลย แต่มันคือ คนของเราเอง
ลองนึกภาพแบบนี้นะครับ สมมติว่าบริษัทแห่งหนึ่งลงทุนซื้อ control ทางเทคนิคครบทุกอย่าง มี DLP มี monitoring มี access control แน่นหนา แล้ววันหนึ่งพนักงานบัญชีคนหนึ่งเอางบการเงินทั้งบริษัทไปวางใน ChatGPT เพื่อ “ขอให้มันช่วยสรุปให้หน่อย” เพราะงานเร่ง ข้อมูลทั้งก้อนก็ไหลออกนอกบ้านไปแล้ว โดยที่ control ทางเทคนิคทุกอันที่เราซื้อมา ไม่ได้ขวางอะไรเลย เพราะพนักงานคนนั้นไม่เคยรู้ว่าทำแบบนั้นมันอันตราย
นี่แหละครับคือหัวใจของตอนนี้ คนที่ไม่รู้ คือช่องโหว่ที่ไม่มี control ทางเทคนิคไหนปิดได้ และทางแก้มันไม่ได้อยู่ที่ซื้อของเพิ่ม แต่อยู่ที่ ทำให้คนของเรา “รู้” และ “เปลี่ยนพฤติกรรม” ซึ่งภาษาทางการเรียกว่า AI Security Awareness Training (การสร้างความตระหนักรู้เรื่องความปลอดภัย AI ให้พนักงาน)
และพอพูดถึงเรื่อง “คน” แล้ว มันมีอีกด้านที่เจ้าของกิจการชอบมองข้าม ไม่ใช่แค่ “พนักงานทั่วไปรู้พอจะใช้ AI อย่างปลอดภัยไหม” แต่คือ “บริษัทเรามีคนที่เก่งพอจะออกแบบ เลือก และคุม AI ได้หรือยัง” เรื่องนี้เรียกว่า AI Skills Gap (ช่องว่างทักษะด้าน AI) เดี๋ยวจะเล่าในครึ่งหลังของตอน
ทบทวนแว่นที่เราใส่ — AI = พนักงานใหม่เก่งๆ ที่ต้องกำกับ
ทั้งซีรีส์นี้ผมชวนมองว่า AI = พนักงานใหม่เก่งสุดๆ คนหนึ่งที่เราต้องกำกับ ไม่ใช่เครื่องวิเศษที่เสกแล้วจบ
พอมาถึง Domain 3 ซึ่งเป็นบทเทคนิคที่สุดของทั้งหมด แว่นอันนี้ต้องปรับโฟกัสนิดนึง Domain 1 เราตั้งกฎ Domain 2 เรามองความเสี่ยง พอมา Domain 3 คือ “ลงมือคุมงานจริงในแต่ละวัน” เหมือนเราเลิกประชุมวางแผนแล้ว เดินลงไปยืนคุมหน้างานจริงๆ
แต่ตอนนี้มีมุมที่ต่างออกไปอีกชั้น เพราะเรื่อง “อบรมพนักงาน” มันไม่ใช่เรื่องการกำกับ “ตัว AI” แล้ว แต่มันคือการกำกับ “คนที่ทำงานกับ AI” ต่างหาก
พูดง่ายๆ คือ ถ้า AI เป็นพนักงานใหม่เก่งๆ ที่เราเพิ่งรับเข้ามา เพื่อนร่วมงานคนเก่าๆ ของเราทุกคน ก็ต้องรู้ว่าจะทำงานกับน้องใหม่คนนี้ยังไงให้ปลอดภัย จะมอบงานอะไรให้ได้ อะไรห้ามบอกน้องเด็ดขาด และถ้าน้องตอบอะไรแปลกๆ มาจะดูออกไหม ขณะเดียวกัน เราในฐานะบริษัท ก็ต้องมี “หัวหน้างาน” ที่เก่งพอจะคุมน้องใหม่คนนี้ด้วย ไม่ใช่รับน้องเก่งเข้ามาแล้วปล่อยให้ทำงานโดยไม่มีใครคุมเป็น
มุมผู้บริหาร: จุดที่คนบริหารพลาดบ่อยที่สุดคือมอง awareness training เป็น “ค่าใช้จ่ายที่ต้องทำให้ครบตามกฎ” จัดอบรมปีละครั้ง ให้พนักงานนั่งฟังสไลด์ กดผ่านแบบทดสอบ จบ เก็บใบเซ็นชื่อไว้โชว์ตอนตรวจ แต่ความจริงคือ awareness ที่ดีคือ control ที่ถูกที่สุดและคุ้มที่สุดที่เราจะซื้อได้ เพราะมันป้องกันความเสียหายที่ control ทางเทคนิคราคาแพงปิดไม่ได้ คำถามที่เราควรถามไม่ใช่ “อบรมครบหรือยัง” แต่คือ “หลังอบรมแล้ว พฤติกรรมพนักงานเปลี่ยนจริงไหม”
ทำไม “อบรมปีละครั้ง” ถึงไม่พอ — และมันต่างจากการอ่าน policy ยังไง
เรื่องแรกที่ตำรา AAISM เน้นหนักมาก และผมว่าเจ้าของกิจการไทยควรขีดเส้นใต้คือ awareness training เรื่อง AI มันไม่ใช่การนำเสนอปีละครั้งที่ให้พนักงานทำกันเองแล้วจบ
ลองนึกภาพการอบรมความปลอดภัยแบบเดิมๆ ที่เราคุ้นกัน เปิดสไลด์ อ่านนิยาม “phishing คืออะไร” “ห้ามคลิกลิงก์แปลกๆ” พนักงานนั่งฟังครึ่งหลับครึ่งตื่น กดทำแบบทดสอบ 10 ข้อ ผ่าน 7 ข้อก็ถือว่าจบ ปีหน้าค่อยมาทำใหม่ แบบนี้สำหรับเรื่อง AI ใช้ไม่ได้เลย ด้วยเหตุผลง่ายๆ สองข้อ
ข้อแรก AI เปลี่ยนเร็วเกินกว่าจะอบรมปีละครั้ง ความรู้ที่อบรมไปต้นปี พอกลางปีอาจล้าสมัยไปแล้ว เพราะมีเครื่องมือ AI ใหม่ ภัยใหม่ วิธีหลอกใหม่โผล่มาตลอด
ข้อสอง AI awareness ไม่ใช่แค่ “ท่องนิยาม” แต่ต้อง “เปลี่ยนวิธีคิดเวลาทำงาน” เพราะการใช้ AI ผิดพลาดส่วนใหญ่ไม่ได้เกิดจากคนตั้งใจร้าย แต่เกิดจากคน “ไม่ทันคิด” เห็นว่าสะดวกก็เอาข้อมูลไปวาง เห็นว่า AI ตอบมาดูฉลาดก็เชื่อเลย เรื่องพวกนี้แก้ด้วยการท่องนิยามไม่ได้ ต้องฝึกให้มัน “ติดเป็นนิสัย”
แล้วที่ตำราย้ำอีกอย่างคือ awareness training ไม่ใช่แค่การเอา “นโยบายการใช้ AI” (AI acceptable use policy) มาอ่านซ้ำ กับ “นิยามว่าเหตุการณ์ความปลอดภัยคืออะไร” การอ่าน policy ให้ฟังมันบอกแค่ “ห้ามทำอะไร” แต่ awareness ที่ดีต้องทำให้พนักงาน “เข้าใจว่าทำไมถึงห้าม” และ “รู้ว่าถ้าเจอสถานการณ์จริงต้องทำยังไง”
และจุดที่สำคัญที่สุด ซึ่งเป็นหน้าที่ของคนบริหารโดยตรง คือ ผู้นำต้องประกาศเจตนาให้ชัดว่าบริษัทจะใช้ AI ยังไง แล้วก็ทำให้นโยบายเก่ากับนโยบายใหม่มันสอดคล้องกัน ไม่ใช่ปล่อยให้พนักงานเดาเอาเองว่า “เอ๊ะ บริษัทอยากให้ใช้ AI ไหมนะ ใช้ได้แค่ไหน” พอไม่ชัด คนก็จะใช้แบบ “ทำไปก่อน เดี๋ยวมีปัญหาค่อยว่ากัน” ซึ่งคือต้นตอของ shadow IT (การแอบใช้เครื่องมือนอกสายตาบริษัท)
มุมผู้บริหาร: awareness training ที่ล้มเหลวมักล้มเพราะ “ผู้บริหารไม่เคยพูดเอง” คือส่งให้ฝ่าย IT หรือ HR จัด แล้วตัวเองไม่เคยปรากฏตัว พนักงานก็จะรับสารว่า “เรื่องนี้คงไม่สำคัญเท่าไหร่ ผู้ใหญ่ยังไม่สนเลย” สิ่งที่ตำราเรียกว่า “the full engagement of employees” (การมีส่วนร่วมเต็มที่ของพนักงาน) มันเริ่มจากบนลงล่าง ถ้าอยากให้พนักงานเอาจริง ผู้บริหารต้องเอาจริงให้เห็นก่อน และต้องเข้าใจด้วยว่าพนักงานแต่ละคนมาพร้อมแรงจูงใจ ความกังวล และมุมมองที่ไม่เหมือนกัน อบรมแบบ “one-size-fits-all” สั่งครั้งเดียวใช้ทั้งบริษัทมักไม่ได้ผล
แล้ว “ต่อเนื่อง” ที่ตำราพูดถึง มันหน้าตาเป็นยังไงในทางปฏิบัติ? ผมขอแปลเป็นจังหวะที่เจ้าของกิจการพอจะนึกภาพได้ (ไม่ใช่สูตรตายตัว แต่ให้เห็นว่ามันไม่ใช่ “อีเวนต์ปีละครั้ง”):
- ตอนรับเข้า/เปลี่ยนหน้าที่ พนักงานใหม่ หรือคนที่เพิ่งได้สิทธิใช้เครื่องมือ AI ตัวใหม่ ต้องอบรมก่อนเริ่มใช้ ไม่ใช่ใช้ไปก่อนแล้วค่อยอบรมตอนสิ้นปี
- เป็นจังหวะสั้นๆ สม่ำเสมอ แทนที่จะยัดทุกอย่างใส่การอบรมก้อนใหญ่ปีละครั้ง ให้แตกเป็นชิ้นเล็กๆ บ่อยๆ (เช่น เตือนสั้นๆ เป็นระยะ) เพราะคนจำเรื่องสั้นที่เจอบ่อยได้ดีกว่าเรื่องยาวที่เจอปีละหน
- เมื่อมีภัยใหม่หรือเครื่องมือใหม่ พอมีวิธีหลอกใหม่ หรือบริษัทเริ่มใช้ AI ตัวใหม่ ต้องมีการสื่อสารอัปเดตทันที ไม่ใช่รอรอบอบรมประจำปี
- หลังเกิดเหตุ (หรือเกือบเกิด) ทุกครั้งที่มีเหตุ AI พลาด หรือเกือบพลาด คือโอกาสอบรมที่ดีที่สุด เพราะคนจะจำบทเรียนจากเรื่องจริงได้แม่นกว่าทฤษฎี
มุมผู้บริหาร: อย่ามอง awareness เป็น “โครงการที่มีวันจบ” แต่ให้มองเป็น “การดูแลต่อเนื่อง” เหมือนการดูแลสุขภาพ — ไม่ใช่ตรวจร่างกายปีละครั้งแล้วถือว่าแข็งแรง แต่ต้องกินดีออกกำลังทุกวัน คำถามที่ผู้บริหารควรถามคือ “ระหว่างรอบอบรมประจำปี เรามีอะไรที่ทำให้คนคิดถึงเรื่องนี้อยู่เรื่อยๆ ไหม” ถ้าไม่มีเลย แปลว่าความรู้ที่อบรมไปจะจางหายภายในไม่กี่สัปดาห์
สองภัยจาก “คน” ที่ awareness ต้องปิด — shadow IT และข้อมูลรั่ว
ตำราระบุชัดว่า awareness training มีไว้เพื่อจัดการ “ความเสี่ยงที่เกิดจากคน” (human-related risk) โดยยกตัวอย่างสองภัยหลักที่เจ้าของกิจการต้องเข้าใจให้ขึ้นใจ เพราะมันคือต้นตอของเหตุการณ์ AI พังที่พบบ่อยที่สุดในโลกจริง:
ภัยที่หนึ่ง — Shadow IT (การแอบใช้เครื่องมือนอกสายตา): พนักงานหาเครื่องมือ AI มาใช้เองโดยที่บริษัทไม่รู้ ไม่อนุมัติ และไม่ได้ประเมินความเสี่ยง ลองนึกภาพทีมการตลาดของบริษัทแห่งหนึ่ง (สมมติ) เบื่อที่จะรอ IT อนุมัติเครื่องมือ เลยสมัครใช้ AI ตัวฟรีบนเน็ตเอง แล้วเอาแผนการตลาดทั้งปีไปให้มันช่วยคิด บริษัทไม่มีทางรู้เลยว่าแผนนั้นไปอยู่ที่ไหน ใครเห็น และถูกเอาไปใช้ทำอะไรต่อ จุดสำคัญคือ shadow IT ไม่ได้เกิดเพราะพนักงาน “อยากทำผิด” แต่เกิดเพราะ “เครื่องมือทางการช้าหรือใช้ยาก” คนเลยหาทางลัด
ภัยที่สอง — ข้อมูลรั่ว (information leakage): พนักงานเอาข้อมูลลับของบริษัทหรือของลูกค้าไปป้อนให้ AI โดยไม่รู้ว่าข้อมูลนั้นอาจถูกเก็บ ถูกเอาไปฝึก model ต่อ หรือถูกคนอื่นเห็น นี่คือเหตุการณ์ที่เปิดตอนนี้ผมยกตัวอย่างไว้ (พนักงานบัญชีเอางบการเงินไปวางใน AI) ความน่ากลัวคือมัน “รั่วแบบเงียบๆ” ไม่มีเสียงเตือน ไม่มีไฟแดงกระพริบ ข้อมูลแค่ไหลออกไปเฉยๆ ตอนที่พนักงานกดปุ่มด้วยความหวังดีว่าจะทำงานเร็วขึ้น
มุมผู้บริหาร: ทั้งสองภัยนี้มีรากเดียวกันคือ “พนักงานหวังดีแต่ไม่รู้” ไม่ใช่ “พนักงานคิดร้าย” นั่นแปลว่าเราจะแก้ด้วยการ “ลงโทษให้เข็ด” ไม่ได้ผล เพราะคนไม่รู้ว่าตัวเองทำผิด ทางแก้ที่ตำราชี้คือ awareness ทำให้คน “รู้” และที่สำคัญกว่านั้น เจ้าของกิจการต้องเข้าใจว่า shadow IT เป็น “อาการ” ไม่ใช่ “โรค” ถ้าพนักงานแอบใช้เครื่องมือนอกสายตาเยอะ แปลว่าเครื่องมือทางการของบริษัทอาจช้าหรือไม่ตอบโจทย์ การออกกฎห้ามอย่างเดียวจะยิ่งผลักให้คนหลบลงใต้ดิน ต้องคู่กับ “ให้ทางเลือกที่ดีพอ” ด้วย
อบรมอะไรบ้าง — แกะ 11 องค์ประกอบของหลักสูตรที่ดี
ทีนี้คำถามที่เจ้าของกิจการถามต่อทันทีคือ “ก็เข้าใจแล้วว่าต้องอบรม แต่ อบรมอะไรบ้างล่ะ” ตำรา AAISM ให้รายการองค์ประกอบของหลักสูตร awareness ที่ดีไว้ ผมขอเรียบเรียงใหม่ จัดกลุ่มเอง พร้อมแปลเป็นภาษาคนว่าแต่ละหัวข้อ “พนักงานต้องรู้ไปทำไม” และ “คนบริหารต้องสั่งให้เกิดอะไร”
ผมจัดเป็น 4 กลุ่มใหญ่ตามจุดประสงค์ เพื่อให้เห็นภาพง่ายขึ้น (ตำราไม่ได้แบ่งกลุ่มแบบนี้ ผมแบ่งเองให้อ่านสนุก):
กลุ่มที่ 1 — “รู้กติกาและเจตนา” (ทำไมเราถึงใช้ AI และใช้ได้แค่ไหน)
| หัวข้อที่ต้องอบรม | พนักงานต้องเข้าใจอะไร (ภาษาคน) | คนบริหารต้องสั่งให้เกิดอะไร |
|---|---|---|
| ความปลอดภัย ความเป็นส่วนตัว และจริยธรรม | กรอบใหญ่ว่า การใช้ AI มีเส้นแดง 3 เส้น — ความปลอดภัย (ข้อมูลห้ามหลุด) ความเป็นส่วนตัว (ข้อมูลคนอื่นห้ามมั่ว) และจริยธรรม (อย่าใช้ AI ในทางที่ทำร้ายคน) | กำหนดเส้นแดงให้ชัดเป็นรูปธรรม ไม่ใช่พูดลอยๆ ว่า “ใช้อย่างมีจริยธรรม” |
| ประโยชน์ที่องค์กรและตัวพนักงานจะได้ | ทำไมบริษัทถึงเอา AI มาใช้ มันช่วยงานเขายังไง — ข้อนี้สำคัญ เพราะถ้าพนักงานไม่เห็นประโยชน์ เขาจะมองว่าเป็นภาระและต่อต้าน | สื่อสารให้เห็นว่า AI มาช่วย “ไม่ใช่มาแย่งงาน” เพื่อลดแรงต้านและลดการแอบใช้แบบมั่วๆ |
| เรื่องลิขสิทธิ์และทรัพย์สินทางปัญญา | งานที่ AI สร้างให้ ใครเป็นเจ้าของ? เอาไปใช้เชิงพาณิชย์ได้ไหม? ไปลอกงานคนอื่นมาหรือเปล่า? — เรื่องนี้พลาดได้ง่ายและฟ้องร้องกันได้จริง | ออกแนวทางชัดว่า งานที่ AI ช่วยทำชิ้นไหนเอาไปใช้ได้/ไม่ได้ และต้องตรวจอะไรก่อนเผยแพร่ |
กับดักที่พบบ่อย — “AI สร้างให้ = ของเราฟรีๆ”: พนักงานจำนวนมากเข้าใจว่า อะไรที่ AI สร้างให้คือ “ของฟรีที่เราเป็นเจ้าของเต็มๆ เอาไปขายได้เลย” ซึ่งอันตรายมาก เพราะ (1) AI อาจสร้างงานที่คล้ายงานมีลิขสิทธิ์ของคนอื่นโดยไม่รู้ตัว และ (2) สิทธิความเป็นเจ้าของในงานที่ AI สร้างยังเป็นเรื่องที่กฎหมายหลายประเทศยังไม่ชัด ทางแก้ไม่ใช่ห้ามใช้ แต่คือ อบรมให้พนักงานรู้ว่าต้องตรวจอะไรก่อนเอางาน AI ไปใช้จริง โดยเฉพาะงานที่จะเผยแพร่สู่สาธารณะหรือขายได้
กลุ่มนี้ผมอยากเน้นข้อ “ประโยชน์ที่พนักงานจะได้” สักหน่อย เพราะมันมักถูกข้ามไป หลักสูตรอบรมส่วนใหญ่เอาแต่พูด “ห้ามนู่นห้ามนี่” จนพนักงานรู้สึกว่า AI คือเรื่องน่ากลัวที่บริษัทเอามาเพิ่มกฎ ผลคือเขาต่อต้านเงียบๆ หรือไม่ก็แอบใช้นอกระบบเพราะกลัวถูกจับผิด ตำราจึงจัด “ประโยชน์ต่อองค์กรและตัวผู้ใช้” ไว้เป็นองค์ประกอบของหลักสูตรโดยตรง คือต้องทำให้พนักงานเห็นว่า “AI มาช่วยให้งานเขาเบาลง ไม่ใช่มาเพิ่มภาระหรือมาแย่งงาน” พอเขาเห็นประโยชน์ เขาจะอยากใช้อย่างถูกวิธีเอง ไม่ใช่หลบไปใช้แบบเสี่ยงๆ นี่คือจิตวิทยาง่ายๆ ที่ทำให้ awareness ได้ผลจริง
มุมผู้บริหาร: เส้นแดงเรื่อง “ความปลอดภัย ความเป็นส่วนตัว จริยธรรม” จะใช้ได้จริงต่อเมื่อมันเป็น รูปธรรม — แทนที่จะบอก “ห้ามเอาข้อมูลลับไปใส่ AI” (พนักงานงงว่าอะไรคือลับ) ให้บอกเป็นตัวอย่างชัดๆ ว่า “ข้อมูลลูกค้า เลขบัตรประชาชน งบการเงิน สูตร/ความลับทางการค้า ห้ามใส่ AI สาธารณะเด็ดขาด” คนบริหารมีหน้าที่ “แปลนามธรรมเป็นรูปธรรม” ให้พนักงานเอาไปใช้ตัดสินใจได้ทันทีหน้างาน ไม่ใช่ทิ้งหลักการกว้างๆ ให้เขาตีความเอง
กลุ่มที่ 2 — “อ่านผลลัพธ์ AI ให้เป็น” (อย่าเชื่อทุกอย่างที่มันตอบ)
นี่คือกลุ่มที่ผมว่าสำคัญที่สุดและคนละเลยมากที่สุด เพราะปัญหาใหญ่ของ AI ยุคนี้ไม่ใช่ “มันตอบไม่ได้” แต่คือ “มันตอบผิดด้วยน้ำเสียงมั่นใจมากจนคนเชื่อ”
| หัวข้อที่ต้องอบรม | พนักงานต้องเข้าใจอะไร (ภาษาคน) | คนบริหารต้องสั่งให้เกิดอะไร |
|---|---|---|
| เข้าใจผลลัพธ์ของ model | AI ตอบมาแบบนี้ “มันมาจากไหน” และ “เชื่อได้แค่ไหน” — ไม่ใช่เห็นคำตอบแล้วเอาไปใช้เลย | ตั้งกติกาว่างานสำคัญต้องมีคน “ตรวจซ้ำ” ก่อนใช้ผลจาก AI เสมอ |
| ฝึกตีความผลลัพธ์ของ model | ลงลึกกว่าข้อบน — ฝึกจริงว่าเจอคำตอบแบบไหนควรสงสัย แบบไหนพอเชื่อได้ ฝึกจากตัวอย่างจริง | จัดให้มี “การฝึกตีความ” ไม่ใช่แค่บอกว่า “ให้ระวัง” แต่ให้ลองทำจริง |
| เข้าใจ explainability และความเสี่ยง black-box | AI บางตัว “อธิบายไม่ได้ว่าทำไมตอบแบบนี้” (เรียกว่ากล่องดำ — black box) พนักงานต้องรู้ว่าของแบบนี้เอาไปใช้ตัดสินใจสำคัญไม่ได้ | กำหนดว่างานประเภทไหน “ห้ามใช้ AI ที่อธิบายไม่ได้” — เช่น การตัดสินใจที่กระทบสิทธิคน |
| ตรวจจับและจัดการ bias (อคติ) ในข้อมูลและผลลัพธ์ | AI เรียนจากข้อมูลเก่า ถ้าข้อมูลเก่ามีอคติ AI ก็จะลำเอียงตาม — พนักงานต้องดูออกว่าผลลัพธ์มันเอนเอียงไม่เป็นธรรมไหม | สร้างช่องทางให้พนักงาน “รายงานเมื่อเจอผลลัพธ์ที่ดูลำเอียง” และมีคนรับเรื่องจริง |
| รู้จัก model drift (โมเดลเพี้ยน) และอคติที่โผล่ในผลลัพธ์ | AI ที่เคยแม่น พอเวลาผ่านไปอาจ “เพี้ยน” ลงเรื่อยๆ เพราะโลกเปลี่ยนแต่มันยังคิดแบบเดิม — พนักงานหน้างานคือคนแรกที่จะสังเกตเห็น | สอนพนักงานให้รู้ว่า “ถ้า AI เริ่มตอบแปลกๆ ไม่เหมือนเดิม” ให้แจ้ง ไม่ใช่ทนใช้ต่อ |
กับดักที่อันตรายที่สุด — “AI hallucination” (อาการแต่งคำตอบมั่ว): ปัญหาคลาสสิกที่สุดคือ AI ประเภทสร้างข้อความ (เช่น ChatGPT) เวลามัน “ไม่รู้คำตอบ มันไม่ยอมบอกว่าไม่รู้ แต่จะแต่งคำตอบขึ้นมาให้ดูน่าเชื่อ” — เรียกอาการนี้ว่า hallucination (อาการหลอน/แต่งเรื่อง) สมมติว่าพนักงานกฎหมายถาม AI ว่ามีคำพิพากษาคดีไหนที่เกี่ยวข้อง แล้ว AI แต่งเลขคดีปลอมๆ ขึ้นมาให้ ดูเป๊ะมากแต่ไม่มีคดีนั้นจริง — ถ้าเอาไปใช้คือหายนะ ทางแก้คือ ฝังให้เป็นนิสัยว่า “คำตอบจาก AI = สมมติฐานที่ต้องตรวจ ไม่ใช่ข้อเท็จจริงที่จบแล้ว”
ผมขอขยายกลุ่มนี้อีกหน่อย เพราะมันคือหัวใจของทั้งตอน ความยากของการ “อ่านผลลัพธ์ AI ให้เป็น” อยู่ที่ AI มันถูกออกแบบมาให้ “ตอบด้วยน้ำเสียงมั่นใจเสมอ” ไม่ว่ามันจะรู้จริงหรือเดามั่ว มันก็พูดด้วยโทนเดียวกันหมด ต่างจากคนที่พอไม่แน่ใจจะมีน้ำเสียงลังเลให้เราจับสังเกตได้ พนักงานจึงต้องฝึก “ความสงสัยที่ถูกจังหวะ” คือรู้ว่าเมื่อไหร่ควรเชื่อ เมื่อไหร่ต้องตรวจ
วิธีที่ตำราเสนอคือ “ฝึกตีความผลลัพธ์” ซึ่งต่างจาก “บอกให้ระวัง” เฉยๆ เพราะบอกให้ระวังคือคำพูดลอยๆ ที่ฟังแล้วลืม แต่ฝึกตีความคือเอาตัวอย่างคำตอบ AI จริงๆ มาให้พนักงานดูว่า “อันนี้น่าเชื่อเพราะอะไร อันนี้ควรสงสัยเพราะอะไร” จนเขาจับจังหวะเป็น เปรียบเหมือนสอนพนักงานใหม่ให้ “อ่านคนเป็น” ไม่ใช่บอกว่า “ระวังคนโกหกนะ” แต่ฝึกให้ดูออกเองว่าเมื่อไหร่ข้อมูลมันน่าสงสัย
อีกสามคำที่จับคู่กันและพนักงานมักสับสน ผมขอแยกให้ชัด เพราะมันคนละเรื่องกัน:
| คำ | แปลเป็นภาษาคน | พนักงานต้องทำอะไรเมื่อเจอ |
|---|---|---|
| Hallucination | AI แต่งคำตอบมั่วเพราะมัน “ไม่รู้แต่ไม่ยอมบอกว่าไม่รู้” | ตรวจกับแหล่งจริงก่อนเชื่อ โดยเฉพาะตัวเลข ชื่อ และข้ออ้างอิง |
| Bias (อคติ) | AI ลำเอียงเพราะข้อมูลที่มันเรียนมามีอคติติดมาด้วย | สังเกตว่าผลลัพธ์เอนเอียงกับคนบางกลุ่มไม่เป็นธรรมไหม แล้วรายงาน |
| Drift (เพี้ยน) | AI ที่เคยแม่น ค่อยๆ แย่ลงเพราะโลกเปลี่ยนแต่มันยังคิดแบบเก่า | สังเกตว่า “เดี๋ยวนี้มันตอบแย่ลงกว่าเมื่อก่อนไหม” แล้วแจ้งทีม |
มุมผู้บริหาร: จุดที่คนบริหารต้องตัดสินใจในกลุ่มนี้ไม่ใช่ “สอนพนักงานยังไง” แต่คือ “งานไหนที่ห้ามปล่อยให้ AI ตัดสินใจคนเดียวเด็ดขาด” — ตำราเรียกหลักการนี้ว่าการมีคนคุมในวงจร (human in the loop) สำหรับงานที่กระทบสิทธิคน กระทบเงิน หรือกระทบชื่อเสียง ต้องบังคับให้มี “คนตรวจซ้ำก่อนใช้ผล” เป็นกติกาตายตัว ไม่ใช่แล้วแต่ดุลพินิจพนักงานแต่ละคน เพราะพอเร่งงาน คนจะข้ามขั้นตรวจซ้ำเสมอถ้าไม่ได้บังคับไว้
กลุ่มที่ 3 — “รู้ทันภัยและการโจมตี AI”
| หัวข้อที่ต้องอบรม | พนักงานต้องเข้าใจอะไร (ภาษาคน) | คนบริหารต้องสั่งให้เกิดอะไร |
|---|---|---|
| รู้จัก adversarial AI และเทคนิคหลอก/ปั่น model | มีคนพยายาม “หลอก AI” หรือ “ปั่น AI” ให้ทำงานเพี้ยนได้ (เช่น ป้อนคำสั่งซ่อนเพื่อหลอกให้ AI ทำสิ่งที่ไม่ควร) พนักงานต้องรู้ว่าภัยแบบนี้มีจริง | ให้ทีมความปลอดภัยอัปเดตพนักงานเรื่องภัย AI ใหม่ๆ สม่ำเสมอ ไม่ใช่ปีละครั้ง |
มุมผู้บริหาร: หัวข้อนี้เป็นหัวข้อที่พนักงานทั่วไป “ไม่จำเป็นต้องเข้าใจลึกถึงระดับเทคนิค” — เขาไม่ต้องรู้ว่า prompt injection (การฝังคำสั่งซ่อนเพื่อหลอก AI) ทำงานยังไงในระดับโค้ด แต่เขา ต้องรู้ว่า “ภัยแบบนี้มีจริง และตัวเองอาจเป็นเหยื่อโดยไม่รู้ตัว” — เช่น เปิดเอกสารที่มีคำสั่งซ่อนอยู่แล้วเอาไปให้ AI สรุป งานของคนบริหารคือ ปรับระดับความลึกของเนื้อหาให้เหมาะกับกลุ่มผู้ฟัง — ทีม IT/security อบรมลึก พนักงานทั่วไปอบรมแค่ “รู้ทันและระวังตัว”
กลุ่มที่ 4 — “ฝึกมือและมีช่องทางย้อนกลับ”
| หัวข้อที่ต้องอบรม | พนักงานต้องเข้าใจอะไร (ภาษาคน) | คนบริหารต้องสั่งให้เกิดอะไร |
|---|---|---|
| Tabletop exercise (ซ้อมรับมือบนโต๊ะ) | ซ้อมจำลองสถานการณ์ “ถ้า AI พลาดแบบนี้เราจะทำยังไง” บนกระดาษก่อนเกิดจริง — ให้ทุกฝ่ายซ้อมพร้อมกัน | จัดให้มีการซ้อมจริง ไม่ใช่แค่บรรยาย — เพราะการซ้อมเผยให้เห็นช่องโหว่ในกระบวนการ |
| ช่องทางให้ feedback (ป้อนกลับ) เรื่องการใช้และผลลัพธ์ AI | พนักงานต้องรู้ว่า “ถ้าเจอ AI ทำงานแปลกๆ จะบอกใคร” และเชื่อว่าบอกไปแล้วมีคนรับเรื่องจริง | สร้างช่องทางรายงานที่ “ง่ายและปลอดภัย” — คนกล้าบอกโดยไม่กลัวโดนตำหนิ |
กับดักที่พบบ่อย — “ซ้อมแต่ผู้บริหารไม่ลงมาซ้อมด้วย”: tabletop exercise ที่มีแต่ทีม IT มานั่งซ้อมกันเอง โดยที่ฝ่ายกฎหมาย ฝ่ายสื่อสาร และผู้บริหารไม่มา — มักจะล้มเหลวตอนเกิดเหตุจริง เพราะคนที่ต้อง “ตัดสินใจ” ตอนวิกฤตคือผู้บริหาร ไม่ใช่ทีม IT ถ้าผู้บริหารไม่เคยซ้อม พอเกิดเหตุจริงจะตัดสินใจช้าและมั่ว ตำราจึงจัด tabletop ไว้เป็นองค์ประกอบหลักของหลักสูตร ไม่ใช่ของแถม
มาดูภาพรวมว่า 11 องค์ประกอบนี้ มันเชื่อมโยงกันยังไงเป็น “หลักสูตรเดียว”:
AI Security Awareness Training (หลักสูตรเดียว) │ ┌──────────────┬───────┴───────┬──────────────┐ ▼ ▼ ▼ ▼[รู้กติกา] [อ่านผลให้เป็น] [รู้ทันภัย] [ฝึกมือ+ป้อนกลับ] │ │ │ │ ความปลอดภัย เข้าใจผล adversarial tabletop ความเป็นส่วนตัว ตีความผล AI/ปั่นโมเดล exercise จริยธรรม explainability ช่องทาง ประโยชน์ bias/อคติ feedback ลิขสิทธิ์/IP model driftคนละกลุ่มต้องอบรมไม่เท่ากัน — อย่าเหมารวมทั้งบริษัท
มีกับดักหนึ่งที่ตำราไม่ได้พูดตรงๆ แต่ซ่อนอยู่ในประโยค “พนักงานแต่ละคนมาพร้อมแรงจูงใจ ความกังวล และมุมมองที่ต่างกัน” นั่นคือ อบรมทั้งบริษัทด้วยเนื้อหาชุดเดียวกัน มักไม่ได้ผล เพราะคนแต่ละกลุ่มทำงานกับ AI คนละแบบ ความเสี่ยงที่เขาก่อก็คนละขนาด
ลองนึกภาพง่ายๆ พนักงานต้อนรับที่ใช้ AI ช่วยร่างอีเมลตอบลูกค้า กับโปรแกรมเมอร์ที่เอา AI มาช่วยเขียนโค้ดที่จะรันในระบบจริง กับผู้บริหารที่จะอนุมัติว่าบริษัทจะเอา AI ไปตัดสินใจเรื่องอะไรบ้าง สามคนนี้ “เสี่ยงคนละเรื่อง” จะอบรมด้วยสไลด์ชุดเดียวกันได้ยังไง
ผมขอเรียบเรียงเป็น 4 กลุ่มผู้ฟัง พร้อม “ความลึกของเนื้อหา” ที่แต่ละกลุ่มต้องการ (ตำราเน้นว่าทีม security/dev ต้องการเนื้อหาเทคนิคเพิ่ม ส่วนนี้ผมขยายให้เห็นภาพทั้งบริษัท):
| กลุ่มผู้ฟัง | ใช้ AI ทำอะไร | ความเสี่ยงหลักของกลุ่มนี้ | เนื้อหาที่ต้องเน้น |
|---|---|---|---|
| พนักงานทั่วไป | ใช้ AI ช่วยงานประจำ — ร่างข้อความ สรุปเอกสาร ตอบลูกค้า | เผลอเอาข้อมูลลับไปวาง / เชื่อคำตอบที่ผิด | เส้นแดงเรื่องข้อมูล + “อย่าเชื่อทุกอย่างที่ AI ตอบ” + ช่องทางถามเมื่อไม่แน่ใจ |
| ทีมพัฒนา (dev) และทีมความปลอดภัย | สร้าง/ติดตั้ง/ดูแลระบบ AI | ฝัง model ที่มีช่องโหว่ / ไม่รู้ทันภัยเทคนิค (prompt injection, data poisoning) | เนื้อหาเทคนิคลึก — ภัยจริงจากกรอบอย่าง OWASP/ATLAS, วิธีเทสต์, วิธีเฝ้าดู |
| ผู้บริหารและคนอนุมัติ | ตัดสินใจว่าจะใช้ AI กับงานอะไร อนุมัติงบ รับความเสี่ยง | อนุมัติใช้ AI กับงานที่ไม่ควร / ไม่รู้ว่าต้องถามอะไรก่อนอนุมัติ | มุมความเสี่ยง+กฎหมาย+จริยธรรมระดับตัดสินใจ, รู้ว่า “งานไหนห้ามใช้ AI ที่อธิบายไม่ได้” |
| ฝ่ายกฎหมาย/compliance/HR | ดูสัญญา ดูกฎ ดูเรื่องคน | ตามกฎ AI ใหม่ไม่ทัน / มองข้ามเรื่องลิขสิทธิ์และความเป็นส่วนตัว | เนื้อหาเรื่องกฎหมาย ลิขสิทธิ์ ความเป็นส่วนตัว และการจ้างคนทักษะ AI |
มุมผู้บริหาร: การแบ่งกลุ่มแบบนี้ไม่ได้แปลว่าต้องทำหลักสูตร 4 ชุดแยกขาดจากกัน — แต่แปลว่าควรมี “แกนกลางที่ทุกคนต้องรู้เหมือนกัน” (เส้นแดงเรื่องข้อมูล, อย่าเชื่อ AI ดิบๆ) แล้ว “ต่อยอดเฉพาะกลุ่ม” ตามความเสี่ยงที่เขาก่อ คำถามที่เราควรถามทีมที่จัดอบรมคือ “หลักสูตรเรามีส่วนที่แยกตามกลุ่มผู้ฟังไหม หรือยัดสไลด์ชุดเดียวให้ทุกคน” — ถ้าใช้ชุดเดียว แปลว่าทีมเทคนิคจะเบื่อเพราะตื้นไป ส่วนพนักงานทั่วไปจะหลับเพราะลึกเกิน สุดท้ายไม่มีใครได้อะไร
วัดผลยังไงว่า “อบรมแล้วได้ผลจริง” — ไม่ใช่นับหัวคนเข้าอบรม
นี่คือคำถามที่คนบริหารต้องถามต่อ “ใช้เงินอบรมไปแล้ว รู้ได้ยังไงว่ามันคุ้ม” เพราะถ้าวัดไม่ได้ มันก็จะกลายเป็น “พิธีกรรมราคาแพง” ที่ทำไปเพื่อให้มีหลักฐานว่าทำ
ตำรา AAISM พูดถึงการวัดผล awareness training ไว้ในกลุ่ม metric ความปลอดภัย AI (ตัวชี้วัด) แกนสำคัญคือ อย่าวัดแค่ว่า “มีกี่คนเข้าอบรม” เพราะจำนวนคนเข้าอบรมไม่ได้บอกอะไรเลยว่าพวกเขา “เปลี่ยนพฤติกรรม” หรือเปล่า
ผมเรียบเรียงสิ่งที่ควรวัดออกเป็น 3 ชั้น เรียงจากชั้นที่วัดง่ายแต่บอกอะไรน้อย ไปถึงชั้นที่วัดยากแต่บอกความจริง:
| ชั้นการวัด | วัดอะไร | บอกอะไรได้ | ข้อควรระวัง |
|---|---|---|---|
| ชั้น 1 — การมีส่วนร่วม (engagement) | กี่คนเข้าอบรม เข้าครบไหม ตั้งใจไหม | บอกแค่ “คนมา” — ขั้นต่ำสุด | คนมานั่งครบ ไม่ได้แปลว่าเขาเข้าใจหรือจะเปลี่ยน |
| ชั้น 2 — ความรู้ที่เพิ่มขึ้น (knowledge improvement) | ก่อน/หลังอบรม ความรู้เพิ่มขึ้นจริงไหม (เทียบคะแนนทดสอบก่อน-หลัง) | บอกว่า “เขารู้เพิ่ม” — ดีขึ้นมาหน่อย | รู้ในห้องสอบ ไม่ได้แปลว่าจะทำตอนทำงานจริง |
| ชั้น 3 — พฤติกรรมที่เปลี่ยน (behavior change) | พฤติกรรมจริงตอนทำงานเปลี่ยนไหม — เช่น คนแอบเอาข้อมูลไปวางใน AI สาธารณะลดลงไหม | บอก “ความจริง” — นี่คือชั้นที่ตำราชี้ว่าสำคัญที่สุด | วัดยากที่สุด ต้องดูจากพฤติกรรมจริง ไม่ใช่คำพูด |
นอกจากนี้ตำรายังเน้นอีกสองอย่างที่คนบริหารต้องดู:
หนึ่ง — หลักสูตรต้องอัปเดตและยังตรงกับความจริง (relevance) หลักสูตรที่อบรมเรื่องเครื่องมือ AI ที่บริษัทเลิกใช้ไปแล้ว หรือไม่พูดถึงภัยใหม่ที่เพิ่งโผล่ ก็ไร้ประโยชน์ ต้องมีรอบทบทวนว่าเนื้อหายังทันสมัยไหม
สอง — วิธีพิสูจน์ว่า awareness ได้ผลจริง คือ “การจำลองการโจมตี” ตำราพูดถึงการใช้ phishing simulation (การจำลองส่งอีเมลหลอกลวง) เพื่อทดสอบว่าพนักงานที่อบรมไปแล้ว “ติดกับดักจริงไหม” ในยุค AI เรื่องนี้ยิ่งสำคัญ เพราะมิจฉาชีพเอา AI มาช่วยปลอมอีเมล ปลอมเสียง ปลอมวิดีโอ (deepfake) ได้แนบเนียนกว่าเดิมมาก การซ้อมจึงเป็นวิธีเดียวที่จะรู้ว่าพนักงาน “พร้อมจริงหรือแค่ผ่านข้อสอบ”
มุมผู้บริหาร: ถ้าจะเลือก metric เดียวมาดูแบบจริงจัง ให้เลือก “พฤติกรรมที่เปลี่ยน” (ชั้น 3) เพราะมันคือสิ่งเดียวที่ป้องกันความเสียหายจริง — ตัวเลข “เข้าอบรมครบทุกคน” สวยงามแต่หลอกตัวเอง วิธีง่ายๆ ที่เจ้าของกิจการเอาไปใช้ได้คือ ตั้งคำถามกับทีม IT ว่า “เดือนที่แล้วมีเหตุพนักงานเอาข้อมูลไปวางในเครื่องมือ AI ที่ไม่ได้รับอนุมัติกี่ครั้ง และตัวเลขนี้ลดลงหลังอบรมไหม” — ถ้าตอบไม่ได้ แปลว่าเรายัง “วัดผลจริง” ไม่ได้ และอาจกำลังจ่ายเงินอบรมแบบสุ่มสี่สุ่มห้า
ลองเดินตาม tabletop หนึ่งรอบ — ซ้อมก่อนเจอจริง
ตำราจัด tabletop exercise (การซ้อมรับมือบนโต๊ะ) ไว้เป็นองค์ประกอบหลักของหลักสูตร แต่หลายคนยังนึกไม่ออกว่ามันหน้าตาเป็นยังไง ผมขอพาเดินตามหนึ่งรอบแบบสมมติ (ย้ำว่าสมมติขึ้นเพื่อให้เห็นภาพ ไม่ใช่เหตุการณ์จริง) เพื่อให้เจ้าของกิจการเห็นว่าทำไมมันถึงสำคัญกว่าการนั่งฟังบรรยาย
ฉากสมมติ: บริษัทบริการลูกค้าแห่งหนึ่งใช้ AI ตอบแชตลูกค้าอัตโนมัติ อยู่มาวันหนึ่ง ลูกค้ารายหนึ่งพิมพ์ข้อความแปลกๆ เข้ามา หลอกให้ AI “ลืมกฎที่ตั้งไว้” แล้ว AI ก็เผลอเปิดเผยข้อมูลโปรโมชันลับและข้อมูลของลูกค้ารายอื่นออกมา พนักงานเพิ่งมารู้ตอนลูกค้าอีกคนแคปหน้าจอมาถาม
ทีนี้ในห้องซ้อม เราจะโยนคำถามให้แต่ละฝ่ายตอบ “บนกระดาษ” ว่าจะทำอะไร:
| คำถามในห้องซ้อม | ฝ่ายที่ต้องตอบ | สิ่งที่การซ้อมจะเผยให้เห็น |
|---|---|---|
| ใครเป็นคนแรกที่ควรสังเกตเห็น แล้วต้องแจ้งใคร? | พนักงานหน้างาน + IT | บริษัทมีช่องทางแจ้งเหตุ AI ไหม หรือไม่มีใครรู้ว่าต้องบอกใคร |
| ต้องปิดระบบ AI ทันทีไหม หรือปล่อยให้ทำงานต่อ? | IT + ผู้บริหาร | ใครมีอำนาจสั่งปิด และปิดแล้วงานบริการลูกค้าจะสะดุดแค่ไหน |
| ข้อมูลลูกค้าที่หลุดไป ต้องแจ้งใครตามกฎหมายไหม ภายในกี่วัน? | กฎหมาย + compliance | ทีมรู้ภาระตามกฎหมายคุ้มครองข้อมูลไหม หรือเพิ่งมารู้ตอนนั้น |
| จะสื่อสารกับลูกค้าและสาธารณะยังไง? | ฝ่ายสื่อสาร + ผู้บริหาร | มีคนเตรียมรับมือสื่อไหม หรือปล่อยให้ลามเป็นวิกฤตชื่อเสียง |
| จะแก้ที่ตัว AI ยังไงไม่ให้เกิดซ้ำ? | dev + security | ทีมเข้าใจช่องโหว่ (การหลอก AI ให้ลืมกฎ) จริงไหม หรือแก้แบบเดาๆ |
เห็นไหมครับว่าการซ้อมแค่รอบเดียว มันเผยให้เห็น “รูรั่วในกระบวนการ” ที่การนั่งฟังบรรยายไม่มีวันเห็น เช่น พบว่าไม่มีใครมีอำนาจสั่งปิดระบบ หรือไม่มีใครรู้กำหนดเวลาแจ้งเหตุข้อมูลรั่วตามกฎหมาย จุดที่ตำราเน้นคือ tabletop ทำให้เรารู้ปัญหา “ตอนยังไม่มีอะไรเสียหายจริง” ดีกว่าไปรู้ตอนเกิดเหตุแล้วทุกคนตื่นตระหนก
มุมผู้บริหาร: คุณค่าจริงของ tabletop ไม่ได้อยู่ที่ “ซ้อมให้ตอบถูก” แต่อยู่ที่ “เจอคำถามที่ตอบไม่ได้” — ทุกครั้งที่ห้องเงียบเพราะไม่มีใครรู้ว่าใครรับผิดชอบ นั่นคือช่องโหว่ที่เพิ่งค้นพบฟรีๆ หน้าที่ของผู้บริหารในห้องซ้อมคือสังเกตว่า “คำถามไหนที่ทีมอึ้ง” แล้วเอาไปอุดเป็นกระบวนการจริงหลังซ้อมจบ — ถ้าซ้อมแล้วตอบได้หมดทุกข้ออย่างราบรื่น อาจแปลว่าโจทย์ง่ายเกินไป ไม่ใช่ว่าเราพร้อมจริง
เชื่อมเข้ากับนโยบายการใช้ AI — อบรมต้องไม่ลอยจาก policy
จุดที่ตำราย้ำและคนบริหารควรเข้าใจคือ awareness training ไม่ได้อยู่ลอยๆ มันต้องผูกกับ นโยบายการใช้ AI ที่ยอมรับได้ (AI acceptable use policy คือแนวทางว่า “ใช้ AI แบบไหนได้ แบบไหนห้าม”) ที่บริษัทตั้งไว้
แต่นี่คือจุดสำคัญ อบรมไม่ใช่แค่ “อ่าน policy ให้ฟัง” ความสัมพันธ์ที่ถูกต้องคือ:
- policy = บอกว่า “อะไรทำได้ อะไรทำไม่ได้” (กฎ)
- awareness training = ทำให้พนักงาน “เข้าใจว่าทำไม และทำเป็นจริงๆ” (ทักษะ + ทัศนคติ)
ถ้ามีแค่ policy แต่ไม่มีการอบรมให้เข้าใจ พนักงานก็จะมองเป็นแค่เอกสารที่ต้องเซ็นรับทราบแล้วลืม ถ้ามีแต่อบรมแต่ policy ไม่ชัด พนักงานก็จะสับสนว่าตกลง “ทำได้แค่ไหนกันแน่” สองอันนี้ต้องไปด้วยกัน และตำราย้ำว่า ผู้นำต้องทำให้นโยบายเก่ากับใหม่สอดคล้องกัน ไม่ใช่ออก policy AI ใหม่ที่ขัดกับ policy ความปลอดภัยเดิมจนพนักงานงง
มุมผู้บริหาร: สัญญาณอันตรายคือเวลาพนักงานถามว่า “ใช้ AI ตัวนี้กับข้อมูลลูกค้าได้ไหม” แล้วไม่มีใครตอบได้ชัด — นั่นแปลว่า policy กับ awareness ของเรายังไม่เชื่อมกัน หน้าที่ของเราไม่ใช่ตอบทุกคำถามเอง แต่คือ ทำให้ระบบมันตอบได้ — policy ชัดพอที่พนักงานเปิดดูแล้วรู้ และอบรมดีพอที่เขาจำได้ว่าต้องไปเปิดดูตรงไหน
ครึ่งหลัง — ช่องว่างทักษะ (AI Skills Gap) : บริษัทเรามีคน “คุม AI เป็น” หรือยัง
ทีนี้มาถึงอีกด้านของเรื่อง “คน” ที่ผมเกริ่นไว้ตอนต้น และเป็นด้านที่ผมว่าเจ้าของกิจการไทยพลาดกันเยอะมาก
awareness training ที่เล่ามาทั้งหมดข้างบน เป็นเรื่องของ “พนักงานทั่วไปใช้ AI อย่างปลอดภัย” แต่ยังมีคำถามที่ใหญ่กว่านั้น และมักถูกลืม:
“บริษัทเรามีคนที่เก่งพอจะ ออกแบบ พัฒนา ติดตั้ง ประเมิน และเฝ้าดู ระบบ AI หรือยัง?”
ลองนึกภาพแบบนี้ สมมติว่าบริษัทแห่งหนึ่ง ผู้บริหารไปประชุม ไปงานสัมมนา กลับมาตื่นเต้นมาก สั่งทีมว่า “เราต้องมี AI! คู่แข่งเขามีกันหมดแล้ว เริ่มเลยเดือนนี้!” ทีมก็รับคำสั่งมา แต่พอลงมือจริงถึงรู้ว่า ไม่มีใครในบริษัทรู้เลยว่าจะคุมมันยังไงให้ปลอดภัย ไม่มีใครรู้ว่าจะเลือก model แบบไหน จะตรวจว่ามันลำเอียงไหมยังไง จะดูออกไหมว่ามันเริ่มเพี้ยน
นี่แหละครับคือ AI Skills Gap ช่องว่างระหว่าง “AI ที่บริษัทอยากใช้” กับ “ความสามารถจริงของคนในบริษัทที่จะคุมมันได้”
และตำราชี้ตรงจุดที่เจ็บที่สุด “การตัดสินใจเรื่องการใช้ AI ส่วนใหญ่มาจากผู้บริหาร โดยไม่ได้คิดถึงทักษะที่จำเป็นต้องใช้รองรับมัน” พูดง่ายๆ คือ สั่งซื้อมาก่อน แล้วค่อยมาหาคนคุมทีหลัง ซึ่งคือลำดับที่กลับหัว
มุมผู้บริหาร: ข้อนี้ตำราชี้นิ้วมาที่ “ผู้บริหาร” ตรงๆ เลยครับ ว่าเป็นต้นตอของปัญหา — เพราะคนที่ตัดสินใจซื้อ/ใช้ AI มักไม่ใช่คนที่ต้องลงมือคุมมัน เลยมองข้ามคำถามว่า “เรามีคนคุมเป็นไหม” คำถามที่เราควรถามตัวเอง ก่อน สั่งเดินหน้าโครงการ AI คือ — “ถ้า AI ตัวนี้ทำงานเพี้ยน วันนั้นใครในบริษัทเราจะดูออก และจะแก้เป็น?” ถ้าตอบไม่ได้ แปลว่าเรากำลังจะรับ “พนักงานใหม่เก่งๆ” เข้ามาทั้งที่ไม่มีหัวหน้างานที่คุมเขาเป็น
ก่อนหาคน — ต้องรู้ก่อนว่า “ต้องการทักษะอะไร” ในแต่ละขั้นของ AI
ตำราตั้งคำถามไว้คมมากว่า “องค์กรจะรู้ได้ยังไงว่าต้องการทักษะและประสบการณ์อะไร เพื่อมา ออกแบบ พัฒนา ติดตั้ง ประเมิน และเฝ้าดู ระบบ AI?” สังเกตว่าตำราไล่เป็น 5 ขั้น ไม่ใช่ก้อนเดียว เพราะแต่ละขั้นต้องการคนทักษะคนละแบบ
ปัญหาของการ “หาคน AI” แบบเหมารวมคือ บริษัทมักนึกว่ามี “คน AI” คนเดียวเก่งครบทุกขั้น ซึ่งไม่จริง ผมขอแตกออกตาม 5 ขั้นที่ตำราระบุ เพื่อให้เจ้าของกิจการเห็นว่าจริงๆ แล้วเรากำลังหา “ทักษะอะไรบ้าง”:
| ขั้นในวงจร AI | ทักษะที่ต้องการ (ภาษาคน) | คำถามที่ผู้บริหารใช้เช็กว่าเรามีคนพอไหม |
|---|---|---|
| ออกแบบ (design) | คนที่เข้าใจว่า “งานนี้ควรใช้ AI แบบไหน หรือไม่ควรใช้เลย" | "เรามีคนที่บอกได้ไหมว่างานไหนเหมาะกับ AI งานไหนเสี่ยงเกิน?” |
| พัฒนา/เลือก (develop) | คนที่เลือก/ปรับ model ได้ หรือประเมิน model ของ vendor เป็น | ”ถ้า vendor เสนอ model มา 3 ตัว เรามีคนเทียบเป็นไหม?” |
| ติดตั้ง (deploy) | คนที่เอา AI ไปเชื่อมกับระบบจริงได้อย่างปลอดภัย | ”เรามีคนที่รู้ว่าต่อ AI เข้าระบบแล้วต้องปิดช่องโหว่ตรงไหน?” |
| ประเมิน (assess) | คนที่ตรวจได้ว่า AI ลำเอียงไหม ปลอดภัยไหม อธิบายผลได้ไหม | ”ใครในบริษัทตรวจได้ว่า AI ตัวนี้ลำเอียงกับลูกค้าบางกลุ่ม?” |
| เฝ้าดู (monitor) | คนที่อ่าน alert เป็น ดูออกว่า model เริ่มเพี้ยน (drift) | “ถ้า AI เริ่มแม่นน้อยลงเรื่อยๆ ใครจะเป็นคนจับสัญญาณได้?” |
พอแตกออกแบบนี้ เจ้าของกิจการมักจะเห็นทันทีว่าบริษัทอาจมีคนเก่งบางขั้น แต่ขาดบางขั้นชัดเจน เช่น มีคนพัฒนาเก่ง แต่ไม่มีใคร “ประเมินเรื่อง bias” เป็นเลย ซึ่งเป็นช่องว่างที่อันตราย เพราะ AI ที่ลำเอียงจะสร้างปัญหาทั้งด้านกฎหมายและชื่อเสียง
มุมผู้บริหาร: วิธีใช้ตารางนี้จริง คือเอาไปทำ “แผนที่ทักษะ” ของบริษัท — ขีดตรงขั้นที่เรามีคนพอ (เขียว) ขั้นที่มีแต่ไม่แน่น (เหลือง) และขั้นที่ไม่มีใครเลย (แดง) ช่องสีแดงคือสิ่งที่ต้อง recruit หรือ develop ก่อนเดินหน้าโครงการ — ไม่ใช่หลังจากระบบพังแล้วค่อยมาหา ที่สำคัญ ขั้น “ประเมิน” และ “เฝ้าดู” มักเป็นสีแดงที่บริษัทมองข้าม เพราะตอนซื้อ AI ทุกคนตื่นเต้นกับขั้น “พัฒนา/ติดตั้ง” แต่ลืมว่าของพวกนี้ต้องมีคนคอย “ตรวจและเฝ้า” ไปตลอดอายุการใช้งาน
บริษัทต้องทำอะไรกับช่องว่างนี้ — recruit, develop, retain
ตำราให้แนวทางจัดการ skills gap ไว้ ผมเรียบเรียงเป็น 3 เสาที่คนบริหารต้องคิดพร้อมกัน:
| เสา | ความหมาย (ภาษาคน) | สิ่งที่คนบริหารต้องตัดสินใจ |
|---|---|---|
| Recruit (หาคนเข้ามา) | จ้างคนที่มีทักษะ AI เข้ามาเสริม | จะจ้างเพิ่ม จะจ้าง outsource หรือจะดึงจากที่ปรึกษา — และที่สำคัญ คนที่หามาต้องมี “พื้นเพ ประสบการณ์ และมุมมองที่สะท้อนกลุ่มคนที่ AI จะไปกระทบ” ด้วย |
| Develop (พัฒนาคนเดิม) | อบรมพนักงานที่มีอยู่ให้คุม AI ได้ — โดยเฉพาะทีมความปลอดภัยและทีมพัฒนา | จัดงบและเวลาให้ทีม security/dev ได้เรียนรู้เพิ่มเรื่อง AI โดยเฉพาะ ไม่ใช่ปล่อยให้เรียนเอง |
| Retain (รักษาคนไว้) | คนเก่งด้าน AI หายาก จ้างมาแล้วต้องรักษาไว้ให้อยู่ | คิดเรื่องการดูแลรักษาคนกลุ่มนี้ตั้งแต่ต้น ไม่ใช่จ้างมาแล้วปล่อยให้ลาออก แล้วช่องว่างก็กลับมาเหมือนเดิม |
จุดที่ตำราเน้นเป็นพิเศษในเสา “Recruit” คือ คนที่หามา ต้องสะท้อนกลุ่มผู้ใช้ที่ AI จะไปกระทบ ฟังดูเป็นนามธรรม แต่แปลเป็นรูปธรรมง่ายๆ คือ ถ้า AI ของเราจะไปให้บริการลูกค้าหลากหลายกลุ่ม แต่ทีมที่สร้าง/คุมมันมาจากภูมิหลังแบบเดียวกันหมด ทีมนั้นอาจมองไม่เห็นว่า AI กำลังลำเอียงกับลูกค้าบางกลุ่ม เพราะไม่มีใครในทีม “อยู่ในมุมของกลุ่มนั้น” ความหลากหลายของทีมจึงไม่ใช่เรื่อง “ความถูกต้องทางการเมือง” แต่เป็น control เรื่อง bias โดยตรง
ทีนี้ในทางปฏิบัติ เจ้าของกิจการมักต้องเลือกว่า ช่องว่างทักษะที่เจอ จะอุดด้วยวิธีไหนใน 3 ทาง และแต่ละทางมีจังหวะที่เหมาะต่างกัน ผมขอเทียบให้เห็น (ส่วนนี้ผมขยายจากกรอบ recruit/develop ของตำราให้เป็นตัวเลือกที่ตัดสินใจได้จริง):
| ทางเลือก | เหมาะเมื่อ | ข้อควรระวัง |
|---|---|---|
| อบรมคนเดิม (develop) | ทักษะที่ขาดเป็นเรื่อง “ต่อยอดจากที่ทีมมีอยู่แล้ว” เช่น ทีม security เดิมที่แค่ต้องรู้ภัย AI เพิ่ม | ใช้เวลา — ต้องวางแผนล่วงหน้า ไม่ทันใช้ถ้าโครงการเร่ง และต้องมีงบ+เวลาจริง ไม่ใช่ปล่อยให้เรียนเองนอกเวลางาน |
| จ้างคนใหม่ (recruit) | ทักษะที่ขาด “ไม่มีในบริษัทเลย” และเป็นหัวใจระยะยาว เช่น คนประเมิน bias | หายากและแพง ตั้งสเปกสูงเกินจะหาไม่ได้ และจ้างมาแล้วต้องมีงานให้ทำต่อเนื่อง ไม่งั้นเขาจะลาออก |
| จ้างที่ปรึกษา/outsource | ต้องการทักษะ “เฉพาะช่วง” เช่น ตอนตั้งระบบครั้งแรก หรือตอนประเมินก่อนใช้งานจริง | พึ่งคนนอกระยะยาวอันตราย — ความรู้ไม่ตกอยู่กับบริษัท พอเขาไป เราก็คุมเองไม่เป็นเหมือนเดิม ควรให้เขา “สอนคนเราไปด้วย” |
มุมผู้บริหาร: กับดักที่พบบ่อยคือเลือก “จ้างที่ปรึกษา” เพราะเร็วและไม่ต้องผูกมัดระยะยาว — แต่แล้วไม่เคยให้ความรู้ตกอยู่กับทีมในบ้าน พอที่ปรึกษาจบงานกลับไป บริษัทก็กลับมามีช่องว่างทักษะเท่าเดิม วนลูปจ้างใหม่ไปเรื่อยๆ หลักที่ปลอดภัยคือ — ทักษะที่เป็นหัวใจและต้องใช้ตลอด (เช่น เฝ้าดู AI) ควรอยู่ในบ้าน ส่วนทักษะที่ใช้เป็นช่วงๆ ค่อยจ้างนอก และไม่ว่าจะจ้างนอกเรื่องไหน ให้ใส่เงื่อนไข “ถ่ายทอดความรู้ให้ทีมเรา” ลงไปด้วยเสมอ
”ลงทุนกับ AI ต้องลงทุนกับคนด้วย” — และอย่าตั้งความหวังผิด
ตำราพูดประโยคที่ผมว่าคมมาก ถ้าบริษัทจะตัดสินใจเอา AI เข้ามาในการทำงานจริง มันก็ “ต้องลงทุนอบรมพนักงานที่มีอยู่ด้วย” เพื่อให้ทำสิ่งที่ถูกต้องและรับผิดชอบ ไม่ใช่ซื้อแต่ของแล้วหวังว่าคนจะคุมเป็นเอง
และมีอีกประเด็นที่เป็นกับดักการจ้างงานโดยเฉพาะ อย่าตั้งสเปกการจ้างคน AI สูงเกินจริง ตำราเตือนว่า ให้ “บริหารความคาดหวังในการคัดคนใหม่ และตั้งความคาดหวังที่สมเหตุสมผล”
กับดักที่พบบ่อย — “ขอคนมีประสบการณ์ AI 10 ปี”: หลายบริษัทเปิดรับสมัครคน AI แล้วเขียนสเปกว่า “ต้องมีประสบการณ์ตรง 10 ปี” — ซึ่งตำราชี้ว่าไม่สมเหตุสมผล เพราะถึงแม้ AI จะมีมานานในเชิงวิชาการ แต่ “การเอา AI มาใช้ทำธุรกิจจริงๆ มันยังอยู่ในช่วงเริ่มต้นมาก” (ตำราใช้คำว่า “still in its infancy” — ยังเป็นทารกอยู่เลย) คนที่มีประสบการณ์ทำ AI ในงานจริง 10 ปีแทบไม่มีในตลาด การตั้งสเปกแบบนี้จะทำให้หาคนไม่ได้สักที แล้วโครงการก็ค้าง ทางแก้คือมองหา “คนที่มีพื้นฐานดีและเรียนรู้เร็ว” มากกว่าจะรอ “ผู้เชี่ยวชาญในตำนาน” ที่ไม่มีจริง
จุดสุดท้ายที่ตำราเชื่อมให้เห็นภาพใหญ่ คือเรื่อง skills gap นี้ ไม่ใช่เรื่องของ HR ฝ่ายเดียว มันต้องถูกใส่เข้าไปใน 2 ที่:
- โปรแกรมกำกับดูแล AI (AI governance program) คือต้องถือว่า “เรามีคนพอจะคุม AI ไหม” เป็นส่วนหนึ่งของการกำกับ ไม่ใช่เรื่องแยก
- ตอนกำหนดความต้องการของสถาปัตยกรรมความปลอดภัย AI ใหม่ คือเวลาออกแบบระบบความปลอดภัย AI ต้องถามตั้งแต่ต้นว่า “ระบบนี้ต้องใช้คนทักษะแบบไหนมาดูแล” ไม่ใช่ออกแบบระบบเสร็จแล้วเพิ่งมาคิดว่าใครจะคุม
มุมผู้บริหาร: วิธีคิดที่ถูกต้องคือ — “คน” เป็นส่วนหนึ่งของ control ตั้งแต่วันออกแบบ ไม่ใช่ของที่หาเพิ่มทีหลัง เวลาเราอนุมัติโครงการ AI ใหม่ คำถามที่ต้องอยู่ในเอกสารอนุมัติคือ “โครงการนี้ต้องใช้คนทักษะอะไรบ้าง เรามีอยู่กี่คน ขาดกี่คน จะหามาจากไหน และใช้งบเท่าไหร่” — ถ้าเอกสารอนุมัติโครงการ AI ของบริษัทเราไม่มีหัวข้อนี้ แปลว่าเรากำลังลงทุนแบบมองไม่เห็นต้นทุนที่แท้จริง
กรอบสากลที่หยิบมาเสริมได้
เรื่อง awareness และ skills gap นี้ มีกรอบสาธารณะที่เจ้าของกิจการเอาไปอ้างอิงต่อได้ฟรี ไม่ต้องเสียเงิน:
- NIST AI RMF (AI Risk Management Framework ของสถาบันมาตรฐานสหรัฐฯ) — มีส่วนที่พูดถึง “วัฒนธรรมและทักษะของคน” ในการบริหารความเสี่ยง AI โดยตรง ใช้เป็นเช็กลิสต์ว่าองค์กรเราคิดเรื่อง “คน” ครบไหม
- MITRE ATLAS — ฐานข้อมูลสาธารณะที่รวบรวม “เทคนิคการโจมตี AI” ที่เกิดจริง ทีม security เอาไปใช้ออกแบบเนื้อหาอบรมเรื่อง adversarial AI ให้ตรงกับภัยจริง
- OWASP Top 10 for LLM — รายการความเสี่ยงยอดฮิตของระบบ AI ประเภทสร้างข้อความ (เช่น prompt injection) เหมาะเอาไปทำเนื้อหาอบรมให้ทีมพัฒนาเข้าใจภัยที่พบบ่อย
ข้อดีของการอิงกรอบพวกนี้คือ — เวลาออกแบบหลักสูตรอบรม เราไม่ต้องนั่งเดาเองว่า “ควรสอนเรื่องอะไร” แต่หยิบรายการภัยจริงจากกรอบสากลมาเป็นโครง แล้วแปลเป็นภาษาคนให้พนักงานเข้าใจ
เช็กลิสต์สั้นๆ ที่เจ้าของกิจการเอาไปใช้ได้เลย
ก่อนสรุป ผมขอรวบเป็นคำถามสั้นๆ ที่เจ้าของกิจการเอาไปยิงใส่ทีมตัวเองได้ทันที — ถ้าตอบ “ไม่” หรือ “ไม่รู้” ข้อไหน นั่นคือช่องว่างที่ต้องอุด:
| ด้าน | คำถามที่ผู้บริหารใช้ตรวจตัวเอง | ตอบ “ไม่” แปลว่า |
|---|---|---|
| ความต่อเนื่อง | เราอบรมเรื่อง AI มากกว่าปีละครั้งไหม มีอัปเดตเมื่อมีภัยใหม่ไหม | หลักสูตรเราล้าสมัยและคนลืมไปแล้ว |
| ความครบ | หลักสูตรครอบทั้ง 4 กลุ่ม (กติกา + อ่านผล + รู้ทันภัย + ฝึกมือ) ไหม | มีรูโหว่ในเนื้อหา คนรู้ไม่ครบ |
| แยกกลุ่ม | เนื้อหาแยกตามกลุ่มผู้ฟังไหม (ทั่วไป/dev/ผู้บริหาร/กฎหมาย) | คนเทคนิคเบื่อ คนทั่วไปหลับ ไม่ได้ผลทั้งคู่ |
| วัดผลจริง | เราวัดที่ “พฤติกรรมเปลี่ยน” ไม่ใช่แค่ “คนเข้าครบ” ไหม | เราหลอกตัวเองว่าได้ผล ทั้งที่ยังวัดความจริงไม่ได้ |
| ผูกกับ policy | นโยบายการใช้ AI ชัดพอที่พนักงานเปิดดูแล้วรู้ไหม | คนจะใช้แบบเดาเอง เกิด shadow IT |
| ซ้อมจริง | เคยซ้อม tabletop โดยมีผู้บริหารและฝ่ายกฎหมายร่วมไหม | พอเกิดเหตุจริงจะตัดสินใจช้าและมั่ว |
| แผนที่ทักษะ | เรารู้ไหมว่าขั้นไหนของ AI (ออกแบบ/พัฒนา/ติดตั้ง/ประเมิน/เฝ้าดู) ที่เราไม่มีคนเลย | กำลังเดินหน้าโครงการทั้งที่ไม่มีคนคุมบางขั้น |
| อนุมัติแบบเห็นต้นทุนคน | เอกสารอนุมัติโครงการ AI มีหัวข้อ “ต้องใช้คนทักษะอะไร ขาดกี่คน” ไหม | กำลังลงทุนแบบมองไม่เห็นต้นทุนจริง |
สรุปตอนนี้ — control ที่ถูกที่สุดคือ “คนที่รู้”
ปิดท้าย ขอรวบให้เห็นภาพเดียว ตอนนี้เราคุยกันเรื่อง control สองด้านที่ไม่ใช่เทคโนโลยี แต่เป็น “คน”:
- awareness training = ทำให้พนักงานทั่วไป “ใช้ AI อย่างปลอดภัย” ต้องทำต่อเนื่อง ไม่ใช่ปีละครั้ง, ต้องครบ 11 องค์ประกอบ (รู้กติกา + อ่านผลเป็น + รู้ทันภัย + ฝึกมือ), และต้องวัดที่ “พฤติกรรมที่เปลี่ยน” ไม่ใช่จำนวนคนเข้าอบรม
- skills gap = ทำให้บริษัทมี “คนที่คุม AI เป็น” อย่าสั่งซื้อ AI ก่อนแล้วหาคนทีหลัง, ต้อง recruit/develop/retain พร้อมกัน, ตั้งสเปกจ้างให้สมจริง, และใส่เรื่องนี้เข้าไปใน governance program ตั้งแต่ต้น
ทั้งสองอย่างนี้ ย้ำแว่นเดิมของซีรีส์ AI คือพนักงานใหม่เก่งๆ ที่เราต้องกำกับ และการกำกับที่ดีที่สุด ไม่ได้เริ่มที่ตัว AI แต่เริ่มที่ “คนรอบๆ AI” ทั้งเพื่อนร่วมงานที่รู้วิธีทำงานกับมัน และหัวหน้างานที่คุมมันเป็น
ตอนต่อไปใน Domain 3 เราจะขยับจากเรื่อง “คน” กลับไปที่ระบบอีกครั้ง ว่าหลังจาก AI เริ่มทำงานจริงแล้ว เราจะ เฝ้าดูมันต่อเนื่องยังไง ให้รู้ทันตอนมันเริ่มเพี้ยน (model drift) หรือตอนมีคนพยายามปั่นข้อมูลฝึกของมัน เรื่อง continuous monitoring ที่ทำให้ “พนักงานใหม่เก่งๆ” คนนี้อยู่ในสายตาเราตลอดเวลา
อ้างอิงเนื้อหาต้นทาง: AAISM Review Manual — Domain 3: AI Technologies and Controls, Section 3.11 (AI Security Awareness Training) และ 3.11.1 (Addressing AI Skills Gaps). กรอบสาธารณะที่อ้างถึง: NIST AI Risk Management Framework, MITRE ATLAS, OWASP Top 10 for LLM Applications.
