-AI 医疗软件是 II 类还是 III 类？
老D侃械系列，转载请注明
我们老板有个癖好，有人把他惹得大怒时，他一上头，就会把鞋脱下来砸那个人，当然，是很有艺术的那种，砸中人却不伤人。而这次，我倒了霉，起因竟然是公司刚开发的一款AI医疗软件，我坚持认为是III类，结果审评意见认为是II类，主席多花了不说，还耽误了好长时间的项目进度。为了不让更多人踩雷，后来我就赶紧复盘问题点，写下了这篇。
先别问 II 类还是III 类 先判断是不是医疗器械，再讨论第几类。算法是否“聪明”不是分类依据；预期用途、临床性能和失效风险才是。
产品会上的场景
产品经理打开演示，兴奋地说“它用了 AI，很高级吧？”法规同事反问：“高级不等于分类答案。它给谁用、输出什么、会不会影响诊疗决定？”屏幕上的模型名称忽然不那么抢戏了，真正要写清的是它在临床流程里扮演什么角色。
先用两个小例子，避免一上来就猜类别
以下例子只用于理解逻辑，不替代分类结论。真正的界定必须看产品的完整预期用途、输入输出、临床流程、风险分析和适用规则。
· 例子 A：医院排班、预约、库存管理软件，即便用户是医院，也不必然是医疗器械；关键在于它是否声称用于疾病诊断、治疗等医疗目的。
· 例子 B：影像软件若只是把图片放大、旋转、归档，和它“自动提示可疑病灶并给出风险分级”是不同的功能和风险等级，不能只按“都是看影像”处理。
· “医生最终决定”也不是万能答案。若软件输出实质性影响诊疗，仍需分析医生是否可以独立复核、错误输出会造成什么后果、软件是否在关键环节介入。
· II 类还是 III 类没有一句话公式。除了目录映射，还要看功能、用途、与人体接触/介入情况（如有）、风险程度及失效后果；还不确定时应走正式分类界定。
先问“它替谁做了什么”，比先问“它用了什么模型”更重要
同样是人工智能模型，放在不同位置，监管含义可能完全不同。一个模型帮医生整理病历、把语音转成文字，和一个模型读取影像后提示病灶、给出风险等级，不是同一种任务。前者可能更接近通用信息处理；后者已可能影响诊疗判断。
所以产品说明不要从“我们用了大模型、准确率很高”开始，而要从最朴素的问题开始：谁输入什么？软件输出什么？谁看这个输出？他会据此做什么？如果输出错了，最坏会发生什么？把这五句话写清，后面的属性和类别讨论才有地基。
“仅供医生参考”为什么不够？
这句话可以说明产品不是完全取代医生，但它不能自动消除软件对临床决策的影响。关键要看医生是否有足够的信息和能力独立核验；软件输出是否在流程中被高度依赖；以及错误输出是否可能造成延误、漏诊、误治或其他风险。
更务实的做法是把边界做进产品：明确适用人群和数据质量要求，提示不适用情形，显示必要依据或置信信息（如适用），规定人工复核流程，并用验证资料证明软件在声明场景下的性能。具体技术做法要与产品特性和适用指导原则匹配。
软件/AI 团队最容易漏掉的 4 件事
· 版本：上线的算法、训练完成的算法、测试使用的算法必须能区分；不能只用一个模糊的产品名覆盖所有版本。
· 数据：数据来源、代表性、标注质量、数据划分和偏倚风险要被认真评估，不能只看总体准确率。
· 更新：每一次模型、参数、输入处理、输出规则或网络环境的变化，都要做变更影响评估。
· 网络安全：账号权限、数据传输、漏洞、日志、异常恢复等不是“上线后再说”的 IT 小事，而与医疗器械安全性相关。
先做 7 个“是 / 否”判断
Q1 它明确用于疾病诊断、监测、治疗或其他医疗目的吗？
如果是：进入医疗器械属性评估。
如果否：先核对是否只是通用行政、沟通或非医疗健康管理功能。
Q2 输出会不会进入临床诊疗决策链？
如果是：继续分析用户如何依赖该输出、能否独立复核及失效后果。
如果否：仍需避免市场文案把产品重新推入诊疗用途。
Q3 输入、输出和目标用户写清了吗？
如果是：把数据来源、输出形式、医生/患者角色和使用时点锁定。
如果否：先暂停“分类猜题”，补完整预期用途说明。
Q4 软件在做提示、辅助分析，还是直接给出诊疗结论/控制动作？
如果是：风险通常需要更严谨评估；不能只靠“仅供参考”一句话降风险。
如果否：记录限定条件，防止上线与宣传突破该边界。
Q5 版本、算法更新、数据集和性能边界受控吗？
如果是：纳入软件生命周期、网络安全和算法变更策略。
如果否：先解决版本可追溯和性能验证，再谈持续迭代。
Q6 能在分类目录、规则和相关指导原则中找到明确映射吗？
如果是：按目录/规则与具体风险作类别判断，并保留比对证据。
如果否：不要把“软件一般是 II 类”当答案。
Q7 仍然说不准吗？
如果是：准备用途、原理、输入输出、场景、风险分析和同类对比，走正式分类界定。
如果否：不要用营销文案或竞品传闻替代技术界定。
最后一步 一张真正有用的界定表，应该让临床、算法、法规三方对“软件输出用于什么”写出同一句话。写不出，就先别定类。