EU AI Act Annex IV × MDR Annex II技术文件映射：AI SaMD如何避免两套文档重复

本文只解决什么 / 不解决什么

这篇文章只解决一件事：你的AI SaMD按MDR走Class IIa及以上、按EU AI Act又是Article 6下的"高风险AI系统"——怎么把两个法规要求的技术文件合并成一份NB能审、不重复劳动、不互相打架的single technical file。

不解决：AI Act整体合规策略、MDR分类（Rule 11）、IEC 62304软件生命周期。如果还在做基础合规规划，先看站内的EU AI Act医疗器械合规指南、MDCG 2025-6合规时间表和MDR技术文档指南。

合并的法律基础是AI Act Article 11(2)：高风险AI系统如果同时受其他欧盟法规（如MDR/IVDR）覆盖，技术文档可以包含一组合并的信息，前提是该信息满足两个法规的全部要求。这句话是中国SaMD企业能省下大半年返工时间的关键——但它不是默认操作，要主动设计文档结构。

双轨义务的本质：附加而非替代

先说清楚一个常见误区：AI Act不替代MDR，是叠加在MDR之上的。NB审你的技术文件时是"双重审"——一遍按MDR Annex II/III、一遍按AI Act Annex IV。两套要求里有大量重叠（risk management、testing、PMS等），也有AI Act独有的（data governance、bias、human oversight、logging等）。

下面这张主映射表是双轨技术文件的核心。第一列是AI Act Annex IV的9个法定章节（按2024/1689条文顺序），第二列是MDR Annex II对应章节，第三列是合并后的single TD建议命名，第四列是高风险缺口——AI Act要求但MDR里没有现成对应的部分。

AI Act Annex IV 章节	MDR Annex II 对应	合并TD建议章节名	AI Act独有要求（高风险缺口）
1. General description of AI system	§1 Device description and specification	TD §1 Device & AI System Description	必须明确标注AI/ML组件、版本号、训练数据快照ID
2. Detailed description of elements & development	§2 Reference to previous & similar generations	TD §2 Design History	必须包含设计选择的rationale、训练数据划分（train/val/test）和优化目标函数
3. Monitoring, functioning and control	§6.1 Pre-clinical & clinical data	TD §3 Performance Testing	必须含bias跨子组（年龄、性别、种族）的性能切片
4. Risk management system	§3 Design and manufacturing information; §5 Risk management	TD §4 Integrated Risk Management	ISO 14971之外要识别"AI-specific harms"（distribution shift、adversarial input、自动化偏倚）
5. Description of changes (lifecycle)	§3.1(d) Design changes; §6.2 PMS	TD §5 Lifecycle & Change Control	PCCP要纳入；模型再训练/微调要有触发与回退机制
6. Standards and harmonised standards applied	§4 GSPR + Standards list	TD §6 Standards Applied	ISO/IEC 42001、ISO/IEC TR 24028、ISO/IEC 5259（数据质量）等
7. EU Declaration of Conformity (DoC)	Annex IV DoC	TD §7 DoC	单一DoC同时声明MDR + AI Act符合性（Article 47 AI Act）
8. Description of post-market monitoring	§6.2 PMS plan, PSUR, PMCF	TD §8 Post-Market Monitoring	drift monitoring计划；real-world performance dashboards而非PDF年报
9. List of decisions/declarations and other documents	§7 Verification & validation	TD §9 Records	含conformity assessment记录；FRIA（fundamental rights impact assessment）（如适用）

这张表的实务意义：你不需要建立两套独立目录，只要把上面的9个章节作为顶层目录，每一章里同时承载MDR和AI Act的内容。NB会读到一份连续的技术文件——这是Article 11(2)允许的"一组合并信息"。

风险管理：最容易塌陷的合并区

AI SaMD的风险管理是中国企业返工率最高的章节，原因是ISO 14971的标准框架不能完整覆盖AI独有的伤害类型。AI Act Article 9要求的"AI-specific risk management system"和ISO 14971的关系是包含-扩展关系。

下面是合并TD §4里建议的内容结构和典型条目：

子章节	ISO 14971覆盖	AI Act Article 9额外要求	典型条目示例
4.1 Hazard identification	是	增加"AI-specific hazards"	模型在中国人群外推性下降；训练数据过时导致distribution shift
4.2 Risk estimation	是	增加severity分布在不同子组中的差异	在65岁以上女性子组中假阴性率升高30%
4.3 Risk control measures	是	增加"human oversight design"作为RCM	输出置信度低于0.6时强制要求医生确认
4.4 Residual risk evaluation	是	增加"distribution shift monitoring"作为残余风险接受条件	接受残余风险的前提是部署monitoring dashboard
4.5 Risk-benefit analysis	是	增加对自动化偏倚（automation bias）的考量	评估临床医生过度依赖AI输出的风险
4.6 Production & post-production information	是	增加model drift事件的反馈机制	drift超阈值后回滚到previous model snapshot

中国SaMD企业写ISO 14971时常用的"硬件风险"思维要扩展。比如把"misclassification"识别为hazard还不够，要拆成：misclassification导致漏诊的clinical harm + AI在某子组中性能下降导致的equity harm + 用户对AI过度依赖导致的automation harm。这三类harm的RCM完全不同。

Data Governance：MDR最薄的一层

MDR Annex II对训练数据的要求基本只有"intended purpose下的数据来源"。AI Act Article 10对数据治理的要求详细得多——这是合并TD里几乎完全additive的章节。

合并TD §3 Performance Testing 的子章节建议结构：

TD §3 Performance Testing
├── §3.1 Dataset Description
│   ├── Training set characteristics (size, demographics, sources)
│   ├── Validation set characteristics
│   ├── Test set characteristics
│   └── Datasets independence justification
├── §3.2 Data Governance Process
│   ├── Data acquisition protocols
│   ├── Annotation/labelling procedures and inter-rater reliability
│   ├── Data quality assessment (completeness, errors, biases)
│   └── Data preparation pipeline (cleaning, augmentation, splits)
├── §3.3 Performance Metrics
│   ├── Overall performance (sensitivity, specificity, AUC)
│   ├── Subgroup performance (by age, sex, ethnicity, geography)
│   └── Failure mode analysis
├── §3.4 Bias Assessment
│   ├── Sources of potential bias
│   ├── Bias detection methodology
│   └── Bias mitigation measures
└── §3.5 Robustness Testing
    ├── Out-of-distribution testing
    ├── Adversarial testing
    └── Stress testing scenarios

中国SaMD企业准备这一章时，最容易踩的雷是子组性能切片。AI Act Article 10要求"sufficiently representative"——如果训练数据基本来自中国人群，要在TD里明确写：（1）人群代表性的限制；（2）针对欧洲部署的pre-market validation方案；（3）post-market对欧洲患者的drift monitoring设计。NB不会接受"等到欧洲销售再监控"——他们要看到上市前的子组验证证据。

Human Oversight：MDR的usability规则不够

MDR用IEC 62366-1管usability，但AI Act Article 14的human oversight是更高的要求：用户必须能够"override, disregard, or reverse"AI输出，且系统设计不能削弱这种能力。

合并TD §4.3里的human oversight设计举证清单：

设计要素	IEC 62366评估	AI Act Article 14额外要求
输出可解释性	use error分析	必须有"sufficient understanding"机制让用户理解模型的能力和局限
用户干预方式	任务分析	必须设计"stop button"或等效干预机制
自动化偏倚防护	部分覆盖	必须主动减轻automation bias（如不强调"AI推荐"措辞、强制showing confidence intervals）
异常状态识别	use error分析	用户必须能识别"system is malfunctioning or producing unreliable outputs"
训练材料	IFU、培训	用户培训内容必须包含AI系统的能力边界

这部分对中国SaMD企业的最大挑战是重新设计UI/UX而不是改文档。如果产品现在的UI显示"AI诊断结果：阳性，置信度91%"这样的形式，可能要改成显示置信区间、显示训练数据范围警告、提供"override"按钮——这些是设计层面的修改，不是文档层面的填写。

Logging：从无到有的章节

MDR对logging的要求散落在IEC 62304里（事件日志、错误日志），AI Act Article 12把这一项明文化为独立义务：

高风险AI系统必须自动记录事件日志贯穿系统生命周期
日志必须支持post-market monitoring和traceability
日志的level要"sufficient to identify situations resulting in significant modification or in risk increase"
日志要保留至少6个月（最低保留期限）

合并TD §8 Post-Market Monitoring的logging子章节要回答以下问题：

问题	必含内容
记录什么	输入特征统计、模型版本ID、输出与置信度、用户override行为、错误状态
记录到哪	设备本地+云端备份；日志schema版本控制
保留多久	至少6个月（AI Act），但建议5年（与MDR PMS对齐）
谁能访问	RBAC（角色权限）；NB审核访问权限
如何分析	自动化drift detection；月度dashboard回顾
隐私如何保障	GDPR合规的pseudonymization；访问审计

Logging设计有两个常被忽视的实务点：第一是版本号要写到日志条目里——事件发生时正在运行的model version是哪一个，没这一字段后续drift分析就做不了；第二是override行为要明确记录——不只是用户点击了"override"按钮，还要记录上下文（哪个case、什么类型的输出、医生最终决策），这是human oversight effectiveness的证据。

PMS：从"年度PSUR"到"实时dashboard"

MDR的PMS（Article 83-86）要求年度PSUR/PMCF；AI Act Article 17的"post-market monitoring system"要求continuous monitoring。两者合并后的PMS plan必须同时满足。

合并TD §8 PMS Plan的核心组件：

TD §8 Post-Market Monitoring Plan
├── §8.1 Performance Monitoring
│   ├── Real-world clinical performance KPIs
│   ├── Subgroup performance trends
│   └── Drift detection thresholds and alerts
├── §8.2 Vigilance
│   ├── Incident reporting workflow (MDR Art. 87)
│   ├── Trend reporting (MDR Art. 88) 
│   └── Serious incident escalation (AI Act Art. 73)
├── §8.3 PMCF
│   ├── PMCF plan and protocols
│   └── PMCF evaluation report
├── §8.4 PSUR / Post-Market Performance Report
│   ├── Annual PSUR (MDR)
│   └── Combined with AI Act post-market monitoring summary
├── §8.5 Logging Analysis
│   ├── Log review cadence
│   ├── Anomaly detection methodology
│   └── Linkage to CAPA
└── §8.6 Model Update Triggers (PCCP linkage)
    ├── Performance degradation triggers
    ├── Distribution shift triggers
    └── Retraining decision tree

中国SaMD企业最常错的是§8.5 Logging Analysis：很多人把日志当成"出了事再查"的资源，AI Act要求把日志当成"持续输入PMS的数据流"。合规设计是建立月度log review cadence、自动化的anomaly detection、log异常→CAPA的linkage。

协调时间表

下面是2026-2027年的合规时间锚点，中国SaMD企业要对照这个表做technical file升级排期：

日期	事件	对TD的影响
2026年8月2日	AI Act对Annex III独立HRAIS适用	不直接覆盖医疗器械（医疗器械走Article 6(1)）
2026年5月28日起	EUDAMED四个核心模块的透明度义务生效	DoC上传要同步AI Act相关声明字段
2027年8月2日	AI Act Article 6(1)对AI医疗器械正式适用	新放上市的AI医疗器械必须含合并TD
2027年8月2日之后的significant change	legacy AI医疗器械若发生重大变更触发AI Act义务	在重大变更前完成TD升级

按MDCG 2025-6和AI Act Article 113的解释：在2027/8/2之前已经放上市的AI医疗器械不会自动落入AI Act高风险义务，但任何2027/8/2之后的重大设计变更会立即触发AI Act完整义务。这给legacy产品留了一条"不动就免"的窗口，但实际上新一代CE续证、PMS驱动的模型再训练几乎都构成significant change。

注意EU Digital Omnibus提案讨论中的延期议题——但截至2026年5月，原始时间表仍是有效计划基础。中国企业不应押注延期，按2027/8/2节点准备最稳妥。

常见失败模式

失败模式1：把AI Act章节"附在MDR TD后面" 后果：NB审到第二遍时发现AI-specific内容散在MDR章节里没体现到，要求重排。补救：从一开始就用合并的9章结构（见主映射表）。

失败模式2：data governance写成"我们用了10万张图像训练" 后果：CHMP-style质询要求人群分布、annotation流程、bias评估，全要补。补救：按§3.1-§3.5的子结构写，数据集描述要可量化（年龄分布、性别比例、地区分布、扫描设备分布）。

失败模式3：把PCCP当成"以后再说" 后果：模型再训练时被NB认定为significant change，重新走conformity assessment。补救：合并TD §5里就要把PCCP写进去，明确"什么变更在PCCP内、什么变更触发重新认证"。

失败模式4：DoC只声明MDR符合性 后果：market surveillance检查时发现DoC不全，违反AI Act Article 47。补救：单一DoC同时引用MDR (EU) 2017/745和AI Act (EU) 2024/1689，明确两份法规的符合性声明。

失败模式5：human oversight只在TD里写，UI没改 后果：NB on-site审核或远程演示时发现UI没有override机制。补救：human oversight是设计层面的要求，要在产品开发周期里就设计；TD只是记录证据。

站内延伸阅读

参考来源

EU AI Act (Regulation (EU) 2024/1689) – 全文，Article 11、Annex IV
MDR (Regulation (EU) 2017/745) – Annex II/III
MDCG 2025-6 Guidance on the integration of MDR/IVDR with AI Act for medical devices
European Commission Implementing Regulation (Draft) on Notified Body QMS for MDR/IVDR (Dec 2025)
ISO/IEC 42001:2023 AI Management System Standard
ISO/IEC TR 24028 Trustworthiness in AI

免责声明：本文仅供医药器械行业从业者参考，不构成法律或注册申报意见。AI Act和MDR的合并实施细节仍在通过MDCG指南和Commission Implementing Acts持续演化，具体合规策略应与公告机构和专业法规顾问就个案确认。