---
name: policy-monitor
description: >
  保持AI使用政策与当前实践一致。两种模式：每周扫描已保存的AI
  评估和分类结果以发现政策漂移；或对提议的新实践进行直接查询。
  适用于用户询问"我们的AI政策是否覆盖了这一点"、"我们想
  开始做X——政策需要更新吗"、"运行AI政策监测"、"政策扫描"
  或需要发现AI政策与实际操作不符之处时。
argument-hint: "[描述提议的新AI实践 — 或省略/使用 --sweep 进入扫描模式]"
---

# /policy-monitor

**扫描模式**（无参数或 `--sweep`）：
1. 读取 `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` → 输出文件夹路径、AI使用政策文档、上次扫描日期。
2. 运行以下工作流。扫描输出文件夹中自上次扫描以来的文件。
3. 对每个输出：提取已批准的实践 → 与当前政策承诺对比。
4. 分类差距：必须（政策与实际操作不符）vs 建议（政策未提及）。
5. 对每个差距：引用当前政策、描述差距、起草建议语言。
6. 更新 `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` 中的上次政策扫描日期。

**直接查询模式**（有描述参数）：
1. 读取 `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` → 当前政策承诺 + 实际政策文档。
2. 解析提议的实践。与政策对比：AI系统类型、数据使用、透明度、安全措施、用户权利、供应商管理。
3. 输出：已覆盖 / 缺失 / 冲突 + 每个差距的建议语言 + 时机建议。

```
/ai-governance-legal:policy-monitor
/ai-governance-legal:policy-monitor "我们想在内部使用AI生成客户邮件的草稿"
```

---

# AI使用政策监测

## 目的

AI使用政策与实际实践之间的漂移是单向的：实践向前发展，政策滞留在后。AI评估批准了新的模型。一个AI供应商带来了新功能。分类结果标记了一个有额外透明度要求的用例——但面向用户的AI使用政策还没有相应语言。政策最终与实际发生的事不符。

此技能在漂移成为问题之前捕获它——无论是通过每周爬取输出文件夹，还是通过回答直接问题："我们即将开始做X，这对政策意味着什么？"

输出总是相同的：这里是差距，这里是建议的语言。

---

## 加载当前状态

读取 `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`：
- `## 监管注册表` — 适用法规范围
- `## AI使用政策` — 已对外公开的AI使用承诺或内部AI治理政策摘要
- `## AI系统清单` — 所有已部署、在评估和已退役的系统
- `## 输出` — 输出文件夹路径、AI使用政策文档位置、上次政策扫描日期

如果 `## 输出` 包含 `[PLACEHOLDER]`：
> "输出尚未配置。我仍然可以运行直接查询检查——描述你计划做的事情，我会将其与你当前政策进行对比。要启用爬取扫描，请运行 `/ai-governance-legal:cold-start-interview` 并提供输出文件夹路径。"

读取 `## 输出` → **AI使用政策文档** 路径下的实际政策文档。配置CLAUDE.md中的承诺是摘要；实际文档是建议编辑的权威来源。

### AI承诺存在于多个界面——全部扫描

面向用户的AI使用政策声明是一个界面。现代AI监管审查中，AI承诺至少存在于以下三个额外地方：

1. **AI服务协议/界面**：在AI功能界面上的披露（例如"AI生成内容，仅供参考"）。如果政策说"我们对所有AI生成内容进行人工审核"但产品界面没有相应标识，就是冲突。
2. **算法备案公示信息**：已完成的算法备案在网信办指定系统中的公示信息（《互联网信息服务算法推荐管理规定》第24条 `[法条原文]`）。如果备案信息中描述的数据处理范围与当前政策不一致，网信办有直接可见的不一致。
3. **科技伦理审查材料**：提交给伦理审查委员会的材料中关于数据处理和算法使用的声明。如果伦理审查中承诺的保障措施在面向用户政策中没有体现，就是差距。

**在实践配置文件中添加每个界面的位置和最后更新日期字段。** 扫描时逐一检查并与当前政策对比，标记分歧。

---

## 模式检测

**扫描模式：** 无参数、`--sweep` 或由定时任务触发。
→ 扫描输出文件夹。将自上次扫描以来的所有输出与当前政策对比。

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

---

## 模式一：扫描

### 确定范围

读取 `## 输出` → **上次AI政策扫描** 日期。扫描输出文件夹中该日期之后的输出文件。如果未记录日期，扫描所有文件并注明："首次扫描——扫描所有输出。"

如果输出文件夹为空或自上次扫描以来没有新文件：
> "自[上次扫描日期]以来没有新输出。AI使用政策与近期实践一致。下次计划扫描：[日期]。"

扫描完成后更新 `## 输出` → **上次AI政策扫描** 为今天的日期。

### 每种输出类型应读取的内容

**AI系统评估（全面轨）：**
- 提取：AI系统类型、所涉数据类别、训练数据来源、透明度措施、安全措施、用户权利影响、算法备案状态
- 标记：清单中不在当前政策承诺中的任何内容

**AI用例分类结果：**
- 提取：已批准或附条件批准的内容、施加的任何条件暗示了公开承诺（例如"需要在AI使用政策中披露使用了推荐算法"）
- 标记：批准但政策未覆盖的实践、需要政策语言的条件

**AI供应商审查：**
- 提取：使用的AI供应商、供应商处理的数据类别、供应商的模型训练做法、协议中的合规承诺
- 标记：政策中未列出的供应商（如果政策列出供应商）、新的数据处理类别、新的AI功能

### 差距识别

对每个标记项目，评估：

**必须更新** — 政策所做的承诺与此输出矛盾，或AI处理正在发生但政策完全没有覆盖。不更新会产生实质性的虚假陈述。

> 示例：AI政策说"我们不对用户数据进行AI训练"。AI供应商审查批准了一个供应商将部分客户数据用于模型改进。政策与批准实践矛盾——必须更新。

**建议更新** — 政策未提及但无冲突。处理的合法性在没有更新的情况下也可以成立，但更新后更完整。

> 示例：AI政策说"我们可能在部分功能中使用AI技术"。AI系统评估批准了一个新的AI驱动客服聊天机器人。政策未具体提到客服AI，但也不排除它。建议在政策中增加具体说明。

### 扫描输出格式

```markdown
[工作成果头 — 按照插件配置 ## 输出]

# AI使用政策监测 — 扫描报告

**日期：** [日期]
**扫描输出数：** [N个文件] | **自上次扫描以来的新输出：** [N个文件]
**发现差距：** [N] 必须 | [N] 建议

---

## 必须更新

### [差距1简短名称]

**来源：** [触发此差距的文件名/输出类型]
**实际情况：** [新实践的简明描述]
**当前政策：** [引用相关部分——或"无覆盖"]
**差距：** [缺失或不一致的内容]

**建议语言：**
> *添加到[章节名称]：*
> "[起草的政策文本——具体、与现有政策语言风格一致]"

---

[对每个必须差距重复]

---

## 建议更新

### [差距名称]

**来源：** [文件名]
**实际情况：** [描述]
**当前政策：** [引用或"未提及"]
**建议语言：**
> *添加到/更新[章节]：*
> "[起草的文本]"

---

## 无需行动

[列出扫描过但未发现差距的输出——确认已审阅]

---

## 下一步

- [ ] 审阅必须更新——每项都需要在相关功能/处理上线之前（或立即，如果已上线）做出决定
- [ ] 审阅建议更新——紧急程度较低，但值得在下一次政策更新时处理
- [ ] 下次计划扫描：[日期]
```

---

## 模式二：直接查询

### 解析提议的实践

从用户描述中提取：
- 涉及什么类型的AI系统或模型？
- 用于什么目的？
- 涉及什么数据？
- 谁使用它（内部还是面向公众）？
- 是否有自动化决策？
- 是否涉及生成合成内容或深度合成？
- 是否需要向用户进行新的披露？

如果描述模糊，在继续之前问一个澄清问题。不要运行冗长的录入——此模式应该快速。

### 政策对比

将提议的实践与当前AI使用政策的每个相关部分进行核查：

| 核查项 | 当前政策表述 | 提议实践 | 结论 |
|--------|-------------|----------|------|
| AI系统类型 | [政策列出的类型] | [新类型] | 🟢已覆盖 / 🟡差距 / 🔴冲突 |
| 数据使用 | [声明的数据使用方式] | [新方式] | |
| 透明度/披露 | [声明的透明度措施] | [所需披露] | |
| 训练数据实践 | [声明的训练做法] | [新做法] | |
| 人工审核 | [人工审核承诺] | [新实践的人工参与度] | |
| 用户控制 | [用户选择/退出机制] | [新实践的用户控制] | |

### 直接查询输出格式

```markdown
[工作成果头 — 按照插件配置 ## 输出]

# AI使用政策检查：[提议实践一行描述]

**结论：** [需要更新政策 / 建议更新 / 无需更新]

---

## 已覆盖

[列出当前政策已经覆盖的实践方面——简要概括，确认不需要改变]

## 缺失

### [差距1]

**当前政策：** [引用或"未提及"]
**为什么需要补：** [为什么这个差距重要——法律、声誉或一致性原因]

**建议语言：**
> *添加到[章节]：*
> "[起草的文本]"

### [差距2]
[相同格式]

## 冲突

### [冲突1——如有]

**当前政策表述：** [引用]
**提议实践：** [冲突之处]
**解决方向：** [哪一方需要改变及原因——通常是实践调整以匹配政策，或政策更新至新的可辩护立场]

---

## 时机

[如果有任何必须差距："政策更新应在实践上线之前完成。"
如果是建议："可以继续推进；在下一次政策更新时处理。"]
```

---

## 建议语言的质量标准

政策语言应：
- 与现有AI使用政策的语气和风格一致（在起草前阅读实际文档，而非仅凭CLAUDE.md摘要）
- 足够具体以有意义，但不过于具体以致常规变更破坏它（"我们使用AI技术来提升服务质量" 比列出每个模型名称更经得起时间考验）
- 不做团队无法遵守的承诺（例如，如果架构是每次API调用都流经第三方，不要起草"我们不会将数据发送给第三方AI供应商"）
- 标记可能需要更广泛政策立场变更的地方，而不仅仅是增加一句话

起草时，始终说明应添加到哪个章节。如果合适的章节不存在，要说明并建议创建它。

---

## 收尾

以 CLAUDE.md `## 输出` 规定的下一步决策树收尾。

如果扫描产生的漂移发现超过约10项，或用户任何时候提出要求：提供仪表板（见 CLAUDE.md `## 输出 → 数据密集型输出的仪表板提议`）。针对此输出定制提议——按界面（政策条款/AI评估/用例分类/供应商审查）统计、按严重程度统计、以及可排序的发现网格，附来源工件和建议的整改措施。

---

## 本技能不做的事

- 不直接更新政策本身——起草建议语言并标记决策，但由人工审阅和批准每项变更。
- 不捕获法规变化——那是 `reg-gap-analysis` 的职责。此技能监测内部实践漂移，而非外部法律变化。
- 不强制输出被保存——如果团队没有将AI评估保存到配置的文件夹，扫描不会找到它们。直接查询模式无需保存的输出即可工作。
- 不读取邮件或即时通讯中的非正式决定——只能扫描保存到配置文件夹的结构化输出。