AI 扩展计划 / Playbooks

AI Change Impact / Release Governance Playbook

本文不是通用 change management，也不是“上线前开个 CAB 会”。它训练的是高级 AI 变更影响分析与发布治理能力：把每一次 AI 变更视为一个跨模型、知识、工具、规则、流程、数据、供应商和监控体系的系统性 release decision。CBAP+ 需要能把业务意图、流程影响、控制要求和验收标准写清楚；AI PM 需要能判断用户价值、风险收益、实验边界和放量策略；架构师需要能

900 行AI_CHANGE_IMPACT_RELEASE_GOVERNANCE_PLAYBOOK.md

AI Change Impact / Release Governance Playbook

适用对象：CBAP+ Business Analyst、AI Product Manager、AI Product Architect、Release Governance Lead、Solutions Architect、Model Risk / Compliance / Audit 合作方、金融零售业务负责人。核心问题：AI 系统上线后，团队如何治理模型、prompt、RAG index、tool contract、policy rules、eval datasets、vendor、human workflow、monitoring threshold 等多维变化，避免“看似小改动”在真实金融零售流程中造成客户伤害、合规缺口、操作风险、审计证据断裂和不可回滚的生产事故。

重要说明：本文是学习、架构设计和作品集材料，不构成法律、监管、模型验证或正式合规意见。金融零售正式项目必须由 business owner、technology、security、privacy、legal、compliance、model risk、operational risk、third-party risk、internal audit 共同确认适用要求、审批权、证据保留和发布边界。

1. Source Anchors

以下来源作为术语、治理心智和证据结构的官方锚点。正式项目必须按访问日期复核最新版本、适用范围、监管解释、机构政策和合同要求。

Anchor	Official link	本手册使用方式
NIST AI Risk Management Framework	https://www.nist.gov/itl/ai-risk-management-framework	用 Govern / Map / Measure / Manage 组织 AI change impact：先识别业务上下文和风险，再衡量、处置、监控和沉淀治理证据。NIST 页面说明 AI RMF 面向 AI 产品、服务和系统的风险管理，并持续演进。
ISO/IEC 42001	https://www.iso.org/standard/81230.html	把 AI change governance 放入 AIMS（AI Management System）：范围、职责、风险机会、过程控制、持续改进、管理评审和证据保留，而不是项目组临时自发管理。
Federal Reserve SR 11-7	https://www.federalreserve.gov/supervisionreg/srletters/sr1107.htm	借鉴金融机构模型风险管理语言：model inventory、intended use、validation、effective challenge、ongoing monitoring、governance、policy、control。本文将其扩展到 LLM / RAG / Agent / workflow 变更，但不声称 SR 11-7 已完整覆盖所有 GenAI 风险。
NIST GenAI Profile	https://www.nist.gov/itl/ai-risk-management-framework/generative-artificial-intelligence-profile	用于识别生成式 AI 的特有风险：hallucination、prompt injection、data leakage、harmful content、overreliance、synthetic content、third-party dependency、evaluation difficulty。实践中也应关注 NIST AI 600-1 GenAI Profile 的正式发布页和机构内部 AI policy。
OpenTelemetry docs	https://opentelemetry.io/docs/	用作生产监控与证据采集的工程锚点：traces、metrics、logs、context propagation、sampling、redaction、service instrumentation。AI release governance 需要把模型调用、RAG retrieval、tool execution、human override 和 policy decision 串成可观测链路。

2. Core Mental Model：AI Change Impact 是多维系统影响

传统软件变更常被简化成“代码改了什么”。传统 MLOps 又容易把 AI 变更简化成“模型版本改了什么”。这两种心智都不够。

在金融零售 AI 系统里，生产行为由多个 artifact 共同决定：

AI runtime behavior =
  model behavior
  + prompt and system instructions
  + RAG corpus, chunking, embedding, index, retriever, reranker
  + tool/API contract and permission scope
  + policy rules, DMN, guardrails, decision thresholds
  + workflow and human handoff
  + UI copy and disclosure
  + vendor configuration and regional routing
  + eval dataset, rubric, judge and acceptance threshold
  + telemetry, alerting, sampling and retention

因此：

AI change impact is multidimensional.
Model change is only one category.

一个 prompt 小改动可能改变信用拒绝解释的公平性；一次 RAG index rebuild 可能让 AML analyst 看不到新 typology；一个 CRM write tool 增加字段可能把客服机器人从“建议回复”变成“实际修改客户资料”；一个监控阈值调宽可能让投诉激增被延迟发现；一次 vendor model upgrade 可能改变答案风格、拒答率、PII 暴露概率和成本曲线。

2.1 高级治理问题

每次 AI 变更都必须回答 12 个问题：

问题	高级判断点
1. 变更对象是什么？	model、prompt、RAG、tool、policy、eval、vendor、workflow、threshold、monitoring、retention 是否同时变化。
2. 变更意图是什么？	修复缺陷、提升质量、降低成本、满足监管、更新知识、扩展权限、改善体验、降低人工负担。
3. 哪些业务决策会被影响？	信用、AML、反欺诈、客服、投诉、营销、理财适当性、身份核验、费用豁免、账户维护。
4. 哪些客户群体可能受到不同影响？	新客户、弱势客户、逾期客户、小微商户、老年客户、非英语客户、高风险客户、受保护属性相关群体。
5. 哪些控制会被绕过或弱化？	human review、policy check、explanation template、dual control、maker-checker、audit logging、consent boundary。
6. 哪些依赖会连带变化？	embedding model、schema、feature、prompt variable、tool version、ruleset、retrieval filter、vendor endpoint。
7. 如何证明没有退化？	regression eval、golden set、scenario test、red-team、shadow run、human review sample、monitoring baseline。
8. 谁有权批准？	product owner、business control owner、model risk、compliance、security、privacy、data owner、operations、architecture review。
9. 如何分阶段上线？	canary、shadow、dark launch、regional ramp、customer segment ramp、human-in-the-loop ramp、read-only before write-enabled。
10. 如何快速止损？	feature flag、model route rollback、index rollback、prompt rollback、tool permission kill switch、vendor fallback、manual queue。
11. 证据如何保留？	request、impact assessment、eval result、approval、deployment metadata、runtime traces、post-release metrics、exception log。
12. 什么时候复盘？	24h / 72h / 14d monitoring review、monthly control review、quarterly model risk review、incident-triggered review。

2.2 变更影响不是单点风险，而是路径风险

Release governance 的目标不是把每个 artifact 分别审批一遍，而是识别“从变更到客户影响”的路径。

Change artifact
-> AI behavior
-> workflow step
-> business decision
-> customer / regulatory / operational impact
-> control evidence

示例：

Prompt wording change
-> explanation becomes more definitive
-> credit adverse action explanation generated
-> customer receives inaccurate reason
-> complaint, fair lending concern, audit issue
-> missing evidence if prompt version and eval result are not retained

真正成熟的团队会建立 AI Impact Graph，而不是只维护一个 release note。

3. Change Taxonomy：AI 变更分类法

分类法的作用不是填表，而是决定 risk tier、eval gate、审批人、放量策略和回滚方式。一个变更可以属于多个类别；多类别变更默认按最高风险等级治理。

变更类别	典型变更	主要风险	必要证据
Model	foundation model、fine-tuned model、classification model、ranking model、fraud model、decision model 版本更新	行为漂移、准确率退化、偏差变化、拒答率变化、成本/延迟变化、供应商不可解释变更	model card、version diff、eval result、validation note、routing config、rollback path
Prompt	system prompt、developer prompt、task prompt、few-shot examples、output schema instruction、refusal instruction	语气过度确定、合规披露缺失、越权建议、解释不一致、prompt injection 防护减弱	prompt diff、scenario eval、policy eval、red-team cases、approval record
RAG corpus / index	知识文档增删、chunking、metadata filter、index rebuild、document ranking、freshness window	检索不到关键政策、引用过期知识、跨区域知识混用、敏感文档暴露、答案依据不可复现	corpus manifest、document lineage、index version、retrieval eval、access review
Embedding	embedding model、维度、normalization、vector store config、distance metric	语义召回变化、历史索引不兼容、召回偏向、成本/延迟变化	embedding version、index compatibility test、recall benchmark、migration plan
Reranker	reranker model、top-k、score threshold、boost rule、hybrid search 权重	正确证据排序下降、长尾知识被压低、合规文档排位变化、解释引用不稳定	ranking eval、critical document recall、side-by-side result review
Tool / API contract	CRM、case management、payment、account servicing、KYC、fraud queue、email/SMS tool schema 或权限变化	从 read-only 变成 write-enabled、字段语义误解、幂等性缺失、审批绕过、误操作客户账户	OpenAPI / AsyncAPI diff、contract test、permission review、idempotency evidence、kill switch
Policy / DMN / rules	eligibility rule、AML rule、complaint routing rule、fee waiver rule、guardrail policy	业务政策变更未同步、规则冲突、例外处理不一致、监管口径错误	ruleset version、DMN decision table diff、policy owner sign-off、decision trace
Eval set / rubric	golden dataset、edge cases、judge prompt、rubric、pass threshold、sampling strategy	release gate 被放松、历史结果不可比、评价目标偏移、过拟合 eval	dataset card、rubric diff、baseline comparison、independent challenge
Vendor	LLM provider、embedding provider、vector DB、observability vendor、moderation vendor、region routing	合同边界、数据出境、可用性、不可解释升级、成本、退出困难、SLA 变化	vendor risk review、DPA/SLA evidence、exit plan、fallback test、data flow review
Workflow	human handoff、maker-checker、case queue、SOP、role responsibility、exception handling	人工复核被压缩、责任不清、服务 SLA 受损、操作风险上升	BPMN / service blueprint diff、RACI、training evidence、operations sign-off
UI	disclosure、confidence display、citation display、action button、review screen、override reason	用户误信、员工过度依赖、关键警示不可见、错误操作入口太近	UX review、accessibility check、disclosure approval、human factors test
Threshold	confidence threshold、similarity threshold、risk score cutoff、alert trigger、auto-approve / auto-escalate threshold	漏报/误报变化、自动化边界扩大、人工队列容量冲击	threshold analysis、backtest、capacity impact、business owner approval
Monitoring	metric definition、alert threshold、sampling rate、trace attribute、dashboard query、on-call route	异常不可见、误报疲劳、证据断层、低频高损场景漏检	observability diff、metric lineage、alert test、runbook update
Data retention	prompt/response log retention、PII redaction、trace retention、eval data retention、evidence pack retention	隐私过度保留、审计证据不足、不可复现、数据主体请求无法处理	retention schedule、privacy review、redaction test、evidence retention mapping

3.1 Risk tiering：按“客户影响 + 控制影响 + 可回滚性”分级

建议把 AI 变更分为四级。

Tier	适用情形	Gate 强度	发布策略
Tier 0 Routine	不改变客户输出、不改变自动化决策、不改变数据流、不改变工具权限；例如内部日志标签修正	peer review + automated test	标准发布；保留变更记录
Tier 1 Low	影响内部员工辅助体验，但不直接写入客户记录或自动决策；例如客服知识引用排序小调整	regression eval + product approval	小流量 canary；监控员工 override
Tier 2 Controlled	影响客户可见内容、合规解释、case routing、人工复核优先级或关键知识库	cross-functional review + shadow/canary + rollback plan	分阶段 ramp；24h/72h review；evidence pack 必备
Tier 3 Material	影响授信、AML、欺诈拦截、账户限制、付款、合规报告、客户权益或 write-enabled tool	formal governance board + independent validation/effective challenge + security/privacy/legal review	shadow-first；human-in-the-loop；limited go；明确 no-go 和 kill switch

判断口诀：

如果变更会影响“谁被批准、谁被拒绝、谁被调查、谁被收费、谁的账户被改动、谁收到什么解释”，至少按 Tier 2 管。
如果变更扩大自动化权限或减少人工控制，通常按 Tier 3 管。

4. Release Governance Architecture：从 Intake 到 Evidence Pack

AI release governance 是一个控制平面（control plane），不是会议流程。它应该把变更请求、依赖图、风险分级、评估结果、审批记录、发布状态、遥测数据和回滚动作串起来。

Change Intake
-> Risk Classification
-> Impact Graph
-> Regression Eval
-> Security / Privacy / Compliance Review
-> Stakeholder Sign-off
-> Canary / Shadow / Ramp
-> Rollback / Kill Switch
-> Evidence Pack
-> Post-release Monitoring Review

4.1 Change intake：把变更描述成 AI artifact change

普通 release ticket 常写“升级模型”“优化 prompt”“更新知识库”。这对 AI 治理不够。AI change request 必须结构化记录：

字段	要求
Change ID	全局唯一，与 deployment、eval run、approval、trace tag 关联。
Business intent	业务问题、客户价值、风险降低目标、监管或审计驱动。
Artifact changed	model、prompt、RAG、embedding、tool、rules、eval、vendor、workflow、threshold、monitoring、retention。
Intended use	变更适用的业务场景、客户群、渠道、地区、语言、产品线。
Out-of-scope use	明确禁止被该变更影响的场景。
Decision impact	是否影响建议、解释、排序、自动决策、写入操作、升级/拒绝/批准。
Data impact	输入数据、输出数据、日志、PII、敏感属性、跨境、retention。
Control impact	human review、approval、policy guardrail、audit log、monitoring、incident route 是否变化。
Expected behavior	变更后应该出现的行为差异，用业务语言写。
Non-regression expectation	哪些行为必须保持不变。
Rollback method	如何回到上一个可接受版本，预计耗时，责任人。

4.2 Risk classification：按业务后果，而不是按改动大小

一个 3 行 prompt 改动可能是 Tier 3；一个大规模日志重构可能只是 Tier 0。分类必须看后果：

维度	低风险信号	高风险信号
Customer impact	仅内部试用、无客户输出	客户可见解释、建议、收费、拒绝、账户动作
Automation boundary	人只参考 AI，决策不变	AI 自动批准、拒绝、升级、写入、拦截
Regulatory sensitivity	非监管流程	AML、KYC、fair lending、UDAAP、privacy、complaint、suitability
Reversibility	feature flag 秒级回退	数据写入不可逆、外部通知已发送、监管报告已生成
Observability	指标清晰、trace 完整	采样过低、无 prompt/index/tool version、无法复现
Validation maturity	有 golden set 和 baseline	新场景无历史数据、eval 未覆盖长尾
Vendor dependency	内部可控	黑盒升级、SLA/region/data usage 变化

4.3 Impact graph：用图而不是清单分析影响

Impact graph 至少覆盖 8 类节点：

Artifact
-> Runtime component
-> Data object
-> Business rule
-> Workflow step
-> Human role
-> Customer outcome
-> Control / evidence

示例字段：

节点类型	示例
Artifact	prompt `credit_explain_v14`、index `aml_typology_q2_2026`、tool contract `crm.updateCustomer.v3`
Runtime component	orchestrator、retriever、reranker、policy engine、tool gateway、moderation layer
Data object	application attributes、customer profile、case notes、SAR narrative draft、call transcript
Business rule	adverse action reason mapping、AML escalation rule、complaint SLA rule、fee waiver policy
Workflow step	agent review、customer disclosure, supervisor approval、case closure
Human role	banker、analyst、contact center agent、fraud investigator、compliance reviewer
Customer outcome	explanation received、case escalated、account updated、payment blocked、fee refunded
Control / evidence	eval run、approval, trace, override reason、post-release metric, incident runbook

Impact graph 的好处：

发现隐藏依赖：prompt 输出字段被 downstream rules 使用。
发现控制断点：RAG index rebuild 没有记录 document manifest，导致答案引用不可复现。
发现回滚难点：tool contract 变化后旧 agent 不能解析新 CRM response。
发现审批缺口：vendor model upgrade 影响 data residency，但 ticket 只让 ML lead 审批。

4.4 Regression eval：把“质量变好”拆成可比较指标

AI release gate 必须把主指标、保护指标和控制指标分开。

指标类型	示例	用途
Primary quality	answer correctness、retrieval groundedness、classification F1、resolution rate	证明变更达成业务目标
Safety / compliance	PII leakage、policy violation、forbidden advice、unfair explanation、toxicity、jailbreak success	防止合规和客户伤害
Workflow	handoff accuracy、case routing accuracy、agent acceptance、override reason mix、AHT impact	防止运营流程被扰乱
Reliability	latency、timeout、tool error、fallback rate、cost per task	防止生产稳定性退化
Explainability	citation accuracy、reason code consistency、audit trace completeness	支撑客户解释和审计
Monitoring readiness	trace coverage、metric coverage、alert test pass、dashboard freshness	确保上线后可见

Eval gate 设计原则：

不只看平均分，要看 segment：产品、地区、语言、渠道、客户群、风险等级、员工队列。
不只看正确率，要看 harmful failure：错误授信解释、错误 AML 排除、错误账户写入。
不只看新版本，要看 delta：与 production baseline、previous candidate、fallback route 比较。
不只看自动 judge，要有人类抽检和 independent challenge。
不只看离线 eval，要有 shadow / canary 的真实分布数据。

4.5 Security / privacy review：AI 变更常改变数据边界

安全和隐私评审不能只在系统首次上线时做。以下变更必须触发复核：

触发条件	复核重点
新增 tool write action	权限最小化、审批、幂等性、审计日志、replay 防护、kill switch
RAG corpus 新增敏感文档	访问控制、document-level ACL、metadata filter、PII redaction、cross-tenant leakage
Vendor endpoint / model 变更	data usage、retention、region、subprocessor、SLA、incident notification、exit plan
Prompt 增加上下文字段	是否引入敏感属性、客户隐私、员工隐私、不可用于该目的的数据
Telemetry 采样或 retention 变化	是否过度保留 prompt/response、是否影响证据、是否支持删除和脱敏
Eval set 增加真实样本	数据授权、脱敏、labeler access、retention、re-identification risk

4.6 Stakeholder sign-off：签字不是形式，是风险所有权

不同变更需要不同 owner 承担清晰责任。

角色	关注点	不能替代谁
Business owner	业务收益、客户影响、政策符合、运营容量	不能替代 model risk / compliance
AI PM	目标、用户体验、release scope、success metric、rollback criteria	不能替代安全和隐私评审
Solution architect	架构依赖、runtime path、tool contract、observability、rollback	不能替代业务风险接受
Model risk / validation	intended use、validation evidence、limitations、ongoing monitoring	不能替代 product go/no-go
Compliance / legal	监管解释、客户披露、投诉、记录保留、政策约束	不能替代技术可行性
Security / privacy	access、data flow、secrets、PII、retention、vendor controls	不能替代业务 owner
Operations lead	SOP、training、queue capacity、exception handling、manual fallback	不能替代 architecture
Internal audit	控制设计和运行有效性检查	通常不作为 release approver，而是 independent assurance

4.7 Canary / shadow / ramp：先观察，再放权

建议按能力边界分阶段：

阶段	做什么	适用场景
Offline regression	用固定 eval set、历史样本和 synthetic edge cases 比较	所有 Tier 1+
Shadow mode	新版本并行运行，但不影响员工或客户决策	信用、AML、欺诈、客服建议
Read-only canary	新版本只读系统数据，不写入业务系统	RAG、explanation、case summary
Human-reviewed canary	AI 输出必须经人工确认	高风险解释、case routing、customer response
Limited write	只允许低风险字段或低风险客户群写入	CRM note、case tag、non-financial preference
Ramp	按地区、渠道、产品、客户群、队列逐步放量	多渠道金融零售场景
Full release	达到预设稳定期和 KRI 门槛后全量	证据完整且回滚路径验证通过

4.8 Rollback：AI 回滚不是只回代码

AI 回滚对象包括：

对象	回滚动作
Model route	切回 previous approved model 或 fallback model；保留 candidate traces。
Prompt	切回上一版 prompt template 和 few-shot examples；确认 prompt variables 兼容。
RAG index	切回 previous index snapshot；冻结新 document ingestion；保留 corpus manifest。
Embedding / reranker	切回 compatible retrieval stack；避免新 embedding 与旧 index 混用。
Tool contract	关闭 write permission；切回旧 schema adapter；启用 manual processing queue。
Rules / policy	恢复上一版 DMN/ruleset；对发布期间 decision trace 做 sample review。
Vendor	切换备用 provider / region / model；执行 data flow exception log。
Workflow	恢复原 SOP、队列规则和人工复核阈值；通知 operations。
Monitoring	恢复原 alert threshold；保留异常期 dashboard snapshot。

Rollback plan 必须提前演练。未演练的 rollback 只是愿望。

4.9 Evidence pack：发布证据必须能复现当时决策

每次 Tier 2 / Tier 3 AI release 至少保留：

Evidence	说明
Change request	变更目标、范围、artifact、risk tier、owner。
Impact graph	依赖、业务流程、客户结果、控制、证据链。
Diff package	prompt diff、rules diff、contract diff、corpus manifest、model version、threshold diff。
Eval package	eval dataset version、rubric、runner、judge、result、failure analysis、approval threshold。
Security/privacy review	data flow、access、retention、vendor、PII redaction、tool permission。
Sign-off record	谁在何时基于什么证据批准；例外和条件是什么。
Deployment metadata	environment、route、feature flag、traffic percentage、time window、operator。
Runtime telemetry	trace coverage、metric coverage、logs、sampling rate、redaction status。
Rollback evidence	rollback method、test result、owner、RTO、known constraints。
Post-release review	24h/72h/14d 指标、KRI、incident/complaint/override、decision outcome。

5. Financial Retail Cases

5.1 Credit explanation AI prompt change

场景：信用卡申请被拒后，AI 根据模型 reason codes 和政策文档生成客户可读解释。团队想把 prompt 从“简洁解释”改成“更具同理心和可行动建议”。

看似只是文案优化，但在金融零售中至少触发 Tier 2，某些机构会按 Tier 3 管。

影响点	风险
Reason code 映射	prompt 可能把模型 reason code 改写成不准确或未经批准的原因。
Fair lending / adverse action	解释不能引入未使用的因素，不能暗示受保护属性相关推断。
Customer actionability	“建议提高收入”这类表述可能不合适或不可操作。
Complaint handling	客户引用 AI 解释投诉时，机构必须复现当时版本。
UI disclosure	AI 解释是否需要人工审核、是否有正式模板边界。

治理动作：

建立 prompt diff，标明 system instruction、few-shot examples、forbidden wording、approved phrases。
用 golden set 覆盖拒绝原因组合、薄信用文件、收入不稳定、新移民、小微商户、共同申请人。
加入 fairness-sensitive review：检查解释是否新增模型未使用的原因、是否造成群体差异化措辞。
Shadow run 历史拒绝样本，比较 reason code consistency、customer readability、policy violation。
Human-reviewed canary：前两周所有新 prompt 解释进入 reviewer queue，抽样检查。
保留 prompt version、model reason code、generated explanation、human edit、final customer communication。

Go / no-go 门槛示例：

Gate	门槛
Reason code consistency	关键 reason code 不得被遗漏或错误替换。
Forbidden wording	0 个未经批准的授信建议、0 个受保护属性相关暗示。
Human edit rate	canary 阶段人工重大修改率不高于 baseline + agreed tolerance。
Complaint signal	投诉率、解释不清原因、升级率无异常上升。

5.2 AML typology knowledge update

场景：金融犯罪团队发布新的 typology，要求 AML investigation assistant 在 case summary 和 alert triage 中引用新红旗指标。

变更对象不一定是模型，主要是 RAG corpus、metadata、retrieval filter、analyst workflow 和 monitoring。

影响点	风险
Knowledge freshness	新 typology 未被检索到，分析员继续依据旧知识判断。
Source authority	非正式草稿进入知识库，导致错误升级。
Jurisdiction filter	不同国家/州的 AML 规则混用。
Analyst overreliance	AI 摘要过度确定，掩盖 evidence gaps。
Auditability	SAR 相关分析必须能追溯引用来源和版本。

治理动作：

建立 corpus manifest：文档 ID、版本、owner、approval date、jurisdiction、effective date、expiry/review date。
重新生成 index，记录 chunking config、embedding version、metadata filters、index hash。
运行 retrieval eval：给定 typology-specific scenarios，检查 top-k 是否召回权威文档。
Reranker 评估：关键红旗指标文档必须稳定排在 analyst 可见范围内。
Shadow triage：对最近案件并行生成摘要，不影响实际 SAR decision。
Analyst training：解释新 typology、AI 引用方式、不得把 AI 输出作为唯一依据。
Post-release dashboard：新 typology citation rate、analyst override、false positive feedback、case escalation pattern。

Rollback 不是删除知识库这么简单。如果新 typology 已被用于案件升级，需要保留版本，并对受影响案件做 sample review。

5.3 Customer-service RAG index rebuild

场景：客服 AI 助手使用产品政策、费用表、投诉处理流程和运营 SOP 回答员工问题。团队重建 RAG index 以提升召回率。

常见误判是把 index rebuild 当作低风险工程任务。实际上它可能改变员工对客户的承诺。

风险路径	示例
费用政策错误	AI 引用旧 fee waiver policy，客服承诺错误减免费用。
投诉 SLA 错误	AI 漏掉高风险投诉升级要求，造成 SLA breach。
产品地区混用	某州/省政策被错误用于其他地区客户。
ACL 漏洞	内部高敏政策或员工资料进入普通客服检索范围。
Citation drift	答案正确但引用错误，削弱审计和员工信任。

治理动作：

Index rebuild 前冻结 corpus snapshot，生成 document manifest。
建立 critical policy recall suite：费用、投诉、账户关闭、欺诈申诉、客户身份核验。
对比 old index vs new index 的 answer groundedness、citation accuracy、retrieval latency。
做 region / product / channel segmentation，确保 metadata filter 生效。
Canary 到低风险队列，要求员工反馈“helpful / incorrect / missing / outdated”。
设置 rollback：vector store alias 指回上一版 index，停止新 ingest job。
上线 72 小时内 daily review：top failed queries、no-answer rate、escalation rate、complaint keywords。

5.4 Vendor model upgrade

场景：供应商宣布默认模型从 Model A 升级到 Model B，承诺质量更好、价格更低、上下文更长。团队想直接切换。

金融零售不应接受“供应商默认升级 = 内部自动升级”。供应商升级必须作为 vendor + model + eval + data flow 变更治理。

影响点	风险
Output style	更自信、更长、更少拒答，可能影响合规边界。
Refusal behavior	对敏感金融建议、身份核验、投诉场景的拒答模式变化。
Tool calling	function calling 参数更激进或 schema adherence 变化。
Data processing	retention、training opt-out、region、subprocessor、logging policy 变化。
Cost / latency	单次成本下降但 token 输出变长，队列延迟上升。
Evaluation comparability	旧 eval baseline 不再直接可比，需要重新跑。

治理动作：

要求 vendor release note、model card、data processing statement、deprecation timeline、rollback option。
对所有 Tier 2 / Tier 3 use cases 跑 full regression，不允许只用 vendor benchmark。
Shadow mode 覆盖真实 production distribution，比较 policy violation、refusal、tool error、latency、cost。
审查合同和数据流：region、retention、training use、subprocessor、incident notification。
采用 route-based ramp：按 use case 逐个切换，不做全局默认切换。
保留 vendor version pin 或 internal model routing alias，避免隐式升级。

Release decision memo 必须说明：升级收益是什么、哪些场景不升级、何时重新评估、供应商强制退役旧模型时的替代路径。

5.5 Tool contract change to CRM write action

场景：客服 AI 原来只读 CRM。新版本允许 AI 根据通话内容写入客户偏好、联系地址备注、投诉标签和 follow-up task。

这是典型 Tier 3。风险不在“模型会不会回答错”，而在“AI 能否改变系统 of record”。

影响点	风险
Permission boundary	AI 从建议者变成执行者。
Field semantics	`customer_preference`、`marketing_consent`、`complaint_flag` 等字段有法律和运营含义。
Idempotency	重复调用造成重复 task、错误标签或覆盖人工记录。
Human confirmation	员工是否明确确认每个写入字段。
Audit log	必须区分 AI 建议、员工确认、系统写入和后续修改。
Reversal	错误写入如何撤销，是否影响 downstream campaign 或 complaint workflow。

治理动作：

Contract-first：OpenAPI / AsyncAPI schema 明确字段、枚举、required、nullable、idempotency key、error code。
Tool gateway policy：AI 不直接调用 CRM，必须经 policy engine 检查权限、字段、客户状态和 confirmation token。
Human-in-the-loop：员工逐字段确认；高风险字段只生成 draft，不自动写入。
Contract test：schema compatibility、invalid enum、duplicate request、timeout retry、partial failure、rollback compensation。
Canary：只开放低风险字段；记录每次 suggestion -> edit -> confirmation -> write。
Monitoring：write error rate、manual edit rate、reversal rate、complaint tag spike、downstream campaign exclusion errors。
Kill switch：秒级关闭 write action，保留 read-only assistant。

6. Artifact Templates

这些模板可以作为作品集和真实项目的起点。真实机构应映射到内部 Jira / ServiceNow / GRC / model inventory / CI-CD / observability 平台字段。

6.1 AI Change Request

Section	Field	示例要求
Identity	Change ID	`AI-CR-2026-0715-CRM-WRITE-V1`
Identity	Use case	客服 AI CRM 写入辅助
Identity	Requestor / owner	AI PM、business owner、system owner、risk owner
Business	Business intent	降低通话后处理时间，同时保持客户资料准确性和投诉标记合规性
Business	Customer / employee impact	客服员工、信用卡客户、投诉客户、营销偏好受影响客户
Scope	Artifact changed	tool contract、workflow、UI confirmation、monitoring、training SOP
Scope	In scope	写入低风险联系偏好备注、创建 follow-up task
Scope	Out of scope	修改法定地址、营销同意、投诉最终分类、费用减免
Risk	Proposed risk tier	Tier 3 Material
Risk	Rationale	write-enabled system of record，影响客户资料和后续流程
Evaluation	Regression suite	tool contract test、human confirmation test、CRM sandbox write test、audit log test
Controls	Required approvals	business、CRM system owner、security、privacy、compliance、operations、architecture
Release	Strategy	read-only shadow -> human-reviewed canary -> limited write -> ramp
Rollback	Method	disable write tool flag；route to manual note-taking；reconcile affected records
Evidence	Evidence location	change request、diff、eval run、approval、deployment、dashboard、post-release review

6.2 Impact Assessment Matrix

Dimension	Questions	Evidence
Business decision	变更是否影响批准、拒绝、升级、调查、费用、客户沟通、账户动作？	process map、decision table、sample cases
Customer segment	哪些客户群、语言、地区、渠道、产品线受影响？	segmentation analysis、scenario coverage
Artifact dependency	是否同时改变 model、prompt、index、rules、tool、vendor、threshold？	artifact manifest、diff package
Data boundary	是否新增字段、PII、敏感属性、跨境、retention、logging？	data flow diagram、privacy review
Control boundary	是否减少人工复核、扩大自动化、改变审批、改变监控？	RACI、control mapping、approval log
Evaluation coverage	eval 是否覆盖高风险场景、长尾、historical baseline、synthetic edge？	eval dataset card、result report
Security boundary	权限、secrets、API scope、tool gateway、ACL 是否变化？	security review、contract tests
Operational capacity	人工队列、training、SOP、on-call、exception handling 是否准备好？	training record、capacity estimate
Rollback feasibility	回滚是否秒级、分钟级、小时级？是否存在不可逆外部影响？	rollback plan、drill evidence
Evidence readiness	是否能复现版本、输入、输出、审批、部署、监控？	evidence pack checklist

6.3 Regression Gate Checklist

Gate	Pass Criteria	Owner
Artifact diff reviewed	所有 changed artifacts 有版本号、diff、owner 和 effective date	Release lead
Intended use unchanged or approved	任何 intended use 扩展都有 business 和 risk approval	AI PM / business owner
Golden set passed	主指标达到门槛，关键高风险样本无 critical failure	EvalOps
Policy test passed	forbidden advice、PII leakage、unsafe tool use、unapproved disclosure 无 critical failure	Compliance / safety
Segment regression reviewed	关键客户群、语言、地区、产品线无不可接受退化	AI PM / analytics
Tool contract test passed	schema、permission、idempotency、error handling、audit log 均通过	Solution architect
Security/privacy review completed	data flow、retention、vendor、access、redaction 已批准	Security / privacy
Monitoring ready	trace、metric、log、dashboard、alert、runbook 已验证	SRE / observability
Rollback verified	rollback route、owner、RTO、communication plan 已演练	Release lead
Evidence pack complete	request、impact、eval、approval、deployment、monitoring 证据齐全	Governance lead

6.4 Rollback Plan

Field	内容
Rollback trigger	critical eval failure in canary、complaint spike、override spike、policy violation、tool write error、latency breach、vendor incident
Decision authority	release commander、business owner、incident commander、risk owner
Technical action	disable feature flag、route to previous model、restore prompt/index/rules/tool version、close write permission
Operational action	notify frontline, switch to manual SOP, open review queue, freeze affected automation
Customer action	decide whether customer communication, correction, apology, fee reversal or complaint handling is required
Data action	tag affected interactions, preserve traces, stop problematic logging, begin reconciliation
Evidence action	capture dashboard, deployment metadata, trace samples, decision log, timeline
Recovery criteria	no new critical events, affected cases triaged, stable baseline restored, owners approve re-entry
Re-release path	root cause fixed, regression suite expanded, governance board reviews new release memo

6.5 Release Decision Memo

Section	内容
Decision	Go、limited go、no-go、rollback、hold for evidence、hold for validation
Scope	use case、channel、customer segment、traffic percentage、time window
Change summary	artifact diffs、business intent、expected behavior change
Risk classification	tier、rationale、material risks、residual risk
Evaluation summary	primary metrics、safety metrics、segment regression、failure analysis
Control summary	human review、policy guardrail、tool gateway、monitoring、incident route
Approval conditions	release conditions、traffic caps、manual review period、stop criteria
Rollback readiness	rollback method、tested date、RTO、owner
Evidence	links/IDs for request、impact graph、eval run、approvals、deployment plan、dashboard
Final accountability	named business owner and release owner accept the decision within stated boundaries

6.6 Post-release Monitoring Dashboard

Panel	Metric	Why it matters
Release exposure	traffic %, users affected, segment distribution, model/prompt/index/tool version	知道谁实际暴露在新版本下
Quality	task success, groundedness, reason code consistency, retrieval hit, tool success	证明行为符合预期
Safety/compliance	policy violations, PII leakage, forbidden content, unapproved advice, citation errors	发现客户和合规伤害
Human control	override rate, edit rate, handoff rate, escalation rate, review backlog	观察人工控制是否被冲击
Customer signal	complaint count, complaint themes, repeat contact, abandonment, CSAT/NPS proxy	观察真实客户反馈
Operations	AHT, queue SLA, case reopen, manual reconciliation volume	观察运营成本和容量
Reliability/cost	latency, timeout, error, fallback, cost per task, token usage	观察生产稳定性
Drift	input distribution, retrieval distribution, output category, tool action mix	发现行为分布偏移
Evidence completeness	trace coverage, prompt version coverage, index version coverage, approval links	证明可审计性没有断裂

7. Metrics and KRIs

AI release governance 的指标不应只看“上线成功率”。真正要看的是缺陷是否逃逸、控制是否有效、证据是否完整、组织是否能快速止损。

Metric / KRI	定义	解读
Escaped defects	上线后才发现且本应由 eval / review 捕捉的问题数量	衡量 release gate 是否有效
Eval regression	candidate 相比 baseline 在关键指标和关键 segment 的退化	衡量质量和公平性风险
Critical scenario failure	高风险样本出现 policy、safety、decision、tool write critical failure	通常触发 no-go 或 rollback
Override spike	员工拒绝、修改或覆盖 AI 建议的比例异常上升	说明 AI 行为与现实流程脱节
Complaint spike	客户投诉、解释不清、错误承诺、账户处理争议上升	真实客户伤害信号
Drift	输入分布、retrieval source、output category、tool action mix、score distribution 偏离 baseline	表示模型或业务环境变化
Rollback frequency	单位时间内 AI release rollback 次数和原因	过高说明 release quality 或变更粒度有问题
Rollback time	从触发条件到恢复稳定 baseline 的时间	衡量 kill switch 和 operational readiness
Evidence completeness	release evidence pack 中必备字段和证据覆盖率	衡量审计就绪度
Approval SLA	从 request 到 required approvals 完成的时间	衡量治理效率，过慢会导致绕流程
Exception aging	未关闭 release exception 的天数和风险等级	衡量 residual risk 管理
Monitoring coverage	带有 version tags、trace IDs、policy decisions、tool call metadata 的请求比例	衡量可观测性
Alert precision	有效告警 / 总告警	过低会造成告警疲劳
Human review backlog	需人工复核的 AI 输出积压量	衡量放量是否超过运营容量
Vendor change lead time	从 vendor notice 到内部评估完成的时间	衡量第三方变更治理能力

7.1 KRI trigger examples

Trigger	Suggested action
Critical policy violation > 0 in Tier 3 canary	Stop ramp, freeze traffic, root cause review, expand eval set
Tool write reversal rate > baseline + tolerance	Disable write action, route to manual queue, review affected records
Complaint spike after prompt change	Pause release, sample customer communications, compliance review
Retrieval critical document recall below threshold	Roll back index, repair corpus metadata, rerun retrieval eval
Evidence completeness below required threshold	Hold release or classify as governance exception with executive approval
Vendor latency p95 breaches SLA in high-volume queue	Route to fallback, reassess cost/capacity, update vendor risk log

8. Operating Model and RACI

AI change governance 需要跨职能，但不能让所有人审批所有事。建议建立 risk-tiered RACI。

Activity	AI PM	BA / CBAP+	Solution Architect	EvalOps	Security / Privacy	Compliance / Model Risk	Operations	Release Governance
Change intake	A	R	C	C	C	C	C	R
Process impact	C	A/R	C	C	C	C	R	C
Artifact diff	C	C	A/R	R	C	C	C	C
Risk tiering	R	R	C	C	C	A/R	C	A/R
Impact graph	R	A/R	A/R	C	C	C	C	C
Eval design	C	C	C	A/R	C	C	C	C
Security/privacy review	C	C	C	C	A/R	C	C	C
Compliance / model risk review	C	C	C	C	C	A/R	C	C
Release decision	R	C	C	C	C	C	C	A
Canary monitoring	R	C	R	R	C	C	A/R	A/R
Rollback decision	C	C	R	C	C	C	R	A/R
Evidence pack	C	C	C	C	C	C	C	A/R

Legend: A = accountable, R = responsible, C = consulted.

8.1 Governance board design

不要把 AI governance board 设计成所有变更都必须排队汇报的瓶颈。建议：

Forum	处理范围	节奏
Daily release triage	Tier 0 / Tier 1，低风险快速决策，异常升级	每日或按需
Weekly AI release review	Tier 2，跨团队 release decision、canary review、exception aging	每周
Material AI change board	Tier 3，高客户影响、高监管风险、write-enabled、vendor material change	按需，必须有 quorum
Monthly control review	KRI、escaped defects、evidence completeness、approval SLA、rollback trends	每月
Quarterly management review	AIMS、portfolio risk、model inventory、vendor risk、audit findings、policy updates	每季度

9. Architecture Patterns for Governed AI Release

9.1 Version everything that can change behavior

必须版本化：

model route and model parameters
prompt template and prompt variables
RAG corpus manifest, chunking config, embedding model, index snapshot, retriever config, reranker config
tool schema, permission scope, policy gateway rules
DMN / ruleset / threshold config
eval dataset, rubric, judge model/prompt, evaluator code
vendor endpoint, region, SLA, data processing terms
monitoring query, alert threshold, sampling config, retention policy

每个 runtime trace 至少带：

change_id
release_id
use_case_id
model_version
prompt_version
index_version
retriever_version
tool_contract_version
ruleset_version
eval_baseline_id
policy_decision_id
human_review_status

9.2 Use a release control plane

一个成熟架构通常包含：

Component	Function
AI artifact registry	存放 model、prompt、index、rules、tool contract、eval set、threshold 的版本和 metadata
Policy gateway	对 tool calls、data access、customer segment、risk tier 做 runtime policy enforcement
EvalOps pipeline	离线和 shadow eval，生成可比较结果和 release gate status
Release orchestrator	控制 route、feature flag、traffic split、canary、ramp、rollback
Observability layer	收集 traces、metrics、logs、version tags、policy decisions、tool outcomes
Evidence binder	自动汇总 request、diff、eval、approval、deployment、monitoring、rollback evidence
Incident integration	把 KRI trigger 连接到 incident management、manual queue、customer remediation

9.3 Separate behavior release from code deployment

AI 系统常出现“代码没发版，但行为变了”：

vendor 默认模型升级；
RAG 文档自动 ingest；
prompt 在配置中心被改；
threshold 由运营人员调整；
eval judge 被替换；
policy rule 从 GRC 系统同步；
monitoring query 改了采样窗口。

所以 governance 不能只挂在 CI/CD。要把行为相关配置接入 release governance。

建议原则：

Any artifact that can change customer-facing or decision-support behavior must be treated as release-controlled.

9.4 Contract-first tool governance

所有 write-enabled tool 必须经过 contract-first 设计：

Requirement	Explanation
Explicit schema	字段、类型、枚举、约束、错误码必须稳定。
Permission scope	read、draft、write、submit、approve、reverse 分开授权。
Idempotency	所有写操作必须支持 idempotency key 或 compensating control。
Confirmation token	高风险写入必须有 human confirmation 或 policy-issued token。
Audit trail	记录 AI suggestion、human edit、final action、actor、timestamp、customer impact。
Dry-run mode	canary 前必须支持 sandbox 或 dry-run。
Kill switch	可按 tool、field、use case、customer segment 关闭。

9.5 Observability for AI change impact

OpenTelemetry 的 traces、metrics、logs 思路可以扩展到 AI runtime。关键不是“打更多日志”，而是让每一次 AI 行为能被关联到版本、输入、检索、决策、工具调用和人工控制。

Trace span 示例：

customer_interaction
  -> policy_precheck
  -> prompt_build
  -> retrieval_query
  -> rerank
  -> model_inference
  -> policy_postcheck
  -> tool_call_dry_run
  -> human_review
  -> tool_write
  -> customer_response

关键 attributes：

Attribute	示例
`ai.change_id`	`AI-CR-2026-0715-CRM-WRITE-V1`
`ai.release_id`	`rel-2026-07-22-003`
`ai.risk_tier`	`Tier3`
`ai.prompt.version`	`credit_explain_v14`
`ai.rag.index_version`	`aml_typology_q2_2026_hash`
`ai.tool.contract_version`	`crm.updateCustomer.v3`
`ai.policy.ruleset_version`	`customer_service_policy_2026_07`
`ai.eval.baseline_id`	`golden_credit_explain_2026_06`
`ai.human.review_status`	`approved_with_edit`
`ai.rollback_group`	`crm_write_canary_group_a`

Privacy note：不要把原始 prompt、客户 PII、敏感 case notes 无控制地写入 telemetry。需要 redaction、field-level access、retention policy 和 evidence sampling strategy。

10. Anti-patterns

Anti-pattern	为什么危险	更好的做法
“只是 prompt 改动，不需要治理”	prompt 可改变合规解释、拒答边界、tool calling、客户承诺	prompt diff + scenario eval + approval + version tag
“RAG index 每晚自动重建”	知识来源、ACL、chunking、embedding 变化会改变答案和证据	corpus manifest + index version + retrieval eval + rollback snapshot
“供应商模型更强，直接升级”	vendor benchmark 不代表本机构业务、监管和客户场景	internal regression + data flow review + route-based ramp
“eval set 改了但 release gate 没变”	历史 baseline 不可比，可能无意放松门槛	eval dataset versioning + baseline recalibration + approval
“监控阈值只是 SRE 调整”	监控阈值改变异常发现能力，也改变控制运行有效性	alert threshold change request + runbook update + evidence
“只要有人审就安全”	人工复核可能形式化、过载或缺少上下文	human factors test + override monitoring + capacity control
“回滚就是 redeploy 旧代码”	AI 行为由 prompt/index/model/rules/tool/vendor 共同决定	artifact-level rollback matrix + drill
“审计证据上线后再整理”	事后补证据不可复现，容易遗漏版本和审批上下文	evidence generated in workflow

11. Interview Section

11.1 30-second answer：How do you govern AI changes after launch?

我不会把 AI 上线后的变更只当成 model update 管。金融零售里的 AI 行为由 model、prompt、RAG index、tool contract、policy rules、eval set、vendor、workflow 和 monitoring threshold 共同决定。我的做法是建立 risk-tiered release governance：每个变更先做 artifact-level intake 和业务影响分级，再画 impact graph，明确会影响哪些决策、客户群、控制和证据；之后跑 regression eval、security/privacy/compliance review，按风险选择 shadow、canary、human-reviewed ramp 或 full release。所有发布都必须有 rollback plan、runtime telemetry 和 evidence pack，确保出问题能止损、复现和审计。

11.2 2-minute answer：How do you govern AI changes after launch?

上线后的 AI 治理重点不是“模型有没有换”，而是“系统行为有没有变，以及这种变化会不会影响客户、控制和审计证据”。我会把 AI change impact 分成多类：model、prompt、RAG corpus/index、embedding、reranker、tool/API contract、policy/DMN rules、eval set/rubric、vendor、workflow、UI、threshold、monitoring 和 data retention。任何能改变客户输出、员工决策支持、系统写入、风险评分、人工复核或监管证据的 artifact，都进入 release-controlled 范围。

流程上，我会先让 change request 结构化描述业务意图、变更对象、intended use、out-of-scope use、客户和流程影响、数据边界、控制变化、预期行为和回滚方式。然后做 risk classification，不按代码大小分级，而按客户影响、自动化边界、监管敏感度、可回滚性、可观测性和验证成熟度分 Tier。接着画 impact graph，把 artifact 连接到 runtime component、数据对象、业务规则、workflow step、human role、customer outcome 和 control evidence，避免漏掉 hidden dependency。

上线前的 gate 包括 regression eval、segment analysis、policy/safety test、tool contract test、security/privacy review、stakeholder sign-off 和 rollback drill。Tier 2 或 Tier 3 变更通常先 shadow，再 read-only canary 或 human-reviewed canary，最后按地区、渠道、客户群或队列 ramp。上线后我会用 OpenTelemetry-style traces、metrics 和 logs 追踪 model/prompt/index/tool/ruleset version、policy decision、human override、complaint、drift、latency、cost 和 evidence completeness。触发 critical policy violation、override spike、complaint spike、tool write reversal 或 retrieval recall 下降时，按预案 rollback 或关闭对应能力。

最后，每次高风险 release 都必须生成 evidence pack：change request、impact assessment、artifact diff、eval result、security/privacy review、approval record、deployment metadata、runtime dashboard、rollback evidence 和 post-release review。这样才能同时满足产品迭代、模型风险管理、运营控制和监管审计的要求。

12. Portfolio Exercise

目标：做一个可展示的“AI Change Impact / Release Governance”作品集包，模拟金融零售 AI 客服助手从 read-only RAG 升级到 CRM write-enabled assistant。

12.1 Scenario

一家零售银行的客服 AI 助手当前能力：

根据产品政策和 SOP 回答客服员工问题；
生成通话摘要；
建议 follow-up action；
只读 CRM 和 case management 系统。

拟变更：

vendor model 从旧版本升级到新版本；
RAG index 加入新的投诉处理 SOP；
prompt 增加“更主动建议下一步行动”的指令；
tool contract 新增 crm.createFollowUpTask 和 crm.updateCustomerPreferenceNote；
monitoring 阈值调整以降低低价值告警；
eval set 增加真实通话样本和高风险投诉样本。

12.2 Deliverables

Deliverable	内容
AI Change Request	明确 change ID、business intent、artifact changed、risk tier、scope、out-of-scope、rollback。
Impact Graph	画出 prompt / RAG / vendor / tool / workflow / customer outcome / evidence 的依赖图。
Risk Classification Memo	说明为什么这是 Tier 3，以及哪些子变更可以拆分为 Tier 2。
Regression Gate Design	设计 eval suites：policy Q&A、complaint SOP、tool contract、human confirmation、segment regression。
Release Decision Memo	给出 limited go 条件、traffic cap、manual review、stop criteria。
Rollback Plan	分别定义 model、prompt、index、tool、workflow、monitoring 的回滚动作。
Monitoring Dashboard Spec	定义 release exposure、override、complaint、tool write、drift、evidence completeness。
Evidence Pack Map	列出每项证据来源、owner、生成时间、保留期限。

12.3 Scoring rubric

Dimension	Strong answer
Multidimensional change analysis	不把问题简化为模型升级，能覆盖 prompt、RAG、tool、workflow、monitoring、eval、vendor。
Financial retail risk sense	能识别投诉、客户资料、费用、合规解释、隐私、系统 of record 的实际风险。
Release architecture	有 control plane、versioning、feature flag、canary、telemetry、rollback。
Evidence quality	每个 decision 都有可追溯证据，不依赖口头承诺。
Practicality	不把所有变更都送最高委员会；能按 risk tier 快速治理。
Interview readiness	能用 30 秒讲清框架，用 2 分钟讲清落地细节。

13. Practitioner Checklist

发布前：

变更对象已分类：model、prompt、RAG、embedding、reranker、tool、rules、eval、vendor、workflow、UI、threshold、monitoring、retention。
已按客户影响、自动化边界、监管敏感度、可回滚性、可观测性和验证成熟度完成 risk tiering。
Impact graph 已覆盖 artifact、runtime、data、rule、workflow、role、customer outcome、control evidence。
Eval suite 已覆盖主指标、保护指标、segment、high-risk scenarios、tool contract 和 monitoring readiness。
Security/privacy review 已覆盖 data flow、PII、access、vendor、retention、redaction。
Stakeholder sign-off 明确谁接受 residual risk，谁负责 release，谁负责 rollback。
Canary / shadow / ramp 策略已定义，包含 traffic cap、duration、stop criteria。
Rollback plan 已演练，明确 artifact-level 回滚动作和 operational fallback。
Runtime telemetry 带有 model、prompt、index、tool、ruleset、release、change ID。
Evidence pack 生成路径已确认，不依赖上线后人工补材料。

发布中：

实时监控 release exposure、critical failures、override、complaint、tool errors、latency、cost。
监控 canary segment 是否与计划一致，未扩散到未批准客户群或渠道。
Operations 明确当前 release 状态、人工复核规则和异常升级路径。
任何 stop criteria 触发时，release owner 有权立即暂停 ramp。
所有人工 override、edit、reversal 和 exception 都带 reason code。

发布后：

24 小时内完成初步 post-release review。
72 小时内复核 complaint、override、drift、tool write、retrieval、policy violation。
14 天内完成稳定性和控制有效性复核。
Escaped defects 已进入 eval set 或 control update。
Release decision、deployment metadata、dashboard snapshot 和 review conclusion 已归档。
未关闭 exceptions 有 owner、due date、residual risk acceptance 和 escalation route。

14. One-page Executive Summary

AI change governance 的核心不是阻止变化，而是让变化可理解、可验证、可控、可回滚、可审计。

高级角色要避免三个误区：

把 AI 变更等同于模型变更。
把 release governance 等同于审批会议。
把监控和证据当成上线后的补充材料。

正确的做法是：

Classify the artifact change.
Map the impact path.
Evaluate against business, safety, compliance and workflow gates.
Release gradually with telemetry.
Rollback by artifact, not only by code.
Preserve evidence as the work happens.
Review production outcomes and feed failures back into evals and controls.

在面试、作品集或真实项目中，一个成熟的 CBAP+ / AI PM / Product Architect / Release Governance Lead 应该能拿出：

AI change taxonomy；
risk-tiered release gate；
impact assessment matrix；
regression eval gate；
artifact-level rollback plan；
post-release KRI dashboard；
audit-ready evidence pack。

这才是金融零售 AI 上线后的 release governance：不是一次上线仪式，而是一套持续运行的 AI control system。