3、核心原则解析：合法、正当、必要、诚信原则；目的限制；数据最小化；准确性；存储限制；完整性保密性；问责制

好，咱们直接进入正题。这七个原则，说白了就是数据合规的「七寸」。你把这七个点拿捏住了，整个体系的大框架就不会歪。我见过太多团队，上来就搞技术方案、搞加密算法，结果连最基本的「合法性」都没论证清楚——嗯，那后面全是白搭。

3.1 合法、正当、必要与诚信原则

这四个词经常被放在一起说，但它们的侧重点完全不同。

• 合法：你得有法律依据。要么用户同意，要么是履行合同所必需，要么是法定义务。没有「我觉得差不多」这种说法。
• 正当：处理方式不能「阴」。你不能说「为了改善服务」去偷偷扫描用户的相册。我在项目中遇到过一家做智能相框的公司，他们收集用户照片是为了分析家庭成员构成——用户根本不知道。这就是不正当。
• 必要：只处理实现业务目标所必需的数据。多一个字段都不行。
• 诚信：别忽悠用户。隐私政策里写的和实际做的必须一致。

3.2 目的限制

这个原则很简单：你当初为什么收集，就只能为什么用。

举个例子：用户为了下单提供了手机号，你不能拿这个手机号去做营销推送。除非你重新获得同意。

我个人习惯在系统设计阶段就做一件事：给每个数据字段打上「目的标签」。比如：

字段：手机号
目的：订单通知（不可用于营销）
有效期：订单完成后30天

这样，开发人员拿到数据时，就知道这个字段的「使用边界」在哪里。

3.3 数据最小化

这是我最喜欢的一个原则。为什么？因为它直接帮你省钱、省力、省风险。

数据最小化的核心就一句话：只收集你当下需要的，别想着「以后可能有用」。

我参与过一个电商项目，产品经理要求收集用户的「身高、体重、鞋码」——说是为了未来推荐服装。我当时就问了一句：「你现在有服装业务吗？」他说没有。我说：「那就别收。」

你想想看，你收了一堆用不上的数据，万一泄露了，责任全是你的。何必呢？

场景	常见错误	正确做法
用户注册	要求填写性别、生日、职业	只收集邮箱/手机号
订单处理	收集身份证号	只收集收货地址和联系方式
客服咨询	记录完整对话录音	只记录关键信息摘要

3.4 准确性

这个原则容易被忽略。很多人觉得「数据准不准是业务的事，跟合规有什么关系？」

关系大了。如果你基于不准确的数据做决策，比如给用户推荐了错误的产品，或者更严重的——给用户打上了错误的信用标签，那用户是可以起诉你的。

我建议的做法是：给用户提供数据更正入口。比如在个人中心里，让用户可以随时修改自己的信息。同时，系统内部也要做数据校验，比如手机号格式、邮箱格式等。

3.5 存储限制

数据不能无限期保存。这是很多企业的通病——数据越堆越多，最后自己都不知道存了什么。

我个人习惯的做法是：给每类数据设定明确的保留期限。比如：

• 订单数据：保存3年（税务要求）
• 日志数据：保存6个月
• 用户头像：用户注销后立即删除

然后，写一个定时任务，每天跑一次，把过期的数据清理掉。别手动删，容易出事故。

3.6 完整性与保密性

这两个原则其实对应的是信息安全的三要素中的两个（另一个是可用性）。

• 完整性：数据不能被篡改。比如用户的余额，不能因为系统bug就变了。
• 保密性：数据不能被未授权的人看到。比如用户的密码，必须加密存储。

实现方式其实很成熟：

# 完整性：使用哈希校验
存储时：hash(data + salt)
读取时：对比 hash 是否一致

# 保密性：使用加密
存储时：AES-256 加密
传输时：TLS 1.2+

嗯，这里要注意：加密不是万能的。密钥管理才是真正的难点。我见过不少公司，加密做得很好，但密钥直接写在配置文件里，跟没加密一样。

3.7 问责制

最后一个原则，也是最重要的一个——出了事，谁负责？

问责制要求企业必须指定一个人（或一个团队）来承担数据保护的责任。这个人就是DPO（数据保护官）。

但光有DPO不够。我建议的做法是：把责任分解到每个业务线。比如：

• 电商团队：对用户订单数据负责
• 营销团队：对用户偏好数据负责
• 技术团队：对系统日志数据负责

这样，出了问题不会互相推诿。而且，每个团队都要定期做数据保护影响评估（DPIA）。

好了，七个原则讲完了。你可能会觉得有点多，但其实核心就一句话：尊重用户的数据，就像尊重你自己的钱一样。下一章，咱们聊聊怎么把这些原则落地到具体的系统架构里。