# Cross Regulatory Impact Analyzer Patrick Munro

> 分析多个法规如何对特定产品、服务或商业模式产生交互。识别义务在何处重叠、强化、互补、重复或冲突；构建优先级矩阵；生成整合的合规时间线；并估算总合规负担。在以下情形使用：(1) 发布前针对完整监管格局界定新产品或服务范围，(2) 就目标公司多法规敞口进行并购尽职调查，(3) 构建单一法规分析会遗漏交互的战略合规路线图，(4) 就法规从不同角度触及同一行为的复杂情况提供咨询，或 (5) 为多法规合规估算预算和资源配置。主要覆盖欧盟数字监管（GDPR、数据法案、AI 法案、CRA、NIS2、DORA、DMA、DSA、ePrivacy）和国家实施；该框架可扩展到任何重叠监管制度适用于同一活动的法域。

- Skill: `cslawyer1985/cross-regulatory-impact-analyzer-patrick-munro` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add cslawyer1985/cross-regulatory-impact-analyzer-patrick-munro`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cslawyer1985/cross-regulatory-impact-analyzer-patrick-munro/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cslawyer1985 (https://skillmd.com/u/cslawyer1985)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cslawyer1985/cross-regulatory-impact-analyzer-patrick-munro

---


# 跨法规影响分析器

## 目的

大多数法规分析一次只处理一个法规。当企业只受一个法规约束时这没问题。当多个法规触及同一活动时，这就成问题了，因为真正的合规问题存在于重叠处：哪个义务更严格、哪个截止日期在前、什么同时满足两者、什么互相冲突。本技能产生单一法规指南所不能提供的分析。

## 何时使用

- 新产品或服务发布，且合理适用多个法规
- 对具有多法规敞口的目标公司进行并购尽职调查
- 条块化、逐法规的方法已达极限的战略合规规划
- 关于法规交互的复杂客户咨询
- 多法规计划的预算和资源配置估算
- 多个报告制度同时触发时对事件响应剧本进行分类

## 分析框架

分析分六个阶段进行。每个阶段产生输入下一阶段的输出。

### 阶段 1：范围确定

基于以下内容识别哪些法规适用：

- **产品或服务类型**：硬件、软件、SaaS、物联网、AI 系统、平台、金融服务
- **行业**：金融服务、医疗保健、关键基础设施、公共部门、消费等
- **实体规模**：员工人数、收入、资产负债表（对 NIS2、DORA 规模阈值、中小企业豁免很重要）
- **数据处理**：个人数据类型、数量、特殊类别
- **地理范围**：全欧盟、特定成员国、针对第三国
- **风险概况**：安全、安保、基本权利影响
- **指定状态**：VLOP/VLOSE（DSA）、守门人（DMA）、关键 ICT 第三方服务商（DORA）、关键实体（NIS2/CER）

为每个法规记录纳入理由。也记录排除理由，因为"我们考虑了 X 并得出结论因 Y 不适用"是分析价值的一半。

### 阶段 2：义务提取

对每个适用法规，提取：

- **核心要求**：必须做什么
- **截止日期**：何时需要合规，区分分阶段适用日期
- **处罚**：行政罚款、刑事制裁、私人诉权
- **符合性声明或认证**：评估类型、公告机构、自我评估与第三方
- **文件**：记录、报告、影响评估
- **持续义务**：监控、审查、更新、培训

精确引用条文。标记义务依赖尚未通过的授权法案或指引的地方。

### 阶段 3：重叠分类

使用此分类对每个交互进行分类：

- **强化（Reinforcing）**：多个法规要求相同的行动。一次实施满足两者。
- **互补（Complementary）**：法规处理同一主题的不同方面。协调，而非重复。
- **重复（Duplicative）**：措辞不同但近乎相同的义务。单一实施，双重文档。
- **冲突（Conflicting）**：要求看似矛盾。需要解释、法律意见或监管机构接触。
- **特别法（Lex specialis）**：行业特定法规优先于一般法规（如金融实体的 DORA 优先于 NIS2）。

分类很重要，因为每种分类触发不同的合规策略。

### 阶段 4：优先级矩阵

沿五个轴对义务排序：

1. **法律严重性**：被禁止的做法 > 高风险义务 > 中 > 低
2. **时间线**：最早截止日期优先
3. **依赖性**：前提先于依赖（在映射处理活动之前无法构建 DPIA）
4. **影响**：业务影响或处罚敞口最高者优先
5. **可行性**：速赢与长周期建设

产生堆叠排序的列表。不要产生"优先级"全为优先级 1 的列表。

### 阶段 5：时间线协调

构建显示以下内容的整合时间线：

- 跨法规的所有监管截止日期
- 义务之间的依赖关系
- 资源分配点
- 里程碑和检查点
- 为授权法案、指引发布和监管接触预留缓冲

交付形式：实施规划用甘特图、监管截止日期用日历视图、交互是重点时用依赖关系图。

### 阶段 6：成本估算

以明确的区间和假设估算总合规成本：

- **法律**：外部律师、监管咨询、意见书、诉讼准备金
- **技术**：系统修改、安全措施、API 开发、SBOM 工具
- **人员**：合规人员编制、培训、持续监控
- **认证**：第三方评估、审计、公告机构费用
- **机会成本**：延迟市场进入、功能限制、法域豁免

用区间，而非点估计。假设可见。对主要驱动因素进行敏感性分析。

## 输出格式

根据受众和用例选择。

### 执行摘要（1-2 页）

供董事会或高管层阅读。

- 适用法规一览
- 首要风险和冲突
- 五项优先行动
- 总合规成本估算（含区间）
- 带继续/停止门禁的推荐时间线

### 详细分析（10-30 页）

供法律和合规团队阅读。

- 带理由的范围确定
- 逐法规义务映射
- 带分类的重叠和冲突分析
- 优先排序的义务列表
- 整合时间线
- 带假设的成本明细
- 风险缓解和未决问题

### 实施路线图（可视化）

供项目管理使用。

- 按法规颜色编码的时间线图
- 依赖关系可见
- 关键点标注资源需求
- 里程碑和门禁决策

### 合规矩阵（电子表格）

供运营跟踪使用。

- 每义务一行
- 列：法规、条文、要求、截止日期、优先级、成本、负责人、状态、证据
- 可筛选和可排序
- 进度跟踪能力

## 典型工作流

1. **受理**。收集产品描述、技术架构、处理活动、目标市场、实体概况。
2. **研究**。核实每个适用法规的现行文本。注意近期修正案、待定授权法案、国家实施。
3. **界定范围**。系统应用纳入标准。记录理由。处理边界情况。
4. **提取**。构建每个法规的义务映射，条文级引用。
5. **分类**。对所有重要的两两交互应用交互分类。
6. **排序**。构建优先级矩阵。对照时间线和资源约束进行压力测试。
7. **估算**。成本和时间线。带假设的区间。
8. **产出**。选择输出格式。撰写。

## 冲突解决层级

当法规冲突时，按顺序应用：

1. **特别法**：行业特定优先于一般。金融实体的 DORA 优先于 NIS2。医疗器械 AI 的 MDR 优先于 AI 法案（MDR 处理特定风险处）。
2. **更严格标准**：当两者累积适用时，满足更高标准。同时符合重大事件的个人数据泄露，NIS2 的 24 小时早期预警优于 GDPR 的 72 小时。
3. **累积合规**：当两者既非特别法也非明显更严格时，同时满足两者。AI 互联产品的 CRA 和 AI 法案。
4. **过渡条款**：检查特定日期前投放市场的产品是否有祖父条款、分阶段适用或豁免。
5. **监管机构指引**：查阅欧委会指引、EDPB 意见、ENISA 出版物、国家主管机构立场。
6. **正式法律意见**：对于新颖或模糊的情况，从相关法域的合格律师处获取书面意见。记录推理过程。

## 常见交互模式

最常见的重叠情景的详细分析见 `references/regulation-interactions.md`，包括：

- GDPR 与数据法案（数据访问、可携性）
- AI 法案与 GDPR（自动化决策、数据治理）
- CRA 与 AI 法案（产品安全、漏洞处理）
- NIS2 与 DORA（事件报告、第三方风险、金融服务）
- GDPR 与 NIS2（安全措施、泄露通知时间线）
- 数据法案与 CRA（互联产品要求、API 安全）
- DSA 与 DMA（守门人的分层平台义务）
- AI 法案与行业法规（医疗器械、汽车、金融服务）

## 法规快速参考

此处覆盖的核心欧盟数字法规（GDPR、数据法案、AI 法案、CRA、NIS2、DORA、DMA、DSA、ePrivacy）的简明概况（范围、关键截止日期、主要义务和处罚区间）见 `references/regulation-profiles.md`。概况是参考资料，在约束性语境中使用前必须对照现行主要来源核实。

## 行业模板

值得预先思考的常见组合：

- **物联网产品制造商**：GDPR + 数据法案 + CRA + AI 法案（如板载 AI 系统）
- **云或 SaaS 服务商**：GDPR + 数据法案 + NIS2 + CRA（软件）
- **金融平台**：GDPR + DORA + AI 法案（如高风险 AI）+ NIS2（金融特定 ICT 由 DORA 优先）
- **医疗保健应用**：GDPR + MDR 或 IVDR + AI 法案（如医疗 AI）
- **大型在线平台**：GDPR + DSA + DMA（如守门人）+ ePrivacy
- **关键基础设施运营者**：GDPR + NIS2 + CER + 行业法规

## 质量检查清单

交付前：

- [ ] 范围内的每个法规都有记录的纳入理由
- [ ] 每个法规的现行版本已对照主要来源核实
- [ ] 全程条文级引用
- [ ] 所有实质性重叠已用分类分类
- [ ] 冲突被明确标记，而非埋在中性叙述中
- [ ] 优先级矩阵已堆叠排序；无"一切皆为优先级 1"
- [ ] 时间线显示每个实质性截止日期
- [ ] 成本估算包含区间和具名假设
- [ ] 建议具体且可操作
- [ ] 执行摘要捕捉最重要的五个要点
- [ ] 已知缺口和未决问题被列出，而非隐藏

## 局限性

本分析反映截至输出日期已生效的法规和公开可用的指引。需注意三个常见的漂移来源：

- **授权和实施法案**：许多欧盟法规的授权法案独立且晚于主法规的时间线通过
- **国家实施**：指令和一些法规给成员国留下裁量空间；国家措施随时间从欧盟框架漂移
- **执法实践**：监管机构通过指引和执法发展解释；今天合规的明天可能被重新谈判

在交付物中醒目地说明这些局限性。至少推荐年度刷新，并在实质性监管变化时触发更新。

## 输出位置

使用清晰的命名约定：

```
cross-regulatory-analysis-[产品或客户]-[YYYY-MM-DD].docx
compliance-matrix-[产品或客户]-[YYYY-MM-DD].xlsx
```

## 免责声明

本分析是战略规划工具，不是法律意见。法规交互对事实敏感；具体问题需要适用法域的合格律师。监管实践和指引不断发展；此处引用的日期和阈值在约束性语境中使用前必须重新核实。