第二章：DPIA触发条件——哪些场景必须做DPIA
大家好，我是你们的老朋友。今天咱们聊聊DPIA的触发条件。说实话，这个问题我在项目里被问过不下百次：「到底什么时候必须做DPIA？」
嗯，咱们先别急着背法条。你想想看，GDPR第35条写得挺清楚，但实际落地时，边界往往是模糊的。我个人的习惯是：先判断「是不是高风险」，再决定「要不要做DPIA」。
一、哪些场景必须做DPIA？
说白了，以下三类场景，基本跑不掉：
- 系统性的大规模画像——比如银行用AI评估客户信用，或者电商平台搞千人千面的推荐算法。这类处理会直接影响个人的权益或合同。
- 大规模处理特殊类别数据——比如医院管理患者的健康档案，或者HR系统存储员工的生物识别信息。这类数据一旦泄露，后果很严重。
- 公共区域的系统性监控——比如商场安装人脸识别摄像头，或者智慧城市项目采集市民的行踪轨迹。这类处理往往涉及大量不知情的数据主体。
重要提醒：以上三类只是「最低门槛」。实际项目中，很多看似普通的处理也可能触发DPIA。我见过一个案例：某公司只是做员工考勤统计，但因为用了指纹打卡，最后被监管要求补做DPIA。
二、高风险处理活动的识别——我的实战经验
怎么判断「高风险」？我个人习惯用「四维评估法」：
| 评估维度 | 具体问题 | 风险等级 |
|---|---|---|
| 数据性质 | 是否涉及特殊类别数据？是否涉及儿童数据？ | 高/中/低 |
| 处理规模 | 涉及多少数据主体？数据量有多大？ | 高/中/低 |
| 技术手段 | 是否使用新技术（如AI、区块链）？是否涉及自动化决策？ | 高/中/低 |
| 影响程度 | 是否可能造成歧视、经济损失或声誉损害？ | 高/中/低 |
举个例子。我之前帮一家金融科技公司做评估，他们想用机器学习模型来预测用户的还款能力。乍一看，这好像只是普通的信用评估。但仔细一分析：
- 数据性质：涉及收入、消费习惯等敏感信息
- 处理规模：覆盖上百万用户
- 技术手段：黑盒模型，难以解释决策逻辑
- 影响程度：可能直接导致用户被拒绝贷款
你看，四个维度全中。这不做DPIA，说不过去。
我的小技巧：如果你不确定某个处理活动是否属于高风险，可以先用这个四维表格打个分。只要有两个维度达到「高」，我建议你直接启动DPIA流程。宁可多做，不要漏做。
三、数据主体权益影响评估
这部分是DPIA的核心。说白了，你要回答一个问题：「这个处理活动，会不会让数据主体吃亏？」
我一般从三个层面来评估：
- 物理层面——会不会造成人身伤害？比如医疗数据处理出错，可能导致误诊。
- 经济层面——会不会造成财产损失？比如信用评分错误，导致用户贷不到款。
- 精神层面——会不会造成心理压力？比如被监控的员工，长期处于焦虑状态。
嗯，这里要注意。很多公司只关注前两个层面，忽略了精神层面的影响。我曾经处理过一个案例：某公司用AI监控员工的工作效率，结果员工普遍反映「感觉像在坐牢」。最后工会介入，要求公司补做DPIA，并调整监控策略。
避坑指南：我曾经见过一个团队，把DPIA做成了「走过场」。他们只填了表格，没有真正去访谈数据主体代表，也没有模拟处理活动的实际影响。结果监管检查时，直接被认定为「无效DPIA」，罚了20万欧元。记住：DPIA不是写作文，是真正的风险评估。
四、实操建议
最后，给你三个落地建议：
- 建立触发清单——把常见的DPIA触发场景列成清单，嵌入到项目立项流程中。这样新项目启动时，产品经理就能自动判断是否需要DPIA。
- 定期复盘——处理活动不是一成不变的。我建议每半年回顾一次，看看有没有新的高风险场景出现。
- 保留记录——即使你判断某个处理活动不需要做DPIA，也要把评估过程记录下来。万一监管问起来，你能拿出证据。
好了，这一章就聊到这儿。下一章咱们会深入讲解DPIA的具体执行步骤，包括怎么画数据流图、怎么识别风险点。到时候我会分享一个我亲手做过的完整案例，保证干货满满。
咨询更多资料，