ลองนึกภาพ — พนักงานใหม่คนนี้ก็มี “ช่วงชีวิต” ของเขา#

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

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

AI ก็เป๊ะเลยครับ — มันมี วงจรชีวิต (AI Life Cycle) ตั้งแต่ “ยังไม่มีตัวตน” ไปจนถึง “วันที่ต้องปลดระวาง” และหัวใจที่ผมอยากให้จำทั้งตอนคือ:

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

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

ทำไมต้องเทียบกับ SDLC — และมันต่างกันตรงไหน#

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

ข่าวดีก็คือ เราไม่ต้องเริ่มจากศูนย์ กระบวนการคุมงานที่เรามีอยู่แล้ว เช่น การจัดการการเปลี่ยนแปลง (change management), การทำเอกสาร, การ sign-off ก่อนขึ้นระบบ พวกนี้เอามาใช้กับ AI ได้เกือบหมด

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

ประเด็นสุดท้ายในตารางสำคัญมาก ในแนวทาง NIST (กรอบบริหารความเสี่ยง AI ของสถาบันมาตรฐานสหรัฐ — NIST AI RMF) เขาเตือนไว้ตรงๆ ว่า “ความเสี่ยงที่วัดตอนต้นวงจร อาจได้ผลไม่เหมือนกับที่วัดตอนปลายวงจร” ความเสี่ยงบางตัวมันแฝงอยู่เงียบๆ (latent) แล้วค่อยโตขึ้นเมื่อ AI ปรับตัวและวิวัฒนาการไปตามข้อมูลใหม่

แปลเป็นภาษาเจ้าของกิจการก็คือ อย่าตรวจความเสี่ยง AI แค่ตอนซื้อหรือตอนสร้างเสร็จแล้วปิดแฟ้ม มันไม่เหมือนซื้อเครื่องจักรที่ตรวจรับครั้งเดียวจบ AI ต้องตรวจซ้ำเรื่อยๆ เพราะตัวมันเองเปลี่ยนได้

ภาพรวม 7 เฟส — แผนที่ทั้งใบก่อนลงรายละเอียด#

ก่อนเดินทีละเฟส ผมขอกางแผนที่ทั้งใบให้ดูก่อน วงจรชีวิต AI ที่ใช้กันในแนวทางสากล (OECD และ NIST ใช้โครงเดียวกัน) แบ่งเป็น 7 ช่วง ดังนี้:

1
   [1] วางแผน & ออกแบบ
2
        (Plan & Design)
3
              │
4
              ▼
5
   [2] เก็บ & เตรียมข้อมูล
6
        (Collect & Process Data)
7
              │
8
              ▼
9
   [3] สร้าง / ปรับโมเดล
10
        (Build / Adapt Model)
11
              │
12
              ▼
13
   [4] ทดสอบ-ประเมิน-ตรวจสอบ-ยืนยัน
14
        (Test, Evaluate, Verify, Validate = TEVV)
15
              │
16
              ▼
17
   [5] ปล่อยขึ้นใช้งานจริง
18
        (Deploy)
19
              │
20
              ▼
21
   [6] ใช้งาน & เฝ้าดู
22
        (Operate & Monitor) ←──┐  วนกลับมาประเมินซ้ำได้
23
              │                 │  (เจอปัญหา → ย้อนไปแก้เฟสก่อน)
24
              └─────────────────┘
25
              │
26
              ▼
27
   [7] ปลดระวาง
28
        (Retire / Decommission)

ลูกศรที่วนกลับตรงเฟส 6 สำคัญครับ — วงจรนี้ ไม่ใช่เส้นตรงทางเดียว เฟสใช้งานจริงสามารถส่งสัญญาณกลับไปให้เราย้อนไปแก้เฟสก่อนหน้าได้เสมอ (เช่น ใช้ไปแล้วเจอว่าข้อมูลที่เทรนมาเริ่มเก่า ก็ต้องวนกลับไปเฟส 2)

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

ทีนี้เราจะเดินทีละเฟส ลงรายละเอียดในมุม “ผู้บริหารต้องตัดสินใจและคุมอะไร” กันครับ

เฟส 1 — วางแผน & ออกแบบ (Plan & Design)#

นี่คือเฟสที่ผมอยากให้เจ้าของกิจการ ลงแรงมากที่สุด เพราะมันคือเฟสที่ “ถูกที่สุด” ที่จะแก้ความผิดพลาด แก้บนกระดาษมันถูกกว่าแก้ของที่สร้างเสร็จแล้วเสมอ เหมือนหลัก Shift-Left ใน DevSecOps ที่ผมเล่าใน EP.34

เฟสนี้คือการตอบให้ชัดว่า AI ตัวนี้เกิดมาเพื่ออะไร ตั้งแต่แนวคิดของระบบ สมมติฐานที่ตั้งไว้ บริบทที่จะใช้ ความต้องการ และอาจรวมถึงการทำตัวต้นแบบ (prototype) ลองของก่อน

สิ่งที่ผู้บริหารต้องคุมในเฟสนี้:

• ตั้งเป้าและตัวชี้วัดความสำเร็จให้ชัด — “สำเร็จ” ของโปรเจกต์นี้หน้าตายังไง วัดด้วยตัวเลขอะไร. ถ้าตอบไม่ได้ตั้งแต่ต้น แปลว่าเรายังไม่พร้อมเริ่ม
• ทำเอกสาร business use case — เขียนให้ชัดว่าปัญหาคืออะไร AI จะแก้ยังไง และต้องให้ ผู้มีส่วนได้ส่วนเสีย (stakeholder) ที่เกี่ยวข้อง มาร่วมเขียน ไม่ใช่ฝ่าย IT คิดเองคนเดียว
• ดึงคนที่เกี่ยวข้องเข้ามาตั้งแต่เนิ่นๆ — คนหน้างานรู้ข้อจำกัดที่ห้องประชุมไม่รู้ การดึงเขาเข้ามาแต่ต้นทำให้ทุกคน “เป็นเจ้าของร่วม” และลดแรงต้านตอนใช้จริง
• กำหนดโครงสร้างคนรับผิดชอบ — ใครเป็นคนตัดสินใจ ใครรับผิดเรื่องจริยธรรมและกฎหมาย ต้องมีชื่อชัดตั้งแต่ตอนนี้
• ประเมินความเสี่ยงรอบแรก — รวมถึงผลกระทบเชิงจริยธรรมและสังคม โดยเฉพาะการมองหา อคติ (bias) ที่อาจซ่อนอยู่ในข้อมูลหรือตัวอัลกอริทึม และคิดวิธีลดมันไว้ล่วงหน้า
• วางกรอบการกำกับข้อมูล (data governance) — ตั้งแต่ตอนนี้เลยว่าข้อมูลจะเก็บ/ใช้/ทิ้งยังไงให้เคารพความเป็นส่วนตัวและไม่ผิดกฎหมาย

ตัวต้นแบบ (prototype) เป็นเครื่องมือสำคัญของเฟสนี้ มันให้เราลองของจริงเล็กๆ เพื่อพิสูจน์ว่าแนวคิดเวิร์กไหม เจอปัญหาตั้งแต่ยังเล็ก ก่อนจะทุ่มงบเต็มที่

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

กับดักที่พบบ่อยในเฟส 1:

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

เฟส 2 — เก็บ & เตรียมข้อมูล (Collect & Process Data)#

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

ถ้าพลาดเฟสนี้ AI จะออกผลลัพธ์ที่ ผิดเพี้ยน มีอคติ และเสี่ยงผิดกฎหมายความเป็นส่วนตัว มาดูกันว่าเฟสนี้ทำอะไรและผู้บริหารต้องคุมตรงไหน:

1) เก็บข้อมูล (Collect) — รวบรวมข้อมูลจากหลายแหล่ง ทั้งแบบมีโครงสร้าง (ตาราง) และไม่มีโครงสร้าง (ข้อความ รูป เสียงเซ็นเซอร์). จุดที่ผู้บริหารต้องคุมแบบห้ามพลาดคือ:

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

2) ทำความสะอาดข้อมูล (Clean) — กำจัดข้อมูลที่ขัดแย้งกัน ซ้ำซ้อน หรือผิดพลาดออก ให้เหลือแต่ข้อมูลที่ถูกต้องและใช้งานได้

3) ตรวจความครบและคุณภาพ (Completeness & Quality Check) — เช็กว่าชุดข้อมูลครอบคลุมขอบเขตที่ต้องการไหม ตอบโจทย์ business case ที่ตั้งไว้ในเฟส 1 ไหม. ต้องดูทั้ง:

• ข้อมูลที่ ขาดหาย (missing) — มีช่องว่างตรงไหนที่จะทำให้ผลเพี้ยน
• ความผิดปกติและค่าโดดๆ (anomalies & outliers) ที่อาจดึงผลให้เบี้ยว
• ความสดใหม่และตรงประเด็น — ข้อมูลเก่าเกินไปหรือไม่เกี่ยวกับเป้าหมายธุรกิจหรือเปล่า

4) บันทึกที่มาของข้อมูล (Data Provenance) — อันนี้เป็น control ที่ผู้บริหารต้องบังคับให้มี เพราะมันคือ หลักฐานความโปร่งใสและความรับผิดชอบ ของทั้งโปรเจกต์. เอกสารที่มาข้อมูลควรบอก:

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

กับดักที่พบบ่อยในเฟส 2:

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

เฟส 3 — สร้าง / ปรับโมเดล (Build / Adapt Model)#

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

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

• เลือกโมเดล/อัลกอริทึมให้เหมาะกับงาน — เลือกตามธรรมชาติของข้อมูล ความซับซ้อนของปัญหา และผลลัพธ์ที่อยากได้. (เลือกผิดประเภท = ทำงานไม่มีประสิทธิภาพ หรือผลไม่แม่น)
• ปรับจูนและเทรน (Calibrate & Train) — การปรับจูนคือการปรับค่าพารามิเตอร์ของโมเดลให้แม่นขึ้น เป็นงานที่ต้องวนทำซ้ำหลายรอบ ลองแล้วปรับ. การเทรนคือป้อนข้อมูลปริมาณมากให้มันเรียนรู้แพตเทิร์น

แต่สอง control ต่อไปนี้คือสิ่งที่ผู้บริหารต้อง บังคับให้มี เพราะมันคือเกราะป้องกันความเสี่ยงในมุมบริหารโดยตรง:

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

2) การบันทึกเหตุการณ์อัตโนมัติ (Automated Event Recording / Logging) — ออกแบบให้ระบบจดบันทึกทุกการกระทำและการตัดสินใจสำคัญของ AI ไว้อัตโนมัติ. ทำไมผู้บริหารต้องสน — เพราะ log นี้คือสิ่งที่ทำให้เรา:

• เฝ้าดูและตรวจสอบ (monitor & audit) ได้ว่า AI ทำอะไรไปบ้าง
• จับความผิดปกติได้ทันท่วงที
• มีหลักฐานเวลาเกิดเหตุ ว่า AI ตัดสินใจอะไร เมื่อไหร่ บนข้อมูลอะไร

3) วางจุดให้คนเข้ามาตรวจ (Human-in-the-loop = HITL) — ออกแบบให้มี “คน” คอยตรวจและยืนยันการตัดสินใจของ AI ที่จุดสำคัญๆ มันคือการเอาจุดแข็งของคน (วิจารณญาณ) มาเสริมจุดแข็งของ AI (ความเร็ว) HITL เป็นเรื่องใหญ่ที่ผมจะเล่าละเอียดในตอนหลังของ Domain 3 ตอนนี้แค่จำว่า เฟสสร้างโมเดลต้องออกแบบ “ช่องให้คนแทรกได้” ไว้ตั้งแต่แรก ไม่ใช่ไปแปะทีหลัง

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

กับดักที่พบบ่อยในเฟส 3:

• ไล่ตามความแม่นยำอย่างเดียวจนได้โมเดลที่อธิบายไม่ได้ พอเอาไปใช้กับงานที่ต้องให้เหตุผลก็ติดล็อก
• ไม่ทำ logging ตั้งแต่ต้น พอเกิดเหตุก็ไม่มีหลักฐานว่า AI ทำอะไรไป
• คิดว่า HITL คือ “เดี๋ยวค่อยใส่ทีหลัง” — แต่ระบบที่ไม่ได้ออกแบบช่องให้คนแทรก จะแทรกทีหลังแทบไม่ได้

เฟส 4 — ทดสอบ-ประเมิน-ตรวจสอบ-ยืนยัน (TEVV)#

เฟสนี้คำเต็มยาวมาก Test, Evaluate, Verify, Validate (TEVV) แต่ผมขอแปลแก่นให้จำง่ายเป็น 2 คำถาม:

• Verify (สร้างถูกไหม): โมเดลถูกสร้างตรงตามที่ออกแบบไว้หรือเปล่า
• Validate (ตอบโจทย์ไหม): โมเดลทำงานได้ผลถูกต้องเชื่อถือได้ และ ตอบโจทย์ธุรกิจที่ตั้งไว้ตั้งแต่เฟส 1 จริงไหม

ความต่างของสองคำนี้สำคัญนะครับ “สร้างถูกตามสเปก” ไม่เท่ากับ “ตอบโจทย์จริง” เราอาจสร้างของได้ตรงสเปกเป๊ะ แต่สเปกนั้นแก้ปัญหาธุรกิจไม่ได้ก็เป็นได้

control สำคัญของผู้บริหาร: การทดสอบ AI ต้องเดินผ่านกระบวนการจัดการการเปลี่ยนแปลง (change management) เดียวกับระบบอื่นในบริษัท และต้องทดสอบเทียบกับ business justification เดิม ไม่ใช่แค่ทดสอบว่า “มันรันได้”

วิธีทดสอบมีหลายแบบ ผมเรียบเรียงเป็นตารางให้เห็นว่าแต่ละแบบ “กันความเสี่ยงตัวไหน”:

เฟส 5 — ปล่อยขึ้นใช้งานจริง (Deploy)#

ผ่านด่านทดสอบแล้ว ก็ถึงเวลา เอา AI ขึ้นใช้งานจริง เฟสนี้ฟังดูเหมือนแค่ “กดปุ่ม launch” แต่จริงๆ มีงานคุมหลายอย่าง:

• นำร่องก่อน (Piloting) — ทดสอบในวงจำกัด/สภาพแวดล้อมควบคุม ก่อนปล่อยเต็มสเกล เพื่อจับปัญหา วัดผล และเก็บ feedback จากผู้ใช้จริงกลุ่มเล็กก่อน. มันคือ proof of concept รอบสุดท้ายในสภาพจริง
• ตรวจความเข้ากันได้กับระบบเดิม (Compatibility) — AI มักต้องเสียบเข้ากับระบบและซอฟต์แวร์เดิมที่บริษัทใช้อยู่ การเช็กว่ามันทำงานร่วมกันได้ช่วยกันไม่ให้ระบบเดิมล่ม. อาจต้องปรับจูนทางเทคนิค ทำตัวเชื่อม (integration) หรือกระทั่งอัปเดตระบบเดิม
• ดูแลถึงบุคคลที่สามและผู้นำไปใช้ปลายทาง (downstream deployers) — ถ้าเราส่ง AI ต่อให้คนอื่นใช้ ต้องให้คำแนะนำการติดตั้ง ตั้งค่า แก้ปัญหา และดูแลรักษาที่ชัดเจน
• เอกสารทางเทคนิคโดยละเอียด — ทำไว้ตลอดกระบวนการพัฒนาและเก็บรักษาตลอดวงจรชีวิต. เอกสารนี้ทำ 2 หน้าที่: (1) เป็นคู่มือส่งมอบ และ (2) เป็น หลักฐานความสอดคล้องตามกฎเกณฑ์ (compliance) — รวมคำแนะนำ การประเมินความเสี่ยง การ map กับข้อกำหนดกฎหมาย ฯลฯ
• จัดการการเปลี่ยนแปลงคน (Organizational Change Management) — นี่คือจุดที่ผู้บริหารมักลืม. การปล่อย AI ไม่ใช่แค่เรื่องเทคนิค แต่คือการเปลี่ยนวิธีทำงานของคน:
  • เทรนพนักงาน ให้เข้าใจบทบาทและหน้าที่ใหม่
  • สร้างการรับรู้และการยอมรับ (buy-in) — คนกลัว AI มาแย่งงานจะต่อต้านเงียบๆ
  • มี ช่องทางรับ feedback ที่กระตุ้นให้เจ้าของระบบ AI ลงมือแก้เมื่อผู้ใช้เจอปัญหา

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

กับดักที่พบบ่อยในเฟส 5:

• ปล่อยเต็มสเกลทันทีโดยไม่ทำ pilot — พังทีก็พังทั้งบริษัท
• ลืมว่าระบบเดิมต้องคุยกับของใหม่ พอเสียบเข้าไประบบเดิมรวน
• โฟกัสแต่เทคนิค ลืมเทรนคน — ของดีแต่ไม่มีใครใช้เป็น

เฟส 6 — ใช้งาน & เฝ้าดู (Operate & Monitor)#

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

งานหลักของเฟสนี้:

• ดูแลงานประจำวัน ของ AI ให้ทำงานได้ปกติ
• วัดและบันทึกตัวชี้วัดคุณภาพ (quality metrics) อย่างเป็นระบบ — ไม่ใช่ดูตอนเสียแล้วค่อยดู แต่วัดต่อเนื่องเพื่อจับ “อาการเสื่อม” แต่เนิ่นๆ
• ประเมินทั้งผลที่ตั้งใจและผลที่ไม่ได้ตั้งใจ (intended & unintended consequences) — AI อาจสร้างผลข้างเคียงที่เราไม่ได้คิดไว้ ต้องมีกลไกจับให้ได้ ว่ามันยังตรงกับเป้าธุรกิจและยังอยู่ในกรอบจริยธรรมไหม
• ตั้งระบบจัดการคุณภาพ (Quality Management System = QMS) — ช่วยให้สอดคล้องกับมาตรฐานและกฎเกณฑ์ โดยใช้เอกสารชุดเดิมที่ทำมาตั้งแต่เฟสก่อนๆ (เอกสารเทคนิค การประเมินความเสี่ยง compliance mapping) มาดูแลต่อเนื่อง พร้อม ตรวจสอบ (audit) และอัปเดตเป็นรอบ

จุดที่ผมอยากเน้นที่สุดในเฟสนี้คือเรื่อง “การเสื่อมของโมเดล (drift)” แม้คู่มือจะไม่ได้ใช้คำนี้ตรงๆ แต่นี่คือหัวใจของการ monitor เลย: โลกเปลี่ยน ข้อมูลเปลี่ยน พฤติกรรมลูกค้าเปลี่ยน แต่โมเดลเรายังเทรนมาจากโลกเก่า AI ที่เคยแม่น 95% เมื่อปีก่อน อาจเหลือ 70% ปีนี้โดยที่ไม่มีใครรู้ ถ้าไม่ได้เฝ้าวัด

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

กับดักที่พบบ่อยในเฟส 6:

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

เฟส 7 — ปลดระวาง (Retire / Decommission)#

เฟสสุดท้าย คือการ ให้ AI “ออกจากงาน” ซึ่งหลายบริษัทไม่เคยคิดถึงเลย แล้วก็ทิ้งระบบเก่าค้างไว้จนกลายเป็นความเสี่ยงเงียบ

AI ถูกปลดระวางได้จาก 2-3 สาเหตุ:

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

เมื่อตัดสินใจปลดแล้ว ต้องทำ แผนปลดระวาง (decommissioning plan) ที่เดินผ่าน change management เหมือนเฟสอื่นๆ โดยครอบคลุม:

• การย้ายหรือลบข้อมูล (data migration / deletion) — ข้อมูลที่ค้างในระบบ AI ที่เลิกใช้คือความเสี่ยงรั่วไหล ต้องจัดการให้เรียบร้อย
• การจัดการการเชื่อมต่อกับระบบอื่น (integration) — ถอดออกยังไงไม่ให้ระบบอื่นที่พึ่งมันอยู่พังตาม
• ความต่อเนื่องของงาน (continuity of operations) — งานที่ AI ตัวนี้เคยทำ ต้องมีคน/ระบบอื่นรับช่วงต่อ ไม่ให้สะดุด
• สื่อสารกับผู้เกี่ยวข้องให้ชัด — ตั้งความคาดหวัง ลดการกระทบกระเทือนช่วงเปลี่ยนผ่าน

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

กับดักที่พบบ่อยในเฟส 7:

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

สรุป Domain 3 ฝั่งวงจรชีวิต — แผนที่ใบเดียวที่ผู้บริหารต้องพกติดตัว#

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

หน้าที่ของผู้บริหารใน Domain 3 ฝั่งนี้ ไม่ใช่การลงไปสร้างโมเดลเอง แต่คือการ รู้ว่าตอนนี้ AI อยู่เฟสไหน และวาง control ให้ถูกเฟส:

1. วางแผน & ออกแบบ — ลงแรงมากที่สุด ตั้งเป้าให้ชัด หาคนรับผิดชอบ ประเมินเสี่ยงรอบแรก
2. เก็บ & เตรียมข้อมูล — คุม consent + คุณภาพ + ที่มาข้อมูล (เฟสที่ SDLC ไม่มี)
3. สร้าง / ปรับโมเดล — บังคับให้มี explainability + logging + ช่อง HITL
4. ทดสอบ (TEVV) — ถือ go/no-go ไว้ในมือ ต้อง red team + ตรวจ bias ก่อนปล่อย
5. ปล่อยขึ้นใช้งาน — pilot ก่อน + เทรนคน + จัดการการเปลี่ยนแปลง
6. ใช้งาน & เฝ้าดู — เฟสยาวที่สุด ห้าม “ปล่อยแล้วลืม” ต้องกันงบ+คนไว้
7. ปลดระวาง — ปิดประตูให้สนิท ลบข้อมูล ปิดสิทธิ์ ส่งมอบงาน

และอย่าลืมหลักจาก NIST 2 ข้อ — (1) วัดความเสี่ยงซ้ำตลอดวงจร เพราะความเสี่ยงบางตัวซ่อนตอนต้นแล้วโตตอนปลาย และ (2) เราในฐานะ deployer เห็นความเสี่ยงคนละมุมกับคนสร้าง ฉะนั้นต่อให้ซื้อของสำเร็จมา ก็ต้องประเมินเสี่ยงในบริบทของเราเองเสมอ

ตอนนี้เราได้ “แผนที่เวลา” ของ AI แล้วว่ามันเดินจากเกิดถึงปลดยังไง และความเสี่ยงเปลี่ยนหน้าตาตรงไหนบ้าง ตอนต่อๆ ไปของ Domain 3 เราจะซูมเข้าไปในเฟสที่ “วัตถุดิบ” สำคัญที่สุดอยู่ นั่นคือเรื่อง ข้อมูล ว่าจะกำกับ (governance) และรักษาความปลอดภัย (security) ของข้อมูลที่หล่อเลี้ยงพนักงาน AI คนนี้ยังไง เพราะอย่างที่เราเห็นในเฟส 2 แล้วว่า ข้อมูลพังเมื่อไหร่ AI ก็พังตาม

อ้างอิงแนวคิด: AAISM — Domain 3: Section 3.3 (AI Life Cycle Phases). โครงวงจรชีวิต 7 เฟสอ้างอิงแนวทางสาธารณะของ OECD AI Principles และ NIST AI RMF 1.0 (NIST AI 100-1) เรื่องการวัดความเสี่ยงตลอดวงจรและมุมมองความเสี่ยงที่ต่างกันของ AI actors. กรอบความปลอดภัย AI สาธารณะที่อ้างถึง: OWASP Top 10 for LLM Applications และ MITRE ATLAS. ตัวอย่างทั้งหมดในบทเป็นกรณีสมมติเพื่อประกอบความเข้าใจ ไม่ใช่เหตุการณ์จริงของผู้เขียน