Điều kiện chuyển đổi cần xác định trước khi ký hợp đồng dịch vụ AI

Hãy hình dung công ty đang chọn dịch vụ AI tạo sinh để hỗ trợ soạn tài liệu nội bộ và trình duyệt hợp đồng năm. Bản dùng thử tạo được văn bản đủ tốt, phí nằm trong ngân sách. Nhưng hồ sơ đề xuất không cho biết “nếu mô hình thay đổi thì ai kiểm thử?” hay “khi kết thúc hợp đồng có thể mang theo những gì?”.

Trước khi ký, cần xác định không chỉ hiệu năng hiện tại mà cả điều kiện chuyển sang dịch vụ khác. Bài viết khuyến nghị xác định trước những gì công ty sẽ tự quản lý trong số chỉ dẫn, cấu hình và ví dụ đầu vào đánh giá tích lũy trong nghiệp vụ. Sau đó, đưa một thử nghiệm chuyển đổi quy mô nhỏ vào điều kiện mua sắm.

Tách quyết định bắt đầu sử dụng khỏi quyết định tiếp tục

Cơ quan Kỹ thuật số Nhật Bản vận hành môi trường AI tạo sinh nội bộ “Gennai” từ tháng 5 năm 2025; việc mở rộng sang các bộ, ngành khác phân biệt thử nghiệm triển khai quy mô lớn trong năm tài khóa 2026 với sử dụng chính thức từ năm tài khóa 2027. [1] Điều đáng chú ý là cần tách việc cung cấp môi trường sử dụng khỏi việc xác định điều kiện dùng lâu dài. Ở doanh nghiệp tư nhân, chấp thuận dùng thử và chấp thuận hợp đồng dài hạn cũng nên là hai quyết định riêng.

Nếu cố định mô hình thì có cần chuẩn bị cho thay đổi không? Tài liệu chính thức của Microsoft cho biết các mô hình Foundry có các giai đoạn ngừng cung cấp; yêu cầu suy luận tới mô hình đã ngừng sẽ gặp lỗi. Tài liệu cũng nói mô hình kế nhiệm có thể không được cung cấp ở cùng khu vực. [3] Đây là đặc tả của dịch vụ Microsoft, không phải điều kiện áp dụng chung cho mọi sản phẩm AI tạo sinh.

Chính vì thế, đừng coi thời hạn hợp đồng và thời gian mô hình được cung cấp là một. Hãy xác nhận riêng theo từng lựa chọn, đồng thời quyết định nơi nhận thông báo kết thúc, người phụ trách quyết định trong công ty và thời điểm thử phương án thay thế.

Định nghĩa “có thể mang đi” theo từng loại tài sản

Việc đầu tiên nên làm không phải bảng so sánh chức năng sản phẩm mà là danh sách tài sản cần bàn giao khi di chuyển. Liệt kê chỉ dẫn, quy trình xử lý, tài liệu gốc được tham chiếu, định nghĩa thuật ngữ nghiệp vụ, định dạng đầu ra, ví dụ đầu vào đánh giá và tiêu chí chấm; ghi người quản lý và nơi lưu của từng mục. Không giả định có thể chuyển tất cả ra ngoài, mà đồng thời xác định phạm vi được phép chuyển.

Phiên bản 2.0 của hướng dẫn về mua sắm và sử dụng AI tạo sinh của Cơ quan Kỹ thuật số Nhật Bản đưa việc công khai thông tin phiên bản mô hình và thiết kế/triển khai có xét đến tính dễ chuyển đổi vào các mục cơ bản của phiếu kiểm tra mua sắm. Trong khi đó, chức năng xuất lịch sử trò chuyện và prompt đã đăng ký là mục cộng điểm tùy chọn. [2] Bài viết sử dụng các mục dành cho hành chính này làm tài liệu tham khảo khi xây dựng điều kiện mua sắm tư nhân.

Câu trả lời “có thể xuất dữ liệu” chưa đủ làm điều kiện bàn giao. Hãy chỉ định cụ thể dữ liệu nào, ở định dạng nào, đến khi nào và ai có thể xuất. Tùy mục đích, cũng cần quyết định có lưu mối liên hệ giữa tài liệu đính kèm và nguồn tham chiếu, ý nghĩa các giá trị cấu hình và dấu thời gian lịch sử hay không. Đừng để các mục không thuộc phạm vi xuất bị bỏ trống; yêu cầu nêu lý do loại trừ.

Ví dụ, với hệ thống tóm tắt đơn đăng ký, chỉ nhận lịch sử trò chuyện là chưa đủ để tái tạo cùng điều kiện ở nơi mới nếu không biết chỉ dẫn bổ sung theo từng phòng ban hoặc phiên bản tài liệu đã tham chiếu. Cần xác nhận thông tin đủ để tái cấu trúc nghiệp vụ, không chỉ đếm số tệp xuất ra.

Trước khi ký, tái tạo một nghiệp vụ trong môi trường khác

Đừng biến thử nghiệm chuyển đổi thành cuộc thi tái tạo mọi chức năng của dịch vụ ứng viên. Hãy chọn một nghiệp vụ và dựng lại quy trình trong môi trường khác từ tài sản nhận bàn giao. Qua đó, tìm ra cấu hình nào chỉ nhà cung cấp hiện tại biết.

Quy trình di chuyển mô hình của Microsoft cũng khuyên chuẩn bị đầu vào đại diện, đầu ra kỳ vọng và tiêu chí thành công trước khi chọn nơi chuyển đến, rồi giữ cố định chúng trong quá trình so sánh. [4] Đây là hướng dẫn cho việc chuyển mô hình trong cùng nhà cung cấp, nhưng cách tiếp cận cũng hữu ích cho thử nghiệm chuyển dịch vụ. Những điều dưới đây là đề xuất của bài viết khi áp dụng phương pháp ấy vào mua sắm.

Trước tiên, bộ phận sử dụng chọn không chỉ đầu vào thông thường mà cả ví dụ thiếu trường hoặc khác cách ghi. Tiếp theo, nhóm phát triển lấy cấu hình từ hệ thống nguồn và chuyển đổi sang dạng có thể dùng ở môi trường mới. Cuối cùng, người phụ trách nghiệp vụ đối chiếu với các điều kiện ban đầu. Có thể điều chỉnh chỉ dẫn theo từng mô hình, nhưng không thay đổi đầu vào chấm điểm hoặc điều kiện đạt.

Khi đánh giá, hãy ưu tiên nội dung thiết yếu có được giữ nguyên hay không, thay vì văn bản có giống nhau hay không. Ví dụ, với bản tóm tắt đơn đăng ký, điều kiện có thể là không bỏ sót số tiền, thời hạn và điểm chưa xác định. Ghi lại công sức điều chỉnh và thông tin không thể chuyển; ước tính phần việc còn lại trước khi chốt phạm vi hợp đồng.

Quyết định dùng tính năng riêng bằng cách so sánh cả chi phí chuyển đổi

Có ba lựa chọn. Một là dùng sâu các tính năng của một sản phẩm cụ thể. Nếu đánh giá rằng có thể kết hợp nhanh các tính năng cần thiết, đây là lựa chọn đáng cân nhắc. Tuy nhiên, hãy ước tính riêng chi phí làm lại thiết lập độc quyền, ngoài chi phí triển khai ban đầu.

Hai là giới hạn ở những chức năng chung giữa nhiều sản phẩm. Cách này giúp thống nhất đặc tả, nhưng có thể phải từ bỏ chức năng riêng muốn dùng. Bộ phận sử dụng cần quyết định có thể hy sinh bao nhiêu giá trị nghiệp vụ để đổi lấy khả năng chuyển đổi.

Ba là phương án bài viết khuyến nghị: để công ty tự quản lý chỉ dẫn và điều kiện đạt của nghiệp vụ, đồng thời tách riêng phần kết nối và cấu hình đặc thù sản phẩm. Mục tiêu không phải tương thích hoàn toàn mà là biết rõ phạm vi phải dựng lại. Tuy vậy, quản lý cấu hình hai nơi tạo gánh nặng bảo trì, nên cần so sánh chi phí với phương án giao hết cho một sản phẩm.

Ngoài phí sử dụng thường lệ, bảng so sánh nên tính cả xuất tài sản, chuyển đổi cấu hình, kiểm chứng lại, hướng dẫn người dùng và giai đoạn phải sử dụng song song. Chọn điều kiện kích hoạt chuyển đổi như mức giá tối đa có thể chấp nhận, ngừng cung cấp chức năng cần thiết hoặc không còn phù hợp với điều kiện sử dụng nội bộ, rồi chỉ định người phụ trách.

Tránh chuẩn bị quá mức và lấp khoảng trống trách nhiệm

Cách làm này không phù hợp với bản dùng thử ngắn hạn, khi không có tài sản nghiệp vụ nào cần lưu và không bàn giao đầu ra sau khi kết thúc. Không cần xây nền tảng chung hỗ trợ nhiều sản phẩm cho trường hợp như vậy. Chỉ cần xác nhận điều kiện lưu/xóa dữ liệu và xác định thời điểm kết thúc dùng thử.

Với nghiệp vụ dùng lâu dài, đừng giao toàn bộ trách nhiệm chuyển đổi cho bộ phận hệ thống thông tin. Có thể phân vai: mua sắm phụ trách phạm vi bàn giao và chi phí; bộ phận sử dụng xác định điều kiện đạt về nghiệp vụ; nhóm phát triển/vận hành chuyển đổi và dựng lại cấu hình. Hãy mời cả người phụ trách rà soát hợp đồng và ghi rõ đâu là bảo trì thông thường, đâu là công việc tính thêm.

Nếu áp dụng cách làm Forward Deployed Engineering (FDE), đồng hành với khách hàng từ khâu lập kế hoạch, thử nghiệm, triển khai đến ổn định, thì các hạn chế chuyển đổi phát hiện trong thử nghiệm cũng nên là sản phẩm bàn giao cho bên mua. Nếu chỉ ước tính sau khi đã quyết định chuyển đổi, phạm vi chi phí dùng để so sánh lúc chọn dịch vụ ban đầu đã quá hẹp.

Gợi ý cho thực tiễn

Đề xuất 1: Đính kèm danh sách tài sản cần bàn giao vào yêu cầu đề xuất. Hỏi rõ dữ liệu xuất, định dạng, nội dung không thuộc phạm vi, thời điểm cung cấp và người phụ trách.

Đề xuất 2: Đưa một thử nghiệm chuyển đổi nhỏ vào khâu thẩm định trước hợp đồng. Dựng lại một nghiệp vụ trong môi trường khác, xác định dữ liệu cần thiết bị thiếu và ước tính công sức điều chỉnh.

Đề xuất 3: Lưu lại lý do chọn tính năng độc quyền cùng điều kiện rời bỏ. Tôn trọng quyết định chọn sự tiện lợi, đồng thời chỉ rõ ai nhận thông báo thay đổi, ai quyết định ngân sách chuyển đổi và ai xác nhận nghiệp vụ.

Tài liệu tham khảo

1. Cơ quan Kỹ thuật số Nhật Bản “Government AI ‘Gennai’” (ngày đăng/cập nhật không rõ, ngày kiểm tra: 2026-09-21)
2. Cơ quan Kỹ thuật số Nhật Bản “Hướng dẫn về mua sắm và sử dụng AI tạo sinh nhằm thúc đẩy sự phát triển và đổi mới trong hành chính” (Phiên bản 2.0, cập nhật 2026-06-12, ngày kiểm tra: 2026-09-21)
3. Microsoft, “Microsoft Foundry Models lifecycle and support policy” (cập nhật 2026-07-24, ngày kiểm tra: 2026-09-21)
4. Microsoft, “Model migration process” (cập nhật 2026-08-19, ngày kiểm tra: 2026-09-21)

Bài viết này được thực hiện với sự hỗ trợ của AI và đã được rà soát tự động trước khi xuất bản. Ngày kiểm tra thông tin: 2026-09-21.