Lộ trình 90 ngày triển khai AI Agent: từ khảo sát đến vận hành

Nhiều doanh nghiệp muốn một câu trả lời đơn giản trước khi bắt đầu dự án AI Agent: sau ba tháng sẽ có gì trong tay. Đó là câu hỏi hợp lý, vì ban lãnh đạo cần biết khi nào phải ra quyết định, phòng ban nào phải dành thời gian, và thế nào thì được coi là xong.

Bài viết này đưa ra một lộ trình mẫu trong 90 ngày, chia thành tám chặng và năm cổng quyết định. Đây không phải cam kết tiến độ. Thời gian thật của từng chặng phụ thuộc phạm vi, độ sẵn sàng của dữ liệu, số hệ thống cần kết nối và tốc độ phản hồi của phía doanh nghiệp. Mục đích của lộ trình là giúp hai bên biết việc gì đi trước, việc gì chạy song song và ở đâu phải dừng lại để quyết định.

Nếu cần xem chi tiết từng giai đoạn kỹ thuật, hãy đọc bài quy trình triển khai AI Agent. Bài này tập trung vào cách xếp các giai đoạn đó lên một khung thời gian và quản lý nó.

1. Bản chất của một lộ trình triển khai AI Agent

Một lộ trình tốt không phải biểu đồ Gantt với ngày cố định cho từng việc, mà là chuỗi cổng quyết định. Mỗi cổng có đầu vào cần chuẩn bị, người duyệt và ba lựa chọn: đi tiếp, sửa rồi xem lại, hoặc dừng. Cách này quan trọng với AI Agent vì chất lượng câu trả lời chỉ đo được khi đã chạy trên dữ liệu thật, nên kế hoạch phải chừa chỗ cho việc điều chỉnh.

Ba mức năng lực hỏi đáp, tra cứu thời gian thực và hành động ghi cũng quyết định hình dạng lộ trình. Agent chỉ hỏi đáp trên tài liệu có thể đi hết các chặng khá nhanh. Agent tra cứu cần thêm thời gian cho API và phân quyền. Agent ghi vào hệ thống cần chặng pilot và UAT dài hơn, vì lỗi ghi khó hoàn tác. Một cách làm phổ biến là đưa phần hỏi đáp vào dùng trước trong 90 ngày đầu, còn phần ghi để sang vòng tiếp theo.

Khung tham chiếu có thể hình dung như sau, không gắn số ngày cho từng chặng:

2. Tám chặng của lộ trình mẫu

1. Tuần khảo sát

Gọi là tuần khảo sát cho dễ hình dung; với quy trình liên quan nhiều phòng ban, khảo sát có thể kéo dài hơn. Việc chính là phỏng vấn người làm thật, thu mẫu yêu cầu thật, liệt kê hệ thống và tài liệu liên quan. Đầu ra là tài liệu phạm vi ghi rõ Agent làm gì, không làm gì, đo bằng gì. Dấu hiệu khảo sát chưa đủ là không ai nói được ba loại ngoại lệ hay gặp nhất.

2. Chuẩn bị dữ liệu

Chặng này bắt đầu ngay khi phạm vi rõ và thường chạy song song với thiết kế. Phía doanh nghiệp chọn tài liệu chính thức, gỡ bản cũ, gán người sở hữu cho từng nguồn và xin quyền truy cập hệ thống. Đây là chỗ dự án hay bị chậm nhất, vì phụ thuộc vào thời gian của người nghiệp vụ, nên cần một người phía doanh nghiệp được giao riêng việc này.

3. Thiết kế tích hợp

Thiết kế ghi rõ Agent đọc hệ thống nào, ghi vào đâu, dùng tài khoản dịch vụ nào, xử lý ra sao khi API chậm hoặc lỗi. Các luồng ngoại lệ và điểm cần người duyệt cũng được vẽ ở đây. Cổng quyết định cuối chặng đầu là buổi duyệt thiết kế có mặt người sở hữu nghiệp vụ và IT.

4. Xây dựng

Đội triển khai dựng phần hội thoại, kết nối kho kiến thức và API, cài quyền, nhật ký và cảnh báo. Nên có bản chạy được trên môi trường thử sớm để người nghiệp vụ xem và góp ý hằng tuần, thay vì đợi đến cuối chặng. Việc thêm yêu cầu mới giữa chừng cần ghi vào danh sách riêng để quyết định ở cổng sau, không nhét ngay vào bản đang dựng.

5. Pilot

Pilot là chạy với một nhóm người dùng thật nhỏ trên phạm vi hẹp, thường song song với cách làm cũ. Mục tiêu là tìm lỗi mà bộ thử trên giấy không bắt được: cách diễn đạt lạ, dữ liệu thiếu, người dùng dùng sai mục đích. Người vận hành đọc log hằng ngày và phân loại lỗi theo dữ liệu, tích hợp hay kịch bản.

6. UAT

UAT là buổi kiểm thử chấp nhận theo tiêu chí đã chốt từ đầu, với bộ ca thử gồm cả tình huống chuẩn và tình huống xấu. Người ký nghiệm thu là người sở hữu nghiệp vụ, không phải đội triển khai. Danh mục tình huống nên thử có ở bài checklist nghiệm thu AI Agent.

7. Đào tạo

Người dùng cần biết Agent làm được gì, không làm gì và phải làm gì khi Agent trả lời sai. Người vận hành cần biết cách đọc log, sửa dữ liệu, tạm dừng tính năng và báo sự cố. Đào tạo ngắn theo tình huống thật hiệu quả hơn một buổi giới thiệu tính năng dài.

8. Đánh giá mở rộng

Cuối lộ trình, nhóm dự án so kết quả với chỉ số đã đặt từ tuần khảo sát và đề xuất bước tiếp theo: mở cho thêm người dùng, thêm kênh, thêm quy trình hay giữ nguyên để ổn định. Quyết định mở rộng dựa trên số liệu vận hành thật, không dựa trên cảm nhận sau buổi demo.

3. Cách vận hành lộ trình

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

Ngay buổi khởi động, hai bên chốt quy trình, người sở hữu nghiệp vụ, chỉ số đo và lịch các cổng quyết định. Tài liệu phạm vi được ký trước khi sang chặng xây dựng. Mọi thay đổi phạm vi sau đó đều đi qua người sở hữu nghiệp vụ và được ghi lại cùng ảnh hưởng tới tiến độ.

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

Danh sách tài liệu, hệ thống và quyền cần có được lập từ tuần đầu, mỗi mục có người chịu trách nhiệm và ngày cần xong. Nhóm dự án theo dõi danh sách này mỗi tuần như một hạng mục riêng. Khi một quyền truy cập bị chậm, lộ trình điều chỉnh sớm thay vì phát hiện lúc sắp pilot.

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

Mỗi cổng quyết định có một buổi họp ngắn với tài liệu đầu vào gửi trước: bản thiết kế, kết quả thử, danh sách lỗi còn mở. Người duyệt chọn đi tiếp, sửa rồi xem lại hoặc dừng, và lý do được ghi vào biên bản. Những yếu tố hay làm một cổng bị lùi được phân tích ở bài thời gian triển khai AI Agent.

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

Từ lúc có bản chạy thử, mỗi tuần có một buổi xem log và danh sách lỗi cùng người nghiệp vụ. Lỗi được xếp theo mức ảnh hưởng, lỗi nặng phải xong trước cổng tiếp theo. Bộ ca thử được bổ sung sau mỗi lỗi mới để lần sửa sau không làm hỏng lại chỗ cũ.

4. Ví dụ giả định

Doanh nghiệp chia 90 ngày thành các cổng quyết định, chỉ mở rộng sau khi pilot đạt chất lượng và vận hành ổn định.

Giả sử đến cổng cho phép pilot, quyền đọc CRM vẫn chưa được cấp. Lộ trình tốt cho phép hai lựa chọn rõ ràng: pilot phần hỏi đáp trên tài liệu trước và để phần tra cứu CRM sang sau, hoặc lùi cổng pilot và báo lãnh đạo lý do. Bài học rút ra là mỗi cổng nên có tiêu chí đi tiếp viết sẵn và phương án thu hẹp phạm vi, để khi thiếu một điều kiện, dự án vẫn có quyết định chứ không trôi.

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 của một lộ trình 90 ngày là coi con số 90 như hạn chót bắt buộc. Khi đó các cổng quyết định bị bỏ qua, pilot bị rút ngắn và UAT trở thành thủ tục, dẫn tới một Agent mở rộng khi chưa ổn. Rủi ro thứ hai là phạm vi phình dần qua từng buổi họp. Rủi ro thứ ba là người nghiệp vụ không có thời gian thật cho dự án, khiến dữ liệu và nghiệm thu bị dồn về cuối.

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

Nhà tài trợ dự án phía doanh nghiệp, thường là trưởng bộ phận, chủ trì các cổng quyết định và giải quyết vướng mắc giữa phòng ban. Người sở hữu nghiệp vụ trả lời câu hỏi về quy trình, duyệt dữ liệu, tham gia pilot và ký UAT. IT cấp quyền, hỗ trợ tích hợp và duyệt phần bảo mật. Đội triển khai lập kế hoạch, dựng Agent, báo cáo tiến độ hằng tuần và nói sớm khi có rủi ro trễ.

Sau khi vận hành, lộ trình chuyển thành nhịp cải tiến. Mỗi thay đổi về dữ liệu, prompt, mô hình hay quyền đi qua một vòng thử nhỏ trước khi áp dụng. Người vận hành có quyền tạm dừng tính năng khi thấy lỗi nghiêm trọng, và nhà tài trợ dự án quyết định khi nào mở lại.

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

• Tỷ lệ cổng quyết định đi qua đúng lịch và đủ tài liệu
• Tỷ lệ yêu cầu Agent xử lý đúng trong pilot và UAT
• Số lỗi còn mở, độ trễ và số thao tác phải sửa tay
• Chi phí cùng tác động tới quy trình được chọn

Theo dõi tiến độ bằng phần trăm việc đã làm dễ gây hiểu lầm, vì phần khó thường nằm ở cuối. Tốt hơn là đo theo cổng: cổng nào đã qua, cổng nào đang chờ điều kiện gì, lỗi nặng còn bao nhiêu. Sau khi vận hành, chuyển sang chỉ số chất lượng và tác động của chính quy trình đã chọn.

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

• Phạm vi, người sở hữu và lịch các cổng đã được 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

Có thể áp nguyên lộ trình 90 ngày cho mọi dự án AI Agent không? Không nên áp nguyên. Chín mươi ngày là khung tham chiếu cho một quy trình có phạm vi vừa phải; dự án chỉ hỏi đáp trên tài liệu sẵn có có thể ngắn hơn, dự án ghi vào nhiều hệ thống có thể dài hơn. Tiến độ thật chỉ chốt được sau khi khảo sát dữ liệu và tích hợp.

Nên bắt đầu lộ trình triển khai AI Agent từ đâu? Bắt đầu bằng việc chọn một quy trình, một người sở hữu nghiệp vụ và một bộ tiêu chí đo trước khi viết dòng mã nào. Việc xin quyền truy cập và gom tài liệu nên khởi động ngay tuần đầu vì đây thường là phần chờ lâu nhất.

Khi nào trong lộ trình cần người duyệt? Ở mỗi cổng quyết định: chốt phạm vi sau khảo sát, duyệt thiết kế tích hợp và ngoại lệ, quyết định cho pilot chạy thật, ký nghiệm thu UAT và quyết định mở rộng. Người duyệt nên được chỉ định từ đầu cùng lịch họp cho từng cổng.

Nếu đến cuối 90 ngày mà pilot chưa đạt thì sao? Không mở rộng. Nhóm dự án xem log để biết lỗi nằm ở dữ liệu, tích hợp hay phạm vi, rồi quyết định kéo dài pilot, thu hẹp phạm vi hoặc dừng. Mở rộng một Agent chưa ổn chỉ nhân lỗi lên nhiều người dùng hơn.

Kết luận

Lộ trình 90 ngày hữu ích khi nó là khung để ra quyết định đúng lúc, không phải lời hứa về ngày hoàn thành. Chọn một quy trình, khởi động phần dữ liệu và quyền từ tuần đầu, giữ nghiêm các cổng quyết định, và chỉ mở rộng khi số liệu pilot cho thấy Agent đã ổn.

Trao đổi với Naventic để lập lộ trình triển khai AI Agent cho quy trình của bạn. Đọc thêm: Dịch vụ.