Checklist chuẩn bị trước khi bắt đầu dự án AI Agent

Nhiều dự án AI Agent vướng ngay từ tuần đầu, không phải vì mô hình yếu mà vì những câu hỏi rất cơ bản chưa ai trả lời: bảng giá mới nhất nằm ở đâu, ai có quyền sửa, hệ thống bán hàng có API không, và khi agent trả lời sai thì ai chịu trách nhiệm. Khi các câu hỏi đó chỉ lộ ra lúc đội kỹ thuật bắt tay vào làm, dự án phải dừng lại chờ, phạm vi bị cắt hoặc chi phí tăng.

Checklist trong bài này dùng cho giai đoạn TRƯỚC khi khởi động: trước khi ký hợp đồng, trước khi chốt phạm vi, trước khi đội kỹ thuật được giao việc. Mục đích là giúp doanh nghiệp biết mình đã sẵn sàng tới đâu và còn thiếu gì, để quyết định bắt đầu ngay, bắt đầu với phạm vi nhỏ hơn hay xử lý điều kiện nền trước.

Phần nghiệm thu cuối dự án là một bộ câu hỏi khác, được trình bày ở bài checklist nghiệm thu AI Agent. Hai checklist nên dùng cùng nhau: điều gì được chốt ở đây sẽ trở thành căn cứ để nghiệm thu ở cuối.

1. Bản chất của checklist triển khai AI Agent

Một checklist chuẩn bị không phải danh sách việc kỹ thuật. Nó là công cụ để các bên trong doanh nghiệp cùng xác nhận những điều kiện mà agent cần để chạy được: nó phục vụ ai, lấy thông tin từ đâu, được phép làm gì, và ai theo dõi sau khi chạy. Mỗi dòng trong checklist nên trả lời được bằng “có”, “chưa” hoặc tên một người cụ thể, chứ không phải “đang tìm hiểu”.

Checklist cũng giúp xác định agent sẽ dừng ở mức nào. Nếu chỉ cần hỏi đáp dựa trên tài liệu, phần chuẩn bị chủ yếu là nội dung và người cập nhật. Nếu cần tra cứu dữ liệu thời gian thực như tồn kho hay trạng thái đơn, phải có thêm quyền đọc hệ thống và cách xử lý khi hệ thống chậm. Nếu agent được ghi vào CRM, tạo phiếu hay gửi thông tin ra ngoài, danh sách chuẩn bị dài hơn hẳn: người duyệt, cơ chế chống lặp, nhật ký. Chốt mức này sớm giúp tránh việc một dự án hỏi đáp nhỏ âm thầm biến thành dự án tích hợp lớn.

2. Các yếu tố cần thiết kế

1. Mục tiêu kinh doanh

Viết mục tiêu thành kết quả quan sát được, ví dụ “giảm số câu hỏi lặp mà nhân viên CSKH phải trả lời tay” thay vì “ứng dụng AI vào chăm sóc khách hàng”. Kèm theo là cách đo hiện tại: đang đếm bằng gì, số liệu nằm ở đâu. Nếu chưa đo được hiện trạng, sau dự án cũng không chứng minh được thay đổi.

2. Dữ liệu nguồn

Liệt kê từng nguồn agent sẽ dựa vào: tài liệu chính sách, bảng giá, danh mục sản phẩm, hệ thống đơn hàng. Với mỗi nguồn, ghi định dạng, tần suất cập nhật và bản nào là bản chính thức. Dấu hiệu cần xử lý trước là cùng một thông tin có hai ba bản khác nhau trên ổ chung. Cách làm sạch và sắp xếp các nguồn này có ở bài chuẩn bị dữ liệu cho AI Agent.

3. Quy trình hiện tại

Mô tả quy trình như đang làm thật, không phải như trong sổ tay. Ai nhận yêu cầu, tra ở đâu, khi nào phải hỏi cấp trên, ngoại lệ nào hay gặp. Những bước nhân viên xử lý “theo kinh nghiệm” là nơi agent dễ sai nhất, nên cần ghi riêng để quyết định giữ cho người làm hay viết thành quy tắc.

4. Người sở hữu

Mỗi quy trình và mỗi nguồn dữ liệu cần một người có tên, không phải một phòng ban. Người này quyết định câu trả lời thế nào là đúng, duyệt thay đổi nội dung và xử lý khi agent gặp tình huống lạ. Nếu một nguồn quan trọng không ai nhận, đó là lý do chính đáng để hoãn phần liên quan.

5. Tích hợp cần có

Ghi rõ từng hệ thống cần kết nối, agent cần đọc hay ghi, và hệ thống đó có API, có tài liệu, có môi trường thử hay không. Một hệ thống chỉ xuất được file Excel theo tuần thì không thể phục vụ câu hỏi về tồn kho theo thời gian thực. Biết sớm giới hạn này giúp điều chỉnh phạm vi thay vì hứa điều hệ thống không đáp ứng được. Chi tiết về các kiểu kết nối có ở bài tích hợp AI Agent với CRM, ERP và API.

6. Quyền truy cập

Xác định ai được dùng agent, mỗi nhóm người dùng được thấy thông tin gì, và tài khoản kỹ thuật của agent được cấp quyền nào trên từng hệ thống. Quyền phải được cấu hình ở hệ thống nguồn, không chỉ dặn trong prompt. Việc xin cấp quyền thường mất thời gian qua nhiều cấp duyệt, nên cần khởi động sớm.

7. Tiêu chí nghiệm thu

Viết sẵn danh sách tình huống mẫu kèm kết quả mong đợi ngay từ khi chuẩn bị: câu hỏi phổ biến, câu hỏi ngoài phạm vi, yêu cầu vượt quyền, dữ liệu thiếu. Người sở hữu nghiệp vụ duyệt danh sách này. Nhờ vậy, đến cuối dự án, hai bên nghiệm thu theo thứ đã thống nhất thay vì tranh luận thế nào là “chạy tốt”.

8. Kế hoạch vận hành

Trả lời trước ngày khởi động: sau khi chạy, ai đọc nhật ký, ai sửa nội dung khi chính sách đổi, ai được quyền tắt agent khi có sự cố, và chi phí vận hành hằng tháng lấy từ ngân sách nào. Dự án không có kế hoạch này thường chạy tốt vài tuần đầu rồi chất lượng giảm dần vì không ai cập nhật.

3. Quy trình triển khai thực tế

Bước 1: Xác định phạm vi và kết quả cần đo

Tổ chức một buổi làm việc với người sở hữu quy trình để chọn một luồng cụ thể, ghi mục tiêu và số liệu hiện trạng. Đầu ra là một trang mô tả phạm vi: agent làm gì, không làm gì, phục vụ ai. Người chịu trách nhiệm ngân sách ký xác nhận trang này.

Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập

Kiểm kê các nguồn đã liệt kê, chọn bản chính thức, loại bản cũ và gán người cập nhật cho từng nguồn. Song song, gửi yêu cầu cấp quyền cho tài khoản kỹ thuật của agent. Đầu ra là bảng nguồn dữ liệu có chủ sở hữu và danh sách quyền đã được bộ phận IT phê duyệt.

Bước 3: Thiết kế tích hợp ngoại lệ và phê duyệt

Với từng hệ thống cần kết nối, xác nhận cách truy cập và thử một lệnh đọc đơn giản trên môi trường thử. Viết danh sách ngoại lệ đã biết và quyết định mỗi ngoại lệ sẽ chuyển cho ai. Đầu ra là sơ đồ luồng có đánh dấu điểm cần người duyệt, được cả bên nghiệp vụ và bên kỹ thuật đồng ý.

Bước 4: Kiểm thử vận hành rồi cải thiện theo log

Trước khi chính thức khởi động, rà lại toàn bộ checklist cùng các bên và đánh dấu từng dòng “đã có”, “chưa có” hoặc “chấp nhận rủi ro”. Dòng nào chưa có phải kèm người xử lý và thời hạn. Kết quả buổi rà soát là căn cứ để quyết định bắt đầu đủ phạm vi, thu hẹp hay hoãn.

4. Ví dụ giả định

Một doanh nghiệp dùng checklist để phát hiện chưa có chủ sở hữu bảng giá và hoãn tích hợp cho đến khi nguồn được phê duyệt.

Bài học từ tình huống này là checklist phát huy tác dụng đúng lúc nó làm lộ ra khoảng trống trước khi có dòng code nào. Ca thử nên rút ra gồm: hỏi giá một sản phẩm có hai mức giá ở hai file khác nhau, hỏi giá sản phẩm vừa ngừng bán, và hỏi giá khi bảng giá đang được sửa. Kết quả mong đợi ở cả ba ca là agent không tự chọn một con số mà báo chưa có thông tin chính thức và chuyển cho người phụ trách bán hàng.

5. Rủi ro và giới hạn

• Không tự động hóa khi dữ liệu hoặc thẩm quyền chưa rõ
• Giới hạn quyền đọc ghi theo nhu cầu tối thiểu
• Giữ người phụ trách cho ngoại lệ và quyết định quan trọng
• Theo dõi log và kiểm thử lại sau mỗi thay đổi

Rủi ro lớn nhất ở giai đoạn chuẩn bị là coi checklist như thủ tục: điền cho đủ ô rồi bắt đầu, trong khi nhiều dòng thực chất vẫn còn “chưa rõ”. Rủi ro thứ hai là chuẩn bị quá lâu, chờ mọi nguồn dữ liệu hoàn hảo mới bắt đầu. Cách cân bằng là chấp nhận bắt đầu với phạm vi hẹp những phần đã đủ điều kiện, còn phần chưa đủ thì để ngoài phạm vi và ghi rõ lý do.

6. Phân chia trách nhiệm vận hành

Người sở hữu quy trình chịu trách nhiệm mục tiêu, danh sách ngoại lệ và bộ tình huống nghiệm thu. Người phụ trách từng nguồn dữ liệu cam kết giữ nguồn đó là bản chính thức và cập nhật khi có thay đổi. Bộ phận IT xác nhận khả năng tích hợp, cấp quyền cho tài khoản kỹ thuật và chuẩn bị môi trường thử. Người giữ ngân sách quyết định phạm vi khi checklist cho thấy phải cắt bớt.

Checklist nên được giao cho một đầu mối điều phối, thường là quản lý dự án phía doanh nghiệp, để theo dõi các dòng còn mở tới khi đóng hết. Mỗi lần phạm vi thay đổi, như thêm một kênh hay thêm một hệ thống, đầu mối này mở lại các dòng liên quan thay vì coi checklist đã xong từ đầu.

7. Chỉ số nên theo dõi

• Tỷ lệ hoàn thành đúng theo tiêu chí đã duyệt
• Tỷ lệ từ chối đúng và chuyển người phụ trách
• Lỗi tích hợp, độ trễ và số thao tác phải sửa
• Chi phí cùng tác động kinh doanh của quy trình

Ở giai đoạn chuẩn bị, chỉ số quan trọng nhất là số dòng checklist còn mở và thời gian mỗi dòng bị treo. Sau khi vận hành, nên đối chiếu các chỉ số trên với số liệu hiện trạng đã ghi ở mục tiêu kinh doanh. Nếu không có số liệu hiện trạng, mọi con số sau dự án chỉ cho biết agent đang chạy, không cho biết nó có giúp được gì hay không.

8. Checklist trước khi vận hành

• Nguồn dữ liệu và chủ sở hữu đã xác nhận
• Quyền đọc ghi đã thử với nhiều vai trò
• Có phương án khi hệ thống lỗi hoặc thiếu dữ liệu
• Có log, phê duyệt và cơ chế chống thao tác trùng
• Có bộ kiểm thử hồi quy và người vận hành

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

Chưa hoàn thành hết checklist thì có nên khởi động dự án AI Agent không? Có thể khởi động phần khảo sát và thiết kế, nhưng chưa nên cam kết phạm vi tích hợp hay ngày vận hành. Những mục còn trống, như nguồn dữ liệu chưa có chủ hoặc quyền truy cập chưa được duyệt, nên được ghi thành rủi ro có người theo dõi và hạn xử lý.

Nên bắt đầu điền checklist từ mục nào? Bắt đầu từ mục tiêu kinh doanh và quy trình hiện tại, vì hai mục này quyết định cần dữ liệu gì, tích hợp gì và ai phải tham gia. Điền tích hợp hay quyền truy cập trước khi rõ mục tiêu thường dẫn đến phạm vi phình to.

Ai cần ký xác nhận checklist trước khi dự án chạy? Tối thiểu là người sở hữu quy trình nghiệp vụ, người phụ trách các hệ thống sẽ kết nối và người chịu trách nhiệm ngân sách. Nếu agent chạm dữ liệu cá nhân, tài chính hoặc có hành động ghi, nên có thêm đại diện an toàn thông tin hoặc kiểm soát nội bộ.

Checklist này khác gì checklist nghiệm thu? Checklist chuẩn bị trả lời câu hỏi “đã đủ điều kiện để bắt đầu chưa”, còn checklist nghiệm thu trả lời “hệ thống đã đủ điều kiện để dùng thật chưa”. Làm tốt bước chuẩn bị thì tiêu chí nghiệm thu cũng được viết sẵn từ đầu thay vì chờ tới cuối dự án.

Kết luận

Một checklist chuẩn bị tốt không làm dự án chậm lại; nó đưa những câu hỏi khó lên đầu, lúc thay đổi còn rẻ. Khi mục tiêu, nguồn dữ liệu, người sở hữu và quyền truy cập đã rõ, doanh nghiệp có thể viết yêu cầu gửi nhà cung cấp một cách chính xác, như hướng dẫn ở bài cách viết RFP cho dự án AI Agent.

Trao đổi với Naventic để rà soát mức sẵn sàng trước khi khởi động dự án AI Agent. Đọc thêm: Dịch vụ.