privacy-policy-review

name	privacy-policy-review
description	当用户需要审查、修订或上架前核对隐私政策、个人信息保护政策、App 隐私条款 时使用。覆盖场景：隐私政策起草后自检、监管通报或检测问题后的整改复核、 版本更新合规审查、App 上架前隐私合规检查、第三方 SDK 清单与权限调用对应 核查。同义场景词：隐私政策审查、隐私条款审查、隐私声明、privacy policy review。执行全链路：八大检查类别逐项过堂、🟢🟡🔴 三色分桶、输出带 reviewer note 的审查 memo，问题项附整改建议与优先级；需要重写的条款不代拟，一律 建议转法务或律师起草。
user-invocable	false
metadata	{"legal_frame":"cn-mainland","legal_sources":[{"name":"中华人民共和国个人信息保护法","effective_date":"2021-11-01"}],"last_reviewed":"2026-08-18"}

隐私政策审查

目的

把一份隐私政策从「读一遍」变成「按法定要素逐项过堂」：用八大检查类别 核对文本，把结果分成 🟢🟡🔴 三桶，产出一份可直接行动（改、补、发、停） 的审查 memo。

本技能的核心纪律有三条：

1. 文本与实际要对照：隐私政策写得好不代表做得好——审查中发现的 「文本声称」与「用户描述的实际处理」不一致，比文本缺陷更危险，单独 列项提示；
2. 要素法定：告知要素对照法定要求逐项核对 [CITE:__]，缺项就是缺项， 不用「行业惯例如此」搪塞；
3. 只审不拟：指出问题、给修改方向，不代拟政策条款语言——需要起草 的一律「建议转法务/律师起草」。

本技能遵守 legal-core Shared guardrails（G1–G12）与docs/scenes/data-compliance-cn.md； 冲突时以 legal-core 为准。

前置检查

1. 已按docs/scenes/data-compliance-cn.md B1/B2 完成：画像检查（B9 关键项无 [填空]）、路由 确认（用户已认可走隐私政策审查路径）。
2. 文本完整可读；只有部分章节或截图的，在 reviewer note 的「已读」行 如实写明范围。
3. 已询问或从上下文判断：文本对应的实际处理活动范围（哪些产品、哪些 场景）；用户答不出的，文本审查照做，但「文本与实际一致性」整节标 「未核对」。
4. 用户角色已识别，决定 G4 标头档位与 G5 后果门口径。

操作规程

第 1 步：Matter context 与去向检查

• 查 matters/_log.yaml 是否已有相关事项；有的挂到该事项目录下。
• 询问产物去向：仅内部整改用，还是要随版本更新对外发布？对外发布版本 走 Quiet mode（docs/scenes/data-compliance-cn.md A2）——发布文本本身不含任何内部标记； memo 与发布文本分开保存。

第 2 步：八类检查清单

逐类对照检查。不设硬编码合格线：凡涉「是否清晰」「是否充分」的判断， 结合法定要求与文本实际表述给出，依据带来源标注。

1. 处理目的明确性：每类信息的处理目的是否具体、明确、与业务功能 直接相关；有无「等」「包括但不限于」式的无限扩张表述；目的变更的 告知与重新同意机制 [CITE:__]。
2. 收集清单与权限对应：收集的个人信息种类是否逐项列举；App 权限 （定位、通讯录、相册、麦克风等）与业务功能的对应关系是否说明； 有无超出功能需要的收集迹象（对照用户描述的实际功能）。
3. 敏感个人信息单独告知：是否列出敏感个人信息种类、处理目的与 必要性、对个人权益的影响；是否说明单独同意机制 [CITE:__]；涉及 不满十四周岁未成年人的，是否有专门规则与监护人同意安排 [模型知识—待核实，引用前经 statute-verify 核验]。
4. 共享、转让、公开披露清单：向第三方提供的场景、接收方类型、 信息种类是否列举；嵌入的第三方 SDK 是否清单化（名称、目的、收集 信息种类）；委托处理与对外提供是否区分表述 [CITE:__]。
5. 用户权利响应机制：查阅、复制、更正、补充、删除、撤回同意、 注销账户等权利的行使方式与程序是否写明；响应时限与渠道是否明确 [CITE:]；自动化决策场景下是否有拒绝仅依自动化决策作出决定的 安排 [CITE:]。
6. 未成年人保护：是否有未成年人个人信息保护专章或专门条款； 年龄识别与监护人同意机制是否说明。
7. 保存期限：各类信息的保存期限或期限确定方法是否写明；超期 删除或匿名化的承诺是否明确 [CITE:__]。
8. 跨境章节：涉个人信息出境的，是否说明境外接收方、目的、信息 种类、个人权利行使方式；与出境合规路径（安全评估/SCC/认证）的 衔接是否一致 [CITE:__]——发现出境安排的，提示另行走 data-export-assessment。

同时全量过一遍docs/scenes/data-compliance-cn.md A8.1 的 blocks 红线（如文本显示处理 敏感个人信息但通篇无单独同意迹象）。命中即停止，按 blocks 纪律处理。

第 3 步：文本与实际一致性核对

• 把用户描述的实际处理活动（第 3 项前置检查取得）与文本逐项对照： 实际在收但文本没写的、文本写了但实际不收的、SDK 清单与实际接入 不一致的，单独列「一致性」标记项，法律风险轴不低于 🟠。
• 用户无法提供实际处理信息的，本节整节标「未核对」，并在 memo 首部 提示：仅文本合规不等于实践合规。

第 4 步：三色分桶 🟢🟡🔴

• 🟢 可发布：八类检查项均符合要求，一致性核对无 🟠 及以上项。 🟢 只能基于经 statute-verify 核验为现行有效的法定要素清单给出； 未核验时最高 🟡，理由写明「法条时效未核验」（场景 B3）。
• 🟡 需修订：要素缺失、表述含混、机制不完整，但可经修订补救 （A8.1 work-but-ships）；逐项给修改方向与时限。
• 🔴 不得发布：命中 blocks 红线；或文本与实际系统性背离（写了 不收的在大规模收集），继续发布将构成虚假告知。
• 每个标记项按 G9 双轴标注：法律风险轴（🔴🟠🟡🟢）× 商业摩擦轴 （阻碍/拖慢/费解/无感）。「费解」轴在本文书场景尤其常用：用户 读不懂的告知，合规价值打折。

第 5 步：输出审查 memo

按下方模板输出。执行摘要里只放机械性一行修改（如「第 X 节补充 保存期限一项」）；凡是需要起草新语言的（重写敏感个人信息章节、补 SDK 清单表），建议栏只写「建议转法务/律师起草」，不在 memo 里 代拟条款。

第 6 步：后果门（对应 G5）

• 结论含 🔴：memo 首页明示「本版本不对外发布、不随版本更新上架」， 按 G5 生成「带给律师的一页 brief」，非律师用户到此停止。
• 结论 🟢 且即将对外发布：非律师用户走 G5 动作闸门——显式确认知悉 发布的合规后果并获得明确指令，同时生成律师 brief 供快速复核。
• 结论 🟡：逐项给修改方向；改完可重新过一遍本技能。

第 7 步：收尾登记

• memo 与所审文本版本按 matter-workspace 版本规则保存；已对外发布 的历史版本永不覆盖、永不删除（监管核查常要求提供历史版本）。
• 所有条文引用过 citation-audit（G10）；未核验的保持 [CITE:__] 占位。
• 发现实际处理活动与画像数据规模信息不符的，提示经 customize 写回 画像。

输出模板

【保密标头：按 G4 二选一】

# 隐私政策审查 memo：<政策名称与版本>

## Reviewer note
- 来源：<政策文本 [用户提供]；实际处理活动描述 [用户提供]；法条来源标注>
- 已读：<全文 / 指定范围>
- 标记：结论 🔴 不得发布 / 🟡 需修订 / 🟢 可发布；
  单项 = 法律风险轴（🔴🟠🟡🟢）× 商业摩擦轴（阻碍/拖慢/费解/无感）
- 时效：<法律状态核查日期；未核验写"未核验">
- 使用前注意：<去向限制；非律师用户注明"本 memo 不是法律意见"；
  注明"仅文本合规不等于实践合规">

## 执行摘要
<三句话以内：总体结论、最关键的一件事、一致性核对结果>
<机械性一行修改清单；需要起草的只写"建议转法务/律师起草">

## 八类检查结果
| # | 检查类别 | 结论（🟢/🟡/🔴） | 主要问题 | 依据 |
| --- | --- | --- | --- | --- |
| 1 | 处理目的明确性 | | | [CITE:__] |
| 2 | 收集清单与权限对应 | | | |
| 3 | 敏感个人信息单独告知 | | | [CITE:__] |
| 4 | 共享、转让、公开披露清单 | | | [CITE:__] |
| 5 | 用户权利响应机制 | | | [CITE:__] |
| 6 | 未成年人保护 | | | |
| 7 | 保存期限 | | | [CITE:__] |
| 8 | 跨境章节 | | | [CITE:__] |

## 标记项
| # | 位置 | 问题 | 法律风险轴 | 商业摩擦轴 | 建议改法 | 依据 |
| --- | --- | --- | --- | --- | --- | --- |

## 文本与实际一致性
<逐项对照结果，或"未核对"声明>

## FYI
<偏离最佳实践但合法的记录（A8.1 FYI）>

## [需复核] 清单
<全文内联 [需复核] 项汇总（G8）>

## 下一步
<按第 6 步后果门展开>

本技能不做什么

• 不代拟隐私政策条款或修改稿语言——需要起草的一律「建议转法务/律师 起草」。
• 不做技术检测：权限实际调用、SDK 实际收集行为需要技术检测手段，本 技能只核对文本与用户提供的信息，并如实声明此边界。
• 不凭默认值给 🟢：法定要素清单未经 statute-verify 核验时，结论天花板 是 🟡。
• 不把「行业惯例」当依据：惯例只能进 FYI 区，不能冲抵法定要素缺项。
• 不对文本与实际不一致装没看见：用户提供的信息足以显示背离的，单独 列项，法律风险轴不低于 🟠。
• 不处理 🔴 事项的后续（不出粉饰方案，生成律师 brief 后停止）。
• 不直接手改画像：现场取得的信息经 customize 写回。

收尾与下一步

1. memo 交付后按第 6 步后果门分流：🔴 停止发布并升级；🟡 修订后复审； 🟢 走 G5 显式确认 + 律师 brief。
2. 发现出境安排 → 接续 data-export-assessment；发现触发个保影响评估 的情形 → 接续 pipl-assessment。
3. 全部引用过 citation-audit；发布版本纳入合规档案，历史版本留档。
4. 隐私政策所对应的处理活动发生重大变化（新功能、新 SDK、新出境安排） 时，提示重新审查。
5. 审查中发现画像缺口（产品范围、SDK 接入情况、数据规模），提示经 customize 补齐——画像越完整，一致性核对的可信度越高。