AI Change Impact / Release Governance 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_CHANGE_IMPACT_RELEASE_GOVERNANCE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

Source Anchors

核心导读

AI release governance 不能只围绕“模型版本”设计。上线后的 AI 系统会因为 prompt、RAG 语料、index、embedding、reranker、tool contract、policy rule、eval set、vendor、UI、人工流程、监控阈值和数据留存变化而改变行为。很多客户风险不是来自一次大版本发布，而是来自看似局部的配置、知识源或流程变更。

成熟的 change impact architecture 要把每个变化映射到 use case、需求、评测、控制、客户分群、证据、发布门禁、监控窗口和回滚方案。它不是让治理拖慢迭代，而是让高风险 AI 能持续演进，同时避免靠平均分、主观 signoff 或生产事故来发现退步。

可以把它理解为：

AI release governance =
  change taxonomy
  + impact graph
  + risk-tiered gates
  + regression eval
  + staged rollout
  + rollback and evidence

1. 问题定义

传统软件发布通常关注代码差异、测试通过率和部署稳定性。AI 系统的行为面更宽：同一个业务功能即使代码不变，也会因为知识库更新、prompt 调整、模型供应商升级、工具权限变化或人工流程重排而改变客户输出、证据链和合规风险。

问题不在于每个变化都要走同样重的审批，而在于组织必须知道变化影响了什么。一个 RAG index rebuild 可能影响 citation support、policy freshness、retrieval coverage、adverse action explanation、customer complaint rate 和 auditor evidence query；一个 CRM tool contract 变化可能把 agent 从“写草稿”升级为“写正式字段”，进而触发客户通知或下游费用。

2. 架构模型

Change impact architecture 的核心对象是 impact graph。它把 change 从技术项转成业务和风险项，避免“prompt change, low risk”这类不可验证判断。

change
  -> affected use cases
  -> affected requirements
  -> affected evals
  -> affected controls
  -> affected customer segments
  -> affected evidence
  -> release gate

生产级 release governance 架构：

change intake
  -> change classification
  -> impact graph
  -> risk tier
  -> regression eval
  -> security/privacy/model-risk review
  -> release decision
  -> shadow/canary/ramp
  -> monitoring window
  -> rollback or scale
  -> evidence archive

高风险 AI release 需要把技术 release 和治理 release 合并。发布结论不是“测试通过”，而是“在这些影响范围和剩余风险下，可以以这种暴露方式上线”。

3. 关键机制/生命周期

AI change 生命周期要支持小变更快速处理，也要让高风险变更触发足够门禁。

identify change
  -> classify type and scope
  -> build impact graph
  -> assign risk tier
  -> select regression gates
  -> run eval and control checks
  -> decide release strategy
  -> monitor leading and lagging signals
  -> rollback, fix or scale
  -> update inventory and evidence

Regression gate 要按影响面组合，而不是只看平均质量分。

高风险 slice 退步可以阻断 release，即使总体指标提升。例如，客服 RAG 总体准确率提高，但信用卡争议截止日期类问题召回下降，仍应阻断扩量；credit explanation prompt 更自然，但 reason-code consistency 下降，也不能以“用户体验提升”放行。

变更记录需要结构化字段，而不是靠发布会议纪要：

4. 证据与控制

Release governance 的证据目标是证明：组织理解了变化影响，选择了适当门禁，按风险控制了暴露，并在上线后观察到足够信号。

核心指标要区分质量退步、客户影响、治理效率和经济性。

5. 金融零售/AI产品场景

Credit explanation prompt change

风险是语气更自然，但 reason code 不再精确；加入“建议重新申请”可能误导客户。Release gate 应覆盖 adverse action reason consistency、prohibited wording check、policy version eval、high-impact explanation review 和 legal/compliance signoff。上线方式宜先用 shadow 或 internal-only review，再扩到低风险解释场景。

AML typology knowledge update

风险是新 typology 加入后，旧 case narrative 变得过度告警；RAG 检索偏向新文档，忽略旧规则；analyst 负担上升。Release gate 应覆盖 old/new typology regression、analyst review、false positive KRI、SAR narrative quality 和 evidence completeness。

Customer-service RAG index rebuild

风险是 chunking 改变导致关键例外条款无法召回，source citation 不稳定，客户收到过期或不完整政策。Release gate 应覆盖 retrieval recall、citation exactness、high-traffic policy Q&A、complaint-sensitive cases、source freshness 和 rollback to previous index。

CRM write tool contract change

风险是 agent 从写草稿变成写正式字段，下游系统触发客户通知、费用、账户状态或 case closure。Release gate 应覆盖 tool authority review、approval-before-action、sandbox test、side-effect trace、rollback/compensation plan 和 post-release tool-action monitoring。

6. 反模式

7. 最终心智模型

AI release governance 的核心不是“审批变多”，而是把每次变化对客户、控制、评测和证据的影响显性化。生产级 AI 系统必须允许持续变化，但每次变化都要知道影响什么、如何测试、如何限制暴露、何时回滚、如何证明。

最终要形成一条稳定链路：

change
  -> impact graph
  -> risk tier
  -> regression gates
  -> staged rollout
  -> monitoring
  -> rollback or scale
  -> evidence archive

如果一个 AI 系统只能说明“发布了哪个版本”，却说不清 prompt、RAG、tool、workflow、eval 和 monitoring 变化对客户权益、解释、公平性、隐私和证据链的影响，它就还没有可持续的 release governance。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。