4. 合法性与目的分析：识别处理的法律依据、评估目的正当性、目的限制原则检查、合法性审查清单

好，咱们进入DPIA最核心的环节之一——合法性与目的分析。

说实话，我见过太多DPIA做到这一步就草草了事。很多人觉得，只要用户点了“同意”，合法性就搞定了。嗯，如果你也这么想，那今天这节内容可能会让你重新审视很多项目。

我个人习惯，拿到一个数据处理场景，第一件事不是看功能怎么实现，而是问：我们凭什么处理这些数据？

GDPR第6条列出了六种合法基础，但很多团队只认识“同意”。我在项目中遇到过，一个HR系统要处理员工健康数据，产品经理说“让员工签个同意书不就行了？”——这其实是个大坑。劳动关系下，员工很难真正自由地拒绝，这时候“同意”的合法性基础非常脆弱。

常见的合法基础包括：

关键原则：一个处理活动可以依赖多个合法基础，但必须在处理前明确选择最合适的一个。不能事后补票。

我的小技巧：我会做一个“合法基础对照表”，把每个数据处理目的和对应的合法基础列出来。这样在DPIA评审时，一眼就能看出哪个场景的合法性基础选错了。

合法基础选对了，不代表目的就正当。你想想看，如果一家公司收集用户的位置数据，说是为了“提供导航服务”，但实际用来分析用户去了哪些竞争对手门店——这个目的正当吗？

我个人判断目的正当性，会从三个维度来拷问：

是否合法：目的本身不能违反法律。比如收集数据用于价格歧视，在很多地区是违法的。
是否透明：用户能合理预期到这个目的吗？我曾经处理过一个智能音箱的DPIA，厂商说收集语音是为了“改善语音识别”，但用户根本不知道他们的对话会被人工标注团队听到。
是否必要：有没有更少侵犯隐私的方式达到同样目的？比如用匿名化数据代替个人数据。

这里有个避坑指南：我曾经见过一个项目，目的写得很漂亮——“提升用户体验”。但拆开来看，实际上是在做用户画像用于精准广告。这种“挂羊头卖狗肉”的做法，在DPIA审查中基本过不了。

目的限制原则，说白了就是：当初说好用来干嘛，就只能用来干嘛。

但现实往往很骨感。我见过一个电商平台，收集用户的收货地址是为了发货，结果市场部拿去做了线下门店的客流分析。这就是典型的目的偏离。

检查目的限制时，我建议你问自己三个问题：

注意：目的限制不是死的。如果新目的与原始目的兼容（比如从“订单管理”扩展到“售后服务”），可能不需要重新获取同意。但“兼容性测试”需要做正式评估，不能拍脑袋。

我记得有一次，一个SaaS平台想把用户的使用数据用于产品改进。原始目的里写的是“提供软件服务”，而“产品改进”其实可以算作兼容目的。但我们还是做了正式的兼容性分析，并更新了隐私政策。这个步骤虽然繁琐，但能避免后续的合规风险。

好了，理论讲完了，咱们来点实际的。下面是我自己用的合法性审查清单，每次做DPIA我都会过一遍：

实战建议：把这个清单做成一个Excel模板，每个处理活动一行。每次DPIA评审时，直接对着表格打勾。我团队现在就是这么干的，效率提升了不少。

咱们来看一个实际案例。假设你是一家健身App的数据合规负责人，App要收集用户的心率数据用于“个性化运动建议”。

第一步：识别合法基础
心率数据属于健康数据，是敏感数据。你不能只靠“合同履行”来处理，因为用户不提供心率也能用App。所以，明确同意是必须的。

第二步：评估目的正当性
“个性化运动建议”这个目的正当吗？合法，没问题。透明吗？用户能理解。必要吗？其实可以用运动时长、卡路里等非敏感数据做基础建议，但个性化建议确实需要心率数据。嗯，这里算通过。

第三步：目的限制检查
如果后来市场部想用这些心率数据做“用户健康趋势分析”用于广告投放——这就偏离了原始目的。需要重新获取同意，或者找到其他合法基础。

第四步：合法性审查清单
逐项检查：合法基础选了“同意”，目的明确且正当，无偏离，隐私政策已更新，敏感数据有额外保护措施。全部通过。

最后说一句：合法性分析不是一次性的。业务会变，目的会变，法律也会变。我建议每12个月重新审查一次你的合法性基础，尤其是那些依赖“正当利益”的场景。

好了，这一节的内容就到这儿。下一节我们会聊数据最小化与存储限制——说白了，就是怎么做到“够用就好，别贪多”。