## 3. 评审的前置条件：模型版本、文档就绪、环境就绪、关键干系人确认
### 适用场景
- 模型边界确认评审会正式召开之前，所有参与方（模型开发团队、安全组、运维、业务审核）必须确认评审的前置条件已全部满足。
- 避免评审会因版本不一致、文档缺失、环境不可达或关键人员缺席导致会议无效或重复召开。
### 前置条件
| 条件类别 | 具体内容 | 验证方式 |
|---------|---------|---------|
| **模型版本** | 待评审的模型版本号与模型仓库（如 MLflow / Model Registry）中记录的版本一致，且为经过验证的稳定版本 | 对比版本标签、Git commit SHA、MD5 校验 |
| **文档就绪** | 模型卡（Model Card）、系统架构图、数据流图、边界定义清单、安全评估报告等文档已完成终版审批 | 文档库中标记为“已批准”，且包含评审日期及审批人签名 |
| **环境就绪** | 评审所需的气象/交通/金融数据接口可正常调用；推理测试环境（沙箱）已部署且权限配置正确 | 运行环境自检脚本或接口连通性测试 |
| **关键干系人确认** | 模型负责人、技术评审组长、安全合规经理、业务代表均已确认出席时间，无利益冲突或替岗 | 邮件/会议邀请响应记录与确认回执 |
### 操作步骤
1. **版本核验**
从模型注册表拉取待评审模型标签，与开发分支最新合并记录比对，确保无未批准的修补。
2. **文档完整性检查**
对照《模型边界确认文档清单》逐项勾选，检查文档状态是否为“已终审”，并确认版本号与模型版本关联。
3. **环境可用性测试**
使用专用测试账号登录评审沙箱，运行快速推理脚本验证模型加载与数据通路。
4. **干系人行程核对**
在评审会前 1 个工作日通过协作平台（如 Jira / 钉钉）二次确认关键人员参会情况，并记录确认人及确认时间戳。
5. **生成就绪检查报告**
汇总以上四步结果，输出《评审就绪检查清单》，由评审组织者签字确认。
### 输入输出物
| 输入物 | 输出物 |
|-------|-------|
| 模型注册表地址 & 版本标签、文档清单、环境配置说明、关键干系人列表 | 《评审就绪检查清单》（含四类条件逐项确认结果及签字） |
### 责任边界
- **模型开发负责人**：保证模型版本正确、文档齐全且版本匹配。
- **运维/SRE**：保障评审环境正常运行，提供环境自检脚本与结果。
- **评审组织者（PMO/QA）**：召集干系人、发出确认通知、汇总就绪检查报告。
- **安全/法务**：仅需确认文档中安全评估部分是否已审批，不参与环境检查。
### 记录材料
- 《评审就绪检查清单》电子版（PDF，含时间戳与签名）。
- 干系人确认邮件截图或会议系统确认记录。
- 环境自检日志输出（保留 30 天）。
### 异常处理
- **版本不一致**：**立即暂停**，要求模型开发团队回滚至正确版本并重新提交审批，本轮评审调整至下一周期。
- **文档缺失**：标记为“待补充”，允许评审会推迟至多 2 个工作日。若超出时限则关闭当前评审工单。
- **环境不可用**：运维应在 1 小时内修复；若超过 4 小时未恢复，评审顺延并通知所有干系人。
- **关键干系人缺席**：必须有正式授权委托书（Attestation of Delegation），否则评审无效，需重新排期。
### 验收标准
1. 四类前置条件均被明确标记为 **“已确认”** 且包含确认人签字及时间戳。
2. 就绪检查报告无“不通过”项，所有待办项有明确的修复计划与期限。
3. 关键干系人出席率 ≥ 80%（至少模型负责人、技术评审组长必须到场）。
🔑 核心原则：“前置条件未通过，不启动评审”是防止评审资源浪费的第一道防线。模型版本与文档版本必须严格对应，环境可用性测试脚本建议固化在 CI/CD 流水线中自动执行。
#### 前置条件确认流程总览
⚠ 常见陷阱：
- 版本号小数点后差异（如 v2.1.0 vs v2.1.1）常被忽略，却可能导致部署模型与评审版本不符。
- 环境就绪脚本若采用“只验证容器启动而不验证模型推理”，可能跳过关键的数据通路错误。
- 干系人确认邮件回复仅确认“收到”不等于确认“按时参会”，务必明确回复“确认参会时间”。