医疗 AI 治理不是上线前签一张风险表，而是从需求、数据、开发、验证到运行和退出的持续控制。最小闭环包括：明确预期用途，识别受影响人群，用本地数据和真实工作流验证，记录版本与责任，上线后监测性能和安全事件，并在证据不再成立时暂停或回滚。
WHO 的医疗 AI 指南把自主、福祉与安全、透明、责任、公平和可持续列为核心原则；NIST AI RMF 用 Govern、Map、Measure、Manage 四个函数组织风险管理。下面把这些原则转换成医疗机构和开发团队可以执行的检查项。
一、从预期用途开始，而不是从模型能力开始
预期用途应写成可验证句子：谁，在什么环境，使用哪些输入，获得什么输出，为哪个决定提供何种程度的支持。还要同步写出非预期用途和禁用场景。
例如，“帮助急诊医生基于已完成的检查对某类患者进行队列优先级提示”，比“用 AI 提升急诊效率”更可评估。前者能够定义目标人群、输入完整性、参考标准、错误后果和工作流；后者只是一句愿景。
用途发生变化时，旧证据不一定继续有效。把后台文书模型改成患者问答，或把风险提示改成自动处置，都应重新完成风险与合规判断。
二、建立分层风险分类
可以用两个维度做初始分层：输出影响的决定，以及错误后果的严重程度。
| 层级 | 示例 | 最低控制 |
|---|---|---|
| 较低风险 | 排班建议、内部文书格式化 | 数据保护、质量抽检、人工可修改 |
| 中等风险 | 患者消息草稿、病历摘要、检查队列提示 | 本地验证、证据引用、专业人员确认、持续监测 |
| 较高风险 | 诊断、治疗或高后果分诊支持 | 临床与监管评估、严格门禁、可用性研究、上市后监测 |
该表只是治理起点，不是法律分类。一个功能是否构成医疗器械，以及适用何种准入路径，必须根据司法辖区、产品声明和具体功能判断。
三、验证数据必须匹配本地人群与流程
供应商报告的平均性能不能自动迁移到本地。验证集应覆盖：
- 目标疾病谱、患病率和病例难度；
- 年龄、性别、语言、残障及机构关注的其他亚组；
- 设备厂商、采集协议、科室和使用环境；
- 缺失、噪声、边界病例和系统不可用状态；
- 实际工作流中的人工行为与时间压力。
数据拆分应防止同一患者或高度相关记录跨训练与测试集泄漏。参考标准应说明由谁、按照什么规则产生，以及存在分歧时如何处理。
四、指标必须对应临床后果
不要只报告 Accuracy 或 AUC。应根据任务同时选择：
- 分类：敏感度、特异度、阳性与阴性预测值、校准；
- 排序：不同阈值下的召回、等待时间和新增工作量；
- 生成：事实新增、关键遗漏、证据一致性和严重度；
- 公平：各关键亚组的性能、校准和失败类型；
- 工作流：任务完成时间、人工覆盖、告警疲劳和不可用回退；
- 运行：超时、错误率、漂移、投诉和安全事件。
阈值应在看结果前确定，并写明为何与业务和患者风险相匹配。平均值不能掩盖高风险亚组或少量严重错误。
五、单独评估人机交互和自动化偏见
FDA 等机构的透明度原则明确关注人机团队表现。模型离线正确，不代表用户能在真实界面中正确理解并采取行动。
可用性测试应观察：用户是否知道 AI 的预期用途；能否找到证据和局限；是否把置信度误解为正确概率；何时接受或覆盖建议；告警是否过多；模型不可用时能否继续工作。
人工复核也需要指标。若使用者在压力下几乎总是接受默认建议，“有人在环”并不能自动降低风险。
六、把透明度做成产品能力
透明度不是公开模型全部源代码，而是让不同受众获得做决定所需的信息：
- 临床用户：用途、输入要求、输出含义、性能、局限和回退；
- 患者：AI 在何处参与、数据如何使用、如何提出异议或联系人工；
- 管理与采购：验证人群、亚组结果、更新策略、事件响应和退出安排；
- 运维与审计：模型、数据、Prompt、配置、访问和变更记录。
已知失败模式和数据缺口必须与优势一样容易被找到。FDA、Health Canada 与 MHRA 的原则还建议持续提供模型、数据、性能监测和风险管理更新。
七、用四个函数组织治理闭环
Govern：确定责任与政策
建立跨职能负责人、风险分级、审批权限、供应商要求、数据政策、事件分级和停用权限。高风险项目不能只有技术团队签字。
Map：描述场景与受影响者
绘制输入、输出、用户、患者、依赖系统和失败传播路径。记录谁可能受益，谁可能因数据不足、无障碍问题或资源差异受到不成比例的伤害。
Measure：生成可复现证据
冻结测试集、参考标准、模型与配置，报告总体和亚组指标、置信区间、严重错误及人机结果。生成式 AI 还应测试虚构、隐私、偏倚和不安全内容。
Manage：决定上线、限制、回滚或退出
把风险与收益证据映射到明确决策，确定监测阈值、责任人、响应时限和替代流程。无法降低到可接受水平的风险应导致限制用途或不部署。
八、管理模型、数据和 Prompt 更新
模型更新可能改变输出风格、拒答、事实错误、亚组表现和延迟。生产系统应固定可识别版本，并记录：
模型与供应商版本
Prompt / 系统指令版本
检索库与医学知识版本
特征和数据处理版本
阈值与后处理规则
部署时间、批准人和回滚版本
每次重大变更都要重跑回归测试。若采用可持续更新的医疗器械软件，还需根据适用监管要求准备变更控制和生命周期资料。FDA 2025 年相关文件目前是草案和非约束性建议，不能把它写成已经生效的强制规则，但其中的总产品生命周期思路仍可作为工程参考。
九、设计上线后的监测与事件响应
监测计划应在上线前完成，至少包含：
- 输入分布和数据质量变化；
- 总体与关键亚组性能代理指标；
- 人工覆盖、投诉、延误和严重错误；
- 模型、接口、知识库和依赖服务变更；
- 隐私、访问控制、提示注入和供应链事件；
- 触发调查、限制、回滚和停用的阈值。
不是所有真实结果都能立即获得标签。团队可以组合延迟标签、人工抽样、覆盖行为、投诉和数据漂移信号，但必须说明这些代理指标的局限。
十、采购或上线评审的十二个问题
- 预期用途和明确禁用场景是什么？
- 功能是否需要医疗器械或其他监管判断？
- 训练、验证和本地数据与目标人群是否匹配？
- 总体、亚组和严重错误结果是否公开给评审者？
- 输出如何影响临床或患者行为？
- 使用者能否看到依据、局限和不确定性？
- 谁审核、谁签署、谁对事件负责？
- 患者数据发送到哪里，保存多久，是否用于再训练？
- 版本更新前后如何测试、批准和回滚？
- 系统不可用或证据失效时如何退出？
- 上线后监测哪些信号，多久复审一次？
- 供应商终止服务时，数据和业务如何迁出？
医疗 AI 的治理目标不是消除所有风险，而是让风险、证据和责任可见，并使组织能够在条件变化时及时限制或停止系统。应用全景可参阅AI 在医疗领域有哪些应用，文书场景可继续阅读生成式 AI 病历摘要与临床文书指南。