Cách đánh giá nhà cung cấp giải pháp AI Agent trước khi ký hợp đồng

Khi đã có hai, ba đề xuất AI Agent trên bàn, doanh nghiệp thường bị kéo về hai thứ dễ so nhất: tổng giá và cảm giác sau buổi demo. Cả hai đều không cho biết nhà cung cấp sẽ làm gì khi dữ liệu thiếu, khi API của phần mềm nội bộ đổi phiên bản, hay khi agent trả lời sai với khách thật.

Bài checklist lựa chọn đơn vị triển khai AI Agent đã liệt kê những câu hỏi cần đặt ra ở vòng đầu. Bài này dành cho giai đoạn sát ngày ký: biến các câu hỏi đó thành bảng chấm điểm có bằng chứng, chuẩn bị câu hỏi thẩm định để hỏi thẳng đội kỹ thuật của nhà cung cấp, và đọc kỹ những điều khoản hợp đồng hay bị lướt qua.

Mục tiêu không phải tìm một nhà cung cấp hoàn hảo, mà là biết rõ mình đang chấp nhận rủi ro gì với từng lựa chọn.

1. Bản chất của đánh giá nhà cung cấp AI Agent

Đánh giá nhà cung cấp phần mềm thông thường chủ yếu xem tính năng có đủ không. Với AI Agent, thứ được bàn giao còn gồm những phần khó thấy: cách agent tìm dữ liệu, cách nó chọn công cụ để gọi và cách nó dừng lại khi không chắc chắn. Hai nhà cung cấp dùng cùng một mô hình ngôn ngữ vẫn có thể cho kết quả rất khác nhau, vì khác biệt nằm ở khâu khảo sát, thiết kế dữ liệu và kiểm soát quyền.

Vì vậy nên chấm riêng năng lực ở ba mức việc. Mức hỏi đáp: nhà cung cấp có chứng minh được agent trả lời đúng từ tài liệu của doanh nghiệp và biết nói “chưa có thông tin” khi tài liệu không có. Mức tra cứu: họ đã từng kết nối với loại hệ thống doanh nghiệp đang dùng chưa, và xử lý ra sao khi nguồn chậm hoặc lỗi. Mức ghi: họ thiết kế chống lặp, phê duyệt và nhật ký thế nào cho những thao tác như tạo đơn hay cập nhật CRM. Một bên mạnh ở mức đầu chưa chắc đã sẵn sàng cho mức thứ ba.

2. Tám tiêu chí cần chấm điểm

1. Năng lực khảo sát

Nhà cung cấp tốt hỏi nhiều trước khi báo giá: ai đang làm việc này, dữ liệu nằm ở đâu, ngoại lệ nào hay gặp. Câu hỏi thẩm định nên đặt: “Anh chị cần gặp những ai và xem tài liệu nào trước khi chốt phạm vi?”. Nếu đề xuất đến ngay sau một cuộc gọi giới thiệu mà đã kèm danh sách tính năng dài, nhiều khả năng phần khảo sát sẽ bị đẩy sang sau khi ký, lúc mọi điều chỉnh đều thành phát sinh.

2. Kiến trúc đề xuất

Yêu cầu một sơ đồ chỉ rõ dữ liệu đi từ đâu đến đâu, agent gọi những công cụ nào và phần nào chạy trên hạ tầng của ai. Hỏi thêm: nếu đổi mô hình ngôn ngữ hoặc đổi CRM thì phải làm lại những phần nào. Sơ đồ chỉ vẽ một khối “AI” ở giữa, không tách truy xuất, công cụ và lớp kiểm soát, là dấu hiệu nên chấm thấp.

3. Bảo mật

Bảo mật nên được chấm bằng cách làm cụ thể, không bằng những chứng chỉ trưng trên slide. Hỏi rõ khóa API của hệ thống doanh nghiệp được lưu ở đâu, ai trong đội nhà cung cấp truy cập được dữ liệu, dữ liệu có đi qua dịch vụ bên thứ ba nào không và nhật ký có che thông tin cá nhân không. Câu trả lời tốt thường kèm tài liệu mô tả luồng dữ liệu; câu kiểu “hệ thống bảo mật tuyệt đối” nên bị trừ điểm. Các lớp cần kiểm có ở bài bảo mật dữ liệu AI Agent.

4. Demo theo dữ liệu thật

Demo trên dữ liệu mẫu của nhà cung cấp gần như luôn đẹp. Hãy gửi cùng một bộ tài liệu và cùng một danh sách câu hỏi cho mọi ứng viên, trong đó cài sẵn câu thiếu dữ liệu, câu ngoài phạm vi và câu cố tình yêu cầu vượt quyền. Điểm cao dành cho bên vừa trả lời đúng vừa từ chối đúng, và giải thích được vì sao một câu bị sai. Nếu dữ liệu nhạy cảm, dùng bản đã che tên và số liệu.

5. Tiêu chí nghiệm thu

Đề nghị mỗi nhà cung cấp tự viết dự thảo tiêu chí nghiệm thu cho phạm vi họ báo giá. Cách họ viết cho thấy họ hiểu dự án tới đâu: tiêu chí tốt gắn với ca thử, dữ liệu đầu vào và kết quả mong đợi; tiêu chí yếu chỉ ghi “agent hoạt động ổn định, trả lời chính xác” và để phần giải thích lại cho lúc nghiệm thu, khi hai bên dễ hiểu khác nhau nhất.

6. Tài liệu bàn giao

Xin xem mẫu tài liệu bàn giao của một dự án trước, đã che thông tin khách. Một bộ đủ dùng thường có sơ đồ tích hợp, danh sách tài khoản và quyền, cách cập nhật kho kiến thức, bộ ca kiểm thử hồi quy và hướng dẫn tạm dừng agent khi có sự cố. Nhà cung cấp không đưa ra được mẫu nào thì chấm thấp, và đưa danh mục tài liệu bắt buộc vào phụ lục hợp đồng.

7. Hỗ trợ sau triển khai

Hỏi ai xử lý khi agent lỗi ngoài giờ, kênh báo lỗi là gì, việc nào nằm trong gói hỗ trợ và việc nào tính riêng: sửa lỗi, cập nhật tài liệu, xử lý khi hệ thống bên thứ ba đổi API. Các cam kết này nên được viết thành SLA cho AI Agent với mức sự cố và đầu mối rõ ràng, thay vì một câu “hỗ trợ tận tình” trong báo giá.

8. Minh bạch chi phí

Chi phí AI Agent có phần làm một lần và phần thay đổi theo mức sử dụng, như lượt gọi mô hình, hạ tầng hay dịch vụ kênh nhắn tin. Chấm cao cho bảng giá tách được từng dòng và nói rõ giả định về lưu lượng dùng để ước tính. Một báo giá trọn gói không tách dòng khiến doanh nghiệp không so được với bên khác và khó đoán chi phí khi lượng dùng tăng.

3. Bảng chấm điểm mẫu

Bảng dưới đây gom tám tiêu chí thành một khung chấm chung cho mọi ứng viên. Mỗi tiêu chí chấm theo ba mức: 1 điểm khi chỉ có lời hứa, 3 điểm khi có tài liệu hoặc quy trình mô tả, 5 điểm khi đã chứng minh trên dữ liệu và tình huống của chính doanh nghiệp. Trọng số do doanh nghiệp tự đặt theo rủi ro: agent có quyền ghi vào hệ thống tài chính nên đặt nặng bảo mật và nghiệm thu hơn agent chỉ trả lời câu hỏi.

Nên để hai hoặc ba người chấm độc lập, gồm người phụ trách nghiệp vụ và người phụ trách kỹ thuật, rồi mới ngồi lại so kết quả. Tiêu chí nào có điểm lệch nhau nhiều giữa các người chấm là chỗ cần hỏi thêm nhà cung cấp.

4. Điều khoản hợp đồng cần đọc kỹ

Nhiều rủi ro của dự án AI Agent chỉ lộ ra trong hợp đồng, không phải trong demo. Trước khi ký, nên rà các điểm sau cùng bộ phận pháp chế hoặc đơn vị tư vấn:

• Phạm vi công việc kèm danh sách những gì không bao gồm
• Tiêu chí nghiệm thu và bộ ca thử được đính kèm làm phụ lục
• Quyền sở hữu hoặc quyền sử dụng với dữ liệu, cấu hình, prompt và mã nguồn
• Nơi lưu trữ, xử lý dữ liệu và các dịch vụ bên thứ ba được phép dùng
• Cam kết hỗ trợ, cách phân mức sự cố và thời gian phản hồi
• Cách tính chi phí biến đổi và ai đứng tên các tài khoản dịch vụ
• Quy trình yêu cầu thay đổi và cách định giá phát sinh
• Điều kiện chấm dứt và nghĩa vụ chuyển giao khi dừng hợp tác

Điều khoản cuối thường bị bỏ qua nhất. Nếu hợp đồng không nói rõ khi dừng hợp tác doanh nghiệp nhận lại những gì, ở định dạng nào, thì kho kiến thức, lịch sử cấu hình và bộ ca thử có thể mắc kẹt ở phía nhà cung cấp.

5. Quy trình đánh giá thực tế

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

Trước khi liên hệ nhà cung cấp, doanh nghiệp tự viết một tài liệu ngắn: quy trình nào, ai dùng, agent được đọc và ghi những gì, kết quả nào thì coi là thành công. Tài liệu này gửi giống nhau cho mọi ứng viên để các đề xuất nhận về so được với nhau. Người sở hữu nghiệp vụ xác nhận nội dung trước khi gửi đi.

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

Chuẩn bị bộ dữ liệu thử gồm tài liệu mẫu, vài bản ghi đã che thông tin và danh sách câu hỏi kèm đáp án mong đợi. Quyết định trước nhà cung cấp được xem đến đâu, qua kênh nào, và ký thỏa thuận bảo mật trước khi chuyển dữ liệu. IT hoặc người phụ trách an toàn thông tin duyệt bộ dữ liệu này.

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

Ở vòng thẩm định kỹ thuật, yêu cầu từng nhà cung cấp trình bày cách xử lý ba tình huống: hệ thống nguồn không phản hồi, hai nguồn dữ liệu mâu thuẫn và thao tác ghi cần người duyệt. Biên bản ghi câu trả lời của từng bên là căn cứ chấm tiêu chí kiến trúc và bảo mật. Người phụ trách kỹ thuật của doanh nghiệp chủ trì buổi này.

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

Với một hoặc hai ứng viên cuối, có thể thỏa thuận một đợt chạy thử có phạm vi và chi phí rõ ràng. Trong đợt này, đề nghị được xem nhật ký: câu nào agent trả lời, dựa vào nguồn nào, câu nào bị chuyển người. Kết quả chạy thử cùng bảng chấm điểm được trình lên người ra quyết định cuối cùng.

6. Ví dụ giả định

Ba nhà cung cấp được yêu cầu chạy cùng bộ ca thử; doanh nghiệp chọn phương án giải thích được lỗi và kế hoạch vận hành rõ nhất.

Điều đáng rút ra là tiêu chí chọn không dừng ở số câu trả lời đúng. Giả sử bên có demo mượt nhất không giải thích được vì sao hai câu bị sai, còn một bên khác chỉ ra ngay câu nào sai do tài liệu cũ, câu nào do truy xuất nhầm đoạn. Từ đó có thể lập một ca thẩm định cố định cho các lần chọn sau: cài sẵn một tài liệu mâu thuẫn và một câu vượt quyền trong bộ thử, rồi chấm cả cách nhà cung cấp chẩn đoán lỗi chứ không chỉ kết quả.

7. 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

Trong giai đoạn đánh giá, rủi ro lớn nhất là để lộ dữ liệu cho những bên cuối cùng không được chọn. Chỉ gửi dữ liệu đã che, qua kênh có kiểm soát, và yêu cầu xóa sau khi kết thúc thẩm định. Rủi ro thứ hai là bị khóa vào một nhà cung cấp: nếu kho kiến thức, prompt và cấu hình chỉ tồn tại trên nền tảng của họ, việc đổi đơn vị sau này gần như phải làm lại từ đầu. Bốn nguyên tắc ở trên cũng là câu hỏi nên đặt cho nhà cung cấp: trong thiết kế của họ, quyền tối thiểu và người duyệt nằm ở đâu.

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

Trong một đợt đánh giá, người sở hữu nghiệp vụ quyết định phạm vi và chấm phần hiểu nghiệp vụ, phần demo. Đội IT chấm kiến trúc, tích hợp và bảo mật. Bộ phận mua hàng hoặc tài chính so cấu trúc chi phí, còn pháp chế rà hợp đồng. Người ra quyết định cuối cùng nên nhận bảng tổng hợp có ý kiến của cả bốn bên, không chỉ bản trình bày của nhà cung cấp.

Sau khi ký, cần ghi rõ ai phía doanh nghiệp làm đầu mối với nhà cung cấp, ai duyệt thay đổi phạm vi và ai có quyền yêu cầu tạm dừng agent khi có sự cố. Thiếu đầu mối, mọi yêu cầu đi qua nhiều người, nhà cung cấp không biết nghe ai, và khi có lỗi rất khó xác định trách nhiệm.

9. 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

Những chỉ số này nên xuất hiện ngay trong đợt chạy thử, không đợi đến sau khi ký. Nhà cung cấp đưa ra được báo cáo tách theo loại yêu cầu, có tỷ lệ từ chối đúng và lỗi tích hợp, thường cũng là bên vận hành minh bạch về sau. Nếu báo cáo chỉ có số hội thoại hay số người dùng, hãy yêu cầu bổ sung trước khi chấm điểm.

10. Checklist trước khi ký

• 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

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

Có thể đánh giá nhà cung cấp AI Agent ngay khi nhận báo giá không? Có thể sàng lọc sơ bộ, nhưng chưa đủ để quyết định. Báo giá chỉ so được với nhau khi mọi bên trả lời cùng một tài liệu yêu cầu; sau đó cần thêm vòng thẩm định kỹ thuật và chạy bộ ca thử chung.

Nên bắt đầu đánh giá nhà cung cấp AI Agent từ đâu? Bắt đầu từ tài liệu yêu cầu do chính doanh nghiệp viết: quy trình nào, dữ liệu nào, agent được đọc và ghi gì, kết quả nào là thành công. Có tài liệu này rồi mới gửi cho các nhà cung cấp và dựng bảng chấm điểm.

Ai cần duyệt trước khi ký hợp đồng với nhà cung cấp AI Agent? Tối thiểu là người sở hữu nghiệp vụ, người phụ trách IT hoặc an toàn thông tin và bộ phận pháp chế. Nếu agent được ghi vào hệ thống tài chính hay xử lý dữ liệu cá nhân, nên có thêm người phụ trách kiểm soát nội bộ.

Có nên chọn nhà cung cấp có kết quả demo tốt nhất không? Chưa chắc. Demo chỉ là một trong tám tiêu chí. Bên giải thích được vì sao agent sai, có tài liệu bàn giao rõ và chấp nhận điều khoản chuyển giao khi dừng hợp tác thường ít rủi ro hơn trong vận hành lâu dài.

Kết luận

Đánh giá nhà cung cấp AI Agent là so bằng chứng, không so lời hứa. Một bảng chấm điểm chung, một bộ ca thử chung và danh sách điều khoản cần đọc giúp những đề xuất rất khác nhau trở nên so được với nhau. Bên đáng chọn thường là bên nói rõ giới hạn của mình và chỉ ra được lỗi nằm ở đâu.

Trao đổi với Naventic để nhận đề xuất theo đúng bộ tiêu chí của doanh nghiệp. Đọc thêm: Dịch vụ.