4、合法处理基础：GDPR六大合法基础 vs 数据法案的同意与合同例外
这个话题，说白了就是「你凭什么处理我的数据？」。我在好几个跨境项目中，都被客户问过同一个问题：GDPR和数据法案，到底听谁的？嗯，今天咱们就把这个核心问题拆开揉碎了讲清楚。
4.1 GDPR的六大合法基础
GDPR第6条明确规定了六种合法处理基础。我个人习惯把它们分成两类：「主动型」和「被动型」。
| 合法基础 | 适用场景 | 我的经验 |
|---|---|---|
| 同意（Consent） | 用户主动授权 | 最常见，但也是最容易被滥用的 |
| 合同履行（Contract） | 提供服务所必需 | 比如电商发货必须用地址 |
| 法律义务（Legal Obligation） | 法律要求必须处理 | 比如税务申报 |
| 重大利益（Vital Interests） | 保护生命健康 | 紧急医疗场景 |
| 公共利益（Public Interest） | 政府或公共机构 | 流行病追踪 |
| 正当利益（Legitimate Interests） | 企业合理需求 | 反欺诈、网络安全 |
关键点：六大基础之间是并列关系，不是优先级关系。你选一个就行，但不能同时用两个互相矛盾的。
4.2 数据法案的特殊规定
数据法案（Data Act）跟GDPR不太一样。它更关注物联网数据和工业数据的流通。我在一个智能家居项目里就遇到过这个冲突——设备产生的数据，到底归谁？
数据法案的核心逻辑是：用户有权访问自己产生的数据，哪怕这些数据是通过别人的设备生成的。这就引出了两个特殊概念：
- 同意例外（Consent Exception）：在某些场景下，不需要用户明确同意就能处理数据
- 合同例外（Contract Exception）：基于合同履行可以绕过同意流程
注意：数据法案的「例外」不是让你随便用数据。它只是说在某些特定场景下，同意不是唯一路径。我见过有人误解成「不需要同意」，结果被罚得很惨。
4.3 两者的交叉与冲突
你想想看，GDPR要求「明确同意」，数据法案说「合同例外可以绕过同意」。这不就打架了吗？
我个人建议用这个判断流程：
1. 先看数据法案是否适用（物联网/工业数据？）
├─ 是 → 检查合同例外是否成立
│ ├─ 成立 → 按数据法案走
│ └─ 不成立 → 回到GDPR
└─ 否 → 直接走GDPR六大基础
2. 如果两者都适用，优先满足更严格的那个我的经验：遇到冲突时，我通常会做一份「双重合规检查表」。左边列GDPR要求，右边列数据法案要求，中间写我的处理方案。这样审计来了也不怕。
4.4 实战中的选择策略
嗯，这里要讲点干货了。我在三个不同项目里总结出来的策略：
- B2C场景：优先用「同意」。用户直接面对你，同意最清晰。
- B2B场景：优先用「合同履行」或「正当利益」。别跟企业用户要同意，效率太低。
- 物联网场景：仔细检查数据法案的合同例外是否适用。我有个客户是做智能门锁的，一开始全用同意，后来发现数据法案允许合同例外，直接省掉了30%的弹窗。
4.5 知识体系图
下面这张图是我自己画的，帮你理清整个逻辑：
4.6 避坑指南
我曾经在一个医疗数据项目里踩过坑。当时我们用了「正当利益」作为合法基础，觉得医院和患者之间是合理关系。结果数据法案一出来，发现医疗设备产生的数据必须走「同意」或「合同例外」。嗯，那次我们连夜改了合规方案。
三个最容易踩的坑：
- 以为数据法案完全替代了GDPR——其实它是补充，不是替代
- 把「合同例外」理解成「随便用」——合同例外有严格的范围限制
- 忽略双重合规——两个法规都要满足，不是二选一
最后说一句：合法基础的选择不是一劳永逸的。业务变了、法规更新了，你得定期回头检查。我每季度都会做一次合规审计，确保合法基础依然成立。