2024年8月1日,欧盟《人工智能法案》(Regulation (EU) 2024/1689,以下简称EU AI Act)正式生效,标志着全球首部全面规范人工智能系统的横向法律诞生。对于正在或计划进入欧盟市场的中国AI医疗器械企业而言,这不仅仅是"多了一个法规"——它从根本上改变了SaMD(Software as a Medical Device)的合规架构,在既有的MDR/IVDR体系之上叠加了一整套AI特定要求,形成前所未有的双重合规框架。
本文是本站SaMD/人工智能医疗器械全球注册路径指南的深度补充,专门聚焦EU AI Act这一全新监管层,系统解析其对医疗器械AI系统的分类逻辑、合规要求以及与MDR/IVDR的交叉关系,并为中国企业提供切实可行的应对策略。
一、EU AI Act概述:全球首部AI立法
1.1 立法背景与核心目标
EU AI Act是欧盟委员会于2021年4月首次提出、历经三年立法博弈后于2024年最终通过的里程碑式法规。其核心目标可以概括为三个层面:
| 目标层面 | 具体内容 |
|---|---|
| 安全性 | 确保投放欧盟市场的AI系统是安全的,尊重基本权利 |
| 法律确定性 | 为AI开发者和部署者提供清晰、统一的合规框架 |
| 创新促进 | 在保障安全的同时,避免过度监管阻碍AI技术创新 |
EU AI Act采用基于风险的分级监管(Risk-Based Approach)——与MDR对医疗器械的风险分级逻辑一脉相承,但关注的是AI系统本身的风险,而非器械的物理风险。这意味着一个AI驱动的SaMD产品将同时被两套风险分类体系所覆盖。
1.2 关键定义
理解EU AI Act的第一步是准确把握其核心定义(Article 3):
| 术语 | 定义 | 对SaMD的影响 |
|---|---|---|
| AI系统(AI System) | 设计为具有不同程度自主性运行的机器系统,在部署后可能表现出适应性,并从其接收的输入中推断如何生成输出(如预测、内容、建议或决策),以影响物理或虚拟环境 | 大多数AI/ML驱动的SaMD符合此定义 |
| 提供者(Provider) | 开发AI系统或通用AI模型并投放市场或投入使用的自然人或法人 | 中国SaMD制造商通常为"提供者" |
| 部署者(Deployer) | 在其权限下使用AI系统的自然人或法人(公共机构除外) | 欧盟医疗机构、诊所为"部署者" |
| 投放市场(Placing on the Market) | 首次在欧盟市场提供AI系统 | 与MDR的"placing on the market"一致 |
| 预期目的(Intended Purpose) | 提供者为AI系统预期的用途 | 与MDR的"intended purpose"对应 |
1.3 完整实施时间线
EU AI Act采用分阶段实施的方式,给予行业充分的过渡期:
| 日期 | 里程碑 | 对SaMD企业的影响 |
|---|---|---|
| 2024年8月1日 | EU AI Act正式生效 | 开始合规准备窗口期 |
| 2025年2月2日 | 禁止性AI实践(Title II)生效 | 确认SaMD不涉及被禁止的AI用途 |
| 2025年8月2日 | GPAI模型规则(Chapter V)生效;AI素养要求生效 | 使用GPT等GPAI模型的SaMD需关注 |
| 2026年8月2日 | 高风险AI系统完整要求(Chapter III Section 2)生效;透明度义务生效 | 核心合规截止日期:所有高风险AI SaMD必须满足全部要求 |
| 2027年8月2日 | 附件I中现有产品(已上市并已通过合格评定的产品)的过渡期结束 | 已在市场上的AI SaMD须完成合规升级 |
| 2030年8月2日 | 特定公共部门AI系统的过渡期结束 | 对商业SaMD影响有限 |
对于中国AI医疗器械企业而言,2026年8月2日是最关键的时间节点——自该日起,任何新投放欧盟市场的高风险AI SaMD都必须满足EU AI Act的全部要求。而对于已在市场上的产品,2027年8月2日前必须完成合规升级。
二、AI系统风险分类:四级金字塔
EU AI Act建立了一个四级风险分类体系,从最高风险的"禁止"到最低风险的"自愿准则",形成清晰的监管金字塔。
2.1 四级分类总览
| 风险等级 | 监管措施 | 占比估计 | 医疗器械中的典型场景 |
|---|---|---|---|
| 不可接受的风险(Unacceptable Risk) | 完全禁止 | <5% | 社会评分系统、操纵性AI(不适用于正规SaMD) |
| 高风险(High Risk) | 严格合规要求,需合格评定 | 约15-20% | 几乎所有AI驱动的SaMD(诊断AI、治疗决策AI等) |
| 有限风险(Limited Risk) | 透明度义务 | 约20-30% | 医疗咨询聊天机器人、患者交互AI |
| 最低/无风险(Minimal/No Risk) | 自愿行为准则 | 约50-60% | 医院管理软件、非临床健康提醒App |
2.2 禁止性AI实践(Title II, Article 5)
以下AI实践自2025年2月2日起在欧盟被完全禁止:
| 被禁止的AI实践 | 说明 | 与SaMD的关系 |
|---|---|---|
| 潜意识操纵 | 利用人类潜意识技术影响行为 | 正规SaMD不涉及 |
| 利用脆弱群体 | 利用年龄、残疾等脆弱性特征 | 需注意老年辅助AI的设计 |
| 社会评分 | 基于社会行为的分类评分系统 | 不适用 |
| 实时远程生物识别(执法用) | 公共场所的实时人脸识别 | 不适用于医疗场景 |
| 情绪推断(工作/教育) | 在工作场所或教育机构推断情绪 | 医疗场景中的情绪评估工具需审慎评估 |
| 无差别面部图像采集 | 从互联网或监控中大规模采集人脸 | 不适用 |
要点:虽然大多数SaMD不会触及禁止条款,但企业仍需正式完成禁止性评估文档,作为合规档案的一部分。特别是涉及精神健康评估、情绪识别的SaMD,需要仔细评估是否可能触及"情绪推断"禁令的边界。
2.3 高风险AI系统(Title III, Article 6)
高风险AI系统是EU AI Act监管的核心——也是与SaMD企业关系最密切的部分。高风险AI系统的认定有两条路径:
路径一:Article 6(1)——附件I产品中的AI安全组件如果AI系统本身就是属于附件I(Annex I)所列欧盟产品法规管辖范围的产品,或者是该等产品的安全组件,且该产品需要由第三方机构进行合格评定(Conformity Assessment),则该AI系统自动被归类为高风险。
路径二:Article 6(2)——附件III独立高风险用途附件III列出了八个被视为高风险的AI应用领域,包括但不限于关键基础设施、教育、就业、执法等。
对于SaMD而言,路径一是核心判定依据。
2.4 为什么医疗器械AI几乎都是"高风险"
这是理解EU AI Act对SaMD影响的关键:
Annex I Section A第15项明确列出了两部法规:- MDR (EU) 2017/745——医疗器械法规
- IVDR (EU) 2017/746——体外诊断法规
根据Article 6(1)的逻辑链条:
AI SaMD属于MDR/IVDR管辖范围
↓
MDR/IVDR要求Class IIa及以上器械必须由公告机构(Notified Body)进行合格评定
↓
符合Article 6(1)的条件:产品属于Annex I法规范围 + 需要第三方合格评定
↓
该AI SaMD自动被分类为"高风险AI系统"
这意味着:
| MDR器械分类 | 是否需要公告机构评估 | AI Act风险分类 | 说明 |
|---|---|---|---|
| Class I | 否(自我声明) | 非高风险 | 仅Class I SaMD可能免于高风险分类 |
| Class IIa | 是 | 高风险 | 需满足AI Act全部高风险要求 |
| Class IIb | 是 | 高风险 | 需满足AI Act全部高风险要求 |
| Class III | 是 | 高风险 | 需满足AI Act全部高风险要求 |
实际影响:根据MDR Rule 11,几乎所有用于临床决策的AI SaMD至少被分为Class IIa,因此绝大多数AI SaMD将自动成为EU AI Act下的"高风险AI系统"。
Article 6(3)的例外条款:Article 6(3)规定,如果高风险AI系统不对其所属产品的安全构成重大风险,且不构成该产品的主要功能,则可被排除在高风险分类之外。但对于AI SaMD而言,AI算法通常就是产品的核心功能,因此该例外条款很难适用。
2.5 有限风险AI系统(Title IV, Article 50)
有限风险AI系统主要承担透明度义务:
| 透明度要求 | 适用场景 | 对SaMD的影响 |
|---|---|---|
| 标注AI交互 | 用户与AI系统互动时,需告知对方在与AI交互 | 医疗AI聊天机器人、远程咨询AI |
| 标注AI生成内容 | AI生成的文本、图像、音频须标明 | AI生成的医疗报告需标注 |
| 标注深度伪造 | 深度伪造内容须标明 | 通常不适用 |
| 标注情绪识别/分类 | 使用情绪识别或生物特征分类时须通知 | 精神健康评估AI |
2.6 最低风险AI系统
不属于上述类别的AI系统为最低风险,无强制性合规要求,但欧盟鼓励遵守自愿行为准则。医疗领域中,健康生活方式推荐App、非临床用途的健康数据可视化工具等可能属于此类。
三、高风险AI系统的合规要求:逐条解读
对于被归类为高风险的AI SaMD,EU AI Act Chapter III Section 2规定了一套完整的合规要求。以下逐一解读每项要求的具体内容和对SaMD企业的实操影响。
3.1 风险管理体系(Article 9)
| 维度 | AI Act要求 | 对SaMD的实操影响 |
|---|---|---|
| 范围 | 建立、实施、记录并维护一套风险管理体系 | 需在ISO 14971风险管理基础上扩展AI特定风险 |
| 风险识别 | 识别和分析AI系统在其预期目的和可合理预见的误用条件下的已知和可预见风险 | 需评估算法偏差、对抗攻击、数据漂移等AI特有风险 |
| 风险评估 | 评估可能产生的对健康、安全和基本权利的风险 | 超越传统医疗器械风险评估,纳入"基本权利"维度 |
| 残余风险 | 采取适当的风险管理措施后,残余风险须可接受 | 需建立AI特定的残余风险可接受标准 |
| 测试验证 | 通过适当的测试程序验证风险管理措施 | AI验证测试需覆盖多种临床场景和极端情况 |
| 迭代过程 | 风险管理贯穿AI系统全生命周期 | 上市后持续监测和风险再评估 |
关键差异:Article 9比ISO 14971更广泛——它要求评估对基本权利(如隐私权、非歧视权)的风险,而ISO 14971主要关注物理健康风险。SaMD企业需要在现有的ISO 14971风险管理档案中新增AI特定风险分析模块。
3.2 数据治理与数据集管理(Article 10)
Article 10是对AI SaMD企业影响最大的条款之一,对训练、验证和测试数据提出了前所未有的详细要求:
| 要求类别 | 具体内容 | 实操要点 |
|---|---|---|
| 数据治理实践 | 建立涵盖设计选择、数据收集流程、数据准备操作(标注、清洗、丰富等)的治理框架 | 需编制完整的数据治理手册 |
| 训练数据相关性 | 训练数据必须与AI系统的预期目的相关 | 数据集须覆盖目标临床人群和使用场景 |
| 训练数据代表性 | 数据集须充分代表AI系统将要部署的使用环境 | 核心挑战:须包含欧洲人群数据 |
| 数据集无错误 | 尽可能确保数据集没有错误和不完整性 | 标注质量控制、金标准验证 |
| 偏差识别与纠正 | 识别和解决可能导致歧视性输出的数据偏差 | 需进行亚组分析(性别、年龄、种族) |
| 数据集统计属性 | 记录数据集的统计特征(大小、分布、覆盖率等) | 数据集描述报告 |
| 数据保护 | 遵守GDPR和其他数据保护法规 | 跨境数据传输需SCCs或其他合法机制 |
| 特殊类别个人数据 | 处理健康数据等特殊类别数据须有合法基础 | 需GDPR第9条的明确豁免基础 |
对中国企业的核心挑战:如果AI SaMD的训练数据主要来自中国医疗机构,可能面临以下问题:
- 人群代表性:欧洲人群在疾病谱、生理参数上与中国人群存在差异
- 设备兼容性:训练数据采集设备可能与欧洲临床常用设备不同
- 数据传输合规:将欧洲临床数据传回中国用于模型训练可能违反GDPR
- 数据标注标准:中国与欧洲的临床标注标准可能存在差异
3.3 技术文档(Article 11 + Annex IV)
高风险AI系统必须在投放市场前编制技术文档,并持续更新。Annex IV详细规定了文档内容:
| 文档章节 | 具体要求 | 与MDR技术文件的关系 |
|---|---|---|
| 系统一般描述 | AI系统的预期目的、开发者、版本号、与其他系统的交互方式 | 可整合至MDR技术文件的产品描述部分 |
| 系统详细描述 | 开发方法论、设计规格、系统架构、算法选择理由、关键设计决策 | 新增内容,需详细描述AI/ML架构 |
| 开发过程信息 | 开发工具、框架、数据管道、训练过程、超参数选择 | 新增内容,远超IEC 62304要求 |
| 监测与控制 | 算法行为的监测机制、人为监督界面 | 可与MDR上市后监督整合 |
| 数据集信息 | 训练/验证/测试数据集的详细描述、来源、选择理由、偏差分析 | 新增内容,需极为详细的数据集报告 |
| 测试与验证 | 测试方法、测试指标、测试结果、已知局限性 | 可与MDR性能验证报告整合 |
| 风险管理 | 风险管理系统描述、风险识别结果、风险控制措施 | 可与ISO 14971报告整合并扩展 |
文档量估算:一个典型的Class IIb AI诊断SaMD,其AI Act技术文档可能需要额外200-400页(在MDR技术文件基础上)。
3.4 记录保持与自动日志(Article 12)
| 要求 | 具体内容 | 实操要点 |
|---|---|---|
| 自动日志 | 高风险AI系统须具备自动记录事件(日志)的功能 | 需在软件架构中内建日志系统 |
| 日志内容 | 至少记录:使用的时间段、输入数据的参考信息、触发自检的情况 | 需设计详细的日志数据模型 |
| 可追溯性 | 日志须能追溯AI系统在每个使用场景中的行为 | 确保每次诊断建议可回溯 |
| 日志保存 | 保存期限须与AI系统的预期目的及适用法律要求一致 | 建议至少保存10年(与MDR要求对齐) |
| 部署者义务 | 部署者(医疗机构)须保留AI系统自动生成的日志 | 需在产品使用说明中告知部署者义务 |
技术影响:这意味着AI SaMD需要内建一套完整的审计追踪(Audit Trail)系统,能够在每次推理过程中自动记录输入、输出、置信度、处理时间等关键信息。存储和安全管理这些日志数据的成本不容忽视。
3.5 透明度与用户信息(Article 13)
| 要求 | 具体内容 | 对SaMD说明书的影响 |
|---|---|---|
| 运行透明度 | AI系统的设计和开发须确保部署者能够理解其输出并适当使用 | 需在IFU中增加AI行为描述 |
| 使用说明 | 须以清晰、易懂的方式提供使用说明 | IFU需大幅扩充AI相关内容 |
| 性能指标 | 须提供AI系统的性能水平,特别是准确性指标 | 需明确标注灵敏度、特异度、AUC等指标 |
| 已知局限 | 须说明可预见的使用情形中AI系统的已知或可预见的局限性 | 需在IFU中明确列出算法的适用范围和边界 |
| 人为监督信息 | 须告知如何实施人为监督 | 需描述临床医生何时以及如何审核AI输出 |
| 输入数据规格 | 须说明输入数据的技术要求 | 需描述可接受的输入数据格式、质量要求 |
3.6 人为监督(Article 14)
| 要求 | 具体内容 | 对SaMD设计的影响 |
|---|---|---|
| 监督目的 | 防止或最小化可预见风险;确保人类能有效监督AI系统 | 须设计临床医生审核工作流 |
| 监督能力 | 系统设计须使人类监督者能够充分理解AI系统的能力和局限 | 需提供可解释性输出和置信度评分 |
| 干预能力 | 人类监督者须能在任何时候决定不使用AI系统的输出、覆盖或逆转AI输出 | 关键要求:SaMD须设计"否决"机制 |
| 停止能力 | 人类监督者须能通过"停止"按钮或类似程序中断AI系统运行 | 须在UI中设计紧急停止功能 |
| 自动化偏差防范 | 设计须减轻人类对AI输出的过度依赖(自动化偏差) | 需在UI中显示不确定性提示 |
实操建议:对于AI辅助诊断SaMD,最直接的人为监督实现方式是采用"AI建议 + 医生确认"的工作流——AI输出诊断建议,但最终决策权始终在医生手中,且医生可以修改、否决或忽略AI的建议。
3.7 准确性、稳健性与网络安全(Article 15)
| 维度 | 要求 | 对SaMD的具体要求 |
|---|---|---|
| 准确性 | AI系统须在其整个生命周期内达到适当的准确性水平 | 须定义并验证灵敏度、特异度、PPV、NPV、AUC等指标 |
| 稳健性 | AI系统须具备应对错误、故障和不一致性的稳健性 | 须进行对抗性测试、噪声鲁棒性测试 |
| 弹性 | 须能抵御未经授权的第三方试图利用系统漏洞改变系统行为的企图 | 须进行对抗样本攻击测试 |
| 网络安全 | 须防范试图利用AI特有漏洞的攻击,包括数据中毒、模型中毒、对抗样本、模型逆向工程等 | 须建立AI特定的威胁模型 |
| 输出一致性 | 对于自适应AI,须采取措施确保输出的可预测性和一致性 | 持续学习型SaMD的特殊挑战 |
| 回退机制 | 须设计适当的回退方案和故障安全机制 | 当AI系统失败时,须有安全降级方案 |
| 威胁类型 | 描述 | 防范措施 |
|---|---|---|
| 数据中毒(Data Poisoning) | 攻击者篡改训练数据以影响模型行为 | 训练数据完整性验证、可信数据源管理 |
| 模型中毒(Model Poisoning) | 在联邦学习等场景中注入恶意模型更新 | 异常检测、贡献者验证 |
| 对抗样本(Adversarial Examples) | 精心构造的输入,导致模型产生错误输出 | 对抗训练、输入验证、异常检测 |
| 模型逆向工程 | 通过查询接口推断模型参数或训练数据 | API速率限制、输出扰动、差分隐私 |
| 模型窃取(Model Extraction) | 通过大量查询复制模型行为 | 水印技术、查询监控 |
四、EU AI Act与MDR/IVDR交叉合规:双重框架解析
这是本文最核心的部分。EU AI Act第六章(Article 113-114)明确规定了与现有欧盟产品立法(包括MDR和IVDR)的衔接机制。
4.1 一个CE标志,双重评估
EU AI Act Article 43(3)明确规定:对于同时属于EU AI Act和MDR/IVDR管辖范围的产品,不需要进行两次独立的合格评定。但公告机构在进行MDR/IVDR合格评定时,必须同时验证AI Act的高风险AI要求是否得到满足。
| 合规维度 | MDR/IVDR合格评定 | AI Act合格评定 | 整合方式 |
|---|---|---|---|
| 评定主体 | MDR/IVDR指定的公告机构 | 同一公告机构 | 公告机构需具备AI评估能力 |
| 评定范围 | MDR Annex I基本安全与性能要求 | AI Act Chapter III Section 2要求 | 合并评估,出具统一结论 |
| CE标志 | 一个CE标志 | 不另外加贴CE标志 | 一次合格评定,一个CE标志 |
| 符合性声明 | EU DoC | 同一文件中涵盖AI Act合规声明 | 扩展EU DoC以涵盖AI Act |
| 技术文件 | MDR技术文件 | AI Act Annex IV技术文档 | 建议整合为统一技术文件 |
4.2 MDR与AI Act要求对照:重叠与差距
以下表格系统梳理了MDR和AI Act在每个合规维度上的要求,帮助企业识别已覆盖的领域和需要补充的差距:
| 合规维度 | MDR要求 | AI Act新增/加强要求 | 差距分析 |
|---|---|---|---|
| 风险管理 | ISO 14971风险管理 | Article 9:扩展至"基本权利"风险;要求涵盖可合理预见的误用 | 差距:需新增基本权利影响评估、AI特有风险(偏差、漂移) |
| 临床评价 | CER/PER(MDR Article 61) | Article 9:AI验证须覆盖真实使用环境 | 部分重叠:临床评价可复用,但需补充AI特定验证 |
| 技术文件 | MDR Annex II/III | Annex IV:极详细的AI特定文档(算法架构、训练过程、数据集) | 重大差距:需新增大量AI特定文档 |
| 质量管理体系 | ISO 13485 | Article 17:要求建立AI质量管理体系 | 部分重叠:ISO 13485为基础,但需扩展AI数据管理和模型管理 |
| 上市后监督 | PMS/PMCF(MDR Article 83-86) | Article 72:AI特定上市后监测 | 部分重叠:需在PMS中纳入算法性能监测、偏差监测 |
| 标签/IFU | MDR Annex I Chapter III | Article 13:透明度要求(性能指标、局限性、人为监督说明) | 差距:IFU需大幅扩展AI相关信息 |
| 网络安全 | MDR Annex I 17.2 | Article 15:AI特有网络安全(数据中毒、对抗样本防范) | 差距:需新增AI特有威胁防范 |
| 数据治理 | 有限要求 | Article 10:全面数据治理框架 | 重大差距:MDR无系统性数据治理要求 |
| 人为监督 | MDR对SaMD有限的人机交互要求 | Article 14:详细的人为监督设计要求 | 差距:需显式设计人为监督机制 |
| 记录保持 | MDR要求保存技术文件 | Article 12:自动日志记录功能 | 差距:需在软件中内建审计追踪 |
4.3 公告机构的角色变化
EU AI Act对公告机构提出了新的能力要求:
| 维度 | MDR下的公告机构 | AI Act下的额外要求 |
|---|---|---|
| 评估能力 | 医疗器械安全性和性能评估 | 需具备AI系统评估的专业能力 |
| 人员资质 | 医疗器械领域专家 | 需增加AI/ML技术专家 |
| 评估范围 | MDR Annex I基本要求 | 加上AI Act Chapter III Section 2全部要求 |
| 评估方法 | 技术文件审查 + QMS审核 | 需新增AI模型验证、数据集审查、偏差评估 |
| 授权范围 | MDR Article 42 | AI Act Article 28-29对公告机构的额外要求 |
实际影响:目前欧盟境内具备AI评估能力的公告机构数量有限。企业在选择公告机构时,须确认其是否已获得AI Act下的评估授权。预计2026年上半年,主流公告机构(如BSI、TUV SUD、TUV Rheinland、DEKRA等)将陆续获得AI Act评估资质。
4.4 技术文档整合策略
为避免重复劳动和文档不一致,建议企业采用整合式技术文档架构:
| 文档层级 | 内容 | 整合策略 |
|---|---|---|
| 第一层:产品总述 | 产品描述、预期目的、分类(MDR + AI Act双重分类) | 一份综合文件 |
| 第二层:MDR核心文档 | 基本安全与性能要求符合性、CER、PMS计划 | 保持MDR结构不变 |
| 第三层:AI Act补充文档 | AI系统详细描述、数据集报告、AI风险管理补充、人为监督设计、日志设计、透明度措施 | 作为MDR技术文件的附录或补充模块 |
| 第四层:验证证据 | 软件验证、AI性能验证、网络安全测试、对抗测试 | 整合为统一验证报告集 |
4.5 QMS扩展:ISO 13485 + AI质量管理
AI Act Article 17要求高风险AI提供者建立质量管理体系。对于已建立ISO 13485的SaMD企业,需要在以下方面进行扩展:
| ISO 13485现有覆盖 | AI Act新增要求 | 建议实施方式 |
|---|---|---|
| 设计开发控制 | AI模型版本控制、训练过程记录 | 在设计控制程序中新增AI模型管理子流程 |
| 文件控制 | 数据集版本管理、数据血统追踪 | 建立专门的数据资产管理系统 |
| 变更控制 | AI模型更新控制、数据集更新评估 | 扩展变更控制程序以涵盖AI模型和数据变更 |
| 供应商管理 | GPAI模型提供者评估、数据供应商审核 | 扩展供应商审核清单 |
| 管理评审 | AI性能监测数据纳入管理评审 | 在管理评审议程中新增AI性能议题 |
| CAPA | AI偏差、性能退化的CAPA流程 | 建立AI特定的CAPA触发标准 |
五、GPAI模型与医疗AI的关系
EU AI Act Chapter V专门规范了通用人工智能模型(General-Purpose AI Models, GPAI),这对使用基础模型的SaMD企业有直接影响。
5.1 什么是GPAI模型
GPAI模型是指经大量数据训练、具有显著通用性、能够胜任广泛不同任务的AI模型。典型例子包括GPT系列、Claude系列、Gemini系列,以及专用的医疗LLM(如Med-PaLM、BioMedLM等)。
5.2 GPAI与SaMD的关系链
GPAI模型提供者(如OpenAI、Google等)
↓ 提供基础模型
SaMD开发者(中国企业)
↓ 微调/集成为SaMD产品
SaMD产品
↓ 部署至欧盟医疗机构
部署者(欧盟医院/诊所)
5.3 GPAI提供者 vs SaMD提供者的责任划分
| 责任领域 | GPAI模型提供者 | SaMD提供者(中国企业) |
|---|---|---|
| 模型技术文档 | 必须提供GPAI技术文档 | 可依赖GPAI提供者的文档 |
| 训练数据合规 | 负责基础训练数据合规 | 负责微调数据合规 |
| 版权合规 | 须遵守EU版权指令 | 通常由GPAI提供者承担 |
| 下游集成指导 | 须向下游提供充分的集成指导和文档 | 须按照指导进行集成 |
| 高风险AI合规 | 不直接适用高风险AI要求 | 全部责任由SaMD提供者承担 |
| 上市后监测 | 配合提供模型更新信息 | 全部责任在SaMD提供者 |
关键要点:即使SaMD使用了第三方GPAI模型,SaMD提供者仍须对最终产品的AI Act合规承担完整责任。这包括验证GPAI模型在医疗场景中的性能、评估其偏差、确保其安全性等。
5.4 系统性风险GPAI的额外要求
如果SaMD使用的GPAI模型被欧盟委员会指定为"具有系统性风险的GPAI模型"(训练所用算力超过10^25 FLOPs,或经欧盟委员会评估后认定),则GPAI提供者须满足额外要求:
| 额外要求 | 内容 | 对SaMD的间接影响 |
|---|---|---|
| 模型评估 | 根据标准化协议进行模型评估 | SaMD提供者可要求查看评估结果 |
| 系统性风险评估 | 评估和缓解模型可能的系统性风险 | 影响SaMD的风险评估 |
| 严重事件追踪 | 跟踪、记录和报告严重事件 | 须与SaMD的不良事件报告协调 |
| 网络安全保护 | 充分的网络安全保护水平 | 影响SaMD的整体安全架构 |
5.5 实操建议
对于计划在SaMD中集成GPAI模型的中国企业:
- 合同约束:在与GPAI提供者的合同中明确要求提供AI Act所需的技术文档、集成指导和更新通知
- 独立验证:不完全依赖GPAI提供者的性能声明,在医疗场景中进行独立验证
- 供应商审核:将GPAI提供者纳入QMS供应商管理流程
- 回退方案:设计不依赖特定GPAI模型的回退机制
- 版本锁定:明确使用的GPAI模型版本,建立模型更新评估流程
六、对中国AI医疗器械企业的具体影响
6.1 数据集要求对中国企业的挑战
| 挑战 | 具体表现 | 应对策略 |
|---|---|---|
| 训练数据偏差 | 以中国患者数据为主的训练集可能不代表欧洲人群的疾病谱和生理特征 | 在欧洲开展多中心验证研究,收集补充数据集 |
| 欧洲人群代表性 | EU AI Act明确要求数据集须代表部署环境的人口统计特征 | 与欧洲医疗机构合作获取标注数据 |
| 设备兼容性 | 中国医院使用的影像设备品牌/型号与欧洲可能不同 | 在欧洲常用设备上进行额外验证 |
| 数据跨境传输 | GDPR严格限制欧洲健康数据向第三国传输 | 在欧洲本地进行数据处理,采用联邦学习或合成数据 |
| 标注标准差异 | 疾病编码体系(ICD-10 vs 中国分类)可能存在差异 | 建立跨体系的标注映射方案 |
| 数据量与质量 | 某些罕见疾病或特定亚组数据可能不足 | 利用数据增强、迁移学习技术 |
6.2 算法透明度 vs 商业秘密保护
EU AI Act Article 78规定了保密义务,在一定程度上保护了商业秘密。但企业仍需在透明度与保密之间找到平衡:
| 必须披露的内容 | 可以保密的内容 | 建议策略 |
|---|---|---|
| 算法类型和总体架构 | 具体的模型参数和权重 | 描述架构层面的信息,不披露具体参数 |
| 训练数据集的统计特征 | 训练数据集本身 | 提供数据集摘要报告 |
| 性能指标和已知局限 | 特定的优化技巧 | 全面披露性能指标 |
| 偏差评估结果 | 专有的偏差纠正方法 | 披露评估结果,不披露纠正算法细节 |
| 人为监督机制 | UI设计细节 | 描述监督工作流 |
6.3 欧盟授权代表的新要求
EU AI Act Article 22要求欧盟境外的AI系统提供者在投放欧盟市场前指定一名欧盟授权代表(Authorised Representative)。
| 维度 | MDR授权代表 | AI Act授权代表 | 整合方式 |
|---|---|---|---|
| 法律依据 | MDR Article 11 | AI Act Article 22 | 可以是同一实体 |
| 职责范围 | MDR合格评定、上市后监督、EUDAMED | AI Act合规文件保存、与市场监督机构沟通 | 扩展现有MDR授权代表的职责 |
| 资质要求 | 设在欧盟境内 | 设在欧盟境内 | 一致 |
| 费用 | €10,000-30,000/年 | 额外€5,000-15,000/年 | 可谈判打包价格 |
建议:选择同时熟悉MDR和AI Act的授权代表,实现职责整合,降低合规成本。
6.4 合规成本估算
以下是不同规模中国AI SaMD企业进入欧盟市场的合规成本估算(以Class IIb AI诊断SaMD为例):
| 费用项目 | 小型企业(<50人) | 中型企业(50-500人) | 大型企业(>500人) |
|---|---|---|---|
| AI Act差距分析与策略 | €15,000-30,000 | €25,000-50,000 | €40,000-80,000 |
| 数据治理体系建设 | €20,000-50,000 | €50,000-100,000 | €80,000-200,000 |
| AI技术文档编制 | €30,000-60,000 | €40,000-80,000 | €50,000-100,000 |
| AI性能验证(欧洲数据) | €50,000-150,000 | €80,000-200,000 | €100,000-300,000 |
| 对抗性测试与AI安全评估 | €15,000-30,000 | €20,000-50,000 | €30,000-80,000 |
| 公告机构AI审查附加费 | €10,000-25,000 | €15,000-30,000 | €20,000-40,000 |
| 授权代表(AI Act扩展) | €5,000-10,000/年 | €8,000-15,000/年 | €10,000-20,000/年 |
| 外部法规咨询 | €20,000-40,000 | €30,000-60,000 | €40,000-80,000 |
| 人为监督与日志系统开发 | €30,000-80,000 | €50,000-120,000 | €80,000-200,000 |
| AI Act合规总增量成本 | €195,000-475,000 | €318,000-705,000 | €450,000-1,100,000 |
| MDR合规成本(参考) | €200,000-500,000 | €300,000-700,000 | €400,000-900,000 |
| 双重合规总成本 | €395,000-975,000 | €618,000-1,405,000 | €850,000-2,000,000 |
要点:AI Act带来的增量合规成本约为MDR合规成本的50%-100%,实质上将欧盟市场准入的总成本翻了近一倍。
七、合规路径与实操建议
7.1 五阶段合规路线图
Phase 1:AI系统分类评估(第1-2个月)
| 任务 | 交付物 | 关键问题 |
|---|---|---|
| 确认AI系统是否属于EU AI Act的"AI系统"定义 | AI系统定义评估报告 | 产品是否具有自主性和推断能力? |
| 评估是否触及禁止性AI实践 | 禁止性评估文档 | 是否涉及情绪推断、社会评分等? |
| 确定AI风险分类 | AI风险分类报告 | MDR Class IIa+ = 高风险AI |
| 明确适用的EU AI Act条款 | 适用条款清单 | Chapter III Section 2全部适用? |
Phase 2:差距分析(第2-4个月)
| 任务 | 交付物 | 关键问题 |
|---|---|---|
| 盘点现有MDR合规文档 | 现状评估报告 | 哪些文档已覆盖AI Act要求? |
| 逐条对照AI Act高风险要求 | 差距分析矩阵 | 最大差距在哪里? |
| 评估技术能力差距 | 技术差距报告 | 是否需要新增AI安全测试能力? |
| 评估数据差距 | 数据差距报告 | 现有数据是否满足欧洲代表性要求? |
| 编制合规路线图与预算 | 合规实施计划 | 在2026年8月2日前能否完成? |
Phase 3:数据治理体系建设(第3-8个月)
| 任务 | 交付物 | 关键问题 |
|---|---|---|
| 建立数据治理框架 | 数据治理手册 | 覆盖收集、标注、清洗、存储全流程? |
| 评估并改进训练数据集 | 数据集评估报告 | 数据集是否满足代表性和无偏要求? |
| 收集欧洲补充数据 | 数据合作协议 | 是否与欧洲医疗机构建立合作? |
| 建立数据血统追踪 | 数据血统文档 | 能否追溯每条数据的完整生命周期? |
| 确保GDPR合规 | GDPR影响评估(DPIA) | 跨境数据传输机制是否到位? |
Phase 4:技术文档扩展与系统升级(第5-12个月)
| 任务 | 交付物 | 关键问题 |
|---|---|---|
| 编制AI Act Annex IV技术文档 | AI技术文档 | 是否涵盖算法架构、训练过程、数据集详述? |
| 实施AI特定验证测试 | AI验证报告 | 包括对抗测试、公平性测试、鲁棒性测试? |
| 开发人为监督功能 | 人为监督设计文档 | 临床医生能否有效审核和否决AI输出? |
| 开发自动日志功能 | 日志系统设计文档 | 能否自动记录每次推理的全部关键信息? |
| 更新IFU(使用说明书) | 更新后的IFU | 是否包含透明度要求的全部信息? |
| 扩展QMS流程 | 更新后的QMS文件 | ISO 13485是否扩展了AI质量管理? |
Phase 5:合格评定与CE认证(第10-18个月)
| 任务 | 交付物 | 关键问题 |
|---|---|---|
| 选择具备AI评估资质的公告机构 | NB选择报告 | NB是否获得AI Act评估授权? |
| 提交技术文件(含AI Act文档) | 完整技术文件包 | MDR + AI Act文档是否完整整合? |
| 配合NB审核(含AI审查) | 审核响应文件 | 是否有AI技术专家配合审核? |
| 获得CE证书 | CE证书(涵盖MDR + AI Act合规声明) | EU DoC是否涵盖AI Act合规? |
| 在欧盟AI数据库注册 | 注册确认 | Article 49要求注册高风险AI系统 |
7.2 关键时间线
针对2026年8月2日高风险AI系统要求生效这一截止日期,企业应参考以下时间线:
| 时间节点 | 对新产品的建议 | 对已上市产品的建议 |
|---|---|---|
| 2026年Q1(现在) | 立即启动Phase 1-2(分类评估+差距分析) | 立即启动差距分析 |
| 2026年Q2 | 推进Phase 3-4(数据治理+技术文档) | 启动技术文档补充和系统升级 |
| 2026年Q3 | 启动Phase 5(合格评定) | 与公告机构沟通AI Act合规升级方案 |
| 2026年Q4-2027年Q1 | 完成CE认证 | 启动合格评定更新 |
| 2027年8月2日前 | — | 完成合规升级,更新CE证书 |
八、全球AI医疗器械监管对比
8.1 三大框架横向对比
| 维度 | EU AI Act | FDA AI/ML Framework | NMPA AI SaMD Guidance |
|---|---|---|---|
| 法律性质 | 强制性法规(Regulation) | 指导原则 + 具体指南 | 指导原则(非强制性) |
| 分类方法 | 基于风险的四级分类 | 基于功能风险的产品分类 | 基于产品目录的三级分类 |
| 高风险判定 | MDR Class IIa+ = 高风险AI | 按产品风险定(Class I/II/III) | Class III为最严格 |
| 数据治理 | 最严格:Article 10全面要求 | 建议性要求 | 有要求但细节较少 |
| 透明度 | 最严格:详细的透明度义务 | 要求合理范围内的透明度 | 要求算法可解释性 |
| 人为监督 | 最严格:Article 14详细要求 | 无统一要求 | 建议性要求 |
| 自动日志 | 最严格:Article 12强制要求 | 无统一要求 | 无强制要求 |
| 偏差评估 | 强制要求 | 建议要求 | 要求但灵活度高 |
| 对抗鲁棒性 | Article 15明确要求 | 建议性要求 | 有限要求 |
| 持续学习管理 | 严格的变更控制 | PCCP机制(较灵活) | 更新验证程序 |
| 处罚力度 | 最高€35M或全球营收7% | 产品下架、Warning Letter | 产品下架、行政处罚 |
| 实施时间 | 2026年8月2日(高风险) | 已实施(持续更新) | 已实施(持续更新) |
8.2 核心差异分析
| 差异点 | 对中国企业的影响 |
|---|---|
| EU AI Act是横向法规,FDA/NMPA是纵向产品监管 | 欧盟合规需要同时满足两套法律体系,复杂度最高 |
| EU AI Act的数据治理要求最严格 | 中国企业面临最大的数据合规挑战在欧盟 |
| EU AI Act的处罚力度远超其他地区 | 不合规的商业风险极高 |
| FDA的PCCP机制最灵活 | 持续学习型AI在美国的监管路径最清晰 |
| EU AI Act的透明度要求最详细 | 欧盟市场要求更高的算法透明度投入 |
8.3 合规策略建议
| 策略 | 适用企业 | 优势 |
|---|---|---|
| 以EU AI Act为最高标准统一合规 | 面向全球市场的企业 | 一套体系满足所有市场(欧盟标准最高) |
| 分市场定制合规 | 资源有限、市场优先级明确的企业 | 控制成本,按需合规 |
| 先FDA后欧盟 | 美国市场为首要目标的企业 | FDA经验可部分复用于EU AI Act |
九、处罚与执法
了解处罚力度有助于企业准确评估不合规的商业风险:
| 违规类型 | 最高罚款 | 备注 |
|---|---|---|
| 投放被禁止的AI系统 | €35,000,000或全球年营收的7%(取高者) | 最严厉处罚 |
| 不遵守高风险AI系统义务 | €15,000,000或全球年营收的3%(取高者) | SaMD企业最可能面临的处罚 |
| 向公告机构或监管机构提供不准确信息 | €7,500,000或全球年营收的1%(取高者) | 诚信义务 |
| SME和初创企业 | 上述罚款的较低值,但仍具惩罚性 | 对小企业有一定减免 |
对比参考:GDPR最高罚款为€20,000,000或全球年营收的4%。EU AI Act的处罚上限更高,体现了欧盟对AI监管的重视程度。
十、常见问题FAQ
Q1:我们的SaMD已经获得了MDR CE认证,还需要额外做什么?
如果您的SaMD包含AI/ML功能且被分类为Class IIa或以上,则在2027年8月2日前必须补充满足AI Act的全部高风险AI系统要求。建议立即启动差距分析,识别现有MDR技术文件与AI Act要求之间的差距,并制定补救计划。最常见的差距包括:AI技术文档(Annex IV)、数据治理体系(Article 10)、人为监督设计(Article 14)和自动日志系统(Article 12)。
Q2:Class I的AI SaMD是否需要满足AI Act的高风险要求?
不需要。根据Article 6(1)的判定逻辑,只有需要公告机构进行合格评定的产品(即Class IIa及以上)才自动被归类为高风险AI系统。Class I SaMD采用自我声明方式,不需要公告机构介入,因此不自动触发高风险分类。但请注意,根据MDR Rule 11,大多数具有临床决策功能的AI SaMD至少被分为Class IIa。
Q3:EU AI Act的数据治理要求与GDPR是什么关系?
两者是互补而非替代关系。GDPR规范的是个人数据的处理(合法性、数据主体权利等),而AI Act Article 10规范的是AI训练/验证/测试数据集的质量和治理(代表性、无偏差、统计特征等)。企业需要同时满足两者:使用健康数据训练AI需要GDPR第9条的合法基础,同时数据集本身需要满足AI Act的质量和治理要求。
Q4:我们使用了第三方预训练模型(如GPT),AI Act的合规责任怎么划分?
SaMD提供者(中国企业)对最终产品的AI Act合规承担全部责任,无论是否使用了第三方GPAI模型。GPAI提供者有义务提供技术文档和集成指导,但高风险AI系统的全部合规要求(包括数据治理、风险管理、人为监督等)由SaMD提供者承担。建议在与GPAI提供者的合同中明确要求其配合提供所需文档和技术支持。
Q5:EU AI Act下的技术文档能否与MDR技术文件合并?
可以,且强烈建议这样做。AI Act Article 43(3)明确允许整合评定,实际操作中建议将AI Act Annex IV要求的文档作为MDR技术文件的补充模块或附录。关键是确保文档架构清晰、交叉引用明确,使公告机构能够高效审查两套要求的符合性。
Q6:对抗性测试(Adversarial Testing)是强制要求吗?具体该怎么做?
是的。Article 15(4)要求高风险AI系统须能抵御试图利用其漏洞的攻击,包括对抗样本攻击。对于影像AI SaMD,典型的对抗性测试包括:(1)向输入图像添加人类不可见的微小扰动,验证模型输出是否发生重大改变;(2)测试模型对图像质量退化(噪声、模糊、压缩伪影)的鲁棒性;(3)评估边界病例(正常与异常的模糊地带)的分类稳定性。建议委托具有AI安全测试经验的专业实验室执行。
Q7:公告机构目前是否已经准备好审查AI Act合规性?
截至2026年3月,大多数主流公告机构正在积极准备AI Act评估能力的建设。BSI、TUV SUD等头部机构已开始招聘AI领域审核员,并开发AI Act评估方法论。但完整的AI Act审查能力预计在2026年下半年才能全面就绪。建议企业尽早与目标公告机构沟通,了解其AI Act审查时间表和要求。
Q8:如果我们的SaMD仅在欧盟做OEM/白标,没有自己的品牌,AI Act的责任由谁承担?
根据AI Act Article 25,如果以自己的名称或商标将AI系统投放市场,或对已投放市场的高风险AI系统进行实质性修改,则该实体被视为"提供者",承担全部AI Act义务。在OEM/白标模式中,将产品以自己品牌投放欧盟市场的欧盟实体为"提供者",但中国制造商作为实际开发者仍可能通过合同被追溯责任。建议在OEM协议中明确划分AI Act合规责任。
Q9:EU AI Act对自适应/持续学习型AI SaMD有什么特殊要求?
自适应AI SaMD面临更严格的监管。Article 15要求确保持续学习不会导致输出的不可预测性。Article 9要求在风险管理中特别考虑算法漂移风险。实际操作中,建议:(1)预定义允许的模型更新范围和触发条件;(2)建立更新前的自动验证流程,确保更新后性能不低于基准;(3)设计回滚机制,在性能退化时可快速恢复到上一个验证版本;(4)将模型更新纳入变更控制程序并通知公告机构。
Q10:EU AI Act要求注册到哪个数据库?
Article 49和Article 71要求高风险AI系统的提供者在欧盟AI数据库(EU Database for High-Risk AI Systems)中注册其系统。这是一个独立于EUDAMED的公开数据库。注册信息包括:提供者名称、AI系统描述、预期目的、风险分类、合格评定信息、欧盟授权代表信息等。此注册义务是在EUDAMED注册之外的额外要求。
十一、总结:中国AI SaMD企业的行动优先级
EU AI Act对医疗器械AI系统的监管影响深远而具体。以下是按优先级排列的核心行动清单:
立即行动(2026年Q1-Q2):- 完成AI系统分类评估,确认产品是否属于高风险AI
- 启动差距分析,量化现有MDR合规与AI Act新增要求之间的差距
- 评估数据集的欧洲人群代表性,规划数据补充策略
- 与公告机构沟通AI Act评估时间表和要求
中期推进(2026年Q2-Q4): 5. 建立数据治理体系,编制数据集评估报告 6. 开发人为监督功能和自动日志系统 7. 编制AI Act Annex IV技术文档 8. 执行对抗性测试和AI安全评估
长期建设(持续): 9. 将AI质量管理嵌入ISO 13485 QMS 10. 建立AI性能上市后监测体系 11. 跟踪欧盟委员会发布的AI Act实施细则和统一标准 12. 参与行业标准化进程(ISO/IEC JTC 1/SC 42等)
EU AI Act代表了全球AI监管的最高标准。对于志在全球化的中国AI医疗器械企业而言,将EU AI Act的合规要求视为产品设计的内在约束而非外部负担,建立"合规即竞争力"的思维方式,才能在日益严格的全球监管环境中保持持续的市场准入能力。
参考法规与标准:
- Regulation (EU) 2024/1689 — EU AI Act
- Regulation (EU) 2017/745 — MDR
- Regulation (EU) 2017/746 — IVDR
- EU AI Act Annex I — Union Harmonisation Legislation (Section A, No. 15: MDR & IVDR)
- EU AI Act Annex IV — Technical Documentation for High-Risk AI Systems
- MDCG 2019-11 — Guidance on Qualification and Classification of Software
- ISO 14971:2019 — Medical devices — Application of risk management
- ISO/IEC 42001:2023 — AI Management System
- IEC 62304:2006+AMD1:2015 — Medical device software — Software life cycle processes