GDPR 数据保护影响评估（DPIA）——面向 AI 训练与推理场景

章节结构（11）

1. 1. 一、触发判定与评估范围

   先写清这次评估覆盖哪一项（或哪一组同类）处理活动，再逐项对照说明为什么需要做 DPIA。第 35(3) 条列了三类强制情形：基于自动化处理（含画像）对个人方面进行系统、广泛的评价且据以作出产生法律效果或类似重大影响的决定；大规模处理第 9(1) 条特殊类别数据或第 10 条犯罪相关数据；大规模系统性监控公共可进入区域。除此之外按 wp248rev.01 的九项判据打分：评价或评分、有法律或类似重大效果的自动化决策、系统性监控、敏感或高度私密数据、大规模处理、数据集匹配或合并、涉及弱势数据主体、创新性技术或组织方案、以及处理本身阻碍个人行使权利或获得服务。工作组的经验法则是满足两项即应当做；只满足一项而决定不做的，必须在此处写下不做的理由并留档。同时写明所在成员国监管机构依第 35(4) 条公布的强制清单是否命中——这是最常被忽略的一步，因为各国清单并不一致。范围描述要具体到系统与版本：是"v3 推荐模型的训练 + 线上推理"，不是"我们的 AI 业务"。

   需要附的证据

   • · 九项判据的逐项打分表（含判定人与日期）
   • · 所在成员国监管机构第 35(4) 条强制 DPIA 清单的比对记录
   • · 本次评估覆盖的系统与版本清单（含未覆盖部分的说明）
   • · 若判定无需 DPIA：不做的书面理由与 DPO 会签

   常见失分点

   • · 把一份 DPIA 写成覆盖"公司所有 AI 产品"，导致任何一个具体风险都无法落到具体系统上；
   • · 只引用第 35(3) 条三种情形，完全不提九项判据，评审人无法判断判定是否充分；
   • · 未查所在成员国的强制清单，误以为 GDPR 条文之外没有额外要求；
   • · 评估在系统已经上线之后才补做，日期本身就暴露了"事前"要求未满足。

2. 2. 二、处理活动的系统性描述

   第 35(7)(a) 条要求"系统性描述"，wp248rev.01 附件 2 把它拆成可核对的几项：处理的性质、范围、背景与目的；记录个人数据类别、接收方与留存期限；给出处理流程的功能性描述；识别个人数据所依赖的资产（硬件、软件、网络、人员、纸质载体与纸质传输渠道）。AI 场景下建议按数据生命周期分段写：采集/获取（自有产品、第三方数据集、爬取、用户输入、合成数据各写一段）→ 清洗与标注 → 训练与微调 → 评测 → 线上推理与日志 → 反馈回流用于再训练 → 删除。每段都要写明数据类别、数据主体类别、法律角色（控制者/处理者/共同控制者）、境内外存放位置。把这张图与第 30 条处理活动记录（ROPA）对齐，两份文件出现矛盾是最容易被抓的破绽。

   需要附的证据

   • · 数据流图（含境内外存放位置与跨境节点标注）
   • · 字段级数据清单（数据类别、数据主体类别、来源、留存期限）
   • · 第 30 条处理活动记录（ROPA）相应条目及与本文件的对齐说明
   • · 资产清单（训练集群、向量库、日志系统、标注外包平台）
   • · 接收方清单（处理者、子处理者、共同控制者）

   常见失分点

   • · 只画了推理链路，训练数据从哪来、标注外包给谁、日志回流怎么处理全部缺失；
   • · 留存期限写"按业务需要"，等于没写——第 5(1)(e) 条要求期限可确定；
   • · ROPA 里写的处理者与 DPIA 里写的不一致，说明两份文件由不同团队各写各的；
   • · 把"资产"理解成服务器清单，漏掉人员与外包标注环节这类最常出事的资产。

3. 3. 三、合法性基础、必要性与相称性

   第 35(7)(b) 条要求评估"处理活动相对于目的的必要性与相称性"。分三层写。第一层：每一个处理目的（训练、评测、线上推理、滥用检测、再训练）分别对应第 6(1) 条哪一项合法性基础，不要用一句"正当利益"覆盖全部环节。若依赖正当利益，按三步检验逐步论证：利益是否正当、处理是否为实现该利益所必需、与数据主体的权利与合理预期的权衡结论；EDPB 第 28/2024 号意见专门讨论了这一检验在模型训练场景下的适用。第二层：特殊类别数据（第 9 条）与犯罪数据（第 10 条）是否被排除，若未排除则写明第 9(2) 条的哪一项例外；从公开网络抓取的语料中夹带特殊类别数据是本节最常见的漏洞。第三层：数据最小化与留存限制的具体措施（去重、去标识、字段裁剪、采样、训练完成后原始语料的处置）。最后写第 5(1)(b) 条目的限制：把已收集的用户数据改用于模型训练，属于兼容性使用还是新目的，结论与理由都要落纸。

   需要附的证据

   • · 目的—合法性基础对照表（每个处理阶段一行）
   • · 正当利益三步检验记录（含权衡结论与反对权处理方式）
   • · 特殊类别数据筛除方案与抽样核查结果
   • · 数据最小化措施说明与实施前后的数据量对比
   • · 目的兼容性分析（第 6(4) 条要素逐项）

   常见失分点

   • · 全流程一句"基于正当利益"，没有三步检验，也没有说明如何处理第 21 条反对权；
   • · 声称训练语料"不含个人数据"却拿不出筛查方法与抽样证据；
   • · 把同意作为训练的基础，却无法证明该同意在收集时就覆盖了模型训练用途；
   • · 必要性论证写成产品价值论证——评审人要看的是"少用这些数据能不能达成同样目的"。

4. 4. 四、数据主体权利的保障安排

   wp248rev.01 附件 2 把"有助于数据主体权利的措施"列为必查项，需逐条写清第 12–22 条在本系统里如何落地：告知（第 13、14 条，包括数据非直接来自本人时的来源说明与第 14(5) 条例外的适用理由）、访问与可携带（第 15、20 条）、更正与删除（第 16、17、19 条）、限制与反对（第 18、19、21 条）。AI 场景的难点必须正面回答，不能回避：已进入训练集并被模型吸收的个人数据，删除请求如何执行——是仅从语料与索引删除、还是触发再训练或权重级干预，各自的技术边界与时间成本是什么；模型输出中出现的错误个人信息如何更正（输出侧过滤、检索层修正、还是拒答）。第 12(3) 条的一个月响应时限（可延长两个月并说明理由）要写进流程，而不是只写在制度文件里。

   需要附的证据

   • · 隐私告知文本（训练用途段落）与展示位置截图
   • · 权利请求处理 SOP（含身份核验、一个月时限与延长理由模板）
   • · 删除请求在语料层、索引层、模型层的技术执行说明与实测记录
   • · 权利请求台账（受理时间、响应时间、结论）
   • · 第 14(5) 条例外适用的书面理由（若援引）

   常见失分点

   • · "模型无法删除单条数据"写成结论就结束了，没有写替代措施与残余风险；
   • · 爬取语料未做第 14 条告知，也未论证第 14(5)(b) 条"不可能或需付出不成比例努力"的适用；
   • · 权利请求入口只在英文隐私政策底部，实际到达路径长于三次点击；
   • · 台账里全部记录"已处理"，没有响应时长数据，无法证明一个月时限被遵守。

5. 5. 五、自动化决策与画像专项

   若系统输出会被用来作出对个人产生法律效果或类似重大影响的决定（授信、录用筛选、保险定价、内容封禁、价格差异），本节必须单独成章。先判定是否落入第 22(1) 条的"完全基于自动化处理"：人工环节是否具备实质干预能力（有权推翻、有信息基础、有时间），还是只是形式上点一下确认。若落入，写明第 22(2) 条的哪一项例外（履行合同必需、成员国法律授权、明示同意），以及第 22(3) 条要求的保障措施：获得人工干预、表达意见、提出异议。同时把第 13(2)(f)/14(2)(g)/15(1)(h) 条要求的"有意义的逻辑信息"具体写出来——用了哪几类特征、大致权重或影响方向、预期后果，而不是"使用机器学习算法"。涉及第 9 条特殊类别数据的自动化决策适用第 22(4) 条的更严格限制。

   需要附的证据

   • · 自动化决策判定记录（人工环节的权限、信息与时间证据）
   • · 第 22(2) 条例外适用的法律分析
   • · 人工复核流程说明与复核推翻率统计
   • · 面向个人的"逻辑信息"说明文本（产品内实际展示版本）
   • · 异议与申诉渠道的处理台账

   常见失分点

   • · 以"有人工审核"为由否认适用第 22 条，却拿不出复核推翻率或复核时长数据；
   • · "逻辑信息"写成算法名称，个人据此无法判断该不该提出异议；
   • · 异议渠道存在但无人处理，台账里连续数月零记录；
   • · 忽略第 22(4) 条：用健康、生物识别等特殊类别特征做自动化决策却未做额外论证。

6. 6. 六、处理者、子处理者与模型供应链

   按第 28 条写清链条上每一方的角色与合同安排：云与算力供应商、标注外包商、向量库与检索服务、被调用的第三方大模型 API、评测与红队供应商。每一方写明：法律角色（处理者还是独立控制者——调用第三方模型 API 时这一点经常判错）、数据处理协议（DPA）是否签署及签署日期、第 28(2)/(4) 条的子处理者授权与告知机制、审计权、以及供应商所在国。若把欧盟用户输入传给第三方模型提供者，必须写明该提供者是否将输入用于自身训练、是否可关闭、默认值是什么——这是欧盟企业客户尽调中被问得最多的一条。若企业自身对某些客户是处理者，也在此写明与之相应的指令边界。

   需要附的证据

   • · 供应链清单（角色、DPA 状态、所在国、数据类别）
   • · 各方 DPA 与子处理者清单及变更通知记录
   • · 第三方模型 API 的训练用途设置截图与合同条款引用
   • · 供应商安全评估/尽调记录（问卷、认证证书、渗透测试摘要）
   • · 审计权行使记录或替代性保证（如第三方审计报告）

   常见失分点

   • · 把第三方模型提供者一律写成"处理者"，但其条款里保留了自主使用输入数据的权利——这时它是独立控制者；
   • · 子处理者清单只在签约时给过一次，之后新增供应商无通知记录；
   • · 标注外包环节完全缺失，而这往往是原始个人数据接触面最大的一环；
   • · 有 DPA 但没有任何审计或替代保证证据，第 28(3)(h) 条的核查义务落空。

7. 7. 七、处理安全与设计/默认数据保护

   按第 32 条把技术与组织措施写到可核查的粒度：加密（传输与静态、密钥管理归属）、访问控制（训练集群、语料仓库、日志、推理记录分别谁可访问）、假名化与去标识的具体方法与再识别风险评估、可用性与恢复（RTO/RPO、备份演练记录）、以及"定期测试、评估和评价措施有效性"的机制与最近一次结果。第 25 条的设计与默认要求单独回答：默认配置下收集多少、保留多久、是否默认开启训练回流。AI 特有的风险要正面写：训练数据记忆与提示注入导致的个人数据泄露、模型反演与成员推断、日志中意外留存的用户输入、RAG 索引越权检索。每一项写明缓解措施与验证方式，避免"已加密"这种无法核查的表述。

   需要附的证据

   • · 技术与组织措施清单（措施—风险—验证方式三列）
   • · 访问控制矩阵与权限复核记录
   • · 假名化/去标识方法说明与再识别风险测试结果
   • · 记忆化、成员推断、提示注入的测试报告
   • · 最近一次安全测试/渗透测试与整改关闭记录
   • · 备份恢复演练记录

   常见失分点

   • · 措施清单照抄 ISO 27001 控制项，没有一条与本系统的具体风险对应；
   • · 日志与推理记录的访问权限被忽略，而它们往往包含最原始的用户输入；
   • · "定期测试"没有最近一次的日期与结论，无法证明机制在运行；
   • · 把模型安全测试等同于内容安全红队，未覆盖个人数据泄露向量。

8. 8. 八、国际传输与第三国法律环境

   列出本系统涉及的每一条出境链路（含远程访问与运维访问——这两类最常被漏记），写明：接收方与所在国、传输目的与数据类别、依据的第五章机制（充分性决定、标准合同条款、有约束力的公司规则、第 49 条减损）、以及是否已完成传输影响评估。传输到中国的链路必须单独说明——这是中国 AI 企业面向欧盟客户时最受关注的一节，应当写清中国法下的政府访问框架、企业可采取的合同与技术补充措施、以及收到访问请求时的处理流程。传输影响评估本身另出独立文件（见"传输影响评估（TIA）"模板），此处只作索引与结论摘要，避免两份文件各写一套结论。

   需要附的证据

   • · 出境链路清单（含远程访问与运维访问）
   • · 已签署的标准合同条款及其附件 I–III
   • · 传输影响评估报告索引与结论摘要
   • · 补充措施清单及其有效性验证
   • · 政府数据访问请求的处理流程与透明度报告（若有）

   常见失分点

   • · 只统计"数据复制到境外"的链路，漏掉境内存储但境外可远程查询/调取的情形；
   • · 标准合同条款签了模板但附件 I–III 留空或照抄，无法反映真实数据流；
   • · DPIA 里说"已评估风险可接受"，而独立的 TIA 文件给出不同结论；
   • · 对中国法下的访问框架回避不谈，反而使客户尽调停滞更久。

9. 9. 九、风险识别、分级与缓解措施

   第 35(7)(c)、(d) 条要求从数据主体（不是公司）的视角评估风险并确定应对措施。wp248rev.01 附件 2 给出方法要求：考虑风险来源，识别非法访问、非法篡改、数据灭失三类事件对个人权利与自由的潜在影响，识别可能导致这些事件的威胁，估计可能性与严重性。建议做成风险登记表：风险编号 / 场景描述（写成对个人的后果，如"求职者因训练数据偏差被系统性筛除"）/ 风险来源 / 可能性 / 严重性 / 固有风险等级 / 缓解措施 / 措施负责人与时限 / 残余风险等级 / 残余风险是否可接受及决定人。AI 场景至少覆盖：训练数据偏差导致的歧视、记忆化导致的数据泄露、幻觉输出造成的名誉损害或错误决定、错误的实体链接把行为归到无关个人、模型被用于超出预期目的、以及供应链某一环失守。

   需要附的证据

   • · 风险登记表（含固有风险与残余风险两级评分）
   • · 偏差与公平性测试结果（分组指标与样本量）
   • · 缓解措施的实施证据与验收记录
   • · 残余风险接受决定的签署记录（签署人及职位）
   • · 未采纳的缓解方案及不采纳理由

   常见失分点

   • · 风险写成对公司的风险（"被罚款""声誉受损"），不是对个人的影响；
   • · 所有风险经缓解后一律降为"低"，且没有任何残余风险，评审人会直接判定评估不诚实；
   • · 缓解措施只写"将加强"，无负责人、无时限、无验收标准；
   • · 公平性测试只报总体准确率，没有分组指标，无法支撑无歧视的结论。

10. 10. 十、咨询、事前咨询与签署

    第 35(2) 条要求在已指定 DPO 时征求其意见，第 35(9) 条要求在适当时征求数据主体或其代表的意见。两者都要留下痕迹：DPO 意见原文（含保留意见）、征求数据主体意见的方式与结果，或不征求的理由（如涉及商业秘密或安全，须具体说明）。随后判断是否触发第 36(1) 条事前咨询：若在采取缓解措施之后风险仍为高，必须在处理开始前咨询监管机构。第 36(2) 条给监管机构最长八周出具书面意见的期限，复杂情形可延长六周，并可因监管机构索取资料而中止计时——在项目排期里按这个量级预留时间，不要按"两周回复"假设。最后写明批准人：谁签字、职位、日期、以及本次批准覆盖的系统版本。

    需要附的证据

    • · DPO 书面意见及对意见的处理记录
    • · 数据主体意见征求方式与结果，或不征求的具体理由
    • · 事前咨询判定记录（高风险是否在缓解后仍存在）
    • · 如提交事前咨询：第 36(3) 条要求的材料清单与监管机构回复
    • · 批准记录（签署人、职位、日期、覆盖版本）

    常见失分点

    • · DPO 意见只写"无异议"，看不出其是否实际参与，也不符合第 38(1) 条"及时、适当参与"的要求；
    • · 识别出高残余风险却未做事前咨询，也未记录为什么认为无需咨询；
    • · 把监管机构八周（可延长六周）的期限当成两周，导致上线计划被迫推迟；
    • · 签署人是项目经理而非有权承担风险的管理层。

11. 11. 十一、复评触发与版本管理

    第 35(11) 条要求在处理活动的风险发生变化时至少进行一次复核。把"变化"定义成可自动检测的触发条件，而不是一句"定期复核"：模型重大版本更新或基座模型更换；训练数据来源新增或采集方式改变；新增处理目的或新增国家/地区上线；新增或更换处理者、子处理者；发生个人数据泄露或重大投诉；适用法律变化（如欧盟人工智能法案高风险规则适用、成员国清单更新）。每次复评记录：触发原因、变更内容、风险是否升级、是否需要重新征求 DPO 意见或事前咨询。文档本身用版本号管理，并在首页标注"本版本覆盖的系统版本区间"，使读者能判断手上这份是否仍然有效。

    需要附的证据

    • · 复评触发条件清单及其监测方式
    • · 版本历史表（版本号、日期、触发原因、变更摘要、批准人）
    • · 最近一次复评记录与结论
    • · 与变更管理/发布流程的挂接说明（哪一个发布门禁会检查 DPIA 有效性）

    常见失分点

    • · 写"每年复核一次"，但模型一年发了十几个版本，DPIA 早已与在跑的系统脱节；
    • · 版本历史缺失，无法证明评估在处理开始之前完成；
    • · 复评没有与发布流程绑定，实际上从未被触发；
    • · 法规变化（如高风险规则适用日）未列入触发条件。