隐私请求分流

要解决什么问题

客服或隐私值班收到个人信息主体请求（查阅、复制、更正、删除、撤回同意等）时，难点往往不是「能不能办」，而是先搞清楚类型、谁跟进、多久要闭环、还有哪些事实没核实。若把账号数据与订单数据混在一行，或把口头「产品说要留存」直接写成结论，内部分派很容易踩坑。

本技能只做对内分诊底稿：整理成分流清单，不出具正式法律意见，不直接删改生产数据，也不自动向监管提交。

技能如何工作

使用前应先确认：请求原文或摘要、身份是否已核验、涉及系统/数据范围、内部对接人（若已知）。随后按步骤输出：

1. 归类类型：查阅 / 复制 / 更正 / 删除 / 撤回同意 / 其他；不确定则标待确认。
2. 标期限：仅写你提供的内部 SLA，或写「按公司政策待确认」；不编造法定天数。
3. 责任建议：法务、安全、业务、客服等——据线索建议，缺则待确认。
4. 待确认项：身份核验、数据范围、第三方共享等。
5. 输出：分流表 + 待确认列表；不对客自动发送。

同一主体在一句话里提到多类数据时，应按 references/triage-template.md 口径拆成多行（例如账号数据与订单数据的留存义务、责任方可能不同）。口头线索归入待确认，而非直接写入建议期限。

边界与注意点

• 适合：收到主体请求后，需要分给法务/安全/业务并标期限的内部分流。
• 不适合：正式法律意见书、自动执行删库/脱敏、绕过身份核验推进高风险处置。
• 禁止表述：写成「已删除/已答复监管」；无身份核验结论时不应推进高风险处置。
• 与 policy-plain-digest、customer-reply-draft、access-review-checklist 等技能不同，本技能聚焦请求分流与期限/责任，不是制度白话、对客成稿或权限盘点。
• 不连接工单/CRM/数据库；不替代 DPO/法务最终判断。