---

name: pia-generation description: > 生成符合内部格式的个人信息保护影响评估（PIA），适用于新功能、产品或处理活动， 使用从种子PIA学习到的结构。当用户说"写一份PIA""个人信息保护影响评估""我们需要 为这个做PIA吗""对这个功能做隐私审查"，或描述一项新的个人信息处理活动时使用。 argument-hint: "[功能名称或描述]"

/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 "位置共享功能"

/privacy-legal:pia-generation
PRD: [网盘链接]

---

个人信息保护影响评估生成

事项上下文

事项上下文。 检查实践级 CLAUDE.md 中的 ## 事项工作区。如果 已启用 为 ✗（法务用户的默认值），跳过本段——技能使用实践级上下文，事项机制不可见。如果已启用且无活动事项，询问："这是哪个事项？运行 /privacy-legal:matter-workspace switch <slug> 或说 实践级。"加载活动事项的 matter.md 获取事项特定上下文和覆盖项。将输出写入事项文件夹 ~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/。除非 跨事项上下文 为 开启，否则绝不读取其他事项的文件。

---

目的地检查

在生成输出前，检查输出目的地。如果用户指定了目的地（渠道、分发列表、对方当事人、"所有人"），询问是否在保密圈内。公共渠道、全公司列表、对方当事人/对方律师、供应商和客户（就工作成果而言）会放弃保护。当目的地疑似在圈外时，标示并提供 (a) 仅供法务的保密版本，(b) 供更广泛渠道的净化版本，或 (c) 两者——不要默默加上保密抬头然后帮助粘贴到该抬头无法保护的地方。参见本插件 CLAUDE.md 中的 ## 共享护栏 → 目的地检查。

目的

PIA 是与产品团队的对话，被记录下来。它问：什么数据，为什么，多久，谁看，什么可能出错。本技能结构化这场对话，并以本团队的格式写出输出——与冷启动访谈从种子 PIA 学习到的格式一致。

法域假设

本评估假定你的配置中指定的法域范围。隐私规则、评估触发条件和合法性基础因法域而异（个保法 vs. GDPR vs. 其他法域）。如果处理活动、处理者或受影响个人信息主体属于不同法域，本分析可能不直接适用。

加载关于本功能/活动的先前上下文

在撰写新 PIA 之前，检查输出文件夹中是否有关于同一功能、处理活动或对方当事人的先前工作。读取 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## 输出 获取路径。扫描：

• 先前的 use-case-triage 结果涵盖本活动——分诊的风险评级、强制条件和标注的关注点是 PIA 的入口。
• 先前的 pia-generation 输出涵盖相同或重叠的活动——新 PIA 应做好衔接（什么变了，什么延续）。一个对着同一活动静默产生不同结论的 PIA 是审核律师无法发现的矛盾。
• 先前的 dpa-review 输出涵盖范围内的供应商——DPA 审查中的发现为 PIA 对下游处理者/跨境/保留风险的分析提供信息。

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

"先前的分诊（[日期]）将本活动评为[风险等级]，并要求[条件]。本 PIA 以此发现为基础——[哪些条件已满足，哪些仍待满足，哪些被重新界定]。"

如果先前存在 PIA：

"本 PIA 取代[日期]的 PIA，因为[原因——范围变化、新数据类别、供应商变更、法规变化]。延续的结论：[X]。修订的结论：[Y，因为Z]。"

从上游继承严重程度作为底线，遵循 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## 共享护栏 中的跨技能严重程度底线规则。被分诊评为高风险的活动，不能在 PIA 中静默变为低风险，除非说明理由和变化了什么。

如果未找到先前的输出，明确说明——"输出文件夹中无关于本活动的先前分诊或 PIA；此为冷启动"——以便审核律师知道检查已经执行过且未发现需要衔接的内容。

加载内部规范

读取 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## PIA 内部规范。其中包含：

• 本团队什么触发 PIA（可能与法定评估触发条件不同——有些团队对所有处理活动做 PIA，有些仅对高风险活动）
• 从种子 PIA 提取的结构模板
• 典型深度
• 审批人

如果配置 CLAUDE.md 中有种子 PIA 结构，使用它。核心在于本 PIA 看起来像该团队产出的其他 PIA，而非像通用模板。

第0步：是否需要 PIA？

检查 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 中的触发标准。这是团队的内部回答。

此外，检索监管覆盖范围中每个适用制度的当前有效法定评估触发条件（个保法第55条四类情形、数据出境安全评估、算法安全评估等）。引用现行有效的法律、行政法规、部门规章或指引，附精准引用。验证时效——评估门槛和定义因新法出台和执法指引而变化。不确定时标示，而非猜测。

禁止静默补充。 如果对配置的法律检索工具的检索查询返回关于某制度的评估触发条件或合法性基础规则的结果很少或为零，报告找到的内容并停止。不要未经询问即从网络搜索或模型知识填补空白。说："搜索从[工具]返回[N]条结果。[制度/问题]的覆盖似乎薄弱。选项：(1) 扩大搜索查询，(2) 尝试不同的检索工具，(3) 搜索网页——结果将标记为 [联网检索 — 需复核]，依赖前应与主源核对，(4) 标记为未验证并停止。你想选哪个？"由律师决定是否接受可信度较低的来源。

来源溯源标签。 为 PIA 中每处引用标记来源标签：[法条原文] 表示直接引用法规条文，[yuandian检索] 表示通过 yuandian MCP 获取，[联网检索 — 需复核] 表示网页搜索获取，[模型知识 — 需验证] 表示来自训练数据，[用户提供] 表示由用户提供。标记为"需验证"的引用造假风险最高，应优先核对。绝不剥离或折叠标签。

超出法律规定，将以下作为强指标——即便不严格法定强制也值得做 PIA（研究在适用制度下是否独立触发法定评估）：

• 新技术应用或对现有技术的创新性使用
• 未成年人数据
• 合并原本分开收集的数据集
• 可能导致歧视的数据
• 个人信息主体不会预期的处理活动

如果无法定触发条件且内部触发也未满足 → "看起来不需要做 PIA。这是说明理由的一小段备忘录，以防有人问起。"

录入

在撰写任何内容前，从产品团队获取以下问题的答案。对话式即可——这不是发送给他们的表格。

什么和为什么

• 功能/产品/变更是什么？
• 它为用户解决什么问题？
• 涉及哪些个人信息？具体——"用户数据"不是答案。哪些字段？
• 是否有新的采集内容，还是全部为已有数据？
• 处理是什么——存储、分析、共享、自动化决策？

合法性基础 / 制度特定检查

对每个适用制度，检索该问题下的当前有效框架并引用主源：

• 个保法第13条合法性基础 [法条原文]：识别每个处理目的的合法性基础（告知同意 / 订立或履行合同所必需 / 履行法定义务所必需 / 应对突发公共卫生事件或保护自然人生命健康和财产安全所必需 / 为公共利益实施新闻报道、舆论监督等行为在合理范围内处理 / 在合理范围内处理已公开的个人信息 / 法律、行政法规规定的其他情形）。研究告知同意应满足"自愿、明确、知情"（个保法第14条 [法条原文]）的具体要求。
• 敏感个人信息：如涉及，检查是否满足个保法第28-30条要求（单独同意 + 特定目的 + 充分必要性 + 告知影响）[法条原文]。
• 数据出境：如涉及，检查是否需通过安全评估（《数据出境安全评估办法》）、签署标准合同（《个人信息出境标准合同办法》）或认证（个保法第38条 [法条原文]）。
• 行业监管：金融（个人金融信息保护技术规范）、医疗（人口健康信息管理办法）、儿童（儿童个人信息网络保护规定）等领域是否有特殊要求。

验证时效；法定定义和依据经常通过行政法规和部门规章修订。不确定时标示，供律师核实。

谁和哪里

• 公司内部谁可以访问这些数据？工程师？客服？分析师？
• 是否有第三方？供应商、合作伙伴、数据分析方？
• 数据存储在哪里？哪个区域？新基础设施还是已有基础设施？
• 保留多久？是否有删除时间表，还是永久保留？

什么可能出错

• 如果这些数据泄露，对个人的伤害是什么？
• 这些数据能否被用于歧视，即便是意外的？
• 用户会惊讶这是正在发生的吗？（"诡异测试"——非法定标准，但有用。）
• 是否有退出选项？是否应该有？

撰写 PIA

使用配置 CLAUDE.md 中的种子 PIA 结构。 如果未捕获，使用以下默认结构。冠以 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md ## 输出 中的工作成果抬头（因用户角色不同而异——见 ## 谁在使用）。

[工作成果抬头 — 按插件配置 ## 输出]

# 个人信息保护影响评估：[功能/产品名称]

**编制人：** [姓名] | **日期：** [日期] | **状态：** 草案 / 已批准
**产品负责人：** [姓名] | **隐私审核人：** [姓名]

---

## 摘要

[两句话：这是什么，是否合规。例如："功能X收集位置数据以提供Y服务。处理活动与现行个人信息处理规则承诺一致，以告知同意为合法性基础。以下建议两项缓解措施；未识别到阻碍事项。"]

**整体风险：** [审核人设定：🟢 低 / 🟡 中 / 🟠 高 / 🔴 极高]

---

## 1. 处理活动描述

**是什么：** [功能，通俗描述]
**数据类别：** [具体字段——不是"用户数据"]
**个人信息主体：** [客户 / 最终用户 / 员工 / 等]
**目的：** [为什么——与用户利益关联]
**新收集？** [是——以下字段为新增 / 否——复用已有数据]

---

## 2. 合法性基础（个保法第13条）

| 目的 | 合法性基础 | 备注 |
|---|---|---|
| [目的1] | [告知同意 / 合同必需 / 法定义务 / 等] | [如为同意：如何获取；如涉及敏感个人信息：是否已获单独同意（个保法第29条）] |

---

## 3. 数据流转

**收集：** [数据如何/从哪里进入]
**存储：** [系统、区域、加密]
**访问：** [谁，通过何种控制措施]
**共享：** [第三方，目的，受哪份数据处理协议约束]
**保留：** [保留多久，删除机制——个保法第19条：最短必要期限 `[法条原文]`]

---

## 4. 个人信息处理规则一致性

| 处理规则承诺 | 一致？ | 备注 |
|---|---|---|
| [来自配置 CLAUDE.md 处理规则部分的承诺] | 🟢 / 🟡 | |

[如有任何 🟡：上线前需更新处理规则，或需变更处理活动]

---

## 5. 风险与缓解措施

| # | 风险 | 可能性 | 影响 | 缓解措施 | 状态 | 负责人 |
|---|---|---|---|---|---|---|
| 1 | [与设计关联的具体风险——并非泛泛的"数据泄露"] | 低/中/高 | 低/中/高 | [具体控制措施] | 已完成 / 计划中 / 缺口 | [姓名] |

**缓解后剩余风险：** [评估]

---

## 6. 个人信息主体权利（个保法第44-50条）

| 权利 | 可行使？ | 如何行使 |
|---|---|---|
| 知情权（第44条） | | |
| 查阅权（第45条） | | |
| 复制权（第45条） | | |
| 更正权（第46条） | | |
| 删除权（第47条） | | |
| 可携带权（第45条） | | |
| 解释说明权（第48条） | | |

---

## 7. 建议

[批准 / 附条件批准 / 需变更 / 不批准]

**条件（如有）：**
- [ ] [上线前必须完成的具体事项]

**审批：** [姓名，日期]

风险质量标准

PIA 中的风险应具体且与设计关联，而非泛泛。差的风险陈述会填充文件并训练读者跳读。

差的风险	为什么差	更好
"数据泄露"	适用于所有情况；什么都没说	"支持人员可通过后台面板访问位置历史记录，且无审计日志——恶意内部人员可追踪用户而不被发现"
"不遵守个保法"	循环论证——PIA 正是为了评估合规性	指出具体条文和缺口
"用户可能不喜欢"	模糊	"已选择退出的用户仍可能接收此推送，因为该流程中未检查退出标记"

目标 2-5 个真实风险，而非 15 个填充风险。

个人信息处理规则差异对比

每份 PIA 都应交叉检查 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 中的个人信息处理规则承诺。常见漂移：

• 处理规则说"我们收集 X、Y、Z"——新功能收集 W。需更新处理规则，或停止收集 W。
• 处理规则说"我们不会向第三方提供数据"——新功能与广告合作伙伴共享。可能构成个保法第23条下的对外提供。
• 处理规则说保留期限为"账户存续期间"——新功能在账户删除后仍保留数据。

标示每个不匹配。上线前二者之一必须改变。

交接

• 至产品团队： 带负责人和截止日期的条件清单。不是"改进安全"——而是"为后台面板的位置查询添加审计日志，负责人：[工程负责人]，截止：上线前。"
• 至 reg-gap-analysis 技能： 如果 PIA 发现了处理规则不一致，该技能追踪处理规则更新。
• 至审批流程： 按 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → 谁批准 PIA。

关口：向监管机构提交评估

制作内部 PIA 是研究和记录。将 PIA 提交给监管部门——或应行政调查请求自愿披露——是具有法律后果的行为。

在将任何影响评估提交给网信办或其他履行个人信息保护职责的部门之前： 读取 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 中的 ## 谁在使用。如果角色为非律师：

向监管部门提交文件具有法律后果——文件成为行政监管记录的一部分，任何实质遗漏或错误均构成执法风险敞口。你是否已请律师审查过？如已审查，继续。如未审查，以下是你带给律师的简要材料：

[生成1页摘要：适用制度和监管部门，为何提交（法定触发或自愿），已识别的风险，缓解后剩余风险，任何标注的不确定性，以及提交前应询问律师的三件事。]

如果你需要寻找执业律师或其他经授权的法律专业人士：通过你所在地区的律师协会或司法局的律师查询系统是最快的起点。许多地方律师协会提供免费或低成本的初步咨询。

未经明确同意，不得越过此关口。

以下一步决策树结束

以符合 CLAUDE.md ## 输出 的下一步决策树结束。根据本技能刚刚产出的内容定制选项——五个默认分支（起草X、升级、获取更多事实、观察和等待、其他）是起点，而非锁定。决策树即输出；律师选择。

本技能不做的事

• 不批准处理活动。由人签署 PIA。
• 不撰写向监管部门提交的 DPIA——那是具有特定监管要求的更正式文件。这是内部评估。
• 不设计缓解措施。它描述什么需要缓解；由工程团队设计修复方案。