Transfer Impact Assessment Tia Oliver Schmidt Prietz

GDPR 转移影响评估（TIA）技能

免责声明（会话开始时显示，不阻塞）

重要提示： 本技能基于 EDPB 建议、CNIL 指引、欧洲法院判例法和新兴的国内判例法（慕尼黑高等地区法院 21 U 3882/25 e）提供结构化的 GDPR 第五章转移评估指引。不构成法律意见。最终决定应让 DPO 和合格法律顾问参与，尤其在技能标记某项转移需要暂停或重组时。

路由

确定用户需要什么，并仅懒加载所需的参考文件：

docx 技能： Claude.ai Projects 中的 /mnt/skills/public/docx/SKILL.md，或 Claude Code 中的 docx-processing-anthropic。如不可用，回退生成 Markdown。

会话设置

三个快速问题。如用户预先提供丰富语境，灵活调整——提取答案并确认，而非顺序询问。

1. 范围： "你是在评估一项已知的具体转移，还是需要先映射贵组织的国际转移？"
2. 现有数据： "你有可供我使用的现有 RoPA 或转移清单吗？" （如范围 = 具体转移则跳过）
3. 时点： "这是针对上线前的新转移，还是对已就位转移的事后评估？"

其余细节——出口者、进口者、国家、机制、数据类别——作为评估流水线的自然第一步捕获，而非枯燥的前置问卷。

工作区模式（批量评估）

对于有多项转移需要评估的组织，技能使用工作区模式：

skills/tia-workspace/<org-slug>/
├── transfer-registry.json        # All identified transfers, each with a UUID
├── assessments/
│   ├── TIA-US-2026-001.json     # Per-transfer assessment state
│   ├── TIA-US-2026-001.md       # Per-transfer Markdown report
│   ├── TIA-US-2026-001.docx     # Per-transfer formal document (generated last)
│   └── TIA-IN-2026-002.*
├── outbound/                     # Delta files queued for RoPA
│   └── tia-<uuid>-<timestamp>.delta.json
└── state.json                    # Session checkpoint (current transfer, step, partial findings)

每一步后设置检查点。通过读取 state.json 恢复。

评估前门禁：转移定性

在运行 6 步流水线之前，技能确定是否存在第五章意义上的"转移"。适用 EDPB《指南 05/2021》——三项累积标准：

1. 出口者就相关处理受 GDPR 约束（第 3(1) 或 3(2) 条）。
2. 向独立的控制者或处理者披露（非同一实体；非数据主体直接收集）。
3. 进口者在第三国（无论 GDPR 是否依第 3 条适用于进口者）。

三项均满足 → 第五章适用 → 继续 TIA 要求检查。

任何一项不满足 → 输出转移定性结论，记录：

• 哪项标准未满足及原因。
• 第五章不适用于该处理。
• 第 5/24/32 条的保障措施仍属强制（依指南第 4 节）。
• 对于第三国母公司之欧盟子公司场景（EDPB 示例 12）：要求按第 28 条对处理者的域外法律敞口进行尽职调查。

该结论本身就是有价值的交付物——它记录了该问题已得到评估。

TIA 要求检查（三项标准均满足时）

• 第 45 条充分性？ → 仅轻量评估（记录该认定、条件、审查日期、DPF 的脆弱性风险）。使用相关国家画像。
• 第 49 条克减？ → 第 49 条评估路径（加载 art49-derogations.md）。平衡框架；记录理由。
• 第 46 条工具（SCC、BCR、个案协议、行为守则、认证）→ 需要完整 TIA → 进入第 1 步。

评估流水线（第 1–6 步）

参考：references/edpb-six-steps.md。完整细节在该文件中；SKILL.md 记录关键流程。

第 1 步：了解你的转移

捕获（来自发现、RoPA 导入或用户直接输入）：出口者、进口者、国家、数据类别、主体、目的、数据量、频率、数据格式、后续转移。确认完整性。将后续转移标记为单独评估。

第 2 步：识别转移工具

记录第五章机制：充分性 / SCC（模块）/ BCR / 个案协议 / 行为守则 / 认证。视相关注明执行日期和监管机构授权。

确定主要机制后： 询问"第 49 条克减是否可作为本转移的主要或替代依据适用？"如是 → 并行/备用路径运行第 49 条评估。

第 3 步：评估第三国法律与实践

加载相关国家画像。三个块：

A 块——数据保护框架。 一般法律、监管机构、权利、救济。

B 块——监视/访问法律。 对每项相关法律：适用四项基本保障（明确规则 / 必要且相称 / 独立监督 / 有效救济）。将每项评级为充分 / 存疑 / 不足。

C 块——实践风险评估（受 Rosenthal 启发）。 进口者的请求历史、现实的目标定位依据、明文访问的必要性、机关对该数据的现实利益。

第 3 步结论——三向分叉（CNIL 方法论）：

1. 转移工具有效 → 进入第 6 步。
2. 转移工具无效，需要补充措施 → 进入第 4 步。
3. 转移工具纸面上无效，但无现实依据认为问题法律会在实践中适用于该转移 → 附透彻、实质性的理由进入第 6 步。

选项 (3) 是合法的（CNIL 指南明确接受），但需要真正的论证——行业、数据类型、进口者画像、请求历史——而非套话。

第 4 步：补充措施

在第 3 步返回结论 (2) 时触发。加载 references/supplementary-measures.md。自动建议与已识别缺口匹配的措施。用户审查 / 接受 / 定制。然后评估：所选措施是否有效弥合缺口？

如是 → 继续。如否 → 转移无法按现有结构进行。选项：重组（不同进口者、不同国家、不同架构）或暂停。

第 5 步：实施行动计划

记录：要实施的措施、责任人、截止日期、合同修改（SCC 附件 II 修订、补充函）、技术变更（加密、假名化流水线）、时间线。

第 6 步：重新评估触发条件

记录：常设触发（充分性审查日期、DPF 脆弱性）、事件驱动（新法律、监管机构行动、进口者政府请求、认证变更）、定期（默认 12 个月，高风险更短）。设定下一次审查日期。

输出

四项交付物（用户选择所需）：

1. Markdown TIA 报告——会话内预览。各部分镜像第 1–6 步。
2. .docx 正式 TIA 文件——用于合规档案。使用 references/tia-template.md 结构，含 CNIL 风格表格、封面页、签署块（评估人 + DPO）、附国家画像摘要的附件。
3. JSON 数据交换 Sidecar——符合 interchange-inbound-schema.json v1.0 的 delta 文件。修补 tia_ref、tia_status、supplementary_measures[]、tia_completed_date、tia_review_date。落至 skills/ropa-workspace/<org-slug>/inbound/。见 references/interchange-delta.md。
4. 转移风险摘要——批量评估的一页高管概览。逐项转移行：目的地、机制、结论、关键风险、措施。无数值评分。

跨技能集成

从 RoPA 入站： 读取 sidecar（<org-slug>-ropa-sidecar.json）→ 筛选含第三国转移的条目 → 预填第 1 步 → 跟踪 activity_id UUID。

向 RoPA 出站： 每项已评估转移发出 delta 文件（见输出 #3）。写入后 delta 归 RoPA 所有。

DPIA 触发： 如第 3 步揭示高风险处理（第 9 条特殊类别 + 系统性监控 + 第三国风险），向用户标记："请考虑是否需要依第 35 条进行 DPIA。此转移的风险状况可能达到 DPIA 阈值标准。" 不要自动触发 DPIA Sentinel——仅标记。

法律精确性要点

这些是 Claude 训练知识可能不精确的领域。始终适用以下规则：

1. 只有第 46 条转移才需要 TIA。 充分性（第 45 条）和第 49 条克减不需要 TIA——但各自需要自己的文档记录（充分性：认定编号 + 条件；第 49 条：理由 + 适用的子款）。

2. GDPR 中"转移"没有法律定义。 EDPB《指南 05/2021》定义了三项累积标准。从数据主体直接收集 ≠ 转移（示例 1）。处理者从第三国远程访问 = 转移（示例 11）。员工出差访问自己雇主的数据 ≠ 转移（示例 8）。

3. 后续转移需要单独评估。 链条中的每一跳（控制者 → 处理者 → 第三国次级处理者）都是第五章下的独立转移，需要各自的分析。

4. DPF 不是美国的整体充分性认定。 仅涵盖 (a) 受 FTC/DoT 管辖且 (b) 积极获得 DPF 认证的组织。始终在 dataprivacyframework.gov 核实当前认证状态。未获认证的美国接收者需要 SCC + TIA，依 country-profiles/us-non-dpf.md。

5. DPF 的政治脆弱性是现实风险。 DPF 建立在行政令 14086 之上（行政部门构造）。未来的美国政府可以废除它。对于长期转移，在依赖 DPF 的同时保留 SCC 作为回退。

6. 充分性认定可以附条件和到期日。 日本：适用补充规则。英国：2025 年 12 月续期，有效期至 2031 年 12 月 27 日（任何续期前由欧盟委员会/EDPB 联合审查）。加拿大：仅 PIPEDA 监管的组织。韩国：仅 PIPA 监管的组织。记录条件；跟踪审查日期。

7. 第 49 条在法条上并不限于"最后手段"。 那是 EDPB 指引（《指南 2/2018》）的框架，而非法律条文。慕尼黑高等地区法院（21 U 3882/25 e，2026 年 5 月 11 日）接受了第 49(1)(b) 条适用于全球服务的日常转移，前提是合同本质上具有国际性。欧洲法院报告法官 von Danwitz 法官曾表示，第 49 条可能覆盖比 EDPB 所承认更多的转移场景。记录执业者所依赖的立场；两者均有辩护空间。

8. "合同履行所必需"意味着转移是必要的，而不仅仅是合同存在。 但在服务本质上具有跨境性时（慕尼黑高等地区法院），转移与合同相互交织。记录服务本质上具有国际性。

9. 补充措施必须有效，而不仅仅是存在。 出口者持钥的加密只有进口者无需解密时才有效。挑战条款只有进口者有现实的法律途径时才有效。记录每项措施的有效性评估，包括"何时无效"的条件。

10. "没有理由相信"的出口阀门是合法的，但必须记录。 CNIL 第 3 步结论选项 (3)——转移工具纸面上无效，但无现实依据认为问题法律会适用——需要实质性理由（行业、数据类型、进口者画像、请求历史），而非套话式断言。

11. SCC 不可修改。 只能填写可选条款；当事人可通过加入条款（第 7 条）添加。补充措施与 SCC 并置（通常在附件 II 或补充协议中），不在 SCC 文本内部。

12. 即使转移由处理者发起，控制者仍负责任。 依 EDPB《指南 05/2021》示例 7：处理者向第三国次级处理者转移时，控制者仍依第 28 条和第五章承担责任。

13. 第三国公司的欧盟子公司可以触发转移问题而无实际转移。 EDPB《指南 05/2021》示例 12：如欧盟处理者受域外监视法约束（例如通过其美国母公司受 CLOUD Act 约束），遵守政府访问请求将变成一项转移。在聘用处理者前依第 28 条评估此点。

14. TIA 必须在转移开始前完成。 依 Schrems II 和 EDPB《建议 01/2020》，评估是第 46 条转移的前提条件。对现有转移的事后 TIA 在实践中很常见，但代表合规缺口；记录该缺口并关闭它。

15. 重新评估不是可选的。 第 46 条机制要求持续监控。立法变化（新监视法）、判例法（Schrems III 落地时）、接收国的监管机构执法行动、进口者收到政府访问请求，以及政治发展（DPF 废止风险）都会触发重新评估。默认定期审查：12 个月。

参考文件

• GDPR 第五章（第 44–49 条）
• 欧洲法院 C-311/18（Schrems II）
• EDPB《建议 01/2020》v2.0（补充措施）
• EDPB《建议 02/2020》（基本保障）
• EDPB《指南 05/2021》v2.0（第 3 条 / 第五章互动）
• EDPB《指南 2/2018》（第 49 条克减）
• CNIL TIA 指南（最终版，2025 年 1 月）
• 慕尼黑高等地区法院，21 U 3882/25 e（2026 年 5 月 11 日）
• 实施决定（EU）2023/1795（欧盟-美国 DPF）
• Rosenthal EU SCC TIA Toolbox（v1.10，2025 年 9 月修补）

完整引用见 references/sources.md。

变更日志

见 CHANGELOG.md。

相关 GDPR 技能

本技能可独立使用，但与我的其他欧盟数据保护技能搭配效果良好——可单独安装任一技能或组合使用：

• DPIA Sentinel——第 35 条数据保护影响评估
• GDPR Breach Sentinel——第 33/34 条违规响应与通知
• Privacy Notice Generator——第 13/14 条隐私通知
• DPA Art. 28——控制者-处理者协议（AVV）
• Legitimate Interest——第 6(1)(f) 条合法利益评估/利益平衡测试