Hợp đồng dịch vụ AI Agent cần có những điều khoản nào?

Hợp đồng phần mềm thông thường mô tả một sản phẩm tương đối cố định: tính năng này, giao diện kia, chạy trên hạ tầng nọ. AI Agent thì khác. Câu trả lời của nó không lặp lại y hệt giữa hai lần hỏi, chất lượng phụ thuộc vào dữ liệu doanh nghiệp đưa vào, và phần lõi thường là mô hình ngôn ngữ của một bên thứ ba có thể thay đổi bất cứ lúc nào. Những đặc điểm đó cần được phản ánh trong hợp đồng, nếu không hai bên sẽ tranh cãi ở đúng những chỗ mà văn bản im lặng.

Bài viết đi qua các điều khoản theo vòng đời của một hợp đồng dịch vụ AI Agent: từ lúc chốt phạm vi, trong quá trình vận hành, tới lúc bàn giao hoặc chấm dứt. Nếu bạn đang ở bước chọn nhà cung cấp, bài đánh giá nhà cung cấp AI Agent có danh sách điều khoản cần đọc kỹ trước khi ký; bài này đi sâu hơn vào cách viết và cách kiểm từng nhóm điều khoản. Nội dung dưới đây không phải tư vấn pháp lý; hợp đồng cụ thể cần pháp chế của doanh nghiệp rà theo quy định hiện hành.

1. Vì sao hợp đồng AI Agent cần cách viết riêng

Có bốn điểm khiến khuôn hợp đồng phần mềm quen thuộc không đủ. Thứ nhất, đầu ra không xác định: không thể cam kết “agent luôn trả lời đúng”, chỉ có thể cam kết đạt ngưỡng trên một bộ ca thử đã thống nhất. Thứ hai, dữ liệu chảy qua nhiều bên: hệ thống của doanh nghiệp, hạ tầng của nhà cung cấp dịch vụ, và nhà cung cấp mô hình. Thứ ba, sản phẩm tiếp tục thay đổi sau nghiệm thu, vì kho kiến thức được cập nhật, prompt được chỉnh, mô hình được nâng cấp. Thứ tư, phần giá trị nhất khi dừng hợp tác không chỉ là mã nguồn mà là dữ liệu đã được làm sạch, cấu hình và bộ ca thử.

Một hợp đồng tốt không cố viết kín mọi tình huống. Nó xác định ai quyết định, ai chịu chi phí và điều gì xảy ra khi một trong bốn điểm trên thay đổi.

2. Điều khoản theo vòng đời hợp đồng

1. Phạm vi dịch vụ và cách thay đổi phạm vi

Phạm vi nên mô tả bằng quy trình nghiệp vụ và hệ thống cụ thể: agent tiếp nhận loại yêu cầu nào, đọc từ hệ thống nào, được ghi vào đâu, kênh nào. Đi kèm là danh sách những gì không bao gồm, ví dụ không tự thực hiện hoàn tiền, không kết nối hệ thống kế toán. Quan trọng không kém là cách thay đổi phạm vi: ai được đề xuất, ai duyệt, đánh giá tác động trong bao lâu, và thay đổi được tính chi phí theo nguyên tắc nào. Dự án AI gần như chắc chắn sẽ có thay đổi phạm vi sau khi người dùng thật bắt đầu hỏi.

Nếu doanh nghiệp đã có hồ sơ yêu cầu, phần phạm vi trong hợp đồng nên dẫn chiếu tới đó thay vì viết lại. Cách chuẩn bị hồ sơ này có ở bài viết RFP cho dự án AI Agent.

2. Dữ liệu, đầu ra và quyền sở hữu

Cần tách ít nhất bốn thứ: dữ liệu doanh nghiệp đưa vào (tài liệu, danh mục, lịch sử khách hàng), dữ liệu phát sinh khi vận hành (hội thoại, nhật ký), đầu ra do agent tạo (câu trả lời, bản nháp, báo cáo), và các sản phẩm kỹ thuật (mã nguồn viết riêng, cấu hình, prompt, bộ ca thử). Với mỗi loại, hợp đồng nói ai sở hữu, ai được dùng vào mục đích gì. Điểm hay gây tranh cãi là nhà cung cấp có được dùng dữ liệu hội thoại để cải tiến sản phẩm chung của họ hay không; nếu không muốn, phải ghi rõ.

3. Bảo mật và xử lý dữ liệu

Điều khoản bảo mật nên gắn với luồng dữ liệu thật: dữ liệu được lưu ở đâu, truyền qua đâu, ai trong đội nhà cung cấp được truy cập, lưu bao lâu. Yêu cầu về vị trí lưu trữ và bản sao lưu được phân tích ở bài data residency khi triển khai AI Agent. Hợp đồng cũng nên quy định nghĩa vụ thông báo khi có sự cố liên quan dữ liệu, thời hạn thông báo và thông tin tối thiểu phải cung cấp. Khi agent chạm tới dữ liệu cá nhân của khách hay nhân viên, pháp chế nên soát riêng phần này theo quy định hiện hành về dữ liệu cá nhân.

4. Cam kết mức dịch vụ

Mức dịch vụ gồm thời gian sẵn sàng, thời gian phản hồi theo mức nghiêm trọng, cách báo cáo và cách xử lý khi không đạt. Những chỉ số này đã được trình bày đầy đủ ở bài SLA cho AI Agent. Trong hợp đồng, điều cần chú ý là phần phụ thuộc bên thứ ba: khi nhà cung cấp mô hình gặp sự cố, thời gian đó có tính vào cam kết hay không, và nhà cung cấp dịch vụ phải làm gì trong lúc đó.

5. Nhà thầu phụ và dịch vụ bên thứ ba

Một AI Agent thường dùng nhiều dịch vụ bên ngoài: nhà cung cấp mô hình, hạ tầng đám mây, dịch vụ nhắn tin, công cụ giám sát. Hợp đồng nên có danh sách các bên này ở dạng phụ lục, nghĩa vụ báo trước khi thêm hoặc đổi một bên có tiếp cận dữ liệu, và quyền của doanh nghiệp phản đối thay đổi đó. Ai đứng tên tài khoản dịch vụ và ai trả chi phí sử dụng biến đổi cũng cần ghi rõ, vì điều này quyết định việc chuyển giao sau này dễ hay khó.

6. Thay đổi mô hình hoặc nhà cung cấp mô hình

Đây là điều khoản đặc thù nhất của AI Agent. Nhà cung cấp mô hình có thể ra phiên bản mới, ngừng phiên bản cũ hoặc đổi điều kiện sử dụng. Hợp đồng nên quy định: ai được quyết định đổi mô hình; phải báo trước bao lâu; bộ ca thử nào phải chạy lại trước khi đổi; nếu kết quả thấp hơn ngưỡng đã nghiệm thu thì xử lý thế nào; chi phí phát sinh do ai chịu. Không có điều khoản này, doanh nghiệp có thể thấy chất lượng câu trả lời thay đổi mà không biết lý do.

7. Nghiệm thu và bàn giao

Nghiệm thu nên dựa trên bộ ca thử đính kèm làm phụ lục, kèm ngưỡng đạt cho từng nhóm ca. Cách xây bộ tiêu chí có ở bài checklist nghiệm thu AI Agent. Bàn giao cần liệt kê cụ thể: mã nguồn phần viết riêng, cấu hình, prompt, tài liệu kiến trúc, hướng dẫn vận hành, danh sách tài khoản và quyền, bộ ca thử. Nếu nhà cung cấp tiếp tục vận hành sau bàn giao, hợp đồng nên nói rõ doanh nghiệp được xem những gì trong thời gian đó.

8. Chấm dứt và rút dữ liệu

Điều khoản chấm dứt cần trả lời: lúc chia tay, những tài sản nào được giao lại cho doanh nghiệp, dưới dạng tệp gì, trong thời hạn nào; nhà cung cấp xóa dữ liệu ở hệ thống của họ và của các bên thứ ba ra sao, có xác nhận bằng văn bản không; có giai đoạn chuyển tiếp để đơn vị khác tiếp quản mà dịch vụ không bị gián đoạn không. Kho kiến thức đã được làm sạch và bộ ca thử là tài sản mất nhiều công sức nhất để làm lại, nên phải nằm trong danh sách trả lại.

3. Rà hợp đồng theo bốn bước

Bước 1: Vẽ luồng dữ liệu trước khi đọc điều khoản

Trước khi mở bản hợp đồng, vẽ một sơ đồ đơn giản: dữ liệu đi từ hệ thống nào, qua dịch vụ nào, lưu ở đâu, ai xem được. Sơ đồ này giúp phát hiện ngay điều khoản bảo mật hay danh sách nhà thầu phụ còn thiếu một mắt xích.

Bước 2: Đối chiếu phạm vi với hồ sơ yêu cầu

So từng dòng phạm vi trong hợp đồng với hồ sơ yêu cầu và biên bản khảo sát. Mọi thứ đã trao đổi miệng mà không có trong văn bản coi như không có. Danh sách “không bao gồm” cần được bộ phận nghiệp vụ đọc, vì họ là người biết việc nào dễ bị ngầm hiểu là có.

Bước 3: Diễn tập các tình huống thay đổi

Đặt vài câu hỏi giả định và tìm câu trả lời trong văn bản: nhà cung cấp mô hình ngừng phiên bản đang dùng thì sao; doanh nghiệp muốn thêm một kênh chat; nhà cung cấp muốn đổi hạ tầng lưu trữ; hai bên dừng hợp tác sau một năm. Tình huống nào không tìm được câu trả lời là chỗ cần bổ sung.

Bước 4: Pháp chế rà và chốt phụ lục

Pháp chế hoặc luật sư của doanh nghiệp rà phần trách nhiệm, bồi thường, bảo vệ dữ liệu và luật áp dụng. Các phụ lục kỹ thuật như bộ ca thử, danh sách nhà thầu phụ, danh mục bàn giao nên được chốt cùng lúc với hợp đồng chính, không để “bổ sung sau”.

4. Ví dụ giả định

Một chuỗi bán lẻ ký hợp đồng xây chatbot chăm sóc khách hàng đọc dữ liệu đơn hàng và chính sách đổi trả. Tám tháng sau, nhà cung cấp mô hình thông báo ngừng phiên bản đang dùng. Vì hợp đồng có điều khoản thay đổi mô hình, đơn vị triển khai báo trước, chạy lại bộ ca thử trên phiên bản mới, phát hiện nhóm câu hỏi về điều kiện đổi trả có kết quả thấp hơn ngưỡng, chỉnh lại prompt và kho kiến thức, rồi mới chuyển. Chuỗi bán lẻ nhận báo cáo kết quả trước và sau.

Một năm sau, chuỗi quyết định chuyển vận hành về đội nội bộ. Nhờ danh mục bàn giao đã ghi rõ, đội nội bộ nhận được mã nguồn phần viết riêng, bản xuất kho kiến thức, bộ ca thử và danh sách tài khoản dịch vụ. Tài khoản của nhà cung cấp mô hình vốn đứng tên chuỗi bán lẻ từ đầu nên không cần chuyển. Nếu những điểm này không nằm trong hợp đồng, cả hai tình huống đều có thể biến thành đàm phán kéo dài.

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

• Cam kết chất lượng kiểu “trả lời chính xác” không có bộ ca thử và ngưỡng đo được
• Không nói gì về việc nhà cung cấp mô hình đổi phiên bản hay điều kiện sử dụng
• Tài khoản dịch vụ và dữ liệu nằm dưới tên nhà cung cấp, khó chuyển khi dừng
• Danh sách nhà thầu phụ không có hoặc không có nghĩa vụ báo khi thay đổi

Không có hợp đồng nào loại bỏ được rủi ro kỹ thuật. Hợp đồng chỉ phân định rõ khi rủi ro xảy ra thì ai làm gì. Cũng cần tránh viết quá chặt ở những chỗ bản chất không chắc chắn: một điều khoản phạt nặng cho mọi câu trả lời sai sẽ khiến nhà cung cấp thu hẹp phạm vi agent tới mức không còn hữu ích. Cân bằng hợp lý là cam kết theo ngưỡng trên bộ ca thử, cộng nghĩa vụ xử lý và báo cáo khi phát hiện lỗi.

6. Phân chia trách nhiệm

Khi đàm phán, bộ phận nghiệp vụ chịu trách nhiệm phạm vi, danh sách không bao gồm và bộ ca thử. Bộ phận công nghệ rà luồng dữ liệu, tích hợp, danh sách nhà thầu phụ và danh mục bàn giao. Pháp chế rà trách nhiệm, bảo vệ dữ liệu và điều khoản chấm dứt. Người ký cần biết hợp đồng đang chấp nhận những rủi ro nào, không chỉ biết giá.

Trong thời gian thực hiện, doanh nghiệp nên có một người theo dõi các nghĩa vụ định kỳ: báo cáo mức dịch vụ, thông báo thay đổi nhà thầu phụ, kết quả chạy lại bộ ca thử, hạn gia hạn. Khi hợp đồng có nhiều mốc như vậy, việc theo dõi có hệ thống sẽ đỡ hơn trông vào trí nhớ; cách làm được trình bày ở bài AI theo dõi nghĩa vụ hợp đồng.

7. Chỉ số nên theo dõi trong thời gian hợp đồng

• Tỷ lệ đạt trên bộ ca thử sau mỗi lần cập nhật mô hình hoặc kho kiến thức
• Số yêu cầu thay đổi phạm vi, thời gian xử lý và chi phí phát sinh
• Mức dịch vụ thực tế so với cam kết, tách phần do bên thứ ba
• Số thay đổi nhà thầu phụ hoặc hạ tầng được báo trước so với phát hiện sau

Những chỉ số này cho biết hợp đồng có đang được thực hiện đúng tinh thần hay không. Khi tỷ lệ đạt trên bộ ca thử giảm dần qua các lần cập nhật mà không ai báo, hoặc số yêu cầu thay đổi phạm vi tăng đều, đó là tín hiệu nên ngồi lại xem hợp đồng trước kỳ gia hạn.

8. Checklist trước khi ký

• Phạm vi mô tả bằng quy trình và hệ thống, có danh sách không bao gồm
• Quy trình thay đổi phạm vi có người duyệt và nguyên tắc tính chi phí
• Quyền sở hữu tách riêng cho dữ liệu, đầu ra, mã nguồn, cấu hình và bộ ca thử
• Danh sách nhà thầu phụ và nghĩa vụ báo trước khi thay đổi
• Điều khoản thay đổi mô hình có bước chạy lại bộ ca thử
• Danh mục bàn giao và điều kiện chấm dứt, rút dữ liệu, xác nhận xóa
• Pháp chế đã rà theo quy định hiện hành

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

Có mẫu hợp đồng AI Agent chuẩn để dùng luôn không? Không nên dùng nguyên một mẫu. Hợp đồng phải phản ánh luồng dữ liệu, hệ thống tích hợp và mức rủi ro của chính dự án. Mẫu chỉ hữu ích như danh sách nhắc việc; nội dung cụ thể cần pháp chế của doanh nghiệp rà theo quy định hiện hành.

Điều khoản nào hay bị bỏ sót nhất trong hợp đồng AI Agent? Điều khoản về thay đổi mô hình và điều khoản chấm dứt. Mô hình ngôn ngữ do bên thứ ba cung cấp có thể được cập nhật hoặc ngừng hỗ trợ, còn khi dừng hợp tác thì kho kiến thức, cấu hình và bộ ca thử thường không được nói rõ sẽ trả lại ra sao.

Doanh nghiệp có cần sở hữu mã nguồn của AI Agent không? Tùy mức phụ thuộc chấp nhận được. Nếu agent gắn sâu vào quy trình lõi, nên có ít nhất quyền sử dụng lâu dài, quyền nhận mã nguồn phần viết riêng và tài liệu đủ để đơn vị khác tiếp quản. Thành phần dùng chung của nhà cung cấp thường chỉ cấp quyền sử dụng.

Nên đưa bộ ca thử nghiệm thu vào hợp đồng không? Nên, dưới dạng phụ lục. Khi bộ ca thử và ngưỡng đạt được ghi sẵn, việc nghiệm thu và việc kiểm tra lại sau mỗi lần đổi mô hình có căn cứ chung, hai bên không phải tranh luận câu trả lời thế nào là đủ tốt.

Kết luận

Hợp đồng dịch vụ AI Agent tốt không phải hợp đồng dài nhất mà là hợp đồng trả lời được những câu hỏi sẽ xảy ra: phạm vi đổi thì sao, mô hình đổi thì sao, dữ liệu thuộc về ai, và khi dừng thì mang được gì về. Đọc hợp đồng theo vòng đời, diễn tập vài tình huống thay đổi và để pháp chế rà phần trách nhiệm là cách giảm tranh chấp hiệu quả hơn bất kỳ mẫu văn bản nào.

Trao đổi với Naventic để làm rõ phạm vi, dữ liệu và bàn giao trước khi ký. Đọc thêm: Dịch vụ.