4、合法处理基础：掌握六种合法处理基础
说实话，GDPR 里最让我头疼的，就是这六种合法处理基础。
我刚入行那会儿，总觉得「只要用户同意了，不就万事大吉了吗？」后来被罚过一次才明白——同意不是万能钥匙。你想想看，如果每个数据处理都要用户点头，业务根本跑不动。
今天我就把这六种基础掰开揉碎了讲。每个我都会结合项目里的真实案例，告诉你什么时候用、怎么用、坑在哪。
4.1 六种基础速览
先给个全景图。GDPR 第6条明确规定了六种合法处理基础：
| 编号 | 基础名称 | 英文 | 适用场景 |
|---|---|---|---|
| 1 | 同意 | Consent | 用户主动授权 |
| 2 | 合同 | Contract | 履行合同所必需 |
| 3 | 法律义务 | Legal Obligation | 法律要求必须处理 |
| 4 | 重大利益 | Vital Interests | 保护生命健康 |
| 5 | 公共利益 | Public Interest | 官方权力或公共任务 |
| 6 | 合法利益 | Legitimate Interests | 平衡双方利益 |
嗯，这里要注意：六种基础是并列关系，没有优先级。你不能说「同意比合同更合法」。选哪个，完全看你的业务场景。
4.2 同意（Consent）—— 最熟悉也最容易翻车
同意是大家最熟悉的。但 GDPR 对同意的要求，比国内严格得多。
GDPR 同意的三要素：
- 自由给予：不能捆绑，不能胁迫。比如「不同意就不让用 App」——这不行。
- 具体明确：不能笼统地说「我同意处理我的数据」。必须说清楚处理什么、为什么处理。
- 知情同意：用户得知道自己在同意什么。隐私政策里藏着的小字，不算。
我在项目中遇到过一家电商公司，他们搞了个「一键同意所有」的按钮。结果被用户投诉到监管机构，罚了20万欧元。为什么？因为用户根本不知道同意了哪些处理活动。
我的建议：
同意要分层。比如：
- 第一层：必要功能（不需要同意，基于合同）
- 第二层：个性化推荐（需要同意）
- 第三层：第三方共享（需要单独同意）
这样既合规，用户体验也好。
4.3 合同（Contract）—— 业务运转的基石
合同基础，说白了就是「为了履行合同，必须处理这些数据」。
举个例子：你在电商平台买了东西，平台必须知道你的收货地址才能发货。这个处理不需要你额外同意——合同本身就授权了。
但这里有个坑：不能把合同基础无限扩大。
我曾经踩过的坑：
有个 SaaS 客户，在用户协议里写「为了提供更好的服务，我们有权分析您的使用数据」。他们觉得这是合同必需。但监管机构认为：分析数据不是履行合同所必需，应该用同意或合法利益。最后被要求整改。
判断标准很简单：如果不处理这个数据，合同还能不能履行？如果能，那就不能用合同基础。
4.4 法律义务（Legal Obligation）—— 没得选，必须做
这个基础最硬。法律要求你处理，你就得处理，没商量。
比如：
- 税务部门要求保留交易记录7年
- 反洗钱法要求收集客户身份信息
- 劳动法要求保存员工工资记录
我个人习惯是：先列一个「法律义务清单」，把公司涉及的所有法律法规都梳理一遍。这样每次有业务部门问「这个数据能不能删」，我直接翻清单——法律要求保留的，不能删。
4.5 重大利益（Vital Interests）—— 救命用的
这个基础很少用，但关键时刻能救命。
场景很窄：处理数据是为了保护某人的生命或健康。比如：
- 医院在紧急情况下，没有时间获取患者同意，但必须处理医疗数据才能抢救
- 自然灾害中，救援组织需要处理受灾者的位置数据
注意：重大利益不能滥用。你不能说「为了公司的重大利益」——GDPR 里的「重大利益」特指生命健康，不是商业利益。
4.6 公共利益（Public Interest）—— 官方机构的特权
这个基础主要适用于公共机构。比如：
- 统计局收集人口数据
- 卫生部门追踪疫情
- 教育部门管理学生信息
企业基本用不上。但如果你和政府部门合作，承接了公共任务，那可能涉及。我记得有个做智慧城市的项目，他们帮政府管理交通数据，用的就是公共利益基础。
4.7 合法利益（Legitimate Interests）—— 最灵活也最复杂
这个基础，我个人认为是六种里最考验功力的。
合法利益允许你在「不严重影响用户权益」的前提下，基于你的合理商业利益处理数据。比如：
- 防止欺诈
- 网络安全
- 直接营销（但有限制）
- 内部管理
但使用合法利益，必须做平衡测试（Legitimate Interests Assessment, LIA）。说白了就是三步：
- 识别合法利益：你的目的是什么？比如「防止账户被盗」
- 评估对用户的影响：处理数据会不会伤害用户？比如「分析登录行为」影响很小
- 平衡：你的利益是否大于用户的影响？如果是，可以用
我的实操经验：
合法利益最适合的场景是「安全类」和「反欺诈类」。因为这些处理对用户影响小，但对公司价值大。
但直接营销用合法利益要小心。欧盟有些国家（比如德国）对营销类合法利益要求很严，最好还是用同意。
4.8 如何选择？一张决策流程图
很多同学问我：「这么多基础，到底选哪个？」
我一般按这个逻辑走：
1. 法律要求必须处理？ → 法律义务
2. 需要保护生命健康？ → 重大利益
3. 履行公共任务？ → 公共利益
4. 履行合同所必需？ → 合同
5. 有合理商业利益且不影响用户？ → 合法利益
6. 以上都不行？ → 同意注意：同意是兜底方案。如果其他基础都不适用，那就老老实实拿同意。但同意成本最高——你要设计弹窗、记录日志、提供撤回机制。
避坑指南：
我曾经见过一个项目，把「同意」当成了所有处理的默认基础。结果用户撤回同意后，系统直接崩了——因为有些处理其实是合同必需的，不应该依赖同意。
正确做法：每个处理活动单独评估，选最合适的基础，而不是一刀切。
4.9 实战：一个完整的案例
假设你是一家电商公司的 DPO，现在要处理用户数据做以下几件事：
| 处理活动 | 推荐基础 | 理由 |
|---|---|---|
| 处理订单、发货 | 合同 | 履行购买合同所必需 |
| 保存交易记录7年 | 法律义务 | 税务法要求 |
| 发送促销邮件 | 同意 | 直接营销，用户需主动授权 |
| 分析用户行为防欺诈 | 合法利益 | 保护公司利益，对用户影响小 |
| 紧急情况下联系用户 | 重大利益 | 保护用户安全（极少用） |
你看，同一个用户，不同的处理活动，用的基础完全不同。这就是合规落地的精髓——精细化、场景化。
4.10 最后说两句
六种合法处理基础，说白了就是 GDPR 给你的六把钥匙。每把钥匙开一把锁，别拿错，也别硬塞。
我个人习惯是：每做一个新功能，先问三个问题——
- 这个处理有法律依据吗？
- 用户知道吗？
- 用户能控制吗？
三个问题都答得上，基本就稳了。
嗯，今天就到这儿。下一章我们聊数据保护影响评估（DPIA）——那个才是真正烧脑的活儿。