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` 补齐——画像越完整，下次评估的盲区越小。