Chương 63. Privacy, Compliance và Data Governance

Ở chương trước, ta nói về multi-tenancy.

Khi một hệ thống phục vụ nhiều tenant, ranh giới dữ liệu trở nên rất quan trọng:

Tenant nào được thấy dữ liệu nào?
User nào được làm gì trong tenant đó?
AI/RAG có lấy nhầm dữ liệu tenant khác không?
Backup, export, audit có tách tenant không?

Chương này đi thêm một lớp nữa:

Privacy, compliance và data governance.

Nói ngắn gọn:

Dữ liệu người dùng không phải chỉ là thứ để lưu và query.

Dữ liệu có quyền riêng tư.

Dữ liệu có mục đích sử dụng.

Dữ liệu có thời hạn giữ.

Dữ liệu có người được quyền truy cập và người không được quyền truy cập.

Dữ liệu có thể cần export, xóa, mask, mã hóa, audit, hoặc giữ trong một khu vực địa lý nhất định.

Và khi có AI, câu hỏi càng nhạy hơn:

Dữ liệu này có được đưa vào prompt không?
Có được dùng để training không?
Có được dùng cho analytics không?
Có được lưu trong log không?
Ai được xem prompt/response?

Thông điệp chính của chương:

> Privacy và compliance không phải lớp giấy tờ gắn sau cùng. Với hệ thống xử lý dữ liệu nhạy cảm, chúng phải ảnh hưởng đến kiến trúc từ đầu: data model, permission, logging, retention, export, deletion, analytics, AI và vận hành.

---

63.1. Một tình huống: AI Judge lưu nhiều dữ liệu nhạy cảm hơn ta tưởng

Hãy nhìn AI Judge.

Ban đầu ta có thể nghĩ:

Đây chỉ là hệ thống chấm bài.

Nhưng hệ thống này có thể lưu:

Tên học sinh.
Email.
Lớp.
Trường.
Bài làm.
File upload.
Điểm.
Feedback.
Lịch sử nộp bài.
Deadline.
Rubric.
Nhận xét giáo viên.
AI prompt.
AI response.
Log truy cập.
Analytics học tập.

Một số dữ liệu có vẻ bình thường.

Nhưng khi ghép lại, nó tạo thành hồ sơ học tập khá nhạy cảm.

Ví dụ:

Học sinh nào thường nộp trễ.
Học sinh nào điểm thấp.
Học sinh nào bị flagged cần review.
Giáo viên nào sửa điểm AI thường xuyên.
Trường nào có tỉ lệ bài lỗi cao.

Nếu hệ thống dùng AI, còn có thêm câu hỏi:

Bài làm học sinh có bị gửi cho model provider không?
Prompt/response có được log không?
Dữ liệu có được dùng để cải thiện model không?
Tenant có đồng ý không?

Đây không còn là chuyện "database có cột gì".

Đây là chuyện hệ thống quản trị dữ liệu có trách nhiệm hay không.

---

63.2. Privacy là gì?

Privacy là quyền riêng tư của người dùng và tổ chức đối với dữ liệu của họ.

Trong hệ thống phần mềm, privacy hỏi:

Ta thu thập dữ liệu gì?
Vì sao cần thu thập?
Ai được xem?
Dùng cho mục đích gì?
Giữ bao lâu?
Có chia sẻ với bên thứ ba không?
Người dùng có biết không?
Người dùng có quyền xóa/export không?

Privacy không chỉ là "không bị hack".

Bảo mật là một phần.

Nhưng privacy rộng hơn.

Ví dụ hệ thống không bị hack, nhưng vẫn có thể vi phạm privacy nếu:

Thu thập dữ liệu không cần thiết.
Dùng dữ liệu cho mục đích người dùng không đồng ý.
Giữ dữ liệu quá lâu.
Cho nhân viên nội bộ xem dữ liệu không có lý do.
Đưa dữ liệu vào AI training khi tenant không cho phép.

Privacy là thiết kế cách đối xử với dữ liệu.

Không chỉ là khóa cửa database.

---

63.3. Compliance là gì?

Compliance là việc hệ thống đáp ứng các quy định, tiêu chuẩn, hợp đồng hoặc chính sách liên quan.

Tùy lĩnh vực, compliance có thể liên quan đến:

Luật bảo vệ dữ liệu cá nhân.
Quy định giáo dục.
Quy định tài chính.
Yêu cầu khách hàng enterprise.
Chính sách nội bộ.
Hợp đồng xử lý dữ liệu.
Data residency.
Audit retention.
Quyền xóa/export dữ liệu.

Trong sách này, ta không học thuộc luật.

Điểm quan trọng là hiểu tác động kiến trúc.

Compliance có thể buộc hệ thống phải có:

Consent tracking.
Data retention policy.
Data deletion workflow.
Data export.
Audit log.
Encryption.
Access review.
Data residency.
Vendor governance.

Nếu chờ đến khi sản phẩm lớn mới nghĩ đến, sửa rất khó.

Vì dữ liệu đã nằm trong nhiều nơi:

Database.
Logs.
Backups.
Object storage.
Analytics warehouse.
Search index.
Vector index.
AI prompt logs.
Third-party services.

Compliance càng đến muộn, chi phí sửa càng cao.

---

63.4. Data governance là gì?

Data governance là cách tổ chức quản lý dữ liệu có kỷ luật.

Nó trả lời:

Dữ liệu nào tồn tại?
Ai sở hữu?
Dữ liệu có nhạy cảm không?
Dùng cho mục đích gì?
Ai được truy cập?
Chất lượng dữ liệu ra sao?
Giữ bao lâu?
Xóa thế nào?
Export thế nào?
Đưa vào analytics/AI được không?

Governance nghe có vẻ quản trị doanh nghiệp.

Nhưng trong code, nó hiện ra rất cụ thể:

Cột này có chứa PII không?
Log này có mask email không?
Backup này giữ bao lâu?
Job analytics này có lấy dữ liệu học sinh không?
RAG index này có metadata tenant/permission không?
Prompt log này ai đọc được?

Data governance tốt giúp engineer biết dữ liệu nào có thể dùng, dữ liệu nào phải bảo vệ, và dữ liệu nào không được đem đi lung tung.

Không có governance, mỗi team tự đoán.

Mà với dữ liệu nhạy cảm, đoán là rất nguy hiểm.

---

63.5. PII là gì?

PII là Personally Identifiable Information.

Hiểu đơn giản:

Dữ liệu có thể dùng để nhận diện một người.

Ví dụ:

Họ tên.
Email.
Số điện thoại.
Địa chỉ.
Mã học sinh.
Ảnh đại diện.
IP address trong một số ngữ cảnh.
Device identifier.

PII có thể trực tiếp hoặc gián tiếp.

Trực tiếp:

Email: an@example.com

Gián tiếp:

Trường + lớp + số thứ tự + thời gian nộp bài

có thể đủ để nhận ra học sinh trong một nhóm nhỏ.

Trong AI Judge, PII không chỉ nằm trong bảng users.

Nó có thể nằm trong:

File bài làm.
Nội dung bài tự luận.
Feedback.
Prompt gửi cho AI.
Log lỗi.
Screenshot support.
Export CSV.
Analytics table.

Vì vậy bảo vệ PII không chỉ là bảo vệ vài cột rõ ràng.

Phải nhìn toàn bộ luồng dữ liệu.

---

63.6. Dữ liệu nhạy cảm không chỉ là PII

PII quan trọng, nhưng không phải tất cả.

Dữ liệu nhạy cảm còn có thể là:

Điểm số.
Đánh giá năng lực.
Nhận xét giáo viên.
Thông tin hành vi.
Nội dung bài viết cá nhân.
Lịch sử kỷ luật.
Thông tin sức khỏe nếu có.
Thông tin thanh toán.
Token/API key.
Tài liệu nội bộ.
Model prompt bí mật.
Business metrics.

Một dữ liệu không nhận diện trực tiếp một người vẫn có thể nhạy cảm.

Ví dụ:

Danh sách học sinh có điểm dưới trung bình trong lớp 10A.

Nếu ai đó trong trường xem được, có thể biết là ai.

Vì vậy data classification nên có nhiều mức:

Public.
Internal.
Confidential.
Restricted.
Highly sensitive.

Mỗi mức có rule khác nhau về truy cập, logging, retention, export và AI usage.

Nếu không phân loại, hệ thống dễ xử lý mọi dữ liệu như nhau.

Và đó là nguồn rủi ro.

---

63.7. Data minimization

Data minimization nghĩa là chỉ thu thập và giữ dữ liệu thật sự cần.

Một câu hỏi rất tốt:

Ta có cần dữ liệu này để phục vụ mục đích sản phẩm không?

Ví dụ AI Judge có cần:

Ngày sinh học sinh?
Địa chỉ nhà?
Số điện thoại phụ huynh?
Ảnh đại diện?

Có thể có, có thể không.

Nếu không cần, đừng thu thập.

Dữ liệu không có trong hệ thống thì không thể bị lộ từ hệ thống đó.

Data minimization cũng áp dụng cho AI context.

Ví dụ chấm bài thường không cần đưa vào prompt:

Email học sinh.
Số điện thoại.
Thông tin gia đình.
Danh sách điểm các môn khác.

Nếu không cần cho kết quả, không đưa.

Prompt ngắn hơn, rẻ hơn, ít rủi ro hơn.

Data minimization vừa tốt cho privacy vừa tốt cho cost/latency.

---

63.8. Purpose limitation

Purpose limitation nghĩa là dữ liệu được dùng đúng mục đích đã xác định.

Ví dụ tenant đồng ý dùng dữ liệu bài làm để:

Chấm bài.
Hiển thị feedback.
Tạo báo cáo học tập cho giáo viên.

Điều đó không tự động nghĩa là ta được dùng dữ liệu đó để:

Training model thương mại.
Chạy analytics marketing.
Chia sẻ với đối tác.
Tạo benchmark công khai.

Mỗi mục đích cần được xem xét riêng.

Trong kiến trúc, purpose limitation có thể trở thành:

Metadata về consent/purpose.
Policy engine.
Data access layer kiểm tra mục đích.
Tách dataset theo mục đích.
Audit job sử dụng dữ liệu.

Ví dụ một analytics job nên khai báo:

Mục đích: usage billing.
Dữ liệu dùng: tenant_id, token_count, timestamp.
Không dùng: nội dung bài làm.

Nếu job không cần nội dung bài làm, không được lấy.

---

63.9. Consent là gì?

Consent là sự đồng ý cho một cách sử dụng dữ liệu nào đó.

Không phải mọi xử lý dữ liệu đều dựa trên consent.

Tùy bối cảnh có thể có cơ sở pháp lý hoặc hợp đồng khác.

Nhưng trong thiết kế hệ thống, điều quan trọng là:

Ta phải biết dữ liệu này được phép dùng cho mục đích nào.

Ví dụ:

Tenant cho phép dùng bài làm để chấm.
Tenant không cho phép dùng bài làm để training model.
Tenant cho phép dùng dữ liệu ẩn danh cho product analytics.
Tenant yêu cầu không gửi dữ liệu ra ngoài region.

Hệ thống cần lưu được chính sách đó.

Không nên nằm trong trí nhớ của sales hoặc một file hợp đồng không liên kết với runtime.

Với AI app, consent/policy nên ảnh hưởng trực tiếp:

Model provider nào được dùng.
Dữ liệu có được log full prompt không.
Dữ liệu có được đưa vào eval set không.
Dữ liệu có được dùng cho training/fine-tuning không.
Retention prompt logs bao lâu.

Consent không chỉ là checkbox UI.

Nó phải chảy vào kiến trúc.

---

63.10. Data retention

Data retention là chính sách giữ dữ liệu trong bao lâu.

Ví dụ:

Submission gốc giữ 5 năm.
Prompt log giữ 30 ngày.
Audit log giữ 1 năm.
Temporary export file giữ 7 ngày.
Cache giữ vài giờ.
Deleted user data xóa sau 30 ngày.

Không nên giữ mọi thứ mãi mãi.

Giữ lâu có lợi:

Debug.
Audit.
Analytics.
Khôi phục dữ liệu.

Nhưng giữ lâu cũng có rủi ro:

Dữ liệu bị lộ nhiều hơn.
Chi phí tăng.
Compliance khó hơn.
Quyền xóa dữ liệu khó hơn.

Retention nên khác nhau theo loại dữ liệu.

Trong AI Judge:

Bài nộp chính thức có thể cần giữ lâu.
Prompt raw chứa dữ liệu học sinh có thể chỉ giữ ngắn.
Metric aggregate có thể giữ lâu hơn vì không chứa nội dung cá nhân.
Temporary export nên hết hạn nhanh.

Retention phải được tự động hóa.

Nếu chỉ ghi trong tài liệu mà không có job xóa/expire, nó rất dễ bị quên.

---

63.11. Quyền xóa dữ liệu

Một số hệ thống cần hỗ trợ xóa dữ liệu theo yêu cầu user/tenant hoặc theo policy.

Xóa dữ liệu không đơn giản là xóa một row.

Dữ liệu có thể nằm ở:

Database chính.
Object storage.
Cache.
Search index.
Vector index.
Analytics warehouse.
Logs.
Backups.
Prompt logs.
Evaluation dataset.
Third-party provider.

Ví dụ xóa một học sinh khỏi AI Judge:

Xóa hoặc anonymize user profile.
Xử lý submissions.
Xử lý files.
Xử lý grading results.
Xử lý analytics.
Xử lý prompt logs có chứa bài làm.
Xử lý export files còn tồn tại.

Không phải dữ liệu nào cũng xóa cùng cách.

Có dữ liệu cần xóa.

Có dữ liệu cần anonymize.

Có dữ liệu cần giữ vì audit/legal obligation.

Có dữ liệu trong backup sẽ hết hạn theo retention.

Điểm quan trọng là phải có data map.

Nếu không biết dữ liệu nằm đâu, không thể xóa đúng.

---

63.12. Xóa mềm, xóa cứng và anonymization

Soft delete là đánh dấu đã xóa:

deleted_at = timestamp

Ưu điểm:

Dễ khôi phục.
Giữ lịch sử.
Ít phá quan hệ dữ liệu.

Nhược điểm:

Dữ liệu vẫn còn.
Không đáp ứng mọi yêu cầu xóa.
Query phải luôn filter deleted.

Hard delete là xóa thật record.

Ưu điểm:

Dữ liệu không còn trong bảng chính.

Nhược điểm:

Dễ phá audit/history.
Khó khôi phục.
Phải xử lý quan hệ dữ liệu.

Anonymization là bỏ khả năng nhận diện cá nhân.

Ví dụ:

student_name -> "Deleted User"
email -> null
student_id -> random irreversible id

Nhưng anonymization phải cẩn thận.

Nếu dữ liệu còn có thể ghép lại để nhận diện, nó chưa thật sự anonymized.

Ví dụ:

Lớp nhỏ + thời gian nộp + nội dung bài

có thể vẫn nhận ra học sinh.

Xóa dữ liệu là bài toán nghiệp vụ và kiến trúc, không chỉ là câu SQL.

---

63.13. Data export và portability

Data portability nghĩa là user/tenant có thể lấy dữ liệu của mình ra khỏi hệ thống ở định dạng có thể dùng được.

Ví dụ:

Trường muốn export toàn bộ điểm và bài nộp.
Giáo viên muốn tải rubric và feedback.
Học sinh muốn tải dữ liệu cá nhân.
Tenant chuyển sang hệ thống khác.

Export tốt cần:

Đúng phạm vi dữ liệu.
Đúng quyền.
Định dạng rõ.
Không lẫn tenant khác.
Có audit.
Có thời hạn tải file.
Có bảo vệ file export.

Định dạng có thể là:

CSV.
JSON.
ZIP chứa files + manifest.
Parquet nếu cho analytics.

Với dữ liệu phức tạp, nên có manifest:

Export gồm gì.
Tạo lúc nào.
Tenant nào.
Schema version.
Checksum nếu cần.

Export file thường chứa nhiều dữ liệu nhạy cảm.

Vì vậy nó cần permission, expiration, encryption nếu phù hợp, và audit.

Không nên tạo file export public link vĩnh viễn.

---

63.14. Audit trail cho truy cập dữ liệu

Audit trail cho biết ai truy cập dữ liệu nào, khi nào, vì sao.

Không phải mọi read đều cần audit chi tiết như nhau.

Nhưng với dữ liệu nhạy cảm, audit rất quan trọng.

Ví dụ nên audit:

Support xem dữ liệu tenant.
Admin export dữ liệu.
Giáo viên xem bài/điểm học sinh.
AI agent gọi tool đọc dữ liệu nhạy cảm.
User tải file export.
Prompt/response raw được mở để debug.
Permission được thay đổi.
Data deletion được yêu cầu/thực hiện.

Audit record nên có:

actor_id.
actor_role.
tenant_id.
action.
resource_type.
resource_id.
reason nếu cần.
timestamp.
source_ip/device nếu phù hợp.
approval_id nếu có.

Audit log phải khó sửa.

Nếu người có quyền mạnh có thể sửa audit log dễ dàng, audit mất giá trị.

Audit không chỉ để compliance.

Nó còn giúp điều tra incident và xây dựng niềm tin.

---

63.15. Data residency

Data residency là yêu cầu dữ liệu phải được lưu hoặc xử lý ở một khu vực địa lý nhất định.

Ví dụ:

Dữ liệu khách EU phải ở EU.
Dữ liệu trường trong một quốc gia không được ra khỏi quốc gia đó.
Khách enterprise yêu cầu region riêng.

Data residency ảnh hưởng kiến trúc rất mạnh.

Nó không chỉ là chọn region database.

Phải xét:

Database.
Object storage.
Backups.
Logs.
Analytics warehouse.
Search/vector index.
AI provider region.
Support access.
Monitoring data.
Third-party processors.

Nếu database ở EU nhưng prompt gửi sang provider xử lý ở region khác, có thể vẫn vi phạm yêu cầu.

Nếu log chứa PII được gửi sang hệ thống logging global ở region khác, cũng có vấn đề.

Vì vậy data residency phải được thiết kế như luồng dữ liệu end-to-end.

Không phải một flag trong database.

---

63.16. Masking

Masking là che bớt dữ liệu nhạy cảm khi hiển thị hoặc log.

Ví dụ:

email: a***@example.com
phone: ***-***-1234
student_name: Nguyễn V.

Masking hữu ích cho:

Support tooling.
Logs.
Analytics debug.
Screenshots.
Demo.
Training nội bộ.

Masking không thay thế access control.

Nếu user không có quyền xem dữ liệu, đừng chỉ mask một chút rồi cho xem.

Masking là lớp giảm rủi ro khi người dùng có lý do xem một phần dữ liệu nhưng không cần toàn bộ.

Ví dụ support có thể cần xác nhận email người dùng.

Họ có thể chỉ cần:

n***@school.edu

chứ không cần xem full email trong mọi trường hợp.

Masking cũng nên áp dụng cho logs.

Đừng log full prompt chứa bài làm học sinh vào log hệ thống chung.

---

63.17. Encryption

Encryption là mã hóa dữ liệu để người không có key không đọc được.

Có hai loại hay nói:

Encryption in transit.
Encryption at rest.

In transit:

Dữ liệu khi truyền qua mạng, ví dụ HTTPS/TLS.

At rest:

Dữ liệu khi lưu trong database, disk, object storage, backup.

Encryption rất quan trọng.

Nhưng nó không giải quyết mọi vấn đề.

Nếu app có quyền đọc dữ liệu, bug trong app vẫn có thể làm lộ dữ liệu.

Nếu support có quyền xem full data, encryption at rest không ngăn support xem.

Vì vậy encryption là một lớp.

Nó phải đi cùng:

Access control.
Audit.
Key management.
Secret separation.
Masking.
Least privilege.

Với tenant enterprise, có thể cần encryption key riêng theo tenant.

Nhưng key riêng làm vận hành phức tạp hơn.

Phải hiểu trade-off.

---

63.18. Secret separation

Secret là thông tin dùng để truy cập hệ thống hoặc dữ liệu.

Ví dụ:

Database password.
API key.
OAuth client secret.
Webhook signing secret.
Encryption key.
Model provider key.

Secret separation nghĩa là không trộn secret vào code, logs, prompt, export, hoặc config không bảo vệ.

Một số nguyên tắc:

Không commit secret vào repo.
Không log secret.
Không đưa secret vào prompt AI.
Không chia sẻ cùng key cho mọi tenant nếu không cần.
Secret có rotation.
Quyền đọc secret hạn chế.

Với AI agent, secret separation càng quan trọng.

Agent không nên thấy API key nếu nó chỉ cần gọi tool.

Tool executor giữ secret.

Agent chỉ yêu cầu:

send_webhook(...)

Hệ thống thực thi bằng secret được bảo vệ.

Không đưa secret vào context model.

Model không cần biết secret.

---

63.19. Least privilege

Least privilege nghĩa là mỗi người, service, job, agent chỉ có quyền tối thiểu cần thiết.

Ví dụ:

Worker chấm bài cần đọc submission và ghi grading result.
Nó không cần xóa tenant.
Analytics job cần aggregate token usage.
Nó không cần đọc nội dung bài làm nếu không cần.
Support staff mặc định read-only.
AI agent phải xin approval trước khi đổi feature flag.

Least privilege giảm thiệt hại khi có bug hoặc compromise.

Nếu mọi service đều dùng một database user toàn quyền, một bug nhỏ có thể phá rất rộng.

Nếu mỗi service có quyền hẹp, lỗi bị giới hạn hơn.

Least privilege không phải lúc nào cũng dễ.

Nó tăng công thiết kế quyền.

Nhưng với dữ liệu nhạy cảm, đây là nền tảng.

---

63.20. Governance cho analytics

Analytics rất dễ trở thành nơi dữ liệu nhạy cảm bị nhân bản lung tung.

Ví dụ:

Production database có kiểm soát tốt.
Nhưng ETL đẩy dữ liệu sang warehouse.
Nhiều người có quyền query warehouse.
PII nằm trong bảng analytics.
Retention không rõ.
Export từ BI tool không audit.

Data governance cho analytics cần:

Dataset classification.
PII minimization.
Pseudonymization nếu phù hợp.
Access control theo role.
Audit query/export.
Retention.
Data lineage.
Approved metrics.
Tenant isolation nếu multi-tenant.

Không phải ai làm phân tích cũng cần raw data.

Nhiều trường hợp chỉ cần aggregate:

Số bài chấm.
Latency trung bình.
Token usage.
Tỉ lệ needs_review.

Không cần nội dung bài làm.

Analytics càng mạnh, governance càng cần rõ.

---

63.21. Governance cho AI training data

AI training data là vùng cực kỳ nhạy cảm.

Câu hỏi cần trả lời:

Dữ liệu nào được phép dùng để train/fine-tune/evaluate?
Tenant nào đồng ý?
User nào đồng ý?
Dữ liệu đã được anonymize chưa?
Có chứa PII không?
Có chứa nội dung nhạy cảm không?
Dữ liệu có thể bị xóa khỏi training set không?
Model provider có dùng dữ liệu đó không?

Không nên tự động lấy production data để train.

Với AI Judge, bài làm học sinh và feedback giáo viên là dữ liệu rất giá trị.

Nhưng cũng rất nhạy cảm.

Nếu muốn dùng để cải thiện AI, cần có governance:

Policy rõ.
Consent/contract rõ.
Dataset approval.
De-identification.
Access control.
Retention.
Audit.
Versioning dataset.
Xử lý deletion request.

Evaluation set cũng cần governance.

Không phải vì chỉ dùng để eval mà được dùng tùy tiện.

Nếu eval set chứa bài làm thật, nó vẫn là dữ liệu nhạy cảm.

---

63.22. Prompt logs là dữ liệu nhạy cảm

AI app thường log prompt và response để debug.

Điều này rất hữu ích.

Nhưng prompt có thể chứa:

Nội dung bài làm.
Tên học sinh.
Rubric nội bộ.
Feedback.
Tài liệu tenant.
Thông tin cá nhân.

Response cũng có thể chứa dữ liệu nhạy cảm.

Vì vậy prompt logs không nên được đối xử như log kỹ thuật bình thường.

Cần policy:

Log metadata mặc định.
Full prompt/response chỉ lưu khi cần.
Mask/redact nếu có thể.
Retention ngắn hơn.
Access hạn chế.
Audit khi xem.
Không đưa vào công cụ logging public/rộng.
Không dùng cho training nếu chưa được phép.

Một metric như:

prompt_version, token_count, latency, cost, parse_error

thường an toàn hơn full prompt.

Ta vẫn debug được nhiều thứ mà không cần mở toàn bộ dữ liệu nhạy cảm.

---

63.23. Vendor và third-party governance

Hệ thống hiện đại dùng nhiều bên thứ ba:

Cloud provider.
Email provider.
Payment provider.
AI provider.
Analytics tool.
Logging tool.
Support tool.
CDN.
Search/vector service.

Mỗi bên có thể nhận dữ liệu.

Data governance phải biết:

Dữ liệu nào gửi cho vendor nào?
Vendor xử lý ở region nào?
Vendor có lưu dữ liệu không?
Lưu bao lâu?
Vendor có dùng dữ liệu để train không?
Có DPA/hợp đồng xử lý dữ liệu không?
Tenant có cho phép không?

Với AI provider, câu hỏi càng quan trọng:

Prompt/response có được lưu không?
Có được dùng để cải thiện model không?
Data retention của provider là gì?
Region xử lý ở đâu?
Có option zero data retention không?

Kiến trúc không chỉ là code của ta.

Nó còn là các nơi dữ liệu đi qua.

---

63.24. Data map

Data map là bản đồ dữ liệu:

Dữ liệu nào tồn tại?
Nằm ở đâu?
Chảy qua service nào?
Ai truy cập?
Gửi cho vendor nào?
Giữ bao lâu?
Xóa thế nào?

Không cần bắt đầu bằng công cụ phức tạp.

Một bảng thực tế cũng rất hữu ích.

Ví dụ:

| Dữ liệu | Nơi lưu | Nhạy cảm | Retention | Ai truy cập | Gửi vendor | |---|---|---|---|---|---| | Submission file | Object storage | Cao | 5 năm | Student/teacher/admin | AI provider khi chấm | | Prompt metadata | DB/log | Trung bình | 1 năm | Engineering/ops | Không | | Full prompt | Secure log store | Cao | 30 ngày | Limited ops | AI provider | | Token usage | Analytics | Thấp/trung bình | 2 năm | Product/billing | Không |

Data map giúp trả lời deletion/export/compliance nhanh hơn.

Không có data map, mỗi yêu cầu privacy trở thành cuộc săn tìm dữ liệu.

---

63.25. Data lineage

Data lineage là nguồn gốc và đường đi của dữ liệu.

Ví dụ:

Submission file
-> Prompt builder
-> AI provider
-> Model response
-> Grading result
-> Teacher dashboard
-> Analytics aggregate

Lineage giúp biết:

Nếu dữ liệu gốc sai, downstream nào bị ảnh hưởng?
Nếu user yêu cầu xóa, bảng/index nào cần xử lý?
Nếu prompt log chứa PII, nó đến từ đâu?
Nếu analytics metric sai, nguồn nào tạo ra?

Lineage không cần hoàn hảo ngay.

Nhưng với dữ liệu quan trọng, ta nên biết đường đi chính.

Đặc biệt với AI/RAG:

Document nào được retrieve?
Đưa vào prompt nào?
Tạo response nào?
Response ảnh hưởng decision nào?

Không có lineage, rất khó audit AI decision.

---

63.26. Khi compliance phải ảnh hưởng kiến trúc từ đầu

Một số yêu cầu nếu để muộn sẽ rất đau.

Ví dụ:

Data residency.
Tenant isolation mạnh.
Right to delete.
Audit trail đầy đủ.
Customer-managed encryption keys.
Không dùng dữ liệu cho training.
Export toàn bộ dữ liệu tenant.
Retention khác nhau theo tenant.

Nếu data residency cần từ đầu nhưng ta đã xây một global database và global logging pipeline, sửa rất lớn.

Nếu right to delete cần nhưng dữ liệu đã copy vào logs, warehouse, vector index, backups mà không có map, xóa rất khó.

Nếu audit trail cần nhưng hệ thống chưa từng ghi ai xem gì, không thể tạo lại quá khứ.

Vì vậy khi bắt đầu sản phẩm, nên hỏi sớm:

Khách hàng mục tiêu là ai?
Dữ liệu có nhạy cảm không?
Có trẻ em/học sinh/bệnh nhân/tài chính không?
Có enterprise không?
Có multi-region không?
Có AI training không?
Có yêu cầu xóa/export không?

Không cần xây mọi thứ enterprise từ ngày đầu.

Nhưng cần tránh quyết định khóa đường sau này.

---

63.27. Privacy by design

Privacy by design nghĩa là privacy được đưa vào thiết kế từ đầu.

Không phải:

Xây xong rồi hỏi legal xem có ổn không.

Trong thực tế, privacy by design có thể là:

Chỉ thu thập dữ liệu cần.
Tenant-aware permission từ đầu.
PII classification trong schema.
Log redaction mặc định.
Retention job từ đầu.
Export/delete workflow có đường thiết kế.
AI prompt không chứa dữ liệu thừa.
Provider policy được kiểm tra trước.
Audit support access.

Nó không nhất thiết làm sản phẩm chậm.

Ngược lại, nó giảm nợ kỹ thuật privacy.

Vì sửa privacy sau khi dữ liệu đã lan rộng thường rất đắt.

Privacy by design là cách đi chậm một chút ở đầu để tránh trả giá lớn về sau.

---

63.28. AI Judge: kiến trúc privacy thực dụng

Với AI Judge, một kiến trúc privacy thực dụng có thể gồm:

Data classification:

PII: tên, email, mã học sinh.
Sensitive education data: bài làm, điểm, feedback.
Operational metadata: token, latency, prompt version.
Aggregate analytics: usage theo tenant.

Data minimization:

Prompt chấm bài không đưa email/số điện thoại.
Analytics cost không lấy nội dung bài.
Support view mask dữ liệu mặc định.

Retention:

Submission giữ theo policy tenant.
Full prompt logs giữ ngắn.
Temporary export hết hạn.
Audit logs giữ theo yêu cầu.

Access control:

Teacher chỉ xem lớp mình.
Support cần reason và audit.
Agent tool enforce permission.
Raw prompt/response chỉ limited ops xem.

AI governance:

Không dùng production bài làm để training nếu tenant chưa cho phép.
Eval set có approval và de-identification.
Model provider policy rõ.
Prompt/response logging có retention và access control.

Data rights:

Export tenant.
Delete/anonymize user theo policy.
Restore không làm sống lại dữ liệu đã xóa sai cách.

Đây là các quyết định kiến trúc, không phải chỉ là trang policy.

---

63.29. Testing privacy và governance

Privacy cũng cần test.

Ví dụ:

User tenant A không export được tenant B.
Teacher không xem được bài lớp khác.
Support access tạo audit log.
Prompt builder không đưa email vào prompt.
Log redaction che PII.
Delete user xóa/anonymize đúng bảng.
Export file hết hạn sau 7 ngày.
RAG không retrieve tài liệu tenant khác.
Agent write tool cần approval.

Một số test là unit/integration.

Một số là audit định kỳ.

Một số là privacy review trước release.

Không nên chỉ dựa vào niềm tin.

Nếu privacy rule quan trọng, hãy biến nó thành test hoặc check tự động ở nơi có thể.

Ví dụ:

CI kiểm tra log không chứa field cấm.
Prompt builder test không include PII không cần thiết.
Permission integration test cross-tenant.
Data deletion integration test với dataset mẫu.

Governance càng tự động, càng ít phụ thuộc trí nhớ con người.

---

63.30. Những sai lầm phổ biến

Sai lầm thứ nhất:

Nghĩ privacy chỉ là bảo mật database.

Privacy rộng hơn security. Nó gồm mục đích sử dụng, retention, consent, export, deletion và governance.

Sai lầm thứ hai:

Log dữ liệu nhạy cảm quá nhiều.

Log thường ít được kiểm soát hơn database, nhưng lại chứa dữ liệu thật.

Sai lầm thứ ba:

Không biết dữ liệu nằm ở đâu.

Không có data map thì export/delete/compliance rất khó.

Sai lầm thứ tư:

Dùng dữ liệu production cho AI training/eval tùy tiện.

Đây là rủi ro lớn, nhất là với dữ liệu học sinh, y tế, tài chính hoặc enterprise.

Sai lầm thứ năm:

Chỉ mask ở UI nhưng backend vẫn trả full data cho người không cần.

Masking không thay thế permission.

Sai lầm thứ sáu:

Không audit support/admin access.

Đường nội bộ có quyền rộng nên càng cần audit.

Sai lầm thứ bảy:

Data residency chỉ xét database.

Logs, backups, analytics, AI provider và monitoring cũng là luồng dữ liệu.

Sai lầm thứ tám:

Không tính retention từ đầu.

Dữ liệu tích tụ ở khắp nơi rồi mới muốn xóa sẽ rất mệt.

---

63.31. Checklist privacy và data governance

Khi thiết kế hệ thống xử lý dữ liệu nhạy cảm, hãy hỏi:

• Dữ liệu nào là PII?
• Dữ liệu nào nhạy cảm dù không phải PII?
• Có data classification không?
• Có data map không?
• Mục đích thu thập từng loại dữ liệu là gì?
• Có thu thập dữ liệu không cần thiết không?
• Dữ liệu được giữ bao lâu?
• Retention có được tự động hóa không?
• User/tenant có quyền export không?
• User/tenant có quyền xóa/anonymize không?
• Dữ liệu nằm trong logs/backups/warehouse/index không?
• Prompt/response AI có chứa dữ liệu nhạy cảm không?
• Full prompt logs ai được xem?
• Dữ liệu có được dùng cho training/evaluation không?
• Consent/policy có ảnh hưởng runtime không?
• Support/admin access có audit không?
• Data residency có yêu cầu không?
• Vendor nào nhận dữ liệu?
• Vendor có lưu/train trên dữ liệu không?
• Encryption/key management có phù hợp không?
• Secret có bị đưa vào code/log/prompt không?

Nếu nhiều câu trả lời là "không biết", hệ thống chưa quản trị dữ liệu đủ tốt.

---

63.32. Bảng nhìn nhanh

| Khái niệm | Hiểu đơn giản | |---|---| | Privacy | Cách hệ thống tôn trọng quyền riêng tư dữ liệu | | Compliance | Đáp ứng luật, hợp đồng, tiêu chuẩn, chính sách | | Data governance | Quản lý dữ liệu có kỷ luật: ai dùng, dùng gì, vì sao | | PII | Dữ liệu có thể nhận diện cá nhân | | Data minimization | Chỉ thu thập/đưa vào context dữ liệu cần thiết | | Purpose limitation | Dữ liệu chỉ dùng đúng mục đích được phép | | Consent | Sự đồng ý hoặc chính sách cho một cách dùng dữ liệu | | Retention | Giữ dữ liệu trong bao lâu | | Data export | Cho user/tenant lấy dữ liệu của mình | | Audit trail | Ghi lại ai truy cập/làm gì với dữ liệu | | Data residency | Dữ liệu phải ở/xử lý trong khu vực nhất định | | Masking | Che bớt dữ liệu nhạy cảm khi hiển thị/log | | Encryption | Mã hóa dữ liệu khi truyền/lưu | | Data lineage | Biết dữ liệu đi từ đâu đến đâu |

---

63.33. Kết luận của chương

Privacy, compliance và data governance không phải phần phụ của hệ thống.

Chúng quyết định dữ liệu được thu thập, dùng, lưu, xóa, export, audit và chia sẻ ra sao.

Với hệ thống có AI, chúng càng quan trọng.

Vì prompt, response, retrieval, memory, logs, evaluation set và training data đều có thể chứa dữ liệu nhạy cảm.

Một hệ thống tốt không chỉ hỏi:

Ta có thể làm gì với dữ liệu này?

Mà còn hỏi:

Ta có được phép làm không?
Có cần làm không?
Ai được xem?
Giữ bao lâu?
Xóa/export thế nào?
Nếu đưa vào AI thì rủi ro gì?

Thông điệp cần nhớ:

> Dữ liệu càng có giá trị, trách nhiệm càng lớn. Kiến trúc hiện đại không chỉ tối ưu lưu trữ và truy vấn dữ liệu, mà còn phải quản trị vòng đời, quyền truy cập, mục đích sử dụng và rủi ro của dữ liệu.

Ở chương tiếp theo, ta sẽ nói về Money, Ledger và Reconciliation: khi hệ thống chạm vào tiền, số dư, thanh toán hoặc giao dịch không được sai, ta cần tư duy ledger, idempotency mạnh, state machine và đối soát thay vì chỉ update một cột balance.