# Pipl Assessment

> 当用户需要对具体个人信息处理活动开展个人信息保护影响评估（PIPIA）时使用。 覆盖场景：处理敏感个人信息、利用个人信息进行自动化决策、委托处理与向第三方 提供、公开个人信息、向境外提供个人信息前的评估，以及新产品上线、系统改造、 数据合作落地前的合规前置评估。同义场景词：个保影响评估、PIPIA、个人信息 影响评估、隐私影响评估。执行全链路：触发情形识别、处理活动映射、合法性基础 核对、告知同意检查、风险识别与分级、缓释措施与整改建议，输出评估报告模板； 行业与数据规模从执业画像读取，不硬编码实体立场。

- Skill: `minimax-ai/pipl-assessment` (Agent Skill)
- Install (CLI): `npx skillmds@latest add minimax-ai/pipl-assessment`
- Raw SKILL.md: https://api.skillmd.com/api/skills/minimax-ai/pipl-assessment/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/pipl-assessment

---


# 个人信息保护影响评估（PIPIA）

## 目的

把「要不要做评估」和「评估怎么做」变成一条可执行的流水线：先按法定触发
情形确认评估义务，再逐项完成处理活动映射、合法性基础核对、告知同意检查、
风险识别与缓释措施设计，产出一份可留档、可备查的个人信息保护影响评估报告。

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

1. **触发情形法定**：是否必须评估，对照个保法第五十五条列举的情形判断
   [CITE:__]，不由业务方自评「应该不用做」了结；
2. **结论依附角色**：同一处理活动，个人信息处理者（控制者）与受托方的
   评估义务不同，先定角色再评估（docs/scenes/data-compliance-cn.md A6）；
3. **报告必须可留档**：评估报告是法定留档义务的一部分 [CITE:__]，结论、
   依据、整改项都要落到纸面，口头「看过了没问题」不是评估。

本技能遵守 legal-core Shared guardrails（G1–G12）与docs/scenes/data-compliance-cn.md；
冲突时以 legal-core 为准。条文引用纪律：个保法第十三、三十八、五十一、
五十五条为确定性高条号，但对外产物中的正式引用一律先以 [CITE:__] 占位，
经 legal-core `statute-verify` 核验现行文本后填入（G10）。

## 前置检查

1. 已按docs/scenes/data-compliance-cn.md B1/B2 完成：画像检查（B9 关键项无 [填空]）、路由
   确认（用户已认可走 PIPIA 路径）。
2. 数据处理角色已判定（控制者 / 受托方 / 分场景兼有）；角色不明的，先按
   A6 流程确认，不得在角色未定的情况下出结论。
3. 画像中的行业与数据规模已读取；行业有专门数据监管规则（金融、医疗、
   汽车、教育等）的，在评估范围中显式声明是否纳入。
4. 用户角色已识别（律师/法务/合规/业务/其他），决定 G4 标头档位与 G5
   后果门口径。

## 操作规程

### 第 1 步：触发情形识别

对照个保法第五十五条 [CITE:__]，逐项确认本次处理活动是否命中法定评估
情形：

1. 处理**敏感个人信息**；
2. 利用个人信息进行**自动化决策**；
3. **委托处理**个人信息、**向其他个人信息处理者提供**个人信息、
   **公开**个人信息；
4. **向境外提供**个人信息（命中即同时挂起，提示走 `data-export-assessment`）；
5. 其他对个人权益有重大影响的个人信息处理活动。

判定规则：

- 命中任一情形：评估为法定义务，进入第 2 步；
- 均不命中但处理规模大、场景新（如首次上线画像推荐）：建议做自愿评估，
  理由写入报告背景节；
- 用户对「是否敏感个人信息」「是否自动化决策」有争议时，按 G8 从宽认定
  （宁可按命中处理），并在报告中注明认定理由与 [需复核]。

同时全量过一遍docs/scenes/data-compliance-cn.md A8.1 的 blocks 红线（敏感个人信息无单独
同意迹象、未成年人信息处理无监护人同意等）。命中即停止，按 blocks 纪律
处理，不进入评估流程。

### 第 2 步：处理活动映射

把「处理个人信息」拆成可核对的活动清单。每一项记录：

- 数据字段：收集哪些个人信息，是否含敏感个人信息；
- 来源与去向：从谁收集（直接/间接），流向哪些内部系统、哪些外部主体；
- 处理动作：收集、存储、使用、加工、传输、提供、公开、删除各环节是否
  都存在；
- 期限与频次：保存期限、处理频率；
- 系统与人员：承载系统、可访问人员范围、是否有境外访问。

信息来源：用户提供的业务描述、系统文档、数据流图 [用户提供]；缺失的
环节如实写「未提供」，不得凭想象补齐（G2）。

### 第 3 步：合法性基础核对

对每一项处理活动，对照个保法第十三条 [CITE:__] 逐一确认合法性基础：

- 取得同意；
- 订立、履行合同所必需；
- 履行法定职责或法定义务所必需；
- 应对突发公共卫生事件，或紧急情况下保护自然人生命健康和财产安全所必需；
- 公共利益新闻报道等在合理范围内处理；
- 依法公开信息的合理处理；
- 法律、行政法规规定的其他情形。

核对要点：

- **「同意」只是七种基础之一**；逐项说明所选基础及理由，不得全表默认
  勾选「同意」。
- 选「订立、履行合同所必需」的，说明与合同目的的直接关联；关联牵强的
  标 🟡 并建议改用同意路径。
- 敏感个人信息：除基础外，还须确认具有特定目的和充分必要性、采取严格
  保护措施，并取得单独同意（或法定例外）[CITE:__]；涉及不满十四周岁
  未成年人个人信息的，核对监护人同意与专门处理规则 [模型知识—待核实，
  引用前经 statute-verify 核验]。
- 任何一项找不到合法性基础：法律风险轴不低于 🟠，整改建议为「停止该项
  处理或重建合法性基础」。

### 第 4 步：告知同意检查

- 告知要素：处理者名称/联系方式、处理目的与方式、信息种类与保存期限、
  个人权利行使方式与程序等法定要素是否齐全 [CITE:__]；
- 告知形式：是否显著、清晰、易懂；隐私政策与场景化告知是否分层；
- 同意机制：是否自愿、明确作出；有无默认勾选、捆绑授权、不同意即拒绝
  基本服务的情形；
- 特殊情形：敏感个人信息的单独同意、向第三方提供/公开的单独告知
  [CITE:__]；
- 告知不充分属 A8.1 work-but-ships：给出修订建议与完成时限，不阻断评估。

### 第 5 步：风险识别与分级

从四个维度识别对个人权益的影响与安全风险：

1. **合法性风险**：基础缺失、超目的处理、超期保存；
2. **权益影响**：对个人的歧视性影响（自动化决策不公）、人格尊严受损、
   财产受损可能性；
3. **安全风险**：泄露、篡改、丢失的可能性与影响（结合个保法第五十一条
   的安全措施要求 [CITE:__] 核对现有措施）；
4. **第三方风险**：受托方、接收方的安全能力与合同约束是否到位。

每项风险按 G9 双轴标注：法律风险轴（🔴🟠🟡🟢）× 商业摩擦轴
（阻碍/拖慢/费解/无感）。

### 第 6 步：缓释措施与整改建议

对每个 🟠 及以上风险逐项给出缓释措施；🟡 项给优化建议。整改建议必须带：

- 优先级（P0 上线前必须 / P1 限期整改 / P2 持续改进）；
- 建议完成时限；
- 责任方提示（业务/技术/法务，由用户组织内分派，本技能不代为指派到人）。

缓释措施的写法：写清「做什么」，不代拟具体制度文本与隐私政策语言——
需要起草的一律写「建议转法务/律师起草」。

### 第 7 步：输出评估报告

按下方模板输出。报告是留档文件：触发情形、活动清单、基础核对、风险
矩阵、整改项一项不缺；没有信息的栏目如实写「未提供」，不留空白。

### 第 8 步：后果门（按结论分级，对应 G5 与场景 B5）

- 结论含 🔴 或命中 B5 升级触发（重要数据、百万级规模、出境、监管已
  介入、CIIO）：报告首页明示「相关处理活动不建议上线/继续」，按 G5
  生成「带给律师的一页 brief」，非律师用户到此停止。
- 结论 🟢 且处理活动即将上线：非律师用户按 G5 动作闸门——显式确认
  知悉上线的合规后果并获得明确指令，同时生成律师 brief 供快速复核。
- 结论 🟡：按整改建议的优先级推进，P0 项完成前相关业务动作暂缓；
  整改完成后可对整改项重新评估。

### 第 9 步：收尾登记

- 评估报告按 legal-core `matter-workspace` 的版本规则保存到事项目录；
  已发出的版本永不覆盖。
- 报告中所有条文引用过 legal-core 的 `citation-audit`（G10）；未核验的
  保持 [CITE:__] 占位。
- 出境触发项挂起的，提示用户接续 `data-export-assessment`。
- 评估发现画像数据规模、角色信息有缺的，提示经 `customize` 写回画像。

## 输出模板

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

# 个人信息保护影响评估报告：<处理活动/产品名称>

## Reviewer note
- 来源：<业务描述与系统材料 [用户提供]；法条来源标注>
- 已读：<实际读过的材料范围>
- 标记：结论 🔴 不得推进 / 🟡 需整改或需人判断 / 🟢 可推进；
  单项 = 法律风险轴（🔴🟠🟡🟢）× 商业摩擦轴（阻碍/拖慢/费解/无感）
- 时效：<法律状态核查日期；未核验写"未核验">
- 使用前注意：<留档要求；去向限制；非律师用户注明"本报告不是法律意见">

## 一、评估背景与触发情形
- 处理活动概述；数据处理角色（控制者/受托方）；行业与数据规模（来自画像）
- 触发的法定情形：[CITE:__]（逐项列明命中的情形及理由）

## 二、处理活动清单
| # | 数据字段 | 是否敏感 | 来源 | 处理动作 | 流向（内部/外部） | 保存期限 |
| --- | --- | --- | --- | --- | --- | --- |

## 三、合法性基础核对表
| # | 处理活动 | 所选合法性基础 | 理由 | 单独同意/其他要件 | 结论 |
| --- | --- | --- | --- | --- | --- |

## 四、告知同意检查
<要素齐备性、形式、同意机制、特殊情形，逐项结论>

## 五、风险矩阵
| # | 风险描述 | 维度 | 法律风险轴 | 商业摩擦轴 | 现有措施 | 缓释后残余风险 |
| --- | --- | --- | --- | --- | --- | --- |

## 六、整改建议
| # | 对应风险 | 整改建议 | 优先级 | 建议时限 | 责任方提示 |
| --- | --- | --- | --- | --- | --- |

## 七、评估结论
<🟢/🟡/🔴 结论与一句话理由；🟢 须声明法条已核验>

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

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

## 本技能不做什么

- 不代拟隐私政策、告知文本、制度文件——需要起草的一律「建议转法务/律师
  起草」。
- 不在角色未定时下结论：控制者/受托方义务结构不同，角色是前置判断。
- 不凭模型记忆引用门槛与条文：条号、门槛、时限一律 [CITE:__] 占位后
  经 `statute-verify` 核验。
- 不替业务方决定「不做评估」：触发情形存疑时按 G8 从宽认定为命中。
- 不出具「合规证明」：评估报告是内部留档与整改依据，不是对外的合规背书。
- 不处理 🔴 事项的后续（不出绕行方案，生成律师 brief 后停止）。
- 不直接手改画像：现场取得的角色与规模信息经 `customize` 写回。

## 收尾与下一步

1. 报告交付后按第 8 步后果门分流：🔴 停止并升级；🟡 整改后复评；
   🟢 走 G5 显式确认 + 律师 brief。
2. 涉出境触发项 → 接续 `data-export-assessment`；发现隐私政策要素缺口
   → 接续 `privacy-policy-review`；发现既有事件迹象 → 立即转
   `data-incident-response`。
3. 全部引用过 `citation-audit`；需要核验条文原文的经 `statute-verify`
   （核验通过后以 [已确认—日期] 标注填入）。
4. 评估报告纳入个人信息保护合规档案，留档备查 [CITE:__]；评估对象
   发生重大变化（目的、范围、数据种类变化）时提示重新评估。
5. 评估中暴露的画像缺口（角色、规模、行业规则）提示经 `customize`
   补齐——画像越完整，下次评估的盲区越小。