AI 模型清单模板：追踪你的组织在生产中运行的每个模型

监管机构要的是一份清单：每个模型、它的版本、负责人、风险等级、由谁验证、上次审查是什么时候。一句"我们使用 AI"在他们那里算不上治理姿态。如果你无法随时拿出这份清单，那就是一个合规缺口。

本文给出完整的模板。复制它，把字段名改成适配你自己工具链的叫法，今天就可以开始填。

为什么监管机构要求模型清单

三套主要框架在同一项要求上达成了一致：你必须为自己运营的每一个 AI 系统维护一份正式登记册。

SR 11-7（美联储 / OCC） 要求银行及其控股公司，对所有用于业务决策的模型保存完整文档。这里的"模型"定义很宽：任何产出估计值或决策的量化方法都算，包括信用评分、欺诈检测、用在贷款发起流程里的聊天机器人，以及任何触及受监管结果的 LLM 辅助工作流。

EU AI Act 第 11 条 要求高风险 AI 系统在投放市场或投入使用之前编制技术文档，并在系统的整个生命周期内保持更新。对部署者（即使用高风险系统的组织）而言，第 26 条要求保存日志并实施人工监督，而这两件事的前提，是你清楚自己在运行哪些系统。

ISO/IEC 42001（AI 管理体系标准）要求组织在其 AI 管理体系中建立 AI 系统登记册。第 6.1.2 条明确要求识别 AI 系统及其相关风险。

对受上述任一框架约束的组织来说，清单是必备项，其他所有治理工作都建在它上面。

模型清单是什么，不是什么

模型清单是一份结构化登记册，覆盖你的组织在生产环境中运行的每一个 AI/ML 系统。它包括：

• 内部自建的模型
• 供应商提供的模型（包括通过 API 访问的模型，如 GPT-4、Claude、Gemini）
• 微调后的模型，即便基座来自供应商
• 本地部署和云端运行的模型
• 嵌在你所部署的第三方软件里的模型

清单的范围比你调用的 API 列表宽得多。只要供应商的模型做出或影响了业务决策，它就该进你的清单，连同锁定的版本、上次变更的日期，以及万一出问题由谁对结果负责。

影子 AI，也就是各团队绕开正式采购流程自行部署的模型，是最常见的缺口。清单只有诚实反映实际在跑的东西，才有用。

模型清单模板

每一次模型部署占一行。如果同一个模型版本部署在两个彼此独立的生产场景里（比如一个用于客服，一个用于内部运营），就建两行。

已填写的示例行

模型变更日志模板

生产环境中模型的每一次变更，包括版本更新、重新训练、阈值调整，都必须记录在案。它和主清单表是分开的：清单反映当前状态，变更日志反映历史。

变更类型可选项：版本更新 / 阈值调整 / 输入特征变更 / 训练数据更新 / 基础设施迁移 / 紧急回滚

每个字段怎么填

风险等级是最多组织填错的字段。定级依据是失效后果，而不是技术复杂度。一个只做逻辑回归、却影响授信决策的模型属于高风险；一个用来生成内部会议纪要建议的复杂 Transformer 模型属于低风险。要问的问题是：如果这个模型给出了错误的输出，谁会受害，受害有多深？

人工监督级别要写实际情况，而不是写目标状态。如果政策上写的是 HITL，而审核人在 10 秒内就给 98% 的输出盖章放行，那就如实记下来：政策与实践之间的落差本身就是一项审计发现。

版本这一栏要求你为第三方 API 模型锁定版本，别用 "latest" 之类的别名。如果你调用的是 gpt-4 而不是 gpt-4-0613，你其实并不知道自己在跑哪个模型。锁定版本，并把它记下来。

监管范围应该由法务或合规团队来填，而不是工程师。工程师清楚模型做什么，法务清楚这项活动会牵连到哪些法规。

清单的维护

一份没人维护的清单比没有清单更糟：它制造虚假的安心，还会实实在在地误导审计人员。

最低审查频率：

• 高风险系统：每季度
• 中风险系统：每半年
• 低风险系统：每年
• 发生生产事故之后：5 个工作日内

需要新增一条清单记录的触发条件（而不是更新已有的行）：

• 有新模型上线到生产环境
• 已有模型被用于新的业务用途或新的数据类型
• 模型从一个部署环境迁到另一个（预发布 → 生产）

需要更新已有行的触发条件：

• 版本变更
• 负责人变更
• 验证状态变更
• 退役

常见错误

把清单当成一次性项目。 不少组织为了应付一次审计才建起清单，之后就任它过期。监管机构会查最近的更新记录。一份 18 个月没动过的清单，是治理缺口的证据。

漏报影子 AI。 各业务团队会自行接入 AI 工具，比如 Copilot 集成、供应商产品自带的 AI 功能、自己写的 API 集成，全都没走正式采购流程。要直接去问业务部门，不能只问 IT。问法是："你们团队有没有在用不归中央 IT 管的 AI 工具？"答案几乎总是有。

把模型和用例混为一谈。 同一个模型版本（例如 GPT-4o）部署在两个不同场景里，比如面向客户的客服对话和内部法律文件摘要，就是两条不同的清单记录，风险等级、监督要求和监管范围都可能不同。

没有按版本追踪 API 模型。 "我们用 OpenAI"算不上一条清单记录。具体的模型 ID、锁定该版本的日期，以及后续的每一次更新，都属于必填信息。

与你的数据流水线打通

模型变更日志里的几列，尤其是变更类型、变更人和是否完成验证，直接对应一条埋点完善的数据处理流水线的输出。如果你的训练数据流水线为每一步转换都记录了操作人和时间戳，变更日志的原料其实已经有了。缺的通常是把这份运行日志接到治理登记册上。

Ertas Data Suite 会为每一步数据转换生成完整且不可篡改的审计轨迹，记录谁执行、何时执行、改了什么，可以直接汇入模型变更日志，无需人工录入。

预约 Ertas 探索通话 →

下一步

1. 导出当前环境中所有在运行的模型清单（和 ML Ops 与 IT 一起做）
2. 依据你的分级政策为每个模型定风险等级（或直接采用上文的三级框架）
3. 为每个模型确定负责人：如果某个模型无人问责，那就是你的第一项治理发现
4. 在 90 天内为所有高风险系统安排第一次正式审查
5. 建立变更通知流程，让清单保持最新

清单是地基。模型卡、验证文档、审计轨迹和事件响应都要引用它。把它建扎实，治理体系的其余部分才有立足之处。