Dpa clause reviewer

何时使用

• 用户说"审查这份 DPA / 数据处理协议 / 数据处理附录"，或"客户发来了他们的 DPA""这份 DPA 行不行"，或直接附上一份 DPA 文件/链接/文本时。
• 核心前提：你有一份内部 DPA 立场清单（playbook），记录了通知期、违约时限、可接受/不可接受底线等具体数值与立场。没有立场清单则先要求配置，不要凭空编造立场。

不该用的边界：

• 不从零起草 DPA。若结论是"用我们的模板"，去取模板而非生成。
• 不亲自做传输影响评估（TIA）——只标注何时需要做。
• 不替人决定是否接受立场清单之外的条款——这类按升级路径转交律师。

步骤

1. 加载立场清单：读取内部 DPA playbook；同时读取隐私政策承诺（DPA 不能与隐私政策互相矛盾）。若是占位符未配置，停止并提示配置。
2. 先定方向（最关键）：判定己方角色——
   • 我们是处理者（客户把他们的 DPA 发给我们）→ 用"作为处理者"那一栏，做防御性审查，守住运营灵活性。
   • 我们是控制者（我们把 DPA 发给供应商，或审查供应商的）→ 用"作为控制者"那一栏，做保护性审查，守住数据。
   • 不清楚就问。搞错方向会让每一条建议反向。
3. 加载历史上下文：检查输出文件夹中针对同一对手方/处理活动的既往产出（用例分流、PIA、过往 DPA 审查）。命中则在备忘录中引用，并把上游严重级别作为下限——分流评为🔴的活动不能在本次审查中被悄悄降为🟢，任何降级都要写明理由。无历史则明确写"输出文件夹中无此对手方的既往分流或 PIA"，让审阅律师知道这步跑过了。
4. 联邦/行业叠加层（在逐条审查前先问）：本协议流经的数据是否含受联邦/行业专门法监管的类别？GDPR 与各州消费者隐私法是一道底线，行业专门法往往是通用清单里没有的另一道。逐项确认（见下方指令）。无则明确写"未识别到受专门法监管的数据类别；行业叠加层 n/a"。
5. 逐条审查：对照立场清单逐条款走核心条款表。监管底线必须检索当前生效的规则并引用一手来源，不得凭模型知识填补。
6. 隐私政策一致性检查：DPA 承诺的处理目的、子处理者类别等是否与隐私政策一致；是否有条款在 CCPA 下构成"出售"而与"绝不出售数据"的政策冲突。标注不一致项。
7. 出具产物：含红线的审查备忘录，按内部文体保存到对应目录。

指令

核心条款逐条走查表（具体数值/底线来自立场清单，监管底线来自一手法律）：

条款	关注点	常见争点
角色	控制者/处理者界定清晰且与事实相符	对手方标成"联合控制者"等不符实际
处理范围	限于书面指示、目的明确	开放式扩张（"及相关目的"）
子处理者	现有清单已披露、变更机制明确	概括批准 vs 否决权 vs 仅通知
安全措施	附件引用具体控制或标准	"适当技术与组织措施"却无附件＝空头承诺
违约通知	触发点（"发现"vs"确认"）与时限明确	时限松紧、计时起点、"不无故拖延"太模糊
审计权	方式（报告 vs 现场）、频率、通知、费用分担	短通知期的现场审计
跨境传输	传输机制已指明、补充措施、TIA 引用	机制过时或缺失
删除/返还	终止后时限、证明、备份豁免	"商业上合理"的删除＝？
责任	在 MSA 上限内或单列、例外	数据泄露责任不封顶＝致命

作为处理者（防御）：子处理者逐客户否决权→套用清单立场；短通知现场审计→不可行；激进违约通知窗口→检索各适用法域监管底线并引一手来源对比清单；硬性数据驻留→确认架构能承诺什么；处理者责任不封顶→赌上公司；客户可发约束性"指示"→定义为"协议中书面记载或书面另行约定"；删除时限过短→记录备份轮换豁免。

作为控制者（保护）：无子处理者清单→要求公布现行清单＋提前通知；"行业标准安全"→要求附件列具体控制或指名标准（SOC 2、ISO 27001）；无违约通知时限→检索监管底线并要求清单立场；无审计权→至少要求独立审计报告；供应商可将数据用于"服务改进"→删除，处理仅限向我们提供服务（防止拿我们数据训练）；无跨境传输机制→检索该走廊当前生效的传输机制并引一手来源；无删除承诺→要求清单立场＋按需出具删除证明。

联邦/行业叠加层逐项问：GLBA/Reg P（金融账户数据、消费者 NPI）；HIPAA（受保护健康信息 PHI，需 BAA 与 DPA 叠加并下沉至分包商）；FERPA（教育记录，"学校官员"框架、家长同意流转）；COPPA（13 岁以下儿童数据，需可验证家长同意流转、留存限制、按需删除）；其他（VPPA/CPNI/DPPA/TCPA 等）。关键：CCPA § 1798.145(e) 的"豁免"只是移动了治理框架而非消除义务——GLBA 覆盖的数据仍受 GLBA 约束。

两条硬规矩：

• 不得静默填补：检索工具对某监管底线返回结果稀少时，报告所得并停下来问，不要用网络搜索或模型知识私自补全。
• 来源分级标注：每条引用打标签——[settled]（GDPR 第28条、第33条72小时通知等稳定引用，仍需核但优先级低）、[verify]（具体实施细则、监管指南、判例、充分性决定、SCC 模块版本、阈值、生效日期）、[verify-pinpoint]（具体小节字母、SCC 内条款号、段落号等精确定位，伪造风险最高，必须对照一手来源核验）。工具来源保留 [Westlaw]/[监管机构站点] 标签，网络搜索为 [web search — verify]，用户提供为 [user provided]。绝不剥除或合并标签。

红线粒度——以能达成立场的最小改动为默认。 红线是谈判物，不是重写。整条替换显得"把你的起草全推翻"。优先级：改一个词（"twelve (12)"→"twenty-four (24)"）＞改短语＞重构子条款＞替换整句＞替换整条。只有当对手方版本离立场太远、外科式修改反而更难读时才整条替换，并在转送函中说明原因。

签署闸门：审查 DPA 是研究，签署才是有后果的行为。在签署/会签/同意平台自动执行前，若使用者角色是非律师，须提示："签署 DPA 是法律行为，会让公司承担流向监管者和数据主体的特定数据保护义务。是否已与律师审过？"并生成一页摘要（对手方、方向、偏离清单的条款及其处理、未决回退决定、签前要问律师的三件事）。未得到明确"是"不得越过此闸门。

示例

用户：客户发来了他们的 DPA，帮我看看能不能签。customer-dpa.pdf

处理路径：

1. 加载立场清单与隐私政策承诺。
2. 定方向：客户发来他们的 DPA → 我们是处理者 → 走防御性审查。
3. 扫输出文件夹：找到该客户 3 个月前的用例分流，评级🟡——本次审查须不低于此下限。
4. 联邦叠加层：数据含消费者金融账户信息 → 触发 GLBA/Reg P，DPA 需要安全保障规则对齐措施与 NPI 共享限制；标为缺陷。
5. 逐条走查：违约通知要求"24 小时内"但立场清单底线是"发现后 72 小时" → 红线改回；子处理者逐客户否决权 → 推回至概括通知＋异议机制。
6. 隐私政策一致性：DPA 列的子处理者类别与政策一致 → 🟢。
7. 出具备忘录骨架：

# DPA 审查：[对手方]
**方向：** 我们是处理者
**审查日：** [日期]    **附属于：** MSA

## 结论
[两句话：能签吗？必须改什么？]
**问题：** [N]🟢 [N]🟡 [N]🟠 [N]🔴

## 逐条
[每个核心条款一块：对手方怎么写／我们清单怎么说／差距／风险／拟议红线]

## 隐私政策一致性
[🟢 一致 | 🟡 标记：列出]

## 建议红线
[已整合，可直接回传]

## 若对方不让步
[每个问题的回退立场，或无回退时的升级路由]

注意事项

• 方向定错＝全盘反向，这是第一优先级，模棱两可必须先问。
• 法域假设：本审查假定配置中指定的法域范围。GDPR、州消费者隐私法、行业法的规则、响应时限、合法性基础差异巨大；若控制者/处理者/数据主体在配置外的法域，审查可能不适用。
• 跨境传输若缺失传输机制且确有国际传输 → 直接判 🔴（无合法传输机制）。SCC 版本、充分性决定、所需补充措施会因新决定/判例/监管指南而变，引一手来源并核验时效。
• 严重级别只能升不能悄悄降；任何降级都写明并解释。
• 检索稀少不要硬填——停下来问，由律师决定是否接受低置信来源。

互见

• fact-checking：核验一手来源引用（充分性决定、SCC 版本、判例时效）时配合使用。
• first-principles-thinking：在方向判定或条款立场存在根本分歧时，回到"我们到底在保护什么"重新推演。

---

本条采编自 anthropics/claude-for-legal（Apache-2.0），适配重写为中文技能大典条目。