Mở đầu — vì sao bài này quan trọng
Có một sự thật khó chịu mà nhiều PM chỉ học được sau khi đã "trả giá": tính năng đẹp đến mấy, được người dùng yêu thích đến mấy, vẫn có thể bị gỡ xuống chỉ sau một email từ phòng pháp chế, hoặc tệ hơn — một án phạt từ cơ quan quản lý. Năm 2024, Việt Nam ban hành Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân (PDPD) và đang tiến tới Luật Bảo vệ dữ liệu cá nhân (PDPL) 2024–2025, đặt ra nghĩa vụ cụ thể về thu thập, lưu trữ và xóa dữ liệu. Nếu bạn là PM mà chỉ coi pháp lý là "việc của luật sư", bạn đang đặt cả sản phẩm vào rủi ro.
Bài này dạy bạn cách viết Legal & Compliance Spec — phần trong PRD/Spec mô tả rõ những ràng buộc pháp lý, quyền riêng tư, điều khoản và tuân thủ mà tính năng phải đáp ứng. Đây không phải là việc bạn trở thành luật sư. Đây là việc bạn biết đặt đúng câu hỏi, ghi lại đúng quyết định, và đưa đúng người vào đúng thời điểm — để khi tính năng ra mắt, nó không trở thành quả bom hẹn giờ.
Lưu ý phạm vi: bài này tập trung vào cách viết phần Legal & Compliance trong spec — khác với Bài 42 (Security Review, tập trung kỹ thuật bảo mật) và Bài 35 (Data Schema). Khi gặp giao điểm, tôi sẽ chỉ rõ ranh giới.
Khái niệm cốt lõi
Legal & Compliance Spec trả lời một câu hỏi đơn giản: "Có điều gì về luật pháp, quyền riêng tư hoặc nghĩa vụ tuân thủ khiến tính năng này phải làm khác đi, hoặc không được phép làm?"
Phần này thường nằm ở cuối PRD (sau Solution, trước Rollout), và gồm bốn nhóm review chính.
1. Privacy — Quyền riêng tư & dữ liệu cá nhân
Đây là nhóm quan trọng nhất với hầu hết sản phẩm số. Bạn phải mô tả rõ ba vòng đời của dữ liệu:
- Collection (Thu thập): Tính năng thu thập dữ liệu cá nhân nào? Số điện thoại, email, vị trí GPS, hành vi duyệt, ảnh khuôn mặt? Nguyên tắc vàng là data minimization — chỉ thu thập đúng những gì cần cho mục đích đã nêu. Mỗi trường dữ liệu phải có lý do.
- Consent (Đồng ý): Người dùng có được hỏi ý kiến trước khi thu thập không? Đồng ý phải rõ ràng, tự nguyện, có thể rút lại. Một checkbox đã tick sẵn không được tính là đồng ý hợp lệ theo GDPR và tinh thần của PDPD Việt Nam.
- Retention (Lưu trữ): Dữ liệu giữ bao lâu? Lưu mãi mãi gần như luôn sai. Bạn cần một chính sách kiểu "log truy cập giữ 90 ngày, sau đó tự xóa".
- Deletion (Xóa): Khi người dùng yêu cầu xóa tài khoản (quyền "right to be forgotten"), hệ thống có thực sự xóa được không, kể cả trong backup và data warehouse? Đây là chỗ rất nhiều sản phẩm "nói có làm không".
2. Terms of Service & Disclaimer — Điều khoản & tuyên bố miễn trừ
Tính năng có tạo ra cam kết nào với người dùng không? Nếu app fintech của bạn hiển thị "lợi nhuận dự kiến 12%/năm", bạn cần disclaimer rõ ràng rằng đây không phải lời khuyên đầu tư. Nếu một tính năng AI gợi ý liều thuốc, bạn cần tuyên bố nó không thay thế tư vấn y tế. Phần này liên kết chặt với đội Legal để cập nhật ToS khi cần.
3. Regulatory — Tuân thủ quy định ngành
Một số lĩnh vực bị quản lý chặt: tài chính (KYC/AML — định danh khách hàng, chống rửa tiền), y tế, giáo dục, trẻ em (giới hạn độ tuổi), nội dung (kiểm duyệt theo luật an ninh mạng). Spec phải nêu rõ tính năng có chạm vào vùng quản lý nào.
4. IP & Content Rights — Sở hữu trí tuệ & bản quyền nội dung
Tính năng có cho người dùng tải lên nội dung không? Ai sở hữu nội dung đó? Có dùng dữ liệu của bên thứ ba (font, ảnh, API) đúng license không? Với tính năng AI sinh nội dung, ai chịu trách nhiệm nếu output vi phạm bản quyền?
Khái niệm xương sống: Data Flow & DPIA
Công cụ mạnh nhất của bạn là một bảng Data Flow: dữ liệu nào → thu thập ở đâu → lưu ở đâu → ai truy cập được → giữ bao lâu → xóa thế nào. Với tính năng rủi ro cao (dữ liệu nhạy cảm, quy mô lớn), bạn cần một DPIA — Data Protection Impact Assessment (đánh giá tác động bảo vệ dữ liệu), một tài liệu phân tích rủi ro riêng tư và cách giảm thiểu.
Tình huống thực tế
Ví dụ 1 — App gọi xe thu thập vị trị nền (background location)
Một startup gọi xe ở TP.HCM, tạm gọi là GoMove, muốn ra tính năng "ước tính thời gian tài xế đến" chính xác hơn bằng cách thu thập vị trí GPS của hành khách liên tục dưới nền, kể cả khi app đóng. PM viết spec mô tả rất kỹ phần kỹ thuật, nhưng phần Legal chỉ ghi một dòng: "Cần quyền vị trí".
Khi đưa qua Legal review, luật sư đặt ba câu hỏi: (1) Tại sao cần vị trí nền thay vì chỉ khi app mở? (2) Người dùng đồng ý ở đâu, với ngôn ngữ gì? (3) Dữ liệu vị trí giữ bao lâu? Hóa ra tính năng không thực sự cần background location — chỉ cần vị trí khi app foreground là đủ. Việc thu thập nền vừa thừa, vừa tạo rủi ro vi phạm nguyên tắc data minimization của PDPD, và rất dễ bị Apple/Google từ chối duyệt app.
Bài học: Phần Legal review buộc bạn trả lời "tại sao cần dữ liệu này", và câu trả lời đó thường khiến bạn thiết kế lại tính năng theo hướng đơn giản và an toàn hơn. Spec cuối cùng đổi thành: chỉ thu thập vị trí khi app foreground, hiển thị consent screen rõ ràng "Chúng tôi dùng vị trí để tìm tài xế gần bạn", và log vị trí tự xóa sau 30 ngày.
Ví dụ 2 — Tính năng "Xóa tài khoản" tưởng dễ mà không xóa nổi
Một app thương mại điện tử Đông Nam Á (giả định, tạm gọi ShopNow) bị một người dùng EU gửi yêu cầu xóa toàn bộ dữ liệu theo GDPR. Đội support bấm nút "Xóa tài khoản" — nhưng ba tuần sau, email marketing vẫn gửi đến người này. Điều tra ra: nút "xóa" chỉ đánh dấu is_active = false trong bảng users, còn email vẫn nằm trong hệ thống CRM bên thứ ba (Mailchimp), trong data warehouse (BigQuery) phục vụ phân tích, và trong các bản backup hằng đêm.
Vấn đề gốc: PRD ban đầu của tính năng "Xóa tài khoản" chưa từng có Legal & Compliance Spec. Không ai định nghĩa "xóa" nghĩa là gì về mặt kỹ thuật và pháp lý. Hậu quả là khi có yêu cầu thật, công ty phải làm thủ công, tốn hàng chục giờ kỹ sư, và đối mặt rủi ro khiếu nại.
Bài học: "Xóa" là một từ pháp lý có hệ quả kỹ thuật trên toàn bộ hệ thống. Một Legal Spec tốt phải liệt kê mọi nơi dữ liệu được sao chép tới và quy trình xóa/ẩn danh hóa cho từng nơi — kể cả backup (thường dùng cách "xóa theo lịch khi backup hết hạn") và data warehouse. Đây cũng là lý do Legal Spec phải làm trước khi build, không phải vá sau.
Ví dụ 3 — Chatbot AI tư vấn sức khỏe và disclaimer
Một công ty health-tech Việt Nam ra mắt chatbot AI trả lời câu hỏi sức khỏe. Marketing muốn câu chữ thật tự tin: "Hỏi gì cũng có câu trả lời chính xác". PM, sau khi làm Legal review, đã chặn lại. Lý do: nếu chatbot gợi ý sai và người dùng làm theo gây hậu quả, công ty có thể bị quy trách nhiệm cung cấp dịch vụ tư vấn y tế không phép.
Legal Spec cuối cùng yêu cầu: (1) disclaimer cố định ở đầu mỗi phiên — "Thông tin chỉ mang tính tham khảo, không thay thế tư vấn của bác sĩ"; (2) chặn cứng các câu hỏi về liều lượng thuốc, chẩn đoán bệnh cụ thể, và chuyển hướng "Vui lòng gặp bác sĩ"; (3) lưu log hội thoại để truy vết trách nhiệm, nhưng ẩn danh sau 90 ngày.
Bài học: Với tính năng AI (giao điểm với các bài AI Spec), Legal review không chỉ về dữ liệu mà còn về trách nhiệm pháp lý của output. Disclaimer và guardrail không phải để né tránh — chúng là một phần thiết kế sản phẩm có trách nhiệm.
Hướng dẫn từng bước
Đây là quy trình viết Legal & Compliance Spec mà tôi khuyên bạn dùng cho mọi PRD có chạm đến dữ liệu hoặc nội dung người dùng.
Bước 1 — Phân loại mức rủi ro pháp lý của tính năng. Trước khi viết, tự hỏi: tính năng này có (a) thu thập dữ liệu cá nhân mới? (b) thay đổi cách dùng dữ liệu hiện có? (c) tạo cam kết/nội dung với người dùng? (d) chạm vào ngành bị quản lý? Nếu tất cả đều "không" — một dòng "Không có tác động pháp lý đáng kể" là đủ. Nếu có bất kỳ "có" nào, làm tiếp các bước sau.
Bước 2 — Lập bảng Data Flow. Liệt kê từng loại dữ liệu cá nhân với các cột: Loại dữ liệu | Mục đích thu thập | Nơi lưu | Ai truy cập | Thời gian giữ | Cách xóa. Bảng này là trái tim của spec — nó buộc bạn nghĩ về toàn vòng đời.
Bước 3 — Định nghĩa Consent. Mô tả chính xác: người dùng thấy gì, bấm gì để đồng ý, đồng ý cho mục đích nào, và rút lại bằng cách nào. Nếu cần cập nhật consent screen hiện có, ghi rõ.
Bước 4 — Nêu chính sách Retention & Deletion. Với mỗi loại dữ liệu, ghi rõ thời gian giữ và cơ chế xóa, bao gồm backup và warehouse. Đừng để trống — "lưu vô thời hạn" phải là quyết định có ý thức, không phải mặc định vì lười.
Bước 5 — Liệt kê các nghĩa vụ tuân thủ & disclaimer. Ngành của bạn yêu cầu gì (KYC, giới hạn tuổi, kiểm duyệt)? Cần disclaimer nào? Liên kết tới điều khoản ToS cần cập nhật.
Bước 6 — Ghi Open Questions và đưa Legal vào sớm. Đánh dấu rõ những điểm bạn không chắc bằng tag kiểu [CẦN LEGAL XÁC NHẬN]. Gửi spec cho phòng pháp chế ở giai đoạn draft, không phải ngày trước khi ship. Ghi lại quyết định của họ ngay trong spec — sau này đây là bằng chứng "đã review".
Bước 7 — Liên kết tới DPIA nếu rủi ro cao. Nếu tính năng xử lý dữ liệu nhạy cảm (sức khỏe, sinh trắc học, tài chính, trẻ em) hoặc quy mô rất lớn, đính kèm link tới tài liệu DPIA riêng.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi Legal là bước cuối, review sau khi đã build xong. Đây là lỗi đắt nhất. Khi code đã viết, việc thay đổi vì lý do pháp lý tốn gấp nhiều lần. Mẹo: đưa Legal vào ngay từ draft PRD, dù chỉ là một email "tính năng X sắp tới có gì cần lưu ý không?".
Lỗi 2 — Viết chung chung "tuân thủ GDPR/PDPD". Câu này vô nghĩa vì không ai biết phải làm gì cụ thể. Mẹo: luôn quy về hành động cụ thể — "thêm consent screen", "xóa log sau 90 ngày", "không thu thập số CMND".
Lỗi 3 — Quên backup và data warehouse khi nói về xóa. Như ví dụ ShopNow. Mẹo: luôn hỏi "dữ liệu này còn được sao chép tới đâu nữa?" và xử lý từng nơi.
Lỗi 4 — Thu thập dữ liệu "để dành dùng sau". Đây là cám dỗ lớn của data team. Nhưng dữ liệu không dùng là rủi ro thuần túy. Mẹo: áp dụng data minimization — không có mục đích rõ ràng ngay bây giờ thì không thu thập.
Lỗi 5 — PM tự quyết định pháp lý. Bạn không phải luật sư. Mẹo: vai trò của bạn là phát hiện rủi ro và đặt câu hỏi, còn quyết định cuối cùng về tính hợp pháp thuộc về Legal. Đừng viết "việc này hợp pháp" trong spec; hãy viết "Legal đã xác nhận ngày X".
Mẹo vàng — Tạo một checklist Legal dùng lại. Mỗi công ty nên có một template gồm 8–10 câu hỏi sàng lọc (thu thập dữ liệu gì? consent ở đâu? giữ bao lâu? ngành quản lý? disclaimer?). PM tự trả lời trước, lọc ra 90% trường hợp đơn giản, chỉ những case phức tạp mới cần Legal họp.
Bài tập thực hành
Chọn một trong hai đề sau và viết phần Legal & Compliance Spec (khoảng 1 trang).
Đề A — Tính năng "Đăng nhập bằng khuôn mặt" (Face ID nội bộ). Một app fintech Việt Nam muốn cho phép đăng nhập bằng nhận diện khuôn mặt thay vì mật khẩu. Hãy viết spec trả lời: Dữ liệu sinh trắc học được thu thập và lưu ở đâu (thiết bị hay server)? Người dùng đồng ý thế nào và có lựa chọn dùng cách khác không? Giữ bao lâu, xóa ra sao khi gỡ tính năng? Có cần DPIA không? Đánh dấu rõ ít nhất 2 điểm [CẦN LEGAL XÁC NHẬN].
Đề B — Tính năng "Cộng đồng đăng bài & ảnh". Một nền tảng học tập cho phép học viên đăng bài và tải ảnh lên. Hãy viết spec trả lời: Ai sở hữu nội dung người dùng đăng (IP)? Có cơ chế xử lý nội dung vi phạm bản quyền/báo cáo không? Ảnh tải lên có chứa dữ liệu cá nhân (khuôn mặt người khác) thì xử lý ra sao? Khi người dùng xóa bài, ảnh có bị xóa khỏi CDN không? Điều khoản ToS cần bổ sung gì?
Tiêu chí tự chấm: (1) có bảng Data Flow; (2) định nghĩa rõ consent, retention, deletion; (3) phân biệt được "rủi ro tôi phát hiện" với "quyết định pháp lý của Legal"; (4) mọi yêu cầu đều là hành động cụ thể, không chung chung.
Tóm tắt
Legal & Compliance Spec không biến bạn thành luật sư — nó biến bạn thành một PM không gây ra thảm họa pháp lý. Bốn vùng review cốt lõi: Privacy (thu thập, consent, lưu trữ, xóa), Terms & Disclaimer, Regulatory (quy định ngành), và IP & Content Rights. Công cụ trung tâm là bảng Data Flow và, với rủi ro cao, một DPIA.
Ba nguyên tắc cần khắc cốt: (1) Đưa Legal vào sớm, ngay từ draft — đừng review sau khi build; (2) Mọi yêu cầu phải cụ thể — quy "tuân thủ luật" thành hành động đo được; (3) Đừng tự quyết pháp lý — bạn phát hiện rủi ro, Legal quyết định, và bạn ghi lại quyết định đó làm bằng chứng. Với bối cảnh PDPD/PDPL Việt Nam 2024 ngày càng siết chặt, một PM biết viết phần này chính là người giữ cho sản phẩm sống sót lâu dài.