半天追 AI 模型可追溯性：一个 CAPA 暴露的数据血缘断裂
把 AI 模型当文档对待是危险的。作者在一家医疗器械 CMO 公司任 CMO（合同制造组织），一个针对数据血缘缺口打开的 CAPA（纠正与预防措施）滚成了缺失文档问题，又暴露了变更控制和供应商可追溯性的薄弱点。这是发生的事、改了什么，以及阻止循环重复的小自动化。
触发器：看似简单的 CAPA
工程师标记了设备端推理行为与验证测试台之间的差异。CAPA 看起来常规：复现、找根因、纠正数据集或模型权重。很快它变成：无法识别哪个训练数据集产生了已部署的模型（没有 manifest，只有文件夹名）；运行间的预处理步骤不一致（不同标签编码、一个静默的重采样步骤）；模型二进制在共享位置被覆盖，没有不可变模型注册表条目；变更控制只引用发布工单号，不引用数据集或容器镜像摘要。
始于数据血缘的发现变成文档发现，再变成变更控制发现。审计方会称之为可追溯性缺口。EU AI Act 以及公告机构对高风险 AI 组件越来越要求可追溯性：必须展示模型版本如何绑定到数据、训练流水线、验证证据和批准记录。他们没有这个关联。
为什么 CMO 视角不同
在 CMO 处理组件和供应商网络的场景里，"模型"通常是供应商提供的（分析、检验分类器、COA 的 OCR），或由多个供应商拼接的数据集构建。常规 eQMS 流程假设设备制造商控制整条流水线，很少适配供应商密集的现实：次级供应商提供数据集或模型；进货检验依赖供应商模型做自动化检查；供应商 COA（而非内部数据集）喂给训练语料。所以当可追溯性要求说"把模型链到数据、验证和批准"时，实际工作是：链接供应商 COA → 数据集 manifest → 模型产物 → CAPA/变更控制，这条链必须活且可审。
改了什么
聚焦两个目标：让映射显式、让证据机器可读，这样自动化才能帮忙。
训练/部署时捕获不可变产物。每个构建强制模型注册表条目：模型名、语义版本、容器镜像摘要、git commit 哈希、训练任务 ID。数据集 manifest 存校验和（文件级 SHA256）、来源供应商 ID、接收日期、预处理步骤。
把产物链到质量记录。变更控制和 CAPA 模板现在把模型注册表 ID 和数据集 manifest 哈希设为必填字段；验证报告必须包含测试所用模型 ID 和引用的数据集 manifest。
收紧供应商证据捕获。进货 COA 和供应商数据落地时，往 Postgres 表写一条记录：供应商 ID、文件摘要、QA 团队下游使用的入库工单号。
更新 SOP 与签字规则。SOP 澄清谁能批准模型变更、何时必须人工签字（模型变更不许自动关闭）；加 CAPA 驱动的风险评估步骤：小的数据标签修复可记录，较大的预处理变更升级到变更控制。
保持链条活跃的小自动化。Python 脚本给新数据集落哈希、建 manifest、把注册表条目推进 Postgres；Grafana 面板展示模型 → 数据集 → 变更控制链接，部署的容器摘要缺数据集 manifest 时告警。大赢是强制关联：除非模型变更引用了数据集 manifest 和变更控制记录，否则不能提升到生产。
对自动化 CAPA 的态度
对 CAPA 的"自动关闭"功能和黑盒 AI 引导修复持怀疑态度，受控协助可行：AI 辅助 CAPA 可以基于产物差异建议可能根因（标签漂移、预处理不匹配），但工程师必须批准并签署 CAPA 内容；自动化 CAPA（如自动创建的取证请求）对一致性有用，但任何影响患者面对或检验自动化的关闭都必须人工审查。姿态简单可辩护：AI 提议、人批准。也因为把 AI 输出绑回不可变产物（manifest 哈希、容器摘要）和批准轨迹，技术上可审计。
不会再手工做一遍
半天追链接不可扩展。接进已有 incoming inspection 的 Python + Postgres + Grafana 栈：入库任务创建数据集 manifest 并存校验和；CI webhook 创建带容器摘要和 git 哈希的模型注册表条目；Grafana 面板暴露不匹配（部署摘要缺 manifest、变更控制缺模型 ID）；轻量 checklist 强制人工签字点。