AI Exception / Risk Acceptance：例外治理架构
AI Exception Architecture 是把“暂时不能满足标准控制”转成有边界、有补偿、有到期、有证据、有升级、有硬停止条件的风险接受系统。
AI Exception / Risk Acceptance / Waiver Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_EXCEPTION_RISK_ACCEPTANCE_WAIVER_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织例外背景、风险测量、补偿控制和持续治理 |
| 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 | 作为金融机构模型风险管理新锚点; SR 26-2 于 2026-04-17 替代 SR 11-7 和 SR 21-8 |
| FFIEC IT Examination Handbook Management booklet | https://ithandbook.ffiec.gov/it-booklets/management.aspx | 用 IT governance、risk management、third-party、change、audit 和 board reporting 视角组织管理证据 |
核心导读： AI Exception Architecture 是把“暂时不能满足标准控制”转成有边界、有补偿、有到期、有证据、有升级、有硬停止条件的风险接受系统。
核心导读
AI exception / waiver architecture 处理的是标准控制无法完全满足时，组织如何在可见、限时、限域、可证据化的条件下接受残余风险。它不是绕过治理的捷径，也不是上线审批的“特批按钮”。一份有效 waiver 必须说明偏离了哪条控制，为什么不能立即满足，风险暴露在哪里，补偿控制是什么，到期如何退出，谁有权接受残余风险。
金融零售 AI 的例外管理尤其重要，因为 prompt、RAG、模型、工具、供应商、人审容量和数据路径都可能在业务压力下被临时放宽。没有架构化例外机制，临时偏离会变成永久控制缺口。
问题定义
AI 项目常见的例外场景包括：
- 新客服助手已通过大部分测试，但某些低频政策 intent 的 eval coverage 不足。
- 第三方模型供应商无法提供足够细粒度日志，内部证据链不完整。
- 人工复核容量不足，团队希望在低金额争议上临时降低复核比例。
- RAG 文档有效期元数据不完整，只能先用人工抽样补偿。
- 新工具权限尚未接入统一 policy engine，业务希望先在小范围试运行。
- 数据 residency 目标架构未完成，某区域只能用降级服务或本地模板。
这些问题不能简单归为 go / no-go。架构上需要区分 prohibited use、不可接受风险、可补偿风险和可接受低风险偏离。Prohibited use 不应被 waiver 覆盖；可补偿风险必须有 scope、duration、controls 和 monitoring。
核心原理/方法
首先区分 risk appetite、exception 和 risk acceptance：
| 概念 | 含义 |
|---|---|
| Risk appetite | 组织预先定义愿意承受的风险边界和禁止边界 |
| Exception | 对既定政策、控制、标准或 release gate 的具体偏离 |
| Risk acceptance | 授权角色在已知残余风险和补偿控制下接受该偏离 |
| Waiver | 对 exception 的正式记录、审批、范围、有效期和证据载体 |
一个 AI waiver 对象至少应包含：
| 字段 | 说明 |
|---|---|
| Control gap | 偏离的政策、控制、标准、测试或证据要求 |
| Business rationale | 为什么需要现在偏离，而不是推迟、降级或缩小范围 |
| Scope boundary | use case、渠道、客户群、地区、产品、数据、工具、流量、时间 |
| Residual risk | 客户、合规、模型、运营、隐私、安全、第三方和声誉风险 |
| Compensating controls | 临时补偿措施，必须可执行、可测试、可留证 |
| Expiry and exit | 到期日、退出条件、硬停止条件、续期限制 |
| Approval authority | 谁有权接受该级别风险，是否需要独立挑战 |
| Evidence contract | 生产中如何标记、监控和证明 waiver 范围内行为 |
系统/架构模型
Policy / Control Catalog
-> Exception Request Intake
-> Risk Tiering & Prohibited Use Check
-> Residual Risk Assessment
-> Compensating Control Design
-> Approval Matrix & Independent Challenge
-> Runtime Scope Enforcement
-> Waiver Evidence Ledger
-> Aging / Renewal / Breach Monitoring
-> Closure / CAPA / Management Reporting
关键组件：
| 组件 | 职责 |
|---|---|
| Policy catalog | 明确哪些控制可例外、哪些不可例外、哪些需要高级审批 |
| Exception intake | 结构化收集控制缺口、业务理由、范围、风险和请求期限 |
| Risk tiering engine | 按客户影响、资金动作、监管义务、数据敏感度和自动化程度分级 |
| Approval matrix | 将 residual risk 映射到业务、风险、合规、模型、隐私、安全和技术审批 |
| Runtime enforcement | 用 feature flag、policy engine、tool gateway 和 routing rule 强制执行 scope |
| Evidence ledger | 给每个受 waiver 影响事件打上 waiver id、控制缺口和补偿控制状态 |
| Aging monitor | 监控过期、重复续期、scope breach、补偿控制失败和风险升级 |
架构重点是：waiver 不应只存在于文档审批系统中，而要影响生产路径。系统必须知道当前某个 session、tool call 或输出是否在 exception 范围内，并能够阻断越界行为。
关键机制与取舍
| 机制 | 取舍 |
|---|---|
| 速度 vs 控制完整性 | 有时业务需要受限试运行，但速度只能通过缩小 scope 和增强补偿控制获得，不能通过删除证据获得 |
| 例外 vs 降级 | 如果标准控制缺失，高影响功能可选择 degraded mode，而不是带风险上线完整能力 |
| 补偿控制 vs 原控制 | 补偿控制应降低具体风险，但通常不能永久替代目标控制 |
| 续期 vs 硬停止 | 续期应触发更高层级复核；重复续期说明目标架构或治理优先级有问题 |
| 人工审批 vs runtime enforcement | 人工审批只能接受风险，不能确保执行范围；scope enforcement 必须技术化 |
| 局部 waiver vs enterprise pattern | 多个团队反复申请同类例外时，应升级为平台能力缺口，而不是继续个案处理 |
常见 waiver 不应批准的情况包括：触碰明确禁止用途、无法界定客户影响、没有有效补偿控制、没有证据字段、没有到期日、审批人没有风险权限、异常会破坏法律保全或记录义务。
证据与控制
Waiver 的证据要覆盖“批准前、运行中、关闭后”三段：
| 阶段 | 证据 |
|---|---|
| 批准前 | 控制缺口、风险评估、替代方案分析、补偿控制设计、审批和独立挑战记录 |
| 运行中 | waiver id、scope match、事件量、客户影响、补偿控制结果、越界拦截、异常 aging |
| 关闭后 | 目标控制上线证明、残余风险复核、生产样本验证、到期关闭、重复问题进入 CAPA |
关键控制指标包括：active waiver count、expired waiver、repeat renewal、scope breach、compensating control failure、waiver-covered customer impact、aging by risk tier、waiver-to-CAPA conversion。
每个 production event 如果受 waiver 影响，应能回答：它为什么被允许，在什么边界内被允许，哪些补偿控制运行过，是否越界，谁接受了残余风险，到期后会如何处理。
金融零售/AI产品场景
客服 RAG 试运行：某些政策文档缺少有效期元数据。可以批准低风险 intent 的有限流量 waiver，同时要求回答必须引用 source、每日抽样、禁止费用承诺、客户可见输出进入人审，并设置 30 天硬到期。
支付争议自动分流：模型未覆盖新商户类别。可将该类别排除在自动化之外，而不是批准全量 waiver；对低金额、低风险 case 可使用人工抽样补偿。
财富销售助手：如果 suitability gate 未与某产品规则集成，不应批准个性化推荐 waiver。可降级为 education-only 模式，禁止 next best action 和客户定制建议。
供应商日志缺口：第三方模型无法提供 token-level trace。可在低风险内部摘要场景临时接受，但客户可见、高影响或监管记录场景必须要求内部 gateway 捕获 prompt、output、policy decision 和 hash。
反模式
- 把 waiver 当作上线清单最后的手工签字，生产系统不知道 waiver 存在。
- 例外没有客户群、渠道、产品、地区、工具或流量边界。
- 补偿控制写成“加强人工关注”，没有执行规则、样本量、owner 和证据。
- 到期日可无限续期，续期不提高审批层级。
- 所有风险都由项目 owner 接受，缺少独立挑战和风险权限匹配。
- 控制缺口重复出现，却没有进入平台 backlog 或 corrective action。
- exception dashboard 只看数量，不看 aging、越界、客户影响和补偿控制失败。
最终心智模型
AI exception architecture 的本质是“把偏离标准控制的风险产品化管理”。它允许组织在明确边界内做受控试运行或临时补偿，但不允许风险在文档里被接受、在生产中失控。
判断一份 waiver 是否合格，可以问：如果明天审计、监管或客户投诉要求复盘，系统能否证明哪些事件在 waiver 范围内、哪些补偿控制运行过、何时到期、谁接受风险、如何退出。如果不能，所谓 risk acceptance 只是未记录的风险转移。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。