AI Exception / Risk Acceptance / Waiver Architecture Playbook

适用对象: 高级 AI Product Manager / AI BA / Product Architect / Enterprise Architect / Risk Partner / Model Risk Lead / Operational Risk Lead / Compliance / Privacy / Security / Third-Party Risk / Internal Audit / Board reporting owner。 目的: 训练金融零售 AI 团队如何管理政策例外、临时 waiver、剩余风险接受、补偿控制、到期续期、证据留存、升级路径和硬停止条件。重点不是基础 BA, 而是把 AI governance 做成可运行、可监控、可审计、可向高管和审计委员会说明的 exception control system。 核心观点: Risk appetite 定义组织的 AI 风险边界; exception / waiver architecture 管理的是在风险偏好和标准控制已经定义之后, 某个 use case 对标准控制的限时、限域、留证偏离。例外不能成为永久 shadow policy。

重要说明: 本文是学习、作品集和治理设计材料, 不是法律、审计、监管、模型验证或合规意见。正式项目必须由 business owner、legal、compliance、model risk、operational risk、security、privacy、third-party risk、technology、internal audit 和管理层结合机构、司法辖区、监管关系和内部政策确认。

---

1. Executive Framing

1.1 One-sentence positioning

AI Exception / Risk Acceptance / Waiver Architecture 是一套把“暂时不能满足标准 AI 控制”转成有业务理由、有风险归属、有补偿控制、有到期、有证据、有升级、有硬停止条件的治理机制。

An AI waiver is not permission to ignore controls.
It is a time-boxed, scope-bound, evidence-backed acceptance of residual risk.

1.2 Distinction from risk appetite

高级表达: Risk appetite is the baseline. Waiver management is the controlled deviation from that baseline. If the same waiver keeps renewing, the organization has unresolved control debt or an outdated policy baseline.

1.3 Why AI exception handling is special

AI 行为由 model route、prompt、RAG corpus、source registry、eval rubric、tool permissions、agent autonomy、human review capacity、privacy logging、security gateway、vendor terms、customer disclosure 和 remediation process 共同决定。

GenAI / agentic AI 的例外不能只归入模型风险。它需要同时组合 model risk、operational risk、consumer compliance、privacy、security、third-party、technology resilience、customer harm 和 audit evidence。

1.4 Executive question set

---

2. Source Anchors

以下来源作为治理语言和证据结构锚点。本文把它们转成 AI 产品、架构、BA 和金融零售治理实践。访问日期按 2026-06-30 记录。

2.1 Current nuance

• SR 26-2 替代 SR 11-7 和 SR 21-8, 因此 2026 年后的模型风险讨论不能只停留在旧 letter。
• SR 26-2 把模型风险管理推向更明确的 risk-based tailoring、intended use、model inventory、monitoring、validation、effective challenge 和 governance。
• 对 GenAI / agentic AI, exception handling 必须同时说明 operational risk、consumer compliance、privacy、security、third-party、tool autonomy 和 evidence gaps。
• 任何长期续期的例外都要升级为 policy review、control investment 或 formal residual risk decision。

---

3. Exception Taxonomy

3.1 Baseline structure

Risk appetite
-> risk tier
-> standard control baseline
-> control gap
-> exception request

模糊说法: We need an exception for the AI assistant.

合格说法:

We request a 45-day exception from CTRL-EVAL-HIGH-003,
which requires full regression coverage for complaint and fee-dispute slices,
for a 5% employee-only pilot of the retail service copilot.
The exception excludes customer auto-send and all write-enabled tools.

3.2 Taxonomy by control domain

3.3 Taxonomy by AI autonomy

3.4 Non-waivable conditions

Do not approve when the request involves prohibited use, no accountable residual risk owner, no enforceable scope, no stop capability, no evidence path, known active harm without containment, unapproved sensitive-data exposure, or hidden final-decision automation.

---

4. Waiver Lifecycle

4.1 Lifecycle map

Exception trigger
-> intake
-> control gap classification
-> residual risk assessment
-> compensating control design
-> approval routing
-> restricted operation
-> KRI monitoring
-> evidence capture
-> expiry review
-> close / renew / remediate / policy update / stop

4.2 Trigger examples

4.3 Intake fields

4.4 Classification and approval

Authority principle: The person who wants the value should not be the only person accepting the residual risk.

4.5 Restricted operation

4.6 Expiry outcomes

No silent extension.

---

5. Risk Acceptance Memo

5.1 Memo purpose

The memo proves what control is missing or weakened, why the business still wants limited operation, what risk remains, who accepts it, what controls compensate, what evidence will be reviewed, when the acceptance ends and what triggers immediate stop.

5.2 Memo template

5.3 Memo quality bar

Weak memo: We need a temporary exception because the business needs to launch quickly.

Strong memo: We request a 30-day exception from a specific citation control for a 5% low-risk FAQ pilot. The waiver excludes high-risk intents and write tools, uses daily sample review and hard stop triggers, and expires before the next risk committee review.

---

6. Compensating Controls

6.1 Control design principles

Compensating controls must be tied to the specific gap, stronger where uncertainty is higher, feasible for operations, instrumented with evidence, time-boxed, reviewed at expiry and mapped to an owner.

6.2 Control catalog

6.3 Compensating controls for agentic AI

6.4 Control evidence

---

7. Expiry and Renewal

7.1 Expiry rule

Every waiver needs an expiry date, review owner, forum, renewal criteria, closure criteria, stop criteria and evidence bundle. No expiry means no waiver approval.

7.2 Recommended maximums

7.3 Renewal criteria

Renewal should require: business rationale still valid; no hard stop triggered; KRI stable; compensating controls operated as designed; remediation progress; scope not expanded; residual risk owner re-accepts risk; new expiry is shorter or tied to a concrete delivery date.

7.4 Repeat renewal escalation

7.5 Shadow policy test

Ask whether the same exception is active for more than one review cycle, teams design around the waiver as normal practice, the reason recurs across products, management stops discussing exit, controls remain unfunded or audit would see a gap between written policy and operations.

---

8. No-Go Criteria and Hard Stops

8.1 No-go criteria

8.2 Hard stop examples

8.3 Stop rule runbook

Trigger detected
-> classify severity
-> pause or cap feature by exception_id
-> disable affected tool/model/channel if needed
-> notify product, risk, operations, compliance, security/privacy as relevant
-> preserve traces and evidence
-> review affected customers/cases
-> decide rollback, remediation, customer correction or incident escalation
-> update waiver status

8.4 Stop authority

---

9. Dashboards and KRIs

9.1 Exception dashboard

9.2 KRI catalog

9.3 Board and audit committee view

9.4 Example dashboard row

---

10. RACI

10.1 Core roles

10.2 RACI shorthand

10.3 Forum design

---

11. Financial Retail Examples

11.1 Credit policy copilot

Scenario: AI drafts credit policy memos for underwriters; standard control requires full fair-lending regression before expanded pilot; a small-business segment is incomplete.

No-go: AI automatically generates final adverse action reasons under incomplete validation.

11.2 Wealth guidance assistant

Scenario: AI supports advisor preparation and client education; advice boundary classifier has not completed edge-case testing for retirement product prompts.

No-go: customer-facing robo-advice with incomplete advice boundary.

11.3 Customer service AI FAQ

Scenario: Customer-facing low-risk FAQ pilot has incomplete PDF table citation automation.

11.4 AML investigation copilot

Scenario: AI summarizes transaction patterns and drafts narrative; tool audit log lacks one required attribute for analyst override reason.

No-go: AI submits SAR or decides no-SAR with incomplete evidence controls.

11.5 Fraud operations agent

Scenario: Agent can recommend fraud queue actions; write-enabled account restriction tool is technically available but reversal process is not tested.

11.6 Third-party model route

Scenario: Vendor model performs better for Spanish-language support; updated vendor evidence for data retention is due but not yet received.

No-go: PII or restricted data sent to unapproved or unverified route.

---

12. Templates

12.1 Exception intake form

12.2 Residual risk acceptance table

12.3 Compensating control matrix

12.4 Waiver approval record

12.5 Board/audit committee summary

12.6 Expiry review decision

---

13. Architecture Pattern

13.1 Exception control plane

13.2 Runtime tagging

ai.exception_id, ai.exception_scope, ai.risk_tier, ai.control_gap_id, ai.residual_risk_owner, ai.expiry_date, ai.model_version, ai.prompt_version, ai.rag.source_registry_version, ai.tool.policy_version, ai.human_review_required, ai.hard_stop_profile

13.3 Enforcement flow

request enters AI gateway
-> check exception_id active
-> check current date before expiry
-> check user/channel/data/tool/model in approved scope
-> apply exception-specific policy bundle
-> emit trace tags
-> route allowed request
-> deny or route to human if outside scope

---

14. 30-Day Lab

Success criteria: no open-ended waiver; no unowned residual risk; no missing hard stop; no unenforceable scope; no evidence gap; clear explanation of why the exception is not shadow policy.

---

15. Interview Answers

15.1 30-second answer

AI risk appetite defines the baseline; waiver management governs controlled deviations from that baseline. For every AI exception, I require a specific control gap, narrow scope, residual risk owner, compensating controls, expiry date, hard stop conditions, evidence plan and renewal criteria. I also track aging and repeat renewals, because recurring waivers can become shadow policy. For GenAI and agentic AI, I do not treat this as only model risk; I combine model risk, operational risk, consumer compliance, privacy, security and third-party controls.

15.2 2-minute answer

I would manage AI exceptions as a formal risk acceptance lifecycle. First, I start from the approved risk appetite and control catalog. If a use case cannot satisfy a standard control, the team must identify the exact policy or control being waived, not just say “we need an exception.” Then I classify the exception by customer impact, automation level, data sensitivity, regulatory relevance, reversibility and control gap severity.

Second, I write a residual risk memo. It explains the business reason, alternatives considered, limited scope, what harm could occur, who accepts the residual risk and for how long. The waiver must include compensating controls, such as traffic caps, employee-only scope, source allowlists, human review, QA sampling, no write tools, extra monitoring or fallback routing.

Third, I make the waiver operational. The exception registry connects to feature flags, policy engine, model gateway, tool gateway, telemetry and evidence binder. Every request under the waiver carries an exception id, scope, risk tier, control gap and expiry. Hard stops are pre-approved: for example, wrong fee commitment, missed complaint escalation, PII routed to an unapproved model or tool write without approval immediately pauses the feature.

Finally, I manage expiry. A waiver can close, renew with new evidence, remediate, convert to a formal policy update or stop. It cannot silently continue. Repeat renewal, expired active exceptions and recurring control gaps are escalated to management and, when material, board or audit committee reporting. That prevents exceptions from becoming permanent shadow policy.

15.3 CRO version

I would focus on residual risk accountability and aggregate exposure. The CRO should see which AI controls are being waived, which high/critical use cases are affected, who accepted residual risk, what compensating controls are operating, which KRIs are near breach, which exceptions are aging and whether repeat waivers indicate policy drift or underfunded controls. I would also distinguish waivable control gaps from prohibited uses. A waiver cannot be used to approve an unauthorized final decision, unapproved sensitive-data route or uncontrollable agent execution.

15.4 Chief Product Officer version

I would frame waivers as a way to learn safely, not as a way to bypass governance. Product teams can run limited pilots when the control gap is specific, the scope is narrow and the residual risk is accepted. But the waiver must shape the roadmap: if multiple teams keep requesting the same exception, that becomes a platform investment or policy decision. The product leader should track exception debt the same way they track technical debt, because unmanaged waivers slow down future releases and create audit risk.

15.5 Chief Architect version

I would implement exception management as a control plane. The exception registry should feed policy engine, model gateway, tool gateway, release orchestrator, observability and evidence binder. Runtime checks should enforce expiry, user/channel/data/tool/model scope and hard exclusions. Every trace should carry exception id, risk tier, control gap, model/prompt/source/tool versions and review status. The architecture must support artifact-level rollback, not just code rollback, because AI behavior can change through prompt, RAG, model route, tool schema or vendor configuration.

15.6 Internal audit version

I would ask whether management can reconstruct the decision and prove the waiver operated within approved boundaries. Evidence should include the policy baseline, control gap, approval roles, residual risk memo, compensating control tests, release configuration, trace samples, KRI history, hard stop drill and expiry decision. I would pay special attention to expired active exceptions, repeat renewals and cases where the same control is waived across multiple products, because those indicate shadow policy risk.

15.7 Board/audit committee version

At board or audit committee level, I would not show every low-risk waiver. I would show material exposure: active high/critical exceptions, customer-facing exceptions, exceptions linked to incidents, expired active items, repeat renewals, control-gap concentration and remediation progress. The key message is whether AI operations remain within approved risk appetite or whether exceptions are becoming the real operating model.

---

16. Common Failure Modes

---

17. Final Memory Card

Most important sentence:

A mature AI organization does not pretend exceptions will disappear; it designs them as controlled, temporary, evidenced residual-risk decisions and escalates them before they become shadow policy.