合规指南
读完本文后，您将清楚了解 DORA 与 AI Act 在哪些方面重叠、在哪些方面分化，以及如何构建一个统一的合规计划来同时满足两者，而不是运行两个相互重复的计划。
银行内部常见的一种情况是：一个 DORA 团队和一个 AI 治理团队彼此从未沟通过，却各自把同一批 AI 系统视为自己单独负责的合规问题。
这种重复成本高昂，而且完全可以避免。
Digital Operational Resilience Act（DORA）自 2025 年 1 月起适用，监管金融行业范围内的 ICT 风险管理。EU AI Act 在 Digital Omnibus 延期后，其针对独立系统的高风险义务自 2027 年 12 月 2 日起适用，监管用于决策的 AI 系统。对于任何运行 AI 的金融机构，也就是 2026 年几乎所有金融机构，这两部法规会同时适用于同一批系统。
您的 AI 驱动信用评分模型？它既是 DORA 下的 ICT 服务，也是 AI Act 下的高风险 AI 系统。您的欺诈检测引擎？在 DORA 下是 ICT 资产，在 AI Act 下也可能是高风险 AI。您的算法交易平台？同时涉及 DORA、AI Act，以及 MiFID II。为每部法规分别建立合规计划，就像聘请两位建筑师设计同一栋楼，却不告诉他们彼此的存在。最终您会得到相互矛盾的方案、缺口，以及一张让您怀疑职业选择的账单。
EU AI Act 与 DORA 的五个重叠区域
对于金融机构，EU AI Act 与 DORA 重叠的五个区域包括：
- 风险评估：一种方法论可以同时支持第 9 条（AI Act）和第 6 条（DORA）
- 文档：使用共享的技术文件，而不是两套并行材料
- 测试：在同一个日历上安排韧性测试和合规性测试
- 事件报告：一个受理入口，两套监管时钟
- 第三方管理：AI 供应商纳入与 ICT 服务提供商相同的登记册
下面我会梳理 DORA 与 AI Act 对同一批 AI 系统施加重叠要求的具体领域。这些正是采用统一方法最能节省工作量的区域。先说明一个前提，因为这类节省往往会被夸大。重叠在输入层面是真实存在的：同样的研讨会、同样的清单、同一批人在会议室里。但在输出层面，重叠要薄得多，因为 DORA 风险评估和 Annex IV 文件由不同监管机构阅读，回答的是不同问题。可以共享工作过程，但交付物必须保持区分。
区域 1：风险评估
DORA（第 6 条）要求金融实体建立 ICT 风险管理框架，涵盖识别、保护、检测、响应、恢复和学习流程。每个 ICT 系统，包括 AI 系统，都必须进行风险评估。
AI Act（第 9 条）要求为每个高风险 AI 系统建立风险管理体系，涵盖已知和可合理预见风险的识别、风险估计、风险评价以及缓解措施。
重叠点：两者都要求您评估同一系统的风险。DORA 关注运营韧性风险（可用性、完整性、连续性）。AI Act 关注 AI 特定风险（偏见、准确性、稳健性、公平性）。采用一个包含两个模块的统一风险评估（ICT 韧性和 AI 特定风险），即可同时满足两者要求，无需重复进行双方都要求的利益相关方访谈、资产识别和威胁建模。
区域 2：文档化
DORA（第 8-9 条）要求建立 ICT 资产登记册、记录 ICT 风险管理框架、业务连续性计划和沟通策略。
AI Act（附件 IV）要求技术文档涵盖系统描述、开发流程、训练数据、测试方法、性能指标、风险缓解以及人工监督措施。
重叠点：您的 AI 系统会同时出现在两套文档中。与其维护两份独立记录，不如创建分层文档架构。ICT 资产登记册中的系统记录链接到 AI Act 技术文档。风险评估同时标记到 DORA 和 AI Act 要求。业务连续性计划引用 AI 特定的后备程序。一个系统，一套文档族，两类监管输出。
区域 3：测试
DORA（第 24-27 条）强制要求数字运营韧性测试：漏洞评估、渗透测试、基于场景的测试，以及面向指定实体的 TLPT。
AI Act（第 9(5-7) 条）要求在部署前和整个生命周期内进行测试：准确性测试、稳健性测试、偏见测试、真实环境条件下的性能测试。
重叠点：设计一套集成测试方案。您的渗透测试可以包含对抗性 ML 攻击场景（同时测试 ICT 韧性和 AI 稳健性）。您的基于场景的测试可以包含组合故障模式：系统中断 + 模型退化 + 数据质量问题。一个测试周期，两套监管证据。这里需要提醒一点。执行渗透测试的人和测试模型偏见的人通常是不同专家，来自不同供应商，并由不同预算出资。协调日程很容易。产出让各监管机构都能视为连贯证据的报告，需要有意设计，并且必须在界定测试范围时就确定，因为在撰写报告阶段再补做通常行不通。
区域 4：事件报告
DORA（第 19 条）要求向金融监管机构报告重大 ICT 事件：在将事件分类为重大事件后 4 小时内（且在知悉后 24 小时内）提交初始通知，在 72 小时内提交中期报告，并在 1 个月内提交最终报告。
AI Act（第 73 条）要求高风险 AI 的服务提供商向市场监督机构报告严重事件。
重叠点：单一事件可能同时触发两项要求。您的 AI 欺诈检测系统宕机（DORA 重大 ICT 事件），同时在降级模式下产生歧视性输出（AI Act 严重事件）。您需要一个双轨制的事件分类，同时评估 DORA 严重性标准和 AI Act 严重性标准，并将通知分别路由至金融监管机构和市场监督机构。在五个区域中，这正是合并流程真正体现价值的地方，同时也最可能沦为一张无人演练过的图。DORA 的时钟会在 AI 问题仍在争论时开始计时，因此要提前决定先后顺序：先按 DORA 分类并提交，再处理 AI 分支。在真实事件发生时才发现两个团队对由谁宣布什么事项存在分歧，是最糟糕的时刻。
区域 5：第三方管理
DORA（第 28-30 条）要求开展详细的第三方 ICT 风险管理：信息登记册、合同要求（审计权、退出策略、数据位置）、尽职调查、集中度风险评估。
AI Act（第 16 条和第 26 条）对 AI 服务提供商和部署者施加义务，包括针对第三方 AI 系统的供应商尽职调查、获取技术文档以及监测能力。
重叠点：当您从供应商购买 AI 系统时，该供应商既是 ICT 第三方服务提供商（DORA），也是 AI 服务提供商（AI Act）。您的供应商管理框架必须同时覆盖两者：DORA 的合同要求（退出计划、审计权）以及 AI Act 的部署者义务（获取文档、具备监测偏见的能力）。一份供应商合同、一段关系、两套监管期望。
它们不重叠的地方（以及您不能走捷径的地方）
统一方法可以在重叠部分节省工作量。但每项法规中确实存在对方完全没有涉及的独特要求。如果您认为“只要我符合 DORA，就一定也符合 AI Act”，这些领域就会让您陷入麻烦。
在仅属于 AI Act 的事项中，应从偏见和公平性测试开始。它需要您可能未被允许持有的数据、您的模型风险团队可能不具备的统计判断能力，以及一个只能由业务部门作出的决定：对您的产品而言，公平究竟意味着什么。其他三项是可以在一个季度内设计出来的流程。而这一项，是在任何流程值得写下之前就必须先进行的讨论。
仅 DORA 适用的要求
信息登记册
所有 ICT 第三方关系的结构化登记册，包含 ESA 实体代码、合同关联和职能映射。欧盟《人工智能法案》（EU AI Act）没有对应要求。
xBRL-CSV 报告
监管报送所要求的特定结构化数据格式。纯 DORA 要求，不涉及 EU AI Act。
TLPT
面向指定实体的威胁导向渗透测试。TIBER-EU 方法论。完全独立的要求。
集中度风险
评估对单一 ICT 服务提供商的过度依赖。这是 DORA 特有的关注点，AI Act 并未涉及。
仅 AI Act 适用的要求
合格评定
验证是否符合 EU AI Act 要求的正式流程。DORA 采用监管审查，而非合格评定。
基本权利影响评估
某些高风险 AI 部署方需要开展该评估（Art. 27）。DORA 不涉及人权维度。
算法可解释性
高风险 AI 的输出必须能由人工监督人员理解。DORA 不关注可解释性，在 DORA 下黑箱可以接受，但在 AI Act 下不可以。
偏见与公平性测试
针对歧视性输出开展系统性测试。这是 AI Act 的核心要求（Art. 10），DORA 没有对应要求。
真实场景：实际会如何发生
理论只能带您走到一定程度。下面看看双重监管问题在实践中如何出现。
场景：中型银行的 AI 信用评分
该银行使用第三方 AI 信用评分模型，并基于自身数据进行重新训练，同时设置自定义决策阈值。
DORA 义务：该供应商需纳入信息登记册。合同需要包含符合 DORA 的条款（审计权、退出策略、数据位置）。该系统必须纳入 ICT 资产登记册。业务连续性计划必须覆盖评分系统不可用时的应对安排。影响该系统的事件必须按照 DORA RTS 标准进行分类。
AI Act 义务：由于银行对模型进行了重大修改（基于自身数据重新训练、自定义阈值），其很可能被视为提供者。它们需要开展合格评定、准备 Annex IV 技术文档、进行偏见测试、建立人工监督机制，并完成 EU 数据库注册。如果模型系统性地低估某些人口群体的评分，这就构成 AI Act 违规。
统一方法：开展一次风险评估，覆盖 ICT 韧性和 AI 特定模块。准备一套文档包，同时满足 DORA 的资产登记册要求和 AI Act 的 Annex IV 要求。建立一个供应商管理框架，覆盖 DORA 合同条款以及 AI Act 部署方/提供者义务。实施一个测试计划，覆盖韧性、准确性和公平性。
场景：AI 驱动的保险核保
一家保险公司使用 AI 根据风险因素为健康保险保单定价。
DORA 义务：纳入 ICT 资产登记册；如果模型外包，则需要第三方风险管理 (TPRM)；开展运营韧性测试；针对系统故障进行事件报告。
EU AI Act 义务：Annex III 明确将保险定价列为高风险。需要进行合格评定。必须证明定价结果不存在歧视。必须向投保人提供有意义的说明，解释其保费如何确定。可能适用基本权利影响评估。对个体核保决策需要人工监督。
关键冲突点：如果 AI 模型对某些人口群体产生歧视性定价，保险公司将面临 EU AI Act 处罚（最高 €15M 或营业额的 3%）以及保险监管机构可能采取的监管行动。两个监管机构，一个问题，同时产生后果。
场景：双重事件
一家银行的 AI 欺诈检测系统发生数据管道故障。中断期间，系统使用过期数据运行，并开始以不成比例的高频率标记来自某些地理区域的交易。
DORA 事件：系统中断达到重大 ICT 事件阈值。需在 4 小时内向金融监管机构进行初始通知。72 小时内提交中期报告。1 个月内完成根因分析并提交最终报告。
EU AI Act 事件：这种歧视性标记构成第 73 条下的严重事件。需通知市场监督机构。记录对受影响个人的影响。
经验教训：一个事件，两份事件报告，两个监管机构，两套时间线，两组整改预期。您的事件响应手册必须能够处理这种双轨场景，否则就会遗漏一项报告义务。
如何构建统一项目
问题已经说够了。现在谈解决方案。对于任何同时需要满足 DORA 和 EU AI Act 合规的金融机构，我建议采用以下方法。
第 1 步：单一清单。维护一份涵盖所有 ICT 资产和 AI 系统的清单。每个条目都应同时标注其 DORA 分类（是否属于关键或重要职能？是否由第三方提供？）以及 EU AI Act 分类（是否为高风险？谁是提供者？谁是部署者？）。这将成为您的单一事实来源。
第 2 步：合并风险评估。对每个 AI 系统开展一次包含两个模块的风险评估。模块 1 覆盖 DORA ICT 韧性风险（可用性、完整性、恢复、集中度）。模块 2 覆盖 EU AI Act 风险（偏见、准确性、稳健性、可解释性、数据质量）。同一批利益相关方，同一次研讨会，两个输出。
第 3 步：集成测试。设计能够同时为两项法规生成证据的测试计划。包含对抗性 ML 攻击场景的渗透测试，同时覆盖 DORA 第 24 条和 EU AI Act 第 15 条。模拟系统故障并伴随模型退化的场景测试，同时覆盖 DORA 韧性测试和 EU AI Act 稳健性测试。
第 4 步：双轨事件响应。建立一套事件响应手册，对每一个 AI 相关事件，同时评估 DORA 严重性和 EU AI Act 严重性，识别两个通知对象，并跟踪两条整改流程。
第 5 步：统一治理。不要设立一个“DORA 委员会”和一个“AI 伦理委员会”，却让它们彼此从不沟通。应建立单一治理结构，将 ICT 风险与 AI 治理放在一起讨论。董事会需要同时理解两者，DORA 第 5 条要求董事会层面监督 ICT 风险，EU AI Act 第 4 条要求领导层具备 AI 素养。第 1 步到第 4 步是工作。第 5 步是组织政治，它决定其余所有工作能否真正协同。合并两个委员会意味着其中一个将不再存在，并且有人会失去一个固定议程项，因此可以预期阻力会以担心专业聚焦不足的形式出现。应在董事会层面一次性解决，而不是每个季度反复争论。
第 6 步：使用理解交叉关系的平台。这正是工具发挥作用的地方。只支持 DORA 或只支持 AI 治理的平台，会迫使您维护并行系统。能够映射 DORA 与 EU AI Act 要求之间关系的多框架平台，可以让您看到一项控制措施在何处同时满足两者，以及哪里仍存在差距。Venvera 同时支持 DORA 和欧盟《人工智能法案》（EU AI Act），并内置跨框架映射，因此您为一项控制措施提供一次证据，即可同时计入两者。
不要再把它们当作彼此独立的问题
能够妥善应对这一问题的金融机构，都会认识到一个根本事实：欧盟《数字运营韧性法案》（DORA）和欧盟《人工智能法案》（EU AI Act）并不是两个相互独立的合规问题。它们只是观察同一运营现实的两个视角。
金融机构中的每一个 AI 系统，同时也是一个 ICT 系统。针对 AI 驱动服务开展的每一次 ICT 风险评估，都必须考虑 AI 特有风险。每一个第三方 AI 供应商，也都是第三方 ICT 服务提供商。这种重叠并非偶然，而是结构性的。
建立统一方案的机构，共享风险评估、集成测试、合并文档、双轨事件响应，将花费更少、推进更快，并面临更少的监管审计发现。继续维持并行孤岛的机构，则会用双倍工作换来一半的保证。
DORA 团队和 AI 治理团队需要彼此沟通。最好昨天就已经开始。
常见问题
金融机构是否必须同时遵守 DORA 和 EU AI Act？
通常是的。如果您运行信用评分、保险定价或欺诈检测等高风险 AI，这两套制度会同时适用于同一系统：DORA 将该系统作为 ICT 加以监管，EU AI Act 将其作为 AI 加以监管。二者不能相互替代，任何一方也不会免除您遵守另一方的义务。
EU AI Act 的高风险义务何时适用于金融机构？
在理事会于 2026 年 6 月 29 日通过 AI 数字综合法案之后，附件 III 下的独立高风险系统，包括信用评分和保险定价，自 2027 年 12 月 2 日起适用。第 50 条透明度义务仍自 2026 年 8 月 2 日起适用，DORA 已自 2025 年 1 月 17 日起适用。
遵守 DORA 是否已经覆盖 EU AI Act？
不是。两者在风险评估、文档、测试、事件报告和第三方管理方面存在重叠，但 EU AI Act 还增加了合格评定、基本权利影响评估、可解释性，以及偏见与公平性测试，这些并非 DORA 所涵盖。符合 DORA 要求只是一个先发基础。
当 AI 系统发生故障时，适用哪些事件报告规则？
可能两者都适用。重大 ICT 中断会触发 DORA 第 19 条向金融监管机构报告的要求（4 小时、72 小时、一个月）。如果同一事件还造成严重 AI 事件，EU AI Act 第 73 条要求向市场监督机构报告。一个事件可能同时启动两个计时器，因此您的处置手册需要双轨机制。
一个合规方案能否同时覆盖二者？
对于重叠部分，可以。统一的 AI 与 ICT 清单、合并的风险评估、集成测试以及双轨事件响应，使您能够通过一个方案同时满足二者要求，并将框架特定工作保留给二者确实存在差异的领域。
主要来源
本指南基于两项法律文件和 EU 官方指南：Regulation (EU) 2022/2554 (DORA)；EU AI Act, Regulation (EU) 2024/1689（第 9、10、11、13、14、15、26、27、43、50 和 73 条，以及附件 III 和 IV）；以及欧洲理事会最终通过 AI 数字综合法案（2026 年 6 月 29 日），该法案推迟了高风险相关日期。在依赖某个具体日期之前，请确认现行文本。
统一管理您的 DORA 与 AI Act 合规
Venvera 为金融机构管理跨法规合规，涵盖 DORA、EU AI Act、GDPR、NIS2 等，并内置跨框架映射。起价 €399/月，托管于阿姆斯特丹。
预约演示 →最后审核：2026 年 7 月。DORA 和欧盟《人工智能法案》（EU AI Act）均受持续出台的授权法案、监管技术标准和监管指导影响。请关注 ESAs、European AI Office 以及您所在国家主管机关的更新。
同时推进两者也是成本更低的路径；请参阅EU AI Act 合规成本，了解重叠部分如何带来回报。
