更新类型： AI医疗器械 / SaMD / 大模型 / 医疗智能体 / 算法更新 / 数据治理 / 注册申报
发布机构： 国家药品监督管理局医疗器械技术审评中心（CMDE）
发布日期： 2026-09-14
当前状态： 征求意见稿，尚未正式实施
适用范围： 第二类、第三类人工智能独立软件及含人工智能软件组件的医疗器械，包括 IVD
CMDE 于 2026 年 9 月 14 日公开征求《人工智能医疗器械注册审查指导原则（2026年修订版）（征求意见稿）》意见。
本次修订后的文件已经不再只围绕传统深度学习辅助诊断软件，而是进一步覆盖人工智能医疗器械完整生命周期，并新增或明显强化了：
- 大模型；
- 医疗智能体（Agent）；
- 持续学习 / 自适应学习；
- 多模态产品；
- 多病种产品；
- 第三方测评数据库；
- 压力测试与对抗测试；
- 算法更新与版本控制；
- 人工智能算法框架；
- AI 芯片；
- 数据安全及网络安全。
需要注意：
目前仍为征求意见稿，不是已经生效的强制注册要求。
指导原则本身也明确，其属于指导性文件，不作为法规强制执行。
适用范围进一步明确
本指导原则适用于：
- 第二类、第三类人工智能独立软件；
- 含人工智能软件组件的医疗器械；
- 含人工智能软件组件的 IVD；
- 自研人工智能软件。
现成软件组件可参照执行，但不适用于外部软件环境。
此外，采用人工智能技术实现功能或用途的质量管理软件，也可参考其中适用要求。
人工智能医疗器械不再只等于“AI辅助诊断软件”
新版从多个维度重新梳理了人工智能医疗器械。
从用途上，可以分为：
辅助决策类
例如：
- 辅助分诊；
- 辅助评估；
- 辅助检测；
- 辅助诊断；
- 辅助筛查；
- 辅助治疗。
以及：
非辅助决策类
例如：
- 成像流程优化；
- 诊疗流程优化；
- 图像质量改善；
- 成像速度提高；
- 非病灶组织器官自动分割或测量。
从功能上还进一步划分为：
处理功能 / 控制功能 / 安全功能
因此，采用 AI 进行闭环控制、机械臂运动控制或安全风险预警的产品，同样进入人工智能医疗器械生命周期评价框架。
1. 算法更新规则进一步细化
征求意见稿将人工智能算法更新明确区分为：
算法驱动型更新
例如：
- 算法发生改变；
- 算法结构改变；
- 算法流程改变；
- 算法编程框架改变；
- 输入输出数据类型改变；
- 使用全新训练数据重新训练。
这类更新通常属于：
重大软件更新 → 变更注册
数据驱动型更新
即：
核心算法不变，仅通过增加训练数据产生的算法更新。
此时是否属于重大软件更新，原则上根据算法性能评估结果判断。
如果在相同测试集、相同评价指标下，相较前次注册的算法性能存在统计学显著改变，则属于重大软件更新；否则可以作为轻微软件更新管理。
因此，未来算法 change control 不能只记录：
“模型版本从 V1.1 更新到 V1.2。”
而需要能够回答：
为什么更新 → 算法是否改变 → 数据是否改变 → 性能是否显著变化 → 是否影响安全有效性 → 是否需要变更注册。
2. AI 数据治理要求更加体系化
征求意见稿进一步把人工智能数据生命周期拆分为：
数据采集 → 数据整理 → 数据标注 → 数据集构建
并分别提出质量控制要求。
数据来源需要考虑：
- 合规性；
- 充分性；
- 多样性；
- 疾病构成；
- 人群分布；
- 机构来源；
- 采集设备；
- 数据质量。
文件特别强调，应根据产品情况尽可能覆盖：
多家 + 多地域 + 多层级临床机构
以及：
多家 + 多种 + 多参数采集设备。
这实际上是从数据阶段就开始控制模型的泛化能力和偏倚风险。
3. Train / Tune / Test 数据集隔离要求更加明确
征求意见稿明确要求建立：
- 训练集；
- 调优集；
- 测试集。
其中：
训练集、调优集和测试集样本应两两无交集，并通过查重验证。
数据扩增原则上可以用于训练集和调优集，但：
原则上不得对测试集进行数据扩增，对抗测试除外。
如果使用 GAN 等方法进行数据扩增，还需要说明：
- 扩增对象；
- 方法；
- 倍数；
- 数据分布变化；
- 数据偏倚风险。
4. 压力测试和对抗测试被单独提出
新版进一步明确两个概念。
压力测试
采用：
罕见或特殊的真实数据样本
测试算法，用于评价算法泛化能力的极限。
对抗测试
通过：
- 数据扰动；
- 生成对抗网络；
- 其他方式；
生成对抗样本，以评价算法的：
鲁棒性 / 健壮性
如果未开展相关测试，或者测试表现不佳，需要结合风险明确产品：
- 适用范围限制；
- 使用场景限制；
- 核心功能限制；
- 说明书警示信息。
5. 第三方“测评数据库”提出六项要求
第三方数据库可以用于算法性能评估，但并不是任何公开数据库都可以直接承担软件确认。
征求意见稿专门定义了可用于软件确认测试的：
测评数据库
并提出六项要求：
- 权威性
- 科学性
- 规范性
- 多样性
- 封闭性
- 动态性
其中值得注意的是：
公开数据库由于不具备封闭性，不能直接作为测评数据库。
公开数据库仍然可以用于算法性能评价，甚至用于训练，但需要根据具体用途重新评价数据质量和适用性。
6. 多模态产品被单独纳入监管框架
新版明确提出了 多模态产品。
典型场景例如：
X-ray + Ultrasound + MRI → Breast cancer auxiliary diagnosis
文件要求企业分析不同模态之间的：
- 鉴别能力强弱；
- 互补关系；
- 病程阶段差异；
- 模态完整性；
- 模态缺失对模型性能的影响。
对于：
完整模态 / 部分模态 / 单一模态 / 任一模态
还可能需要分别开展性能评价。
如果算法性能高度依赖某一种模态数据，还需要进一步考虑受益风险。
7. 多病种 AI 产品也有了专门要求
征求意见稿同时新增 多病种产品的详细要求。
例如：
一套眼底 AI 同时辅助判断糖尿病视网膜病变、青光眼样视神经改变等多种疾病。
企业需要考虑不同疾病之间的：
- 并发；
- 继发；
- 伴发；
- 独立共存；
- 拮抗；
- 鉴别干扰。
并要求：
- 每种疾病分别设定性能指标；
- 明确多病种输出优先级；
- 评价疾病之间的算法性能影响；
- 建立病种间混淆矩阵。
因此，“一个模型同时输出多个疾病”不再适合只报告一个总体模型性能。
8. 大模型正式进入人工智能医疗器械注册框架
这是本次修订最值得关注的内容之一。
征求意见稿首次系统讨论了大模型，并区分三种主要应用模式。
情况一：通过接口调用通用大模型
如果通用大模型并不是医疗器械实现预期用途的必要环节：
通常可以作为非医疗器械功能。
但说明书仍需明确大模型名称、版本等基本信息。
如果大模型是医疗器械实现预期用途的必要环节：
可视为现成软件组件。
此时需要明确：
- 大模型名称；
- 型号规格；
- 版本；
- 运行环境；
- 接口规格；
并提供相应研究资料。
情况二：基于通用大模型开发医疗智能体
征求意见稿明确提出：
医疗智能体（Agent）原则上可视为医用应用软件，通用大模型可视为现成软件组件。
这意味着：
医疗 Agent ≠ 大模型本身
而是可以拆解为：
医疗应用软件 / Agent + Foundation / General-purpose model component
进行监管评价。
情况三：采用大模型技术路线自研模型
如果企业自行开发：
- 基础模型 / 预训练模型；
- 场景模型 / 微调模型；
则：
- 自研基础模型可视为医用中间件；
- 自研场景模型可视为医用应用软件。
如果二者分别进行版本控制，产品技术要求还需要分别描述其发布版本及版本命名规则。
9. 幻觉和偏见成为明确风险项
无论是：
- 调用通用大模型；
- 医疗智能体；
- 自研大模型；
征求意见稿均要求针对：
Hallucination / Bias
开展风险管理，并在说明书中提供相应警示。
若适用，还需要研究：
- 涌现能力；
- 模型蒸馏；
- 预训练模型；
- 微调模型。
这意味着，大模型医疗器械的注册评价已经不再能够完全套用传统深度学习分类模型的资料结构。
10. 持续学习 / 自适应学习仍然受到严格限制
对于部署后能够持续利用用户数据自行学习的 AI，征求意见稿的立场非常明确。
当前法规和技术条件下：
持续学习 / 自适应学习应关闭自学习功能，或者虽然开放，但不得将自学习产生的更新直接投入临床使用。
换句话说：
Live learning → 自动更新模型 → 直接用于患者
目前并不被接受。
自学习可以用于：
- 算法训练；
- 医学科研。
但产生的新版本仍然需要由注册申请人进行：
验证与确认 → 判断是否需要变更注册 → 获批后投入使用
因此，目前国内 AI 医疗器械的基本监管逻辑仍然是：
Controlled model update
而不是：
Autonomous continuous deployment。
11. AI Framework 和 AI Chip 也进入注册资料
征求意见稿还专门讨论了：
人工智能算法编程框架
需要明确：
- 名称；
- 类型；
- 型号规格；
- 完整版本；
- 制造商。
第三方框架按照：
现成软件 / 供应商
进行管理。
框架发生产品替换或非单纯效率型版本更新时，可能构成重大软件更新。
AI Chip
AI 芯片本身不属于独立监管对象，但需要根据其所在计算平台确定监管方式。
注册资料仍需明确：
- 名称；
- 型号规格；
- 制造商；
- 性能指标。
对于人工智能软件组件，如果 AI 芯片属于医疗器械内部的医用计算平台，则需要与产品整体评价。
12. 算法研究报告的要求进一步结构化
征求意见稿将算法研究报告明确拆分为：
- 算法基本信息；
- 算法风险管理；
- 算法需求规范；
- 数据质控；
- 算法训练；
- 算法验证与确认；
- 算法可追溯性分析；
- 结论。
其中算法可追溯性需要建立：
算法需求 → 算法设计 → 源代码 → 算法测试 → 算法风险管理
之间的关系。
这意味着算法资料正在进一步从单独的“性能测试报告”，转向完整的AI engineering lifecycle evidence。
13. 注册申报资料要求进一步明确
对于软件安全性级别为中等、严重的产品：
全新类型
需要以算法为单位提交：
每个人工智能算法或算法组合的算法研究报告。
成熟类型
可以主要明确算法基本信息，无需完整算法研究报告。
对于软件安全性级别为轻微的产品，同样原则上只需要明确算法基本信息。
此外，对于：
软件安全性级别严重 + 患者使用 / 基层医疗机构使用
的产品，原则上还需要单独提交：
用户培训方案
包括：
- 培训计划；
- 培训材料；
- 培训方式；
- 师资；
- 考核。
14. 说明书需要披露更多 AI 性能信息
对于辅助决策类产品，说明书需要明确：
- 算法性能评价总结；
- 测试集基本信息；
- 性能指标及结果；
- 临床评价总结；
- 临床数据基本信息；
- 临床评价指标及结果；
- 决策指标定义。
对于基于数据的人工智能算法，还需要增加：
算法训练总结
包括训练集基本信息、训练指标与结果。
对于黑盒算法，还应根据算法性能影响因素分析，在说明书中进一步明确产品限制和警示信息。
总体来看
这次修订最明显的变化，是 CMDE 正在把人工智能医疗器械监管从过去相对集中于：
深度学习 → 数据集 → 算法性能 → 临床评价
进一步扩展为：
数据治理 → 模型开发 → 算法泛化 → 压力/对抗测试 → 多模态/多病种 → 大模型/Agent → 软件供应链 → 算法更新 → 上市后生命周期管理
尤其是针对：
大模型、医疗智能体和持续学习
已经给出了比较明确的初步监管边界。
对正在开发人工智能医疗器械的企业，后续更需要从产品早期就建立：
Intended use → Data → Model → V&V → Clinical evaluation → Risk → Version → Change control → PMS
完整证据链，而不是在注册阶段才补充算法性能报告。
当前仍为征求意见稿，正式要求应以后续最终发布版本为准。