pia-generation

/pia-generation

1. 加载 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → PIA 的团队风格（触发条件、结构、深度、签署）。
2. 运行以下工作流。
3. 检查：是否确实需要 PIA？（团队触发条件 + 研究每项适用法规的强制评估触发条件——引用一手资料，并核实其时效性。）
4. 收集信息：向产品团队提问。若提供了 PRD，可从中提取信息。
5. 按团队格式撰写 PIA。纳入隐私政策一致性检查。
6. 输出条件清单和明确的负责人。提交审批。

/privacy-legal:pia-generation "Location sharing feature"

/privacy-legal:pia-generation
PRD: [Drive link]

---

PIA 生成

事项背景

事项背景。 检查实践层级 CLAUDE.md 中的 ## Matter workspaces。如果 Enabled 为 ✗（内部用户的默认值），跳过本段其余内容——技能使用实践层级的背景信息，事项管理机制不可见。如果已启用且没有活动事项，请询问：“这是哪个事项？运行 /privacy-legal:matter-workspace switch <slug>，或回复 practice-level。”加载活动事项的 matter.md，获取事项专属背景和覆盖设置。将输出写入事项文件夹 ~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/。除非 Cross-matter context 为 on，否则绝不读取其他事项的文件。

---

目标位置检查

生成输出前，先检查内容将发送到哪里。如果用户指定了目标位置（频道、分发列表、交易对方、“所有人”），请询问该位置是否属于特权保护圈。公开频道、全公司分发列表、交易对方／对方律师、供应商以及客户（对于工作成果）都会导致保护失效。如果目标位置看起来不在保护圈内，请指出这一点，并提供以下选项：(a) 仅供法务使用的特权版本；(b) 面向更广泛频道的脱敏版本；或 (c) 两者——不要悄悄加上特权标记，随后又帮忙将内容粘贴到无法受该标记保护的位置。请参阅此插件 CLAUDE.md 中的规范章节 ## Shared guardrails → Destination check。

目的

PIA 是与产品团队的一次对话，并将其记录下来。它会询问：有哪些数据、为何使用、保留多久、谁能看到、可能出现什么问题。此技能将这场对话整理成结构化内容，并按照本团队的格式撰写输出——该格式是在冷启动期间从种子 PIA 中学习得来的。

管辖范围假设

本评估假定适用的是配置中指定的管辖范围。不同管辖范围的隐私规则、评估触发条件和合法依据存在重大差异（GDPR、州消费者隐私法与行业法规之间均有差异）。如果处理活动、控制者或受影响的数据主体属于其他管辖范围，本分析可能不适用于实际情况。

加载此功能 / 活动的先前上下文

撰写新的 PIA 之前，请检查 outputs 文件夹中是否有关于同一功能、处理活动或交易对方的先前工作。阅读 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## Outputs，查找路径。检查以下内容：

• 先前关于此活动的 use-case-triage 结果——分诊的风险评级、强制条件和指出的问题，是 PIA 分析的起点。
• 关于相同或重叠活动的先前 pia-generation 输出——后续 PIA 应说明如何与先前结论衔接（哪些内容有变化，哪些内容沿用）。如果 PIA 对同一活动悄然得出与先前 PIA 不同的结论，就会产生审阅律师无法察觉的矛盾。
• 适用范围内供应商的先前 dpa-review 输出——DPA 审查结果可为 PIA 对子处理方 / 跨境 / 保留风险的分析提供依据。

如果找到先前输出，请在 PIA 中引用：

“先前的分诊（[日期]）将此活动评为[风险等级]，并要求满足[条件]。本 PIA 以该结论为基础——[说明哪些条件已满足、哪些仍未满足、哪些已调整范围]。”

如果存在先前的 PIA：

“本 PIA 取代[日期]的 PIA，原因是[原因——范围变更、新的数据类别、供应商变更、监管变化]。沿用的结论：[X]。修订的结论：[Y，原因是 Z]。”

按照跨技能严重程度下限规则，将上游的严重程度作为最低标准。该规则见 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## Shared guardrails。如果 use-case-triage 将此活动评为高风险，PIA 就不能在不说明原因及变化的情况下得出低风险结论。

如果没有找到先前输出，请明确说明——“outputs 文件夹中没有此活动的先前分诊或 PIA；这是一次冷启动”——让审阅律师知道已进行检查，且没有找到需要协调的内容。

加载团队风格

阅读 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## PIA house style。其中包含：

• 在此处哪些情况需要进行 PIA（可能与监管 DPIA 的触发条件不同——有些团队会对所有事项进行 PIA，有些团队只对高风险事项进行）
• 从种子 PIA 提取的结构模板
• 通常的详略程度
• 审批人

如果配置 CLAUDE.md 中包含种子 PIA 的结构，请使用该结构。这样做是为了让本 PIA 与团队制作的其他 PIA 保持一致，而不是像一份通用文档。

步骤 0：是否需要 PIA？

查看 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 中的触发标准。这是团队的既定答案。

此外，研究监管范围内每项制度当前生效的强制评估触发条件（GDPR/UK GDPR 的 DPIA 触发条件、CCPA/CPRA 的风险评估触发条件、其他美国州的数据保护评估触发条件，以及行业监管制度）。引用具有约束力的法规、规章或监管机构指导文件，并提供精确出处。核实信息是否仍然有效——评估门槛和定义会随着新的州法律、规则制定和执法指导而变化。有不确定之处时应明确指出，不要猜测。

不得悄悄补充信息。 如果对配置的法律研究工具发起查询后，针对某项制度的 DPIA／风险评估触发条件或合法依据返回的结果很少或没有，请报告已找到的内容并停止。未经询问，不得通过网络搜索或模型知识填补空白。请说明：“从 [工具] 搜索到 [N] 条结果。关于 [制度／问题] 的资料似乎不充分。可选方案：(1) 扩大搜索范围，(2) 尝试其他研究工具，(3) 搜索网络——结果将标记为 [web search — verify]，依赖前应对照一手来源核实，或 (4) 标记为未经核实并停止。您希望怎么做？”是否接受可信度较低的来源，由律师决定。

来源归属。 为 PIA 中的每条引文标注来源：来自法律研究连接器的引文标注为 [Westlaw]、[regulator site] 或 MCP 工具名称；网络搜索引文标注为 [web search — verify]；回忆自训练数据的引文标注为 [model knowledge — verify]；用户提供的引文标注为 [user provided]。带有 verify 标记的引文伪造风险较高，应优先核实。绝不能删除或合并这些标记。

除法定要求外，即使严格来说并非强制，也应将以下情况视为值得进行 PIA 的强烈迹象（研究其中任何一项是否会根据适用制度独立触发强制评估）：

• 新技术或对现有技术的新颖用途
• 儿童数据
• 合并并非一同收集的数据集
• 可能导致歧视的数据
• 用户不会预期的数据处理

如果没有适用的法定触发条件，且也未达到团队既定触发标准 → “看起来不需要进行 PIA。这里有一段说明原因的文件记录，供日后有人询问时使用。”

信息收集

在撰写任何内容之前，先向产品团队了解以下信息。可以采用对话形式——这不是一份要发给他们填写的表格。

内容与目的

• 这是什么功能／产品／变更？
• 它为用户解决什么问题？
• 涉及哪些个人数据？请具体说明——“用户数据”不是答案。具体有哪些字段？
• 是否包含任何新收集的数据，还是全部都是已有数据？
• 涉及哪些处理活动——存储、分析、共享、自动化决策？

法律依据 / 特定制度检查

对于每项适用制度，研究下列问题所涉及的当前有效框架，并引用一手资料：

• 对于要求明确处理合法依据的制度（例如 GDPR、UK GDPR），针对每项目的确定其依据（合同 / 合法利益 / 同意 / 法律义务 / 重大利益 / 公共任务 / 其他）。研究具体要求，以及任何关于平衡测试或同意标准的预期；引用具有约束力的权威来源。
• 对于监管披露行为的制度（例如 CCPA/CPRA 和其他美国州隐私法），检查任何数据流是否符合当前有效法定定义中的“出售”“共享”或其他受监管披露。第三方广告是常见陷阱——研究其是否属于适用制度下的受监管类别。
• 对于行业制度（HIPAA、GLBA、COPPA、FERPA 等），研究特定制度的依据或披露规则。

核实时效性；法定定义和处理依据经常修订。如有不确定之处，标记出来以供律师核实。

涉及人员与存储位置

• 公司内部哪些人可以查看这些数据？工程师？支持人员？分析师？
• 是否涉及任何第三方？供应商、合作伙伴、分析服务？
• 数据存储在哪里？哪个区域？使用新的还是现有的基础设施？
• 数据保留多久？是否有删除计划，还是会永久保留？

可能出现的问题

• 如果这些数据泄露，会对个人造成什么伤害？
• 这些数据是否可能被用于歧视，即使是无意的？
• 用户会对这种做法感到意外吗？（“令人不适测试”——并非法律标准，但很有参考价值。）
• 是否提供退出选项？是否应该提供？

撰写 PIA

**使用配置文件 CLAUDE.md 中的种子 PIA 结构。**如果未找到，请使用以下默认结构。在文首添加 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 的 ## Outputs 中的工作成果标头（该标头因用户角色而异——请参阅 ## Who's using this）。

[WORK-PRODUCT HEADER — per plugin config ## Outputs]

# Privacy Impact Assessment: [Feature/Product Name]

**Prepared by:** [name] | **Date:** [date] | **Status:** DRAFT / APPROVED
**Product owner:** [name] | **Privacy reviewer:** [name]

---

## Executive summary

[Two sentences: what this is, whether it's okay. E.g., "Feature X collects
location data to provide Y. Processing is consistent with existing privacy
policy commitments and uses consent as lawful basis. Two mitigations
recommended below; no blockers identified."]

**Overall risk:** [Reviewer to set: 🟢 Low / 🟡 Medium / 🟠 High / 🔴 Very high]

---

## 1. Description of processing

**What:** [the feature, in plain English]
**Data categories:** [specific fields — not "user data"]
**Data subjects:** [customers / end users / employees / etc.]
**Purpose:** [why — tie to user benefit]
**New collection?** [yes — these fields are new / no — reusing existing data]

---

## 2. Lawful basis

| Purpose | Basis | Notes |
|---|---|---|
| [purpose 1] | [Contract / LI / Consent / etc.] | [if LI: balancing test summary; if consent: how obtained] |

---

## 3. Data flow

**Collection:** [how/where data enters]
**Storage:** [system, region, encryption]
**Access:** [who, via what controls]
**Sharing:** [third parties, purpose, governed by which DPA]
**Retention:** [how long, deletion mechanism]

---

## 4. Privacy policy consistency

| Policy commitment | Consistent? | Notes |
|---|---|---|
| [commitment from config CLAUDE.md privacy policy section] | 🟢 / 🟡 | |

[If any 🟡: policy update needed before launch, or processing needs to change]

---

## 5. Risks and mitigations

| # | Risk | Likelihood | Impact | Mitigation | Status | Owner |
|---|---|---|---|---|---|---|
| 1 | [specific risk, tied to the design — not "data breach" generically] | L/M/H | L/M/H | [specific control] | Done / Planned / Gap | [name] |

**Residual risk after mitigations:** [assessment]

---

## 6. Data subject rights

| Right | Can be exercised? | How |
|---|---|---|
| Access | | |
| Deletion | | |
| Correction | | |
| Portability | | |
| Objection | | |

---

## 7. Recommendation

[APPROVED / APPROVED WITH CONDITIONS / CHANGES REQUIRED / NOT APPROVED]

**Conditions (if any):**
- [ ] [specific thing that has to happen before launch]

**Sign-off:** [name, date]

风险质量标准

PIA 中的风险应当具体且与设计相关，而非泛泛而谈。糟糕的风险描述会让文档充斥无用内容，还会让读者养成略读的习惯。

不佳的风险描述	不佳之处	更好的写法
“数据泄露”	适用于所有情况；没有提供任何信息	“支持人员可通过管理面板访问位置历史记录，且没有审计日志——恶意内部人员可能在不被发现的情况下追踪用户”
“不遵守 GDPR”	循环论证——PIA 的目的正是评估合规性	指出具体条款及其缺口
“用户可能不喜欢”	含糊	“已选择退出营销的用户仍可能收到相关内容，因为此流程未检查退出标记”

应列出 2–5 项真实风险，而非凑出 15 项。

隐私政策差异

每份 PIA 都应对照 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 中的隐私政策承诺进行核查。常见的不一致情况：

• 政策称“我们收集 X、Y、Z”——新功能还会收集 W。需要更新政策，或停止收集 W。
• 政策称“我们不会出售数据”——新功能会与广告合作伙伴共享数据。这可能构成 CCPA 下的出售。
• 政策称保留期限为“只要你的账户处于活跃状态”——新功能在账户删除后仍会保留数据。

标记所有不一致之处。上线前必须修改其中一方。

交接

• **交给产品团队：**列出条件，并注明负责人和截止日期。不要写“加强安全性”，而要写“在管理面板的位置查询功能中添加审计日志，负责人：[eng lead]，须在上线前完成。”
• **交给 reg-gap-analysis 技能：**如果 PIA 发现政策不一致，由该技能跟踪政策更新。
• **交给审批流程：**根据 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → 谁负责批准 PIA。

关卡：向监管机构提交 DPIA

编制内部 PIA 属于研究和文档工作。向监管机构提交 DPIA——或在回应问询时自愿向监管机构披露 DPIA——才是会产生重大后果的行为。

**在继续向监管机构、监督机关或执法机构提交 DPIA（或任何同等的影响评估）之前：**请阅读 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 中的 ## Who's using this。如果 Role 为 Non-lawyer：

向监管机构提交文件会产生法律后果——该文件将成为监督记录的一部分，任何重大遗漏或错误都可能带来执法风险。你是否已与律师审阅过此事？如果是，请继续。如果不是，以下是你可以带去咨询的简要材料：

[生成一页摘要：适用制度和监管机构、提交原因（强制触发还是自愿提交）、已识别的风险、采取缓解措施后的剩余风险、任何已标明的不确定性，以及提交前需要向律师询问的三件事。]

如果你需要寻找所在司法管辖区获许可的 attorney、solicitor、barrister 或其他获授权的法律专业人士，最快的起点是你所在地区专业监管机构的转介服务（美国的州律师协会、英格兰和威尔士的 SRA/Bar Standards Board、苏格兰/北爱尔兰/爱尔兰/加拿大/澳大利亚的 Law Society，或你所在司法管辖区的同等机构）。

未经明确答复“是”，不得越过此关卡。

以“下一步决策树”结尾

按照 CLAUDE.md ## Outputs 中的要求，以“下一步决策树”结尾。根据此技能刚刚生成的内容定制选项——五个默认分支（起草 X、升级处理、补充事实、观察等待、其他事项）仅供参考，并非固定选项。决策树就是输出；由律师作出选择。

此技能不做什么

• 它不会批准相关处理。PIA 由人工签署。
• 它不会为监督机关撰写 DPIA——那是更正式的文件，有具体的监管要求。此处进行的是内部评估。
• 它不会设计缓解措施。它会说明哪些方面需要缓解；具体修复方案由工程团队设计。