Bài 83 – Dữ liệu khách hàng nên được chia sẻ nội bộ đến mức nào? thuộc series Marketing BĐS số. Bài được thiết kế theo hướng quản trị thực hành: biến các nguyên tắc pháp lý, dữ liệu và đạo đức thành quy trình, bằng chứng và điểm kiểm soát có thể áp dụng trong chiến dịch.
Biên soạn: ThS. Nguyễn Mạnh Hùng
Đơn vị: GV. Khoa QLĐĐ&BĐS – ĐH Nông Lâm TP.HCM
Email: nguyenmanhhung@hcmuaf.edu.vn
Cập nhật 30/09/2026: Nội dung được biên soạn cho mục đích giảng dạy Marketing BĐS số, không phải ý kiến pháp lý cho một hồ sơ cụ thể. Các yêu cầu pháp lý được trình bày theo khung pháp luật đang có hiệu lực tại thời điểm biên soạn; khi triển khai thực tế cần đối chiếu văn bản hiện hành, vai trò của các bên và tình huống cụ thể.
Ranh giới chuyên đề: Bài thuộc phần dữ liệu cá nhân, pháp lý và đạo đức số. Nội dung giúp nhận diện rủi ro và thiết kế kiểm soát trong Marketing BĐS số; không thay thế tư vấn pháp lý cho tình huống cụ thể. Kỹ thuật bảo mật/API/SQL thuộc Tin học BĐS.
1. Việc dữ liệu nằm 'trong cùng công ty' không có nghĩa mọi nhân viên đều nên thấy toàn bộ hồ sơ khách; quyền truy cập cần bám mục đích và trách nhiệm công việc
Việc dữ liệu nằm 'trong cùng công ty' không có nghĩa mọi nhân viên đều nên thấy toàn bộ hồ sơ khách; quyền truy cập cần bám mục đích và trách nhiệm công việc.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
2. Nguyên tắc need-to-know yêu cầu mỗi vai trò chỉ nhận dữ liệu cần cho nhiệm vụ: Marketing cần source/lifecycle; Sales cần nhu cầu và lịch sử liên hệ; quản trị hệ thống cần quyền kỹ thuật nhưng không mặc định dùng dữ liệu cho mục đích kinh doanh
Nguyên tắc need-to-know yêu cầu mỗi vai trò chỉ nhận dữ liệu cần cho nhiệm vụ: Marketing cần source/lifecycle; Sales cần nhu cầu và lịch sử liên hệ; quản trị hệ thống cần quyền kỹ thuật nhưng không mặc định dùng dữ liệu cho mục đích kinh doanh.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
3. Least privilege nên áp dụng cả ở màn hình, API, file export và dashboard; một màn hình che số điện thoại không đủ nếu nhân viên vẫn có thể xuất Excel toàn bộ database
Least privilege nên áp dụng cả ở màn hình, API, file export và dashboard; một màn hình che số điện thoại không đủ nếu nhân viên vẫn có thể xuất Excel toàn bộ database.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
| Câu hỏi | Thiết kế cần chốt | Bằng chứng |
|---|---|---|
| Mục đích? | Purpose/use case | Register |
| Nguồn? | Source-of-truth | Evidence |
| Ai? | Owner/access | RACI/log |
| Điều kiện? | Rule/consent/claim scope | Version |
| Kiểm soát? | Approval/monitoring | Audit trail |
4. Role-based access cần phân vai rõ giữa nhân viên, trưởng nhóm, agency, đối tác, call center, nhà cung cấp CRM và người quản trị; tài khoản dùng chung làm mất khả năng truy vết
Role-based access cần phân vai rõ giữa nhân viên, trưởng nhóm, agency, đối tác, call center, nhà cung cấp CRM và người quản trị; tài khoản dùng chung làm mất khả năng truy vết.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
5. Dữ liệu nhạy cảm hoặc trường không cần thiết cho tác vụ nên được masking/ẩn hoặc tách quyền truy cập; không nên đưa toàn bộ hồ sơ vào nhóm chat để 'tiện phối hợp'
Dữ liệu nhạy cảm hoặc trường không cần thiết cho tác vụ nên được masking/ẩn hoặc tách quyền truy cập; không nên đưa toàn bộ hồ sơ vào nhóm chat để 'tiện phối hợp'.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
6. Chia sẻ cho bên thứ ba cần xem xét vai trò, mục đích, phạm vi, điều khoản, bảo mật và khả năng kiểm soát sau chia sẻ; không nên coi file đã gửi cho agency là 'dữ liệu ngoài trách nhiệm'
Chia sẻ cho bên thứ ba cần xem xét vai trò, mục đích, phạm vi, điều khoản, bảo mật và khả năng kiểm soát sau chia sẻ; không nên coi file đã gửi cho agency là 'dữ liệu ngoài trách nhiệm'.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
7. Audit log và access review định kỳ giúp phát hiện quyền dư thừa, tài khoản cũ, download bất thường hoặc nhân viên đã chuyển vị trí nhưng vẫn còn quyền
Audit log và access review định kỳ giúp phát hiện quyền dư thừa, tài khoản cũ, download bất thường hoặc nhân viên đã chuyển vị trí nhưng vẫn còn quyền.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
8. Khi nhân viên nghỉ, đổi dự án hoặc khách yêu cầu hạn chế/dừng xử lý, entitlement và workflow phải thay đổi tương ứng; access lifecycle quan trọng như data lifecycle
Khi nhân viên nghỉ, đổi dự án hoặc khách yêu cầu hạn chế/dừng xử lý, entitlement và workflow phải thay đổi tương ứng; access lifecycle quan trọng như data lifecycle.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
Ma trận trọng tâm
| Vai trò | Nên thấy | Không mặc định thấy |
|---|---|---|
| Marketing | Source/behavior/lifecycle | Ghi chú nhạy cảm không cần |
| Sales | Need/history/contact | Toàn database |
| Manager | Team pipeline | Export tùy ý |
| Agency | Data scoped | Master customer list |
| Admin | Technical access | Business use ngoài nhiệm vụ |
Khung pháp lý dữ liệu cá nhân đang áp dụng
Tại thời điểm biên soạn, Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 và Nghị định 356/2025/NĐ-CP đã có hiệu lực từ ngày 01/01/2026. Nghị định 356 xác định số điện thoại thuộc dữ liệu cá nhân cơ bản. Điều 9 của Luật 91/2025/QH15 quy định sự đồng ý phải dựa trên sự tự nguyện và biết rõ thông tin về loại dữ liệu, mục đích, bên kiểm soát/kiểm soát và xử lý cùng các quyền, nghĩa vụ; sự đồng ý phải rõ ràng, cụ thể, có thể kiểm chứng và theo từng mục đích.
Đối với Marketing BĐS số, ý nghĩa thực hành là không thể coi việc có số điện thoại trong file là mặc nhiên có quyền dùng cho mọi chiến dịch. Data governance phải trả lời được nguồn, mục đích, phạm vi, trạng thái đồng ý hoặc căn cứ xử lý phù hợp, quyền truy cập và vòng đời dữ liệu.
Tình huống giả lập phục vụ giảng dạy
Một file Excel 25.000 lead gồm số điện thoại, ngân sách và ghi chú được gửi vào nhóm chat 70 người để mọi người cùng gọi. Hãy thiết kế lại quyền truy cập, routing, masking, export và audit.
Sinh viên phải nhận diện rủi ro, dữ liệu/bằng chứng còn thiếu, người chịu trách nhiệm, control trước khi chạy và cách theo dõi sau khi chạy. Với case performance, phải tách lỗi media, website, data, CRM và Sales thay vì đổ lỗi cho một bộ phận.
Internal Data Access Model
Một hệ thống quản trị tốt cần biến nguyên tắc thành artefact có thể kiểm tra: register, rule, owner, version, evidence, alert và decision record. Không nên dựa vào trí nhớ cá nhân hoặc trao đổi rời rạc trong nhóm chat. Khi có khiếu nại, audit hoặc hiệu quả đi xuống, tổ chức phải truy được ai quyết định, dựa trên dữ liệu nào và phiên bản nào đã chạy.
| Thành phần | Câu hỏi kiểm soát | Artefact |
|---|---|---|
| Definition | Khái niệm được hiểu thế nào? | Data/claim dictionary |
| Source | Thông tin từ đâu? | Evidence/source register |
| Owner | Ai chịu trách nhiệm? | RACI |
| Version | Phiên bản nào? | Version history |
| Approval | Ai duyệt? | Approval log |
| Monitoring | Theo dõi gì? | Dashboard/alerts |
| Incident | Nếu sai thì sao? | Playbook |
Pre-mortem: giả định chiến dịch đã thất bại
Trước khi xuất bản, nhóm nên giả định sau 30 ngày chiến dịch gây khiếu nại, dữ liệu bị dùng sai hoặc Sales nói lead rất kém. Sau đó liệt kê các nguyên nhân có thể: claim cũ, consent mơ hồ, form quá rộng, audience lệch, automation không suppress, source mất, affiliate gian lận hoặc AI tạo nội dung sai. Pre-mortem giúp đặt kiểm soát trước khi hậu quả xảy ra.
| Rủi ro | Early signal | Preventive control | Recovery |
|---|---|---|---|
| Claim lỗi thời | Update mismatch | Expiry date | Pause/update |
| Consent gap | Unknown status | Consent record | Suppress/re-consent |
| Data leak | Bulk export | Access alert | Revoke/investigate |
| Lead fraud | Invalid rate↑ | Validation | Block source |
| AI error | Fact mismatch | Human gate | Withdraw/correct |
| Funnel leak | Stage drop | Monitoring | Experiment/fix |
Decision Record
Mỗi quyết định rủi ro cao nên ghi mục tiêu, dữ liệu, giả định, bằng chứng, người duyệt, thời điểm, phạm vi, guardrail và ngày review. Decision Record đặc biệt hữu ích với claim pháp lý/giá, thay đổi consent, chia sẻ database, mở affiliate mới, bật auto-publish AI hoặc thay scoring/routing.
Ma trận mức độ rủi ro
| Mức | Ví dụ | Xử lý |
|---|---|---|
| Thấp | Copy/format không chứa claim nhạy cảm | Review thường |
| Vừa | Form, nurture, personalization | Owner + test |
| Cao | Giá, pháp lý, scarcity, customer data export | Approval + evidence |
| Rất cao | Leak, fraud lớn, claim sai diện rộng | Pause/escalate/incident |
Checklist áp dụng
- Xác định mục tiêu và phạm vi chiến dịch.
- Kiểm source-of-truth cho dữ liệu và claim.
- Kiểm data fields/mục đích/consent hoặc căn cứ phù hợp.
- Kiểm quyền truy cập và bên thứ ba.
- Kiểm giá/inventory/pháp lý/tiến độ và ngày cập nhật.
- Kiểm AI/visual provenance và disclosure.
- Kiểm tracking/CRM/SLA/suppression.
- Đặt severity và người sign-off.
- Theo dõi complaints, data health và downstream quality.
- Có rollback/incident plan.
Những sai lầm cần tránh
- Có số điện thoại rồi cho rằng được dùng cho mọi mục đích.
- Một checkbox gộp nhiều mục đích.
- Gửi database vào nhóm chat vì tiện.
- Dùng giá mồi hoặc scarcity không có nguồn.
- Dùng từ tuyệt đối mà không có evidence.
- Cho AI tự bịa hoặc tự publish claim.
- Tin CPL thấp mà bỏ contactability/SQL.
- Chỉ đọc platform dashboard khi nghi gian lận.
- Không có expiry date cho price/inventory claim.
- Không lưu bằng chứng và người phê duyệt.
Bài tập thực hành
- Audit một form thu lead BĐS.
- Thiết kế consent record theo từng mục đích.
- Thiết kế RBAC cho Marketing–Sales–Agency.
- Viết lại một mẫu quảng cáo giá mồi.
- Lập evidence pack cho 5 claim.
- Thiết kế AI pre-publish gate.
- Thiết kế fraud investigation checklist.
- Lập go/no-go board cho một campaign.
- Chẩn đoán case traffic cao ít lead.
- Chẩn đoán case CPL thấp quality kém.
Câu hỏi tự kiểm tra
- Dữ liệu này được thu để làm gì?
- Khách có thể hiểu khác với thông điệp không?
- Claim có nguồn, điều kiện và thời điểm không?
- Ai có quyền truy cập/xuất dữ liệu?
- AI đang hỗ trợ hay đang quyết định thay người?
- Nếu có khiếu nại, tôi truy được bằng chứng không?
Ghi nhớ trong 30 giây
- Việc dữ liệu nằm 'trong cùng công ty' không có nghĩa mọi nhân viên đều nên thấy toàn bộ hồ sơ khách; quyền truy cập cần bám mục đích và trách nhiệm công việc.
- Nguyên tắc need-to-know yêu cầu mỗi vai trò chỉ nhận dữ liệu cần cho nhiệm vụ: Marketing cần source/lifecycle; Sales cần nhu cầu và lịch sử liên hệ; quản trị hệ thống cần quyền kỹ thuật nhưng không mặc định dùng dữ liệu cho mục đích kinh doanh.
- Role-based access cần phân vai rõ giữa nhân viên, trưởng nhóm, agency, đối tác, call center, nhà cung cấp CRM và người quản trị; tài khoản dùng chung làm mất khả năng truy vết.
- Chia sẻ cho bên thứ ba cần xem xét vai trò, mục đích, phạm vi, điều khoản, bảo mật và khả năng kiểm soát sau chia sẻ; không nên coi file đã gửi cho agency là 'dữ liệu ngoài trách nhiệm'.
- Khi nhân viên nghỉ, đổi dự án hoặc khách yêu cầu hạn chế/dừng xử lý, entitlement và workflow phải thay đổi tương ứng; access lifecycle quan trọng như data lifecycle.
Nguồn tham khảo
- Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15, có hiệu lực từ 01/01/2026.
- Nghị định số 356/2025/NĐ-CP quy định chi tiết một số điều và biện pháp thi hành Luật Bảo vệ dữ liệu cá nhân, có hiệu lực từ 01/01/2026.
- Luật sửa đổi, bổ sung một số điều của Luật Quảng cáo số 75/2025/QH15, có hiệu lực từ 01/01/2026.
- Nghị định số 87/2026/NĐ-CP quy định xử phạt vi phạm hành chính trong lĩnh vực văn hóa và quảng cáo, có hiệu lực từ 15/05/2026.
- Luật Bảo vệ quyền lợi người tiêu dùng số 19/2023/QH15 và Nghị định số 55/2024/NĐ-CP.
- Luật Kinh doanh bất động sản số 29/2023/QH15 và các văn bản sửa đổi, hướng dẫn có liên quan.
- NIST AI Risk Management Framework – tham khảo quản trị rủi ro AI, không thay thế pháp luật Việt Nam.
Bài tiếp theo: “Tin mồi, giá mồi và nội dung khan hiếm giả gây rủi ro gì?”.