# Privacy Policy Review

> 当用户需要审查、修订或上架前核对隐私政策、个人信息保护政策、App 隐私条款 时使用。覆盖场景：隐私政策起草后自检、监管通报或检测问题后的整改复核、 版本更新合规审查、App 上架前隐私合规检查、第三方 SDK 清单与权限调用对应 核查。同义场景词：隐私政策审查、隐私条款审查、隐私声明、privacy policy review。执行全链路：八大检查类别逐项过堂、🟢🟡🔴 三色分桶、输出带 reviewer note 的审查 memo，问题项附整改建议与优先级；需要重写的条款不代拟，一律 建议转法务或律师起草。

- Skill: `minimax-ai/privacy-policy-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add minimax-ai/privacy-policy-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/minimax-ai/privacy-policy-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: MiniMax AI (https://skillmd.com/u/minimax-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/minimax-ai/privacy-policy-review

---


# 隐私政策审查

## 目的

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

## 输出模板

```markdown
【保密标头：按 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` 补齐——画像越完整，一致性核对的可信度越高。