Đưa AI agent vào production: Thiết kế cách dừng, bàn giao và chạy lại

Sáng thứ Hai, một AI agent xử lý các yêu cầu cuối tuần và màn hình hiện “120 hoàn tất, 7 lỗi”. Nhưng không ai biết email nào đã gửi, thông tin khách hàng nào đã sửa hay phải bắt đầu làm lại từ đâu. Trong một tình huống như vậy, thiếu sót trong thiết kế vận hành sẽ lộ ra trước cả độ chính xác của mô hình.

Câu hỏi đầu tiên khi đưa vào production không phải “có thể tự động hóa đến đâu”, mà là “dừng ở điều kiện nào, chuyển cho ai những gì, và tiếp tục từ đâu mà không bị trùng lặp”. Quan điểm của bài viết rất rõ: cần thiết kế trước đơn vị nhỏ nhất để khôi phục nghiệp vụ sau khi AI agent thất bại, thay vì bắt đầu từ độ rộng năng lực của nó.

Mở rộng sử dụng cũng mở rộng phạm vi ảnh hưởng khi có lỗi

Panasonic Connect cho biết đã triển khai ConnectAI cho khoảng 11.800 nhân viên tại Nhật Bản và công bố mức tiết kiệm trong năm tài khóa 2025 là 788.000 giờ, tương đương 3,4% tổng thời gian lao động. Đây là con số do công ty tự tính, chưa được xác minh độc lập. Từ năm tài khóa 2026, công ty cũng đặt mục tiêu mở rộng AI agent liên kết dữ liệu nghiệp vụ với dữ liệu có cấu trúc trong SFA và ERP. [1]

Cơ quan Kỹ thuật số Nhật Bản cũng tự phát triển môi trường AI tạo sinh “Gennai” cho toàn bộ nhân viên từ tháng 5 năm 2025, cung cấp tìm kiếm trả lời chất vấn quốc hội và hỗ trợ nghiên cứu chế độ pháp luật, đồng thời nêu định hướng tiếp tục vận hành và mở rộng cho chính phủ. [2] Đây là ví dụ cho thấy việc dùng AI tạo sinh đang đi từ soạn văn bản sang tham chiếu dữ liệu nội bộ và hỗ trợ quyết định nghiệp vụ. Tuy nhiên, việc có ví dụ không chứng minh tự động thực thi là phù hợp với mọi nghiệp vụ.

Không thể đánh giá vận hành production chỉ bằng độ chính xác

Hướng dẫn mua sắm và sử dụng AI tạo sinh của Cơ quan Kỹ thuật số đưa vào hạng mục cần kiểm tra việc cung cấp thông tin về tình trạng hoạt động, nguyên nhân và cách xử lý lỗi, nội dung cập nhật, phạm vi sử dụng dự kiến; đồng thời kiểm chứng chức năng quản trị, giám sát vận hành, thể chế/quy trình xử lý sự cố và diễn tập trước. [3] Bộ Nội vụ và Truyền thông cùng Bộ Kinh tế, Thương mại và Công nghiệp đã cập nhật “Hướng dẫn dành cho doanh nghiệp AI” lên phiên bản 1.2 ngày 2026-03-31. [4]

Khung quản lý rủi ro AI của NIST cũng đưa trách nhiệm dừng hoặc vô hiệu hóa AI tạo kết quả khác với mục đích dự kiến, thao tác ghi đè của người dùng, ứng phó sự cố, khôi phục và quản lý thay đổi vào các hạng mục quản lý sau triển khai. [5] Điểm chung là không coi việc vượt qua đánh giá độ chính xác là hoàn tất.

Độ chính xác đo “thường khớp đến đâu”. Nhưng trong production, tổn thất phụ thuộc vào lỗi lan tới bao nhiêu nơi, có thể hủy hay không và người phụ trách có tái dựng được sự việc không. Vì vậy, đơn vị đánh giá cần mở rộng từ một câu trả lời sang một giao dịch nghiệp vụ gồm cả đầu vào và cập nhật hệ thống bên ngoài.

Ba thiết kế cần chốt trước

1. Tách điều kiện dừng khỏi “độ tự tin” của mô hình

Nếu chỉ dựa vào độ tin cậy do mô hình đưa ra để quyết định dừng, hệ thống có thể hiểu sai mức độ quan trọng đối với nghiệp vụ. Chi phí khắc phục lỗi khác nhau giữa đọc dữ liệu, tạo bản nháp, cập nhật nội bộ, gửi ra ngoài và thao tác liên quan tiền bạc/hợp đồng. Hãy đặt giới hạn số lượng, số tiền, đối tượng được phép, số lần lỗi liên tiếp, thời gian xử lý và điều kiện thiếu đầu vào cho từng thao tác. Khi chạm điều kiện, hãy dừng xử lý thay vì yêu cầu mô hình suy nghĩ lại.

Hướng dẫn xây dựng agent của OpenAI cũng nêu vượt quá giới hạn số lượt thử và thao tác rủi ro cao khó hoàn tác là các tình huống chính cần chuyển cho con người. [6] Đây là hướng dẫn thiết kế của nhà cung cấp, không đảm bảo thành công cho một sản phẩm cụ thể. Trong thực tế, hãy thay thế bằng ngưỡng tổn thất và trách nhiệm phê duyệt của doanh nghiệp.

2. Chuyển cho người không chỉ bằng một thông báo lỗi

Chỉ báo cho người phụ trách “đã thất bại” sẽ khiến quá trình điều tra phải bắt đầu lại từ đầu. Khi chuyển giao, hãy gửi thành một gói gồm ID yêu cầu, công đoạn đã hoàn tất, công đoạn chưa chạy, căn cứ đã tham chiếu, thay đổi đã thực hiện trong hệ thống ngoài, lý do dừng và thao tác tiếp theo được đề xuất. Điều quan trọng là lưu dưới dạng có thể tìm trong hồ sơ nghiệp vụ, không chỉ trong lịch sử hội thoại trên màn hình.

Ví dụ, nếu quy trình gồm tạo nháp báo giá rồi gửi yêu cầu phê duyệt, “không tạo được báo giá” là chưa đủ. Nếu biết việc tham chiếu bảng giá đã thành công nhưng agent dừng vì không xác định được người phê duyệt chiết khấu riêng cho khách hàng, người phụ trách có thể quyết định riêng phần còn lại. Chất lượng bàn giao ảnh hưởng cả thời gian khôi phục lẫn sự rõ ràng về phân định trách nhiệm.

3. Chạy lại theo công đoạn và ghi sổ các tác động phụ

Chạy lại toàn bộ quy trình từ đầu dễ triển khai nhưng có thể gửi email trùng hoặc cập nhật bản ghi hai lần. Yêu cầu con người hủy mọi thứ mỗi lần có ngoại lệ giúp xử lý linh hoạt nhưng khối lượng vận hành tăng theo số vụ. Khuyến nghị là cấp ID duy nhất và trạng thái hoàn tất cho từng công đoạn, ghi thay đổi ra bên ngoài vào “sổ tác động phụ”, rồi chỉ tiếp tục các công đoạn chưa hoàn thành.

Cách này đòi hỏi chi phí thiết kế ban đầu và vùng lưu trữ. Không cần áp dụng cho mọi prototype; nên ưu tiên nghiệp vụ lặp lại có gửi ra ngoài hoặc cập nhật hệ thống. Với kiểm chứng ngắn hạn chỉ đọc dữ liệu, lưu đầu ra và kiểm tra thủ công có thể đã đủ.

Trong FDE, mở rộng từng bước bắt đầu từ cách khôi phục nghiệp vụ

Theo Forward Deployed Engineering (FDE), không chia kế hoạch, prototype, PoC, triển khai và ổn định thành các lần bàn giao rời rạc. Bộ phận sử dụng và phát triển cùng xem các ghi chép lỗi, rồi mở rộng tự động hóa theo trình tự sau.

Thứ nhất, cùng người phụ trách nghiệp vụ viết điều kiện hoàn thành thành một câu và liệt kê tác động phụ ra bên ngoài. Thứ hai, chạy song song ở chế độ shadow, đọc dữ liệu thật nhưng không cập nhật, thu thập lý do dừng và thông tin bàn giao. Thứ ba, chủ động tạo mất kết nối, đầu vào thiếu, API hết thời gian chờ và người phê duyệt vắng mặt để thử chạy lại và khôi phục thủ công. Thứ tư, chỉ cho phép cập nhật trong phạm vi số vụ và người dùng giới hạn. Cuối cùng, xem thời gian điều tra mỗi lỗi, số xử lý trùng và tỷ lệ hoàn tất sau bàn giao thủ công để mở rộng.

Tăng số điểm phê duyệt không nhất thiết làm hệ thống an toàn hơn. Khi phê duyệt diễn ra thường xuyên, người phụ trách có thể duyệt mà không đọc nội dung và công việc bị tồn. Điều kiện dừng không nên là “không chắc thì chuyển tất cả”, mà cần tập trung vào thao tác tổn thất lớn, khó hoàn tác hoặc thiếu căn cứ.

Cách tiếp cận nhiều agent tự thực thi không phù hợp nếu số lượng xử lý nhỏ, người phụ trách có thể kiểm tra mọi vụ nhanh và hệ thống nghiệp vụ không lưu được ID xử lý duy nhất. Khi đó hợp lý hơn là giới hạn AI ở soạn nháp và nêu căn cứ, còn thao tác xác nhận cuối cùng để con người thực hiện.

Gợi ý cho thực tiễn

Đề xuất 1: Phê duyệt điều kiện dừng trước. Trước khi quyết định mô hình, prompt hay giao diện, người chịu trách nhiệm nghiệp vụ đặt giới hạn số vụ, số tiền, đối tượng, số lỗi liên tiếp và thời gian chờ.

Đề xuất 2: Đưa thử nghiệm khôi phục vào tiêu chí đạt của PoC. Ngoài tỷ lệ thành công bình thường, cần trình diễn được dừng giữa chừng, bàn giao cho người và tiếp tục từ công đoạn chưa xong.

Đề xuất 3: Theo dõi khả năng khôi phục, không chỉ tỷ lệ tự động hóa. Tối thiểu ghi số thao tác trùng, thời gian khôi phục và số vụ phải điều tra lại thủ công. Chỉ mở rộng phạm vi khi cả ba nằm trong giới hạn chấp nhận được.

Đưa AI agent vào production không phải kế hoạch loại bỏ mọi thất bại. Đó là kế hoạch để khi lỗi xảy ra vẫn giới hạn được ảnh hưởng, giải thích được diễn tiến và tiếp tục nghiệp vụ từ điểm đúng. Chỉ sau khi xác định cách dừng mới có thể tăng tốc tự động hóa.

Tài liệu tham khảo

1. Panasonic Connect “Tiết kiệm 3,4% tổng thời gian lao động nhờ ứng dụng AI” (2026-07-29)
2. Cơ quan Kỹ thuật số Nhật Bản “Government AI ‘Gennai’” (ngày kiểm tra: 2026-09-21)
3. Cơ quan Kỹ thuật số Nhật Bản “Hướng dẫn về mua sắm và sử dụng AI tạo sinh nhằm thúc đẩy sự phát triển và đổi mới trong hành chính” (bản đăng ngày 2025-09-18)
4. Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản “Hướng dẫn dành cho doanh nghiệp AI (Phiên bản 1.2)” (2026-03-31)
5. NIST “AI Risk Management Framework Core” (AI RMF 1.0, ngày kiểm tra: 2026-09-21)
6. OpenAI “A practical guide to building agents” (không rõ ngày, ngày kiểm tra: 2026-09-21)

Bài viết này được thực hiện với sự hỗ trợ của AI và đã được rà soát tự động trước khi xuất bản. Ngày kiểm tra thông tin: 2026-09-21.