Phục hồi triển khai AI thất bại: Chẩn đoán 30 ngày tại Thái Lan

Khi một triển khai AI bắt đầu thất bại, vội phát triển thêm có thể làm tình hình xấu hơn. PoC tốt nhưng accuracy giảm với dữ liệu production; nhà máy không dùng; tích hợp ERP hoặc máy bị kẹt; vendor chỉ đề nghị tuning thêm. Lúc này doanh nghiệp không cần một roadmap triển khai AI chung. Cần một chẩn đoán recovery 30 ngày để tách triệu chứng khỏi nguyên nhân và dùng bằng chứng chọn một trong bốn hướng: tiếp tục, thu hẹp, thiết kế lại, hoặc dừng.

Bài viết dành cho dự án AI tại cơ sở hoạt động ở Thái Lan đã đình trệ hoặc không đạt kỳ vọng. Chúng tôi không dùng thống kê tỷ lệ thất bại thiếu căn cứ, chi phí hư cấu hay thành tích giả định. Nội dung giải thích cách đánh giá lại baseline, test set, holdout, KPI nghiệp vụ, metric mô hình, data drift, human override, IT/OT, log, stop rule, hợp đồng và tài liệu exit, rồi đưa vào decision memo có thể phê duyệt.

Không để “triển khai AI thất bại” chỉ là mô tả triệu chứng

“Accuracy kém”, “chậm” và “nhà máy không dùng” là triệu chứng, không phải root cause. Accuracy giảm có thể do distribution đầu vào, label sai, định nghĩa nghiệp vụ đổi, preprocessing khác, permission, model version, threshold, UI hoặc đào tạo. Nếu chỉ yêu cầu vendor “cải thiện accuracy”, vòng tuning có thể kéo dài trong khi lỗi workflow và dữ liệu còn nguyên.

Trong buổi chẩn đoán đầu tiên, chuyển ý kiến thành quan sát.

Không bắt đầu bằng quy trách nhiệm. Hãy hỏi giả thuyết nào có thể bị bác bỏ bằng bằng chứng nào. Trách nhiệm có thể đối chiếu hợp đồng sau; log và configuration bị ghi đè có thể không thể khôi phục.

Bảo toàn bằng chứng trước chẩn đoán 30 ngày

Không retrain hay thay đổi hàng loạt trong ngày đầu. Trạng thái hiện tại có thể là comparator duy nhất. Công bố diagnostic freeze: trừ biện pháp an toàn khẩn cấp, không đổi model, prompt, threshold, preprocessing, retrieval index hoặc data connection khi chưa duyệt.

Bảo toàn gì trong 48 giờ đầu

• Version production và PoC của model, prompt, rule, library, container.
• ID, điều kiện extract, hash, ngày tạo của training, validation, test, holdout.
• Log input, output, confidence, citation, error, latency, human override.
• Interface và change history của ERP, MES, SCADA, data lake, API gateway.
• Requirement, acceptance criteria, PoC report, biên bản, change request, incident, vendor report.
• Agreement, SOW, data term, SLA, IP, transition support và subprocessor.

Tránh tạo bản sao chẩn đoán không kiểm soát, đặc biệt khi có dữ liệu cá nhân hoặc bí mật kinh doanh. Dùng tài liệu PDPA chính thức ETDA công bố làm điểm xuất phát và review purpose, access, retention, processing role với pháp lý hoặc DPO. Đây không phải tư vấn pháp lý.

Tổng quan recovery sprint 30 ngày

Ba mươi ngày không phải cam kết sửa mọi thứ. Đó là timebox để thu đủ bằng chứng, tránh thêm một quyết định đầu tư mơ hồ.

Ngày 1–5: bảo toàn sự kiện và lập symptom map

Freeze hợp đồng, requirement, version, data và log. Phân loại triệu chứng thành business, model, data, integration, operation, governance. Có đại diện management, business, user, IT, security, legal, vendor. Tạo một timeline: mục tiêu ban đầu, thay đổi gì, khi nào, ai duyệt.

Deliverable là evidence inventory, symptom map, change timeline và danh sách bằng chứng thiếu. Chưa chọn solution.

Ngày 6–12: dựng lại baseline và evaluation design

Nếu tiêu chí cũ mơ hồ, đo lại baseline công việc hiện tại. Kiểm tra tách test/holdout, chất lượng label, population, thời gian và segment theo sản phẩm, ngôn ngữ, site, ca. Xác định dữ liệu PoC có đại diện production không.

Deliverable là metric dictionary, data lineage, evaluation script tái lập, version được đánh giá và limitation.

Ngày 13–20: kiểm thử causal hypothesis bằng experiment giới hạn

Với từng hypothesis, chỉ đổi yếu tố nhỏ nhất. Đổi model, prompt, data, threshold cùng lúc che mất nhân quả. Ưu tiên so sánh cùng model với preprocessor cũ, cùng test set chỉ đổi model version, hoặc business outcome trước/sau human override.

Ghi hypothesis, experiment, result, uncertainty và reproduction condition.

Ngày 21–26: đánh giá khả năng phục hồi operation, integration, contract

Mô hình có thể sửa nhưng không lên production nếu data right, API, OT safety, operation hoặc vendor dependency không thể phục hồi. Đánh giá riêng owner, monitoring, incident, cost driver và khả năng chuyển giao code, setting, evidence.

Ngày 27–30: phê duyệt decision memo bốn lựa chọn

So sánh tiếp tục, thu hẹp, thiết kế lại, dừng cùng định dạng: benefit, residual risk, resource, experiment tiếp, stop rule, contract impact. Ngày cuối phải có decision, owner, deadline và evidence gate, không phải “tiếp tục xem xét”.

Dựng lại baseline

Một lỗi phổ biến là không có comparator hợp lệ. Nếu volume, product mix, shift, kỹ năng hoặc demand đổi giữa trước và sau AI, before/after trực tiếp sẽ sai. Baseline là phép đo quy trình hiện tại hoặc phương án thay thế dưới điều kiện tương đương, không phải số lý tưởng “không AI”.

Ba lớp baseline

1. Business baseline: handling time, rework, first resolution, defect escape, downtime.
2. Method baseline: rule, search, statistical model hoặc human decision dùng để so AI.
3. Risk baseline: mức nghiêm trọng của error, privacy exposure, unapproved action, recovery time.

Điểm model có thể tăng nhưng thời gian công việc tăng vì review. Ngược lại, cải thiện trung bình nhỏ vẫn có giá trị nếu critical case được chuyển cho người đúng. Đặt business và model trong cùng bảng.

Kiểm tra nhiễm test set và holdout

Khi PoC tốt nhưng production kém, điều tra evaluation data có đi vào development không. Nếu liên tục chỉnh prompt/threshold khi nhìn test result, test set trở thành development data. Khôi phục vai trò rõ:

• Training/development: huấn luyện, cải thiện prompt/logic.
• Validation: chọn approach, threshold, hyperparameter.
• Test: đánh giá approach đã chọn, không tối ưu lặp.
• Holdout: không chạm đến final decision gate.
• Production shadow: quan sát distribution production nhưng không tự động action.

Dữ liệu ít vẫn cần kỷ luật. Random split có thể sai khi cùng machine, document family, customer, lot hoặc thời gian gần nhau ở hai phía. Split theo đơn vị có ý nghĩa và ghi duplicate, derivative, labeler, version.

MEASURE trong NIST AI RMF Core đề cập việc ghi test set, metric, TEVV tool, đo trong điều kiện gần deployment và production monitoring. Core không phải checklist hoặc thứ tự bắt buộc. GOVERN, MAP, MEASURE, MANAGE được dùng lặp theo context. Chẩn đoán phải làm phương pháp đo tái lập được, không chỉ báo score.

Đánh giá KPI nghiệp vụ tách khỏi metric mô hình

Metric mô hình cần thiết nhưng không đủ để quyết định tiếp tục. Map từng metric với business outcome.

Phân đoạn theo product, equipment, language, user, shift, risk class thay vì chỉ dùng average. Kiểm tra critical minority class và selection bias giữa nhóm dùng/không dùng AI.

Tách data drift khỏi context drift

Data drift là input distribution đổi nhưng không phải nguồn duy nhất. Có concept drift khi quan hệ input-label đổi, context drift khi purpose/workflow đổi, pipeline drift do ETL/API và hành vi người dùng đổi.

Bảng chẩn đoán drift

Không “phát hiện drift là retrain”. Nếu lỗi ở label policy hoặc ETL, retraining sẽ nhúng lỗi. Định nghĩa detection, impact review, approval, reevaluation, release.

NIST AI Metrology Center kết nối metric, method, tool với AI RMF và lifecycle nhưng nêu rõ inclusion không phải NIST endorsement, validation hay suitability. Nhóm phải chứng minh metric phù hợp use case của mình.

Xác minh human override có thực sự hoạt động

Specification có thể nói “người quyết định cuối” nhưng operator không thể override có ý nghĩa. AI recommendation có thể là default; reject cần giải trình thêm; thời gian quá ngắn; thiếu permission; hoặc bất đồng ảnh hưởng KPI. Đây chỉ là human-in-the-loop hình thức.

Không đánh giá override rate đơn giản cao/thấp. Xem tình huống, lý do, kết quả, thời gian, AI confidence, user role. Override đúng hiếm khác với override cần thiết nhưng bất khả thi. Test stop authority, restart approval, manual procedure, appeal và log.

Chẩn đoán integration và IT/OT tách khỏi mô hình

Trong nhà máy Thái, model bình thường có thể hỏng tại ERP, MES, SCADA, PLC, camera, network hoặc time synchronization. Trước retrain, trace record end-to-end từ input đến business action.

Kiểm tra system of record, acquisition time, unit, missing, retry, order, ID mapping, permission, timeout, buffer, manual mode. Với vision, xác minh camera, lighting, lens, trigger, compression. Với sensor, kiểm tra calibration và lịch sử thay. Nếu AI ảnh hưởng OT control, test quay về read-only, fail-safe tại thiết bị và change có cần quality/customer approval không.

Chẩn đoán phải có equipment, control, quality, production, maintenance, cybersecurity, không chỉ AI team. Nếu ownership dừng tại model API, chỉ định owner cho end-to-end KPI.

Dùng log và reproducibility để xem lại AI vendor

Xem lại vendor không đồng nghĩa quan hệ phải kết thúc. Đây là kiểm tra reproducibility và transferability như deliverable hợp đồng. Với sample chẩn đoán, buyer hoặc independent team phải thử reproduce với cùng version, input, configuration.

Reproduction package tối thiểu

• Architecture/data flow và version matrix của model, prompt, rule, index.
• Runtime, dependency, configuration, cách tham chiếu secret.
• Cách tạo 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.

Không chấp nhận “proprietary” là lý do toàn bộ cho việc không reproduce. Dù không mở IP, vẫn có thể thống nhất input condition, output, interface, performance evidence, monitoring, exit export. Ghi black-box scope và ranh giới buyer có thể kiểm chứng vào hợp đồng.

Viết stop rule trước khi sửa tiếp

Recovery kéo dài khi “chỉnh thêm có thể tốt” không có deadline. Approve stop rule trước sprint.

Ví dụ: không đạt minimum critical safety class trên holdout; tái diễn lộ dữ liệu ngoài quyền; không xác lập data right đúng hạn; không chạy manual fallback trong thời gian cho phép; không tạo required log; improvement thấp hơn minimum effect đã duyệt. Threshold phải theo risk tolerance dự án, không sao chép giá trị chung.

Dừng không nhất thiết bỏ toàn bộ. Có thể dừng autonomous action nhưng giữ decision support, giới hạn sản phẩm, bỏ sensitive data hoặc tiếp tục một ngôn ngữ. Chuẩn bị scope-reduction cạnh mỗi stop rule.

Bốn lựa chọn: tiếp tục, thu hẹp, thiết kế lại, dừng

Tiếp tục

Chỉ chọn khi xác định nguyên nhân, improvement lặp lại trong limited experiment và residual risk chấp nhận được. Gắn ngày review, monitoring owner, change approval, stop rule. Tiếp tục do quán tính không phải decision.

Thu hẹp

Chọn khi có value ở một số segment nhưng không phải mọi site, product, language, user. Định nghĩa scope, permission, manual work và KPI mới. Đây không phải quay về PoC vô hạn mà là production hẹp có value đã chứng minh.

Thiết kế lại

Chọn khi objective vẫn hợp lệ nhưng architecture, data pipeline, human workflow hoặc evaluation design sai căn bản. Tách asset reuse/discard và approve như project riêng. Không đổi nhãn dự án cũ thành thành công để chuyển ngân sách.

Dừng

Dừng khi không có value theo objective, critical risk không kiểm soát, data/right không có hoặc non-AI alternative hợp lý hơn. Bao gồm user notice, manual process, data return/deletion, access revoke, settlement, asset retention, lessons learned.

MANAGE của NIST AI RMF Core gồm quyết định hệ thống có đạt purpose và development/deployment nên tiếp tục không, cùng cơ chế supersede, disengage, deactivate hệ thống không nhất quán intended use. Dừng là lựa chọn risk management bình thường.

Template decision memo

Output ngày 30 là memo ngắn có thể phê duyệt, bằng chứng đặt ở appendix:

1. Objective ban đầu và triệu chứng: scope, user, expectation, observation.
2. Nguyên nhân và confidence: confirmed, probable, unresolved.
3. Reevaluation: baseline, holdout, segment, business KPI, risk, integration.
4. So sánh bốn hướng: benefit, residual risk, resource, time, contract impact.
5. Recommendation: một lựa chọn và lý do.
6. Condition/stop rule: gate, owner, evidence, deadline.
7. Dissent: phản đối chưa giải quyết và lý do vẫn quyết định.

U.S. GAO AI Accountability Framework tổ chức accountability quanh governance, data, performance, monitoring. Dù ban đầu dành cho federal agencies và entities khác, nó cung cấp câu hỏi hữu ích để phân rã hệ thống AI hiện hữu thành bằng chứng audit. Đây không phải yêu cầu pháp luật Thái Lan hay chỉ thị trực tiếp cho doanh nghiệp.

Chẩn đoán hợp đồng và tài liệu exit

Hợp đồng có thể hạn chế recovery hơn công nghệ. Nếu quyền model/code, data export, log access, third-party service, minimum commitment, transition support không rõ, không thể so redesign và vendor transition.

Review master agreement, SOW, change order, DPA, SLA, license, acceptance record, invoice basis, subprocessor, termination term. Nếu hợp đồng và thực tế khác, ghi sự kiện và chuyển pháp lý.

Kiểm tra exit readiness

• Có nhận data, label, prompt, configuration, log, evaluation result dạng machine-readable không?
• Có tách asset của customer, vendor, third party không?
• Có revoke credential/connection và bằng chứng xóa cả backup không?
• Successor có nhận interface, schema, runbook, known limitation không?
• Có thời gian parallel transition và shutdown point an toàn không?

ISO/IEC 42001:2023 quy định yêu cầu thiết lập, triển khai, duy trì, cải tiến liên tục AI management system. Không quyết recovery chỉ từ certification. Kiểm tra accountability, risk assessment, change, monitoring, corrective action và continual improvement có hồ sơ cho hệ thống này không.

Cách sử dụng tài liệu TEVV năm 2026

Ngày 7/8/2026, NIST mở lấy ý kiến tới 6/10/2026 cho initial public draft NIST AI 200-2, TEVV-Athlon Framework đánh giá AI system. Đây chưa phải tiêu chuẩn hoàn tất. Dùng như tài liệu đang phát triển về test, evaluation, verification, validation cho nhiều AI use case, không dùng như certification hay conformity bắt buộc trong hợp đồng.

Draft giới thiệu assessment tùy biến theo TEVV objective của tổ chức. Với recovery, điều này hỗ trợ thiết kế evidence theo operational goal thay vì thu hệ thống thành một score. Memo phải nêu terminology và structure có thể đổi.

ETDA Generative AI Governance Guideline cũng hữu ích để xem benefit, limitation, risk, application mode, governance theo bối cảnh tổ chức. Phân biệt guideline với luật Thái và nghĩa vụ hợp đồng.

FAQ về triển khai AI thất bại

Phục hồi dự án AI có nghĩa là thay vendor không?

Không. Nếu requirement, data, internal operation là nguyên nhân, đổi vendor có thể lặp lỗi. Trước hết test evidence/reproducibility, rồi so correction với vendor hiện tại, thu hẹp, redesign và transition trên cùng điều kiện.

Đánh giá lại AI PoC có dùng test set cũ được không?

Nếu test set đã được nhìn lặp trong tuning, có thể không independent. Kiểm tra usage history và tạo untouched holdout nếu có thể. Với dữ liệu ít, split theo time, equipment, customer hoặc blind review. Xem chi phí và tiêu chí thành công AI PoC tại Thái Lan để đặt gate từ đầu.

Accuracy cải thiện có đủ để tiếp tục không?

Không. Cần kiểm tra business KPI, critical class, permission, human override, latency, integration, operating burden, residual risk. Xem quản lý chất lượng AI và acceptance test tại Thái Lan.

Nhà máy không dùng AI có phải do thiếu đào tạo?

Không nhất thiết. Output chậm, sửa khó, trách nhiệm mơ hồ, xung đột SOP, override không thật hoặc KPI chỉ đếm login có thể là lỗi thiết kế. Dùng log và quan sát hiện trường. Xem hỗ trợ duy trì ứng dụng AI tại Thái Lan.

Có thể sửa hệ thống trong 30 ngày không?

Ba mươi ngày ở đây là diagnostic timebox, không phải repair guarantee. Có thể test limited fix, nhưng output chính là evidence về cause, reevaluation, option, stop rule, contract impact.

Dừng có làm lãng phí đầu tư không?

Dừng có thể tránh loss/risk thêm và giữ data, evaluation method, interface, lesson cho tương lai. Quyết định theo future benefit/risk, không theo sunk cost.

Kết luận: khôi phục khả năng quyết định trước khi sửa

Khi AI thất bại, hãy bảo toàn version, data, log, contract trước tuning. Tách symptom khỏi cause. Trong recovery sprint 30 ngày, đánh giá baseline, test/holdout, business KPI, drift, human override, IT/OT, reproducibility, stop rule, rồi so tiếp tục, thu hẹp, thiết kế lại, dừng trong cùng decision memo.

Nếu dự án AI tại cơ sở hoạt động ở Thái Lan đình trệ và cần tách lỗi model khỏi workflow và IT/OT, hãy liên hệ TOMAS TECH. Chúng tôi có thể hỗ trợ diagnostic phase mà không mặc định tiếp tục là đáp án duy nhất.

Nguồn sơ cấp kiểm tra ngày 2/9/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