กู้โครงการ AI ที่ล้มเหลว: วินิจฉัย 30 วันสำหรับหน่วยงานในไทย

เมื่อเริ่มเห็นว่าโครงการ AI ล้มเหลว การเร่งพัฒนาเพิ่มอาจทำให้ปัญหาหนักขึ้น PoC ดูดีแต่ความแม่นยำตกเมื่อใช้ข้อมูล production หน้างานไม่ใช้ ระบบติดที่ ERP หรือเครื่องจักร และ vendor เสนอเพียงปรับโมเดลอีกรอบ ในจุดนี้องค์กรไม่ต้องการ roadmap การนำ AI มาใช้แบบทั่วไป แต่ต้องการการวินิจฉัย recovery 30 วัน เพื่อแยกอาการออกจากสาเหตุและเลือกด้วยหลักฐาน 4 ทาง: ทำต่อ ลดขอบเขต ออกแบบใหม่ หรือหยุด

บทความนี้สำหรับโครงการ AI ของหน่วยงานในประเทศไทยซึ่งหยุดชะงักหรือไม่ถึงความคาดหวัง เราไม่ใช้สถิติอัตราความล้มเหลวที่หลักฐานอ่อน ไม่สร้างค่าบริการหรือกรณีศึกษาสมมติ เนื้อหาครอบคลุม baseline, test set, holdout, KPI ธุรกิจ, metric โมเดล, data drift, human override, IT/OT, log, stop rule, สัญญาและเอกสาร exit ก่อนสรุปเป็น decision memo ที่อนุมัติได้

อย่าให้ “AI ล้มเหลว” จบที่คำบอกอาการ

“ความแม่นยำไม่ดี” “ช้า” และ “โรงงานไม่ใช้” เป็นอาการ ไม่ใช่ root cause ความแม่นยำที่ลดลงอาจมาจาก distribution ของ input, label ผิด, นิยามธุรกิจเปลี่ยน, preprocessing ต่างกัน, permission, model version, threshold, UI หรือการฝึกผู้ใช้ หากขอให้ vendor “ปรับ accuracy” จากอาการเพียงอย่างเดียว การ tune โมเดลอาจดำเนินต่อไปโดยปัญหา workflow และข้อมูลยังอยู่

ในการประชุมวินิจฉัยครั้งแรก ให้แปลงความเห็นเป็นข้อเท็จจริงที่สังเกตได้

อย่าเริ่มด้วยการหาคนผิด ให้เริ่มด้วยคำถามว่า สมมติฐานใดสามารถหักล้างได้ด้วยหลักฐานใด ความรับผิดเทียบกับสัญญาได้ภายหลัง แต่ log หรือ configuration ที่ถูกเขียนทับอาจกู้คืนไม่ได้

รักษาหลักฐานก่อนเริ่มวินิจฉัย 30 วัน

อย่า retrain หรือเปลี่ยน configuration จำนวนมากในวันแรก สถานะปัจจุบันอาจเป็นตัวเปรียบเทียบเดียว ให้ประกาศ diagnostic freeze และยกเว้นเฉพาะมาตรการความปลอดภัยเร่งด่วน ห้ามเปลี่ยน model, prompt, threshold, preprocessing, retrieval index หรือ data connection โดยไม่มี approval

สิ่งที่ต้องรักษาใน 48 ชั่วโมงแรก

• Version production/PoC ของ model, prompt, rule, library และ container
• ID เงื่อนไข extract, hash และวันที่ของ training, validation, test, holdout
• Log input, output, confidence, citation, error, latency และ human override
• Interface กับ change history ของ ERP, MES, SCADA, data lake และ API gateway
• Requirement, acceptance criteria, PoC report, บันทึกการประชุม, change request, incident, vendor report
• Agreement, SOW, data term, SLA, IP, transition support และ subprocessor

หลีกเลี่ยงการสร้างสำเนาวินิจฉัยโดยไม่มีการควบคุม โดยเฉพาะข้อมูลส่วนบุคคลหรือความลับทางการค้า ใช้เอกสาร PDPA ทางการที่ ETDA เผยแพร่เป็นจุดเริ่ม และ review purpose, access, retention, processing role กับกฎหมายหรือ DPO บทความนี้ไม่ใช่คำแนะนำทางกฎหมาย

ภาพรวม recovery sprint 30 วัน

สามสิบวันไม่ใช่คำสัญญาว่าจะแก้ทุกอย่าง แต่เป็น timebox เพื่อรวบรวมหลักฐานพอที่จะหยุดการตัดสินใจลงทุนแบบคลุมเครือ

Day 1–5: รักษาข้อเท็จจริงและทำ symptom map

Freeze สัญญา requirement version data และ log จัดอาการเป็น business, model, data, integration, operation, governance เชิญ management, business, user, IT, security, legal และ vendor สร้าง timeline เดียว: เดิมตั้งใจทำอะไร เปลี่ยนอะไร เมื่อไร ใครอนุมัติ

Deliverable คือ evidence inventory, symptom map, change timeline และรายการหลักฐานที่ขาด ยังไม่เลือก solution ในช่วงนี้

Day 6–12: สร้าง baseline และ evaluation design ใหม่

หาก success criteria เดิมคลุมเครือ ให้วัด baseline งานปัจจุบันใหม่ ตรวจการแยก test/holdout คุณภาพ label กลุ่มเป้าหมาย ช่วงเวลา และ segment ตามผลิตภัณฑ์ ภาษา site หรือกะ ตรวจด้วยว่าข้อมูล PoC เป็นตัวแทน production จริงหรือไม่

Deliverable คือ metric dictionary, data lineage, evaluation script ที่ทำซ้ำได้ version ที่ทดสอบ และข้อจำกัด

Day 13–20: ทดสอบ causal hypothesis ด้วย experiment จำกัด

เปลี่ยนปัจจัยให้น้อยที่สุดในแต่ละ hypothesis การเปลี่ยน model, prompt, data, threshold พร้อมกันทำให้ไม่รู้สาเหตุ เปรียบเทียบ model เดียวกับ preprocessor เก่า หรือ test set เดียวกับ model version เดียวที่เปลี่ยน และเทียบผลธุรกิจก่อน/หลัง human override

เก็บ hypothesis, experiment, result, uncertainty และเงื่อนไข reproduction

Day 21–26: ประเมินการกู้คืนด้าน operation, integration, contract

แม้โมเดลแก้ได้ แต่ถ้า data right, API, OT safety, operation หรือ vendor dependency กู้ไม่ได้ ก็ขึ้น production ไม่ได้ ประเมิน owner, monitoring, incident, cost driver และความสามารถโอน code, setting, evidence แยกจากโมเดล

Day 27–30: อนุมัติ decision memo 4 ทาง

เปรียบเทียบ ทำต่อ ลดขอบเขต ออกแบบใหม่ หยุด ด้วยรูปแบบเดียว: benefit, residual risk, resource, experiment ถัดไป, stop rule, contract impact วันสุดท้ายต้องมี decision, owner, deadline และ evidence gate ไม่ใช่ “พิจารณาต่อ”

สร้าง baseline ใหม่

ความสับสนที่พบบ่อยคือไม่มี comparator ที่ถูกต้อง หาก volume, product mix, shift, skill หรือ demand เปลี่ยนระหว่างก่อนและหลัง AI การเทียบตรง ๆ จะผิด baseline คือการวัดกระบวนการปัจจุบันหรือทางเลือกภายใต้เงื่อนไขเทียบเคียง ไม่ใช่ค่าจินตนาการของ “ไม่มี AI”

baseline 3 ชั้น

1. Business baseline: handling time, rework, first resolution, defect escape, downtime
2. Method baseline: rule, search, statistical model หรือ human decision ที่ใช้เทียบ AI
3. Risk baseline: ความรุนแรงของ error, privacy exposure, unapproved action, recovery time

คะแนนโมเดลอาจดีขึ้นแต่เวลางานแย่ลงเพราะต้อง review มากขึ้น หรือค่าเฉลี่ยเพิ่มไม่มากแต่ส่ง critical case ให้คนได้ดีจนเกิดคุณค่าได้ จึงต้องใส่ business กับ model ในตารางเดียวกัน

ตรวจการปนเปื้อนของ test set และ holdout

เมื่อ PoC ดีแต่ production ไม่ดี ให้ตรวจว่า evaluation data ไหลเข้า development หรือไม่ หากปรับ prompt/threshold โดยดู test result ซ้ำ test set ก็กลายเป็น development data แบ่งบทบาทใหม่ให้ชัด:

• Training/development: ใช้ฝึกและปรับ prompt/logic
• Validation: เลือก approach, threshold, hyperparameter
• Test: ประเมิน approach ที่เลือก ไม่ใช้ optimize ซ้ำ
• Holdout: ไม่แตะจนถึง final decision gate
• Production shadow: สังเกต distribution production โดยไม่ทำ action อัตโนมัติ

แม้ข้อมูลน้อยก็ต้องแยกอย่างมีเหตุผล Random split อาจผิดหาก machine, document family, customer, lot หรือเวลาใกล้กันอยู่ทั้งสองฝั่ง ให้ split ตามหน่วยที่มีความหมายและบันทึก duplicate, derivative, labeler, version

MEASURE ใน NIST AI RMF Core กล่าวถึงการบันทึก test set, metric, TEVV tool การวัดในสภาพใกล้ deployment และ production monitoring Core ไม่ใช่ checklist หรือลำดับบังคับ แต่ให้ใช้ GOVERN, MAP, MEASURE, MANAGE แบบวนซ้ำตาม context การวินิจฉัยจึงต้องทำให้วิธีวัด reproduce ได้ ไม่ใช่รายงานตัวเลขอย่างเดียว

ประเมิน KPI ธุรกิจกับ metric โมเดลแยกกัน

Metric โมเดลจำเป็น แต่ใช้ตัดสินทำต่อเพียงอย่างเดียวไม่ได้ ให้ map metric กับ business outcome

แยกตาม product, equipment, language, user, shift และ risk class อย่าใช้เฉลี่ยอย่างเดียว ตรวจ critical minority class และ selection bias ระหว่างกลุ่มใช้/ไม่ใช้ AI

แยก data drift ออกจาก context drift

Data drift คือ input distribution เปลี่ยน แต่ไม่ใช่สาเหตุเดียว ยังมี concept drift ที่ความสัมพันธ์ input-label เปลี่ยน context drift ที่ purpose/workflow เปลี่ยน pipeline drift จาก ETL/API และพฤติกรรม user ที่เปลี่ยน

ตารางวินิจฉัย drift

อย่า retrain ทันทีทุกครั้งที่พบ drift หากเป็น label policy หรือ ETL defect การ retrain จะฝัง error กำหนด detection, impact review, approval, reevaluation, release

NIST AI Metrology Center เชื่อม metric, method, tool กับ AI RMF และ lifecycle แต่ระบุชัดว่าการมี resource ในศูนย์ไม่ได้หมายถึง NIST endorse, validate หรือรับรอง suitability ทีมต้องพิสูจน์ว่า metric เหมาะกับ use case ของตน

ตรวจว่า human override ใช้งานได้จริง

Specification อาจเขียนว่า “คนตัดสินสุดท้าย” แต่ operator อาจ override ไม่ได้จริง Recommendation ของ AI อาจเป็น default การ reject ต้องกรอกเหตุผลเพิ่ม เวลาสั้น ไม่มี permission หรือการไม่เห็นด้วยกระทบ KPI สิ่งเหล่านี้เป็น human-in-the-loop แค่รูปแบบ

อย่าตัดสิน override rate ว่าสูง/ต่ำอย่างเดียว ตรวจ situation, reason, outcome, time, AI confidence และ role แยกกรณี override ที่ถูกต้องมีน้อยออกจากกรณีควร override แต่ทำไม่ได้ ทดสอบ stop authority, restart approval, manual procedure, appeal และ log

วินิจฉัย integration และ IT/OT แยกจากโมเดล

ในโรงงานไทย โมเดลปกติอาจล้มที่ ERP, MES, SCADA, PLC, camera, network หรือ time sync ก่อน retrain ให้ trace record จาก input ถึง business action แบบ end-to-end

ตรวจ system of record, acquisition time, unit, missing value, retry, order, ID mapping, permission, timeout, buffer และ manual mode งาน vision ต้องตรวจ camera setting, lighting, lens, trigger, compression งาน sensor ต้องตรวจ calibration และประวัติเปลี่ยน หาก AI มีผลต่อ OT control ให้ทดสอบว่ากลับ read-only ได้หรือไม่ มี fail-safe ที่อุปกรณ์หรือไม่ และ change กระทบ quality/customer approval หรือไม่

ต้องมี equipment, control, quality, production, maintenance, cybersecurity ไม่ใช่ AI team เท่านั้น หาก ownership หยุดที่ model API ให้ตั้ง owner ของ end-to-end KPI

ใช้ log และ reproducibility ทบทวน AI vendor

การทบทวน vendor ไม่ได้แปลว่าต้องยุติความสัมพันธ์ แต่เป็นการทดสอบ reproducibility และ transferability ในฐานะ deliverable สำหรับ sample วินิจฉัย ให้ buyer หรือ independent team ลอง reproduce ด้วย version, input, configuration เดียวกัน

Reproduction package ขั้นต่ำ

• Architecture/data flow และ version matrix ของ model, prompt, rule, index
• Runtime, dependency, configuration และ secret reference
• วิธีสร้าง evaluation data, label definition, metric code, expected result
• Runbook deployment, rollback, monitoring, incident, backup, decommission
• Third-party API, OSS, license, terms, subprocessor
• Known limitation, unresolved issue, technical debt, backlog

อย่ารับคำว่า proprietary เป็นเหตุผลทั้งหมดที่ทำซ้ำไม่ได้ แม้เปิด IP ไม่ได้ ก็ยังตกลง input condition, output, interface, performance evidence, monitoring, exit export ได้ ระบุ black-box scope และขอบเขตที่ buyer ตรวจได้ในสัญญา

เขียน stop rule ก่อนซ่อมเพิ่ม

Recovery ยืดเยื้อเมื่อ “ปรับอีกนิดอาจดี” ไม่มี deadline ให้ approve stop rule ก่อนเริ่ม sprint

ตัวอย่างคือ ไม่ผ่าน minimum ของ critical safety class บน holdout, เกิด unauthorized-data exposure ซ้ำ, ยืนยัน data right ไม่ได้ภายในวันที่กำหนด, ทำ manual fallback ไม่ทัน, สร้าง required log ไม่ได้ หรือ improvement ต่ำกว่า minimum effect ที่ตกลง กำหนดค่าจาก risk tolerance ของโครงการ ไม่ copy ค่าทั่วไป

หยุดไม่จำเป็นต้องทิ้งทั้งหมด อาจหยุด autonomous action แต่คง decision support จำกัด product เอา sensitive data ออก หรือทำต่อเพียงภาษาเดียว เตรียม scope-reduction คู่ stop rule

4 ทางเลือก: ทำต่อ ลดขอบเขต ออกแบบใหม่ หยุด

ทำต่อ

เลือกเมื่อรู้สาเหตุ improvement ทำซ้ำได้ใน limited experiment และ residual risk ยอมรับได้ แนบวัน review ถัดไป monitoring owner, change approval, stop rule การทำต่อเพราะความเคยชินไม่ใช่ decision

ลดขอบเขต

ใช้เมื่อมี value บาง segment แต่ไม่ใช่ทุก site, product, language, user ระบุ scope, permission, manual work, KPI ใหม่ ไม่ใช่กลับไป PoC ที่ไม่มีกำหนด แต่เป็น production แคบที่พิสูจน์ value แล้ว

ออกแบบใหม่

ใช้เมื่อ objective ยังมีคุณค่า แต่ architecture, data pipeline, human workflow หรือ evaluation design ผิดพื้นฐาน แยก asset ที่ reuse กับ discard และ approve เป็น project ใหม่ อย่าเปลี่ยนชื่อโครงการเดิมให้เหมือนสำเร็จเพื่อย้ายงบ

หยุด

หยุดเมื่อไม่มี value ตาม objective, critical risk คุมไม่ได้, ข้อมูล/สิทธิ์ไม่มี หรือ non-AI alternative เหมาะกว่า รวม user notice, manual process, data return/deletion, access revoke, settlement, asset retention, lessons learned

MANAGE ใน NIST AI RMF Core ครอบคลุมการตัดสินว่าระบบบรรลุ purpose หรือควรดำเนิน development/deployment ต่อ รวมทั้งกลไก supersede, disengage, deactivate ระบบที่ผลไม่สอดคล้อง intended use การหยุดเป็นทางเลือก risk management ปกติ

Template decision memo

ผลวันที่ 30 ควรเป็น memo สั้นที่อนุมัติได้ โดยเก็บ evidence ใน appendix:

1. Objective เดิมและอาการปัจจุบัน: scope, user, expectation, observation
2. Cause และ confidence: confirmed, probable, unresolved
3. Reevaluation: baseline, holdout, segment, business KPI, risk, integration
4. เทียบ 4 ทาง: benefit, residual risk, resource, time, contract impact
5. Recommendation: ทางเลือกหนึ่งและเหตุผล
6. Condition/stop rule: gate, owner, evidence, deadline
7. Dissent: ข้อคัดค้านที่ยังไม่จบและเหตุผลที่ยังตัดสินใจได้

U.S. GAO AI Accountability Framework จัด accountability รอบ governance, data, performance, monitoring แม้พัฒนาสำหรับ federal agencies และ entities อื่น แต่ใช้เป็นคำถามแยกระบบ AI ที่มีอยู่ให้ audit ได้ ไม่ใช่ข้อกำหนดกฎหมายไทยหรือคำสั่งตรงต่อบริษัท

วินิจฉัยสัญญาและเอกสาร exit

สัญญาอาจจำกัด recovery มากกว่าเทคโนโลยี หากสิทธิ์ใน model/code, data export, log access, third-party service, minimum commitment และ transition support ไม่ชัด จะเทียบ redesign หรือเปลี่ยน vendor ไม่ได้

Review master agreement, SOW, change order, DPA, SLA, license, acceptance record, invoice basis, subprocessor, termination term หากสัญญากับความจริงต่างกัน ให้บันทึกและส่ง legal

เช็ก exit readiness

• รับ data, label, prompt, configuration, log, evaluation result แบบ machine-readable ได้หรือไม่
• แยก asset ของ customer, vendor, third party ได้หรือไม่
• revoke credential/connection และมีหลักฐานลบรวม backup ได้หรือไม่
• ผู้รับช่วงได้รับ interface, schema, runbook, known limitation หรือไม่
• มีช่วง parallel transition และ shutdown point ที่ปลอดภัยหรือไม่

ISO/IEC 42001:2023 กำหนด requirement สำหรับจัดตั้ง ใช้งาน รักษา และปรับปรุง AI management system ต่อเนื่อง อย่าตัดสิน recovery จาก certification อย่างเดียว ให้ตรวจ accountability, risk assessment, change, monitoring, corrective action และ continual improvement ของระบบนี้จริง

วิธีใช้เอกสาร TEVV ปี 2026

วันที่ 7 สิงหาคม 2026 NIST เปิดรับความคิดเห็นต่อ initial public draft ของ NIST AI 200-2 หรือ TEVV-Athlon Framework ถึง 6 ตุลาคม 2026 เอกสารนี้ยังไม่ใช่มาตรฐานฉบับสมบูรณ์ ให้ใช้เป็นแนวคิดที่กำลังพัฒนาเรื่อง test, evaluation, verification, validation สำหรับ AI use case หลากหลาย ไม่ใช้เป็น certification หรือ contractual conformity ที่บังคับ

Draft เสนอแนวคิด assessment ที่ customize ตาม TEVV objective ขององค์กร สำหรับ recovery จึงช่วยออกแบบ evidence ตาม operational goal แทนการลดทุกอย่างเหลือคะแนนเดียว แต่ memo ต้องระบุว่า terminology และ structure อาจเปลี่ยน

ETDA Generative AI Governance Guideline ก็ช่วยพิจารณา benefit, limitation, risk, application mode, governance ตามบริบทองค์กร ควรแยกสถานะ guideline ออกจากกฎหมายไทยและหน้าที่ตามสัญญา

FAQ เรื่อง AI ล้มเหลว

การกู้โครงการ AI คือการเปลี่ยน vendor หรือไม่?

ไม่ใช่ หาก requirement, data หรือ internal operation เป็นสาเหตุ การเปลี่ยน vendor อาจเกิดซ้ำ ต้องตรวจ evidence/reproducibility แล้วเทียบ correction กับ vendor เดิม, scope reduction, redesign, transition ด้วยเงื่อนไขเดียวกัน

การประเมิน AI PoC ใหม่ใช้ test set เดิมได้หรือไม่?

หากใช้ดูระหว่าง tuning ซ้ำ อาจไม่ independent ตรวจ usage history และสร้าง untouched holdout เมื่อทำได้ หากข้อมูลน้อยให้ split ตามเวลา equipment customer หรือ blind review อ่าน ค่าใช้จ่ายและเกณฑ์สำเร็จ AI PoC ในไทย สำหรับการกำหนด gate ตั้งแต่ต้น

Accuracy ดีขึ้นแล้วทำต่อได้หรือไม่?

ยังไม่พอ ต้องตรวจ business KPI, critical class, permission, human override, latency, integration, operating burden, residual risk อ่าน การจัดการคุณภาพ AI และ acceptance test ในไทย

หน้างานไม่ใช้ AI แปลว่าขาด training หรือไม่?

ไม่เสมอ อาจช้า แก้ยาก responsibility ไม่ชัด ชนกับ SOP, override ไม่ได้ หรือใช้ login เป็น KPI ต้องดู log และ field observation อ่าน การสนับสนุนการใช้งาน AI อย่างต่อเนื่องในไทย

แก้ระบบได้ใน 30 วันหรือไม่?

30 วันในบทความคือ diagnostic timebox ไม่ใช่ repair guarantee อาจทดสอบ limited fix แต่ output หลักคือ evidence ของ cause, reevaluation, option, stop rule, contract impact

การหยุดทำให้เงินลงทุนสูญเปล่าหรือไม่?

การหยุดอาจป้องกัน loss/risk เพิ่ม และรักษา data, evaluation method, interface, lesson สำหรับอนาคต ให้ตัดสินจาก future benefit/risk ไม่ใช่ sunk cost

สรุป: คืนความสามารถในการตัดสินใจก่อนซ่อม

เมื่อ AI ล้มเหลว ให้รักษา version, data, log, contract ก่อน tune เพิ่ม แยก symptom จาก cause ใน recovery sprint 30 วัน ประเมิน baseline, test/holdout, business KPI, drift, human override, IT/OT, reproducibility, stop rule แล้วเทียบ ทำต่อ ลดขอบเขต ออกแบบใหม่ หยุด ใน decision memo เดียว

หากโครงการ AI ของหน่วยงานในประเทศไทยหยุดและต้องแยกปัญหา model ออกจาก workflow และ IT/OT สามารถ ปรึกษา TOMAS TECH ได้ เราช่วยตั้งแต่ diagnostic phase โดยไม่ถือว่าการทำต่อเป็นคำตอบเดียว

แหล่งข้อมูลปฐมภูมิที่ตรวจสอบเมื่อ 2 กันยายน 2026

• NIST AIRC, AI RMF Core
• NIST, AI Resource Center
• NIST AIRC, AI Metrology Center
• NIST, The TEVV-Athlon Framework for Evaluating AI Systems
• U.S. GAO, Artificial Intelligence: An Accountability Framework for Federal Agencies and Other Entities
• ISO, ISO/IEC 42001:2023 AI management systems
• ETDA, Generative AI Governance Guideline for Organizations
• ETDA, Thailand Personal Data Protection Act resources