合法处理数据的法律基础：同意、合同、法律义务
说白了，GDPR 第六条是整部法规的“地基”。没有合法的法律基础，你处理任何个人数据都是违法的。我刚开始接触 GDPR 审计时，总以为只要用户点了同意就万事大吉——后来被一位数据保护官一句话点醒：“同意不是万能钥匙，用错了地方反而更危险。”
这一章我们就聚焦三个最常用的基础：同意、合同、法律义务。审计日志里 90% 的数据处理活动都踩着这三条线走。
1. 同意（Consent）——最常用，也最容易翻车
GDPR 对同意的要求比很多人想象中严格。不是点一下“我同意”就完了。第 7 条和《关于同意的指南》（WP29）讲了四个要件：自由给予、具体、知情、明确指示。嗯，字面意思，但落地时全是坑。
审计检查点（同意）
- 用户是否真正拥有自由选择权？捆绑同意无效（比如：用服务换同意）
- 同意声明是否独立于其他条款？不能藏在隐私政策第 5 页
- 撤回同意是否和给予一样简单？不能设置“需要打电话才能撤回”
- 记录：是否留存了当时同意的时间、内容、版本？
我个人习惯在审计日志里增加一个字段：consent_retraction_url。如果用户撤回后这个字段还是空的，那肯定有问题。曾经有一个电商客户，把“同意营销推送”放在注册流程的默认勾选框里，结果被德国监管罚款 20 万欧——因为用户要取消勾选才能拒绝，这叫“不自由”。
💡 小技巧：日志里不仅要记录“是否同意”，还要记录“同意获取时的上下文”。比如：用户所在页面地址、用户代理（UA）、同意版本号。这样万一用户投诉，你能拿证据出来自证清白。
2. 合同（Contract）——处理数据是为了履约，别乱扩展
GDPR 第 6(1)(b) 条说：处理是履行合同所必需的，或者应数据主体要求采取措施的，就不用再额外要同意了。你想想看，电商下单必须处理收件地址和手机号，这是天经地义的。
但我见过太多 overscoping 的情况。某 SaaS 公司把用户的工作邮箱拿去发营销邮件，然后辩称“合同履行需要”——这是站不住脚的。只有必不可少的数据才能靠合同基础。
⚠ 避坑指南
我曾经审计过一个招聘平台，他们把候选人的简历数据用在算法推荐上，说这是“合同履行”的一部分。其实候选人只是上传简历找工作，并没有允许平台拿去做推荐训练。合同基础管不了增值服务。后来他们不得不转为同意基础，然后补发通知。
日志里怎么体现？我建议对每笔数据处理记录，打上“必要性标签”：这个字段是不是不填就完成不了合同？如果是，打上 contract_necessary: true；否则就需要切换到其他法律基础。
3. 法律义务（Legal Obligation）——只要法律明确要求，你就有权处理
GDPR 第 6(1)(c) 条说：处理是数据控制者履行法律义务所必需的。注意，这里的“法律”不是公司内部制度，而是欧盟或成员国法律。比如：雇主处理员工的税务信息、银行处理反洗钱信息。
审计时最容易忽略的一点是：法律义务必须有具体条款支撑。不能模棱两可说“为了合规”。我遇到过一起案例，一家物流公司说“行业惯例”要求他们保存包裹内容清单两年——结果行业惯例不是法律，照样被罚。
💡 建议：在日志的 legal_basis 字段里，直接引用法律条文编号和名称。例如 “Art. 6(1)(c) GDPR + § 34a BDSG”。这样审计员一眼就知道你的依据。
三者对比一览
| 法律基础 | 适用场景 | 核心要求 | 日志审计要点 |
|---|---|---|---|
| 同意 | 营销推送、非必需的数据收集 | 自由、具体、知情、可撤回 | 记录撤回路径、版本号、时间戳 |
| 合同 | 电商、订阅服务、订单处理 | 必要性测试，不能扩张 | 标记字段是否为履约所必需 |
| 法律义务 | 税务、劳动法、反洗钱 | 有明确法律条款依据 | 记录具体法律条文编号 |
最后说句实在的：选择法律基础不是“选一个就行”，而是一个动态判断。同一种数据处理活动，随时间变化可能基础也得换。比如用户停止使用你的服务后，合同基础就不成立了，需要看是否转到法律义务或合法利益。日志巡检就是帮你发现这种“基础漂移”的工具。记住了，日志清晰，审计不慌。
🚨 核心红线
- 不要用“同意”来覆盖合同履行已经够用的场景——合同更稳固，同意可撤回。
- 法律义务必须有条文，不能自己解读“应该合规”。
- 三种基础不允许混用：一条处理记录只能有一个主导基础。