สารบัญ
Series: AAISM — AI Security Management สำหรับเจ้าของกิจการ (มุม Deployer/ผู้บริหาร)
ตอนที่ 23 / Domain 2 — AI Risk & Opportunity Management (ปิดท้าย Domain 2)
(สารบัญเต็มจะตามมาครับ — ตอนนี้ขอเล่าไล่เป็นตอนๆ ไปก่อน)
📚 พื้นฐานที่ควรอ่านคู่กัน: ตอนนี้จะพูดเรื่อง supply chain ของซอฟต์แวร์ + DevSecOps เยอะมาก. ถ้าใครยังไม่แม่นว่า “ทำไมโจรยุคใหม่หันไปเจาะ supplier แทนเจาะตัวแอป” + “Shift-Left / SBOM / CI-CD pipeline คืออะไร” ผมแนะนำให้อ่าน CyberSecurity Foundation EP.34 — DevSecOps + Shift-Left ก่อน. ตอนนี้ผมจะ ไม่สอนพื้นฐาน supply chain ซ้ำ — แต่จะเล่าเฉพาะ มุมที่ AI ทำให้มันแปลกไปจากซอฟต์แวร์ธรรมดา + มุมที่ผู้บริหารต้องตัดสินใจ
ครับ มาถึงตอนปิด Domain 2 แล้ว.
ถ้าจำได้ — ตลอด Domain 2 ผมพาคุณมองภาพ AI = พนักงานใหม่เก่งสุดๆ ที่ต้องกำกับ มาตลอด. เราคุยกันว่า:
- จะ เชื่อ พนักงานคนนี้แค่ไหน (AI Trust) — และจะ มองหาความเสี่ยง ของเขายังไง (Risk Identification, Frameworks อย่าง NIST AI RMF / EU AI Act)
- จะ ตั้งเส้น ว่ายอมรับความเสี่ยงได้แค่ไหน (Acceptable Limits) — แล้ว รับมือ ยังไง (Accept / Avoid / Mitigate / Transfer)
- เขาจะ ถูกโจมตี ตรงไหน (Threat Landscape, Threat Modeling) — แล้ว ป้องกัน ยังไง (Mitigation)
- และถ้าเราไม่ได้สร้างพนักงานคนนี้เอง แต่ จ้างมาจากบริษัทจัดหา (vendor / provider) — จะ คุม เขายังไง (Vendor Management, Deployer Considerations, Shared Responsibility Model)
ตอนนี้เป็น 2 หัวข้อสุดท้ายของ Domain 2 ครับ — และเป็น 2 หัวข้อที่ผมว่าเจ้าของกิจการชอบมองข้ามมากที่สุด เพราะมันไม่ใช่เรื่อง “AI ตอบผิด” หรือ “AI โดน hack” แบบที่เห็นในข่าว แต่เป็นเรื่องที่ซ่อนอยู่ใต้พรม:
- Integration Risk — เวลาเราเอาพนักงานใหม่คนนี้มาเสียบเข้าระบบเก่าที่ใช้มา 20 ปี มันพังตรงไหน? แล้วงานที่เขาทำออกมา — มันเป็นของเราจริงไหม หรือเขาแอบลอกของคนอื่นมาส่งเรา?
- AI Software Supply Chain Risk — พนักงานคนนี้มาจากสายการผลิตที่ยาวแค่ไหน? เราจ้างผ่านบริษัท A แต่ A ไปจ้างต่อ B, B จ้างต่อ C… ไล่ไปจนถึงโรงงานผลิตชิปในไต้หวันที่เราไม่เคยได้ยินชื่อด้วยซ้ำ
มุมที่ผมจะย้ำตลอดตอนนี้ และตลอด Domain 2 เลย คือ ในฐานะ deployer (คนเอา AI มาใช้) ผู้บริหารคือเจ้าของความเสี่ยง. เราไม่ใช่ auditor ที่มา “ตรวจ” ว่าใครทำผิด checklist. เราคือคนที่ต้องตัดสินใจเองว่ารับความเสี่ยงนี้ไหม จะ treat ยังไง และถ้ามันระเบิด เราคือคนรับผิด ไม่ใช่ vendor. การที่ vendor ทำพลาด ไม่ได้แปลว่าความรับผิดชอบหลุดจากมือเรา (เรื่องนี้ผมเล่าไว้ละเอียดในตอน Shared Responsibility Model แล้ว)
เริ่มที่เรื่องแรกครับ — Integration Risk
1. Integration Risk — ตอนเอาพนักงานใหม่ไปเสียบเข้าระบบเก่า
ลองนึกภาพแบบนี้ครับ. สมมติคุณเป็นเจ้าของโรงงานแห่งหนึ่งที่เปิดมา 25 ปี. เครื่องจักรในสายการผลิตบางตัวซื้อมาตั้งแต่ปี 2543 — มันยังทำงานได้ดี แต่มันพูดภาษาคนละภาษากับเครื่องรุ่นใหม่. ตอนนี้คุณจ้าง “พนักงานใหม่เก่งๆ” (AI) เข้ามา แล้วบอกเขาว่า “ไปคุยกับเครื่องจักรเก่าพวกนี้ให้หน่อย ช่วยปรับ optimize การผลิต”
ปัญหาคือพนักงานคนนี้เก่งจริง แต่เขาเกิดในยุค cloud เขาคุ้นกับ API สมัยใหม่ ส่วนเครื่องจักรเก่าของคุณไม่มี API ด้วยซ้ำ มันสื่อสารด้วยไฟล์ format โบราณที่คนเขียนโปรแกรมรุ่นนั้นเกษียณไปหมดแล้ว.
นี่แหละครับ Integration Risk คือความเสี่ยงที่เกิดตอน “เสียบ” AI เข้ากับสิ่งที่เรามีอยู่. ในคู่มือ AAISM แยกเป็น 2 ก้อนใหญ่ คือ Legacy Systems (ระบบเก่า) กับ Intellectual Property (ทรัพย์สินทางปัญญา / ลิขสิทธิ์). ขอเล่าทีละก้อน
1.1 Legacy Systems — ระบบเก่าที่ไม่ยอมตาย
Legacy system (ระบบเก่า) คือระบบที่อยู่กับองค์กรมานาน — บางที 10-20 ปี — และมักจะยังอยู่ต่อไปอีกนาน เพราะมันยัง “ทำงานได้” และการรื้อมันออกแพงเกินกว่าจะคุ้ม. ปัญหาคือระบบพวกนี้มักต่อยาก ปรับยาก และ “ไม่ได้ถูกออกแบบมาให้ทำงานกับ AI” ตั้งแต่แรก. พอเอา AI ไปเสียบ — แทนที่จะได้ประสิทธิภาพ กลับไปสะกิดปัญหาเดิมๆ ที่ซ่อนอยู่ ให้โผล่ขึ้นมา หรือสร้างปัญหาใหม่ทับเข้าไปอีก
ในมุม deployer — ก่อนจะตัดสินใจเสียบ AI เข้าระบบเก่า ผู้บริหารต้องสั่งทีมให้ตอบคำถามชุดนี้ก่อน (ผมเรียบเรียงเป็นตารางของผมเองเพื่อให้ใช้เป็น checklist ตัดสินใจได้):
| คำถามที่ต้องตอบก่อนเสียบ AI เข้าระบบเก่า | ทำไมผู้บริหารต้องสนใจ |
|---|---|
| ใช้ AI ตรงนี้ “สมเหตุสมผล” ไหม — คุยกับ stakeholder ทุกฝ่ายว่าทางไหนดีที่สุด | บางทีคำตอบที่ถูกคือ “อย่าเพิ่งใช้ AI ตรงนี้” — การ avoid ก็เป็น risk response ที่ valid |
| ระบบ AI ของ provider ต่อกับระบบเดิมเราได้จริงไหม — เช็ค integration capability | ถ้าต่อไม่ได้ ค่า custom integration อาจแพงกว่าตัว AI หลายเท่า |
| ต้อง “รื้อใหญ่” (overhaul) ทั้งระบบไหม ถึงจะเอา AI มาใช้ได้ | ตัวเลขนี้เปลี่ยน ROI ทั้งโปรเจกต์ — ต้องรู้ก่อนเซ็น |
| ข้อมูลเรา “พอ” และ “ดีพอ” ไหม หรือต้องไปยกเครื่อง data governance ก่อน | AI เก่งแค่ไหนก็แพ้ข้อมูลขยะ — มักเป็นต้นทุนแฝงที่ใหญ่ที่สุด |
| กระทบ “คน” และ “กระบวนการ” เดิมยังไง — ใครในสายงานเดิมต้องเปลี่ยนวิธีทำงาน | คนต่อต้านการเปลี่ยนแปลง = โปรเจกต์ล่ม แม้เทคโนโลยีพร้อม |
| มี “วิธีการที่ยืดหยุ่น” ไหม — เพราะการ modernize จะขุด debt เก่าขึ้นมาเพียบ | ทั้ง technical debt, privacy debt, security debt ที่ซ่อนอยู่จะโผล่หมด |
| ใช้ “แรง เงิน เวลา” เท่าไหร่ จริงๆ | upgrade ระบบเก่าไม่เคยง่ายและไม่เคยถูก — ประเมินต่ำ = งบบาน |
| Provider จะ “อยู่กับเรา” ตลอด integration ไหม | ถ้า provider หายตอนกลางทาง = ติดอยู่กับระบบครึ่งๆ กลางๆ ที่ไม่มีใครดูแล |
ประเด็นสำคัญที่คู่มือย้ำ และผมเห็นด้วยมาก คือ — การ modernize ระบบเก่าเพื่อรับ AI มัน “ขุด debt” ขึ้นมา. คำว่า debt (หนี้) ในที่นี้คือ “หนี้ทางเทคนิค” — สิ่งที่องค์กรเคยทำลวกๆ ผ่านๆ ไว้เมื่อ 15 ปีก่อน เพราะตอนนั้นรีบ แล้วไม่เคยกลับมาแก้. พอเราจะเอา AI มาเสียบ มันบังคับให้เราเปิดฝาระบบเก่า — แล้วเจอว่า “ข้างในมันยุ่งเหยิงกว่าที่คิดเยอะ” ทั้งข้อมูลที่ไม่เคยจัดระเบียบ, รหัสผ่านที่ hardcode ทิ้งไว้, ช่องโหว่ที่ไม่เคยปิด.
ลองนึกภาพให้เป็นรูปธรรมครับ. สมมติว่าโรงงานผลิตชิ้นส่วนแห่งหนึ่งใช้ระบบ ERP (ระบบบริหารทรัพยากรองค์กร — ตัวที่คุมสต็อก คุมการสั่งซื้อ คุมบัญชี) ตัวเดิมมาตั้งแต่ปี 2548. ระบบนี้ยัง “ทำงานได้” — พนักงานบัญชีคีย์ข้อมูลเข้าทุกวัน. ทีนี้เจ้าของอยากเอา AI มาช่วย “พยากรณ์ว่าควรสั่งวัตถุดิบล่วงหน้าเท่าไหร่” เพื่อลดของค้างสต็อก. ฟังดูดีมาก.
แต่พอทีมลงไปดูจริง — เจอว่า:
- ระบบ ERP เก่าไม่มี API ให้ AI ดึงข้อมูลออกมาได้ ต้อง export เป็นไฟล์ Excel ด้วยมือทุกเช้า
- ข้อมูลในระบบ ไม่สม่ำเสมอ — ชื่อวัตถุดิบตัวเดียวกันถูกพิมพ์ไว้ 5 แบบ (เพราะพนักงานคนละคนคีย์คนละช่วงปี) AI เลยนับเป็นของคนละชนิด
- ข้อมูลย้อนหลังที่ “ดีพอจะเทรน” จริงๆ มีแค่ 2 ปี เพราะก่อนหน้านั้นบางช่วงข้อมูลหาย
ผลคือกว่าจะเอา AI มาใช้ได้จริง ต้องไปลงทุน “ยกเครื่อง data governance” ก่อน (จัดระเบียบชื่อวัตถุดิบ, สร้าง pipeline ดึงข้อมูลอัตโนมัติ, เก็บข้อมูลย้อนหลังให้ครบ) ซึ่งใช้เวลาและงบมากกว่าตัว AI หลายเท่า. นี่แหละครับคือ “debt ที่ถูกขุดขึ้นมา” ตัว AI ไม่ได้แพง แต่ “การทำให้ระบบเก่าพร้อมรับ AI” ต่างหากที่แพง. และถ้าผู้บริหารไม่รู้ตัวเลขนี้ตั้งแต่แรก งบก็จะบานกลางทาง แล้วโปรเจกต์ก็ค้างเติ่ง
มุมผู้บริหาร: อย่าถามทีมว่า “AI ตัวนี้เก่งไหม” อย่างเดียว. คำถามที่แพงกว่าคือ “กว่าจะเสียบมันเข้าระบบเราได้จริง ต้องลงทุนเท่าไหร่ และจะขุดเจอ debt เก่าอะไรบ้าง?” เพราะหลายโปรเจกต์ AI ที่ล่ม — ไม่ได้ล่มเพราะ AI ไม่เก่ง แต่ล่มเพราะค่า integration + ค่ายกเครื่อง data governance บานเกินงบ จนสุดท้ายได้พนักงานเทพมานั่งเฉยๆ เพราะคุยกับระบบเก่าไม่รู้เรื่อง. การตัดสินใจ “ยังไม่เสียบตอนนี้” (avoid/defer) เป็นการตัดสินใจที่กล้าหาญและถูกต้องบ่อยกว่าที่คิด
1.2 Intellectual Property — งานที่ AI ทำให้ เป็น “ของใคร”?
ก้อนที่สองของ Integration Risk หนักกว่า เพราะมันลากกฎหมายเข้ามาเกี่ยว — และเป็นพื้นที่ที่ทั่วโลกยังไม่มีคำตอบชัด. นี่คือเรื่อง ลิขสิทธิ์ + ทรัพย์สินทางปัญญา (IP) ของผลงานที่ GenAI สร้างให้
ลองนึกภาพพนักงานใหม่คนนี้อีกครั้งครับ. เขาเก่งเพราะเขา “อ่านมาเยอะมาก” อ่านทุกอย่างบนอินเทอร์เน็ต. แต่ปัญหาคือเขาอ่านของที่มีลิขสิทธิ์มาด้วย. แล้วเวลาเขาเขียนรายงานหรือเขียนโค้ดให้เรา เขาอาจจะ “หยิบ” สำนวน โครงสร้าง หรือชิ้นส่วนงานของคนอื่นมาปนโดยที่เราไม่รู้.
เรื่องนี้มี 2 มุมที่ผู้บริหารต้องแยกให้ออก:
มุมที่ 1 — AI อาจส่ง “ของลอก” มาให้เราโดยไม่รู้ตัว (ความเสี่ยงด้านการละเมิด)
โมเดล AI ต้องเทรนจากข้อมูลมหาศาล ซึ่งส่วนใหญ่ดึงมาจากเว็บสาธารณะ. ในกองข้อมูลนั้นมักมีงานมีลิขสิทธิ์ สิทธิบัตร หรืองานวิจัยเฉพาะปนอยู่. ผลที่ตามมาคือ output ที่โมเดลสร้าง อาจ “ไม่ได้ originality จริง” เพราะมันอาจหยิบชิ้นส่วนงานคนอื่นมาประกอบ. แปลว่าองค์กรอาจเผลอเอาเนื้อหาที่ถูกขโมยมาไปใส่ในสินค้า/บริการของตัวเอง โดยไม่รู้เลย แล้ววันดีคืนดีก็โดนฟ้องร้อง โดนปรับ ตามมา
คู่มือใช้คำตรงๆ ว่า “copyright infringement is unclear in the case of GenAI” คือเรื่องการละเมิดลิขสิทธิ์ของ GenAI ยังไม่ชัดเจนทางกฎหมาย. เหตุผลคือ GenAI ไม่ได้แค่ “สร้าง” เนื้อหาขึ้นมา แต่มัน “เรียนรู้” จากสิ่งที่ผู้ใช้ป้อนให้ด้วย. ถ้า provider ใช้ชุดข้อมูลที่ได้มาแบบไม่ถูกต้อง output ที่ออกมาดีที่สุดก็ใช้ไม่ได้ แย่ที่สุดก็พาเราขึ้นโรงขึ้นศาล. สำหรับองค์กรที่เอา insight จาก AI ไปขายต่อ นี่อาจทำให้บริการของเรากลายเป็นภาระมากกว่าจะเป็นประโยชน์
🔎 ประเด็นนี้สอดคล้องกับสิ่งที่เกิดขึ้นจริงในระดับโลก — มีคดีฟ้องร้องผู้พัฒนาโมเดล GenAI หลายคดีเรื่องการใช้งานมีลิขสิทธิ์มาเทรนโมเดลโดยไม่ได้รับอนุญาต ซึ่ง ณ ตอนที่ผมเขียน ส่วนใหญ่ยังไม่มีคำพิพากษาที่เป็นบรรทัดฐานชัดเจน. นี่คือเหตุผลที่ผมบอกว่า “พื้นที่นี้ยังเป็นหมอก” — เราในฐานะผู้ใช้จึงต้องป้องกันตัวเองด้วย “สัญญา” ไม่ใช่รอให้กฎหมายมาชัดก่อน
มุมที่ 2 — งานที่ AI ทำให้ “เป็นของเรา” จริงไหม (ความเสี่ยงด้านความเป็นเจ้าของ)
อันนี้ละเอียดกว่า — แม้ output ของ AI จะ “ไม่ผิดกฎหมาย” (ไม่ได้ลอกใคร) แต่ก็ยังมีคำถามว่า ใครเป็นเจ้าของ. สมมติว่าองค์กรหนึ่งใช้โมเดล AI ของ vendor มาช่วยเขียนโค้ด — แต่โมเดลนั้นไป “ดึง” ข้อมูลจากชุดข้อมูลของ vendor มาประกอบเป็นโค้ดด้วย. คำถามคือ — โค้ดที่ออกมา ใครคือเจ้าของ IP ตัวจริง? เรา? vendor? หรือไม่มีใครเป็นเจ้าของได้เลย?
คู่มือชี้ทางออกชัดเจน — “ต้องเขียนเรื่องความเป็นเจ้าของ (ownership provisions) ลงในสัญญาให้ชัด” และ “ต้องปรึกษาทีมกฎหมาย / general counsel ก่อนเซ็นสัญญาใดๆ” ที่ให้ AI ของ vendor มาสร้างเนื้อหาให้เรา
ผมขอสรุป 2 มุมนี้เป็นตารางตัดสินใจของผมเอง:
| มุม IP | คำถามที่ผู้บริหารต้องถาม | สิ่งที่ต้องทำ (treat) |
|---|---|---|
| ความเสี่ยงละเมิด (AI ลอกของคนอื่นมาให้เรา) | “ถ้า output นี้ดันไปละเมิดลิขสิทธิ์ใคร — ใครรับผิด เรา หรือ vendor?” | ขอ indemnification clause (ข้อสัญญาที่ vendor รับผิดชดใช้แทน) + ถาม provider ว่าเทรนจากข้อมูลที่มีสิทธิ์ใช้หรือไม่ |
| ความเสี่ยงความเป็นเจ้าของ (งานที่ได้เป็นของใคร) | “โค้ด/เนื้อหาที่ AI สร้างให้ — เราถือลิขสิทธิ์เต็มได้ไหม เอาไปขายต่อได้ไหม?” | เขียน ownership provision ในสัญญาให้ชัด + ให้ legal review ก่อนเซ็น |
ลองนึกภาพสมมติอีกสักฉากครับ. บริษัทเอเจนซีโฆษณาแห่งหนึ่งรับงานทำแคมเปญให้ลูกค้ารายใหญ่. ทีมงานใช้ GenAI สร้างภาพ key visual + เขียน slogan ส่งลูกค้า — งานสวย ลูกค้าชอบ ปิดดีลได้. ผ่านไป 3 เดือน มีบริษัทอื่นส่งจดหมายมาบอกว่า “ภาพที่คุณใช้ มันคล้ายงานมีลิขสิทธิ์ของเรามากเกินไป” — เพราะ AI ดันไปหยิบสไตล์/องค์ประกอบจากงานที่มีลิขสิทธิ์ซึ่งปนอยู่ในข้อมูลเทรนมา. คำถามที่ตามมาทันทีคือ — ใครรับผิด? เอเจนซี (ผู้ใช้ AI)? เจ้าของ AI tool (provider)? หรือลูกค้าที่เอาไปใช้ต่อ?
ถ้าในสัญญาระหว่างเอเจนซีกับ AI tool ไม่มีข้อ indemnification (ข้อที่ provider รับผิดชดใช้แทนถ้า output ไปละเมิดสิทธิ์ใคร) — เอเจนซีอาจต้องรับผิดเต็มๆ คนเดียว. และถ้าในสัญญากับลูกค้าก็ไม่ได้เคลียร์เรื่องนี้ไว้ — เอเจนซีอาจต้องชดใช้ทั้งสองทาง. นี่คือสาเหตุที่คู่มือย้ำว่า “ปรึกษา legal ก่อนเซ็น” — เพราะจุดที่ป้องกันความเสียหายได้คือ “ตอนเซ็นสัญญา” ไม่ใช่ “ตอนโดนฟ้องแล้ว”
มุมผู้บริหาร: เรื่อง IP กับ GenAI ไม่ใช่เรื่องของฝ่าย IT — มันเป็นเรื่องของฝ่ายกฎหมายและตัวคุณ. การตัดสินใจที่แพงที่สุดไม่ใช่ “ซื้อ AI ตัวไหน” แต่คือ “เซ็นสัญญายังไงให้ ถ้า AI ส่งของลอกมาให้เรา vendor เป็นคนรับผิด ไม่ใช่เรา” และ “งานที่ AI ทำให้ เราเป็นเจ้าของจริง เอาไปต่อยอดเชิงพาณิชย์ได้”. อย่าให้ทีม dev ไปเซ็น Terms of Service ของ AI tool เองโดยไม่ผ่าน legal — เพราะ ToS หลายตัวเขียนไว้ว่า “ทุกอย่างที่คุณป้อนเข้ามา เราเอาไปเทรนต่อได้” ซึ่งแปลว่าความลับทางการค้าของคุณอาจรั่ว และ “งานที่ได้อาจไม่ใช่ของคุณคนเดียว”
กับดักที่ผู้บริหารชอบติด (Integration Risk)
- กับดักที่ 1 — “AI เก่ง = โปรเจกต์จะสำเร็จ” ❌ ความจริงคือโปรเจกต์ AI ส่วนใหญ่ตายที่ขั้นตอน integration กับระบบเก่า + คุณภาพข้อมูล ไม่ใช่ที่ความเก่งของโมเดล
- กับดักที่ 2 — “ของที่ AI สร้าง = ของเราอัตโนมัติ” ❌ ไม่จริง ถ้าไม่ได้เขียน ownership ลงสัญญา ความเป็นเจ้าของอาจคลุมเครือ
- กับดักที่ 3 — “ใช้ AI เขียนโค้ด/คอนเทนต์แล้วเอาไปขายได้เลย” ❌ เสี่ยงโดนฟ้องละเมิดลิขสิทธิ์โดยไม่รู้ตัว เพราะเราไม่รู้ว่า provider เทรนจากอะไร
- กับดักที่ 4 — “ปล่อยให้ทีมเทคนิคเซ็น ToS เองได้” ❌ ToS = สัญญา ต้องผ่าน legal เสมอ
จบเรื่อง Integration Risk แล้วครับ. ทีนี้มาดูเรื่องสุดท้ายของ Domain 2 ที่ผมว่า “เปิดหูเปิดตา” ที่สุด — ห่วงโซ่อุปทานของ AI
2. AI Software Supply Chain Risk — พนักงานคนนี้มาจาก “สายผลิต” ที่ยาวแค่ไหน?
ครับ ถ้าใครอ่าน EP.34 DevSecOps มาแล้ว จะคุ้นกับแนวคิด supply chain ของซอฟต์แวร์ดี — ที่ผมเปรียบว่าแอปยุคนี้ก็เหมือนรถยนต์ ที่ 95% ของชิ้นส่วนมาจาก supplier คนอื่น ทีม dev แค่ “ประกอบ”.
แต่กับ AI — เรื่องนี้ซับซ้อนกว่าซอฟต์แวร์ธรรมดาอีกชั้น. คู่มือ AAISM พูดประโยคหนึ่งที่ผมว่าโดนมาก:
“supply chain risk ไม่ใช่เรื่องใหม่ — แต่การจัดการ supply chain แบบเดิม จัดการ ‘แต่ละชิ้นส่วน’ ขณะที่ AI ต้องจัดการ ‘ทั้งระบบ’. และเหตุผลที่ต้องจัดการ AI supply chain ไม่ใช่แค่เพื่อลด attack surface หรือปิดช่องโหว่ — แต่เพื่อปกป้อง แบรนด์ ชื่อเสียง และความไว้วางใจ ขององค์กร”
แปลเป็นภาษาคนคือ สมัยก่อนเราเช็ค supply chain แบบ “ชิ้นต่อชิ้น” (library ตัวนี้มีช่องโหว่ไหม?). แต่ AI มันเป็น “ระบบมีชีวิต” ที่ประกอบจากหลายมิติพร้อมกัน ทั้งคน ทั้งกระบวนการ ทั้งข้อมูล ทั้งตัวโมเดล. ช่องโหว่อาจไม่ได้อยู่ในโค้ด แต่อยู่ในข้อมูลที่ใช้เทรน หรือตัวโมเดลสำเร็จรูปที่เราดาวน์โหลดมา
เรื่องนี้ไม่ได้มีแต่ AAISM ที่พูด — วงการ security สากลก็จัดให้ “supply chain” เป็นความเสี่ยงระดับต้นๆ ของ AI. OWASP Top 10 for LLM Applications (รายการช่องโหว่ของแอป LLM ที่ OWASP จัดทำเป็นสาธารณะ) มีหัวข้อ “Supply Chain” ติดอันดับชัดเจน — ครอบคลุมทั้ง library บุคคลที่สามที่มีช่องโหว่, ปัญหาเรื่องสัญญาอนุญาตใช้งาน (licensing), และโมเดลที่เก่า/ถูก poison มา. ส่วน MITRE ATLAS (ฐานความรู้สาธารณะเรื่องเทคนิคการโจมตีระบบ AI/ML — เปรียบได้กับ ATT&CK แต่สำหรับ AI) ก็รวบรวมเทคนิคที่โจมตี “ห่วงโซ่ ML” ไว้ เช่นการแอบยัดโมเดลที่มี backdoor เข้าไปในคลังโมเดลสาธารณะให้คนหลงโหลดไปใช้. สองแหล่งนี้เป็นข้อมูลเปิดที่ผู้บริหารให้ทีมไปอ้างอิงได้ฟรี — ไม่ต้องเสียเงินซื้อ framework
2.1 ห่วงโซ่ AI มี 5 มิติ ไม่ใช่แค่ “โค้ด”
คู่มือแยกห่วงโซ่ AI ออกเป็น 5 มิติ (dimensions): คน, กระบวนการ, เทคโนโลยี, ข้อมูล, และโมเดล. ผมขอเรียบเรียงเป็นตารางของผมเอง พร้อมเติม “มุมที่ผู้บริหารต้องระวัง” ในแต่ละมิติ:
| มิติ | มีใคร/อะไรอยู่ในนั้น (ตัวอย่าง) | จุดที่ผู้บริหารต้องระวัง |
|---|---|---|
| People (คน) | data scientist, developer, นัก data modeling, tester, ผู้เชี่ยวชาญเฉพาะทาง (SME), auditor, regulator, reseller, vendor, ผู้ใช้ | คนแต่ละกลุ่มเข้าถึง “อะไร” ได้บ้าง — คนนอกในห่วงโซ่ (vendor, reseller) อาจเห็นข้อมูลเรา |
| Processes (กระบวนการ) | agentic framework, สถาปัตยกรรม/ออกแบบ, CI/CD pipeline, code review, การเก็บข้อมูล, dependency management, ETL, การ packaging, secure SDLC, การทดสอบ, version control | กระบวนการพวกนี้ของ provider เรามองไม่เห็น — ต้องอาศัยสัญญา + report บังคับให้เขาทำ |
| Technology (เทคโนโลยี) | build tool, container, dependency tool, IDE, infrastructure, แหล่งข้อมูล RAG, third-party library, version control | ทุกชิ้นคือช่องโหว่ที่อาจไม่ใช่ของเรา แต่กระทบเรา |
| Data (ข้อมูล) | data pipeline, dataset, log, raw data, ข้อมูล structured/unstructured, training data, แหล่ง RAG | ”ข้อมูลเทรน” คือหัวใจ — ถ้าถูก poison (วางยา) ตั้งแต่ต้นทาง โมเดลพังตั้งแต่เกิด |
| Model (โมเดล) | ตัวโมเดล AI, algorithm, computer vision, deep learning, framework, GenAI, ML model, NLP, reasoning model, parameter, weights | โมเดลสำเร็จรูปที่ดาวน์โหลดมาฟรี อาจมีมัลแวร์ฝังอยู่ใน weights |
จุดที่ผมอยากให้สังเกตคือ 3 มิติหลังนี้ (เทคโนโลยี, ข้อมูล, โมเดล) เป็นสิ่งที่ supply chain ซอฟต์แวร์แบบเก่าไม่ค่อยมี. ซอฟต์แวร์ธรรมดาเราห่วงแค่ “library ที่ import มา”. แต่ AI เราต้องห่วงเพิ่มอีกว่า ข้อมูลที่เทรนมาจากไหน และ ตัวโมเดลสำเร็จรูปที่โหลดมาสะอาดไหม. คำว่า weights (น้ำหนัก คือตัวเลขนับล้านที่เป็น “สมอง” ของโมเดล) ฟังดูไม่มีพิษภัย แต่ไฟล์โมเดลบาง format สามารถฝังโค้ดอันตรายไว้ได้ พอเราโหลดมารัน = มัลแวร์ทำงานทันที. นี่แหละครับคือเหตุผลที่ “โหลดโมเดลฟรีจากเน็ตมาใช้เลย” เป็นเรื่องที่ต้องระวังมาก
2.2 First Party ถึง Nth Party — สายที่ยาวจน “มองไม่เห็นปลาย”
นี่คือหัวใจของตอนนี้ครับ และเป็นภาพที่ผมอยากให้เจ้าของกิจการทุกคนเห็น.
ลองนึกภาพ supply chain ของรถยนต์อีกที (เหมือนใน EP.34) — แต่คราวนี้เราจะไล่ย้อนไปให้สุดสาย. คุณซื้อรถจาก showroom (นั่นคือ “first party” คือตัวคุณ). showroom ได้รถจากโรงงานประกอบ. โรงงานประกอบซื้อชิป ECU จาก Bosch. Bosch ซื้อชิปดิบจาก TSMC ที่ไต้หวัน. TSMC ซื้อเครื่องพิมพ์ลายวงจร (lithography) จาก ASML ที่เนเธอร์แลนด์ — ซึ่งเป็นบริษัทเดียวในโลกที่ทำเครื่องระดับนั้นได้.
AI ก็เป็นแบบนี้เป๊ะ — แค่เป็นสายดิจิทัล. คู่มือแบ่ง “party” (ฝ่ายในห่วงโซ่) เป็นชั้นๆ ผมขอเรียบเรียงเป็นตารางของผมเอง ด้วยตัวอย่างที่คนคุ้น:
| ชั้น | คือใคร | ตัวอย่าง (ในวงการจริง) |
|---|---|---|
| First Party | ผู้ใช้ AI — ก็คือ “เรา” องค์กรลูกค้า | บริษัทคุณที่เอา AI มาใช้ |
| Third Party | คนที่ provider เราไปทำสัญญาตรงด้วย — ผู้ให้ข้อมูล, ผู้พัฒนาโมเดล, ผู้ให้บริการ cloud | AWS, Google, OpenAI, Hugging Face, Snowflake |
| Fourth Party | vendor ของ vendor — คนที่ third party ของเราไปจ้างต่อ | Cloudflare, TSMC, Dell, Microsoft |
| Fifth Party | คนที่ fourth party ไปพึ่งต่อ — สายมันยาวขึ้นเรื่อยๆ | ASML, Equinix, SAP, Oracle |
| Nth Party | ทุกชั้นที่ลึกกว่านั้น — ลึกแค่ไหนขึ้นกับว่าห่วงโซ่ซ้อนกี่ชั้น | การไฟฟ้า, บริการสิ่งแวดล้อม, บริษัทบริหารอาคาร data center |
หมายเหตุเรื่องการอ้างอิงชื่อบริษัท: รายชื่อบริษัทข้างบนยกมาเพื่อ “ให้เห็นภาพ” ว่าห่วงโซ่จริงมันลากไปถึงใครเท่านั้น ไม่ใช่การรับรองหรือเชียร์บริการใดเป็นพิเศษครับ
มาดูภาพ “สาย” ให้ชัดขึ้น — ผมวาดเป็นแผนผังของผมเอง โดยไล่จาก prompt ที่เราพิมพ์ ลงไปจนถึงผู้ผลิตชิปและเครื่องจักรพิมพ์วงจร:
เรา (First Party / Deployer) │ พิมพ์ prompt / เรียกใช้ AI ▼ AI Provider ── ผู้ให้บริการ AI ที่เราเซ็นสัญญาด้วย │ ├── Cloud ────────► ผู้ให้บริการ cloud (Third party) │ │ │ └─► ผู้ผลิต server/ฮาร์ดแวร์ (Fourth) │ │ │ └─► โรงงานผลิตชิป (Fifth) │ │ │ └─► ผู้ผลิตเครื่องพิมพ์วงจร (Nth) │ ├── Data storage ─► ผู้ให้บริการเก็บข้อมูล/วิเคราะห์ │ ├── Model API ───► เจ้าของโมเดลผ่าน API │ │ │ └─► ผู้ให้บริการ security/CDN │ │ │ └─► ผู้ดูแล data center จริงๆ │ └── Pretrained model ─► คลังโมเดลสำเร็จรูป │ └─► ผู้รับจ้างติด label ข้อมูล │ └─► ระบบ ERP เบื้องหลังภาพนี้สื่อความหมายอะไร? คือ เวลาคุณพิมพ์ prompt สั้นๆ เข้า AI หนึ่งครั้ง คุณกำลัง “พึ่งพา” บริษัทเป็นสิบ ที่คุณไม่เคยรู้จัก ไม่เคยเซ็นสัญญาด้วย และมองไม่เห็นเลยว่าเขาทำงานยังไง. ถ้าโรงงานผลิตชิปในไต้หวันถูก disrupt (เช่น แผ่นดินไหว หรือปัญหาภูมิรัฐศาสตร์) มันก็กระทบมาถึง AI ที่คุณใช้ทำงานประจำวันได้. ถ้า data center ที่ไหนสักแห่งในสายนี้ดับ บริการคุณก็ดับตาม. ถ้าใครในสายนี้ถูก hack ข้อมูลคุณก็อาจรั่วโดยที่ provider ตรงหน้าคุณก็ไม่รู้ตัว
ในมุม risk เราเรียกความเสี่ยงจากชั้นลึกๆ พวกนี้ว่า concentration risk (ความเสี่ยงจากการกระจุกตัว) เพราะถึงคุณจะใช้ provider คนละเจ้ากับคู่แข่ง แต่ลึกลงไปทุกคนอาจพึ่งโรงงานชิปเจ้าเดียวกัน หรือ cloud เจ้าเดียวกัน. เจ้าเดียวล่ม = ทั้งอุตสาหกรรมสะเทือนพร้อมกัน
มุมผู้บริหาร: คำถามที่ผู้บริหารต้องถามไม่ใช่แค่ “provider ตรงหน้าเราน่าเชื่อถือไหม” — แต่คือ “สายมันลึกแค่ไหน และเราพึ่งใครที่เรามองไม่เห็นบ้าง?” ในทางปฏิบัติ เราคุม Nth party โดยตรงไม่ได้ (เราเซ็นสัญญาได้แค่กับ third party) แต่เราสามารถ บังคับ third party ในสัญญาให้เขารับผิดชอบ “ทั้งสายข้างหลังเขา” ได้ — เช่น ระบุว่า “ถ้า subcontractor ของคุณทำข้อมูลเรารั่ว คุณ (third party) ต้องรับผิด”. และที่สำคัญ — ความลึกของสายควรเป็นปัจจัยในการตัดสินใจว่าจะใช้ provider เจ้านี้ไหมตั้งแต่แรก. ยิ่งสายลึกและทึบ ความเสี่ยงที่เรา “มองไม่เห็น” ยิ่งสูง
กับดักที่ผู้บริหารชอบติด (Supply Chain)
- กับดักที่ 1 — “เราเซ็นกับ provider ใหญ่ น่าเชื่อถือแล้ว = ปลอดภัย” ❌ provider ใหญ่ก็พึ่ง subcontractor เป็นสิบ ที่คุณไม่เห็น
- กับดักที่ 2 — “ใช้คนละ vendor กับคู่แข่ง = กระจายความเสี่ยงแล้ว” ❌ ลึกลงไปอาจพึ่ง cloud / โรงงานชิป เจ้าเดียวกัน (concentration risk)
- กับดักที่ 3 — “โหลดโมเดลโอเพนซอร์สฟรีมาใช้ ประหยัดดี” ❌ โมเดลสำเร็จรูปอาจมีมัลแวร์ฝังใน weights หรือถูก poison ข้อมูลเทรนมาก่อน
- กับดักที่ 4 — “supply chain เป็นเรื่องของ provider ไม่ใช่เรื่องเรา” ❌ ในฐานะ deployer ถ้าข้อมูลลูกค้าเรารั่วผ่านสายนี้ คนที่ลูกค้าฟ้องและแบรนด์ที่เสียคือ “เรา”
2.3 แล้ว deployer คุมห่วงโซ่ที่ “มองไม่เห็น” ได้ยังไง
โอเค พอเห็นภาพสายที่ยาวเป็น Nth-party แล้ว คำถามที่ผู้บริหารจะถามต่อทันทีคือ — “ถ้าเราคุมชั้นลึกๆ ไม่ได้ แล้วจะทำยังไง? นั่งรอวันซวยเหรอ?” ไม่ใช่ครับ. เราไม่ได้ไร้เครื่องมือ — เราแค่ต้องใช้เครื่องมือที่ “เอื้อมถึงได้จริง”. ผมขอเรียบเรียงเป็นชุดเครื่องมือ 4 อย่างที่ deployer ใช้ได้ — โดยโยงกลับไปที่ Shared Responsibility Model ที่เราคุยกันไปแล้ว (ฝั่ง deployer มีหน้าที่ “Supply Chain Risk Management” ชัดเจน)
1. Due Diligence — ตรวจประวัติก่อนจ้าง. ก่อนเซ็นสัญญากับ provider เราต้อง “ตรวจประวัติ” เขาเหมือนตรวจประวัติพนักงานก่อนรับเข้าทำงาน ไม่ใช่แค่ “เขาเก่งไหม” แต่ดูถึง “ฐานะการเงินมั่นคงไหม (ถ้าเจ๊งกลางทางเราจะค้าง), ชื่อเสียงเป็นยังไง, เคยมีประวัติข้อมูลรั่วไหม, แล้วเขาไปจ้างใครต่อบ้าง”. จุดสำคัญคือเราต้องถามไปถึง “เขาตรวจประวัติ subcontractor ของเขายังไง” เพราะนั่นคือวิธีเดียวที่เราจะ “เอื้อมมือ” ไปถึงชั้นลึกที่เราเซ็นสัญญาตรงไม่ได้
2. SBOM / AI-BOM — ขอ “รายการชิ้นส่วน”. ใครอ่าน EP.34 มาจะคุ้นกับคำว่า SBOM (Software Bill of Materials) — “ใบรายการชิ้นส่วน” ของซอฟต์แวร์ เหมือน bill of materials ของรถยนต์ที่บอกว่าใช้อะไหล่ของใครบ้าง. ในโลก AI มีแนวคิดต่อยอดที่เริ่มถูกพูดถึงคือ AI-BOM / model card — เอกสารที่บอกว่าโมเดลนี้เทรนจากข้อมูลอะไร ใช้ library อะไร มีข้อจำกัดอะไร. การ “ขอเอกสารพวกนี้” จาก provider ทำให้สายที่เคยทึบ “โปร่งขึ้น” — เราเริ่มเห็นว่าข้างในมีอะไร
3. Contractual Safeguards — บังคับผ่านสัญญา. อย่างที่ผมย้ำในมุมผู้บริหารข้างบน — เราเซ็นสัญญาตรงได้แค่กับ third party แต่เราใส่เงื่อนไขให้เขารับผิดชอบ “สายข้างหลังเขา” ได้. ข้อสัญญาที่ควรมี: การแจ้งเหตุเมื่อมีข้อมูลรั่ว (breach notification — ต้องแจ้งภายในกี่ชั่วโมง), ข้อกำหนดด้าน privacy/security ที่ subcontractor ต้องทำตามด้วย, สิทธิ์ในการ audit, และ SLA (ข้อตกลงระดับบริการ) ที่ชัด
4. Compliance Reports / Certifications — ขอใบรับรองจากบุคคลที่สาม. แทนที่จะต้องบินไป audit provider เองทุกเจ้า (ทำไม่ไหว) — เราขอ “รายงานที่ผู้ตรวจอิสระทำให้แล้ว” เช่น SOC 2, ISO ที่เกี่ยวข้อง. มันคือวิธี “ยืม” การตรวจสอบของคนอื่นมาใช้ ประหยัดแรงเราแต่ยังได้ความมั่นใจระดับหนึ่ง
ผมขอสรุปเป็นตารางว่า “ความเสี่ยงแต่ละชั้น ใช้เครื่องมือไหนเอื้อมถึง”:
| ชั้นที่กังวล | เราเซ็นสัญญาตรงได้ไหม | เครื่องมือที่ใช้เอื้อมถึง |
|---|---|---|
| Third party (provider ตรงหน้า) | ได้ | due diligence + สัญญา + SLA + audit rights |
| Fourth/Fifth party (vendor ของ vendor) | ไม่ได้ | บังคับผ่านสัญญา third party (“คุณต้องคุม subcontractor คุณ”) + ขอ SBOM/AI-BOM |
| Nth party (ลึกจนมองไม่เห็น เช่น โรงงานชิป) | ไม่ได้เลย | ประเมินเป็น concentration risk ตอนตัดสินใจเลือก + วางแผนสำรอง (เช่น มี provider สำรอง) |
มุมผู้บริหาร: หัวใจของการคุม supply chain ที่มองไม่เห็น คือเปลี่ยนจาก “ตรวจเองทุกชั้น” (ทำไม่ได้) มาเป็น “ผลักภาระความรับผิดและความโปร่งใสผ่านสัญญา + ใบรับรอง”. และต้องยอมรับความจริงข้อหนึ่ง — บางความเสี่ยง (เช่น โรงงานชิปเจ้าใหญ่ล่ม) เรา treat ไม่ได้เลย ทำได้แค่ “accept อย่างรู้ตัว + เตรียมแผนสำรอง”. สิ่งที่ยอมรับไม่ได้คือ “ไม่รู้ว่ามันมีอยู่”
2.4 จะ “เฝ้าระวัง” พนักงานที่จ้างมาจากข้างนอกยังไง (Best Practices / MLOps)
ทีนี้ — สมมติเราตัดสินใจแล้วว่าจะใช้ AI จาก provider. คำถามต่อไปคือ — เราจะ “เฝ้าดู” พนักงานคนนี้ตลอดเวลาที่เขาทำงานให้เรายังไง? เพราะ AI ไม่เหมือนซอฟต์แวร์ปกติที่ “เขียนเสร็จแล้วจบ” — มันเปลี่ยนพฤติกรรมได้ตลอด (เรียนรู้ใหม่, drift, provider อัปเดตโมเดลเงียบๆ)
นี่คือที่มาของวินัยที่เรียกว่า MLOps (Machine Learning Operations) — เปรียบได้กับ DevSecOps แต่สำหรับโลก AI โดยเฉพาะ. คือการ “เฝ้าดูและดูแล” โมเดลตลอดอายุการใช้งาน ไม่ใช่แค่ตอน deploy ครั้งแรก. คู่มือสรุปเป็น best practices ในการ monitor ผลงานของ AI vendor ผมขอเรียบเรียงเป็นตารางของผมเอง พร้อมแปลเป็นภาษาคน:
| Best Practice | แปลเป็นภาษาคน — เราต้องทำอะไร |
|---|---|
| เลือก metric ที่ใช่ | อย่าวัดมั่ว — เลือกตัวชี้วัดที่สะท้อน “งานจริง” ของ AI ตัวนั้น ผสมทั้งตัวชี้วัดภายใน (intrinsic) และผลลัพธ์ภายนอก (extrinsic) ตาม use case |
| ตั้ง logging + alert + monitoring ให้ดี | ต้องเห็นว่า AI ทำอะไรอยู่ตลอด + ตั้งเส้น threshold ชัด + กำหนดว่าใครต้องได้รับแจ้งเมื่อเกินเส้น. เฝ้าดู: คุณภาพ prompt, output ตรงประเด็นไหม, อคติ (bias), อารมณ์ (sentiment), เนื้อหาเป็นพิษ (toxicity) |
| ทดสอบเชิงโจมตี (adversarial test) | ลองโจมตีโมเดลเองดู — บิดเบือน token, jailbreak (หลอกให้ข้ามกฎ) เพื่อหาจุดอ่อนก่อนที่โจรจะหาเจอ |
| คุมความสะอาดของ input + ข้อมูล | เช็คคุณภาพข้อมูลสม่ำเสมอ ตรวจจับ bias, validate ทุก input, เฝ้าระวัง anomaly และ model drift (โมเดลค่อยๆ เพี้ยนไปตามเวลา) |
| Never trust, always verify | อย่าเชื่อ output ดิบๆ — บังคับให้ AI อ้างอิงแหล่งที่มา เพื่อให้เรา fact-check ได้ |
| Sanity check ข้ามโมเดล | ถามคำถามเดียวกันกับ AI หลายตัว แล้วเทียบคำตอบ — ถ้าตอบไม่ตรงกัน แปลว่าต้องระวัง |
| ตั้ง “gold image” แล้วค่อย fine-tune | ตั้งมาตรฐานกลาง (gold standard) ก่อน แล้วค่อยปรับจูนให้เข้า use case เรา — fine-tune เร็วกว่าและถูกกว่าเทรนใหม่จากศูนย์ |
| ดุลขนาดโมเดลกับต้นทุน | โมเดลใหญ่ฉลาดกว่า แต่ทุกครั้งที่เรียกใช้ก็เปลือง — ชั่งน้ำหนักค่า deploy + ค่า query ให้คุ้ม |
จุดที่ผมอยากเน้น 2 ตัว:
“Never trust, always verify” — คนที่อ่านซีรีส์ CyberSec มาจะคุ้นกับหลัก Zero Trust ใช่ไหมครับ. หลักเดียวกันเป๊ะ — แต่ใช้กับ “พนักงาน AI”. อย่าเชื่อแค่เพราะมันตอบอย่างมั่นใจ. AI ที่ตอบผิดแบบมั่นหน้า (hallucination) อันตรายกว่า AI ที่บอกว่า “ไม่รู้” เพราะมันชวนให้เราเชื่อ. การบังคับให้ AI อ้างแหล่งที่มา + ถามหลายตัวแล้วเทียบกัน คือ control ราคาถูกที่ผู้บริหารสั่งให้ทำได้ทันที
Model drift — โมเดลค่อยๆ “เพี้ยน”. สมมติเราเอา AI มาช่วยพยากรณ์ยอดขาย เทรนด้วยข้อมูลปี 2566. พอเข้าปี 2569 พฤติกรรมลูกค้าเปลี่ยน เศรษฐกิจเปลี่ยน — โมเดลเดิมที่เคยแม่นจะค่อยๆ ทำนายเพี้ยนขึ้นเรื่อยๆ ทั้งที่ “โค้ดไม่เปลี่ยนเลย”. นี่คือเหตุผลที่ AI ต้อง monitor ตลอด ไม่ใช่ “ติดตั้งเสร็จแล้วลืม”
ลองนึกภาพสมมติให้เห็นภัยเงียบของ drift ครับ. ร้านค้าออนไลน์แห่งหนึ่งใช้ AI แนะนำสินค้าให้ลูกค้า — ตอนเปิดใช้ใหม่ๆ ยอดขายจากการแนะนำพุ่งสวยมาก. แต่ผ่านไปปีกว่า เทรนด์สินค้าเปลี่ยน คนรุ่นใหม่เข้ามาเป็นลูกค้า — AI ยังแนะนำของแบบเดิมที่ “เคยขายดี” แต่ตอนนี้ไม่มีใครอยากได้แล้ว. ยอดขายจากการแนะนำค่อยๆ ตก เดือนละนิด — ช้าจนไม่มีใครสังเกต เพราะมัน “ไม่ได้พังแบบมีข้อความ error เด้ง”. กว่าจะรู้ตัวก็เสียโอกาสไปเป็นปี. นี่แหละครับความน่ากลัวของ drift — มันไม่ระเบิด มันแค่ “เสื่อมเงียบๆ” ซึ่งจับได้ก็ต่อเมื่อเรา ตั้ง metric เฝ้าดูไว้ล่วงหน้า เท่านั้น
อีกประเด็นที่ผมอยากเสริมจากตารางข้างบน คือคำว่า “gold image” + fine-tune. แปลง่ายๆ คือ แทนที่จะให้แต่ละทีมในบริษัทไปหา AI มาใช้กันเองมั่วๆ (เกิด “AI เถื่อน” กระจายทั่วองค์กร = shadow AI ที่คุมไม่ได้) เราก็ตั้ง “ตัวมาตรฐานกลาง” (gold image) ที่ผ่านการตรวจสอบแล้วหนึ่งตัว แล้วให้แต่ละทีมเอาตัวกลางนี้ไป “ปรับจูน” (fine-tune) ให้เข้างานตัวเอง. วิธีนี้ทั้งถูกกว่า เร็วกว่า แล้วก็ คุมความเสี่ยงได้จากจุดเดียว. ผู้บริหารควรผลักให้เกิดแนวทางนี้ แทนที่จะปล่อยให้ทุกคนต่างคนต่างใช้
มุมผู้บริหาร: ความผิดพลาดคลาสสิกคือคิดว่า AI เหมือนซอฟต์แวร์ — “ซื้อมา ติดตั้งเสร็จ ก็จบ”. แต่ AI คือ พนักงานที่ต้องมีการประเมินผลและกำกับต่อเนื่อง. ผู้บริหารต้องถามทีมว่า “เรามีคนเฝ้าดู output ของ AI ตัวนี้อยู่ไหม? ใครจะรู้ถ้ามันเริ่มเพี้ยน? เราตั้งเส้น threshold ไว้ที่เท่าไหร่ ถ้าเกินแล้วใครรับแจ้ง?” — ถ้าตอบไม่ได้ แปลว่าเราปล่อยพนักงานเทพคนนี้ทำงานโดยไม่มีหัวหน้าคุม. และข้อสำคัญ — งาน monitor นี้เป็นความรับผิดชอบของ deployer (เรา) ไม่ใช่ของ provider. provider ดูแลตัวโมเดล แต่ “ผลลัพธ์ที่กระทบธุรกิจเรา” เราต้องเฝ้าเอง
3. ปิด Domain 2 — เราเรียนอะไรไปบ้าง
ครับ มาถึงตรงนี้ Domain 2 จบแล้ว. ผมขอ “ถอยออกมามองภาพรวม” สักหน่อย เพราะ Domain 2 เป็นโดเมนที่ใหญ่และแน่นที่สุดโดเมนหนึ่ง
ตลอด Domain 2 เราเดินตามตรรกะของ “เจ้าของความเสี่ยง” มาตลอด — ไม่ใช่ผู้ตรวจสอบ. ภาพรวมทั้งโดเมนเดินเป็นเส้นเรื่องแบบนี้:
Part A: ประเมิน + ตั้งเส้น + รับมือ ┌─────────────────────────────────────────────┐ │ AI Trust → มองหาความเสี่ยง → Framework │ │ (NIST AI RMF: Govern/Map/Measure/Manage, │ │ EU AI Act: 4 ระดับความเสี่ยง) │ │ → ตั้งเส้นยอมรับ → รับมือ 4 ทาง │ │ (Accept/Avoid/Mitigate/Transfer) │ │ → Threat Modeling │ └─────────────────────────────────────────────┘ │ Part B: ภัยคุกคาม + ช่องโหว่ ┌─────────────────────────────────────────────┐ │ AI Threat Landscape → Mitigation Strategies │ └─────────────────────────────────────────────┘ │ Part C: Vendor + Supply Chain ┌─────────────────────────────────────────────┐ │ บทบาทเราในห่วงโซ่ → จัดการ Vendor → │ │ มุม Deployer → Shared Responsibility → │ │ Integration Risk → Supply Chain (Nth-party) │ ← ตอนนี้ └─────────────────────────────────────────────┘ถ้าจะให้ผมสรุป Domain 2 เป็นประโยคเดียวสำหรับเจ้าของกิจการ — คือ:
“AI คือพนักงานใหม่ที่เก่งมาก แต่เราจ้างเขามาทั้งที่ยังมองไม่เห็นว่าเขาเรียนรู้มาจากไหน มาจากสายไหน และจะพังตรงไหน — หน้าที่ของเราคือตั้งกฎ ตั้งเส้น เฝ้าดู และรับผิดชอบผลลัพธ์ — เพราะสุดท้าย ความเสี่ยงนี้เป็นของเรา ไม่ใช่ของ vendor.”
3 ข้อคิดที่ผมอยากให้ติดไม้ติดมือจาก Domain 2:
- เราเป็นเจ้าของความเสี่ยง ไม่ใช่ผู้ตรวจ — การจ้าง vendor ไม่ได้ “โอน” ความรับผิดออกจากเรา. เราตัดสินใจเอง เรารับผิดเอง (จำ Shared Responsibility ได้ไหมครับ — ส่วนของเราไม่เคยเป็นศูนย์)
- ความเสี่ยงที่อันตรายสุดคือความเสี่ยงที่ “มองไม่เห็น” — debt ในระบบเก่า, ลิขสิทธิ์ที่ปนมาในข้อมูลเทรน, subcontractor ชั้นที่ 5 ที่เราไม่รู้จัก. งานของผู้บริหารคือ “ส่องไฟ” เข้าไปในมุมที่มืด
- AI ต้อง “กำกับต่อเนื่อง” ไม่ใช่ “ติดตั้งเสร็จแล้วลืม” — monitor, verify, เทียบหลายตัว, เฝ้า drift. พนักงานเทพก็ต้องมีหัวหน้าคุม
เกริ่น Domain 3 — จาก”มองเห็นความเสี่ยง” สู่ “ลงมือสร้างเครื่องมือคุม”
Domain 2 ทั้งหมด เราอยู่ในโหมด “มองและตัดสินใจ” — มองว่าพนักงาน AI คนนี้เสี่ยงตรงไหน แล้วตัดสินใจว่าจะรับมือยังไง.
แต่พอตัดสินใจแล้วว่า “เราจะ mitigate” — คำถามต่อไปคือ “แล้วจะ mitigate ด้วยเครื่องมืออะไร? control อะไร? เทคโนโลยีไหน?”
นั่นคือสิ่งที่ Domain 3 จะพาไป — โลกของ เทคโนโลยีและการควบคุม (Technology & Controls) ของ AI Security. ถ้า Domain 2 คือ “การวางแผนรบ — รู้ว่าศัตรูอยู่ไหน” Domain 3 ก็คือ “คลังอาวุธ — เครื่องมือจริงๆ ที่เราหยิบมาใช้คุม AI ในแต่ละจุด” ตั้งแต่การคุม input/output, การป้องกันโมเดล, การวาง security architecture สำหรับ AI โดยเฉพาะ ไปจนถึง control ทางเทคนิคที่ลงมือทำได้จริง
จากมุม “ผู้บริหารที่ตั้งกฎและมองความเสี่ยง” ใน Domain 2 — Domain 3 จะพาเราเข้าใกล้ “เครื่องมือในมือทีมงาน” มากขึ้น แต่ยังคงมุมเดิม คือผู้บริหารต้องเข้าใจพอที่จะตัดสินใจเลือก control และจัดสรรทรัพยากรได้ถูก — ไม่ใช่ปล่อยให้ฝ่ายเทคนิคตัดสินใจคนเดียว
แล้วเจอกันตอนหน้าครับ เปิดประตูคลังอาวุธของ Domain 3 ไปด้วยกัน 🙂
อ้างอิงแนวคิด: AAISM — Domain 2: Section 2.13 (Integration Risk) และ Section 2.14 (AI Software Supply Chain Risk). กรอบแนวคิดสาธารณะที่อ้างถึง: NIST AI RMF 1.0 (ฟังก์ชัน Govern/Map/Measure/Manage), EU AI Act (ระดับความเสี่ยง unacceptable/high/limited/minimal), OWASP Top 10 for LLM Applications, MITRE ATLAS. ตัวอย่างทั้งหมดในบทเป็นกรณีสมมติเพื่อประกอบความเข้าใจ ชื่อบริษัทที่ปรากฏยกมาเพื่อให้เห็นภาพห่วงโซ่จริงเท่านั้น ไม่ใช่การรับรองบริการใด
