立项：模型清单
列出项目会用到的全部模型，包括嵌入、重排、语音与图像模型，标注来源、许可与用途。只写主模型是常见疏漏，附属模型同样会接触数据，而且往往由不同团队选型，没人统一管，附属模型的选型也要登记。
开发：制品与密钥
模型文件入制品库并带哈希，推理密钥走密钥管理，不写进代码与配置文件。开发环境与生产环境分离，禁止用生产密钥调试，这类习惯一旦养成，泄露只是时间问题，密钥要能按服务单独回收，后续处理成本更高。
测试：四类用例
越狱、注入、敏感信息外泄与偏见四类，各准备可判定的预期结果。测试报告要写明未通过项、影响与接受理由，作为上线决策依据；只写通过率，验收时仍然只能凭印象判断，也说不清风险藏在哪一环。
上线：灰度与监控
小流量灰度，观察异常输出比例、护栏命中与延迟变化；设定回滚条件与责任人。没有明确回滚条件的灰度，往往在争议中被拖成事实全量，最后谁也不敢停，灰度指标要在上线之前就写清楚，回滚由值班负责人按下。
运营：版本与复测
模型或数据更新触发复测，季度做一次全量回归；把事件与整改纳入台账。运营阶段最容易松懈，也最容易积累未记录的变更。等到出事时再问「中间改过什么」，往往没人答得上来，所以台账要能一眼看出改过什么。
适用与不适用
适合谁
- 正在立项或交付 AI 系统的项目组，需要评审材料
- 需要评审供应商模型方案的甲方，要能提问
- 负责 AI 项目验收的技术与安全人员，要对齐口径
不适合谁
- 仅使用成熟 SaaS 且无自建模型的项目，无权重资产
- 没有明确上线计划的概念验证，暂不适用
典型场景
某零售企业的商品标题生成项目在验收时被要求补材料：模型许可证、微调数据授权、越狱测试报告、灰度记录。团队提前按清单准备，验收一次通过；隔壁同类项目因缺评测报告，被要求延后两周补测，验收材料的清单也在内部复用。
可执行步骤
- 列出项目用到的全部模型，包含嵌入、重排、语音与图像模型，同步给部门负责人。
- 模型文件入制品库并带哈希，推理密钥统一入密钥管理，禁止写入代码库。
- 准备越狱、注入、敏感信息外泄与偏见四类用例及可判定的预期结果，报告写未通过项
- 设定灰度比例、观察指标、回滚条件与决策责任人，停不停由值班负责人判断。
- 把版本或数据更新触发复测写进运维手册，明确负责人与触发条件，在系统里留操作记录。
常见坑
- 只登记主模型，嵌入与重排模型没人管，数据照样从这些环节流出去，也没人负责统一登记，事后难补。
- 推理密钥写在配置文件里，随代码一起进了仓库，事后才被发现，仓库扫描也从来没有开过，责任难界定。
- 评测报告只写通过率，不写未通过项与接受理由，验收时无法判断风险，只能凭印象拍板，风险说不清楚。
- 灰度没有预设回滚条件，出了问题还在开会讨论要不要停，争议中没人敢按停，责任往往落不到人。
自检与验收清单
- 是否列出全部模型，包含嵌入与重排等附属模型，含附属模型
- 模型文件与推理密钥是否分别纳入管控，分别管控
- 是否有四类安全用例与完整测试报告，报告完整
- 灰度是否预设观察指标与回滚条件，责任到具体人
- 版本或数据更新是否触发复测，触发后立即生效
常见问题
采购第三方模型还要做这些吗？
要，但重点不同：更多放在供应商准入、合同条款、数据区域与接口审计上。自建部分才需要关注权重、加载与隔离，两类工作不能互相替代，也不能只做其中一半，两套材料不要混用。
小项目可以只做测试不做台账吗？
可以先简化台账，但来源、版本与责任人三项建议保留。出事时这三项决定了你能不能快速定位，缺了它们，测试结果也说不清对应哪个版本，能做到快速定位就已经够用，按场景分别约定。
验收时甲方该看什么？
看可核查的材料而不是口头说明：模型清单与许可、评测报告、灰度记录、回滚方案、日志样例。能现场抽查一条请求的完整链路，比任何承诺都有说服力，现场演示最有说服力。