当静态框架遇到动态 AI：SaMD 监管十年

第二篇：N81，软件的"技术身份证"

N81 不打算解决 N12 在 AI 面前的分类困境。但它提出了另一个问题：传统风险管理标准 ISO 14971，管得了硬件的疲劳和断裂，但管不了软件的漏洞和漂移。描述软件的风险，需要一套新的语法。

一、硬件会疲劳，软件不会——但软件会过期

传统医疗器械的风险管理标准 ISO 14971，核心逻辑是 FMEA（Failure Mode and Effects Analysis，失效模式与影响分析）。它的基本假设很简单：东西会磨损。

手术刀的钢材会疲劳，电池会老化，密封圈会开裂。ISO 14971 要求厂商回答：这个部件可能在什么条件下失效？失效后对患者的伤害是什么？概率和严重度怎么权衡？

这套逻辑在硬件上跑得很顺。但搬到软件上，事情变得古怪起来。

一个训练好的深度学习模型，不会因为"用久了"而性能下降——至少不是因为物理磨损。但它的风险一点不比硬件少：

• 它依赖的 Python 包明年停止维护，出现漏洞没人修。比如 2021 年 Log4j 事件，一个被广泛使用的日志库爆出远程代码执行漏洞，全球数百万系统受影响
• 它底层调用的 OpenSSL 版本爆出 CVE，整个信任链崩塌
• 训练数据里没有足够的特定人群样本，模型对这个群体系统性表现更差
• 输入图像被加了一层人眼不可见的噪点，模型把良性肿瘤诊断为恶性
• 真实世界的数据分布随季节、地域、人群变化，模型性能慢慢衰减

这些风险怎么塞进 ISO 14971 的 FMEA 表格？“失效模式"是什么？“概率"怎么估算？一个开源库的维护者突然弃坑，这算设计缺陷、制造缺陷、还是外部事件？

ISO 14971 没有给这些问题准备格子。它的整个语法都是为物理失效设计的。

N81 的核心贡献就是：监管机构终于承认，软件的风险需要单独刻画，不能硬塞进硬件的风险管理框架里。

二、N81 要你交什么：三张清单

N81 把软件的特征化拆成三个部分。下面是逐项拆解，以及可以拿来直接用的 checklist。

清单 1：预期用途声明（Intended Use Statement）

N81 要什么：不只是复制粘贴说明书。它要求一个边界清晰的定义——什么数据进、什么决策出、软件在医疗工作流程里扮演什么角色、跟谁交互。

为什么要这个：软件的风险很大程度上取决于它的"生态位”。同一个算法，输出给医生参考是一个风险画像，直接驱动治疗设备是另一个风险画像。

Checklist：

• 输入定义：软件接收什么数据？格式是什么？（DICOM、HL7 FHIR、CSV、图像文件等）
• 输出定义：软件生成什么结果？（概率分数、分类标签、 segmentation mask、诊断建议等）
• 目标用户：谁用这个输出？（放射科医生、全科医生、患者、另一个软件系统）
• 使用场景：在什么医疗环节使用？（筛查、辅助诊断、治疗计划制定、疗效评估、随访）
• 决策层级：输出是"仅供参考”，还是驱动临床决策，还是直接输出诊断/治疗结论？
• 交互系统：软件跟哪些外部系统通信？（PACS、HIS、EMR、云服务等）
• 运行环境：部署在哪里？（本地工作站、医院内网服务器、公有云、边缘设备）

给你的模板框架：

本软件 [名称] 是一款 [SaMD/SiMD]，预期用于 [医疗目的]。软件接收 [输入数据类型]，通过 [核心算法/处理逻辑] 生成 [输出类型]，供 [目标用户] 在 [使用场景] 中 [如何使用输出结果]。软件运行于 [部署环境]，与 [外部系统/接口] 交互。

常见的坑：很多厂商直接把说明书里的"适用范围"段落复制过来交差。N81 要的不是这个。它要的是软件在系统中的功能边界。

清单 2：软件描述（Software Description）

N81 要什么：软件的架构、接口、依赖关系、AI/ML 组件。用 N81 的原话说，是"a comprehensive description of the software that provides an understanding of the software’s design, functionality, and behaviour"。

Checklist：

架构层面

• 软件架构类型（单体 / 微服务 / 客户端-服务器 / 云原生）
• 部署拓扑图（各组件在哪里运行、怎么通信）
• 数据流图（数据从进入系统到输出结果的全路径）
• 是否有持续学习 / 在线更新机制？

接口层面

• 所有外部接口列表（API、文件导入导出、数据库连接、消息队列）
• 通信协议（HTTP/HTTPS、DICOM、HL7、MQTT 等）
• 认证和授权机制
• 数据加密方式（传输中、静态存储）

依赖关系（SBOM）

• 操作系统及版本
• 编程语言运行时及版本
• 所有第三方库和框架（名称、版本、许可证）
• 开源组件清单（特别关注是否有停止维护的依赖）
• 云平台/基础设施依赖（AWS、Azure、阿里云等）
• 硬件依赖（GPU 型号、内存要求等）

AI/ML 组件（如果有）

• 模型架构（CNN、Transformer、RNN、 ensemble 等）
• 模型输入输出规格
• 训练数据来源、规模、时间范围
• 训练数据质控方法
• 性能指标（AUC、灵敏度、特异度、PPV、NPV 等）
• 在不同子群体上的性能差异
• 模型版本控制方式
• 模型更新/回滚机制

清单 3：软件特定风险（Software-Specific Risk Considerations）

N81 要什么：识别和描述软件特有的风险，而不是传统的临床风险。N81 列了一个非穷举的清单，下面是整理后的 checklist：

供应链风险

• 第三方组件是否有已知的停止维护计划？
• 开源库的社区活跃度如何？（贡献者数量、最近更新时间、issue 响应速度）
• 关键依赖是否有商业支持替代方案？
• 供应链上游（训练数据标注外包、云服务提供商）的可靠性评估

网络安全风险

• 已知漏洞扫描结果（CVE 清单、CVSS 评分）
• 攻击面分析（暴露的接口、默认凭证、未加密通信）
• 数据完整性保护（防篡改、防重放、审计日志）
• 更新机制的安全性（签名验证、防回滚、安全启动）

AI/ML 特有风险

• 模型漂移监测机制（性能随时间衰减的阈值和报警）
• 训练数据偏见评估（不同年龄、性别、种族、地域子群体的性能差异）
• 对抗性攻击防御（输入验证、异常检测、对抗训练）
• 数据投毒防护（训练数据来源验证、数据清洗流程）
• 模型可解释性（黑箱模型的决策依据能否被医生理解）

互操作性风险

• 与医院现有系统的兼容性（不同厂商 PACS、EMR 的对接测试）
• 数据格式转换中的信息丢失风险
• 并发使用时的资源竞争（多个医生同时调用 AI 分析）

配置和部署风险

• 不同医院 IT 环境差异导致的性能不一致（防火墙规则、代理设置、时区配置）
• 默认配置的安全性问题（开放端口、调试模式、默认密码）
• 升级过程中的服务中断风险

三、怎么准备这些文档：别重复造轮子

看到上面的 checklist，你可能已经意识到了：N81 要求的东西，和安全团队平时做的 Threat Model、SBOM、架构文档、漏洞评估，大量重叠。 问题只是两套语言还没打通，厂商往往在交两套几乎一样的文档，只是换了个标题。

下面是一份实操指南，告诉你可以怎么"一鱼多吃"。

Step 1：从 Intended Use Statement 开始定边界

不要从"我要交监管文档"开始，从"我要理解这个软件在系统里干什么"开始。回答 checklist 里清单 1 的问题，同时满足：

• N81 的 Intended Use Statement
• 系统边界定义（后面做威胁建模和架构设计的基础）

关键原则： Intended Use Statement 写得越清楚，后面的软件描述和风险识别就越省力。边界模糊的地方，就是审评员会追问的地方。

Step 2：整理现有的架构图和 SBOM

你手上大概率已经有这些东西：

• 系统架构图 / 数据流图
• SBOM（SPDX 或 CycloneDX 格式）
• 第三方组件清单
• 模型文档（Model Card）

具体做法：

• 拿现有的数据流图，给每个节点加一句"这个模块干什么、用什么技术栈"
• 拿现有的 SBOM，按 N81 要求的分类整理（第三方库、开源组件、AI/ML 组件、操作系统）
• 如果有 AI 模型，单独整理一份 Model Card：架构、训练数据、性能指标、版本控制

一个小技巧：N81 不要求特定格式，但建议你在 Software Description 里显式标注 AI/ML 组件。不要让它藏在依赖清单里混过去。监管机构现在对 AI 部分格外敏感，主动标出来反而显得透明。

Step 3：从现有的安全评估导出 Software-Specific Risk

你手上大概率也已经有：

• 威胁建模报告（STRIDE 或 Attack Tree）
• 漏洞扫描报告
• 网络安全风险评估
• 渗透测试报告

做法：把这些报告里的发现，翻译到 N81 的监管语言里。

关键原则：N81 不要求你重新做一套风险评估。它要求你证明你已经考虑了软件特有的风险，并且这些风险被纳入了整体风险管理。所以你可以直接引用已有的安全评估报告，只需要在前面加一页"映射说明"。

Step 4：跟 524B 的 Cybersecurity 文档复用

如果你在做美国市场，524B 要求提交：

• Cybersecurity Management Plan
• SBOM
• 威胁建模文档
• 安全控制实施证据

N81 要求的 Software Description 和 Software-Specific Risk，跟 524B 的文档包高度重叠。建议策略：

• SBOM：一份 SPDX/CycloneDX，同时满足 N81 和 524B
• 架构图/数据流图：同一套图，N81 的 Software Description 里用文字描述，524B 的提交包里放图形
• 威胁建模：同一份 Threat Model，N81 侧重点是"软件特定风险识别"，524B 侧重点是"安全控制怎么 mitigation"，互为补充
• 已知漏洞评估：同一份漏洞扫描报告，两边都引用

唯一需要单独准备的是 Intended Use Statement——524B 不明确要求这个，但 N81 把它作为软件特征化的起点。

四、一个提醒：N81 不是终点

N81 解决的是"怎么描述软件"的问题，但它没有解决"怎么量化软件风险"的问题。它要求你交一份软件的"技术身份证"，但没有告诉你这份身份证上的信息怎么映射到监管决策。

比如 N81 要求你描述 AI 模型的训练数据来源，但它没有说"训练数据覆盖不足到什么程度就不给批"。它要求你列出已知漏洞，但没有说"有几个 CVE 就触发拒绝"。

这些判断仍然是审评员的自由裁量权。N81 只是在要求你把信息交出来，为未来的标准化判断打基础。

从这个角度看，N81 和 SBOM 的运动是同一股浪潮：监管机构意识到，他们无法管理看不见的东西。先把软件的家谱和漏洞摊开在阳光下，才有资格谈动态监控、持续学习、风险分级。

N81 不是一份激动人心的文件， 但它标志着一个重要的转折点：医疗器械监管从"管设备"转向"管软件"的过程中，终于有人意识到，软件需要自己的语言。

ISO 14971 不会消失，硬件风险管理依然需要它。但软件的风险，得用软件的语法来描述。N81 就是在尝试建立这套语法。

下一篇，我们会把镜头拉远，看看 IMDRF SaMD 系列的全图——N10 给了身份，N12 给了分类，QMS 给了质量管理，N41 给了临床评价，N81 给了软件特征化。这五块拼图合在一起，才构成全球软件医疗器械监管的完整地图。

（未完待续）