AI Continuous Control Monitoring：持续控制监控
AI continuous control monitoring 的核心不是“多做一个 dashboard”，而是把 AI 系统的风险控制从发布前评审改造成持续运行的 assurance loop。金融零售里的 AI workflow 会因为模型版本、prompt、RAG 语料、工具权限、客户群体、政策文本和人工复核容量变化而改变行为；只靠一次性验证无法证明控制在生产中仍然有效。
AI Continuous Control Monitoring / Assurance Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_CONTINUOUS_CONTROL_MONITORING_ASSURANCE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 参考持续 AI risk governance, 把风险识别、衡量、处置和复核变成运行机制 |
| NIST AIRC AI RMF Functions | https://airc.nist.gov/airmf-resources/airmf/ | 用 Govern / Map / Measure / Manage 组织 owner、test、metric、exception 和 action |
| ISO/IEC 42001 | https://www.iso.org/standard/42001 | 用 AI management system 连接运营控制、绩效评价、管理评审和持续改进 |
| Federal Reserve SR 26-2 | https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm | 截至 2026-06-30 的模型风险治理锚点: SR 26-2 于 2026-04-17 superseded SR 11-7 and SR 21-8 |
重要 nuance:
SR 26-2 replaced the old SR 11-7 / SR 21-8 framing on 2026-04-17. For GenAI and agentic AI, 不要机械套用旧 SR 11-7 话术; 应把传统模型风险原则纳入更宽的 AI governance、control assurance、operational risk、privacy、security、third-party risk 和 business control framework。
核心导读
AI continuous control monitoring 的核心不是“多做一个 dashboard”，而是把 AI 系统的风险控制从发布前评审改造成持续运行的 assurance loop。金融零售里的 AI workflow 会因为模型版本、prompt、RAG 语料、工具权限、客户群体、政策文本和人工复核容量变化而改变行为；只靠一次性验证无法证明控制在生产中仍然有效。
这类架构要回答三个问题：哪些控制必须持续运转，什么证据能证明它们运转过，控制失效后谁在多长时间内采取什么动作。成熟做法是把 control objective、test population、KRI、exception、management action 和 evidence contract 绑定到同一个运行模型中。
问题定义
AI 系统的控制失效通常不是“模型突然坏了”这么简单，而是多个组件的轻微漂移叠加后改变业务结果：
- RAG 知识库更新后，关键政策文档召回率下降，客服回答仍然流畅但引用过期。
- Agent tool 权限扩大后，原本只读的助手开始写入 CRM 或触发 case action。
- AML copilot 在新 typology 上 false negative 上升，但月度准确率看起来仍可接受。
- 信贷解释生成器在某个客户 segment 的 reason-code consistency 退化。
- 人工复核队列过载，表面上仍有 human review，实际 reviewer 只能快速放行。
- Incident 被关闭，但 corrective action 没进入 eval set，也没有复发监控。
因此，continuous monitoring 关注的不是单一模型指标，而是“控制目标是否仍被满足”。控制目标可以是：禁止未经授权的客户承诺、限制高影响动作必须复核、确保输出引用当前政策、保证工具调用只在批准范围内、确保异常被升级并留痕。
核心原理/方法
持续控制监控要从 control objective 开始，而不是从 dashboard 指标开始。每个 objective 至少要拆成五层：
| 层次 | 设计问题 | 示例 |
|---|---|---|
| Risk statement | 哪类客户、运营或合规损害需要控制 | 错误解释信用卡费用减免政策 |
| Control objective | 控制要达到什么状态 | 所有费用政策回答必须引用当前生效政策 |
| Control test | 用什么规则证明控制是否运行 | 检查回答中的 citation、source effective date、policy version |
| Evidence field | 哪些字段构成可复盘证据 | prompt id、retrieved chunk id、policy version、answer hash、review state |
| Action rule | 失败后如何处置 | 暂停 intent、提高人工复核、回滚索引、创建 corrective action |
测试类型不应只覆盖模型质量。更完整的 taxonomy 包括：
| 测试类别 | 关注点 |
|---|---|
| Input control test | 输入是否含受限数据、越权数据、未授权目的或 prompt injection 信号 |
| Retrieval control test | 召回内容是否来自批准来源、当前版本、正确区域和允许用途 |
| Output control test | 输出是否含 forbidden claim、未批准承诺、缺失 disclosure 或不一致 reason code |
| Tool control test | 工具调用是否满足权限、审批状态、金额阈值、双人控制和幂等要求 |
| Human review test | 复核是否真实执行、理由是否结构化、SLA 是否满足、override 是否集中 |
| Evidence completeness test | 关键事件字段是否完整，是否可重建一次决策链 |
| Corrective action test | 问题是否进入修复队列，修复是否通过回归验证并监控复发 |
系统/架构模型
一套可运行的 assurance architecture 可以按控制平面和证据平面分离：
AI Use Case Registry
-> Risk & Control Library
-> Control Test Catalog
-> Runtime Policy / Test Engine
-> Telemetry & Evidence Event Bus
-> Evidence Store / Audit Replay
-> KRI & Control Dashboard
-> Exception / CAPA Workflow
-> Management Review & Release Gate
关键组件：
| 组件 | 职责 |
|---|---|
| AI use case registry | 记录 use case、业务 owner、客户影响、模型/工具/数据依赖、风险 tier |
| Risk & control library | 将政策要求转成可执行 control objective、control owner 和 test pattern |
| Runtime policy engine | 在 prompt、RAG、工具调用、输出和复核节点执行 gate 或打标 |
| Test scheduler | 按实时、日批、周批、release-triggered 或 incident-triggered 执行控制测试 |
| Evidence event bus | 捕获输入、检索、输出、工具、复核、审批、异常和动作事件 |
| Evidence store | 保留可重建决策链的结构化记录，支持审计抽样和监管复盘 |
| KRI dashboard | 展示趋势、阈值、异常 aging、控制失效率、残余风险和动作状态 |
| CAPA workflow | 管理 root cause、修复计划、验证结果、复发监控和关闭证据 |
架构重点是把控制测试嵌入运行路径，而不是事后从日志里手工拼证据。无法从系统事件生成证据的控制，通常会退化成截图型控制。
关键机制与取舍
| 机制 | 取舍 |
|---|---|
| 全量测试 vs 抽样测试 | 高影响动作、工具写入和禁止项适合全量检查；低风险输出可用分层抽样，但要证明抽样覆盖高风险 segment |
| 实时阻断 vs 事后侦测 | 实时阻断降低客户损害但增加延迟和误拦截；事后侦测适合趋势、低影响内容和模型漂移 |
| 统一控制库 vs use case 定制 | 统一库保证一致性；use case 定制保证业务贴合。实际应采用 baseline controls + domain extensions |
| 指标阈值 vs 趋势异常 | 阈值适合 hard limit；趋势适合发现缓慢退化。金融场景需要同时看 severity、volume、population 和 duration |
| 自动修复 vs 人工处置 | 自动回滚、降级、停用 intent 可以缩短损害窗口；根因、客户补救和控制变更仍需责任 owner 批准 |
| vendor dashboard vs 内部证据层 | 供应商面板可作补充，但不能替代内部 evidence contract，尤其是跨系统决策链 |
一个常见架构错误是把 KRI 设计成“模型准确率”和“系统可用率”。在 AI 产品中，KRI 应该覆盖控制目标，例如：未经批准 claim 率、政策引用过期率、高风险动作无复核率、tool denial rate、reviewer override concentration、证据字段缺失率、expired exception 数量、repeat issue 率。
证据与控制
可审计的控制证据至少要包含：
| 证据对象 | 关键字段 |
|---|---|
| Control test record | control id、test id、population、sampling logic、threshold、result、severity、owner |
| AI decision trace | use case id、session id、model version、prompt version、retrieved source、tool call、output hash |
| Policy decision event | policy id、input context、decision、reason code、enforcement action、policy version |
| Human review event | reviewer id、skill、queue、decision、reason、evidence viewed、time spent、escalation |
| Exception event | exception id、scope、expiry、compensating control、approver、residual risk |
| Corrective action record | issue id、root cause、change set、verification metric、post-fix monitoring window |
控制有效性不能只证明“有控制存在”，还要证明：
- 控制覆盖了正确 population。
- 触发逻辑与政策版本一致。
- 失败事件进入了可追踪的处置流程。
- 处置动作在 SLA 内完成。
- 修复后指标恢复并经过复发窗口观察。
- 管理层能看到 aging、重复失败、豁免积压和高风险趋势。
金融零售/AI产品场景
信用卡争议助手：AI 为客服整理争议理由、生成客户回复并建议下一步。持续控制应监控错误拒绝理由、缺失法定时限提示、未经批准承诺、证据不足的 case closure、复核队列积压和客户投诉复发。
财富管理销售助手：AI 生成 RM 会谈摘要和产品讨论提纲。控制测试应检查 suitability gate、approved claim、conflict disclosure、客户脆弱状态、licensed handoff 和输出版本留痕。
AML case copilot：AI 帮分析师总结交易模式和 suspicious narrative。监控不应停在 summarization quality，而要覆盖遗漏高风险 typology、引用不可用数据、使用未批准外部工具、分析师 override 模式和 SAR 质量抽样。
零售营销生成平台：AI 生成分群话术和优惠解释。控制目标包括 consent/purpose enforcement、禁止歧视性分群、价格或费用 claim 准确性、A/B 实验边界、投诉反馈进入 corrective action。
反模式
- 只在上线前做一次模型验证，生产后只看 uptime。
- 把控制证据放在截图、PPT 或人工周报里，无法按事件重建。
- 所有 use case 共用同一套泛化指标，忽略客户影响和业务动作差异。
- 把 human review 视为万能补偿控制，却不监控容量、校准和独立性。
- 只统计 exception 数量，不看过期、重复续期、残余风险和补偿控制失效。
- 将 vendor 输出当作黑盒信任，不捕获内部 prompt、RAG、tool 和 policy decision。
- dashboard 只展示红黄绿状态，没有 owner、SLA、动作和关闭证据。
最终心智模型
AI continuous control monitoring 是“把控制目标变成持续运行的证据系统”。它不是仪表盘项目，也不是审计抽样自动化；它是一套连接风险、控制、运行事件、例外、修复和管理评审的 control assurance architecture。
判断一套架构是否成熟，可以看这个场景：当某个 AI workflow 明天因为模型、prompt、RAG、工具、客户群或人工队列变化而伤害客户时，系统能否在可接受时间内发现、证明、阻断、修复并复盘。如果答案依赖人工搜索日志和会议解释，说明控制还没有真正产品化。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。