企业模型仓库采购经常把“来源可信”写成一个勾选项：模型来自公开站点、供应商交付或内部训练，因此可以进入仓库。生产审计真正要问的是，当前运行的制品是否就是当时获取或训练的对象，中间经过哪些转换，依赖和使用边界是什么，以及谁在什么证据下批准。

追溯目标：从任一运行服务反向找到确定制品、来源、处理、依赖、评测和批准；也能从一个制品正向查看分发和使用。可信是可复核判断，不是仓库中的静态标签。

来源可信不能停在下载页面和人工备注

下载地址只能说明某个时间访问过一个位置，页面内容、文件和版本都可能变化。供应商邮件或交付说明给予背景，也需要与实际制品身份关联。内部训练同样不能天然视为可信：数据、代码、环境和导出过程如果未记录，团队仍无法重现或解释。

来源记录至少包含取得方式、给予方或责任团队、时间、原始标识、允许用途、必要条款与实际文件校验。本文不对许可证作法律判断，具体使用范围由采购、法务和业务结合条款确认。仓库负责保存关联证据和状态，不能用一个“已审核”字段替代专业判断。

模型制品是供应链的一部分，可参考 软件供应链安全的制品与准入 理解证据思路，但不能机械照搬代码和镜像流程。模型还涉及数据、评测和输出风险，需要增加符合其生命周期的记录。

先给每个制品建立不可混淆的身份

文件名、模型名称和目录都可能重复。制品身份需要结合校验、大小、格式、来源版本和处理关系，确保团队讨论的是同一对象。哈希可以帮助判断文件是否变化，却不能单独证明来源合法、安全或适用；它只是证据链中的一个环节。

转换、量化、合并、微调、格式变化或重新打包后，应创建派生制品并关联上游。若处理工具、参数或依赖影响运行，也要保留必要信息。直接覆盖原文件会切断来源和评测关系，使旧批准错误地附着到新对象。

身份还要贯穿分发。服务节点、对象存储、缓存和离线包使用同一资产标识或可映射标识，运维才能从运行实例反向查到仓库记录。若部署系统重新命名文件，关联关系需要在发布记录中保留。

证据包记录获取、处理和校验过程

图中的证据链不是一张“顺利获得”证书，而是一组可查询关系。来源、制品、处理、依赖、评测、批准和分发分别由合适系统记录，仓库连接这些真源。

证据包可以按以下分层组织：

证据可能来自采购系统、训练平台、代码库、评测平台和发布平台。模型仓库不必复制全部内容，但应保存稳定引用和状态，且在源记录不可用时有处理策略。自由文本链接容易失效，采购时应验证关联能否查询和导出。

许可证与依赖属于采购边界

外部模型可能有不同使用、修改、分发或商用条件，具体结论需要法律和采购审查。仓库应记录适用条款版本、审查结论来源、允许用途和限制，而不是自行推断。条款变化或使用场景变化时，触发复核，不把历史批准无限沿用。

依赖不止软件包。模型可能依赖适配器、配置、分词与预处理、提示模板、知识资产或运行框架。哪些对象需要进入追溯取决于是否影响重现、结果和使用边界。无关细节不必全部复制，但影响生产判断的关系不能只留在个人经验里。

供应商交付还要明确后续更新和漏洞通知、替代版本、重新评测及退出责任。采购合同不必承诺绝对安全，却应让企业知道制品发生变化时谁通知、谁给予材料、谁执行验证。

准入失败要隔离而不是覆盖旧版本

来源缺失、校验不一致、依赖不完整、许可证待确认或评测未顺利获得的制品，应进入隔离或待补状态，不能直接替代已批准版本。仓库需要阻止生产发布权限，同时保留问题和责任人。删除失败制品会失去调查证据，覆盖旧版本则可能破坏生产回滚。

补齐证据后重新提交，新的判断与原失败记录关联。若业务必须紧急使用，应走例外审批，限制环境、主体和期限，增加观察与退出条件。例外不是把状态改成“可信”，而是明确在缺口存在时由谁接受何种风险。

制品扫描、签名或校验可以增强证据，但任何单项都不能保证安全。企业需结合模型来源、数据与业务风险、评测和运行控制做综合判断，不将工具结果扩大成合规或无风险承诺。

抽样追溯验证证据是否真的可用

采购POC可以随机选择一个已分发测试制品，从服务实例反向查询仓库身份、来源、处理、依赖、评测和批准。随后从来源记录正向找到所有派生版本和已知分发。双向都能完成，才说明关系可用于事故和审计，而不是只在页面上展示字段。

模型资产字段可参考 模型资产管理的版本与权限治理 。POC还应故意制造一个校验不一致或来源缺失的测试制品，确认它被隔离、不能发布，并能在补齐或撤回后留下历史。

未参与搭建的审计或采购人员根据证据包重新判断。若必须依赖平台专家口头解释、后台数据库查询或不可导出的页面，追溯能力需要补测。报告记录原生、集成、定制和人工步骤。

运行变化仍需保持追溯关系

模型进入生产后，路由、配置、适配器和运行环境可能变化。仓库的制品身份保持不变，但发布记录应关联这些变化，使故障团队判断问题来自模型制品还是运行条件。不要因为服务端点不变，就默认底层资产没有变化。

灰度与回滚也要使用追溯标识。新旧版本同时运行时，每次请求或指标能关联实际版本；回滚后确认旧制品和配置恢复，新的分发副本被控制。否则评测与线上结果无法对应。

下线时保留必要追溯。停止新分发、确认依赖迁移、撤销权限、处理缓存和离线副本，再按制度归档或删除制品。外部交付无法远程撤回时，应在合同和登记中保留接收方、用途和更新责任。

权限设计保护证据本身

上传制品、修改元数据、批准来源、调整许可证结论、关联评测和允许发布是不同动作，应由不同角色按职责执行。若一个管理员能修改全部证据而无历史，追溯链很容易被事后重写。

变更记录包含原值、新值、理由、操作人和时间。对关键身份和校验字段，可采用不可直接覆盖的版本化记录；修正错误时新增更正关系，而不是删除历史。查询和导出也需授权，避免证据包泄露敏感信息或许可证材料。

审计日志本身需要保留和备份边界，但不在项目文档记录真实路径、密钥或内部制品。采购验证使用测试数据和脱敏记录，生产细节由企业受控系统管理。

退出平台时证据链不能丢失

仓库迁移需要的不只是下载文件。资产身份、派生关系、来源、依赖、评测、批准、权限和分发记录也要按必要范围导出。若只能取得制品而无法取得关系，企业会在新平台重新人工判断，增加迁移风险。

POC可导出一个测试资产及其证据包，在离线环境验证字段和关系是否可读。专有格式不一定不可接受，但供应方应说明文档、转换和支持责任。历史记录保留范围结合制度与合同，不要求无限迁移。

来源可信的最终价值，是当模型发生问题时企业能迅速回答“它是谁、从哪里来、经历什么、影响哪里、谁批准”。 页面上的绿色标签只有连接这些证据时才有意义。

从运行制品开始双向追溯

随机选取一个在产或测试服务，从运行实例反向追到模型制品、来源、处理、依赖、评测和批准，再从该制品正向查所有分发。对断点分别标记缺少真源、关联、权限还是流程。候选仓库需要用一个失败准入样本证明隔离和历史保留，完成后再进入采购比较。

常见问题

文件哈希是否足以证明模型来源可信？

不足。哈希可以证明两个文件是否一致，或验证传输后是否变化，但无法说明文件最初来自谁、是否允许使用、处理过程是否可靠、依赖是否完整，也不能证明模型适合某个业务或不存在安全风险。它是制品身份的重要组成，不是全部可信结论。

企业应把哈希与来源记录、给予方或训练任务、条款审查、派生过程、评测和批准关联。若只知道某个哈希“曾被认为可信”，却找不到当时对象和依据，审计仍无法复核。采购平台时验证这些关系能否查询、版本化和导出。制品重新打包或转换后应生成派生关系，不能沿用旧哈希对应的批准。

外部下载的模型可以直接进入生产仓库吗？

不宜直接进入可发布状态。可以先进入隔离或待核验区域，记录来源和身份，完成必要的许可证、依赖、安全、评测和业务适用性检查，再由相应角色批准进入指定环境。检查范围取决于数据、业务和风险，不设统一清单或阈值。

紧急试验也应限制在测试环境、独立凭据和非敏感数据内，设置所有者与退出日期。若证据未补齐，不把试验顺利获得写成生产批准。平台应允许保存测试结果，同时阻止未批准制品被生产服务拉取。若后续来源或条款发生变化，还要触发重新复核，而不是永久沿用一次批准。

历史来源记录缺失时应该怎样补救？

先冻结进一步分发，盘点当前制品、运行服务和已知给予方，保留现有文件与日志。顺利获得采购记录、训练任务、代码、缓存、人员访谈和供应方材料重建可验证部分，并明确哪些仍未知。不要为了补齐表格而把推测写成事实。

根据业务关键性决定后续动作：重新获取并核验、重新训练或处理、限制使用、迁移到可信替代，或经风险评审暂时保留。补救过程和新证据与原缺口一起记录，避免未来读者误以为来源从一开始就完整。修复前后的可使用范围也要分别标记，防止历史调用被新结论反向覆盖。