Prompt và eval bạn viết cho khách thực ra thuộc về ai?

Thử hình dung bạn đang ở tuần thứ sáu tại một khách hàng logistics. Trong repo đã có bộ eval 400 case dựng từ ticket hỗ trợ thật, 30 prompt, một connector vào hệ thống ticket, và tất cả chạy trên thư viện eval harness mà công ty bạn dùng cho mọi dự án.

Buổi review, trưởng nhóm bên khách hỏi một câu rất bình thường: hết hợp đồng thì bên họ có giữ được tất cả không? Bạn nhận ra mình không biết câu trả lời. Tệ hơn, hợp đồng có thể cũng không biết.

Trong tình huống này, câu hỏi đã đến muộn sáu tuần. Bạn không phải luật sư, cũng không cần thành luật sư. Việc của bạn là hiểu đủ để phát hiện chỗ trống ngay buổi kickoff, khi sửa vẫn còn rẻ, rồi đưa đúng câu hỏi cho bộ phận pháp lý.

Mọi thứ nằm trong một trong hai cái túi

Khung cơ bản rất đơn giản. Theo cách giải thích của UpCounsel, background IP là thứ có trước khi dự án bắt đầu, còn foreground IP là thứ được phát triển trong dự án. Thư viện eval harness của công ty bạn là background. Bộ 400 case dựng cho khách là foreground.

Quy tắc mặc định đối với túi background khá dễ chịu. Sprintlaw, một hãng luật ở Anh viết cho các agency tự động hóa AI, khuyên hợp đồng nên ghi rằng tài liệu có sẵn vẫn thuộc agency, trừ khi được chuyển nhượng một cách rõ ràng.

Nhưng giữ quyền sở hữu mới là một nửa câu chuyện. Nếu connector bàn giao cần thư viện của bạn mới chạy được, UpCounsel lưu ý hợp đồng phải làm rõ khách có được cấp license dùng thư viện đó hay không.

Túi foreground thì cần một danh sách. Sprintlaw khuyên định nghĩa chính xác sản phẩm nào được chuyển nhượng, nêu tên cụ thể như script, workflow, prompt, thay vì một câu kiểu “mọi sản phẩm của dịch vụ”. Lý do rất thực tế: prompt và eval là những artifact mới, và một điều khoản soạn theo mẫu cũ có thể không nghĩ tới chúng.

Ở Mỹ còn thêm một cái bẫy. Theo định nghĩa trong 17 U.S. Code § 101, một tác phẩm được đặt hàng chỉ là “work made for hire” khi nó thuộc các nhóm mà luật liệt kê và hai bên đã đồng ý bằng văn bản có chữ ký.

Vì thế “khách trả tiền thì khách sở hữu” không phải mặc định an toàn. Cần một điều khoản chuyển nhượng viết rõ ràng.

Một engagement, bốn artifact

Quay lại khách hàng logistics. Ngồi xuống với repo và xếp từng thứ vào túi của nó, bạn sẽ có một bảng như thế này:

Artifact	Túi	Câu cần đưa cho legal
Thư viện eval harness của công ty bạn	Background	Khách được license dùng tiếp sau dự án không, trong phạm vi nào?
400 eval case dựng từ ticket thật	Foreground, chứa thông tin mật	Ai sở hữu, và bên bạn có được giữ lại phiên bản nào không?
30 prompt và workflow viết riêng	Foreground	Danh sách chuyển nhượng có ghi tên chúng không?
Connector vào hệ thống ticket	Lai: lõi dùng chung, cấu hình viết riêng	Ranh giới giữa lõi và phần riêng nằm ở đâu?

Dòng thứ hai khó nhất. Bộ eval là thứ quý nhất bạn làm ra, vì nó mã hóa thế nào là “đúng” với khách này.

Nhưng nó được dựng từ dữ liệu của họ, và Sprintlaw nhấn mạnh hợp đồng nên giới hạn rõ việc dùng lại thông tin mật của khách.

Muốn mang cấu trúc bộ eval sang dự án sau thì phải thỏa thuận từ đầu, đừng tự quyết vào tuần cuối.

Dòng cuối cho thấy vì sao nên tách code từ sớm. Nếu lõi connector nằm trong package riêng còn cấu hình của khách nằm trong module riêng, ranh giới IP trùng với ranh giới trong repo. Nếu mọi thứ trộn trong một file, không điều khoản nào cứu được bạn khi phải bàn giao.

Lớp thứ ba: điều khoản của nhà cung cấp mô hình

Hai bên trong hợp đồng chưa phải tất cả. Sprintlaw cảnh báo rằng điều khoản của nền tảng AI bên thứ ba có thể hạn chế việc chuyển giao, bán lại, sao chép, dùng để huấn luyện hoặc thương mại hóa về sau. Bạn không thể chuyển cho khách một quyền mà chính bạn không có.

Lấy điều khoản thương mại của Anthropic làm ví dụ. Theo đó, khách hàng giữ mọi quyền với Input và sở hữu Output, và Anthropic không được huấn luyện mô hình trên Customer Content từ dịch vụ. Với bộ eval dựng từ ticket thật, đây là chi tiết bạn có thể dùng để trấn an đội bảo mật bên khách.

Nhưng hãy đọc kỹ chữ “Customer”. Điều khoản trao quyền với Output cho Customer, nên việc đầu tiên là kiểm tra ai đang là Customer trong tài khoản mà dự án dùng. Nếu đó không phải chính khách hàng của bạn, hãy đưa thêm một câu cho legal: quyền với Output đến tay khách bằng con đường nào trong hợp đồng.

Điều khoản feedback cũng cần để ý: Anthropic ghi rằng họ có thể dùng feedback của khách hàng mà không có nghĩa vụ gì với khách. Gửi eval case thật lên kèm một báo cáo lỗi là chuyện cần cân nhắc trước khi bấm gửi.

Làm thế nào trong tuần đầu

Bắt đầu từ danh mục artifact dự kiến, viết trước cả khi có code: thư viện nào mang vào, prompt, eval, connector, tài liệu runbook. Gắn nhãn background, foreground hoặc lai cho từng dòng. Sau đó đánh dấu dòng nào chạm tới dữ liệu mật của khách.

Tiếp theo, kiểm tra ai là Customer trong tài khoản API của dự án và đọc phần Input, Output, huấn luyện, feedback trong điều khoản của nhà cung cấp. Cuối cùng gửi bảng này cho legal cùng ba câu hỏi: danh sách chuyển nhượng có gọi tên prompt, eval, connector chưa; khách có license cho công cụ có sẵn không; bên bạn được dùng lại gì sau dự án.

Kỹ năng này cũng có giá khi đi xin việc. Khi tin tuyển dụng FDE nhắc tới “scoping” hay “SOW”, một dòng trong CV như “lập danh mục artifact và phân loại IP cùng legal khi kickoff” cho thấy bạn đã từng điều hành engagement, chứ không chỉ viết code trong đó.

Những lỗi thường gặp

Lỗi phổ biến nhất là coi prompt như cấu hình vặt nên không ai liệt kê. Lỗi thứ hai là để thư viện nội bộ lẫn vào code của khách, nên đến ngày bàn giao, muốn giao connector thì phải giao luôn cả công cụ dùng chung của công ty.

Lỗi thứ ba là chép nguyên bộ eval sang dự án sau vì “đằng nào cũng chỉ là test”, trong khi từng case trong đó là dữ liệu mật của khách.

Lỗi cuối cùng tinh vi hơn: tin rằng chuyện IP là việc của sales và legal. Họ soạn điều khoản, nhưng chỉ người viết code mới biết repo thật sự chứa gì. Câu hỏi của trưởng nhóm logistics ở tuần thứ sáu là câu bạn lẽ ra đã tự hỏi từ ngày đầu, và câu trả lời nên có sẵn trong một bảng bốn dòng.