AI Governance Exceptions: How to Approve a Use Case With Open Testing Gaps Without Creating Permanent Waivers

TL;DR

• SR 26-2 and OCC Bulletin 2026-13 exclude generative and agentic AI from formal model risk guidance scope — but examiners still evaluate these systems for unsafe or unsound practices.
• The CSBS AI Supervisory Framework (September 2026) gives state examiners a tiered risk worksheet that maps directly to how much scrutiny your exception documentation will get.
• An AI governance exception needs five elements: gap description, compensating controls, named owner, hard expiry date, and appropriate escalation path. Without them, it’s an unapproved deployment with paperwork.
• Exception registers age badly. A 60-day exception that reaches 180 days without closure evidence is a permanent waiver. Those are examiner findings.

Your AI governance committee met last quarter. A business unit wanted to deploy a customer-facing document summarization tool — the kind that answers questions about account terms, loan conditions, and fee disclosures. Risk review was mostly complete. The use case was tiered as high-risk given direct customer interaction. Two things were still open: the red-team adversarial testing and a bias review on the training corpus. The committee approved deployment with a 60-day condition to close both gaps.

It’s now been 90 days. The red team got rescheduled. The bias review is “in progress.” The tool has been live for three months.

Congratulations. You have a permanent waiver masquerading as an exception.

This is the operational reality at a significant number of financial institutions right now. The approval process works. The exception tracking doesn’t. And as examiners — both state and federal — get more sophisticated about AI governance, the gap between “we approved this with conditions” and “here’s documented evidence those conditions were closed” is exactly what they’re looking for.

The Regulatory Context That Makes This Harder

The April 2026 revision to interagency model risk guidance didn’t solve the AI exception problem — it created a larger version of it.

SR 26-2 and OCC Bulletin 2026-13 superseded SR 11-7. The new guidance strengthened validation requirements, enhanced vendor model obligations, and applied model risk expectations to a broader set of systems. But it also drew a line: generative AI and agentic AI are explicitly outside the guidance’s scope, described as “novel and rapidly evolving” technologies where the agencies weren’t ready to prescribe specific requirements.

As covered in detail here, that exclusion doesn’t mean examiners ignore these systems — it means the governance framework is yours to build. The agencies said they can still criticize AI governance as unsafe or unsound practice even where the formal guidance doesn’t reach. Your exception process for generative AI use cases lives entirely in your own policy documents. If those documents are thin on exception mechanics, your examiner is going to notice.

The CSBS AI Supervisory Framework, released September 16, 2026, adds state-level structure. It’s voluntary — no new legal obligations — but the Conference of State Bank Supervisors supervises 79% of FDIC-insured banks, and each state regulator can incorporate the framework into its exam program. The five-document package includes a 28-page work program for examiners and a risk-tiering worksheet for individual AI uses. That worksheet is how examiners will classify your use cases — and your exceptions.

Exception vs. Approval vs. Waiver: The Distinction That Matters

These three things are not the same. Treating them interchangeably is how exceptions become permanent liabilities.

A standard approval means the use case passed governance review with all required validation and testing complete. Deployment proceeds under normal monitoring.

An exception means the use case was approved despite incomplete validation, with documented conditions, a named owner, a hard expiry date, and escalation triggers if conditions aren’t met. Deployment is conditional and time-bounded.

A waiver means the standard was set aside, often permanently, without enforceable closure conditions. A waiver may be legitimate — you might formally decide that a particular test is inapplicable to a low-risk use case and document that decision permanently. The problem arises when an exception becomes a waiver by drift: the 60-day close date passes, nobody escalates, and the open items are still open six months later.

The UK PRA’s model risk management principles are instructive here even though they’re not US supervisory text: exceptions should be temporary, should be subject to compensating controls, and should be reported to senior management. An exception that outlives its stated term without documented extension or escalation is, functionally, a waiver — and examiners treat it as one.

The Five Elements Every AI Exception Needs

The mechanics of a defensible AI governance exception are not complicated. What’s complicated is enforcing them consistently across a use-case portfolio that’s growing faster than your governance committee can meet.

1. A specific gap description. Not “validation pending” — that tells you nothing about what’s actually missing. The exception document should name the specific test or review that’s incomplete (adversarial red team, bias audit, explainability documentation), why it’s not done, and what “done” looks like.

2. Compensating controls. What is in place to reduce the risk while the gap remains open? Increased human review? Scope restriction to lower-risk queries? Heightened monitoring? Compensating controls don’t eliminate the gap — they reduce its consequence until the gap is closed.

3. A named owner. Not a team, not a committee, not a function — a named individual responsible for closing the gap by the stated date. Accountability without a name is not accountability.

4. A hard expiry date with automatic escalation. Sixty days means the gap is either closed or the exception is escalated to a higher governance level by day 61. Automatic escalation — built into your workflow, not dependent on someone remembering — is what separates a real exception process from a document that sits in a folder.

5. Closure documentation. When the gap is closed, what does “closed” mean and how is it evidenced? The exception doesn’t end when someone says the test is done — it ends when the test results are documented, reviewed, and the exception record is formally closed.

Your AI use case inventory and model inventory are the systems that should track this. An exception that lives only in a meeting notes email is not an exception process.

How the CSBS Tiers Change the Stakes

The CSBS AI Supervisory Framework doesn’t create new exception requirements — but its risk tiers directly affect how much documentation scrutiny your exceptions will face.

The framework’s Tier 2 covers use cases with consumer-facing or decision-support roles, moderate data sensitivity, or exception-based human oversight. Tier 3 covers use cases with direct consumer outcomes, sensitive personal data, limited human review, or material potential harm from errors or outages.

A document summarization tool that answers questions about loan terms sits in Tier 2 at minimum, and likely Tier 3 given direct customer interaction. If your exception is for a Tier 3 use case — and you’re in a state that has adopted the CSBS framework — your examiner has a worksheet telling them exactly what to look for in your governance documentation.

The CSBS framework is voluntary, and state adoption is uneven. But the practical direction is clear: state examiners are getting structured tools for AI oversight at precisely the moment when federal guidance has stepped back from generative and agentic AI. If your state program incorporates this framework, your AI exception documentation will be evaluated against a real rubric, not a vague expectation.

Four Ways Exceptions Become Permanent

The exception register is where governance intentions go to die. These are the specific failure patterns to watch for.

Scheduling drift. The red team was scheduled for day 45 of the exception period. The team that was supposed to run it was pulled onto a higher-priority project. Nobody rescheduled. Day 60 arrives. The exception auto-extends by convention rather than deliberate decision.

Scope creep. The exception was granted for a limited pilot with 200 users. The pilot went well. The tool was expanded to 20,000 users. The original exception documentation was never updated to reflect the scope change. The gap is now 100x larger but the exception record still says “pilot.”

Ownership turnover. The named owner left the company. Nobody was reassigned. The exception lives in the register with a closed owner field and no active accountability.

Closure without evidence. Someone marked the exception closed. The bias audit was “completed” according to the owner. But the results aren’t documented, the methodology isn’t described, and there’s no artifact that an examiner can review. Closed in the system, undefended in an exam.

What Examiners Are Finding

Examiner questions about AI governance have shifted from awareness (“do you have an AI inventory?”) to specificity (“show me your exception tracking for high-risk AI use cases deployed in the last 12 months”).

The two most common model risk findings in the current exam cycle: AI systems in production that aren’t in the model risk inventory, and high-risk AI deployed under informal approval-with-conditions arrangements that lack enforceable closure mechanics. The second finding is your exception problem.

With the CSBS framework now in examiners’ hands for state-chartered institutions, the documentation bar is rising. An exception register that consists of a spreadsheet with open and closed dates, but no gap descriptions, no compensating controls, and no closure evidence, is unlikely to survive a detailed review.

So What?

Your AI governance committee doesn’t have an approval problem. It has a lifecycle problem.

The approval vote is the easy part. What happens on day 61 of a 60-day exception? Who gets the escalation? What do they do with it? When the closure evidence comes in, who verifies it and formally closes the exception record?

If those questions don’t have clear procedural answers that are enforced by your workflow rather than dependent on individual follow-through, your exceptions will age into permanent waivers. And the next time an examiner asks for your AI exception register — which is now a routine question — what you hand them tells them more about your governance program than any policy document.

The AI Risk Assessment Template & Guide includes exception tracking templates, risk-tier criteria aligned with current guidance, and a framework for documenting compensating controls — built for teams managing AI governance programs that are growing faster than their processes were designed to handle.