สารบัญ
AAISM Series — คู่มือคุม AI ในมุมคนบริหาร (ไม่ใช่มุมผู้ตรวจ) ตอนที่ 22 / Domain 2 — AI Risk & Opportunity Management ซีรีส์นี้เล่าจากมุม “เจ้าของกิจการ / CISO ที่เอา AI มาใช้จริง” ว่าต้องตัดสินใจอะไรและรับความเสี่ยงเอง (สารบัญเต็มจะตามมา)
📚 ตอนนี้คำว่า “vendor management” จะโผล่มาเยอะ ใครยังไม่แม่นว่า “การคุมคนขาย / คุม outsourcing” พื้นฐานมันทำกันยังไง — เรื่อง โอนงานให้คนอื่นทำได้ แต่โอนความรับผิดชอบไม่ได้ เนี่ย ผมเล่าไว้ละเอียดมากแล้วในซีรีส์ CISA Domain 2 ตอนที่ 19 — Vendor Management ทั้งเรื่อง SLA, รายงาน SOC, สัญญา, right-to-audit, การดู vendor’s BCP ใครยังงงว่า “ทำไมจ้างเขาทำแล้วเรายังต้องรับผิด” แวะไปปูพื้นก่อนได้ครับ — ตอนนี้เราจะไม่สอนซ้ำ เราจะหยิบโครงเดิมนั้นมาใส่บริบท AI โดยเฉพาะ ว่ามันต่างจาก vendor ธรรมดายังไง และมีอะไรใหม่ที่ vendor ปกติไม่มี
ตอนก่อนๆ ใน Domain 2 เราคุยกันว่า “ความเสี่ยงของ AI หน้าตาเป็นยังไง” — ทั้งภัยคุกคาม การประเมินเสี่ยง การจัดระดับ และวิธีตอบสนอง (รับ/เลี่ยง/ลด/โอน) มาตอนนี้เราขยับมาที่ความจริงข้อหนึ่งที่เจ้าของกิจการส่วนใหญ่ทำใจไม่ค่อยได้ —
“AI ที่บริษัทเราใช้ ส่วนใหญ่ไม่ได้สร้างเอง และไม่ได้ตั้งใจซื้อด้วยซ้ำ — มันมากับคนขายที่เราใช้บริการอยู่แล้ว แล้วก็ ‘แถม’ ฟีเจอร์ AI เข้ามาเงียบๆ”
ลองนึกภาพโรงงานผลิตอาหารขนาดกลางแห่งหนึ่ง (สมมติขึ้นมาให้เห็นภาพนะครับ) ใช้โปรแกรมบัญชีเจ้าหนึ่งมาห้าปี ใช้ระบบ HR อีกเจ้า ใช้แอปแชตคุยงานอีกเจ้า อยู่มาวันหนึ่งโปรแกรมบัญชีอัปเดต แล้วมีปุ่ม “ให้ AI ช่วยสรุป/ช่วยทำนายยอด” โผล่มา พนักงานบัญชีก็กดใช้เพราะมันสะดวก โดยที่เจ้าของไม่รู้ว่า — ตอนกดปุ่มนั้น ข้อมูลการเงินทั้งบริษัทถูกส่งออกไปประมวลผลที่ไหน ใครได้เห็น และมันถูกเอาไปฝึกโมเดลของคนขายต่อหรือเปล่า
นี่แหละครับคือหัวใจของตอนนี้ — เราในฐานะ “คนใช้ AI ของคนอื่น” (ภาษาทางการเรียก deployer = ผู้นำ AI ไปใช้งาน) จะคุมคนขายที่เอา AI มาให้เรายังไง ทั้งตอนคัดเข้า ตอนใช้งานต่อเนื่อง และตอนเขียนสัญญา และที่สำคัญ — ทำไมความรับผิดชอบสุดท้ายยังตกที่เราอยู่ดี
ทบทวนแว่นที่เราใส่ — AI = พนักงานใหม่เก่งๆ ที่ต้องกำกับ
ทั้งซีรีส์นี้ผมชวนมองว่า AI = พนักงานใหม่เก่งสุดๆ คนหนึ่งที่เราต้องกำกับ ไม่ใช่เครื่องวิเศษที่เสกแล้วจบ
แต่ตอนนี้แว่นอันเดิมต้องปรับมุมนิดนึง — เพราะ AI ตัวนี้ “ไม่ใช่ลูกน้องเราโดยตรง” มันคือ คนเก่งที่บริษัทรับเหมา (vendor) ส่งมาทำงานในบ้านเรา เราไม่ได้สัมภาษณ์เองตั้งแต่ต้น ไม่ได้เทรนเอง ไม่รู้ประวัติเขาเต็มๆ รู้แค่ “บริษัทที่ส่งเขามาบอกว่าเขาเก่ง”
แล้วงานของคนบริหารตอนนี้คืออะไร? คือ มองให้ออกว่า “พนักงานรับเหมาคนนี้อาจทำพังตรงไหน” แล้วรับมือไว้ก่อน ไม่ใช่ไปนั่งจับผิดเขาทีหลัง — ย้ำว่าเราเป็น เจ้าของความเสี่ยง เราตัดสินใจเองว่าจะรับเขาเข้ามาไหม จะคุมเขายังไง และจะ treat (จัดการ) ความเสี่ยงด้วยวิธีไหน ไม่ใช่บทบาท “ผู้ตรวจ” ที่มาเดินดูแล้วเขียนรายงานส่ง — เราคือคนเซ็นชื่อรับผิดชอบ
เวลาเราจ้างบริษัทรับเหมาส่งคนมาทำงานในบ้าน เราจะถามอะไรบ้าง?
- บริษัทนี้น่าเชื่อถือไหม การเงินมั่นคงไหม จะเจ๊งทิ้งงานกลางคันหรือเปล่า
- คนที่ส่งมาเก่งจริงไหม เคยทำงานแบบเรามาก่อนไหม
- เขาจะเอาข้อมูลในบ้านเราไปทำอะไร เห็นความลับเราแค่ไหน
- ถ้าเขาทำพัง เขายอมให้เราเข้าไปตรวจไหม หรือปิดประตูไม่ให้ดู
- ถ้าวันหนึ่งเราอยากเลิกจ้าง เลิกได้ง่ายไหม หรือเขาผูกเราจนถอนตัวไม่ได้
คำถามชุดนี้แหละครับ คือทั้งตอนนี้ — แค่เราเอาไปจับกับ “พนักงานรับเหมาที่เป็น AI”
มุมผู้บริหาร: จุดที่คนพลาดบ่อยที่สุดคือคิดว่า “ก็จ่ายเงินซื้อ/ใช้บริการเขาแล้วนี่ ความเสี่ยงต้องเป็นของคนขายสิ” — ผิดครับ คุณจ่ายเงินซื้อ “บริการ” แต่คุณ ซื้อความรับผิดชอบทิ้งไม่ได้ ถ้า AI ของ vendor ทำข้อมูลลูกค้าเราหลุด คนที่ลูกค้าฟ้องคือเรา คนที่หน่วยงานกำกับเรียกไปคุยคือเรา ไม่ใช่ vendor หน้าที่ของเราจึงไม่ใช่ “ไว้ใจคนขาย” แต่คือ “ออกแบบว่าจะคุมคนขายยังไงให้ความเสี่ยงอยู่ในระดับที่เรารับได้”
ความเปลี่ยนแปลงใหญ่ — โปรแกรมคุม vendor เดิม “ไม่พอ” แล้วสำหรับยุค AI
เรื่องแรกที่ต้องเข้าใจ — บริษัทส่วนใหญ่มีโปรแกรมคุม vendor อยู่แล้ว (vendor management program) เป็นกระบวนการคัดคนขาย ทำสัญญา ต่อสัญญา ประเมินทุกปี ฯลฯ ตามที่ผมเล่าใน CISA Domain 2 ตอน 19
ปัญหาคือ — โปรแกรมเดิมพวกนั้นออกแบบมาก่อนยุค AI มันถามคำถามแบบ IT ทั่วไป เช่น “ระบบ uptime เท่าไหร่” “ข้อมูลเก็บที่ไหน” “เข้ารหัสไหม” แต่มัน ไม่ได้ถามคำถามที่ AI ต้องถาม เช่น “โมเดลคุณฝึกด้วยข้อมูลอะไร” “เอาข้อมูลที่เราป้อนไปฝึกต่อหรือเปล่า” “AI คุณตัดสินใจยังไง อธิบายได้ไหม”
และนี่คือจุดอันตรายที่สุด — vendor ที่เราใช้อยู่แล้ว กำลังยัดฟีเจอร์ AI เข้ามาเรื่อยๆ โดยที่เราไม่รู้ตัว
ทำไมเขาทำงั้น? เพราะคนขายอยากให้ของเขาดูดีขึ้น ขายง่ายขึ้น เพิ่มประสิทธิภาพให้ลูกค้า — เขาไม่ได้คิดร้าย แต่เขา ไม่ได้คิดถึงข้อกำหนดเฉพาะของบริษัทเรา เขาแค่ปล่อยอัปเดตให้ลูกค้าทุกรายเหมือนกันหมด แล้วฟีเจอร์ AI ใหม่นั้นก็เข้าบ้านเรามาฟรีๆ พร้อมความเสี่ยงที่ไม่มีใครประเมิน
ตำรา AAISM แยกความเสี่ยงที่มากับ “ฟีเจอร์ AI ใหม่ของ vendor เดิม” ออกเป็น 4 ด้าน ผมขอเล่าด้วยภาษาคนพร้อมตัวอย่างไทยสมมติ และที่สำคัญ — บอกว่าคนบริหารต้องสั่งทำอะไร:
| ความเสี่ยงที่มากับฟีเจอร์ AI ใหม่ | แปลเป็นภาษาคน + ตัวอย่าง (สมมติ) | คนบริหารต้องสั่งทำอะไร |
|---|---|---|
| เสี่ยงต่อธุรกิจ (Business risk) | ฟีเจอร์ใหม่อาจทำให้ขั้นตอนงานเดิมพังหรือต้องรื้อใหม่ทั้งหมด — โปรแกรม CRM สมมติ อัปเดตให้ AI จัดคิวลูกค้าใหม่อัตโนมัติ แต่ดันสลับลำดับงานทีมขายจนงานสะดุดทั้งแผนก | บังคับให้ vendor แจ้งล่วงหน้า ก่อนปล่อยฟีเจอร์ AI ใหม่ เพื่อให้เราประเมินได้ว่ามันจะกระทบงานเราไหม ก่อนมันจะถูกเปิดใช้ |
| เสี่ยงต่อความเป็นส่วนตัว (Privacy risk) | เราไม่รู้ว่าโมเดล vendor “ฝึกมาด้วยข้อมูลอะไร” และ “เอาข้อมูลเราไปฝึกต่อไหม” — ถ้าข้อมูลลูกค้าเราถูกดูดเข้าไปฝึกโมเดลกลาง อาจผิดกฎหมายคุ้มครองข้อมูลทันที | สั่งทีมไป ทำความเข้าใจว่าโมเดลฝึกด้วยอะไร และข้อมูลเราไหลไปไหน ก่อนปล่อยให้ใช้ — ถ้าตอบไม่ได้ ห้ามใช้กับข้อมูลส่วนบุคคล |
| เสี่ยงต่อความปลอดภัย (Security risk) | ฟีเจอร์ใหม่ = ช่องโหว่ใหม่ — vendor อาจปล่อยอัปเดต AI ที่ยังทดสอบความปลอดภัยไม่ดีพอ เปิดช่องให้ถูกโจมตี (เช่น prompt injection) | เรียก หลักประกันจาก vendor ว่าเขาทดสอบความปลอดภัยทุกครั้งที่เปลี่ยน AI ไม่ใช่ปล่อยของดิบมาให้ลูกค้าเสี่ยงเอง |
| ตามกฎที่เปลี่ยนตลอด (Compliance) | กฎหมาย AI ใหม่ๆ ออกเรื่อยๆ ในแต่ละประเทศ — vendor ตามทันไหม? ถ้าเขาไม่ตาม เราอาจโดนปรับทั้งที่เราไม่ได้ทำเอง | ตั้ง ทีมผสม (กฎหมาย + compliance + privacy + security) ไว้คอยดูว่า vendor ปรับตามกฎใหม่ทันไหม โดยเฉพาะถ้าทำธุรกิจข้ามประเทศ |
กับดักที่อันตรายที่สุด — “AI แอบเข้าบ้านผ่าน vendor เดิม”: เจ้าของกิจการมักระวังตอน “ตั้งใจซื้อ AI ใหม่” — แต่ลืมไปว่าฟีเจอร์ AI ที่เข้าบ้านมากที่สุดคือ ฟีเจอร์ที่ vendor เดิมแถมมาให้ โดยไม่มีใครกดอนุมัติ ของพวกนี้ไม่ผ่านกระบวนการคัดเลย เพราะมัน “อยู่ในของที่เราซื้อมาแล้ว” ทางแก้คือ — เจ้าของต้องกำหนดเป็นกติกาว่า “vendor ห้ามเปิดฟีเจอร์ AI ใหม่ให้เราโดยไม่แจ้งล่วงหน้า” และเขียนลงสัญญา ไม่ใช่หวังว่าเขาจะนึกถึงเราเอง
ประเด็นสำคัญที่ตำราเน้นคือ — การเอาเรื่อง AI ไปเสริมในโปรแกรมคุม vendor เดิม ไม่ใช่แค่ “ทำให้ครบ” แต่มันแสดงว่าบริษัทเรา คิดเรื่องความเสี่ยง AI แบบเชิงรุก ซึ่งช่วยทั้งปกป้องข้อมูล รักษาความต่อเนื่องของธุรกิจ ทำตามกฎหมาย และที่สำคัญ — สร้างความเชื่อมั่น ให้ทั้งลูกค้าและผู้มีส่วนได้เสีย
เส้นทางคัด vendor AI — จากตอนยังไม่ผูกพัน จนถึงตอนคุมต่อเนื่อง
ตำรา AAISM ให้ภาพ “เส้นทางการคุม vendor AI” ไว้แบบหนึ่ง (Figure 2.24) ผมจะไม่ลอกมาตรงๆ แต่ขอเรียบเรียงเป็นลำดับขั้นแบบที่เจ้าของกิจการเอาไปเดินตามได้จริง พร้อมอธิบายว่าแต่ละขั้น “ตัดสินใจอะไร”
หัวใจของเส้นทางนี้คือคำเดียว — “คัดให้จบก่อนจะผูกพันลึก” เพราะพอใช้ vendor ไปนานๆ จนทั้งบริษัทพึ่งเขา ถ้าวันนั้นเพิ่งมารู้ว่าเขามีปัญหา การถอนตัวจะเจ็บมาก (ระบบล่ม งานสะดุด ข้อมูลค้างอยู่กับเขา) — เลยต้องคัดให้หนักตั้งแต่ “ก่อน” จะพึ่งเขา
[1] นิยามก่อนว่า "เราต้องการ AI ไปทำอะไร" + เราพร้อมแค่ไหน │ ▼[2] ทำบัญชี vendor AI — ในบ้านมีใครขาย AI ให้เราบ้าง (รวมที่แถมมา) │ ▼[3] นิยามขอบเขต — AI ตัวนี้จะแตะข้อมูลอะไร ทำงานส่วนไหน │ ▼[4] เอากระบวนการตรวจคนขายเดิม มาเติมคำถามเฉพาะ AI ◄────────┐ │ │ │ ▼ ▼ │[5a] ดูชื่อเสียง + ความมั่นคง [5b] ดูวิธีทำงาน + │ ใช่ → การเงินของ vendor ค่านิยมตรงเราไหม │ วน │ │ │ กลับ └──────────────┬───────────────┘ │ ประเมิน ▼ │ ใหม่[6] นิยาม "เรารับได้แค่ไหน" — ขอเห็นเครื่องวัดใน AI ของเขา │ │ │ ▼ │[7] นิยาม "เรารับได้แค่ไหน" — เรื่องใช้/ใช้ผิด/ใช้ในทางมิชอบ │ │ │ ▼ │[8] ตั้งเกณฑ์ตามกฎ + เกณฑ์ "ต้องแจ้งเราเมื่อเกิดเหตุ" │ │ │ ▼ │[9] วางวิธีคุมต่อเนื่อง — ตรวจซ้ำเป็นระยะ ──[มีอะไรเปลี่ยน?]──┘ │ ไม่มี ▼ ตั้ง "ตัวกระตุ้น" ให้กลับมาประเมินใหม่ (เช่น vendor เปลี่ยนโมเดล / กฎหมายใหม่ / เกิดเหตุ)ผมขอเล่าทีละขั้นในมุมคนบริหารว่าแต่ละจุด “ต้องตอบอะไรให้ได้”:
[1] เรานิยามก่อนว่าจะใช้ AI ทำอะไร + เราพร้อมแค่ไหน — ก่อนไปถามคนขาย ต้องถามตัวเองก่อนว่า “เราจะเอา AI ไปแก้ปัญหาอะไร และในบ้านเราพร้อมรับมันแค่ไหน” ถ้าตอบไม่ได้ ไปคุยกับ vendor ก็จะถูกเขาพาไปตามของที่เขาอยากขาย
[2] ทำบัญชี vendor AI ทั้งหมด — ลิสต์ออกมาว่าตอนนี้ในบ้านเรามีใครขาย/ให้บริการ AI กับเราบ้าง รวมถึงฟีเจอร์ AI ที่แถมมากับของเดิม ข้อนี้สำคัญมากเพราะส่วนใหญ่ทำไม่ครบ — มองแค่ AI ที่ตั้งใจซื้อ แต่ลืมที่แอบเข้ามา
[3] นิยามขอบเขต — AI ตัวนี้จะไปแตะข้อมูลอะไร ทำงานส่วนไหนของบริษัท ขอบเขตยิ่งกว้าง ความเสี่ยงยิ่งสูง ต้องคัดหนักขึ้น
[4] เอากระบวนการเดิมมาเติมคำถาม AI — นี่คือหัวใจ ไม่ต้องสร้างกระบวนการใหม่ทั้งหมด เอาแบบฟอร์มตรวจ vendor เดิมมา เติมหมวดคำถามเฉพาะ AI เข้าไป (โมเดลฝึกด้วยอะไร, อธิบายการตัดสินใจได้ไหม, content provenance มีไหม ฯลฯ)
[5a] + [5b] ตรวจสองด้านพร้อมกัน — ด้านหนึ่งดู “ตัวบริษัท vendor” (ชื่อเสียง + การเงินมั่นคงไหม จะอยู่กับเรายาวไหม) อีกด้านดู “วิธีเขาทำงาน” (กระบวนการเขาดีไหม ค่านิยมตรงเราไหม) ทั้งสองด้านต้องผ่าน
[6] นิยามว่าเรารับได้แค่ไหน — ฝั่งเครื่องมือ/เครื่องวัด — เราต้องบอก vendor ได้ว่า “เราอยากเห็นตัวเลขอะไรจาก AI ของคุณบ้าง” เช่น อัตราผิดพลาด อัตรา false positive ฯลฯ ถ้า vendor ไม่ยอมให้เห็นเครื่องวัดเลย = สัญญาณอันตราย
[7] นิยามว่าเรารับได้แค่ไหน — ฝั่งการใช้งาน — เรื่อง use (ใช้ปกติ) / abuse (ใช้เกินขอบเขต) / misuse (ใช้ผิดวัตถุประสงค์) เราต้องตกลงกันให้ชัดว่าอะไรทำได้ อะไรห้าม
[8] ตั้งเกณฑ์ compliance + การแจ้งเหตุ — เขียนให้ชัดว่า vendor ต้องทำตามกฎอะไร และ ต้องแจ้งเราภายในกี่ชั่วโมงเมื่อเกิดเหตุ (เช่น ข้อมูลรั่ว โมเดลทำงานเพี้ยน) อย่าปล่อยให้เป็น “แล้วแต่เขาจะแจ้ง”
[9] วางวิธีคุมต่อเนื่อง + ตัวกระตุ้นให้ประเมินใหม่ — คัดเข้าแล้วไม่จบ ต้องตรวจซ้ำเป็นระยะ และตั้ง “ตัวกระตุ้น” (trigger) ที่บังคับให้กลับมาประเมินใหม่ทันที เช่น vendor เปลี่ยนโมเดลใหญ่ / มีกฎหมายใหม่ / เกิดเหตุด้านความปลอดภัย — ไม่ใช่รอประเมินรอบปีหน้า
มุมผู้บริหาร: สังเกตว่าเส้นทางนี้มี “ลูป” — ขั้น [9] วิ่งกลับไปขั้น [4] ได้ตลอด นี่คือสิ่งที่ทำให้ vendor AI ต่างจาก vendor ธรรมดา — vendor ขายของทั่วไปคัดเข้าทีเดียวก็ค่อนข้างจบ แต่ AI มันเปลี่ยนตัวเองได้ โมเดลวันนี้กับโมเดลปีหน้าอาจเป็นคนละตัว ความเสี่ยงเลยไม่หยุดนิ่ง คำถามที่เจ้าของต้องตอบให้ได้คือ “อะไรคือ trigger ที่ทำให้เราต้องกลับมาดู vendor นี้ใหม่” — ถ้าตอบไม่ได้ แปลว่าคุณกำลัง “เซ็นแล้วลืม” ซึ่งคือจุดที่ความเสี่ยงสะสมเงียบๆ
สัญญาต้องมีอะไร — เรื่องที่ vendor AI ต้องเขียน แต่ vendor ธรรมดาไม่มี
ตรงนี้เป็นจุดที่ผมอยากเชื่อมกลับไป CISA D2.19 อีกครั้ง — เรื่อง สัญญา, SLA, right-to-audit, รายงาน SOC พวกนั้นยังใช้ได้หมดและยังจำเป็น ไม่ต้องสอนซ้ำ แต่กับ AI มันมี ข้อสัญญาเพิ่มเติม ที่ของธรรมดาไม่มี ผมขอลิสต์เฉพาะส่วนที่ “เป็นเรื่อง AI โดยเฉพาะ”:
| ข้อสัญญา (clause) | ทำไมต้องมีสำหรับ AI โดยเฉพาะ | ถ้าไม่มีจะเจ็บยังไง |
|---|---|---|
| แจ้งล่วงหน้าก่อนเปลี่ยน/เพิ่มฟีเจอร์ AI | AI เปลี่ยนตัวเองได้ ฟีเจอร์ใหม่ = ความเสี่ยงใหม่ | vendor เปิดฟีเจอร์ AI ที่กระทบงานเรา/ผิดกฎ โดยเราไม่รู้ |
| สิทธิเข้าตรวจ (right-to-audit) ที่ครอบคลุมถึง AI | ต้องตรวจได้ว่าโมเดลทำงานยังไง ฝึกด้วยอะไร ไม่ใช่แค่ตรวจ uptime | เกิดเหตุแล้วเข้าไปดูไม่ได้ พิสูจน์ไม่ได้ว่าใครผิด |
| เจ้าของข้อมูล + สิทธิในผลงาน (IP) + ห้ามเอาข้อมูลเราไปฝึกต่อ | ต้องชัดว่าข้อมูลที่เราป้อนยังเป็นของเรา และห้ามถูกดูดไปฝึกโมเดลกลาง | ข้อมูลลูกค้าเราไปโผล่ในคำตอบที่ vendor ให้บริษัทอื่น = ผิดกฎหมายข้อมูล |
| เกณฑ์แจ้งเหตุ (incident notification) ที่รวมเหตุของ AI | เหตุของ AI ไม่ใช่แค่ “ระบบล่ม” แต่รวม “โมเดลเพี้ยน/ลำเอียง/ตอบมั่ว” | vendor ไม่ถือว่า “AI ตอบมั่ว” เป็นเหตุที่ต้องแจ้ง เราเลยไม่รู้ตัว |
| เงื่อนไขถอนตัว / ส่งข้อมูลคืน (exit clause) | กัน vendor lock-in — ถ้าเลิกใช้ ต้องเอาข้อมูลเราออกมาได้ | ติดหล่ม ถอนตัวไม่ได้ ข้อมูลค้างอยู่กับ vendor ตลอดกาล |
| provenance ของ generative AI | ถ้าใช้ AI สร้างเนื้อหา ต้องรู้ว่ามันมาจากไหน เชื่อถือได้ไหม | เอาเนื้อหาที่ AI สร้างไปใช้ แล้วโดนปัญหาลิขสิทธิ์/ข้อมูลเท็จ |
กับดักที่เจอบ่อย — “สัญญาเดิม copy มาใช้กับ AI”: ทีมจัดซื้อหลายที่หยิบสัญญา vendor IT เดิมมาแก้ชื่อแล้วเซ็น — ปัญหาคือสัญญาเดิม ไม่มีคำว่า “ห้ามเอาข้อมูลเราไปฝึกโมเดล” และไม่มีคำว่า “แจ้งก่อนเปลี่ยนโมเดล” เพราะตอนเขียนยังไม่มี AI ทางแก้คือ — ก่อนเซ็น vendor AI เจ้าของต้องสั่งทีมกฎหมายไปเติม clause เฉพาะ AI พวกนี้เข้าไปก่อนเสมอ
มีจุดที่ตำราเตือนชัดเจน — vendor ที่ “ไม่ยอมให้ตรวจ ไม่ยอมให้ทำ due diligence ไม่ยอมให้ประเมินความปลอดภัย” ถือเป็นสัญญาณอันตรายระดับสูง เพราะถ้าตอนจีบกันยังไม่ให้ดู พอเกิดเรื่องจริงยิ่งไม่มีทางได้ดู
checklist คัด vendor AI — 9 เหตุผลที่ทำให้ “ไม่เอา vendor นี้” ได้อย่างมีหลัก
ทีนี้มาถึงส่วนที่เอาไปใช้ได้ทันที — เวลาประเมิน vendor AI สักเจ้า อะไรบ้างที่เป็น “ธงแดง” ที่ทำให้เราตัดสินใจ ไม่เลือก เขาได้อย่างมีเหตุผล ตำรา AAISM ลิสต์ข้อกังวลหลักไว้ ผมขอเรียบเรียงเป็น checklist พร้อมแปลเป็นภาษาคนและตัวอย่างสมมติ:
| # | ธงแดง (เหตุที่อาจไม่เลือก vendor) | แปลเป็นภาษาคน + ตัวอย่าง (สมมติ) |
|---|---|---|
| 1 | AI อธิบายตัวเองไม่ได้ (ขาด transparency/explainability) | ถาม vendor ว่า “AI คุณตัดสินใจแบบนี้เพราะอะไร” แล้วเขาตอบว่า “ไม่รู้เหมือนกัน มันคิดเอง” — รับไม่ได้ถ้าเอาไปใช้เรื่องสำคัญ |
| 2 | มีปัญหาจริยธรรมเกินรับ | AI คัดเรซูเม่สมมติ ที่ vendor ยอมรับเองว่ายัง “เอนเอียง” เรื่องเพศ/อายุอยู่ — ใช้แล้วบริษัทเราเสี่ยงโดนฟ้องเลือกปฏิบัติ |
| 3 | เสี่ยงละเมิดความเป็นส่วนตัวสูง | vendor ตอบไม่ได้ว่าข้อมูลที่เราป้อนไปจบที่ไหน หรือยอมรับว่าเอาไปฝึกโมเดลกลาง |
| 4 | ติดหล่ม vendor (vendor lock-in) | ใช้แล้วถอนตัวไม่ได้ ข้อมูลเอาออกมายาก ค่าเปลี่ยนเจ้าแพงจนเหมือนถูกมัดมือ |
| 5 | เทคโนโลยียังดิบ/ไม่พิสูจน์ แต่ไปแตะเรื่องสุขภาพ/ความปลอดภัย | AI ตัวใหม่เอี่ยมที่ยังไม่มีใครใช้จริง แต่จะเอามาช่วยตัดสินใจเรื่องที่กระทบชีวิตคน — เสี่ยงเกิน |
| 6 | ไม่มีกรอบจัดการความเสี่ยงที่รวม AI | vendor บอก “เรามีระบบความปลอดภัยดีมาก” แต่พอถามเรื่องเสี่ยงเฉพาะ AI (data poisoning, prompt injection) ตอบไม่ได้ |
| 7 | ทำตามข้อกำหนดความปลอดภัยของเราไม่ได้ | เราต้องการการเข้ารหัส/แยกข้อมูลระดับหนึ่ง แต่ vendor ทำให้ไม่ได้ |
| 8 | generative AI ไม่มีกลไกบอกที่มาเนื้อหา (provenance) | ใช้ AI สร้างเนื้อหา แต่บอกไม่ได้ว่าเนื้อหามาจากไหน เชื่อถือได้แค่ไหน |
| 9 | ต่อต้านการตรวจ/ประเมิน (resistance to due diligence/audit) | ขอเอกสาร ขอเข้าตรวจ ขอประเมินความปลอดภัย แล้ว vendor บ่ายเบี่ยง — ข้อนี้อันตรายที่สุด |
แต่ — และนี่สำคัญมาก — ธงแดงไม่ได้แปลว่า “ห้ามใช้เสมอ” ตำราพูดชัดว่าบางที vendor ถูกจัดว่าเสี่ยงสูง แต่บริษัทก็เลือกใช้อยู่ดี เพราะ ความเสี่ยงนั้นจัดการได้ — ลดได้ (mitigate) โอนได้ (transfer) หรือยอมรับได้ (accept) ในระดับที่บริษัทรับไหว
จุดที่ “ต้องไม่เอาจริงๆ” คือเมื่อ — ความเสี่ยงของ vendor นั้น เกินระดับที่บริษัทรับได้ และจัดการไม่ลง ไม่ว่าจะด้วยสัญญา ด้วยเครื่องมือทางเทคนิค หรือด้วยขั้นตอนการทำงาน — เมื่อนั้นต่อให้ AI เก่งแค่ไหน ประโยชน์ก็ไม่คุ้มความเสี่ยง ก็ต้องตัดใจ
มุมผู้บริหาร: checklist 9 ข้อนี้ คุณค่าจริงๆ ของมันไม่ใช่ “เอาไว้จับผิด vendor” แต่คือ เอาไว้ให้เจ้าของกิจการตอบคำถามยากๆ ได้อย่างมีหลัก — เวลาทีมขายของ vendor มากดดันว่า “ทำไมไม่เลือกเรา ของเราดีที่สุด” คุณจะมีคำตอบที่ชัด ไม่ใช่ “รู้สึกไม่ไว้ใจ” แต่เป็น “ข้อ 1, 3, 9 คุณตก— AI อธิบายไม่ได้ ข้อมูลเราไหลไปไหนไม่รู้ และคุณไม่ยอมให้เราเข้าตรวจ” นี่คือความต่างระหว่างคนบริหารที่ “เจ้าของความเสี่ยง” กับคนที่ตัดสินใจตามอารมณ์
เลือก vendor AI — 6 มุมที่ต้องชั่งน้ำหนัก
พอผ่านด่านธงแดงแล้ว ถ้ามี vendor หลายเจ้าที่ “ผ่าน” จะเลือกเจ้าไหน? ตำราให้กรอบ “มุมที่ต้องพิจารณาทางธุรกิจ” ไว้ ผมขอเรียบเรียงเป็น 6 มุมพร้อมคำถามที่คนบริหารควรถาม:
| มุมที่ต้องดู | คำถามที่เจ้าของกิจการต้องถาม |
|---|---|
| 1. ตรงกับกลยุทธ์ธุรกิจไหม | vendor เข้าใจเป้าหมายธุรกิจเราไหม? AI ของเขาช่วยเราไปถึงเป้าได้จริงไหม หรือเป็นแค่ของเล่นทดลองครั้งเดียวจบ? |
| 2. จัดการความเสี่ยง + ความปลอดภัย + แผนรับเหตุ | เขารับมือความเสี่ยงเฉพาะ AI ยังไง? มีแผนรับเหตุไหม? ถ้าเป็น generative AI มีกลไกบอกที่มาเนื้อหาไหม? มีแผนความต่อเนื่องธุรกิจไหมถ้าเขาล่ม? |
| 3. การกำกับข้อมูล + คุณภาพข้อมูล | เขาต้องการข้อมูลอะไรจากเราบ้าง? เขาคุมคุณภาพ/ความลำเอียงของข้อมูลยังไง? ใครเป็นเจ้าของข้อมูลและผลงาน? ข้อมูลที่เขาใช้ฝึกมาจากไหน? |
| 4. ความสามารถ + การเชื่อมต่อระบบ | AI เขาเชื่อมกับระบบเดิมเรา (รวมระบบเก่า) ง่ายไหม? ขยายได้ไหม? อธิบายการตัดสินใจของโมเดลให้เราดูได้ไหม? |
| 5. ทีม + การซัพพอร์ต | ทีมเขาเก่งจริงไหม? ดูแลต่อเนื่อง อัปเดต และมีแผนตอนเลิกซัพพอร์ต (end of life) ไหม? ถ่ายทอดความรู้/เทรนให้ทีมเราไหม? |
| 6. ทำตามกฎหมาย+ จริยธรรม | เขาทำตามกฎหมาย/ระเบียบ/แนวจริยธรรมที่เกี่ยวข้องครบไหม? จุดยืนเรื่องการใช้ AI อย่างมีจริยธรรมของเขาคืออะไร? (ถ้าเป็นหน่วยงานรัฐ — ตรงตามแนวทางรัฐไหม?) |
จุดที่ผมอยากเน้นในมุมคนบริหารคือ มุมที่ 3 (เจ้าของข้อมูล/IP) — นี่คือมุมที่ของ AI ต่างจาก vendor ทั่วไปชัดที่สุด เพราะ AI กินข้อมูลเป็นอาหาร คำถาม “ข้อมูลที่เราป้อน ยังเป็นของเราไหม และเขาเอาไปฝึกต่อไหม” สำคัญพอๆ กับเรื่องราคา — แต่คนมักลืมถามเพราะมันไม่ใช่คำถามที่เคยถาม vendor IT เดิม
มุมผู้บริหาร: สังเกตว่าทั้ง 6 มุมนี้ไม่มีมุมไหนชื่อว่า “ราคา/ROI” เป็นมุมเดี่ยวๆ — เพราะตำราชวนมองว่าราคาแทรกอยู่ในทุกมุม การเลือก vendor AI ที่ถูกที่สุดแต่อธิบายตัวเองไม่ได้ (ตกมุม 4) หรือไม่ยอมบอกว่าข้อมูลเราไปไหน (ตกมุม 3) สุดท้ายอาจแพงกว่ามากเมื่อเกิดเรื่อง คนบริหารที่เก่งจะไม่ถาม “เจ้าไหนถูกสุด” แต่ถาม “เจ้าไหนที่ความเสี่ยงอยู่ในระดับที่เรารับได้ ในราคาที่สมเหตุสมผล”
สรุปสั้นๆ ให้ตัวเองจำได้
อ่านมาถึงตรงนี้ ขอจดกันลืมไว้ห้าอย่างครับ
อย่างแรก — AI ส่วนใหญ่ในบ้านเรามากับ vendor ไม่ได้สร้างเอง และบางส่วน “แอบเข้ามา” โดยแถมมากับของเดิม งานด่านแรกของเจ้าของกิจการคือทำบัญชีให้ครบว่าในบ้านมี AI ของใครอยู่บ้าง รวมที่ไม่ได้ตั้งใจซื้อ
อย่างที่สอง — โปรแกรมคุม vendor เดิม “ไม่พอ” ต้องเอามาเติมคำถามเฉพาะ AI 4 ด้าน — เสี่ยงธุรกิจ / เสี่ยงความเป็นส่วนตัว / เสี่ยงความปลอดภัย / ตามกฎที่เปลี่ยนตลอด — และต้องบังคับให้ vendor แจ้งล่วงหน้าก่อนเปลี่ยน/เพิ่มฟีเจอร์ AI
อย่างที่สาม — คัดให้จบก่อนจะพึ่งเขาลึก แล้วคุมต่อเนื่อง เพราะ AI เปลี่ยนตัวเองได้ ความเสี่ยงไม่หยุดนิ่ง — ต้องตั้ง “ตัวกระตุ้น” ที่บังคับให้กลับมาประเมิน vendor ใหม่ (เปลี่ยนโมเดล / กฎหมายใหม่ / เกิดเหตุ) ไม่ใช่เซ็นแล้วลืม
อย่างที่สี่ — สัญญาต้องมี clause เฉพาะ AI ที่ vendor ธรรมดาไม่มี — แจ้งก่อนเปลี่ยนโมเดล, สิทธิเข้าตรวจถึงตัว AI (right-to-audit), ห้ามเอาข้อมูลเราไปฝึกต่อ, แจ้งเหตุที่รวมเหตุของ AI (เช่น โมเดลเพี้ยน/ลำเอียง), เงื่อนไขถอนตัวกัน lock-in อย่า copy สัญญา IT เดิมมาใช้ดื้อๆ
อย่างที่ห้า — มี checklist 9 ธงแดงไว้ตอบคำว่า “ไม่เอา” ได้อย่างมีหลัก แต่ธงแดงไม่ได้แปลว่าห้ามใช้เสมอ — ใช้ได้ถ้าจัดการความเสี่ยงลง ที่ต้อง “ไม่เอาจริงๆ” คือเมื่อความเสี่ยงเกินที่รับได้และจัดการไม่ลง — แล้วประโยชน์ไม่คุ้มเสี่ยง
ถ้าจะสรุปแบบที่เจ้าของกิจการหลายคนน่าจะพยักหน้าตาม — “งั้น vendor AI ก็เหมือนบริษัทรับเหมาที่ส่งคนเก่งมาทำงานในบ้านเรา เก่งแค่ไหนก็ต้องเช็คประวัติก่อนรับ คุมงานต่อเนื่อง เขียนสัญญาให้ชัดว่าถ้าพลาดใครรับ และที่สำคัญ — ถ้าวันหนึ่งเขาเปลี่ยนคน (เปลี่ยนโมเดล) เราต้องกลับมาดูใหม่ ไม่ใช่ไว้ใจไปตลอด” ใช่เลยครับ นั่นแหละคืองานของคนบริหารที่เป็นเจ้าของความเสี่ยง
ตอนหน้าเราจะขยับจาก “คุมคนขาย AI” ไปสู่คำถามที่ลึกกว่า — “ในฐานะคนเอา AI ของคนอื่นมาใช้ (deployer) เรารับผิดชอบส่วนไหนกันแน่? แล้วถ้าทั้ง chain มีหลายเจ้าต่อกัน ความเสี่ยงมันส่งต่อกันยังไง?” เรื่อง AI Deployer + Shared Responsibility + ความเสี่ยงทั้งห่วงโซ่อุปทาน ไว้เจอกันครับ
อ้างอิงเนื้อหา: AAISM — Domain 2: Section 2.10 (AI Vendor Management — New-Feature Risk, Vendor Management Approach, 2.10.1 AI Vendor Considerations & Selection Criteria) แหล่งสาธารณะที่อ้างถึงโดยตรง: NIST AI Risk Management Framework (AI RMF 1.0) — third-party / supply-chain due diligence (nist.gov) · EU AI Act — provider vs. deployer obligations (artificialintelligenceact.eu) · OWASP Top 10 for LLM Applications — Supply Chain risk (owasp.org) · MITRE ATLAS — adversarial threats to ML supply chain (atlas.mitre.org) · พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA)
