Chọn công ty phát triển AI 2026 — hợp đồng, phạm vi và cách đọc báo giá

Tìm “nên chọn công ty phát triển AI nào”, bạn sẽ gặp hàng loạt bài so sánh 25 hay 50 nhà cung cấp. Nhưng dự án được chọn theo danh sách vẫn thường dừng ở PoC, gây tranh cãi lúc nghiệm thu, hoặc để mất quyền đối với mô hình. Thành bại không nằm ở bảng so sánh, mà ở loại hợp đồng, cách chia giai đoạn, điều kiện nghiệm thu và quyền sở hữu. Bài viết sắp xếp lại thứ tự cần quyết trước khi đặt hàng, cho doanh nghiệp sản xuất Nhật Bản tại Việt Nam và ASEAN.

Vì sao phát triển AI khó cam kết “hoàn thành”

Các bài so sánh dạng danh sách đều ngầm đặt ra một giả định: “chọn được công ty tốt thì thứ mình đặt hàng sẽ hoàn thành”. Với phát triển hệ thống truyền thống, giả định này về cơ bản đúng. Làm xong đủ các màn hình và chức năng ghi trong đặc tả là xong. Nhưng với dự án có mô hình AI, giả định đó sụp đổ về mặt cấu trúc.

Bản “Danh mục kiểm tra hợp đồng về sử dụng và phát triển AI” do Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản (METI) công bố ngày 18 tháng 2 năm 2025 diễn giải vấn đề hiệu năng và độ chính xác như sau: vì mô hình AI được phát triển bằng phương pháp quy nạp dựa trên dữ liệu huấn luyện, nên bản thân dữ liệu huấn luyện có thể đã chứa sẵn giới hạn về độ chính xác. Hệ quả là rất khó thiết lập nghĩa vụ hoàn thành và bảo đảm hiệu năng.

Đây không phải chuyện “nhà cung cấp kém nên không làm xong được”. Đây là chuyện: không ai — dù kỹ sư giỏi đến đâu — khai thác được nhiều thông tin hơn lượng thông tin mà dữ liệu đang có. Đặt vào bối cảnh nhà máy sẽ dễ hiểu hơn. Nếu hồ sơ kiểm tra ba năm qua chỉ ghi vỏn vẹn “lỗi”, không ghi chủng loại lỗi, công đoạn phát sinh, người thao tác, điều kiện môi trường, thì từ dữ liệu đó không thể dựng được mô hình đoán “lỗi xuất hiện trong điều kiện nào”. Và điều đó chỉ lộ ra sau vài tuần bắt tay vào làm việc trực tiếp với dữ liệu.

Chính vì vậy, việc đầu tiên bên đặt hàng cần làm không phải là “đi tìm công ty tốt”, mà là quyết định: giả định rằng dự án có thể không hoàn thành, thì trả tiền tới đâu và dừng lại được ở đâu.

Trước hết hãy xác định dự án của bạn thuộc loại nào

Cũng trong bản danh mục kiểm tra đó, hợp đồng ứng dụng AI được chia thành ba loại tình huống sử dụng. Dự án của bạn rơi vào loại nào sẽ quyết định những điểm phải làm rõ, thậm chí quyết định cả việc có cần hợp đồng riêng hay không.

Danh mục kiểm tra được định vị là “tài liệu chỉ ra vị trí các vấn đề cần cân nhắc khi ký hợp đồng liên quan đến ứng dụng AI”, gồm 14 mục liên quan đến đầu vào và 14 mục liên quan đến đầu ra. Nhóm đầu vào gồm định nghĩa dữ liệu mà người dùng giao cho nhà cung cấp, mục đích sử dụng, điều kiện sử dụng, cơ chế quản lý, thời hạn lưu giữ và việc xóa. Nhóm đầu ra gồm nghĩa vụ hoàn thành, điều kiện cung cấp, mục đích sử dụng, điều kiện sử dụng, quản lý bảo mật.

Việc đầu tiên bên đặt hàng nên làm ở đây là áp 28 mục này vào dự án của mình và liệt kê ra những mục mà chính mình chưa có câu trả lời. Làm việc này trước khi gặp công ty phát triển AI sẽ thay đổi hẳn chất lượng buổi thương thảo. Vì những câu hỏi kiểu “bên bạn có dự định dùng dữ liệu của chúng tôi cho dự án khác không?”, “việc xóa dữ liệu thực hiện khi nào, theo thủ tục gì?” sẽ đến từ một danh sách bao quát chứ không phải từ ý nghĩ chợt nảy ra.

Việc xác định ba loại này cũng gắn trực tiếp với ranh giới tự làm và thuê ngoài: phần nào giữ trong nội bộ, phần nào đưa ra ngoài. Cách chia trách nhiệm theo từng tầng được trình bày chi tiết trong bài viết về hỗ trợ tự phát triển AI nội bộ, bạn có thể tham khảo thêm.

Mô hình phát triển theo giai đoạn mang tính thăm dò — chia hợp đồng thành 4 giai đoạn

Nếu “khó cam kết hoàn thành”, thì phải đặt hàng thế nào? Câu trả lời chính thức từ phía nhà nước Nhật Bản nằm trong “Hướng dẫn hợp đồng về sử dụng AI và dữ liệu” của METI, công bố tháng 6 năm 2018 và sửa đổi một phần tháng 12 năm 2019. Phần về AI của hướng dẫn này đề xuất phương thức phát triển gọi là mô hình theo giai đoạn mang tính thăm dò.

Ý tưởng rất đơn giản. Không ký trọn gói toàn bộ ngay từ đầu, mà chia quá trình phát triển thành nhiều giai đoạn và ký lại hợp đồng cho từng giai đoạn. Cuối mỗi giai đoạn, quyết định “đi tiếp hay dừng tại đây”. Hướng dẫn nêu bốn giai đoạn: giai đoạn đánh giá / giai đoạn PoC / giai đoạn phát triển / giai đoạn huấn luyện bổ sung. Trong bảng dưới đây, tên giai đoạn là theo hướng dẫn, còn hai cột “làm gì” và “bên đặt hàng nhận được gì” là cách sắp xếp của người viết dựa trên hiểu biết thực tiễn phổ biến.

Hướng dẫn nêu phương thức hợp đồng, yếu tố cần cân nhắc và ví dụ điều khoản cho từng giai đoạn. Đồng thời, xuất phát từ việc bản thân mô hình AI được phát triển bằng phương pháp quy nạp phụ thuộc vào dữ liệu, hướng dẫn nhận định rằng hợp đồng ủy thác công việc theo nghĩa vụ cẩn trọng phù hợp hơn với loại việc này.

Ý nghĩa thật sự của việc chia giai đoạn là “tạo ra chỗ để dừng”

Nghe “chia giai đoạn”, nhiều người tưởng đó là chuyện cách triển khai. Nhưng lợi ích thực tế với bên đặt hàng không nằm ở đó. Bản chất là tạo ra những điểm mà về mặt hợp đồng bạn có quyền dừng một cách chính đáng.

Khi chạy dự án bằng một hợp đồng trọn gói, giữa chừng dù nhận ra “có vẻ khó rồi” thì vẫn không dừng được vì hợp đồng còn hiệu lực. Dừng thì thành chuyện vi phạm hợp đồng, còn đi tiếp thì cứ đổ tiền vào chỗ không có triển vọng. Đó chính là thực chất của tình trạng “dừng ở PoC mà không hiểu sao chi phí vẫn chạy”. Với hợp đồng theo giai đoạn, nếu cuối giai đoạn đánh giá có kết luận “với dữ liệu hiện tại thì việc này khó”, bạn trả tiền của giai đoạn đó và kết thúc. Giá trị nằm ở chỗ “kết thúc được”.

Có một điểm cần nhấn mạnh. Khi giai đoạn đánh giá cho kết luận “khó”, đó không phải là thất bại. Xét ở góc độ chỉ mất chi phí giai đoạn khảo sát mà tránh được một quyết định đầu tư lớn, đó là thành công. Nếu trong nội bộ bên đặt hàng hình thành bầu không khí “PoC bắt buộc phải thành công”, hiện trường sẽ tìm cách kéo dài sự sống cho những dự án vô vọng. Khi áp dụng hợp đồng theo giai đoạn, hãy thiết kế đồng thời cả hợp đồng lẫn cách đánh giá nội bộ.

Viết “điều kiện khởi đầu” và “điều kiện kết thúc” cho từng giai đoạn

Chia giai đoạn thôi chưa đủ. Với mỗi giai đoạn, hãy ghi vào hợp đồng hoặc thỏa thuận riêng cả điều kiện khởi đầu (điều kiện để được bắt đầu giai đoạn này) và điều kiện kết thúc (điều kiện để coi là đã hoàn tất giai đoạn này).

Ví dụ, điều kiện khởi đầu của giai đoạn PoC có thể viết là “báo cáo giai đoạn đánh giá xác định rằng dữ liệu đối tượng có chứa đủ thông tin để phân biệt”, còn điều kiện kết thúc là “chỉ số nghiệp vụ trên bộ dữ liệu kiểm chứng đạt mức nêu tại phụ lục, hoặc nếu không đạt thì phải nộp báo cáo phân tích nguyên nhân”. Mẹo ở đây là đưa cả sản phẩm bàn giao trong trường hợp không đạt vào điều kiện kết thúc. Thiếu điều này, khi một giai đoạn không suôn sẻ bạn sẽ chẳng còn lại gì trong tay.

Khoán việc hay ủy thác công việc — phương án dung hòa “ủy thác gắn với kết quả hoàn thành”

Chia giai đoạn xong, bước tiếp theo là ký mỗi giai đoạn theo loại hợp đồng nào. IP BASE của Cục Sáng chế Nhật Bản sắp xếp các loại hợp đồng phát triển AI như sau. Cần lưu ý ngay: cả hai loại dưới đây đều là loại hợp đồng đặc thù của pháp luật Nhật Bản, không phải khái niệm dùng chung cho mọi hệ thống pháp luật, nên phần này được viết theo hướng mô tả để bạn hiểu logic đằng sau.

Khác biệt này rất lớn, và nếu để mập mờ mà cứ đi tiếp thì đó là mầm mống rắc rối. Bên đặt hàng nghĩ “đã đặt hàng thì phải xong”, nhà cung cấp nghĩ “tôi đã giải thích rằng độ chính xác còn tùy dữ liệu”. Sự lệch pha nhận thức giữa hai bên chỉ lộ ra lần đầu tại buổi nghiệm thu.

Hai biến thể của hợp đồng ủy thác công việc

Loại ủy thác công việc còn chia tiếp thành hai biến thể.

• Loại theo tỷ lệ thực hiện: nghĩa vụ thanh toán thù lao phát sinh khi bên nhận đã thực hiện công việc được ủy thác
• Loại gắn với kết quả hoàn thành: nghĩa vụ thanh toán thù lao phát sinh khi bàn giao kết quả

Loại theo tỷ lệ thực hiện, nói nôm na, là “làm bao nhiêu trả bấy nhiêu”. Nó hợp với những công việc mang tính thăm dò như giai đoạn đánh giá hay giai đoạn PoC, khi ngay từ đầu chưa biết sẽ ra được cái gì. Ngược lại, với bên đặt hàng thì đây là “không ra được kết quả nào cũng vẫn phải trả”, nên số tiền càng lớn thì càng khó giải trình nội bộ.

Loại gắn với kết quả hoàn thành là hình thức mà nghĩa vụ thanh toán chỉ phát sinh khi có việc bàn giao kết quả đã được định nghĩa trước. Bên đặt hàng dễ giải trình nội bộ hơn vì có thể diễn giải “không bàn giao gì thì không trả”, nhưng điểm không thay đổi là nhà cung cấp vẫn không gánh nghĩa vụ hoàn thành. Do đó, có định nghĩa được bằng văn bản thế nào là “kết quả” hay không chính là ranh giới quyết định bạn có chọn được loại này hay không. Nếu định nghĩa được thì loại này có lợi cho bên đặt hàng; nhưng nếu chọn loại gắn với kết quả trong khi định nghĩa còn mơ hồ, tranh chấp về việc đã bàn giao hay chưa sẽ còn nghiêm trọng hơn cả loại theo tỷ lệ thực hiện.

Hãy vào bàn đàm phán với giả định: nhà cung cấp có xu hướng tránh khoán việc

Do độ chính xác của AI phụ thuộc vào dữ liệu huấn luyện, nhà cung cấp có xu hướng tránh loại hợp đồng khoán việc. Đây không phải vì họ thiếu thiện chí, mà vì lý do mang tính cấu trúc đã nêu ở chương 1: họ không thể gánh nghĩa vụ hoàn thành. Bước vào đàm phán mà không biết tiền đề này, bạn sẽ rơi vào lập luận lệch trọng tâm kiểu “không chịu ký khoán việc thì không đáng tin”.

Phương án dung hòa được đề xuất là “hợp đồng ủy thác công việc theo nghĩa vụ cẩn trọng, loại gắn với kết quả hoàn thành“. Đây là hình thức trung gian: không gánh nghĩa vụ hoàn thành, nhưng thù lao phát sinh đổi lấy việc bàn giao kết quả đã thỏa thuận. Tuy nhiên, khi chọn hình thức này thì việc trao đổi với chuyên gia về định nghĩa “hoàn thành” được xem là bắt buộc. Và đây chính là chỗ nối với trọng tâm của bài viết. Nếu không viết trọn được thế nào là bàn giao kết quả — tức là điều kiện nghiệm thu — thì loại gắn với kết quả hoàn thành sẽ không vận hành được.

Cách ghép giai đoạn với loại hợp đồng (sắp xếp về mặt tư duy)

Phần dưới đây là cách sắp xếp dựa trên tinh thần của hướng dẫn, không bảo đảm tính hợp pháp hay tính phù hợp cho từng dự án cụ thể.

Với ③ giai đoạn phát triển, sẽ dễ thiết kế hơn nếu bạn tách riêng phần mô hình AI và phần hệ thống xung quanh. Màn hình, quản lý phân quyền, kết nối với hệ thống hiện có, xuất biểu mẫu báo cáo là những phần chốt được đặc tả, nên có dư địa tách ra thành hợp đồng khoán việc kiểu truyền thống. Ngược lại, phần mô hình giữ ở dạng ủy thác công việc. Nếu bạn nói rõ cách phân tách này ngay khi gửi yêu cầu báo giá, chất lượng đề xuất nhận được sẽ cao hơn.

Xin lưu ý, chương này là sắp xếp chung về các loại hợp đồng, không phải tư vấn pháp lý. Khi thực sự soạn thảo và ký hợp đồng, hãy luôn xác nhận với luật sư hoặc chuyên gia. Đặc biệt khi chủ thể hợp đồng là pháp nhân tại nước sở tại, luật áp dụng, thẩm quyền tài phán và cách xử lý theo pháp luật nước đó chưa chắc trùng khớp với cách sắp xếp theo luật Nhật Bản.

Đọc báo giá bằng cách phân tách thành 5 tầng

Khi đã thiết kế được đến đây, cách bạn đọc báo giá sẽ khác. Một câu hỏi rất hay gặp là “chi phí phát triển AI mặt bằng chung là bao nhiêu”, nhưng bài viết này không nêu khoảng giá. Lý do: phần lớn thông tin giá đang công khai đều xuất phát từ kênh truyền thông của chính các công ty phát triển AI và không công bố căn cứ tính toán. Lấy những con số không rõ căn cứ làm cơ sở phán đoán thì lại càng dẫn tới quyết định nguy hiểm.

Thay vào đó, bài viết đề xuất một quy trình: phân tách báo giá thành 5 tầng, rồi tự bên đặt hàng đối chiếu xem mỗi tầng ứng với dòng nào trong báo giá. Không cần biết mặt bằng giá, bạn vẫn tự phát hiện được tầng nào đang bị thiếu.

Năm tầng

“Báo giá rẻ” phần lớn là do thiếu ④ và ⑤

Lấy báo giá từ nhiều công ty, bạn sẽ thấy chênh lệch lớn về số tiền. Kết luận “bên rẻ hơn là bên có tâm” lúc này là vội vàng. Nhìn về mặt cấu trúc, nguyên nhân chính tạo ra chênh lệch không phải trình độ kỹ thuật hay đơn giá, mà là chênh lệch phạm vi: ④ kết nối hệ thống hiện có và thiết kế phân quyền, ⑤ vận hành và huấn luyện lại có nằm trong phạm vi báo giá hay không.

Vì sao hai tầng này dễ rơi rụng? Tầng ④ cần nhìn vào bên trong hệ thống hiện có của bên đặt hàng mới ước lượng được khối lượng công việc, nên ở giai đoạn đề xuất thường bị ghi là “báo giá riêng”. Tầng ⑤ là chuyện sau khi chạy thật, nên tự nhiên bị đẩy ra khỏi cuộc thảo luận về đầu tư ban đầu. Nhưng khi dùng AI trong nhà máy, không có ④ thì mô hình không chạm được tới nghiệp vụ, còn không có ⑤ thì nửa năm sau khi độ chính xác tụt xuống sẽ không ai sửa được.

Thí nghiệm tư duy: thiếu tầng thì báo giá trông rẻ đi bao nhiêu

Phần dưới đây là thí nghiệm tư duy với các giá trị giả định, không phải dữ liệu thực tế và cũng không phải mặt bằng giá. Đây là ví dụ để bạn thay bằng số liệu dự án của mình rồi tự kiểm tra lại.

Các giá trị giả định (tất cả đều là giả định):

Tính toán:

• Khối lượng xây dựng ban đầu bao gồm đủ ①–④: 10 + 25 + 30 + 20 = 85 người-ngày
• Khối lượng ghi trên báo giá khi thiếu ④: 10 + 25 + 30 = 65 người-ngày
• Tỷ lệ rẻ đi trên bề mặt: (85 − 65) ÷ 85 = 20 ÷ 85 ≈ 0,235 → trông rẻ hơn khoảng 23,5%
• Tổng khối lượng 3 năm (①–④ cộng ⑤ trong 3 năm): 85 + 12 × 3 = 85 + 36 = 121 người-ngày
• Tỷ trọng của báo giá thiếu ④⑤ (65 người-ngày) trong tổng khối lượng 3 năm: 65 ÷ 121 ≈ 0,537 → khoảng 53,7%

Nghĩa là, với các giả định này, một báo giá thiếu ④ và ⑤ chỉ phản ánh khoảng một nửa khối lượng công việc thực sự cần trong 3 năm. Khi đặt cạnh nhau hai báo giá — công ty A 65 người-ngày và công ty B 85 người-ngày — bạn phải kiểm tra trước khả năng: không phải B đắt, mà chỉ là A không tính tầng ④.

Xin nhắc lại, các con số người-ngày ở trên là giá trị giả định đặt ra để minh họa. Giá trị thực tế thay đổi rất nhiều tùy nghiệp vụ đối tượng, tình trạng dữ liệu và số lượng hệ thống cần kết nối. Điều quan trọng không phải bản thân các con số, mà là thao tác tự tay đối chiếu xem trong 5 tầng, tầng nào không có dòng tương ứng trong báo giá của bạn.

Quy trình đối chiếu trong thực tế

1. Gắn nhãn mọi dòng của báo giá vào một trong 5 tầng ở trên (nếu có dòng không thuộc tầng nào, hãy hỏi lại nội dung)
2. Liệt kê những tầng không được gán dòng nào
3. Với các tầng bị bỏ trống, hỏi bằng văn bản: “nằm ngoài phạm vi, miễn phí, hay vốn chưa được tính đến?”
4. Với các tầng được trả lời là “báo giá riêng”, hãy chốt trước các điều kiện tiền đề của ước tính sơ bộ (số hệ thống cần kết nối, số giao diện dự kiến, khung giờ vận hành dự kiến…)
5. Quy đổi về tổng chi phí 3 năm rồi trình phê duyệt nội bộ

Nếu muốn nâng độ chính xác của báo giá cho tầng ④, việc sắp xếp trước cấu hình phía hệ thống hiện có sẽ rất hiệu quả. Quy trình kiểm tra chung khi chọn công ty phát triển hệ thống tại Thái Lan được tổng hợp trong bài viết về cách chọn công ty phát triển hệ thống tại Thái Lan. Ngoài ra, không giải thích được hiệu quả của tầng ⑤ thì hồ sơ phê duyệt cho 3 năm sẽ không qua, nên hãy đọc trước bài viết về đo lường hiệu quả và ROI khi triển khai AI để nắm cách đo hiệu quả.

Thiết kế điều kiện nghiệm thu — đừng nhận bàn giao với “độ chính xác 99%”

Sau khi chốt loại hợp đồng và soát đủ các tầng báo giá, bước tiếp theo là điều kiện nghiệm thu. Theo chúng tôi, đây là chương có ảnh hưởng thực tiễn lớn nhất trong bài.

Khi hồ sơ đề xuất ghi “độ chính xác 99%”, câu hỏi đầu tiên bên đặt hàng nên đặt ra không phải “có thật không”, mà là “mẫu số của 99% đó là gì?”.

Mẫu số đổi thì khối lượng kiểm tra cần thiết cũng đổi

Hãy lấy ví dụ một dự án dùng AI đọc chứng từ. “Độ chính xác 99%” có ít nhất ba cách hiểu.

Cùng là “99%”, nhưng mẫu số khác nhau thì số lượng phải kiểm tra bằng tay chênh nhau cả một bậc độ lớn. Vấn đề là thông thường hồ sơ đề xuất không ghi mẫu số.

Thí nghiệm tư duy: mẫu số khác nhau thì công sức kiểm tra thủ công thay đổi ra sao

Phần dưới đây là thí nghiệm tư duy với các giá trị giả định, không phải dữ liệu thực tế. Chúng tôi cũng đơn giản hóa bằng giả định rằng lỗi phát sinh độc lập giữa các trường (trên chứng từ thực tế, lỗi thường tập trung vào một số trường hoặc một số loại chứng từ nhất định, nên giả định đơn giản hóa này không khớp với thực tế).

Các giá trị giả định (tất cả đều là giả định):

Trường hợp A (theo trường, 99%)

• Tổng số trường trong tháng: 1.000 tờ × 20 trường = 20.000 trường
• Kỳ vọng số trường bị lỗi: 20.000 × 1% = 200 trường
• Xác suất cả 20 trường của một chứng từ đều đúng: 0,99 mũ 20 ≈ 0,8179 (khoảng 81,8%)
• Tỷ lệ chứng từ có ít nhất một trường bị lỗi: 1 − 0,8179 = 0,1821 (khoảng 18,2%)
• Số chứng từ cần kiểm tra thủ công: 1.000 tờ × 18,2% ≈ 182 tờ/tháng
• Khối lượng kiểm tra: 182 tờ × 3 phút = 546 phút ≈ 9,1 giờ/tháng

Trường hợp B (theo trường, 99,9%)

• Kỳ vọng số trường bị lỗi: 20.000 × 0,1% = 20 trường
• Xác suất cả 20 trường của một chứng từ đều đúng: 0,999 mũ 20 ≈ 0,9802 (khoảng 98,0%)
• Tỷ lệ chứng từ có ít nhất một trường bị lỗi: 1 − 0,9802 = 0,0198 (khoảng 2,0%)
• Số chứng từ cần kiểm tra thủ công: 1.000 tờ × 2,0% ≈ 20 tờ/tháng
• Khối lượng kiểm tra: 20 tờ × 3 phút = 60 phút = 1,0 giờ/tháng

Xét theo từng trường, “99%” và “99,9%” chỉ chênh nhau 0,9 điểm phần trăm. Nhưng với các giả định này, số chứng từ phải kiểm tra thủ công là 182 tờ so với 20 tờ, khối lượng kiểm tra là 9,1 giờ so với 1,0 giờ, tức chênh khoảng 9 lần. Nếu mỗi chứng từ có 40 trường thay vì 20, vẫn với phép tính đó, số chứng từ cần kiểm tra là khoảng 331 tờ và khoảng 39 tờ, bản thân khoảng cách về số tờ giãn từ 162 tờ lên 292 tờ (còn tỷ lệ thì co lại nhẹ, từ khoảng 9,1 lần xuống khoảng 8,4 lần). Hãy hiểu rằng chứng từ càng nhiều trường thì việc nhầm mẫu số càng đổ thẳng gánh nặng xuống hiện trường.

Hàm ý của phép tính này rất rõ: không được chỉ ghi “độ chính xác 99%” vào hợp đồng. Một chỉ số độ chính xác không kèm mẫu số chắc chắn sẽ dẫn tới cách hiểu khác nhau giữa hai bên tại buổi nghiệm thu.

Chỉ tiêu nghiệm thu nên viết bằng chỉ số nghiệp vụ, không phải “đọc được hay không”

Cách viết chúng tôi khuyến nghị là định nghĩa điều kiện nghiệm thu bằng chỉ số nghiệp vụ thay vì chỉ số hiệu năng của AI.

Có ba điểm mấu chốt. Thứ nhất, cố định bộ dữ liệu nghiệm thu bằng phụ lục. Tổng thể thay đổi thì con số cũng thay đổi. Thứ hai, đặt trọng số theo từng trường. Sai ở mã hàng hay số tiền và sai ở ô ghi chú gây tác động nghiệp vụ hoàn toàn khác nhau. Thứ ba, viết bằng khối lượng công việc còn lại. Chỉ số thật sự có ý nghĩa với bên đặt hàng không phải “tỷ lệ đọc được” mà là “số việc con người vẫn phải đụng tay”.

Về cách làm rõ mẫu số của độ chính xác, bài so sánh AI-OCR đi sâu hơn, kèm cách nhìn theo từng sản phẩm. Đọc trước khi soạn điều kiện nghiệm thu sẽ giúp câu hỏi của bạn sắc nét hơn.

Viết trước cả cách xử lý khi không đạt nghiệm thu

Một điểm nữa hay bị quên là cách xử lý khi không đáp ứng tiêu chí nghiệm thu. Hãy ghi những điều sau vào hợp đồng hoặc thỏa thuận riêng.

• Số lần và thời hạn được làm lại (miễn phí cải thiện tối đa bao nhiêu lần, trong bao nhiêu tuần)
• Biện pháp khi làm lại vẫn không đạt (giảm giá, kết thúc tại giai đoạn đó, không đi tiếp sang giai đoạn sau)
• Những gì được bàn giao cho bên đặt hàng tại thời điểm đó (sản phẩm trung gian, dữ liệu, tài liệu, cách xử lý mô hình đã huấn luyện)
• Thủ tục xóa dữ liệu do bên đặt hàng cung cấp và bằng chứng đã xóa

Mục thứ ba đặc biệt quan trọng. Ngay cả khi không đi tới nghiệm thu, nếu dữ liệu đã được chuẩn hóa và kết quả gán nhãn còn lại trong tay bạn, chúng sẽ là điểm xuất phát cho lần thử tiếp theo. Ngược lại, quên viết chỗ này thì bạn sẽ nhận kết cục tệ nhất: trả tiền rồi mà chẳng còn lại gì.

Quyền sở hữu — mô hình đã huấn luyện rốt cuộc là của ai

Ngang với điều kiện nghiệm thu về mức độ dễ gây tranh cãi là quyền sở hữu. Danh mục kiểm tra hợp đồng của METI yêu cầu phân biệt IP hình thành mới (foreground IP — thành quả phát triển mới) và IP có sẵn (background IP — tài sản đã có) và làm rõ từ trước.

IP hình thành mới và IP có sẵn

• IP có sẵn (background IP): tài sản mỗi bên đã có từ trước khi ký hợp đồng. Phía nhà cung cấp là thư viện sẵn có, mô hình phổ dụng, khung phát triển nội bộ. Phía đặt hàng là dữ liệu nghiệp vụ, hệ thống hiện có, bí quyết của mình.
• IP hình thành mới (foreground IP): thành quả được tạo ra mới theo hợp đồng này.

Chỗ rắc rối trong thực tế là khi hai loại trộn vào nhau. Mô hình đã huấn luyện — tạo ra bằng cách huấn luyện bổ sung mô hình phổ dụng của nhà cung cấp trên dữ liệu hiện trường của bạn — là tài sản của bên nào? Nếu hợp đồng không có câu trả lời cho câu hỏi này, thì đến lúc bạn muốn đổi nhà cung cấp sau khi chạy thật, hoặc muốn nhân rộng sang nhà máy khác trong tập đoàn, mọi thứ chắc chắn sẽ tắc.

Bốn đối tượng cần tách riêng để bàn

Khi bàn về quyền sở hữu, đừng gom chung thành “mô hình AI”, mà hãy tách thành bốn đối tượng sau.

Danh mục kiểm tra nêu rằng trong hợp đồng loại phát triển, cần quy định rõ phạm vi cho phép và điều kiện cụ thể để nhà cung cấp sử dụng đầu vào. Nói ngược lại: không viết gì thì phạm vi sẽ cứ mập mờ mà dự án vẫn chạy tiếp.

Một câu bắt buộc phải xác nhận trong hợp đồng

Có một điểm chúng tôi mong mọi doanh nghiệp sản xuất Nhật Bản đều xác nhận.

Bạn có cho phép nhà cung cấp dùng lại mô hình đã huấn luyện trên dữ liệu hiện trường của bạn (và các mô hình phái sinh của nó) cho dự án của công ty khác không? Nếu có, điều kiện là gì?

Nhiều công ty phát triển AI coi việc tích lũy tri thức mang tính phổ dụng là một phần mô hình kinh doanh. Bản thân điều đó không xấu. Vấn đề là có thể phát sinh tình trạng: bên đặt hàng tưởng rằng “mình đã có mô hình riêng”, trong khi về mặt hợp đồng nhà cung cấp hoàn toàn được phép cung cấp chính mô hình đó cho đối thủ cùng ngành. Ở ASEAN, nơi đối thủ cạnh tranh có thể nằm ngay trong cùng một khu công nghiệp, khác biệt này không thể xem nhẹ về mặt kinh doanh.

Về cách viết, bạn có các lựa chọn sau.

1. Cấm hoàn toàn: cấm cung cấp cho bên thứ ba dữ liệu của dự án cũng như mô hình đã huấn luyện và mô hình phái sinh bắt nguồn từ dữ liệu đó
2. Cho phép trừ cùng ngành: chỉ cấm cung cấp cho một số ngành nhất định hoặc danh sách đối thủ cụ thể
3. Độc quyền có thời hạn: độc quyền trong ◯ năm sau khi vận hành, sau đó chuyển sang không độc quyền
4. Chỉ cho phép tri thức đã trừu tượng hóa: không phải dữ liệu hay tham số cụ thể, mà chấp nhận việc tái sử dụng phương pháp và bí quyết đã khái quát hóa

Phương án 1 an toàn nhất nhưng có thể làm báo giá của nhà cung cấp tăng lên. Phương án 3 và 4 thường là điểm dung hòa thực tế. Dù chọn cách nào, chúng tôi khuyến nghị đưa vấn đề này ra ngay từ giai đoạn hồ sơ yêu cầu đề xuất (RFP). Nêu ra sát lúc ký hợp đồng sẽ dẫn tới đàm phán lại về giá và tiến độ.

Viết cụ thể cả hình thức bàn giao

Ghi “mô hình thuộc về bên đặt hàng” là chưa đủ nếu không rõ thực tế bạn được giao những gì.

• Định dạng tệp và phiên bản của mô hình đã huấn luyện
• Script dùng để huấn luyện, mã tiền xử lý, cấu hình siêu tham số
• Tài liệu đủ để chính công ty bạn hoặc bên thứ ba thực hiện được việc huấn luyện lại
• Các thư viện phụ thuộc và giấy phép của chúng (bao gồm ràng buộc của giấy phép nguồn mở)
• Đặc tả môi trường thực thi cần thiết để chạy suy luận

Nếu bạn tính tới việc tự làm nội bộ hoặc chuyển giao cho bên thứ ba trong tương lai, cần viết đủ tới mức này. Về cách thiết kế tầng kết nối dữ liệu nội bộ, bài viết về xây dựng RAG cũng sẽ hữu ích.

Chủ thể hợp đồng đặt ở đâu — những điều phải quyết thêm (ví dụ cụ thể từ Thái Lan)

Từ đây là những vấn đề riêng của các doanh nghiệp Nhật Bản vận hành sản xuất ngoài lãnh thổ Nhật Bản. Nguyên tắc chung rất đơn giản: cùng một dự án phát triển AI, nhưng đặt chủ thể hợp đồng ở đâu thì cách xử lý thuế và pháp lý sẽ theo quy định của quốc gia đó. Bạn ký bằng trụ sở Nhật Bản, bằng pháp nhân tại Việt Nam, hay bằng pháp nhân tại một nước ASEAN khác — mỗi lựa chọn kéo theo một bộ nghĩa vụ khai báo khác nhau.

Để nguyên tắc chung này không dừng ở mức trừu tượng, phần dưới đây lấy Thái Lan làm ví dụ cụ thể, vì đó là nơi TOMAS TECH đặt trụ sở và là thị trường chúng tôi nắm rõ nhất. Mọi con số trong phần này là quy định của Thái Lan, không áp dụng cho Việt Nam. Với các giao dịch mà chủ thể hợp đồng là pháp nhân tại Việt Nam, hãy đối chiếu với quy định hiện hành của Việt Nam và xác nhận với chuyên gia thuế sở tại — bài viết này không nêu thuế suất của Việt Nam. Điều đáng học ở đây là *cấu trúc của những câu hỏi cần đặt ra*, chứ không phải các con số.

Đứng tên hợp đồng là trụ sở Nhật Bản hay pháp nhân tại nước sở tại

Đây là cửa vào của mọi quyết định sau đó. Trụ sở Nhật Bản đứng tên thì dễ khép kín trong luật và thuế Nhật Bản, nhưng người thực sự dùng hệ thống lại là nhà máy tại nước sở tại. Pháp nhân tại nước sở tại ký thì chạy được bằng ngân sách và thẩm quyền phê duyệt tại chỗ, nhưng sẽ áp dụng chế độ thuế của nước đó. Theo thông tin của JETRO, tại Thái Lan thuế thu nhập doanh nghiệp về nguyên tắc được ấn định vĩnh viễn ở mức 20% kể từ năm tài chính bắt đầu từ ngày 1 tháng 1 năm 2016, và thuế giá trị gia tăng (VAT) hiện ở mức 7% (thuế suất nguyên tắc theo luật là 10% nhưng đã được hạ xuống 7% bằng nghị định hoàng gia).

Trường hợp đặt hàng nhà cung cấp trong nước sở tại (số liệu Thái Lan)

Phí dịch vụ trả cho nhà cung cấp dịch vụ trong lãnh thổ Thái Lan chịu thuế khấu trừ tại nguồn (WHT). Khi doanh nghiệp thông thường chi trả, thuế suất là 3% (5% nếu người nhận là chi nhánh không thường trực của doanh nghiệp nước ngoài). Tờ khai cho khoản chi trả tới pháp nhân là PND53, phải khai và nộp thuế chậm nhất là ngày 7 của tháng kế tiếp tháng chi trả.

Một chế độ đáng chú ý nữa là thuế suất ưu đãi 1% của e-Withholding Tax. Nội các Thái Lan đã phê duyệt việc gia hạn thuế suất ưu đãi cho khấu trừ tại nguồn điện tử: chế độ vốn dự kiến kết thúc vào cuối năm 2025 nay được áp dụng hồi tố và kéo dài đến hết năm 2027. Mức 1% — hạ từ các mức thông thường 5%, 3%, 2% — được giữ nguyên, với thời gian áp dụng từ ngày 1 tháng 1 năm 2026 đến ngày 31 tháng 12 năm 2027. Đối tượng là các khoản chi trả thu nhập chịu thuế cho pháp nhân (trừ quỹ và hiệp hội) và cá nhân, thực hiện qua hệ thống e-Withholding Tax. Phạm vi bao gồm phí dịch vụ, thù lao nghề nghiệp chuyên môn, tiền thuê, phí quảng cáo, tiền bản quyền, chi phí xúc tiến bán hàng, tiền thưởng và các khoản tương tự.

Cùng với đó, khoản đầu tư vào hệ thống e-Tax Invoice / e-Receipt, đầu tư vào hệ thống e-Withholding Tax, chi phí trả nhà cung cấp dịch vụ liên quan đến việc sử dụng các hệ thống này, và dịch vụ đánh giá hệ thống thông tin thông qua ETDA cũng được phê duyệt cho việc tính thêm vào chi phí được trừ khi tính thuế thu nhập doanh nghiệp (cũng trong thời gian từ ngày 1 tháng 1 năm 2026 đến ngày 31 tháng 12 năm 2027). Đây là việc gia hạn các ưu đãi vốn đã hết hiệu lực vào ngày 31 tháng 12 năm 2025.

Thí nghiệm tư duy: khác biệt về khấu trừ tại nguồn làm số tiền chuyển đi thay đổi ra sao

Phần dưới đây là thí nghiệm tư duy dùng số tiền giả định, không thể hiện điều kiện giao dịch thực tế hay kết luận về thuế. Chỉ riêng các thuế suất là con số đã công bố theo quy định của Thái Lan.

Tiền đề (số tiền là giả định): pháp nhân tại Thái Lan trả phí dịch vụ 100.000 THB (chưa thuế) cho một công ty phát triển AI trong lãnh thổ Thái Lan.

Phép tính: 100.000 + 7.000 − 3.000 = 104.000. 100.000 + 7.000 − 1.000 = 106.000.

Tổng số tiền phải chi (phí dịch vụ cộng VAT) là như nhau, nhưng tỷ lệ phân bổ giữa phần khấu trừ nộp cho nhà nước và phần chuyển thẳng cho nhà cung cấp thì thay đổi. Từ góc nhìn nhà cung cấp, dòng tiền vào tay họ tăng lên, nên đôi khi bạn có thể dùng việc áp dụng e-Withholding Tax làm điều kiện đàm phán. Lưu ý rằng cách xử lý VAT (được khấu trừ đầu vào hay không và vào thời điểm nào) cũng như việc hoàn hay bù trừ thuế khấu trừ tại nguồn đều cần xem xét theo từng trường hợp, nên hãy luôn xác nhận với chuyên gia thuế.

Trường hợp đặt hàng nhà cung cấp ở nước ngoài — VAT theo cơ chế đảo ngược và PND54

Khi đặt hàng một công ty phát triển AI tại Nhật Bản, hoặc nhà cung cấp tại Singapore, châu Âu hay Mỹ, sẽ có thêm những điểm phải cân nhắc. Nguyên tắc chung một lần nữa: nghĩa vụ khai báo phát sinh theo pháp luật của quốc gia nơi đặt chủ thể hợp đồng. Với Thái Lan, cụ thể như sau.

Khi doanh nghiệp ngoài lãnh thổ Thái Lan cung cấp dịch vụ từ nước ngoài và dịch vụ đó được sử dụng trong lãnh thổ Thái Lan, giao dịch được coi là cung cấp dịch vụ tại Thái Lan và phát sinh VAT 7%. Trong trường hợp này, pháp nhân Thái Lan nhận dịch vụ phải thay mặt nhà cung cấp dịch vụ ở nước ngoài kê khai và nộp thuế bằng tờ khai P.P.36. Đây chính là cơ chế đảo ngược (reverse charge).

Ngoài ra, các khoản chi trả ra ngoài lãnh thổ Thái Lan đồng thời có khả năng cao thuộc đối tượng chịu thuế khấu trừ tại nguồn (PND54), và được khuyến nghị tham vấn chuyên gia trước. Vì thuế suất cụ thể và khả năng áp dụng hiệp định tránh đánh thuế hai lần khác nhau theo từng giao dịch, bài viết này không kết luận.

Hàm ý thực tiễn là: nhà cung cấp ở nước ngoài trông có vẻ rẻ hơn, nhưng khi tính cả nghĩa vụ kê khai và chi phí phát sinh tại nước đặt chủ thể hợp đồng thì đánh giá có thể đảo chiều. Và điều quan trọng là những nghĩa vụ kê khai này không thể biện minh bằng câu “tôi không biết”. Ngay từ giai đoạn đàm phán hợp đồng, hãy thống nhất ba điểm sau với bộ phận kế toán và thuế trong nội bộ.

1. Đặt chủ thể hợp đồng ở đâu (trụ sở Nhật Bản / pháp nhân tại nước sở tại)
2. “Nơi sử dụng” dịch vụ được xác định là ở đâu
3. VAT và thuế khấu trừ tại nguồn nằm trong giá hợp đồng hay do bên nào chịu riêng (có điều khoản gross-up hay không)

Điểm thứ ba là vấn đề câu chữ hợp đồng. Nếu chỉ ghi “số tiền chưa bao gồm thuế”, sau này sẽ tranh cãi về việc ai gánh khoản thuế đó.

Luật AI của Thái Lan chưa được thông qua — chính vì vậy càng phải viết vào hợp đồng

Còn một vấn đề nữa mang tính thời điểm rất cao. Cơ quan Phát triển Giao dịch Điện tử Thái Lan (ETDA) đã công bố bản dự thảo mới của Luật Trí tuệ nhân tạo (Draft Act on Artificial Intelligence) vào ngày 2 tháng 7 năm 2026 và tổ chức lấy ý kiến công khai trong khoảng 30 ngày. Đợt lấy ý kiến này được cho là đã kết thúc vào đầu tháng 8 năm 2026. Tại thời điểm viết bài, luật vẫn chưa được thông qua.

Tại thời điểm hiện tại, luật này chưa được thông qua và thời điểm thông qua chưa được ấn định. Vì vậy bài viết không nói “hãy tuân thủ Luật AI Thái Lan”. Nhưng nội dung dự thảo có những yếu tố mà bên đặt hàng nên chuẩn bị từ bây giờ.

Dự thảo mượn cấu trúc dựa trên rủi ro từ Đạo luật AI của EU nhưng có những yếu tố riêng của Thái Lan. Cụ thể là trách nhiệm nghiêm ngặt đối với thiệt hại liên quan đến AI, nghĩa vụ chỉ định đại diện trong nước đối với nhà cung cấp nước ngoài, và nghĩa vụ gắn nhãn nội dung do AI tạo ra. Về phân tầng rủi ro, dự thảo đặt ra nhóm AI rủi ro bị cấm (thao túng nhận thức và hành vi bằng kỹ thuật tiềm thức, hệ thống AI gây phân biệt đối xử bất công và trên diện rộng) và nhóm AI rủi ro cao (do nghị định hoàng gia chỉ định, gồm những hệ thống ảnh hưởng tới an ninh quốc gia, sức khỏe, môi trường, năng lượng, viễn thông, giao thông vận tải). Các nghị định ban hành sau đó cũng có thể bổ sung yêu cầu thông báo, đăng ký hoặc xin phép với cơ quan quản lý nhà nước có thẩm quyền trước khi triển khai một số hệ thống AI nhất định.

Từ đây rút ra đúng một kết luận thực tiễn: viết ngay từ bây giờ vào hợp đồng rằng khi luật được thông qua thì ai sẽ xử lý. Cụ thể, hãy cân nhắc các điều khoản sau.

Dù chỉ viết được đúng một câu “khi văn bản pháp luật có hiệu lực, hai bên sẽ trao đổi riêng”, vẫn còn tốt hơn nhiều so với không viết gì. Lý tưởng nhất là viết cả khung trao đổi: ai, trong bao lâu, phân chia chi phí theo tiêu chí nào. Khác biệt thực tiễn giữa các quốc gia khi triển khai AI cũng được đề cập trong bài viết về triển khai AI tại Thái Lan.

Xin lưu ý, cả phần thuế lẫn phần pháp lý, bài viết này chỉ dừng ở mức cung cấp thông tin chung. Khi ra quyết định thực tế, hãy luôn xác nhận với chuyên gia thuế và chuyên gia pháp lý.

10 câu hỏi nhất định phải hỏi công ty phát triển AI

Chúng tôi chuyển toàn bộ nội dung trên thành một danh sách câu hỏi dùng được ngay tại bàn thương thảo. Mỗi câu kèm theo “vì sao hỏi” và “câu trả lời nào là tín hiệu nguy hiểm”.

1. Theo bạn, dự án này thuộc loại nào trong ba loại của danh mục kiểm tra (dùng dịch vụ AI phổ dụng / tùy chỉnh / phát triển mới)?

Vì sao hỏi: loại khác nhau thì các điểm cần làm rõ cũng khác nhau. Qua đó bạn đo được độ thuần thục về thực hành hợp đồng của đối tác.

Tín hiệu nguy hiểm: trả lời ngay “chúng tôi làm tất cả theo đặt hàng riêng”. Có khả năng họ đang đẩy cả những phần mà dùng dịch vụ có sẵn là đã đủ sang phát triển mới.

2. Có thể triển khai theo kiểu chia hợp đồng theo từng giai đoạn như mô hình phát triển theo giai đoạn mang tính thăm dò không?

Vì sao hỏi: để xác nhận bạn có tạo được chỗ dừng hay không.

Tín hiệu nguy hiểm: cố ép bằng lý lẽ “gói trọn sẽ rẻ hơn”. Đổi lại cái rẻ đó, bạn mất quyền tự do rút lui.

3. Nếu giai đoạn đánh giá đi tới kết luận “khó”, chúng tôi được bàn giao những gì?

Vì sao hỏi: xác nhận thất bại rồi thì còn lại gì trong tay.

Tín hiệu nguy hiểm: không trả lời rõ ràng, hoặc nói “chưa từng có trường hợp như vậy”.

4. Loại hợp đồng của từng giai đoạn là khoán việc hay ủy thác công việc? Nếu là ủy thác thì theo tỷ lệ thực hiện hay gắn với kết quả hoàn thành?

Vì sao hỏi: buộc đối tác nói rõ có nghĩa vụ hoàn thành hay không.

Tín hiệu nguy hiểm: giải thích mập mờ kiểu “là ủy thác nhưng thực chất giống khoán việc”. Về mặt pháp lý, hai thứ đó hoàn toàn khác nhau.

5. Mẫu số của chỉ số độ chính xác trong đề xuất là gì? Theo ký tự, theo trường dữ liệu, hay theo chứng từ?

Vì sao hỏi: như đã thấy ở chương 5, mẫu số làm khối lượng công việc chênh nhau cả bậc.

Tín hiệu nguy hiểm: không trả lời được ngay, hoặc đáp “thông thường ra khoảng 99%” mà không nói mẫu số.

6. Bộ dữ liệu nghiệm thu sẽ được xác định thế nào? Bao nhiêu mẫu, cơ cấu ra sao?

Vì sao hỏi: không cố định tổng thể thì việc nghiệm thu không có cơ sở để tiến hành.

Tín hiệu nguy hiểm: định cho qua bằng câu “cứ chạy thử, không có vấn đề gì là được”.

7. Nếu không đạt tiêu chí nghiệm thu, việc xử lý lại được miễn phí tối đa bao nhiêu lần, trong bao nhiêu tuần? Sau đó thì sao?

Vì sao hỏi: xác nhận lối ra khi mọi việc không suôn sẻ.

Tín hiệu nguy hiểm: nói “làm đến khi đạt thì thôi” mà không đặt thời hạn. Trách nhiệm vô hạn trên thực tế không bao giờ được thực hiện.

8. Mô hình đã huấn luyện trên dữ liệu của chúng tôi và các mô hình phái sinh có được dùng lại cho dự án của công ty khác không?

Vì sao hỏi: đây là vấn đề cốt lõi của chương 6.

Tín hiệu nguy hiểm: dừng ở câu “chúng tôi có thể sử dụng dưới dạng tri thức đã khái quát hóa” mà không đi tiếp vào việc định nghĩa phạm vi.

9. Việc kết nối với hệ thống hiện có và thiết kế phân quyền có nằm trong báo giá lần này không? Nếu không, cần chốt được những gì thì bạn ra được báo giá?

Vì sao hỏi: câu hỏi để bịt lỗ hổng tầng ④ ở chương 4.

Tín hiệu nguy hiểm: đẩy ra ngoài phạm vi bằng câu “phần kết nối mong quý công ty tự xử lý” mà không nêu điều kiện nào.

10. Sau khi vận hành, ai thực hiện huấn luyện lại, với tần suất nào, theo cơ cấu nhân sự nào? Chủ thể hợp đồng sẽ là pháp nhân nào?

Vì sao hỏi: xác nhận đồng thời tầng ⑤ và cửa vào của các vấn đề thuế, pháp lý ở chương 7.

Tín hiệu nguy hiểm: hễ nói tới cơ cấu vận hành là đột nhiên đổi người, hoặc xuất hiện thông tin lần đầu được nhắc tới kiểu “phần bảo trì do công ty khác đảm nhiệm”.

Với 10 câu này, nếu được, hãy hỏi bằng văn bản và nhận trả lời bằng văn bản. Giải thích bằng miệng không đọng lại trong hợp đồng. Nếu bạn yêu cầu họ đính kèm văn bản trả lời vào hồ sơ đề xuất, đó sẽ là điểm tham chiếu chung tại buổi nghiệm thu về sau.

Sáu kiểu thất bại thường gặp

Chúng tôi sắp xếp những thất bại hay gặp trong thực tế theo dạng nguyên nhân và đối sách.

Kiểu 1: dừng ở PoC rồi bị đắp chiếu

Nguyên nhân: điều kiện kết thúc của PoC chỉ được định nghĩa ở mức “làm thử cho có cảm nhận”. Không có tiêu chí để quyết định đi tiếp, nên không ai quyết được.

Đối sách: trước khi bắt đầu PoC, thống nhất bằng văn bản “con số nào đạt mức nào thì chuyển sang giai đoạn phát triển”. Đồng thời viết luôn thủ tục kết thúc khi không đi tiếp.

Kiểu 2: nghiệm thu thì hai bên hiểu “độ chính xác” theo hai kiểu

Nguyên nhân: hợp đồng chỉ ghi chỉ số độ chính xác mà không có mẫu số.

Đối sách: cố định bộ dữ liệu nghiệm thu bằng phụ lục và viết bằng chỉ số nghiệp vụ (số việc, số giờ lao động thủ công còn lại).

Kiểu 3: mô hình thì xong, nhưng không nối được vào hệ thống nghiệp vụ

Nguyên nhân: tầng ④ của báo giá (kết nối hệ thống hiện có và thiết kế phân quyền) nằm ngoài phạm vi. Sau khi chạy thật vẫn còn quy trình trao đổi file CSV bằng tay.

Đối sách: đối chiếu báo giá theo 5 tầng và bịt lỗ hổng ④ trước khi đặt hàng. Tự lập trước danh sách và số lượng hệ thống cần kết nối.

Kiểu 4: nửa năm sau độ chính xác tụt, không ai sửa được

Nguyên nhân: cơ cấu của tầng ⑤ (vận hành và huấn luyện lại) không nằm trong hợp đồng. Kỹ sư từng phát triển hệ thống đã chuyển sang dự án khác, quy trình huấn luyện lại không còn được lưu lại.

Đối sách: đưa giai đoạn huấn luyện bổ sung vào hợp đồng ngay từ đầu. Đưa việc bàn giao script và tài liệu cần cho huấn luyện lại vào điều kiện nghiệm thu.

Kiểu 5: không đổi được nhà cung cấp

Nguyên nhân: quyền sở hữu mô hình đã huấn luyện mập mờ, hoặc môi trường thực thi là loại đặc thù riêng của nhà cung cấp và hình thức bàn giao chưa được định nghĩa.

Đối sách: đưa danh sách hình thức bàn giao ở chương 6 vào hợp đồng. Ghi tách bạch IP có sẵn và IP hình thành mới.

Kiểu 6: sát ngày vận hành mới nảy ra vấn đề thuế

Nguyên nhân: các vấn đề như VAT theo cơ chế đảo ngược hay PND54 đối với khoản chi trả cho nhà cung cấp nước ngoài chỉ bị phát hiện sau khi đã ký hợp đồng. Không có điều khoản gross-up nên tranh cãi về bên chịu chi phí.

Đối sách: đặt việc quyết định chủ thể hợp đồng ngay đầu quá trình đàm phán. Kéo bộ phận kế toán và thuế vào ngay từ giai đoạn so sánh báo giá.

Điểm chung của cả sáu kiểu là: tất cả đều không phải vấn đề kỹ thuật, mà là vấn đề thỏa thuận trước. Chính vì thế, so sánh danh sách các công ty không giúp bạn phòng tránh được.

Lộ trình 90 ngày

Cuối cùng là bản đồ triển khai. Đây là ví dụ về cách tiến hành tiêu chuẩn; tùy quy mô dự án và tình trạng dữ liệu, các mốc có thể xê dịch.

Hãy để ý rằng trong 90 ngày này, thời gian thực sự trao đổi với công ty phát triển AI chỉ khoảng 2–3 tuần. Phần còn lại là thời gian để nội bộ bạn quyết những gì mình phải quyết. Làm ngược thứ tự, tức bắt đầu bằng việc đi thăm nhà cung cấp, thì bạn đang nhờ đối tác quyết hộ những việc mình chưa quyết, và quyết định đó chắc chắn sẽ nghiêng về phía có lợi cho họ.

Việc kiểm kê dữ liệu ở tuần 5–6 mà chậm thì toàn bộ tiến độ chậm theo. Đây là chỗ khó ước lượng khối lượng công việc nhất, nên hãy bắt tay sớm với biên độ dự phòng. Phần rà soát của chuyên gia ở tuần 12 cũng phụ thuộc vào lịch của bên ngoài, nên cần liên hệ đặt lịch từ sớm.

Câu hỏi thường gặp (FAQ)

Công ty phát triển AI và công ty tư vấn AI khác nhau ở điểm nào?

Không có định nghĩa chuẩn của ngành, nhưng trên thực tế trọng tâm của hai bên khác nhau. Các công ty tự nhận làm tư vấn AI mạnh ở tầng ① định nghĩa bài toán và khảo sát dữ liệu của chương 4, thường đảm nhận việc xác định nên áp AI vào nghiệp vụ nào và sắp xếp bài toán hiệu quả đầu tư. Công ty phát triển AI thì lấy tầng ③ xây dựng mô hình và ứng dụng làm trung tâm. Vấn đề là có những trường hợp ba tầng ② chuẩn hóa dữ liệu, ④ kết nối hệ thống hiện có và ⑤ vận hành không thuộc phạm vi trách nhiệm của bên nào và bị treo lơ lửng. Nếu bạn trao đổi với cả hai bên, hãy viết ra giấy ngay từ đầu ai giữ tầng nào trong 5 tầng. Ngoài ra, nếu tách phần tư vấn thành hợp đồng riêng, cần kiểm tra xem sản phẩm bàn giao của hợp đồng đó có ở dạng chuyển thẳng được cho công ty phát triển hay không.

Vì sao báo giá phát triển AI theo yêu cầu chênh lệch lớn giữa các công ty?

Nguyên nhân chính không phải chênh lệch đơn giá, mà là chênh lệch phạm vi báo giá. Như đã thấy ở chương 4, tổng số tiền thay đổi rất nhiều tùy vào việc có bao gồm ④ kết nối hệ thống hiện có và thiết kế phân quyền, ⑤ vận hành và huấn luyện lại hay không. Thêm nữa, tiền đề về ② chuẩn hóa dữ liệu khác nhau cũng là yếu tố lớn. Công ty báo giá theo tiền đề “dữ liệu đã được chuẩn hóa” và công ty báo giá theo tiền đề “bắt đầu từ việc sửa các sai khác cách ghi” sẽ cho ra khối lượng công việc hoàn toàn khác nhau cho cùng một dự án. Khi so sánh, đừng xếp các con số cạnh nhau, hãy gắn nhãn theo 5 tầng và chỉnh về cùng một phạm vi rồi mới so. Sau khi chỉnh phạm vi, phần lớn trường hợp chênh lệch sẽ nhỏ hơn bạn tưởng.

Thuê ngoài phát triển AI hay tự làm nội bộ thì có lợi hơn?

Đây là câu hỏi không nên đặt ở dạng chọn một trong hai. Cách phân chia thực tế là theo tầng: trong 5 tầng ở chương 4, giữ ① định nghĩa bài toán và ⑤ vận hành về phía công ty bạn, đưa ra ngoài những phần nặng về kỹ thuật trong ② đến ④. Có hai lý do. Thứ nhất, tầng ① không thể đạt chất lượng cao nếu thiếu hiểu biết về nghiệp vụ của chính bạn. Thứ hai, thuê ngoài hoàn toàn tầng ⑤ sẽ khiến việc phát hiện suy giảm độ chính xác bị chậm, và tới lúc hợp đồng hết hiệu lực thì bạn không làm được gì. Ngược lại, nếu định tự làm nội bộ ③ xây dựng mô hình ngay từ đầu, việc tuyển và giữ nhân sự sẽ mất quá nhiều thời gian. Cách chia trách nhiệm theo từng tầng được tổng hợp chi tiết trong bài viết về hỗ trợ tự phát triển AI nội bộ.

Hợp đồng phát triển hệ thống AI có thể ký theo dạng khoán việc không?

Không phải là “không thể”, nhưng nếu bạn yêu cầu khoán việc cho phần mô hình AI thì thông thường nhà cung cấp sẽ từ chối, hoặc cộng thêm phần bù rủi ro vào giá. Do độ chính xác của AI phụ thuộc vào dữ liệu huấn luyện, nhà cung cấp được cho là có xu hướng tránh loại hợp đồng khoán việc. Có hai thiết kế khả thi. Một là tách phần mô hình AI và phần hệ thống xung quanh, chỉ đưa phần hệ thống xung quanh có đặc tả chốt được sang khoán việc. Hai là chọn phương án dung hòa: hợp đồng ủy thác công việc theo nghĩa vụ cẩn trọng, loại gắn với kết quả hoàn thành. Tuy nhiên nếu chọn phương án sau, việc trao đổi với chuyên gia về định nghĩa “hoàn thành” là bắt buộc. Không viết trọn được định nghĩa thì loại gắn với kết quả chỉ còn là hình thức. Quyết định cuối cùng về loại hợp đồng xin hãy luôn xác nhận với luật sư.

Chi phí phát triển AI dao động nhiều nhất ở đâu?

Ở hai tầng ② chuẩn hóa dữ liệu và ④ kết nối hệ thống hiện có. Tầng ② dao động vì phải bắt tay vào rồi mới biết thực trạng dữ liệu. Bạn được nghe “chúng tôi có dữ liệu 3 năm”, nhưng giữa chừng định dạng đã đổi, mỗi người phụ trách lại nhập theo quy tắc riêng — chuyện đó rất phổ biến. Tầng ④ có khối lượng công việc tăng nhanh hơn cả tuyến tính theo số lượng hệ thống cần kết nối và đặc tả giao diện. Cách tốt nhất để kìm dao động của hai tầng này là tách giai đoạn đánh giá thành một hợp đồng độc lập, xác định xong hiện trạng dữ liệu và hệ thống hiện có tại đó, rồi mới lấy lại báo giá cho ③ trở đi. Hợp đồng theo giai đoạn không chỉ tạo ra quyền tự do rút lui, mà còn là công cụ nâng độ chính xác của báo giá.

Nên bắt đầu trao đổi về việc triển khai AI từ giai đoạn nào, và khi nào mới cần bàn tới hợp đồng phát triển AI?

Từ giai đoạn còn là ý tưởng cũng không sao. Ngược lại, nếu viết xong RFP rồi mới trao đổi lần đầu, tiền đề của tầng ② và ④ có thể bị chốt cứng trong khi không khớp thực tế. Tuy vậy, có ba thứ nên chuẩn bị trước để cuộc trao đổi đi nhanh. Thứ nhất là danh sách công đoạn ứng viên (nêu 3 rồi chọn 1). Thứ hai là hiện trạng dữ liệu (vị trí, số lượng, khoảng thời gian, tình trạng thiếu). Thứ ba là giả thuyết về cách đo hiệu quả. Với thứ ba, bài viết về đo lường hiệu quả và ROI khi triển khai AI sẽ hữu ích. Có đủ ba điểm này thì ngay buổi làm việc đầu tiên đã có thể đi tới nhận định về tính khả thi. Còn hợp đồng phát triển AI thì chỉ cần bàn tới khi đã chốt được giai đoạn đánh giá sẽ làm những gì — không cần có ngay từ buổi đầu.

Kết luận

Xin tóm tắt lại lập luận của bài viết một lần nữa.

Phát triển AI được thực hiện bằng phương pháp quy nạp dựa trên dữ liệu huấn luyện, nên bản thân dữ liệu huấn luyện có thể đã chứa sẵn giới hạn về độ chính xác, và việc thiết lập nghĩa vụ hoàn thành hay bảo đảm hiệu năng là rất khó. Nghĩa là giả định “chọn được công ty tốt thì sẽ hoàn thành” khó đứng vững về mặt cấu trúc. Chính vì vậy, trước khi so sánh danh sách các công ty, bạn cần thiết kế bốn điểm sau.

1. Loại hợp đồng: khoán việc hay ủy thác công việc. Nếu ủy thác thì theo tỷ lệ thực hiện hay gắn với kết quả hoàn thành. Có viết trọn được định nghĩa “hoàn thành” hay không
2. Cách chia giai đoạn: chia thành 4 giai đoạn — đánh giá / PoC / phát triển / huấn luyện bổ sung — và đặt điều kiện khởi đầu và điều kiện kết thúc cho từng giai đoạn. Tạo ra chỗ để dừng
3. Điều kiện nghiệm thu: nêu rõ mẫu số của độ chính xác, cố định bộ dữ liệu nghiệm thu bằng phụ lục, viết bằng chỉ số nghiệp vụ (số việc và số giờ lao động thủ công còn lại)
4. Quyền sở hữu: phân biệt IP hình thành mới và IP có sẵn, quy định tách riêng cho bốn đối tượng là dữ liệu thô, bộ dữ liệu huấn luyện, mô hình đã huấn luyện và mô hình phái sinh. Nhất định phải xác nhận việc có được dùng lại cho dự án của công ty khác hay không

Khi chủ thể hợp đồng là một pháp nhân ở nước ngoài, cần cộng thêm việc chọn chủ thể hợp đồng, cách xử lý thuế khấu trừ tại nguồn, VAT và cơ chế đảo ngược theo pháp luật của quốc gia đó, cùng với phân công xử lý khi một đạo luật về AI đang ở dạng dự thảo — như dự thảo của Thái Lan — được thông qua. Phần thuế và pháp lý xin hãy luôn xác nhận với chuyên gia.

Và như lộ trình 90 ngày đã cho thấy, phần lớn công việc thiết kế này có thể hoàn tất trong nội bộ công ty bạn, trước khi gặp bất kỳ công ty phát triển AI nào. Chỉ cần giữ đúng thứ tự, bạn đã phòng tránh được phần lớn các thất bại trong khâu lựa chọn.

TOMAS TECH đặt trụ sở tại Bangkok, Thái Lan, xây dựng các hệ thống thuộc lĩnh vực IT và OT cho nhà máy của doanh nghiệp sản xuất Nhật Bản. Chúng tôi hoan nghênh cả những trao đổi ở giai đoạn rất sớm, kiểu “vẫn còn là ý tưởng, chưa biết áp vào công đoạn nào” hay “muốn cùng đọc lại bản báo giá vừa nhận từ một công ty khác”. Hãy xem chúng tôi như nơi để thử va đập ý tưởng trước khi chốt nhà cung cấp. Mọi liên hệ xin gửi qua biểu mẫu liên hệ.

Nguồn tham khảo

• METI (Nhật Bản), “Hướng dẫn hợp đồng về sử dụng AI và dữ liệu” (công bố tháng 6 năm 2018, sửa đổi một phần tháng 12 năm 2019), phần AI — https://www.meti.go.jp/policy/mono_info_service/connected_industries/sharing_and_utilization/20180615001-3.pdf
• METI (Nhật Bản), “Danh mục kiểm tra hợp đồng về sử dụng và phát triển AI” (công bố ngày 18 tháng 2 năm 2025), bản PDF gốc — https://www.meti.go.jp/policy/mono_info_service/connected_industries/sharing_and_utilization/20250218003-ar.pdf
• Thông cáo báo chí của tài liệu trên — https://www.meti.go.jp/press/2024/02/20250218003/20250218003.html
• Tài liệu tóm tắt hướng dẫn hợp đồng (tháng 1 năm 2021, Vụ Kinh tế thông tin — METI) — https://www.jftc.go.jp/cprc/conference/index_files/21011902.pdf
• Logit Partners (văn phòng luật sư và kế toán), bài phân tích “Danh mục kiểm tra hợp đồng về sử dụng và phát triển AI” — https://partners.logit.jp/ai-checkliist-meti/
• Cục Sáng chế Nhật Bản, IP BASE, “Các loại hợp đồng phát triển AI” — https://ipbase.go.jp/learn/point/ai/page05.php
• JETRO, “Thái Lan — Chế độ thuế” (thuế thu nhập doanh nghiệp 20%, VAT 7%, thuế khấu trừ tại nguồn) — https://www.jetro.go.jp/world/asia/th/invest_04.html
• HLB Thailand, “Cabinet Approves Extension of Tax Measures to End of 2027” (thuế suất ưu đãi e-Withholding Tax 1%, từ 01/01/2026 đến 31/12/2027) — https://www.hlbthai.com/cabinet-approves-extension-of-tax-measures-to-end-of-2027-to-promote-adoption-of-electronic-tax-systems/
• Mahanakorn Partners, “Thailand Approves Two-Year Extension of Electronic Tax System Incentives” — https://mahanakornpartners.com/thailand-approves-two-year-extension-of-electronic-tax-system-incentives/
• JGA, “Chi trả cho nhà cung cấp nước ngoài và VAT theo cơ chế đảo ngược (P.P.36)” — https://jga.asia/?p=1241
• Mondaq, “Thailand Releases New Draft Artificial Intelligence Act” (ETDA công bố dự thảo ngày 2 tháng 7 năm 2026, chưa được thông qua) — https://www.mondaq.com/it-and-internet/1811290/thailand-releases-new-draft-artificial-intelligence-act
• Tilleke & Gibbins, “Thailand’s AI Governance Framework” — https://www.tilleke.com/insights/comprehensive-policy-thailands-ai-governance-framework/