隐私请求分流
用途
把个人信息主体请求（查阅、复制、更正、删除、撤回同意等）整理成内部分流清单：请求类型、建议期限、责任角色、待确认项。
只做分诊底稿，不出具正式法律意见，不直接删改生产数据，不自动向监管提交。
适用场景
- 适合：客服/隐私值班收到主体请求；需要分给法务/安全/业务并标期限。
- 不适合：正式法律意见书；自动执行删库/脱敏；绕过身份核验直接处理。
边界与差异化
- 参考：
policy-plain-digest、customer-reply-draft、access-review-checklist。 - 本技能差异：请求分流与期限/责任，不是制度白话、对客成稿或权限盘点。
- 禁止：写成「已删除/已答复监管」；无身份核验结论时推进高风险处置。
怎么使用(普通用户)
- 「收到用户要求删除账号数据，帮我分流」
- 「隐私请求分诊：类型、期限、责任、待确认」
可选补充：渠道（邮件/工单）、地区、是否已核验身份、内部 SLA。
使用前必问
请求原文或摘要、主体身份是否已核验、涉及系统/数据范围、公司内部对接人（若已知）。
使用步骤
- 归类类型（据用户描述，不确定则待确认）：查阅/复制/更正/删除/撤回同意/其他。
- 标期限：仅写用户给出的内部 SLA 或「按公司政策待确认」；不编造法定天数。
- 责任建议：法务 / 安全 / 业务 / 客服——据线索建议，缺则待确认。
- 待确认：身份核验、数据范围、是否第三方共享等。
- 输出：分流表 + 待确认；不对客自动发送。
输出模板
空表与逐字段填写口径见 references/triage-template.md。
## 隐私主体请求分流清单
| # | 请求类型 | 摘要 | 建议期限 | 建议责任 | 状态 |
|---|----------|------|----------|----------|------|
| 1 | ... | ... | 待确认/按政策 | ... | 待确认 |
### 待确认
1. 身份核验是否完成？
2. ...
### 说明
- 本稿为内部分诊，不构成法律意见；高风险处置须合规负责人确认。
示例
输入：
渠道：邮件
请求原文：「请删除我的账号和全部订单数据，我不想再使用你们的服务了。」
身份核验：尚未核验
其他线索：产品说订单数据财务那边要留存；内部 SLA 未提供
输出：
## 隐私主体请求分流清单
| # | 请求类型 | 摘要 | 建议期限 | 建议责任 | 状态 |
|---|----------|------|----------|----------|------|
| 1 | 删除 | 删除账号数据（注册信息、登录凭据、个人资料） | 待确认（按公司政策） | 安全（执行）+ 业务（确认范围） | 待身份核验 |
| 2 | 删除 | 删除订单数据 | 待确认（按公司政策） | 法务（留存义务判定）+ 财务 + 安全 | 待确认留存范围 |
### 待确认
1. 身份核验是否完成？**未完成前不推进任何删除动作**
2. 订单数据的留存义务范围与依据——产品仅口头提及「财务要留存」，需法务与财务书面确认
3. 账号与订单数据是否已共享至第三方（分析、客服、营销工具），是否需同步处理
4. 内部 SLA 天数（本批未提供；未按任何法定天数填写）
### 说明
- 本稿为内部分诊，不构成法律意见；高风险处置须合规负责人确认。
- 本清单未执行任何删除或脱敏动作。
示例要点：主体一句话提了两类数据，但必须拆成两行——账号数据与订单数据的留存义务、责任方与结论都可能不同，合并会掩盖订单侧的留存冲突。另外「产品说要留存」只是口头线索，不足以作为留存结论，故进待确认而非直接写入建议期限。
常见问题(FAQ)
- 能直接说已删吗？ 不能。
- 要写法律条款解释吗？ 不做正式法律意见；可列「需法务确认的点」。
- 和对客回复有何不同？ 本稿对内分流；对客话术另开回复类技能。
已知限制
- 不连接工单/CRM/数据库。
- 中文交互；不依赖海外 API。
- 不替代 DPO/法务最终判断。
变更说明
- 0.1.2: 示例由一句摘要改为按模板输出的完整可复制 Markdown 块（分流表 + 待确认 + 说明）；落地
references/triage-template.md（含逐字段填写口径与「同一请求需拆行」的三种情形）；示例演示账号数据与订单数据必须拆行的判断，并把口头留存线索归入待确认而非结论。 - 0.1.1: 补充变更说明节,建立版本记录习惯;正文能力与 0.1.0 一致。
- 0.1.0: 首发。把隐私/个人信息主体请求整理成分流清单（类型、期限、责任、待确认）。
