Regulatory policy diff

何时使用

当一项法规/监管规则发生变更，需要回答「它触及我们哪些内部制度、与现行制度之间存在什么差距」时使用。典型触发：用户说「把这条法规和我们的制度做差距比对」「这条规则影响哪个制度」「做一次合规缺口分析」，或上游的法规监测环节交来一条实质性变更条目。

不该用的边界：

• 不负责起草制度修订文本——本技能只识别「需要改什么」，实际撰写交给制度起草环节或人工。
• 不对模糊监管条款做权威定性——若条文可作两种解读，明确指出并标注交由法务/外部律师裁断，不替决策者拍板。
• 输入是 ANPR/RFI 等「征求意见、尚无强制要求」的预规则时，不做完整差距闭环，改走预定位分析分支（见步骤）。

步骤

1. 载入制度库索引（制度清单、存放位置、责任人/Owner）。索引为空或仍为占位符时，按「注意事项」中的降级处理。
2. 核验规则状态（先验后比，见下）。
3. 逐条提取新规要求。
4. 把每条要求映射到现行制度。
5. 对命中的制度做差距比对；对无命中的要求单列为「缺制度」缺口。
6. 汇总输出：摘要表 + 逐条详细差距 + 新增制度建议 + 无差距项。

指令

第 0 步：比对前先核验规则是否生效

比对前确认规则确实在施行。以下为「可能未生效」的红旗信号：

• 适用/合规日期已过去超过 30 天，但无法确认未被延期；
• 规则发布已超过 12 个月；
• 属于政治争议较大的终局规则（大型立法常被诉讼挑战）。

遇红旗时，通过研究类 MCP、网络检索（若启用）或官方公报/登记册核查：延期、暂缓执行、禁制令、撤销提案、判决撤销、修订等情况。能核实且确认在施行则继续；若无工具可核实，在正文标题上方、任何内容之前置顶以下横幅：

⚠️ 规则状态未核实——无法确认该规则当前是否生效。终局规则在发布后常被暂缓、禁止、延期或撤销。在你于官方登记册或外部律师处确认状态之前，不要把下文任何合规日期当作有约束力的截止日。

输出中每个截止日都打标：[按已发布规则—状态未核实]。向下游交接缺口时标记 status_verified: false，避免仅凭发布日期被误归入「逾期」桶。

第 1 步：提取新增/变更的要求

• 不静默补全：变更文本残缺或含糊、且索引来源拿不到完整规则时，停下来发问，不要用网络检索或模型记忆悄悄补齐。给出选项：粘贴全文 / 指向权威原文 / 检索网络（结果打 [网络检索—待核实]，依赖前须对照发证机构核对）/ 就此停止。由律师决定是否接受低置信来源，Claude 不替其决定。
• 来源标注：每条引用（法规引文、交叉引用、制度摘录）都标来源：原始来源/制度库/MCP 标 [<监管机构或研究工具>]；网络检索标 [网络检索—待核实]；模型记忆标 [模型知识—待核实]；用户粘贴标 [用户提供]。带「待核实」者优先核查，输出中绝不删除或合并标签。

逐条列出离散的新增或变更要求，要具体——「强化披露要求」不算要求；「须在流程 Z 节点以 Y 格式披露 X」才算：

#	要求	生效日	引文
1	[具体要求]	[日期]	[条款]

第 2 步：映射到制度

每条要求找最接近的现行制度：直接命中（制度明确覆盖该主题）/ 间接命中（覆盖相关主题，本条是新子议题）/ 无命中（无制度涉及——缺口是「制度不存在」）。

第 3 步：比对（对直接/间接命中逐条做）

### 要求 [N]：[名称]
**新规要求：** [要求]
**我方制度（[名称]，更新于 [日期]）规定：**
> "[相关摘录]"
**差距：** [无—已覆盖 | 部分—覆盖 X 未覆盖 Y | 完全—制度矛盾或未涉及]
**所需变更：** [具体到「补一段关于 X 的内容」，而非笼统「更新制度」]
**制度责任人：** [取自索引]

第 4 步：无命中缺口（单列）

### 需新增制度
要求 [N]：[要求]
无现有制度覆盖。选项：
- 起草新制度（建议责任人：最接近主题的 Owner）
- 并入现有 [相关制度] 作为新章节
- 判定无需制度（一次性合规，非持续性）

按输入类型分支

• 预规则分支（ANPR/RFI，无强制要求）：不做完整差距闭环，改出「预定位分析」——点名终局规则出台后可能需改的制度、是否值得提交意见函、意见截止日与意见决策责任人。不对 ANPR 逐条产出「无差距」行，用一段话点明未来敞口及触及的制度。
• 否定结论分支（提取的每条都对「该制度」无差距）：不做逐条全文分析，压缩成一段：说明该法规似不要求改 [制度]，并指出它真正触及的是 [其他制度]，建议对那些制度重跑。否定结论命中错目标是「路由问题」，不是合规分析。
• 差距分支（至少有一条对目标制度构成差距）：按上面格式做逐条全文分析。

范围完整性

若用户要求把某制度章节/要求/类别排除出比对：照做（用户掌控范围），但要响亮且永久地标记，并置于标题上方、带到每个下游产物：

⚠️ 范围限制：应用户要求排除 [X] 章节。本比对不反映完整制度，被排除区域内的缺口未被识别。

向下游缺口跟踪交接时附上同一横幅原文，并说明排除的含义（如「排除供应商管理意味着比对会显示『无制度涉及供应商管理』——比直接暴露缺口更糟」）。建立在未披露范围排除之上的合规产物，在举证程序中形同隐瞒——这道标记区分了「我们限定了审查范围」与「我们藏了问题」。

示例

输出骨架：

## 制度差距分析：[法规名]
**法规：** [名称、链接]　**生效：** [日期]　**提取要求数：** [N]

### 结论先行
[需在 [日期] 前处理 N 个缺口——前三：X、Y、Z]

### 摘要
| # | 要求 | 受影响制度 | 差距 | 责任人 |
|---|------|-----------|------|--------|
| 1 | [简述] | [制度名或「无」] | 无/部分/完全 | [姓名] |

### 详细差距
[第 3 步各要求块]
### 需新增制度
[第 4 步，如有]
### 无差距要求
[列表——便于了解已覆盖范围]

---
**依赖前请核验引文。** 上述法规引文与制度引用为 AI 生成、未对照原始来源核查。行动前请对照权威研究平台或发证机构网站确认条文准确性、生效日与当前状态。AI 生成的监管引文有时被臆造、误引或过时；每条要求上的来源标签显示其出处，带「待核实」者风险更高、应先核查。

注意事项

• 制度库为空时：默认把每条要求标为「无制度命中」，并在输出追加提示——若实际已有制度，请先补入制度库再重跑比对。
• 匹配制度缺责任人时：摘要中 Owner 留空，并追加提示请补齐，以便下游缺口跟踪可正确路由。制度库已填全且责任人齐备时，不要在输出里提配置的事。
• 交接：每个「部分」或「完全」差距都转为带责任人与截止日的跟踪项，移交缺口跟踪环节。
• 结尾给出「下一步决策树」（起草 X / 升级上报 / 补充事实 / 观望 / 其他），由律师选择，而非替其锁定。

互见

• fact-checking：核验 AI 生成的监管引文是否被臆造、误引或过时。
• first-principles-thinking：拆解模糊监管条文、判定一条要求是否真正构成新义务。

---

本条采编自 anthropics/claude-for-legal（Apache-2.0）。