摘要：AI 模型在训练、微调、入库和部署之间多次转手，仅凭文件名、下载地址或仓库权限，很难确认线上使用的是否仍是审核通过的版本。PKI 数字证书结合模型签名，可以帮助验证发布身份与文件完整性；再将模型摘要关联到训练、评测和审批记录，才能形成可核查的分发与溯源流程。
模型通过评测以后，交付工作并没有结束。算法团队导出的文件可能先进入对象存储，再被同步到模型仓库，最后由另一组人员部署到生产环境。只要中间有一次覆盖、误拷贝或未经审批的替换，测试报告就可能与实际运行的模型脱节。
企业要建立的可信 AI 模型分发流程，应让接收方能够独立核对：发布者是否获准发布这个模型，收到的文件是否与签名时一致，以及它对应哪一组发布记录。PKI 为公钥与身份之间建立受信任的关联，数字签名把这份身份关联到具体的模型内容；模型仓库和审批系统则补充版本与过程证据。
一 先区分下载安全与模型可信
从 HTTPS 地址下载模型，可以保护本次传输并验证所连接服务器的身份。文件下载完成后又被转存、打包或复制，接收方仍需要另一种方式确认文件本身。一个合规的下载通道，也可能传出误上传的模型版本。
哈希值能帮助发现内容变化，例如使用SHA-256 为模型文件生成摘要。但如果模型和摘要都放在同一个可被改写的位置，攻击者可能同时替换两者。签名的作用在于：用受控私钥签署文件摘要或模型清单，接收方通过可信公钥验证签名，从而检查内容是否与该签名对应。
证书把公钥与经过相应规则验证的身份关联起来，接收方还要确认该身份获得了本模型的发布授权。证书链有效，不等于持证者有权发布企业的任意模型；签名有效，也不等于模型预测准确、没有后门或训练数据已经获得合法授权。这些判断仍需评测、数据治理和安全审查。
二 模型签名应覆盖一套可以复核的交付内容
只签一个权重文件，往往无法完整描述一次模型发布。配置文件决定加载方式，分词器影响输入解释，适配器可能改变模型行为，随包脚本还可能参与执行。哪些文件属于发布对象，应在签名前确定。
一种可行的实施方式，是为交付目录生成模型清单，记录文件路径及各自摘要，再对清单进行签名。对于分片模型，需要覆盖全部权重分片和索引；对于依赖外部基础模型的适配器，还应固定基础模型的版本或摘要。不能只记一个可能随时指向新内容的下载链接。
清单还可以引用模型卡、评测报告和依赖清单的摘要，让接收方确认文件与说明材料属于同一次发布。敏感训练数据不必随模型公开交付，可在受控记录中保存数据集版本标识，并对需要追溯的证据做权限管理。
OpenSSF Model Signing 已提供面向机器学习模型的签名与验证工具。其技术文档展示了先为模型组件生成摘要清单、再签名和核对清单的实现思路。企业可以据此评估工具与现有模型格式的适配情况，而不是自行拼接一套难以长期维护的签名格式。
签名对象一旦确定，验签端就应采用同样的文件范围与路径处理规则。额外增加的可执行脚本、缺失的分片，以及未纳入清单的配置，都需要有明确处理策略。完成验证后，还应将待加载文件固定在受控的只读位置，避免验完再被覆盖。
三 把验签放在真正决定能否上线的位置
仓库接收模型时验一次签，可以提前拦住异常包；生产环境加载前再验一次，才能检查最终交付到节点的文件。只在上传环节记录“验证通过”，不足以覆盖之后的同步与部署过程。
部署前的验证可以按下面的顺序组织，但应由系统执行并保存结果，而不是依赖操作人员逐项口头确认。
1 确认可信发布身份
预先配置允许的信任锚和发布身份，检查证书链、适用的密钥用途及授权范围。不得因为下载包里附了一张根证书，就自动信任它。证书有效期和吊销状态，应按所用签名方案及验证策略处理。
2 验证签名并重算文件摘要
验证签名覆盖的实际字节，再核对每个受保护文件的摘要。清单签名正确，但文件缺失或摘要不一致，仍应判定失败。
3 核对批准版本和来源记录
比对模型标识、发布版本、允许的构建来源及审批结果。旧版本即使签名仍有效，也不应因此自动获得重新上线的许可。
4 决定放行或阻断
验签失败、发布者不在授权范围或版本被禁用时，应阻止本次新部署并保留证据。已在线服务如何保持运行、是否回滚，由预先制定的发布与应急策略决定。
SLSA 的制品验证指南同样强调，验证既要检查签名和制品摘要，也要检查来源记录是否符合预期。把这一原则用于模型交付时，应让部署规则识别获准的发布来源和版本，避免把“密码学验证通过”直接当成全部上线条件。
四 溯源记录要能追到模型的前一个版本
设想一个交付场景：总部训练基础模型，区域团队完成微调，边缘设备使用量化后的版本。三份模型的内容不同，摘要也不同。总部对原始模型的签名，不能直接证明区域微调产物或量化文件未经修改。
每次改变模型内容，都应形成新的制品标识、摘要和签名，并记录与上一版的关系。微调记录引用基础模型摘要及任务标识，量化记录引用输入模型摘要及转换配置；发布审批再指向最终交付的摘要。这样，查询生产版本时才有路径向前追，而不只是找到几个相似的文件名。
例如，验收人员发现某个节点仍在使用旧量化版本，可以从该节点记录的摘要反查发布批次，再确认它由哪份微调模型转换而来。若只有“模型已更新”的工单结论，却没有最终制品摘要，就很难区分同步遗漏、部署回滚和文件被覆盖。
这类记录不应只保存在聊天附件中。模型仓库、发布系统与审批系统需要共享稳定标识，关键记录采用权限隔离、版本保留或追加式审计等措施。签名可以保护已记录内容的完整性，但不会自动证明填写的训练来源、审批结论都是真实的，记录产生环节本身也要受到控制。
五 签名私钥和证书管理需要接入发布制度
如果任意流水线任务都能调用发布私钥，受控签名就可能退化为给任何文件加盖许可。应区分开发测试与正式发布身份，限制签名服务的调用方，并将签名请求关联到已审批的制品摘要。需要时使用HSM 等密钥保护机制，同时确认签名工具、接口与算法兼容。
后续运维至少要准备两类变更。第一类是正常换证或换密钥：先让验证端按计划信任新的发布身份，再切换签名端，保留必要的历史验证材料。第二类是泄露或误签：停用相关签名权限，按方案处理证书吊销，并在模型仓库和部署策略中禁用受影响版本。证书吊销本身不会从所有设备上自动删除已部署模型。
历史签名如何长期验证，也需要提前约定。签名包里普通的时间字段不能单独证明签署时间；需要长期核验时，应评估所用方案支持的可信时间证据、证书链和状态证据保存方式。不要简单规定证书一过期，所有历史模型立即停用，也不要无限期接受缺少有效证据的旧签名。
GlobalSign 能为这套流程提供什么基础
GlobalSign Atlas 是面向公共与私有数字证书的数字身份平台，官网介绍了证书签发、管理及 REST API 集成能力。对于准备建立模型可信分发流程的企业，可以先结合自身 PKI 架构，评估发布身份的证书策略、证书管理和系统集成需求。
模型打包、清单生成、签名格式、审批关联和部署拦截，还需要由选定的模型签名工具与企业发布系统实现。采购前应确认适用的证书用途、算法、密钥存储及验证端兼容性；不能仅凭某款产品支持数字证书或代码签名，就推定它已具备完整的AI 模型溯源功能。
FAQ
Q1 有了模型仓库和访问权限 还需要模型签名吗
A：两者解决的问题不同。仓库权限控制谁能读写，模型签名让接收方核对拿到的文件是否与获准发布的内容一致。模型离开仓库、跨团队交付或复制到边缘节点后，这种验证仍然有用。
Q2 网站的 SSL 证书能直接用来给模型签名吗
A：不应直接套用。网站 SSL/TLS 证书主要用于服务端身份认证与安全通信。模型签名需要符合目标工具和验证策略的证书、密钥用途与算法配置，不能只因证书内含公钥就认定适用。
Q3 模型经过微调或量化后 原签名还有效吗
A：原签名仍可用于核验原始制品，但不能替代对新产物的验证。内容改变后，应为新产物重新生成摘要并签名，同时保留它与输入模型的关联。
Q4 能证明模型来自某个团队 是否就能证明训练数据没有侵权
A：不能。签名帮助验证发布身份和签名内容的完整性，不负责证明训练数据的授权是否合法。数据授权、使用范围及合规结论需要另行审查，相关记录可以与模型发布版本关联保存。
Q5 企业第一次落地 应该怎样验收
A：先选一个真实模型打通发布与部署验证，再分别测试修改文件、遗漏分片、使用未授权发布身份以及提交被禁用旧版本。确认系统能够阻止不合规的新部署，并查回对应的文件摘要和审批记录，再扩大接入范围。
资料来源
GlobalSign Atlas 数字身份平台
https://www.globalsign.cn/atlas
OpenSSF Model Signing 技术文档
https://sigstore.github.io/model-transparency/
SLSA v1.2 制品验证指南