use-case-triage

/use-case-triage

1. 阅读 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md。确认已配置隐私实践；如果没有，停止并引导用户完成设置。
2. 运行以下工作流。如果活动描述含糊，请先澄清。
3. 检查 House 触发条件 → 必须进行 DPIA 检查（如果适用范围包含 GDPR）→ 检查是否与隐私政策冲突。
4. 输出：分类（PROCEED / PIA REQUIRED / DPIA MANDATORY / STOP）、理由、必要时提供条件表，以及跨插件交接事项。
5. 如果需要评估，询问是否继续生成 PIA。

/privacy-legal:use-case-triage "New feature that uses behavioral data to personalize content recommendations"

---

隐私用例分流

事项背景

事项背景。 检查实践级 CLAUDE.md 中的 ## Matter workspaces。如果 Enabled 为 ✗（内部法务用户的默认值），请跳过本段其余内容——技能使用实践级背景，事项机制不可见。如果已启用且没有活动事项，请询问：“这是针对哪个事项的？运行 /privacy-legal:matter-workspace switch <slug>，或回复 practice-level。”加载活动事项的 matter.md，以获取事项专属背景和覆盖项。将输出写入事项文件夹 ~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/。除非 Cross-matter context 为 on，否则切勿读取其他事项的文件。

---

目标位置检查

生成输出前，先检查其目标位置。如果用户指定了目标位置（频道、分发列表、交易对手、“所有人”），请询问该目标是否属于特权保护范围。公开频道、全公司列表、交易对手／对方律师、供应商，以及客户（对于工作成果）都会导致保护失效。如果目标看起来不在保护范围内，请指出这一点，并提供选项：（a）仅供法务使用的特权版本；（b）适用于更广泛频道的脱敏版本；或（c）两者都提供——不要默默加上特权标头，然后又帮忙将其粘贴到标头无法提供保护的地方。请参阅此插件 CLAUDE.md 中的规范章节 ## Shared guardrails → Destination check。

目的

回答任何人在运行 PIA 前都会提出的问题：“这件事到底需不需要 PIA？”如果需要，需要哪种，以及有哪些阻碍？

隐私分流比 PIA 生成更快，但处于其上游。它不会编写评估，而是确定是否需要评估，以及评估应满足哪些条件。PIA 生成技能负责深入分析。

输出分为以下四种分类：

• PROCEED — 无需 PIA。采用标准保障措施。
• PIA REQUIRED — 部署前或部署过程中需要进行评估。
• DPIA MANDATORY — 法规要求进行数据保护影响评估（需研究适用法规的触发条件，并引用一手来源）。要求更严格，可能需要 DPO／GC 参与。
• STOP — 所述处理活动与隐私政策冲突，或没有合法依据。继续之前需要重新设计。

管辖区假设

此分流依据配置中指定的管辖范围。隐私规则、评估触发条件和合法依据会因管辖区而有实质差异（GDPR 与州级消费者隐私法及行业法规之间存在差异）。如果处理活动、控制者或受影响的数据主体属于其他管辖区，则此分类可能不适用。

先阅读配置

进行分流前，务必先阅读 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md。其中的 PIA 触发标准、监管范围和隐私政策承诺具有权威性。一般性的隐私法律分析不能替代公司实际作出的承诺。

如果文件缺失或包含 [PLACEHOLDER]，请显示以下提示：

我注意到你还没有配置执业资料——只有这样，我才能根据你的执业情况调整 PIA 触发标准、监管范围和隐私政策承诺。

两种选择：

• 运行 /privacy-legal:cold-start-interview（2 分钟）来配置你的资料，然后我会根据你的执业情况进行分流。
• 回复 “provisional”，我会根据通用默认值进行分流——美国司法管辖区、中等风险偏好、律师角色、无操作手册——并为每项输出标注 [PROVISIONAL — configure your profile for tailored output]，让你在作出决定前了解我的处理方式。

临时模式

如果用户回复“provisional”，请使用以下通用默认值正常进行分流：中等风险偏好、律师角色、美国司法管辖区（CCPA + 常见联邦行业基线）、无操作手册（依据一般隐私法律原则进行分类，而非对照已配置的承诺）。在审核者备注和每个发现项区块中标注 [PROVISIONAL]。在输出末尾附上：

“这是基于默认假设进行的通用分析。运行 /privacy-legal:cold-start-interview，即可获得根据你的执业情况校准的输出——包括你的监管范围、隐私政策承诺和风险偏好。只需 2 分钟。”

---

分流流程

步骤 1：了解活动

如果描述含糊不清，请先提问，再进行分类。具体了解以下事项：

• 正在收集或处理哪些数据？属于哪些类别？
• 数据主体是谁——客户、员工还是第三方？
• 目的是什么？要解决什么问题？
• 这是在收集新数据，还是将已有数据用于其他用途？
• 是否涉及第三方供应商？是新供应商还是现有供应商？
• 是否涉及任何自动化决策——输出会影响任何人吗？
• 部署场景是什么——仅限内部使用、面向客户还是面向公众？

仅凭“新功能”和“数据处理活动”不足以准确进行分流。

---

步骤 2：检查内部触发条件

阅读 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## PIA house style → Trigger criteria，并据此执行。

如果满足内部触发条件 → 至少为 必须进行 PIA。

如果不满足内部触发条件，在判定为 PROCEED 之前，请继续执行步骤 3。有些活动无论内部政策如何规定，都需要进行 PIA。

---

第 3 步：强制评估检查

在研究特定制度的触发条件前，先询问基于处理活动的联邦覆盖规则问题。 如果处理涉及受联邦监管的数据类别，通常应以联邦覆盖规则作为主导框架，而非州隐私法；分诊流程应尽早发现这一点，而不是事后才考虑。

基于处理活动的联邦覆盖规则——先询问：

此处理是否涉及：

• 消费者的金融账户数据或「非公开个人信息」（GLBA / Reg P——适用于金融机构及其非关联第三方；对为营销目的共享 NPI 施加实质性限制，这些限制独立于且叠加于任何州隐私法豁免）？
• 由受 HIPAA 规管的实体或业务伙伴持有的受保护健康信息（HIPAA 隐私规则 / 安全规则——对使用和披露施加实质性限制；涉及 500 条或以上记录时须通知泄露；任何供应商均须签署 BAA）？
• 由学校或代表学校行事的服务提供商持有的教育记录（FERPA——对披露设有同意要求，并对目录信息作出例外规定）？
• 由面向儿童的在线服务运营者收集，或运营者实际知情收集的 13 岁以下儿童数据（COPPA——须取得家长同意；提供通知和删除权；对保留和共享设有严格限制）？
• 其他联邦行业专项制度（例如，针对视频观看记录的 VPPA、针对运营商数据的 CPNI、针对机动车管理局记录的 DPPA、针对短信 / 电话同意的 TCPA）？

如果任一项的答案为是：联邦覆盖规则通常规定的是主导性的实质限制，而不只是对州消费者隐私法的豁免。继续前先研究并引用具体条款。某项活动因受 GLBA 规管而依据 § 1798.145(e)「豁免」于 CCPA，仍须遵守 GLBA 的限制（例如，关于共享 NPI 的 § 6802(a)-(c)）——CCPA 豁免并不意味着该活动合法；它只是将适用框架转为 GLBA。

对于 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## Regulatory footprint 中的每项制度，研究当前生效的强制性隐私 / 数据保护评估触发条件。引用具有约束力的法规、规章或监管机构指南，并注明具体条款。注明生效日期——国家和州监管机构会定期发布和更新触发条件清单；不要依赖静态核对表。如有不确定之处，应标记并交由律师核实，而不是猜测。

如果任何适用制度的强制触发条件成立 → 必须进行 DPIA（或相应制度规定的强制评估），无论内部触发条件如何。

强烈迹象（未必属于强制情形，但无论如何都应进行评估）：

• 使用新技术，或以新颖方式使用现有技术
• 儿童数据
• 合并未同时收集的数据集
• 可能促成歧视的数据
• 用户不会预期的数据处理
• 相似受众、跨情境行为广告或其他基于追踪的广告技术活动（面向消费者的公司经常会遇到此类问题；这类活动通常能可靠地揭示政策承诺冲突和联邦行业专项覆盖规则）

存在一个或多个强烈迹象，但未发现经研究确认的强制触发条件 → 升级为必须进行 PIA （并非必须进行 DPIA，但须在输出中标明）。

---

步骤 4：隐私政策冲突检查

阅读 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## Privacy policy commitments。逐项检查拟议活动是否符合其中的每项承诺。

需要留意的常见冲突：

• 政策称“我们收集 X、Y、Z”——而此活动收集 W。上线前需要更新政策，或停止收集 W。
• 政策称“我们不会向第三方出售或共享数据”——而此活动会将数据传给供应商，供其自行使用。请调查此数据流在各适用法律体系下是否属于受监管的“出售”“共享”或其他披露类别。
• 政策规定了保留期限——而此活动保留数据的时间更长。
• 政策称“我们仅将数据用于 [目的]”——而此活动未经新的同意或合法利益评估，就将数据用于新目的。
• 政策说明提供哪些用户权利——而此活动创建了新的数据类别，现有权利处理流程尚未涵盖。

如果存在直接冲突 → 停止。不能只是“谨慎推进”——必须先解决政策冲突（更新政策或重新设计活动），才能继续。

---

步骤 5：分类与输出

---

结论

[需要 PIA / 必须进行 DPIA / 可以推进——用一句话说明原因]

---

活动：[说明你所理解的数据处理活动]

分类：[可以推进 / 需要 PIA / 必须进行 DPIA / 停止]

是否满足内部触发条件？[是 / 否] 是否触发 GDPR 强制 DPIA 要求？[是 — [触发条件] / 否 / 不适用（不涉及 GDPR）] 是否存在隐私政策冲突？[无 / 有 — [具体冲突]]

理由： [1-3 句话。若为可以推进：说明为何符合现行政策且安全。若需要 PIA/DPIA：说明产生该义务的原因。若为停止：指出存在冲突的具体政策承诺或原则。]

---

如果需要 PIA 或必须进行 DPIA——推进前的条件：

要求	负责人	已完成？
[例如，隐私影响评估——完整 DPIA 格式]	[隐私法律顾问]	☐
[例如，合法利益评估（若以合法利益为依据）]	[隐私法律顾问]	☐
[例如，咨询 DPO（强制 DPIA 流程）]	[DPO]	☐
[例如，已签订供应商 DPA]	[隐私 / 法务]	☐
[例如，上线前更新隐私政策]	[隐私法律顾问]	☐
[例如，已构建并测试同意机制]	[产品]	☐
[例如，数据主体权利处理流程已涵盖新的数据类别]	[隐私 / 产品]	☐

合法依据（若涉及 GDPR）：[同意 / 合同 / 合法利益 / 法律义务——或“尚不明确——需在 PIA 中确定”]

下一步——询问是否继续：

给出“需要 PIA”或“必须进行 DPIA”的结果后，务必以以下内容结束：

“要我现在开始 PIA 吗？我可以进行收集问题并生成评估文档，无需你另外运行命令。”

如果对方同意，加载 pia-generation 技能并在同一对话中继续——传入活动描述和已识别的任何触发条件。

如果对方拒绝，则保留分流结果。任何时候都可以通过以下命令运行 PIA： /privacy-legal:pia-generation [activity]

---

如果需要停止：

冲突：[存在冲突的具体隐私政策承诺或原则]

要继续，必须满足以下条件之一：

• [方案 A——重新设计活动，避免产生冲突]
• [方案 B——更新隐私政策以涵盖此项处理（需要审查该更新本身是否符合合法依据）]

如果没有可行方案，就不要提出后续路径。如果此项处理根本无法与已声明的承诺或合法依据相协调，请明确说明。

---

第 6 步：跨插件交接

AI 治理交接： 如果活动涉及 AI 系统作出或影响针对个人的决策：

“此活动涉及 AI 决策。除了 PIA 外，可能还需要进行 AI 影响评估。使用 /ai-governance-legal:aia-generation [activity] 并行开展评估——两者不能互相替代。”

产品法律顾问交接： 如果这是新产品功能或产品发布：

“如果这是产品发布的一部分，请让产品法律顾问参与。 使用 /product-legal:launch-review——它会检测隐私相关内容， 并将事项转交给此插件处理。”

仅在交接确实相关时才标记。不要把两项交接都作为套话附加。

---

批量分流

如果用户提供了功能列表、路线图或待办事项——先给出汇总表， 然后展开说明每个非 PROCEED 项：

#	活动	分类	关键条件 / 阻碍
1	[activity]	🟢 可以继续	—
2	[activity]	🟡 需要 PIA	需要评估合法依据；尚未签订供应商 DPA
3	[activity]	🟠 必须进行 DPIA	大规模处理特殊类别数据
4	[activity]	🔴 停止	与隐私政策冲突——目的限制

---

边缘情况和失败模式

“数据已匿名化”并不意味着可以直接 PROCEED。 询问如何进行匿名化，以及根据数据集，是否仍有现实可能重新识别个人。 根据 GDPR，假名化数据仍属于个人数据。

“我们已经做过类似的事”不算完成分流。 从未经过评估的现有处理活动，不能为新的处理活动提供豁免。 如果新活动在规模、目的或数据类别方面存在实质差异， 应重新进行分流。

“只是试点”不代表可以跳过分流。 涉及真实用户或员工数据的试点，同样受相关触发条件约束。 采用相同的分类方式；如果需要 PIA，试点也应进行 PIA。

“隐私问题都由供应商处理。” 供应商负责基础设施。你仍然是决定处理目的的数据控制者。 如果个人数据流向供应商，就需要 DPA；仍需针对处理目的进行分流。

推断数据和衍生属性也算在内。 如果活动会生成有关个人的推断数据（例如行为评分、 预测的偏好），在分流时应将推断属性视为个人数据。 不要让“我们只是在计算评分”掩盖评分所代表的含义。

以“下一步”决策树收尾

按照 CLAUDE.md ## Outputs 中的要求，以“下一步”决策树收尾。根据此技能刚刚生成的内容定制选项——五个默认分支（起草 X、升级处理、补充事实、持续关注并等待、其他事项）只是起点，并非固定选项。决策树就是输出；由律师作出选择。