Checklist nghiệm thu AI Agent: 12 tình huống doanh nghiệp nên kiểm tra trước khi vận hành

Buổi trình diễn của đơn vị triển khai thường chạy những tình huống thuận lợi. Nghiệm thu thì khác: doanh nghiệp cần biết AI Agent xử lý thế nào khi câu hỏi lạ, khi người dùng không đủ quyền, khi API lỗi hay khi yêu cầu vượt hạn mức.

Một buổi nghiệm thu có giá trị cần tiêu chí đạt được chốt trước, dữ liệu thử không ảnh hưởng hệ thống thật và biên bản ghi rõ lỗi nào phải sửa trước khi vận hành. Ngoài chức năng, cần kiểm tra cả nhật ký, báo cáo, giới hạn sử dụng và tài liệu bàn giao.

Bài viết đưa ra 12 tình huống nên có trong checklist nghiệm thu và cách tổ chức buổi UAT.

1. Cách nhìn đúng về nghiệm thu AI Agent

Nghiệm thu cần đi qua cả ba lớp của Agent. Lớp dữ liệu: Agent có dùng đúng nguồn, đúng phiên bản không. Lớp suy luận: Agent có hiểu yêu cầu và chọn đúng công cụ không. Lớp kiểm soát: quyền, hạn mức, chuyển người và nhật ký có hoạt động như thiết kế không. Checklist chỉ soát câu trả lời mà bỏ qua lớp kiểm soát sẽ để lọt những lỗi nghiêm trọng nhất.

Biên bản nghiệm thu nên ghi những gì đã được kiểm chứng, không ghi những gì hệ thống “có thể làm”. Tính năng chưa có dữ liệu thật, chưa kết nối xong hoặc chưa có người chịu trách nhiệm vận hành nên được ghi là ngoài phạm vi đợt nghiệm thu. Cách ghi này tránh hiểu lầm về cam kết giữa hai bên. Xem thêm quy trình triển khai AI Agent.

2. Các vấn đề cần xử lý

1. Tình huống chuẩn

Bắt đầu bằng những yêu cầu phổ biến nhất trong phạm vi đã thống nhất. Agent phải hoàn thành đúng, đủ và dựa đúng nguồn. Nếu tình huống chuẩn chưa đạt ổn định thì chưa nên chuyển sang các tình huống khó.

2. Cách diễn đạt khác

Người dùng thật viết tắt, gõ không dấu, hỏi vòng vo. Mỗi tình huống chuẩn nên có vài cách diễn đạt khác, tốt nhất do chính người dùng thực tế soạn. Kết quả phải nhất quán giữa các cách hỏi.

3. Câu hỏi ngoài dữ liệu

Hỏi những điều không có trong nguồn để xem Agent có thừa nhận chưa có thông tin và hướng người dùng sang kênh phù hợp không. Một câu trả lời đoán, dù nghe hợp lý, vẫn là lỗi cần sửa.

4. Quyền truy cập

Dùng tài khoản với các vai trò khác nhau để hỏi dữ liệu ngoài quyền của mình. Agent phải từ chối, không tiết lộ một phần và ghi nhận lần truy cập bị chặn. Việc kiểm tra quyền phải diễn ra ở hệ thống, không chỉ dựa vào lời dặn trong prompt.

5. API chậm hoặc lỗi

Nhờ đội kỹ thuật giả lập API chậm, lỗi hoặc trả dữ liệu rỗng. Agent cần báo chưa xác nhận được, không bịa kết quả và không để thao tác dở dang. Ghi lại thời gian người dùng phải chờ trước khi nhận phản hồi.

6. Thao tác lặp

Gửi cùng một yêu cầu hai lần, bấm nút liên tục hoặc ngắt mạng giữa chừng. Hệ thống chỉ được tạo một bản ghi. Lỗi này hay bị bỏ sót vì hiếm khi xuất hiện trong buổi trình diễn.

7. Yêu cầu vượt hạn mức

Tạo yêu cầu vượt hạn mức tiền, số lượng hoặc thẩm quyền đã cấu hình. Agent phải dừng và chuyển sang luồng phê duyệt, không tự thực hiện. Cần thử cả trường hợp nhiều yêu cầu nhỏ cộng lại vượt hạn mức.

8. Chuyển người thật

Kiểm tra Agent chuyển người khi được yêu cầu, khi câu hỏi ngoài phạm vi và khi gặp lỗi. Người nhận phải có đủ ngữ cảnh để xử lý tiếp. Thử cả khung giờ không có người trực để xem người dùng được thông báo thế nào.

9. Nhật ký và truy vết

Chọn ngẫu nhiên vài ca đã thử và dựng lại từ nhật ký: yêu cầu, nguồn đã dùng, hành động và kết quả. Nếu không dựng lại được, việc điều tra sự cố sau này sẽ rất khó. Kiểm tra luôn ai được quyền xem nhật ký.

10. Báo cáo vận hành

Người quản lý cần báo cáo để theo dõi Agent sau bàn giao: số yêu cầu, tỷ lệ chuyển người, lỗi tích hợp. Khi nghiệm thu, đối chiếu số trên báo cáo với số ca đã chạy trong buổi thử để chắc báo cáo đếm đúng.

11. Giới hạn sử dụng

Kiểm tra các giới hạn về số lượt, độ dài tin nhắn và tần suất gọi có hoạt động không. Giới hạn giúp kiểm soát chi phí và chặn lạm dụng. Người dùng chạm giới hạn cần nhận thông báo dễ hiểu, không phải một lỗi khó hiểu.

12. Tài liệu và trách nhiệm hỗ trợ

Bàn giao cần có tài liệu mô tả phạm vi, nguồn dữ liệu, quyền, cách cập nhật dữ liệu và cách xử lý sự cố thường gặp. Cần ghi rõ đầu mối hỗ trợ, kênh báo lỗi và cách phân mức ưu tiên. Thiếu phần này, doanh nghiệp khó tự vận hành sau khi dự án kết thúc.

3. Quy trình triển khai đề xuất

Bước 1: Chốt tiêu chí đạt trước buổi UAT

Hai bên thống nhất danh sách tình huống, kết quả mong đợi và cách phân loại lỗi trước khi thử. Đầu ra là tài liệu tiêu chí nghiệm thu được chủ sở hữu nghiệp vụ ký duyệt. Tiêu chí không được sửa trong lúc thử để hợp thức hóa kết quả.

Bước 2: Chuẩn bị dữ liệu thử không làm ảnh hưởng hệ thống thật

Dùng môi trường thử hoặc tài khoản thử để thao tác ghi không chạm vào đơn, khách hàng hay sổ sách thật. Dữ liệu thử cần đủ giống thực tế, gồm cả dữ liệu thiếu và sai định dạng. Đội kỹ thuật xác nhận môi trường đã sẵn sàng trước buổi UAT.

Bước 3: Ghi kết quả, bằng chứng và người chịu trách nhiệm sửa

Mỗi ca ghi đạt hay không đạt, kèm ảnh chụp màn hình hoặc trích nhật ký làm bằng chứng. Lỗi được phân mức: chặn vận hành, cần sửa trước khi mở rộng, hoặc lỗi trình bày. Mỗi lỗi có người nhận sửa và hạn xử lý.

Bước 4: Kiểm thử lại lỗi và các chức năng liên quan

Sau khi sửa, chạy lại ca bị lỗi và các luồng có thể bị ảnh hưởng. Lỗi chỉ được đóng khi người phát hiện xác nhận đạt. Biên bản cuối cùng liệt kê lỗi đã đóng và các rủi ro còn lại được chấp nhận.

4. Ví dụ giả định

Trong UAT, người dùng bấm gửi yêu cầu hai lần khi mạng chậm. Hệ thống phải nhận ra mã thao tác và chỉ tạo một bản ghi. Một thử nghiệm khác dùng tài khoản chi nhánh A để hỏi dữ liệu chi nhánh B; yêu cầu phải bị từ chối và được ghi nhật ký.

Hai tình huống này hiếm khi xuất hiện trong buổi trình diễn nhưng gây hậu quả thật khi vận hành: bản ghi trùng và lộ dữ liệu giữa chi nhánh. Chúng nên nằm cố định trong checklist, có đầu vào cụ thể, kết quả mong đợi và người xác nhận là chủ sở hữu dữ liệu của từng chi nhánh.

5. Rủi ro và giới hạn cần kiểm soát

• Không nghiệm thu chỉ bằng trình diễn của nhà cung cấp
• Tách lỗi nghiêm trọng khỏi lỗi trình bày
• Xác nhận môi trường và dữ liệu dùng để thử
• Làm rõ thời hạn sửa lỗi, bảo hành và đầu mối hỗ trợ

Nghiệm thu nên chạy trên chính cấu hình sẽ vận hành, với quyền và giới hạn đã bật. Dữ liệu cá nhân dùng khi thử cần được ẩn danh hoặc thay bằng dữ liệu giả. Nếu một lỗi được chấp nhận tạm thời, biên bản cần ghi rõ lý do, biện pháp giảm thiểu và hạn xử lý. Xem thêm bảo mật dữ liệu AI Agent.

6. Chỉ số nên theo dõi sau khi vận hành

• Tỷ lệ yêu cầu hoàn thành đúng theo bộ tiêu chí đã duyệt
• Tỷ lệ thiếu dữ liệu, từ chối đúng và chuyển người thật
• Số lỗi tích hợp, thời gian phản hồi và thời gian khắc phục
• Số lần nhân viên sửa kết quả và nguyên nhân sửa

Nghiệm thu đạt mới là điểm bắt đầu. Trong giai đoạn đầu vận hành, nên so chỉ số thực tế với kết quả UAT theo từng nhóm tình huống. Nhóm nào có tỷ lệ sửa hoặc chuyển người cao hơn lúc nghiệm thu là dấu hiệu bộ thử chưa đại diện và cần bổ sung.

7. Checklist trước khi đưa vào sử dụng

• Nguồn dữ liệu và chủ sở hữu đã được xác nhận
• Quyền đọc ghi và phạm vi người dùng đã được kiểm thử
• Ngoại lệ có đường chuyển người phụ trách
• Nhật ký lưu đủ đầu vào nguồn và kết quả
• Bộ câu hỏi hoặc tình huống kiểm thử có đáp án mong đợi
• Có lịch cập nhật dữ liệu và kiểm thử lại

8. Câu hỏi thường gặp

Ai nên tham gia nghiệm thu? Chủ sở hữu nghiệp vụ, người dùng thực tế, kỹ thuật và bộ phận kiểm soát liên quan.

Có cần kiểm thử lại sau khi sửa? Có. Kiểm thử lỗi đã sửa và các luồng có thể bị ảnh hưởng.

Khi nào được đưa vào vận hành? Khi lỗi chặn đã đóng, rủi ro còn lại được chấp nhận và có kế hoạch giám sát.

Kết luận

Nghiệm thu AI Agent cần nhiều hơn vài câu hỏi thử. Mười hai tình huống trên bao phủ chức năng, quyền, lỗi tích hợp, nhật ký và trách nhiệm hỗ trợ. Với Agent tư vấn trên website, có thể bổ sung các ca riêng trong bài AI tư vấn sản phẩm trên website.

Chỉ đưa vào vận hành khi lỗi chặn đã đóng, rủi ro còn lại được ghi nhận và có người theo dõi Agent sau bàn giao.

Trao đổi với Naventic để thống nhất tiêu chí nghiệm thu cho dự án AI Agent. Đọc thêm: Quy trình triển khai AI Agent.