Startup đóng cửa: PM cần chuẩn bị gì khi dữ liệu thành tài sản AI?
AI labs đang mua code và kho dữ liệu công việc từ startup đóng cửa để huấn luyện mô hình. Với PM và founder, đây là lúc làm rõ quyền sở hữu, phạm vi đồng ý, quyền truy cập và quy trình xử lý dữ liệu khi dự án kết thúc.
Một startup ngừng hoạt động không chỉ để lại mã nguồn hay các file thiết kế cũ. Nó còn để lại lịch sử ra quyết định: vì sao team đổi roadmap, phản hồi trong trao đổi nội bộ, tài liệu sản phẩm và kết quả nghiên cứu.
Những “dấu vết vận hành” này đang có giá trị mới. Theo MIT Technology Review, các AI lab và bên xây môi trường huấn luyện cho AI agent đang mua code cùng kho dữ liệu công việc của startup đã đóng cửa, gồm email, chat và tài liệu.
Với PM hoặc founder, câu hỏi không chỉ là dữ liệu còn dùng được hay không. Cần xác định sớm: ai có quyền quyết định việc xử lý dữ liệu, phạm vi sử dụng nào đã được đồng ý, và team có thể xoá hoặc bàn giao dữ liệu một cách kiểm soát không?
Thị trường đang mua dữ liệu vận hành của startup
MIT Technology Review cho biết SimpleClosure đã bổ sung dịch vụ bán dữ liệu vào tháng 4. Nền tảng Asset Hub của công ty hỗ trợ founder bán code và dữ liệu workspace như email, chat và tài liệu.
Bên mua gồm các AI lab phát triển mô hình nền tảng, công ty xây môi trường làm việc mô phỏng để huấn luyện AI, và doanh nghiệp công nghệ tự phát triển mô hình.
SimpleClosure cho biết Asset Hub đã xử lý hơn 150 giao dịch. Theo công ty, 47% giao dịch hiện có yếu tố bán code hoặc dữ liệu, và họ kỳ vọng hoàn trả hơn 10 triệu USD cho các startup đến cuối năm 2026.
Một founder startup crypto được bài viết nhắc tới đã nhận khoảng 25.000 USD cho codebase và dự kiến nhận thêm khoảng 15.000 USD từ dữ liệu lưu trong Google, Notion, Figma và Slack. Sunset, một đơn vị khác trong mảng này, cho biết họ xem xét số nhân sự, số năm hoạt động, khối lượng dữ liệu và cách team sử dụng công cụ khi định giá tài sản.
Với PM, điều này đáng chú ý vì một workspace có thể lưu giữ:
Problem statement, PRD, roadmap và ghi chú họp.
Prototype, phản hồi thiết kế và các quyết định đổi phạm vi.
Insight nghiên cứu người dùng và tài liệu hỗ trợ ra quyết định.
Trao đổi giữa Product, Design, Engineering, Sales và lãnh đạo.
Đây là các tình huống giàu ngữ cảnh, có bất đồng và phán đoán khó — loại dữ liệu mà bên mua cho là có thể hữu ích để AI agent thực hành tác vụ. Tuy vậy, giá trị thương mại không tự động đồng nghĩa với việc dữ liệu phù hợp để chuyển nhượng.
Vì sao dữ liệu công việc cần được xử lý thận trọng
Bài viết nêu rằng kho lưu trữ thực tế có thể tránh một số lỗi của dữ liệu tổng hợp, chẳng hạn những tham chiếu đến ngày tháng không tồn tại. Nhưng chưa có công ty nào công bố thử nghiệm đối chiếu cho thấy dữ liệu công việc thật cải thiện mô hình bao nhiêu so với các lựa chọn khác.
Nói cách khác, việc định giá thường dựa trên giả định về số tác vụ hữu ích có thể rút ra từ dữ liệu, thay vì một chuẩn đã được kiểm chứng công khai.
Rủi ro nằm ở những phần thường bị xem là “ghi chú hậu trường”. Email và lịch có thể chứa lịch khám bệnh, việc đón con hoặc kế hoạch cá nhân. Slack, tài liệu nghiên cứu hay workspace thiết kế cũng có thể bao gồm thông tin về đồng nghiệp, khách hàng, người dùng hoặc chiến lược kinh doanh.
Điểm cần nhớ: nếu discovery được lưu lẫn với dữ liệu nhận diện cá nhân hoặc thông tin kinh doanh nhạy cảm, việc xuất toàn bộ workspace khi công ty đóng cửa là một quyết định cần được đánh giá kỹ, không chỉ là thao tác hành chính.
Bài viết cũng đặt ra vấn đề về phân chia lợi ích. Tiền bán tài sản thường chảy về chủ nợ cấp cao và nhà đầu tư, thay vì nhân viên có dữ liệu lao động xuất hiện trong kho lưu trữ. Founder cũng có thể ít biết người mua cuối cùng là ai và dữ liệu sẽ được dùng như thế nào.
Đưa quản trị dữ liệu vào quy trình product
PM không cần đợi đến lúc startup gặp khó khăn mới lập data inventory: danh mục cho biết dữ liệu nào nằm ở đâu, ai chịu trách nhiệm và được dùng vào mục đích gì.
Có thể đưa hoạt động này vào Definition of Done cho discovery và delivery.
1. Tách dữ liệu theo mục đích
Đừng để bản ghi nghiên cứu gốc, insight đã tổng hợp và PRD nằm chung một nơi với cùng mức quyền truy cập.
Dữ liệu gốc nên có vòng đời lưu trữ và quyền truy cập chặt hơn tài liệu tổng hợp phục vụ quyết định sản phẩm.
2. Gắn người chịu trách nhiệm cho từng kho
Với mỗi teamspace Notion, project Figma, channel Slack hoặc thư mục Drive, hãy xác định:
Người sở hữu nghiệp vụ.
Người chịu trách nhiệm quản trị dữ liệu.
Người phê duyệt khi cần xuất hoặc bàn giao dữ liệu.
3. Làm rõ phạm vi đồng ý và giới hạn sử dụng
Khi mời người dùng phỏng vấn hoặc usability test, cần mô tả rõ phạm vi lưu trữ, người có thể truy cập, thời hạn lưu và phương án xử lý khi không còn cần dữ liệu.
Không nên suy diễn rằng một sự đồng ý thu thập dữ liệu cho nghiên cứu sản phẩm cũng mặc nhiên áp dụng cho mọi mục đích sử dụng về sau.
4. Có playbook khi đóng dự án hoặc đóng công ty
Playbook nên trả lời các câu hỏi sau:
Dữ liệu nào cần xoá?
Dữ liệu nào có thể bàn giao và theo điều kiện nào?
Ai phê duyệt?
Ai cần được thông báo?
Bằng chứng xử lý hoặc xoá dữ liệu được lưu ở đâu?
5. Tách quyền truy cập khỏi quyền quyết định
Một PM có quyền xem transcript để tổng hợp insight không đồng nghĩa PM có quyền xuất, bán hoặc chuyển transcript cho bên thứ ba.
Prompt hỗ trợ lập danh mục dữ liệu cần xử lý
Chỉ dùng prompt dưới đây trong công cụ AI đã được doanh nghiệp phê duyệt. Không tải lên transcript có định danh, thông tin tài khoản khách hàng, usage log hoặc chiến lược kinh doanh nhạy cảm.
Thay vào đó, chỉ dùng mô tả đã ẩn danh và dữ liệu mẫu.
text
Bạn là trợ lý hỗ trợ quản trị dữ liệu cho đội Product.
<productcontext>
[Mô tả sản phẩm, các công cụ đang dùng và mục đích của từng kho dữ liệu]
</productcontext>
<usersegment>
[Mô tả nhóm người dùng ở mức không định danh]
</usersegment>
<researchnotes>
[Chỉ dán insight đã ẩn danh; không dán transcript, recording,
email, thông tin tài khoản hoặc dữ liệu cá nhân]
</researchnotes>
<constraints>
Phân loại: xoá, lưu nội bộ, bàn giao có điều kiện, cần đánh giá thêm
Nêu dữ liệu có thể chứa thông tin cá nhân hoặc bí mật kinh doanh
Không suy đoán phạm vi đồng ý nếu không có bằng chứng
Đề xuất câu hỏi cần xác minh với Legal, Security và Data Owner
Không đưa ra kết luận pháp lý
</constraints>
Hãy tạo:
Bảng data inventory tối giản
Danh sách rủi ro theo mức ưu tiên
Checklist đóng dự án hoặc chuyển giao dữ liệu
Các bằng chứng còn thiếu trước khi ra quyết định
Ví dụ, với một ứng dụng đặt lịch khám, PM có thể nhập mô tả đã ẩn danh: Notion chứa insight tổng hợp, Drive có bản ghi nghiên cứu, Figma có prototype, Slack có trao đổi với đội vận hành.
Một đầu ra hữu ích không phải là kết luận “có thể bán toàn bộ dữ liệu”. Nó cần phân tách rõ:
Insight tổng hợp có thể được đánh giá để lưu nội bộ.
Bản ghi nghiên cứu cần kiểm tra phạm vi đồng ý và thời hạn lưu.
Trao đổi nội bộ cần được rà soát về dữ liệu cá nhân và bí mật kinh doanh.
Phương án chuyển giao ra bên ngoài cần có phê duyệt từ các bên chịu trách nhiệm.
AI hỗ trợ checklist, không thay thế quyết định
AI có thể giúp PM tạo danh mục, phát hiện điểm thiếu trong playbook hoặc chuẩn hoá checklist. Nhưng AI không thể tự xác nhận phạm vi đồng ý của người dùng, điều khoản hợp đồng hay quyền chuyển giao dữ liệu.
Trước khi quyết định lưu, xoá hoặc chuyển giao, hãy đối chiếu đầu ra với:
Bản ghi và biểu mẫu đồng ý gốc.
Điều khoản với khách hàng, đối tác, nhân viên và nhà thầu.
Quyền truy cập thực tế trên Notion, Figma, Slack và Google Workspace.
Tài liệu từ Security, Legal và các bên liên quan.
Các ràng buộc về tài chính, đầu tư hoặc thanh lý nếu có.
Checklist cho PM và founder
[ ] Có danh mục dữ liệu theo công cụ, người phụ trách và mục đích sử dụng.
[ ] Dữ liệu nghiên cứu gốc được tách khỏi insight đã tổng hợp.
[ ] Phạm vi đồng ý và thời hạn lưu được kiểm tra, không suy diễn.
[ ] Có quy trình phê duyệt trước khi xuất hoặc chuyển giao workspace.
[ ] Có kế hoạch xoá, bằng chứng xử lý và đầu mối chịu trách nhiệm.
[ ] Không đưa dữ liệu nhận diện hoặc bí mật kinh doanh lên công cụ AI công khai.
Dữ liệu vận hành có thể trở thành một loại tài sản khi startup đóng cửa. Nhưng với đội Product, giá trị bền vững hơn là xây dựng hệ thống để dữ liệu vẫn được quản trị có trách nhiệm — dù sản phẩm tiếp tục phát triển, dự án kết thúc hay công ty phải dừng lại.