临床AI跑得比安全监管更快：德累斯顿工业大学《自然》综述敲响警钟

对医院和医疗系统而言，重要的不只是判断工具能否生成看似合理的文字，还要回答以下问题：

• 谁有权使用该工具，可以用于哪些任务？
• 系统能够访问哪些数据，数据会被传输和存储在哪里？
• 临床人员必须如何核验AI输出？
• 如果AI辅助生成的病历或建议出现错误，谁承担责任？
• 出现风险时，机构如何调查、暂停或撤回该工具？

如果这些问题没有清晰答案，AI的“智能”就可能掩盖流程上的空白。

两层监督架构：机构治理团队＋集中式安全中心

为强化责任链条，研究者提出了相互配合的两层监督模式。

1. 医疗机构内部的AI治理团队

医疗机构应设立专门的AI治理团队，负责审批AI工具、开展本地评估、明确使用边界和责任，并监督工具投入运行后的表现。

这种安排能够让AI决策与具体机构的患者群体、临床流程、信息基础设施和专业义务保持一致，而不是只依据开发商提供的通用测试结果。

2. 集中式AI安全运营中心

综述还建议建立集中式AI安全运营中心，即AI Security Operations Center（SOC）。这类中心可以跨机构识别安全事件、共享威胁信号，并协调应对措施。

其逻辑在于：一个医疗AI系统遭遇的攻击或故障，可能暴露出其他医疗机构同样存在的系统性漏洞。集中式机制有助于把单个机构的经验转化为更广泛的安全情报。

两层机制结合起来，既保留医疗机构对临床使用的本地责任，也能形成跨机构的安全协作网络。

为什么传统医疗器械监管可能不够用？

传统医疗器械监管框架大多建立在一个前提上：产品在评估后相对稳定。但临床AI软件可能会随着模型更新、数据分布变化、工作流程演变或攻击手段升级而改变其行为和风险水平。

因此，在某个时间点完成审批或评估，并不能自动证明一个持续变化的系统在之后所有场景中都安全。德累斯顿工业大学研究人员围绕医疗AI监管开展的其他工作也指出，监管科学需要跟上快速发展的医疗技术和人工智能。

对医疗机构来说，这意味着部署不应被视为“已经验证安全”。上线后仍应持续检查系统的性能、安全性、网络安全、隐私保护和公平性，并建立事件报告、调查和必要时暂停系统的机制。

此外，现有证据显示，正式获得医疗器械批准的临床AI工具仍只是有限的一部分。缺乏正式批准并不等于工具必然有害，但意味着机构不能把使用AI视为天然经过充分验证，而应根据具体用途和临床环境开展独立评估。

患者知情同意，也是技术安全的一部分

这场讨论并不只关乎算法和服务器，也关乎患者是否真正知道AI正在如何参与自己的医疗服务。

以AI病历记录工具为例，澳大利亚临床使用指南要求，患者应被告知AI系统的用途、使用范围、潜在益处和风险，以及安全性或性能监测安排。指南同时明确，使用AI辅助完成的医疗服务和病历，责任仍由临床人员承担。

澳大利亚全科医学专业指导还强调，医生应在使用AI记录工具前了解并测试其功能，在每次使用前取得患者同意，保护存储的数据，并确保最终病历准确反映诊疗内容。

近期报道显示，澳大利亚不同医疗机构在获取患者同意方面存在明显差异，有些机构仅依靠候诊室告示；澳大利亚医疗监管机构也强调，临床人员必须核查AI生成的所有输出是否准确。

这些情况说明，知情同意不能只是流程中的一个勾选框。患者需要获得足够、易于理解的信息；临床人员需要充分了解工具的能力和局限；而最终的医疗判断与责任必须继续由临床人员承担。

现有证据并不能说明澳大利亚范围内“不充分同意”或“临床人员理解不足”究竟有多普遍。但这些案例确实进一步支持了综述的整体判断：透明度、人类监督和机构问责是实际的安全控制措施，而不是系统上线后再补充的行政手续。

给医疗机构的现实启示

这篇综述并非反对临床AI，而是在提出一套更高的部署标准。大语言模型可以支持有价值的医疗工作流程，但医疗机构必须把它们视为会变化的“社会—技术系统”，而不能当作普通软件工具来管理。

在部署前后，医疗管理者都需要做好几件事：评估模型和具体用途，保护周边IT基础设施，培训使用者，向患者解释AI是否参与医疗服务，持续监测真实环境中的表现，并明确系统出错时谁有权介入和暂停使用。

如果这些控制措施尚未到位，那么临床AI的应用就可能继续跑在安全监督之前。真正值得信赖的医疗AI，不仅要能给出答案，还必须处在清晰的责任链、持续的监测体系和可被追究的临床治理之中。