AI 与 Software as a Medical Device

AI 在医疗领域带来了真实机会，但在 Software as a Medical Device 的语境中，讨论不能只从能力开始，而必须从安全、intended use、可追溯性和证据开始。

这也是为什么 SaMD 会从第一批架构决策起，就改变围绕 AI 的设计纪律。一个功能“有用”并不够。系统还必须能够支持验证、风险控制以及贯穿整个生命周期的责任闭环，并满足临床、监管和质量体系的要求。

在 SaMD 环境中，什么发生了变化

在很多数字产品中，不确定性可以通过迭代和用户容忍来吸收。

但在 SaMD 环境里，不确定性的分量完全不同，因为软件行为可能影响临床或健康相关决策。这意味着架构必须考虑：

• intended use 与临床场景
• 需求、控制与实现之间的可追溯性
• 在预期场景和边界条件下对行为进行验证
• post-market 监测与受控变更管理
• 在风险要求下保持明确的人类监督

这些并不是次级的文档任务，而是直接塑造系统本身的核心要求。

为什么 AI 会进一步抬高门槛

引入 AI，尤其是 generative AI，会进一步提高设计纪律的要求，因为输出可变性、上下文敏感性以及模型演进，都可能以细微方式影响可靠性。

这并不意味着 AI 应该被回避，而是意味着它必须在正确的约束和正确的证据模型下被引入。

这通常要求：

• 明确界定 AI 能做什么、不能做什么
• 区分辅助功能与更高风险的决策支持功能
• 设计反映真实使用条件的验证策略
• 在 use case 需要时提供 explainability 或 traceability
• 建立强有力的质量管理与文档纪律

真正的产品与监管问题是什么

错误的问题是：“我们能不能把 AI 加到这个医疗产品里？”

更好的问题是：“我们能否证明，这种 AI-enabled 行为在整个产品生命周期中是可控、可验证且可治理的？”

这个区别非常关键。它把关注点从功能兴奋感转向证据、责任与风险可接受性。在受监管领域，这正是“一个吸引人的概念”和“一个可部署的医疗级解决方案”之间的差别。

一个务实的方向

最强的做法通常是分阶段、风险感知式的，而不是一开始就追求最大化。

这意味着：

• 先从辅助型或 workflow-supporting 能力开始，因为其风险更清晰，也更容易界定
• 从一开始就把 traceability、risk control 和 validation 嵌入交付过程
• 明确哪些环节必须人工复核，哪些必须保持非自动化
• 为 post-market learning 进行设计，同时避免失控的 model drift
• 尽早让架构决策与监管、临床和质量相关 stakeholder 对齐

AI-enabled SaMD 的机会非常可观，但架构必须尊重其所服务的领域。

做到这一点时，AI 才会从“一个有前景的附加功能”，真正变成“临床上可信、监管上可接受”的能力。