| name | dpa-review |
| description | 依据你的数据处理协议（DPA）操作手册审查一份DPA——自动检测你是受托处理者 还是处理者，并应用操作手册正确的半部分。当用户说"审查这份DPA""检查这份 数据处理附录""客户发来了他们的DPA""这份DPA可以吗"，或附上一份DPA时使用。
|
| argument-hint | [文件 | 网盘链接 | 粘贴文本] |
/dpa-review
- 加载
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → DPA 操作手册。如为占位符，停止并提示设置。
- 获取 DPA。确定方向：我们是受托处理者（客户发来DPA）还是处理者（审供应商的DPA）？不明确时询问。
- 执行以下工作流——逐条对照相应的操作手册行。
- 执行个人信息处理规则一致性检查。
- 输出：带修订标记的审查备忘录。按内部格式保存。
/privacy-legal:dpa-review 客户dpa.pdf
DPA 审查（数据处理协议审查）
事项上下文
事项上下文。 检查实践级 CLAUDE.md 中的 ## 事项工作区。如果 已启用 为 ✗（法务用户的默认值），跳过本段——技能使用实践级上下文，事项机制不可见。如果已启用且无活动事项，询问："这是哪个事项？运行 /privacy-legal:matter-workspace switch <slug> 或说 实践级。"加载活动事项的 matter.md 获取事项特定上下文和覆盖项。将输出写入事项文件夹 ~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/。除非 跨事项上下文 为 开启，否则绝不读取其他事项的文件。
目的
DPA 有两种形态，审查方向几乎完全相反。当客户发来他们的 DPA，我们在捍卫我们的运营灵活性。当我们给供应商发 DPA，我们在保护我们（及我们客户的）数据。两次审查都读同一份 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 操作手册，但从相反的行读取。
首先：哪个方向？
做任何事之前，先确定：
- 我们是受托处理者 → 客户向我们发送他们的 DPA → 读取
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → "当我们是受托处理者时" 表（对应个保法第21条委托处理 [法条原文]）
- 我们是处理者 → 我们正向供应商发送 DPA（或审查他们的）→ 读取 "当我们是处理者时" 表
如果不清楚，询问。方向搞错将颠倒每项建议。
法域假设
本审查假定你的配置中指定的法域范围。隐私规则、响应期限和合法性基础因法域而异（个保法 vs. GDPR vs. 其他法域）。如果处理者、受托处理者或个人信息主体位于不同于配置的法域，本审查可能不直接适用。
加载关于本对方当事人/活动的先前上下文
审查前，检查输出文件夹中关于本对方当事人或处理活动的先前工作。读取 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## 输出 获取输出文件夹路径。扫描：
- 先前的
use-case-triage 结果 涵盖同一对方当事人/处理活动——分诊产生风险评级和条件，本 DPA 审查应遵守或明确偏离。
- 先前的
pia-generation 输出 涵盖本对方当事人/处理活动——PIA 可能已标注需要 DPA 实施的风险缓解措施。
- 先前的
dpa-review 输出 涵盖同一对方当事人——先前的 DPA 审查设定了关于什么可接受、什么被标注、什么已解决的预期。一份静默地与先前审查相矛盾的新审稿侵蚀对工作产品的信任。
如果找到先前的输出，在审查中引用：
"先前的分诊（[日期]）将本活动评为[风险等级]，并以[X]为批准条件。本 DPA 审查与该发现一致。"——或——
"先前的分诊（[日期]）将本活动评为[风险等级]。本 DPA 审查偏离该发现因为[理由——新事实、不同范围、改变了图景的合同条款]。"
从上游继承严重程度作为底线，遵循 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## 共享护栏 中的跨技能严重程度底线规则。被分诊评为🔴的处理活动不能在 DPA 审查中静默降级为🟢；任何降级均应说明和解释。
如果未找到先前的输出（新对方当事人/新活动），在审查中明确说明——"输出文件夹中无关于本对方当事人的先前分诊或PIA"——以便审核律师知道检查已执行。
加载操作手册
读取 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## DPA 操作手册。同时读取 ## 个人信息处理规则承诺——DPA 不能与处理规则承诺相矛盾。
行业监管叠加（在逐条审阅之前先问）
在逐条审阅之前，回答：通过本 DPA 的数据是否包含任何受行业特别监管的类别？ 个保法和通用数据保护法提供一个底线；行业监管通常提供另一个不出现在通用 DPA 操作手册中的底线。一份个保法完整的 DPA 仍可能在金融、医疗健康、未成年人保护等方面存在盲区。
行业监管叠加——首先询问：
本处理活动是否涉及：
- 消费者的个人金融信息（《个人金融信息保护技术规范》JR/T 0171-2020 + 征信业管理条例）？如为是，DPA 需要：(a) 与金融信息保护技术规范一致的共享限制，(b) 安全保护措施与行业标准对齐，(c) 事件通知机制覆盖金融监管部门时限要求，(d) 明确约定数据接收方的安全保护义务。
- 健康医疗数据，由医疗机构或健康医疗数据处理者持有（人口健康信息管理办法 + 个保法）？如为是，DPA 需要：数据接收方须具备相应的安全保护能力和资质，明确使用限制和保密义务，事件通知时限，下游处理者授权条款。
- 不满十四周岁未成年人的个人信息（儿童个人信息网络保护规定 + 个保法第31条）
[法条原文]？如为是，DPA 需要：监护人知情同意流转条款，严格的保留限制和删除机制，禁止用于行为广告（除非有监护人明确同意）。
- 其他行业性监管制度（如汽车数据安全管理若干规定、征信业管理条例、关键信息基础设施安全保护条例等）？
如果任一项为是：行业监管通常提供主导性的实体性限制。检索现行有效的规定并引用。一份"豁免"了个保法某条要求但受行业监管约束的 DPA，仍需满足行业监管的限制——豁免只是转换了适用框架，不消灭合规义务。在红线问题清单中将行业性缺口与通用数据保护缺口并列标注。
如果无行业监管叠加适用，明确说明——"未识别到受行业特别监管的数据类别；行业监管叠加不适用"——以便审核律师看到检查已执行，而非猜测是否被跳过。
逐条审查
核心条款（每份 DPA 都查）
逐条审查 DPA 的以下条款。具体的数值和实体立场（通知期限、泄露时限、可接受/不可接受底线）来自 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## DPA 操作手册。任何 DPA 必须满足的监管底线来自主源法律——检索每个适用制度的现行有效规则并引用主源后再陈述底线。
禁止静默补充。 如果检索查询返回结果很少或为零，报告找到的内容并停止。不要未经询问即从网络搜索或模型知识填补空白。说："搜索返回[N]条结果。覆盖显得薄弱。选项：(1) 扩大搜索查询，(2) 尝试不同的检索工具，(3) 搜索网页——结果将标记为 [联网检索 — 需复核]，(4) 标记为未验证并停止。你想选哪个？"由律师决定是否接受可信度较低的来源。
来源溯源标签分层。 为审查中每处引用标记来源。对于模型知识引用，使用三层而非单一"验证"标签：
[已确定] — 稳定、众所周知的法定和行政法规引用，不太可能已变更（如个保法第21条委托处理、第57条泄露通知）。提交前仍应验证，但优先级较低。[需验证] — 模型知识引用是真实的但应验证：具体实施细则、监管部门指引、案例立场、阈值、生效日期。[需验证——精准引用] — 精准引用（具体款号、条号、段落编号）造假风险最高，应始终对照主源验证。
检索工具获取的引用保留其来源标签；网页搜索引用保留 [联网检索 — 需复核]；用户提供的引用保留 [用户提供]。分层揭示了真正的验证工作——什么都验证的人什么也没验证。绝不剥离或折叠标签。
| 条款 | 关注点 | 操作手册字段 | 常见争议 |
|---|
| 角色 | 清晰的处理者/受托处理者指定；匹配实际 | — | 对方将关系标签为（如"共同处理者"）与实际不符 |
| 处理范围 | 限于书面指示；定义目的 | — | 开放式范围扩展（"及相关目的"） |
| 下游处理者 | 当前名单已披露，变更机制已定义 | 下游处理者变更 | 一揽子批准 vs. 否决权 vs. 仅通知 |
| 安全措施 | 附件引用具体控制措施或标准 | 安全标准 | "适当的技术和组织措施"无附件 = 空洞承诺 |
| 泄露通知 | 已定义触发（"发现" vs. "确认"），已定义时限 | 泄露通知 | 时限紧迫度；计时起点；"及时"的模糊性；个保法第57条要求立即通知网信办和个人 [法条原文] |
| 审计权 | 方式（报告 vs. 现场），频率，通知期限，费用分配 | 审计权 | 短通知期限的现场审计 |
| 数据出境 | 出境机制已识别，补充措施，出境安全评估参照 | 数据出境 | 缺失或过时的出境机制；是否已通过安全评估/签署标准合同/获得认证（个保法第38条） [法条原文] |
| 删除/返还 | 合同终止后时限，认证，备份例外 | 终止后删除 | "商业上合理的"删除 = ??? |
| 责任 | 在主合同责任上限内或单独核算；例外 | 数据责任 | 数据泄露无上限责任 = 公司存亡风险 |
当我们是受托处理者时：防御性审查
客户的 DPA 试图将运营负担推向我们。对以下每一条，将客户的要求与操作手册对比。当客户要求超出操作手册时，推回至团队标准立场（来自配置 CLAUDE.md），并准备好退至可接受立场。
| 条款 | 风险 | 检索 / 操作手册查询 |
|---|
| 下游处理者批准权（否决权） | 每次新增基础设施需逐客户审批 | 应用操作手册关于下游处理者变更的立场 |
| 短通知期限的现场审计 | 大规模下不可操作 | 应用操作手册关于审计权的立场 |
| 激进的数据泄露通知窗口 | 通常在我们知晓发生什么之前要求通知 | 检索各适用制度的监管底线（引用主源——个保法第57条要求"立即"通知）；对比操作手册立场 |
| 硬性数据本地化（单一城市/数据中心） | 可能不匹配架构 | 应用操作手册关于数据位置的立场；确认我们实际能承诺什么 |
| 受托处理者责任无上限 | 赌公司 | 应用操作手册关于数据责任的立场 |
| 客户可发出有约束力的"指示" | 开放式运营控制 | 将指示定义为"合同约定或书面同意" |
| 极短期限内的删除 | 备份和日志保留使此不可能 | 应用操作手册关于终止后删除的立场；记录备份循环例外 |
当我们是处理者时：保护性审查
供应商的 DPA 试图什么都给我们。但对我们：不给。对以下每一条，对比处理者侧操作手册。
| 条款 | 缺口 | 检索 / 操作手册查询 |
|---|
| 无下游处理者名单 | 不知道谁接触我们的数据 | 要求公开当前名单 + 按操作手册要求的事先通知 |
| "行业标准安全" | 毫无意义 | 要求附具体控制措施的附件，或引用指定的标准（如等级保护三级、ISO 27001） |
| 无泄露通知时限 | 他们随便什么时候告诉我们 | 检索适用监管底线（个保法第57条作为参照 [法条原文]）；要求操作手册立场 |
| 完全没有审计权 | 无法核实任何事 | 至少要求按操作手册的独立审计报告 |
| 供应商可将数据用于"服务改进" | 可能在我们数据上训练模型 | 删除；处理限于向我们提供服务 |
| 无数据出境机制 | 无合法出境机制 | 检索当前有效的出境机制适用于相关路径（数据来源地/目的地，适用制度，任何充分性认定，任何补充措施）。引用主源并验证时效。 |
| 无删除承诺 | 数据永远存在 | 要求操作手册关于删除的立场 + 按请求认证 |
一致性检查：个人信息处理规则
你签署的 DPA 不能承诺处理规则未涵盖的内容，反之亦然。
- 如果 DPA 承诺仅为 X、Y、Z 目的处理——处理规则是否列出这些目的？
- 如果处理规则说"我们从不向第三方提供数据"——DPA 中是否有任何条款看起来像向第三方提供或共享？
- 如果处理规则指定了特定的下游处理者类别——DPA 的下游处理者名单是否匹配？
标示不匹配。通常是处理规则陈旧，而非 DPA 错误，但必须有人修复其中之一。
修订标记粒度
以尽可能最小的粒度编辑。 修订标记是谈判工件，不是重写。整条替换信号"我们抛掉了你们的起草"——这是侵略性的，它迫使对方重新阅读整条，并丢弃了他们起草中那部分没问题的内容。手术式的修订标记——删除一个词、插入一个短语、重构一个子条款——信号"我们有具体的诉求"，更容易阅读、理解和接受。
默认使用最小的编辑来实现操作手册立场：
- 先替换一个词，而非短语。（"十二（12）" → "二十四（24）"）
- 先替换一个短语，而非句子。（"由买方支付" → "由买方支付且应付"）
- 先重构一个子条款，而非替换句子。（添加"(a)"和"(b)"以拆分复合条件。）
- 先替换一个句子，而非替换整条。
- 仅当对方的版本离你的立场太远、手术式编辑比重新起草更难阅读时，才替换整条——此时在传递函中说明："我们替换了第8.2条而非逐处修订，因为变更范围广泛。愿意带您逐项过一遍变化。"
存疑时，用更小的。收到手术式修订标记的客户信任你仔细阅读了。收到整体替换的客户怀疑你根本就没读。
输出
冠以 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md ## 输出 中的工作成果抬头（因用户角色不同而异——见 ## 谁在使用）。
[工作成果抬头 — 按插件配置 ## 输出]
# DPA 审查：[对方当事人]
**方向：** [我们是受托处理者 / 我们是处理者]
**审阅日期：** [日期]
**所附于：** [主合同 / 独立文件]
---
## 结论
[两句话。能否签署？什么必须变更？]
**问题：** [N]🟢 [N]🟡 [N]🟠 [N]🔴
---
## 逐条审查
[对每个核心条款，使用标准偏差备忘录格式：对方 DPA 怎么写的，我们操作手册怎么说的，差距，风险，以及提议的修订语言。每条保持为简短的独立块，以便审核人可以略读。]
---
## 个人信息处理规则一致性
[🟢 一致 | 🟡 提示：列出]
---
## 建议修订
[汇总——可直接发回]
---
## 如对方不让步
[对每个问题：来自配置 CLAUDE.md 的退让立场，或如无退让立场则升级路径]
数据出境说明
如果 DPA 涉及数据出境，检索当前有效的出境机制要求适用于相关通道。对每个来源地/目的地对，识别：适用制度，是否需要进行安全评估（《数据出境安全评估办法》）、签署标准合同（《个人信息出境标准合同办法》）或获得认证（个保法第38条），是否需要出境安全评估报告，以及可能需要哪些补充措施。引用主源（法律、行政法规、网信办指引）附精准引用并验证时效——安全评估门槛、标准合同版本和所需补充措施因新规出台而变化。不确定时标示，供律师核实。
如果缺失出境机制且确实有数据出境，这是 🔴——无合法出境机制。
关口：签署 DPA
审查 DPA 是研究。签署它——或指示某人代表我们签字盖章——是具有法律后果的行为。
在签署 DPA（包括返回已签署版本、在对方平台上同意自动执行、或指示签字人签署）之前： 读取 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 中的 ## 谁在使用。如果角色为非律师：
签署 DPA 是法律行为——它使公司受到具体的数据保护义务约束，这些义务流向监管机构和个人信息主体。你是否已请律师审查过？如已审查，继续。如未审查，以下是你带给律师的简要材料：
[生成1页摘要：对方当事人，方向（我们是受托处理者/处理者），偏离操作手册的条款及如何解决的，任何待定的退让决定，以及签署前应询问律师的三件事。]
如果你需要寻找执业律师或其他经授权的法律专业人士：通过你所在地区的律师协会或司法局的律师查询系统是最快的起点。
未经明确同意，不得越过此关口。
以下一步决策树结束
以符合 CLAUDE.md ## 输出 的下一步决策树结束。根据本技能刚刚产出的内容定制选项——五个默认分支（起草X、升级、获取更多事实、观察和等待、其他）是起点，而非锁定。决策树即输出；律师选择。
本技能不做的事
- 不从头起草 DPA。如果答案是"用我们的模板"，从配置 CLAUDE.md 中的种子文档路径提取模板。
- 不做出境安全评估本身——它标注何时需要一个。
- 不决定是否接受超出退让立场的条款。它按升级表路由这些决策。
