上线审批与变更管理
本节目标
把“可以上线”变成绑定具体版本、用途、条件和有效期的可追溯决策，并让系统变化触发与风险相称的复查。一次批准不是给产品名称的永久通行证。
从阶段门开始
治理门应与开发节奏融合，而不是项目结束后才来盖章：
- 需求受理：明确问题、受影响者、非 AI 方案、负责人和禁止用途；明显不可接受的方案在投入开发前停止。
- 受控试验：只用合成或已授权数据，限制用户和工具，登记系统与供应商，记录早期风险。
- 预生产评审：完成影响评估、技术评测、安全/隐私审查、操作说明、监控、回滚和事件手册。
- 上线决策：批准人选择拒绝、限时试点、附条件上线或正式上线；不能只写“评审通过”。
- 扩展与变更：新增地区、用户、数据、工具或自主程度时，按影响重新评估。
- 定期复查/退役：即使没有主动变更，也按风险、事故和外部环境复查继续使用的依据。
低风险草稿工具可以轻量审批；会影响权利、安全或重要机会的系统需要多学科和独立挑战。减少文档不能减少责任。
上线证据包
审批者至少应看到：系统清单与所有者、用途/禁止用途、利益与非 AI 基线、影响评估、数据/模型/供应商记录、场景化评测、威胁与隐私评审、人工监督、用户说明、监控阈值、事件/回滚/退役计划，以及所有未关闭风险。
批准记录包含：
- 决策与理由，批准者及其权限；
- 绑定的模型、Prompt、索引、工具、策略、代码和评测版本；
- 允许的用户、地区、数据、流量、自主程度和有效期；
- 必须满足的上线条件、例外、残余风险负责人和复查日期；
- 超限、投诉、事件或变化时的暂停/重审触发器。
对关键工件记录不可变版本或内容哈希，并让受控发布门在部署前比较批准工件与实际 release。这样才能检测并阻止“批的是 A、上的是 B”；孤立地存一个哈希既不能防止替换，也不能证明 A 安全、有效或合法。离线证据、发布门与线上回归的交接合同见 离线到线上证据交接与回归闭环。
什么变化需要重审
变化包括但不限于：模型或供应商版本、系统/开发者 Prompt、微调数据、RAG 知识源、Embedding 与索引、阈值、Guardrail、工具与权限、输出进入的业务流程、自动执行程度、目标群体、地区、语言、数据类别、保留策略和依赖条款。
先做影响分析：变化是否改变用途、受影响者、可逆性、数据流、攻击面、性能分布、透明说明或法律角色？纯拼写修正可走轻量路径；看似“小”的 Prompt 或工具 schema 变化可能改变行为，应做相关回归。供应商静默更新也是变更，无法检测或固定时要用持续基准和停用条件补偿。
影响分析的输出不是一个 material=true/false：它应列出受影响的风险、控制、评测、说明、审批条件和运行阈值，由各工件负责人确认需要复用、增量验证还是完整重审。无法判断影响范围时，默认扩大复核而不是默认沿用旧证据。
发布与例外
上线采用小流量、明确观察窗、可回滚版本和人工降级。验证失败时默认停止扩展，而不是把阈值改到通过。紧急修复可以缩短事前流程，但必须限定范围、具名批准、保留证据并及时完成事后评审。
例外记录写明原因、补偿控制、责任人、截止日和撤销条件。没有期限的例外会变成未声明政策；同一例外反复续期应升级到治理机构决定。
练习与自测
为“只读 FAQ Agent 新增发工单工具”写变更评审：列出新增资产、权限、攻击路径、测试、审批条件、灰度、回滚和需要更新的用户说明。说明为什么不能沿用旧批准。
- 批准绑定精确版本、用途、范围和期限。
- 开发者不能单独接受自己的重大残余风险。
- 能识别模型外的 Prompt、数据、工具和流程变化。
- 紧急变更和例外都有边界、证据与退出条件。
下一步与资料基线
下一步进入 运行监控、事故与退役。资料获取日期：2026-07-22。参考 NIST AI RMF Manage Playbook、NIST AI RMF Core 与 NIST AI 600-1。框架提供决策思路；组织应把实际授权矩阵和变更流程写入自身政策。