4、合法处理基础：六大合法处理基础详解、同意机制的有效获取与管理

4.1 六大合法处理基础——不只是选择题

说实话，我刚做DPO那会儿，也以为合法处理基础就是个形式。

选一个，打勾，完事。

直到有一次，一个客户把「同意」当成了万能钥匙，结果被投诉到监管机构。嗯，从那以后我才真正明白——合法处理基础不是填空题，是逻辑题。

GDPR第6条给出了六条路。你只能选一条，而且必须选对。

编号	合法基础	适用场景	我的经验
a	同意	用户主动授权，如营销邮件	最容易被滥用，也最容易翻车
b	履行合同	电商下单、订阅服务	范围要窄，别把「改善体验」塞进来
c	法律义务	税务、反洗钱、劳动法	别自己编造法律义务
d	重大利益	生命健康、紧急情况	极少用，但关键时刻能救命
e	公共利益	公共卫生、科研统计	需要国内法授权
f	正当利益	反欺诈、网络安全	必须做LIA测试，别偷懒

4.2 同意机制——最基础也最坑

同意，听起来简单吧？

用户点一下「我同意」就行了。

但我在项目中遇到过太多「假同意」了。比如默认勾选、小字条款、一揽子授权……这些在GDPR眼里，统统不算数。

我曾经帮一家电商平台整改过同意流程。他们原来的做法是：注册时一个勾选框，写着「我同意服务条款和隐私政策」。这其实是个大坑——你把合同履行和营销同意混在一起了。

正确的做法是什么？

// 伪代码示例：同意管理逻辑
if (用户点击「注册」) {
    // 合同履行基础，不需要额外同意
    处理必要数据（姓名、地址、支付信息）
}

if (用户勾选「接收营销邮件」) {
    // 单独获取同意
    记录同意时间戳 + 版本号
    发送确认邮件
}

if (用户未勾选) {
    // 默认不发送
    不记录任何营销偏好
}

你看，代码逻辑清晰了，合规也就清晰了。

4.3 同意的获取——别让用户「被同意」

我见过最离谱的案例：一个App把同意按钮做成灰色小字，拒绝按钮做成大红色。用户几乎是被逼着点「同意」。

这叫什么？这叫dark pattern（暗黑模式）。监管机构看到直接开罚单。

你想想看，如果用户想撤回同意，得打客服电话、发邮件、等三天……这合理吗？

不合理。撤回必须和同意一样简单。

4.4 同意的管理——不是签完就完事了

很多人以为，拿到同意就万事大吉了。

错了。同意是有「保质期」的。

我记得有个客户，三年前收集的用户同意，现在拿出来用。我说不行，你得重新获取。为什么？因为业务变了、数据处理目的变了、甚至公司名字都变了。

4.5 六大基础的选择策略——别硬套

我经常被问到：「哪个合法基础最好用？」

我的回答是：没有最好，只有最合适。

举个例子：

• 你做电商，用户下单——用「履行合同」
• 你做营销，发促销邮件——用「同意」
• 你做反欺诈，分析用户行为——用「正当利益」

但要注意，同一个处理活动，不能同时用两个基础。你选了「同意」，就不能再拿「正当利益」当备胎。

4.6 知识体系框架图

下面这张图，是我自己整理的核心逻辑。你看一眼，基本就明白这章在讲什么了。

4.7 最后说几句

合法处理基础这件事，说白了就是：你得有个站得住脚的理由。

别想着蒙混过关。监管机构不是傻子，用户也不是。

我个人的习惯是：每做一个新数据处理活动，先问自己三个问题——

• 我为什么要处理这些数据？
• 我选哪个合法基础？
• 如果用户问起来，我能解释清楚吗？

三个问题答不上来，就别动手。

---