为新产品/功能/数据处理活动生成内部 PIA 时…

当用户要求撰写 PIA、隐私影响评估、判断是否需要 PIA、对功能做隐私审查或描述新的数据处理活动时，按法律团队内部格式生成可签署的内部隐私影响评估。

适用场景

解决思路

1. 加载 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md`，读取 PIA house style（触发条件、结构、深度、签署人）。
2. 运行下述 PIA 生成工作流。
3. 检查是否真的需要 PIA：结合 house trigger，并针对每个适用法域检索强制评估触发条件，引用一手来源并核验时效。
4. 向产品团队做 intake 访谈；如果提供 PRD，可从 PRD 提取信息。
5. 按 house format 撰写 PIA，并包含隐私政策一致性检查。
6. 输出时附条件清单和具名负责人，并进入签署流程。
7. 检查 practice-level `CLAUDE.md` 的 `## Matter workspaces`。若 `Enabled` 为 `✗`（内部用户默认），跳过 matter 相关步骤，使用 practice-level 上下文。若启用且无 active matter，询问：`Which matter is this for? Run /privacy-legal:matter-workspace switch <slug> or say practice-level.` 加载 active matter 的 `matter.md` 获取特定上下文和覆盖项。将输出写入 `~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/`。除非 `Cross-matter context` 为 `on`，绝不读取其他 matter 文件。
8. 目的地检查：生成输出前检查发送目的地。若用户指定了目的地（频道、分发列表、对手方、所有人），询问是否在特权保护圈内。公共频道、全公司列表、对手方/对方律师、供应商、客户（针对工作成果）会放弃保护。目的地看起来在圈外时，标记并提供：(a) 仅供法律部门的特权版本，(b) 给更广频道的脱敏版本，(c) 两者都要；不要默默加特权标头后又帮助粘贴到标头无法保护的地方。参见插件 `CLAUDE.md` 的 `## Shared guardrails → Destination check`。
9. 管辖权假设：该评估仅基于配置中指定的管辖权范围。隐私规则、评估触发条件和合法性基础因司法辖区而异（GDPR vs 州消费者隐私法 vs 行业法）。若处理活动、控制者或受影响数据主体属于不同辖区，分析不能按原文照搬。
10. 写新 PIA 前，检查 outputs 文件夹中同一功能、处理活动或对手方的先前工作。路径见 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## Outputs`。
11. 扫描先前 `use-case-triage` 结果：覆盖该活动的 triage 风险评级、强制条件和明确关注点是 PIA 的切入点。
12. 扫描先前 `pia-generation` 输出：同一或重叠活动的先前 PIA 应被调和（什么变了、什么延续了）。同一活动的 PIA 若悄悄得出不同结论，是审查律师看不到的矛盾。
13. 扫描先前 `dpa-review` 输出：范围内供应商的 DPA 审查发现会影响 PIA 对 subprocessor、跨境和保留风险的分析。
14. 若找到先前输出，在 PIA 中引用：`Prior triage ([date]) rated this [risk level] and required [conditions]. This PIA builds on that finding — [which conditions are satisfied, which remain, which are re-scoped].`
15. 若存在先前 PIA，引用：`This PIA supersedes the [date] PIA because [reason — scope change, new data category, vendor change, regulatory change]. Conclusions carried over: [X]. Conclusions revised: [Y, because Z].`
16. 按 cross-skill severity floor，将上游严重度作为下限：若 `use-case-triage` 评为高风险，PIA 不能无理由改为低风险；必须说明原因和变化。规则见 `CLAUDE.md` → `## Shared guardrails`。
17. 若未找到先前输出，明确说明：`No prior triage or PIA on this activity in outputs folder; this is a cold start`，让审查律师知道已检查且无内容可调和。
18. 加载 house style：阅读 `CLAUDE.md` → `## PIA house style`，获取此团队何时触发 PIA（可能与法规 DPIA 触发条件不同）、从 seed PIA 提取的结构模板、典型深度、签署人。若 seed PIA 结构在配置 `CLAUDE.md` 中，必须使用它，使 PIA 像本团队其他 PIA 而非通用模板。
19. 检查 `CLAUDE.md` 中的触发标准，作为团队 house answer。
20. 针对 regulatory footprint 中每个制度检索当前有效的强制评估触发条件：GDPR/UK GDPR DPIA 触发条件、CCPA/CPRA risk-assessment 触发条件、其他美国州数据保护评估触发条件、行业制度。引用控制性法规、规章或监管指引并给出精确出处。核验时效；评估阈值和定义会变化；不确定时标记而非猜测。
21. 无静默补充：若配置的法律研究工具对某制度的 DPIA/风险评估触发条件或合法性基础规则返回很少或没有结果，报告找到的内容并停止。不要未经询问从 web search 或模型知识填补。说明：`The search returned [N] results from [tool]. Coverage appears thin for [regime / question]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged [web search — verify] and should be checked against a primary source before relying, or (4) flag as unverified and stop. Which would you like?` 由律师决定是否接受较低可信来源。
22. 来源归属：PIA 中每个引用都要标注来源：从法律研究连接器获取的用 `[Westlaw]`、`[regulator site]` 或 MCP 工具名；web search 用 `[web search — verify]`；模型记忆用 `[model knowledge — verify]`；用户提供用 `[user provided]`。带 `verify` 标签的引用伪造风险更高，应优先核对。绝不要移除或合并标签。
23. 除法定强制外，将以下视为强烈指标，值得做 PIA，并检索其是否独立触发适用制度的强制评估：新技术或现有技术的新颖使用；儿童数据；合并原本未一起收集的数据集；可用于歧视的数据；用户不会预期的处理。
24. 若无法定触发且 house trigger 也未满足 → 输出：`Doesn't look like this needs a PIA. Here's a one-paragraph note for the file explaining why, in case anyone asks.` 即写一段存档说明为什么不需要 PIA。
25. 写作前先向产品团队获取答案。可以对话式，不是发表格。
26. 询问/确认 What and why：功能/产品/变更是什么？
27. 询问/确认：它为用户解决什么问题？
28. 询问/确认：涉及哪些个人数据？要具体到字段——`user data` 不是答案。
29. 询问/确认：哪些是新收集，哪些是已有数据？
30. 询问/确认：处理是什么——存储、分析、共享、自动化决策？
31. 对每个适用制度检索当前有效框架并引用一手来源，用于 Legal basis / regime-specific checks：
32. 对要求识别合法性基础的法域（如 GDPR、UK GDPR），为每个目的识别基础（contract / legitimate interest / consent / legal obligation / vital interests / public task / other）。检索具体要求及 balancing-test 或 consent-standard 预期，引用控制性权威。
33. 对规范披露的法域（如 CCPA/CPRA 和其他美国州隐私法），检查任何数据流是否构成当前有效法定定义下的 `sale`、`share` 或其他受监管披露。第三方广告是常见陷阱，需检索其在适用制度下是否落入受监管类别。
34. 对行业制度（HIPAA、GLBA、COPPA、FERPA 等），检索任何制度特定基础或披露规则。
35. 核验时效；法定定义和基础常被修订；标记不确定处供律师核验。
36. 询问 Who and where：公司内部谁可看到这些数据？工程师、支持、分析师？
37. 询问：是否有第三方？供应商、合作伙伴、分析服务？
38. 询问：数据存在哪里？哪个区域？新基础设施还是现有？
39. 询问：保留多久？有无删除计划，还是永久保留？
40. 询问 What could go wrong：如果这些数据泄露，对个人有什么伤害？
41. 询问：这些数据是否可能被用于歧视，哪怕是意外？
42. 询问：用户是否会惊讶正在发生此事？（creepy test——不是法律标准但有用。）
43. 询问：是否有 opt-out？是否应该有？
44. 使用配置 `CLAUDE.md` 中的 seed PIA 结构。若未捕获，使用默认结构。按 `CLAUDE.md` `## Outputs` 添加 work-product header（随用户角色不同）。
45. 默认结构包含：work-product header；`# Privacy Impact Assessment: [Feature/Product Name]`；`Prepared by` / `Date` / `Status: DRAFT / APPROVED`；`Product owner` / `Privacy reviewer`；`## Executive summary` 两句话说明是什么、是否可以，`Overall risk` 由审查者设置 🟢 Low / 🟡 Medium / 🟠 High / 🔴 Very high；`## 1. Description of processing` 含 What、Data categories（具体字段）、Data subjects、Purpose、New collection?；`## 2. Lawful basis` 表格 Purpose / Basis / Notes（LI 写 balancing test 摘要；consent 写如何取得）；`## 3. Data flow` 含 Collection、Storage、Access、Sharing、Retention；`## 4. Privacy policy consistency` 表格 Policy commitment / Consistent? / Notes，如有 🟡 说明发布前需更新政策或调整处理；`## 5. Risks and mitigations` 表格 # / Risk / Likelihood / Impact / Mitigation / Status / Owner，以及 Residual risk after mitigations；`## 6. Data subject rights` 含 Access、Deletion、Correction、Portability、Objection 及能否行使和方式；`## 7. Recommendation` 含 APPROVED / APPROVED WITH CONDITIONS / CHANGES REQUIRED / NOT APPROVED，Conditions 复选列表，Sign-off。
46. 风险质量：风险要具体并绑定设计，不要泛泛而谈。坏风险如 `Data breach` 适用于一切；`Non-compliance with GDPR` 循环论证；`Users might not like it` 太模糊。好风险应具名具体机制/缺口。目标写 2-5 个真实风险，不要 15 个注水项。
47. 隐私政策 diff：每个 PIA 都要对照 `CLAUDE.md` 中的隐私政策承诺。常见漂移：政策说收集 X、Y、Z，新功能收集 W → 更新政策或停止收集 W；政策说不出售数据，新功能与广告伙伴共享 → 可能构成 CCPA sale；政策说保留期至账户活跃，新功能删除后仍保留。标记每个不一致；发布前必须改变其中之一。
48. Handoff 给产品团队：提供带负责人和截止日期的条件清单。不要写 `improve security`，而写 `add audit logging to the admin panel's location lookup, owner: [eng lead], before launch.`
49. Handoff 给 `reg-gap-analysis` skill：若 PIA 发现政策不一致，由该 skill 跟踪政策更新。
50. Handoff 给签署流程：按 `CLAUDE.md` → 谁批准 PIA。
51. Gate：向监管机构提交 DPIA。产出内部 PIA 是研究和文档；向 supervisory authority 提交 DPIA，或应询自愿向监管机构披露，才是关键行为。在提交 DPIA（或等效影响评估）给监管机构、supervisory authority 或执法机构前：阅读 `CLAUDE.md` 的 `## Who's using this`。若 Role 为 Non-lawyer，使用提示：提交给监管机构有法律后果——文件成为监管记录一部分，任何重大遗漏或错误都会成为执法风险。问是否已与律师审查；若是则继续；若否则生成 1 页摘要给律师，包含 regime and regulator、为何提交（强制触发或自愿）、识别的风险、缓解后剩余风险、任何标记的不确定性、提交前要问律师的三个问题。若需找律师，给出专业监管机构转介服务（美国 state bar，英格兰与威尔士 SRA/Bar Standards Board，苏格兰/北爱尔兰/爱尔兰/加拿大/澳大利亚 Law Society，或辖区等效机构）。没有明确 yes 不得越过此 gate。
52. 结尾给 next-steps decision tree：按 `CLAUDE.md` `## Outputs`，定制到本技能刚产出的内容；五个默认分支（draft the X、escalate、get more facts、watch and wait、something else）是起点而非锁定。树就是输出，由律师选择。
53. 明确此技能不做什么：不批准处理，必须由人签署 PIA；不写提交给 supervisory authority 的 DPIA（那是更正式、具特定监管要求的文件），本技能只做内部评估；不设计缓解措施，只描述需要缓解什么，由工程团队设计修复。

适用边界 · 注意事项

• 需要向监管机构正式提交 DPIA 或等效影响评估时，不应把此技能产物直接作为提交稿；提交前必须经过律师审查并走 gate。
• 当处理活动、控制者或数据主体不在配置管辖权范围内时，不应按该配置的规则直接分析。
• 当缺少 claude-for-legal/隐私法律插件配置、house style、seed PIA 或法律研究工具，且无法获取这些输入时，不应依赖该技能；它依赖特定插件/配置与法律研究连接器。