| name | policy-monitor |
| description | 保持AI使用政策与当前实践一致。两种模式：每周扫描已保存的AI 评估和分类结果以发现政策漂移；或对提议的新实践进行直接查询。 适用于用户询问"我们的AI政策是否覆盖了这一点"、"我们想 开始做X——政策需要更新吗"、"运行AI政策监测"、"政策扫描" 或需要发现AI政策与实际操作不符之处时。
|
| argument-hint | [描述提议的新AI实践 — 或省略/使用 --sweep 进入扫描模式] |
/policy-monitor
扫描模式（无参数或 --sweep）：
- 读取
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → 输出文件夹路径、AI使用政策文档、上次扫描日期。
- 运行以下工作流。扫描输出文件夹中自上次扫描以来的文件。
- 对每个输出：提取已批准的实践 → 与当前政策承诺对比。
- 分类差距：必须（政策与实际操作不符）vs 建议（政策未提及）。
- 对每个差距：引用当前政策、描述差距、起草建议语言。
- 更新
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md 中的上次政策扫描日期。
直接查询模式（有描述参数）：
- 读取
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → 当前政策承诺 + 实际政策文档。
- 解析提议的实践。与政策对比：AI系统类型、数据使用、透明度、安全措施、用户权利、供应商管理。
- 输出：已覆盖 / 缺失 / 冲突 + 每个差距的建议语言 + 时机建议。
/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承诺至少存在于以下三个额外地方：
- AI服务协议/界面：在AI功能界面上的披露（例如"AI生成内容，仅供参考"）。如果政策说"我们对所有AI生成内容进行人工审核"但产品界面没有相应标识，就是冲突。
- 算法备案公示信息：已完成的算法备案在网信办指定系统中的公示信息（《互联网信息服务算法推荐管理规定》第24条
[法条原文]）。如果备案信息中描述的数据处理范围与当前政策不一致，网信办有直接可见的不一致。
- 科技伦理审查材料：提交给伦理审查委员会的材料中关于数据处理和算法使用的声明。如果伦理审查中承诺的保障措施在面向用户政策中没有体现，就是差距。
在实践配置文件中添加每个界面的位置和最后更新日期字段。 扫描时逐一检查并与当前政策对比，标记分歧。
模式检测
扫描模式： 无参数、--sweep 或由定时任务触发。
→ 扫描输出文件夹。将自上次扫描以来的所有输出与当前政策对比。
直接查询模式： 用户提供提议的新AI实践描述。
→ 将该实践与当前政策对比。建议更新。
模式一：扫描
确定范围
读取 ## 输出 → 上次AI政策扫描 日期。扫描输出文件夹中该日期之后的输出文件。如果未记录日期，扫描所有文件并注明："首次扫描——扫描所有输出。"
如果输出文件夹为空或自上次扫描以来没有新文件：
"自[上次扫描日期]以来没有新输出。AI使用政策与近期实践一致。下次计划扫描：[日期]。"
扫描完成后更新 ## 输出 → 上次AI政策扫描 为今天的日期。
每种输出类型应读取的内容
AI系统评估（全面轨）：
- 提取：AI系统类型、所涉数据类别、训练数据来源、透明度措施、安全措施、用户权利影响、算法备案状态
- 标记：清单中不在当前政策承诺中的任何内容
AI用例分类结果：
- 提取：已批准或附条件批准的内容、施加的任何条件暗示了公开承诺（例如"需要在AI使用政策中披露使用了推荐算法"）
- 标记：批准但政策未覆盖的实践、需要政策语言的条件
AI供应商审查：
- 提取：使用的AI供应商、供应商处理的数据类别、供应商的模型训练做法、协议中的合规承诺
- 标记：政策中未列出的供应商（如果政策列出供应商）、新的数据处理类别、新的AI功能
差距识别
对每个标记项目，评估：
必须更新 — 政策所做的承诺与此输出矛盾，或AI处理正在发生但政策完全没有覆盖。不更新会产生实质性的虚假陈述。
示例：AI政策说"我们不对用户数据进行AI训练"。AI供应商审查批准了一个供应商将部分客户数据用于模型改进。政策与批准实践矛盾——必须更新。
建议更新 — 政策未提及但无冲突。处理的合法性在没有更新的情况下也可以成立，但更新后更完整。
示例：AI政策说"我们可能在部分功能中使用AI技术"。AI系统评估批准了一个新的AI驱动客服聊天机器人。政策未具体提到客服AI，但也不排除它。建议在政策中增加具体说明。
扫描输出格式
[工作成果头 — 按照插件配置 ## 输出]
# AI使用政策监测 — 扫描报告
**日期：** [日期]
**扫描输出数：** [N个文件] | **自上次扫描以来的新输出：** [N个文件]
**发现差距：** [N] 必须 | [N] 建议
---
## 必须更新
### [差距1简短名称]
**来源：** [触发此差距的文件名/输出类型]
**实际情况：** [新实践的简明描述]
**当前政策：** [引用相关部分——或"无覆盖"]
**差距：** [缺失或不一致的内容]
**建议语言：**
> *添加到[章节名称]：*
> "[起草的政策文本——具体、与现有政策语言风格一致]"
---
[对每个必须差距重复]
---
## 建议更新
### [差距名称]
**来源：** [文件名]
**实际情况：** [描述]
**当前政策：** [引用或"未提及"]
**建议语言：**
> *添加到/更新[章节]：*
> "[起草的文本]"
---
## 无需行动
[列出扫描过但未发现差距的输出——确认已审阅]
---
## 下一步
- [ ] 审阅必须更新——每项都需要在相关功能/处理上线之前（或立即，如果已上线）做出决定
- [ ] 审阅建议更新——紧急程度较低，但值得在下一次政策更新时处理
- [ ] 下次计划扫描：[日期]
模式二：直接查询
解析提议的实践
从用户描述中提取：
- 涉及什么类型的AI系统或模型？
- 用于什么目的？
- 涉及什么数据？
- 谁使用它（内部还是面向公众）？
- 是否有自动化决策？
- 是否涉及生成合成内容或深度合成？
- 是否需要向用户进行新的披露？
如果描述模糊，在继续之前问一个澄清问题。不要运行冗长的录入——此模式应该快速。
政策对比
将提议的实践与当前AI使用政策的每个相关部分进行核查：
| 核查项 | 当前政策表述 | 提议实践 | 结论 |
|---|
| AI系统类型 | [政策列出的类型] | [新类型] | 🟢已覆盖 / 🟡差距 / 🔴冲突 |
| 数据使用 | [声明的数据使用方式] | [新方式] | |
| 透明度/披露 | [声明的透明度措施] | [所需披露] | |
| 训练数据实践 | [声明的训练做法] | [新做法] | |
| 人工审核 | [人工审核承诺] | [新实践的人工参与度] | |
| 用户控制 | [用户选择/退出机制] | [新实践的用户控制] | |
直接查询输出格式
[工作成果头 — 按照插件配置 ## 输出]
# AI使用政策检查：[提议实践一行描述]
**结论：** [需要更新政策 / 建议更新 / 无需更新]
---
## 已覆盖
[列出当前政策已经覆盖的实践方面——简要概括，确认不需要改变]
## 缺失
### [差距1]
**当前政策：** [引用或"未提及"]
**为什么需要补：** [为什么这个差距重要——法律、声誉或一致性原因]
**建议语言：**
> *添加到[章节]：*
> "[起草的文本]"
### [差距2]
[相同格式]
## 冲突
### [冲突1——如有]
**当前政策表述：** [引用]
**提议实践：** [冲突之处]
**解决方向：** [哪一方需要改变及原因——通常是实践调整以匹配政策，或政策更新至新的可辩护立场]
---
## 时机
[如果有任何必须差距："政策更新应在实践上线之前完成。"
如果是建议："可以继续推进；在下一次政策更新时处理。"]
建议语言的质量标准
政策语言应：
- 与现有AI使用政策的语气和风格一致（在起草前阅读实际文档，而非仅凭CLAUDE.md摘要）
- 足够具体以有意义，但不过于具体以致常规变更破坏它（"我们使用AI技术来提升服务质量" 比列出每个模型名称更经得起时间考验）
- 不做团队无法遵守的承诺（例如，如果架构是每次API调用都流经第三方，不要起草"我们不会将数据发送给第三方AI供应商"）
- 标记可能需要更广泛政策立场变更的地方，而不仅仅是增加一句话
起草时，始终说明应添加到哪个章节。如果合适的章节不存在，要说明并建议创建它。
收尾
以 CLAUDE.md ## 输出 规定的下一步决策树收尾。
如果扫描产生的漂移发现超过约10项，或用户任何时候提出要求：提供仪表板（见 CLAUDE.md ## 输出 → 数据密集型输出的仪表板提议）。针对此输出定制提议——按界面（政策条款/AI评估/用例分类/供应商审查）统计、按严重程度统计、以及可排序的发现网格，附来源工件和建议的整改措施。
本技能不做的事
- 不直接更新政策本身——起草建议语言并标记决策，但由人工审阅和批准每项变更。
- 不捕获法规变化——那是
reg-gap-analysis 的职责。此技能监测内部实践漂移，而非外部法律变化。
- 不强制输出被保存——如果团队没有将AI评估保存到配置的文件夹，扫描不会找到它们。直接查询模式无需保存的输出即可工作。
- 不读取邮件或即时通讯中的非正式决定——只能扫描保存到配置文件夹的结构化输出。
