生成式AI进入医疗器械后，谁负责它每一次变化

医院的信息部门准备在周末更新一套会生成临床文本的软件。旧版本已经完成本地验证，新版本声称回答更完整、速度更快。更新按钮旁边最难回答的问题却不是“功能有没有增加”，而是：星期一重新打开它时，这还是上周被审查过的同一台医疗器械吗？

对于一台传统设备，人们习惯把身份固定在型号、零件和说明书上。软件已经让这种身份变得松动；生成式人工智能又多推了一步。它面对相似输入可能给出不同表达，模型、提示、知识库、过滤器和部署环境中的任何一项变化，都可能改变输出。批准一个产品，似乎不再只是批准一个静止物件，而是要描述一条允许变化、必须监测、可以追责的轨道。

2026年8月18日，美国食品药品监督管理局发布了一份生成式AI医疗器械监管讨论稿，向制造商、临床人员、研究者和公众征求意见，截止日期为10月19日。文件讨论风险评估、上市前评价、上市后监测等问题。最重要的事实或许不是它提出了哪些可能方案，而是它反复说明自己没有做什么：这不是草案或最终指南，不代表政策已经改变，也没有决定现有法律权限是否足够。

所以，这不是一条“FDA已经出台生成式AI医疗新规”的新闻。它是一张尚未填完的责任地图。

当器械不再只有一个答案

医疗器械监管习惯追问几个朴素问题：产品打算做什么，面对什么人群，在什么条件下使用，失败会造成什么后果，提交的证据能否支持这些用途。生成式AI没有取消这些问题，却让每一个问题都变得更难固定。

一个生成文本的系统可能负责整理病历，也可能给出诊断相关信息、生成治疗选项或与患者直接交互。任务名称看起来相近，错误后果却可能完全不同。把一句话写得不够流畅，与遗漏一个危急信号，不应放在同一个风险格子里。FDA讨论稿因此把“系统做什么”与“错误会有多严重”放在风险思考的中心。

更棘手的是输出的可变性。传统软件在相同输入下通常给出可复现结果，测试人员可以列出一组用例，核对通过或失败。生成式系统可能因上下文、随机性、模型更新或外部数据变化产生不同答案。一次测试通过，只能证明那个版本、那个环境和那组输入在当时的表现。它不能自然延伸为“今后所有回答都可靠”。

这并不意味着生成式AI无法评价，而是评价对象需要扩大。模型本身只是其中一层；真实产品还包括界面怎样提示不确定性，医生能否查看依据，系统何时拒绝回答，错误如何上报，医院如何记录版本，以及更新后谁负责重新验证。

一次批准，管不了一生

国际医疗器械监管机构论坛近年的AI工作把生命周期管理列为共同议题。所谓生命周期，不只是产品从开发到上市，还包括部署、监测、更新，最终退出使用。生成式AI把这条时间线从合规文件里的章节，推到了日常运行的正中央。

一台设备上市前可以在预设数据上接受严格评价，但它进入医院后会遇到新的患者构成、新的语言习惯、新的工作流程和新的关联软件。性能可能因为环境变化而漂移，也可能因为团队修复旧问题而改善。关键不是禁止变化，而是让变化留下可验证的边界。

什么变化仍属于原来获准的产品？什么变化需要新的证据？谁能决定更新生效？医院是否知道当前使用的是哪个模型、哪套知识库和哪组安全规则？一旦出现伤害，能否还原当时的配置与输出？这些问题共同决定所谓“上市后监测”是主动治理，还是事故发生后才打开的一只黑箱。

FDA讨论稿还没有给出最终答案。把其中的设问写成确定规则，会制造一种虚假的制度进度。更准确的理解是，监管者正在公开界定问题空间：风险怎样分层，上市前需要哪些证据，上市后怎样发现性能变化，不同主体分别掌握哪些信息。

医生不能只剩下“最终负责”

医疗AI讨论中有一句很方便的话：系统只是辅助，最终由医生负责。它听起来尊重专业判断，却可能把复杂的产品责任全部压回诊室。

医生当然需要判断，但判断必须有条件。如果界面把不确定答案呈现得像确定事实，如果模型更新没有通知使用者，如果医院没有时间和资源做本地验证，如果开发者无法解释错误来自哪一层，那么“人类在环”就可能只是责任在环。医生被要求承担最后决定，却没有获得足以质疑系统的信息和组织支持。

患者的位置更容易被遗漏。患者可能只看到一段自然流畅的文字，不知道它来自固定规则、统计模型还是生成系统，也不知道内容是否经过人工复核。透明不等于向患者倾倒技术术语，而是让他知道谁在作判断、系统扮演什么角色、发生错误时去哪里申诉和更正。

新加坡2026年更新的AI医疗指南把责任清晰、透明和部署风险列为重点。这不能直接替代美国规则，也不能证明某一种治理设计已经成功，但它说明相似矛盾并非单一机构的想象：当AI进入临床，技术性能之外，责任分配本身就是安全条件。

监测什么，决定我们能看见什么

上市后监测常被理解为继续收集准确率。对生成式系统，仅有一个总体分数可能远远不够。平均表现会遮住少数高风险场景，也会遮住不同人群、语言和机构之间的落差。系统可能在常见任务上稳定，却在罕见病、复杂用药或非标准表达中表现脆弱。

更完整的监测至少需要区分：输出错误有没有到达患者，临床人员是否发现并纠正，错误是否集中在某类人群，更新是否引入新的失败模式，使用者是否因为警报太多而忽略真正危险的提示。这里没有一个指标可以独自代表安全。

数据权利也随之出现。监测需要真实使用数据，但医疗数据不是可以无限回收的免费燃料。谁可以把临床交互用于改进模型，患者是否知情，跨医院汇总时如何保护隐私，外部供应商能保留多久，都是生命周期治理的一部分。一个系统越需要持续学习，越不能把持续收集数据当作自然权利。

“像医生一样考试”还不够

生成式AI很容易被放进考试叙事：给它一套题，看它是否达到医生水平。考试可以提供可比较的切面，却无法复制临床工作的完整责任。真实医疗不是连续回答彼此独立的问题，而是在不完整信息中追问、复核、交接、记录和承担后果。

即使系统在某类题目上达到高分，也不能自动推出它适合部署。测试集是否代表目标患者，题目有没有泄漏进训练数据，评分是否只看最终答案而忽略理由与不确定性，临床人员如何使用输出，都会改变结果。受控评测回答“它在这把尺子上得了多少分”，部署治理还要回答“这把尺子漏掉了什么”。

因此，能力评价与产品监管不能互相替代。能力是系统可能做成什么，产品证据是它在具体用途、具体界面和具体责任链中是否可接受。自然语言越像人，越需要提醒自己：流畅不是可靠性的计量单位。

批准的应当是一条可追踪的变化轨道

生成式AI进入医疗器械后，监管也许不能只给一个静止版本盖章。它更需要审查一套变化机制：哪些更新被预先界定，更新前后如何比较，哪些风险必须重新评价，谁能暂停上线，怎样保存旧版本和事故记录。

这不是降低标准，恰恰是把标准放回时间之中。设备在实验室里通过一次测试，只是生命史的一个节点；真正影响患者的是它后来怎样变化、谁看见变化、谁有权说不。

这里还藏着采购制度常常忽略的一层。医院购买软件时，容易把注意力集中在上线功能、接口和价格，却把后续更新视为普通维护。对于会改变临床输出的系统，维护本身可能就是风险事件。合同需要说明供应商何时通知更新、医院能否延迟部署、历史版本保存多久、出现严重错误时谁提供数据和技术人员。否则，监管文件要求的可追踪性会在采购与运维交接处断掉。

小医院承受的压力尤其值得看见。大型医疗中心可能拥有算法评测、网络安全和质量管理团队，基层机构却常由少数信息人员同时维护许多系统。如果安全依赖每家医院独立完成复杂验证，资源差异就会变成患者风险差异。监管如何定义制造商必须提供的证据、通用监测工具和更新说明，不只是技术效率问题，也关系到不同地区是否有能力安全使用同一产品。

这也解释了为什么“持续监测”不能成为无限延后上市前证据的借口。不能因为产品以后还会收集数据，就降低进入临床前的验证要求；同样，也不能因为上市前测试漂亮，就假设部署后的变化无需再看。两段证据承担不同责任：前者决定能否开始使用，后者决定使用是否仍在可接受轨道内。

回到那次周末更新。信息部门最终需要的不会只是厂商发来的一句“性能提升”。它需要一个能被审计的版本说明、一套本地复核条件、一条出错后的回退路径，以及明确到人的责任。医生星期一打开的也许仍叫同一个产品，但制度必须能够回答，它在哪些意义上已经不同。

FDA讨论稿没有替医院回答这些问题。它的价值，是拒绝假装这些问题已经被旧框架自动解决。生成式AI最擅长给出文字答案，而医疗治理此刻更需要做的，是把每一次变化重新变成可以追问的事实。

来源与边界

• FDA讨论稿与说明页用于确认发布日期、征询范围、主题和免责声明；文件不是草案或最终指南，不代表政策已经改变。
• IMDRF材料用于说明AI医疗器械生命周期是跨监管体系的共同议题，不代表其认可FDA的具体设想。
• 新加坡AI医疗指南2.0公告用于提供另一法域对责任、透明和部署风险的处理背景，不作法规等同。
• 本文不评价具体产品，不提供诊断、治疗或合规建议，也不把监管讨论写成疗效证据。