policy-monitor

/policy-monitor

扫描模式（无参数或 --sweep）：

1. 读取 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → 输出文件夹路径、政策文档、上次扫描日期。
2. 运行以下工作流。扫描输出文件夹中自上次扫描以来的文件。
3. 对每项输出：提取已批准的实践 → 与当前政策承诺进行比对。
4. 对差异进行分类：REQUIRED（政策对当前实践的描述有误）与 ADVISABLE（政策未提及）。
5. 对于每项差异：引用当前政策、描述差异、起草建议措辞。
6. 更新 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 中的 Last policy sweep date。

直接查询模式（带描述参数）：

1. 读取 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → 当前政策承诺 + 实际政策文档。
2. 解析拟议实践。将其与政策进行比对：数据类别、用途、第三方、保留期限、用户权利、披露。
3. 输出：已涵盖 / 缺失 / 冲突 + 每项差异的建议措辞 + 时机建议。

计划安排： 在你自己的计划工具（日历、任务管理器或 CI）中设置定期提醒，每周运行一次 /privacy-legal:policy-monitor。计划执行需要计划任务集成；此插件未捆绑该集成。

/privacy-legal:policy-monitor
/privacy-legal:policy-monitor "We want to start using behavioral data to personalize onboarding emails"

---

隐私政策监控器

目的

隐私政策会沿着一个方向逐渐偏离实践：实践不断推进，政策却停滞不前。PIA 批准了一个新的数据类别。签署了 DPA，但其中的子处理方未在任何地方列出。分流结果将一个新用例标记为有条件通过，并要求披露相关信息，而政策尚未作出这项说明。几个月后，有人阅读政策，却发现它与实际情况不符。

此技能可在问题出现前发现这种偏差——既可以每周扫描输出文件夹，也可以回答直接问题：“我们即将开始做 X，这对政策意味着什么？”

输出始终相同：差异在哪里，以及建议措辞是什么。

---

加载当前状态

读取 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md：

• ## Who we are → ## Regulatory footprint — 适用的法规（GDPR、CCPA / CPRA / 其他州消费者隐私法规、GLBA、HIPAA、FERPA、COPPA、VPPA、CPNI 等）
• ## Privacy policy commitments — 从已发布政策中提取的承诺
• ## Outputs — 输出文件夹路径、政策文档位置、上次扫描日期

如果 ## Outputs 包含 [PLACEHOLDER]：

“尚未配置输出。我仍可进行直接查询检查——请描述你计划开展的活动，我会将其与当前政策进行比对。若要启用扫描模式，请运行 /privacy-legal:cold-start-interview 并提供输出文件夹路径。”

读取 ## Outputs 中 Privacy policy document 所指路径下的实际隐私政策文档。配置文件 CLAUDE.md 中的承诺只是摘要；提出编辑建议时，应以实际文档为准。

隐私承诺分布在多个界面上——逐一检查

网站隐私政策只是一个界面。现代隐私计划至少还会在另外四个监管机构积极审查其是否存在不一致的地方作出具有约束力的承诺：

1. Cookie 同意横幅／CMP。 同意管理平台会承诺特定的 Cookie 类别和用途。如果隐私政策写着“我们使用分析 Cookie”，而 CMP 却提供“仅限严格必要项”，两者就相互矛盾。欧盟数据保护机构和 FTC 都曾针对 CMP 配置错误采取执法行动。
2. 应用商店隐私标签。 Apple App Privacy（“营养标签”）和 Google Data Safety 均由企业自行申报，且受 FTC 执法监管。公司更新了隐私政策，却没有更新 App Store 标签，就会造成一项重大且监管机构可见的不一致。请检查：标签上次更新时间是什么时候？标签中的数据类别、用途和共享情况是否与当前政策一致？
3. 产品内同意流程。 用户实际选择如何使用其数据的界面（例如引导流程中的同意选项、设置开关、“我们已更新政策”对话框）。政策说明你会做什么；同意流程说明用户同意了什么。两者应保持一致。
4. 行业特定声明。 GLBA 隐私声明、HIPAA NPP、FERPA 目录信息声明、COPPA 直接通知。这些声明有各自的更新义务，也有与一般隐私政策保持一致的要求。（详见下文“行业专项声明”。）

在实践档案中为每个界面添加其位置和上次更新时间字段。 全面检查会将每个界面与当前政策逐一核对，并标记差异：“隐私政策已于 [date] 更新。App Store 标签上次更新于 [earlier date]——可能未反映新的数据类别。CMP 上次配置于 [date]——请核实 Cookie 用途是否与政策一致。”

隐私政策完善但 App Store 标签已过时的公司，随时可能面临 FTC 投诉。要检查各个界面，而不只是文档。

本轮扫描涵盖行业专项告知

网站隐私政策是一份告知。受联邦监管的实践需要单独的行业专项告知，网站政策不能替代该告知。如果 ## Regulatory footprint 包含以下任一项，本轮扫描除网站政策外，还会针对该告知比对实践；如果未配置此类告知，则会标记其缺失：

足迹条目	比对所依据的行业专项告知	应标记的事项
GLBA / Reg P（处理 NPI 的金融机构）	GLBA 初始及年度隐私告知（12 C.F.R. Part 1016，或职能监管机构的同等规定）	输出暗示新增 NPI 类别、向非关联第三方共享，或变更 Reg P 告知中未体现的退出机制。如果与接收 NPI 的分析供应商签署了 DPA，却未相应更新 Reg P 告知，则存在缺口。
HIPAA（受监管实体或 BA）	隐私实践告知（45 C.F.R. § 164.520）	输出暗示新增用途或披露、新增常规类别，或变更患者权利机制。如果与新的分包商签署了 BAA，且该分包商会接收 PHI，但未相应更新 NPP，则存在缺口。
FERPA（学校或学校服务提供商）	年度目录信息／权利告知（34 C.F.R. § 99.37）	输出暗示依据学校官员例外向服务提供商新增披露类别、新增目录信息要素，或变更可能影响家长同意传递流程的事项。
COPPA（面向 13 岁以下儿童的服务运营方）	直接向家长发出的告知 + 在线告知（16 C.F.R. § 312.4）	输出暗示新增从儿童处收集的数据类别、新增第三方披露，或变更可验证的家长同意机制。
VPPA / CPNI / DPPA / 其他行业专项法规	该法规的具体告知或同意机制	该法规限制但配置的告知中未体现的处理活动。

如果足迹中某项法规没有配置行业专项告知，则每次扫描都应将其作为持续存在的缺口提示，而不是仅提示一次。扫描结果应包含：

行业专项告知覆盖情况：

• [regime]：[已配置的告知路径 + 最后更新日期，或“未配置——解决前每次扫描均须标记”]

如果扫描无法找到行业专项告知，请明确说明——不要默认仅与网站政策进行比对。依赖政策监控扫描、但扫描忽略 GLBA 的金融科技 DPO，可能会在没有任何警告的情况下，使用过时的面向监管机构的告知开展业务。请显著提示这一缺口。

**如果足迹存在歧义，请询问用户。**如果 ## Regulatory footprint 写的是“GDPR / CCPA”，但输出扫描发现了 PHI、NPI 或学生数据类别，则应在继续之前提示足迹与实践不匹配：“您的足迹未列出 [GLBA / HIPAA / FERPA / COPPA]，但本次扫描发现输出涉及[类别]。是否应将该法规纳入足迹？是否有可供比对的行业专项告知？”

---

模式检测

**扫描模式：**未提供参数、使用 --sweep，或由计划任务触发。 → 扫描 outputs 文件夹。将上次扫描之后的所有输出与当前政策进行比对。

**直接查询模式：**用户提供对拟议新实践的描述。 → 将该实践与当前政策进行比对，并建议更新。

---

模式 1：扫描

确定范围

读取 ## Outputs → Last policy sweep 日期。在 outputs 文件夹中查找日期晚于该日期的输出文件。如果未记录日期，则扫描所有文件并注明：“首次扫描——正在扫描所有输出。”

如果 outputs 文件夹为空，或自上次扫描以来没有新文件：

“自 [上次扫描日期] 起没有新输出。政策似乎与近期实践一致。下次计划扫描：[日期]。”

扫描完成后，将 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 中的 Last policy sweep 更新为今天的日期。

各类输出的阅读要点

PIA（隐私影响评估）：

• 提取：处理的数据类别、处理目的、涉及的第三方／子处理方、 保留期限、对用户权利的影响、对处理施加的任何条件
• 标记：上述内容中任何未包含在当前隐私政策承诺中的事项

DPA 审查（已签署或已批准）：

• 提取：新增的子处理方、商定的数据存储位置、涵盖的处理目的、 DPA 条款赋予数据主体的任何义务
• 标记：政策中未列出的子处理方（如果政策会列出）、新增的处理类别、新的数据存储位置、 与政策不一致的义务

分流结果（PIA REQUIRED / PROCEED）：

• 提取：已批准的事项、任何意味着需作出公开承诺的附加条件 （例如：“上线前必须向受影响方披露”）
• 标记：政策未涵盖的已批准做法、需要在政策中说明的条件

DSAR 回复：

• 提取：此前的 DSAR 回复中未出现的任何新数据类别、 添加到系统列表中的任何系统
• 标记：已收集但未在政策中说明的数据类别

识别差距

对于每个标记项，评估：

必须更新 — 政策作出的承诺与此输出相矛盾，或者处理正在进行，但政策完全未涉及。若不更新，就会造成重大失实陈述。

示例：政策称“我们会收集姓名、电子邮件和支付信息”。PIA 批准收集位置数据。政策没有提及位置数据。这属于必须更新——你正在收集尚未披露的数据。

建议更新 — 政策未作说明，但也不存在冲突。即使不更新，该处理也有充分依据；不过更新后会更清晰。

示例：政策称“我们可能会与服务提供商共享数据”。你与一家新的分析服务商签署了 DPA。政策没有点名该服务商，但也未将其排除。如果维护了具名子处理方列表，建议将其列入。

扫描输出格式

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

# Privacy Policy Monitor — Sweep Report

**Date:** [date]
**Outputs scanned:** [N files] | **New since last sweep:** [N files]
**Gaps found:** [N] REQUIRED | [N] ADVISABLE

---

## REQUIRED updates

### [Gap 1 short name]

**Source:** [filename / output type that triggered this]
**What's happening:** [plain description of the new practice]
**Current policy:** [quote the relevant section — or "No coverage"]
**Gap:** [what's missing or inconsistent]

**Suggested language:**
> *Add to [section name]:*
> "[Drafted policy text — specific, consistent with house style of the actual policy]"

---

[repeat for each REQUIRED gap]

---

## ADVISABLE updates

### [Gap name]

**Source:** [filename]
**What's happening:** [description]
**Current policy:** [quote or "Silent"]
**Suggested language:**
> *Add to / update [section]:*
> "[Drafted text]"

---

## No action needed

[List outputs scanned where no gaps were found — confirms they were reviewed]

---

## Next steps

- [ ] Review REQUIRED updates — each needs a decision before the associated
  feature/processing goes live (or immediately if already live)
- [ ] Review ADVISABLE updates — lower urgency but worth addressing at next
  policy refresh
- [ ] Next scheduled sweep: [date]

---

模式 2：直接查询

解析拟议做法

从用户的描述中提取：

• 正在收集或处理哪些数据？
• 目的是什么？
• 还涉及哪些其他方（供应商、合作伙伴、第三方）？
• 数据主体是谁？
• 是否涉及自动化决策？
• 是否需要向数据主体作出任何新的披露？

如果描述含糊，继续之前先提出一个澄清问题。不要进行冗长的信息收集——此模式应当快速。

政策差异分析

将拟议做法与当前政策中的每个相关部分进行核对：

检查项	当前政策说明	拟议做法	结论
数据类别	[政策列出的内容]	[如有新增类别]	🟢 已涵盖 / 🟡 存在差距 / 🔴 存在冲突
目的	[已说明的目的]	[新目的]
第三方／子处理方	[已说明的相关方]	[如有新增相关方]
保留期限	[保留承诺]	[隐含的保留期限]
用户权利	[提供的权利]	[任何新的权利影响]
披露／告知	[政策关于告知用户的说明]	[此做法要求的内容]

直接查询输出格式

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

# Privacy Policy Check: [Proposed practice in one line]

**Bottom line:** [POLICY UPDATE REQUIRED / ADVISABLE / NO UPDATE NEEDED]

---

## What's covered

[List aspects of the proposed practice already addressed by the current policy —
brief, confirms they don't need to change]

## What's missing

### [Gap 1]

**Current policy:** [quote or "Silent"]
**What's needed:** [why this gap matters — legal, reputational, or consistency reason]

**Suggested language:**
> *Add to [section]:*
> "[Drafted text]"

### [Gap 2]
[same format]

## What conflicts

### [Conflict 1 — if any]

**Current policy says:** [quote]
**Proposed practice does:** [what conflicts]
**Resolution:** [which one needs to change and why — usually the practice adjusts
to match the policy, or the policy gets updated to a defensible new position]

---

## Timing

[If any gap is REQUIRED: "Policy update should happen before this goes live."
If ADVISABLE: "Can proceed; update at next policy refresh."]

---

建议的语言质量标准

政策语言应：

• 符合现有政策的语气和风格（起草前请阅读实际文档，而不只是配置中的 CLAUDE.md 摘要）
• 足够具体，能够表达明确含义，但又不至于具体到常规变更就会使其失效（“协助我们运营业务的服务提供商”比列出每个供应商更经得起时间考验）
• 不作出团队无法履行的承诺（例如，如果架构会将位置数据传给分析供应商，就不要起草“我们绝不分享位置数据”）
• 标出可能需要调整更广泛政策立场的地方，而不只是添加一句话

起草时，务必说明应添加到哪个章节。如果不存在合适的章节，请说明这一点并建议新建章节。

---

计划集成

在你自己的日程安排工具（日历、任务管理器或 CI）中设置定期提醒，每周运行一次 /privacy-legal:policy-monitor。定时执行需要定时任务集成；此插件不附带该集成。

每次运行扫描时，都会更新 ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md 中的 ## Outputs → 上次政策扫描，以便下次扫描只检查新文件。

---

以“后续步骤决策树”收尾

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

如果扫描发现的偏差项超过约 10 项，或者用户提出要求，请提供仪表板（参见 CLAUDE.md ## Outputs → Dashboard offer for data-heavy outputs）。根据此输出设计仪表板内容——按涉及对象（政策条款／PIA／DPA／分流）统计数量，按严重程度统计数量，并提供可排序的发现项表格，列出来源材料和建议的补救措施。

此技能不会做什么

• 它不会更新政策本身——它会起草建议用语并标出待决事项，但每项变更都必须经过人工审核和批准。
• 它不会发现法规变化——这属于 reg-gap-analysis 的工作。此技能监控内部实践偏差，而非外部法律变化。
• 它不会强制保存输出——如果团队没有将 PIA 保存到配置的文件夹中，扫描就无法找到它们。直接查询模式无需已保存的输出。
• 它不会读取电子邮件或 Slack 中的非正式决定——只读取保存到配置文件夹中的结构化输出。