AI Closed-Loop Learning / Corrective Action Architecture Playbook

定位：面向 CBAP+、AI Product Manager、AI BA、AI Product Architect、Model Risk、Compliance、Customer Operations、Data Governance、AI Platform 和金融零售业务负责人。本文关注的不是“收集反馈让模型变好”这种基础说法，而是如何把反馈、投诉、人工覆盖、专家审核、eval 失败、漂移信号、事件和审计发现转成有治理、有根因、有变更、有验证、有证据的闭环纠正体系。

适用边界：本文面向 fraud、credit、KYC / AML、payments dispute、customer servicing RAG、complaints、collections、wealth servicing、internal copilot、agentic workflow 和 AI-assisted operations。它把 closed-loop learning 设计成 CAPA-like corrective and preventive action architecture, 不把它简化成 active learning、RLHF、自动重训或 prompt tweaking。

重要说明：本文是学习、作品集和内部方案训练材料，不构成法律意见、合规结论、审计意见、模型验证报告、监管解释或具体机构政策。正式项目必须由 Legal、Compliance、Model Risk、Fair Lending、Privacy、Security、Third Party Risk、Business Owner、Operations、Customer Experience、Data Governance 和管理层结合机构类型、司法辖区、产品范围、客户影响和内部政策确认。访问日期按 2026-06-30 记录。

---

Source Anchors

以下官方来源是本文的治理锚点。本文把它们转成产品、流程、架构、证据和管理层语言，不把任何框架直接等同于监管合规结论。

Source-to-artifact mapping:

---

1. Executive Framing

1.1 一句话定位

Closed-Loop Learning / Corrective Action Architecture =
把生产反馈和风险信号转成受治理的 issue,
通过 root cause analysis 链接到具体 AI / data / policy / process change,
再用独立、可复现、可审计的证据证明修复有效并防止复发。

对高管来说，它回答四个问题：

1. 我们如何知道 AI 系统正在造成错误、伤害、控制弱点或性能退化？
2. 我们如何判断根因是模型、数据、prompt、RAG、tool、流程、政策、vendor 还是治理？
3. 我们如何确保修复动作被执行到正确 artifact，而不是停留在会议纪要？
4. 我们如何证明修复有效、客户已恢复、风险已下降、同类问题没有继续发生？

1.2 它不是 active learning

Active learning 可以产生输入，但 closed-loop learning 的终点不是“多一些训练数据”，而是“生产问题被纠正且证据可审计”。

1.3 高级 PM / BA / Architect 的角色

---

2. Operating Model

2.1 闭环主流程

Signals
  complaints | appeals | overrides | expert reviews | eval failures | drift alerts | incidents | audits
    -> signal normalization
    -> AI contribution matching
    -> issue taxonomy and severity
    -> containment and customer protection
    -> root cause analysis
    -> corrective and preventive action
    -> linked change artifacts
    -> release and approval gate
    -> effectiveness verification
    -> recurrence monitoring
    -> closure and management reporting

2.2 什么进入 corrective action ledger

2.3 Issue 状态机

---

3. Feedback Taxonomy

3.1 Signal taxonomy

3.2 Feedback usage policy

3.3 Signal quality grading

3.4 关键字段

---

4. CAPA Workflow

4.1 End-to-end workflow

1. Detect signal
2. Confirm AI contribution
3. Classify issue and severity
4. Contain customer and operational risk
5. Assign owner and SLA
6. Perform root cause analysis
7. Define corrective action and preventive action
8. Link actions to change artifacts
9. Approve and release changes
10. Verify effectiveness
11. Monitor recurrence
12. Close with evidence and residual risk decision

4.2 Stage detail

4.3 Severity matrix

4.4 Containment patterns

4.5 Closure gates

---

5. Root Cause Taxonomy

5.1 根因分类

5.2 RCA depth test

5.3 Five-why pattern for AI

Issue: Customer received wrong fee waiver answer.
Why 1: RAG answer cited superseded policy.
Why 2: Retriever ranked old policy summary above current policy.
Why 3: Source metadata did not mark old policy as inactive.
Why 4: Knowledge owner SOP required upload of new policy but not deactivation of superseded content.
Why 5: Release gate tested answer correctness, but not source lifecycle controls.
Corrective action: update metadata and retriever filter.
Preventive action: add source retirement SOP and freshness gate to release checklist.

---

6. Change Linkage

6.1 Evidence graph

signal_id
  -> issue_id
  -> harm_or_control_classification
  -> root_cause_id
  -> corrective_action_id
  -> preventive_action_id
  -> change_request_id
  -> artifact_version
  -> eval_run_id
  -> release_approval_id
  -> monitoring_window_id
  -> closure_memo_id

6.2 Artifact linkage matrix

6.3 Traceability anti-patterns

---

7. Effectiveness Verification

7.1 Verification hierarchy

7.2 Metric families

7.3 Closure rule examples

7.4 Recurrence monitoring

---

8. Update Governance

8.1 Dataset update governance

8.2 Prompt update governance

8.3 Model update governance

8.4 RAG update governance

8.5 Tool and agent update governance

8.6 Policy and workflow update governance

---

9. Dashboards and KRIs

9.1 Executive dashboard

9.2 Product and operations dashboard

9.3 Model risk dashboard

9.4 Data / RAG / tool dashboard

9.5 KRI thresholds

---

10. RACI

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

---

11. Templates

11.1 Corrective Action Intake

11.2 RCA Worksheet

11.3 Change Linkage Memo

11.4 Effectiveness Verification Memo

11.5 Executive Status Memo

---

12. 30-Day Lab

目标：30 天内把 closed-loop learning 从概念训练成可展示的金融零售 AI 产品、架构和治理资产。默认读者已经具备高级 BA / PM / 架构基础，不做基础流程图训练。

---

13. Interview Answers

13.1 Closed-loop learning 和 active learning 有什么区别？

30 秒回答：

Active learning 是选择最值得人工标注的样本来提升模型。Closed-loop learning 是把生产反馈、投诉、override、eval 失败、drift、incident 和 audit finding 转成有治理的 issue, 找根因, 链接到具体变更, 再证明修复有效并防复发。它更接近 AI 版 CAPA。

2 分钟展开：

在金融零售里，反馈不能直接等同于训练数据。投诉可能是客户伤害信号，override 可能是员工对 AI 不信任，eval failure 可能是上线门禁缺口，drift 可能是数据、政策或行为变化。我的设计会先做 signal normalization 和 AI contribution matching，再分类 severity 和 issue type。之后进入 RCA，决定修数据、prompt、model、RAG、tool、workflow 还是 policy。每个 action 都链接到具体版本和审批，并用 locked eval、production KRI、投诉趋势和复发监控证明效果。

13.2 如何设计 CAPA-like AI corrective action workflow？

30 秒回答：

我会设计 detect、match、classify、contain、RCA、action、change、verify、monitor、close 的闭环。关键不是流程图好看，而是每一步都有 owner、SLA、证据和关闭标准。

2 分钟展开：

第一步收集信号，包括投诉、申诉、人工覆盖、专家 QA、eval failure、drift、incident 和 audit finding。第二步确认 AI 系统和版本是否参与客户旅程。第三步按客户影响和控制风险分级。高风险场景先 containment，例如暂停自动回答、提高人工复核或恢复客户。然后做 root cause taxonomy，区分 data、model、prompt、RAG、tool、workflow、policy、vendor 和 governance。修复动作必须进入 change management，并链接到 dataset、prompt、model、index、tool policy 或 SOP。最后通过 eval、replay、canary、QA、生产 KRI 和 recurrence window 验证，证据完整后才能关闭。

13.3 如何避免反馈闭环放大偏差？

30 秒回答：

要区分 feedback usage, 记录采样概率和业务动作, 保护 eval set, 按 segment 看覆盖和伤害, 并保留随机 sentinel 样本。不是所有 override 和投诉都能直接训练。

2 分钟展开：

如果只用被模型拦截的交易训练 fraud 模型，就看不到放行交易里的漏报；如果只用会申诉的客户反馈训练信贷解释，就会低估弱势客户的无声伤害。我的设计会给反馈打 usage tag：train、eval、RCA、monitor、audit、exclude。训练数据要有 lineage、label quality 和 segment coverage。评估集要 lock，避免把失败样本反复调参到通过。生产监控要看投诉、appeal upheld、override、abandonment 和 segment disparity。这样闭环学习不是模型自我强化，而是治理过的学习。

13.4 如何证明一个 prompt 或 RAG 修复真的有效？

30 秒回答：

只说 prompt 改了不够。我要看到 prompt diff、policy mapping、locked eval 通过、生产抽样 QA、相关投诉和 override 下降，并在复发窗口内没有同类问题。

2 分钟展开：

以 RAG 过期政策为例，我会先确认 root cause 是 source lifecycle、retriever ranking、prompt citation instruction 还是 handoff rule。修复后，需要锁定 eval cases，验证答案 claim 被当前有效来源支撑，citation 直接支持答案，高风险 intent 会拒答或升级人工。还要跑生产 canary 和人工 QA，监控相关投诉、agent override、unsupported claim、source freshness 和 escalation miss。如果客户曾受影响，还要证明客户通知、纠正和补偿完成。只有质量、客户和控制指标都通过，才能关闭。

13.5 SR 26-2 对 AI closed-loop learning 有什么影响？

30 秒回答：

SR 26-2 是 2026 年银行模型风险管理的重要锚点，强调风险导向、生命周期、治理、独立挑战和问题整改。Nuance 是它正式聚焦 model risk management, 生成式和 agentic AI 的闭环学习还要叠加 AI 管理体系、消费者合规、隐私、安全、第三方和运营控制。

2 分钟展开：

我会用 SR 26-2 的精神要求模型相关问题有完整生命周期治理：issue identification、risk assessment、validation、change control、independent challenge、documentation 和 closure evidence。对于生成式 AI 或 agentic workflow，我不会只问它是否落入传统 model definition，而是从客户影响和控制角度补充 NIST AI RMF、ISO/IEC 42001、complaint signals、security、privacy、third-party 和 operational resilience。也就是说，SR 26-2 给了模型风险纪律，但 AI corrective action architecture 要覆盖更广系统。

13.6 Root cause taxonomy 为什么重要？

30 秒回答：

没有 root cause taxonomy，团队会把所有问题都归因于“模型不准”或“prompt 要改”。金融 AI 的真实根因可能是数据、标签、RAG source、tool permission、workflow、policy、vendor 或 governance。

2 分钟展开：

正确的根因决定正确的修复。比如客户收到错误费用解释，表面是 RAG 答错；真正根因可能是旧政策未停用、retriever 没有 effective-date filter、prompt 没要求当前来源、客服流程没升级冲突答案。如果只改 prompt，问题会复发。我会建立 root cause taxonomy，并要求 RCA 明确 direct cause、contributing cause、control failure 和 preventive action。这样 closed-loop learning 不只是改输出，而是修系统。

13.7 哪些指标证明 corrective action 工作良好？

30 秒回答：

我会看 open CAPA by severity、aging、repeat issue rate、overdue verification、evidence completeness、complaint / appeal / override trend、post-fix recurrence 和 residual risk acceptance。

2 分钟展开：

一个成熟体系不能只统计关闭了多少 ticket。我要看高严重度 issue 是否及时 containment，RCA 是否按根因分类，action 是否链接到具体 artifact，验证是否按计划完成，客户是否恢复，复发是否下降。对产品和运营，看投诉、appeal upheld、override、abandonment、remediation SLA。对模型风险，看 eval regression、drift-to-action、dataset lineage、validation exception closure。对高管，看 overdue CAPA、repeat root cause、residual risk 和投资缺口。

13.8 如何处理 customer complaint 与模型训练的关系？

30 秒回答：

投诉是高价值 customer harm signal, 但不能直接当标签训练。要先做 case review、AI contribution matching、root cause 和 usage tagging。

2 分钟展开：

客户投诉反映客户体验和影响，但叙述可能不完整或带有情绪。我的做法是把 complaint 进入 harm and corrective action ledger，关联 AI trace、case record、policy version 和 journey step。若复核确认 AI 输出错误，可生成 eval scenario、RCA evidence、customer remediation case，必要时形成训练标签。但进入训练前需要专家 adjudication、privacy review、segment bias check 和 dataset lineage。投诉更直接的价值是暴露产品承诺失败和恢复路径缺陷。

13.9 如何把 closed-loop learning 做成作品集？

30 秒回答：

我会展示一个完整 case：信号 taxonomy、CAPA workflow、root cause taxonomy、change linkage、effectiveness dashboard、RACI 和 executive memo，而不是只展示模型指标。

2 分钟展开：

例如信用卡客服 RAG stale policy case。作品集先展示客户旅程和 AI touchpoint，再展示投诉、agent override、RAG eval failure 和 drift cluster 如何进入 corrective action ledger。然后用 root cause taxonomy 证明问题不是单纯 prompt，而是 source lifecycle、retrieval ranking 和 handoff gate。接着展示 change linkage：source registry、retriever config、prompt version、eval set、release approval。最后用 locked eval、生产 QA、投诉趋势、override 下降和 recurrence window 证明有效。这样体现 PM、BA、架构和治理能力。

13.10 如果团队说“我们已经有 monitoring dashboard”，你怎么回应？

30 秒回答：

Dashboard 只是发现问题，不是闭环。我要看告警是否有 owner、severity、RCA、action、change linkage、verification、closure 和 recurrence monitoring。

2 分钟展开：

很多 AI 团队有很漂亮的 drift、latency、quality dashboard，但问题是报警后没人处理，或者处理后没有证据证明修复有效。我的标准是 shift-to-action 和 signal-to-CAPA。每个红色指标必须映射到 triage owner 和 runbook；每个高风险 issue 必须能链接到具体变更；每个关闭必须有 before / after 证据和残余风险接受。否则 dashboard 只是观察系统，不是治理系统。

---

14. Final Operating View

成熟的 AI closed-loop learning 不是让模型“自动吸收反馈”。成熟状态是组织能持续证明：

We know where AI touches customers and operations.
We capture complaints, appeals, overrides, expert reviews, eval failures, drift, incidents and audits.
We classify issues by customer impact, control weakness and root cause.
We protect customers before permanent fixes are shipped.
We link each corrective action to a specific dataset, prompt, model, RAG, tool, workflow or policy change.
We verify fixes with locked evals, replay, QA, production KRIs and recurrence monitoring.
We prevent eval leakage, feedback bias and undocumented changes.
We can show executives, auditors and regulators what failed, why it failed, what changed, and why it is safe to close.

对 CBAP+、AI PM、AI BA 和 AI Architect 来说，这就是从“AI 系统持续优化”升级为“AI 组织持续学习、纠正、证明和防复发”的核心能力。