Feature AI Risk
72% of Banks Can't Shut Down a Malfunctioning AI Model. Examiners Are About to Find That Out.
A June 2026 survey found 72% of banks are unprepared to shut down a malfunctioning AI model or report an AI failure to regulators—the two most basic controls in any AI incident-response playbook. OCC and Fed examiners have made AI a permanent standing topic in every routine bank examination. Here's what kill switch documentation, vendor disentanglement testing, and data boundary enforcement look like when an examiner walks in.
Table of Contents
TL;DR
- A June 2026 survey found 72% of U.S. banks are unprepared to shut down a malfunctioning AI model or report an AI failure to regulators—the two most basic controls in any AI incident-response playbook
- OCC and Federal Reserve examiners have made AI governance a standing topic in every routine bank examination; no exam now proceeds without some discussion of AI governance, kill switches, vendor risk, and data boundaries
- SR 26-2 (April 2026) explicitly excluded generative AI and agentic AI from its scope—but examiners aren’t waiting for the formal guidance to ask about GenAI governance
- The specific exam questions banks are getting: can you shut down a malfunctioning model? Can you exit your AI vendor in 30 days? Are your AI tools accessing data they shouldn’t be?
The Number You Don’t Want Your Examiner to Know
In June 2026, American Banker reported results of a survey showing that 72% of U.S. banks cannot confirm they have the ability to shut down a malfunctioning AI model or report an AI failure to regulators. That’s not an abstract gap. It’s the two most fundamental controls in any AI incident-response playbook—and nearly three in four institutions either don’t have them or aren’t confident they do.
The timing is notable. The same month that survey published, examiners from the Office of the Comptroller of the Currency, Federal Reserve, and FDIC made AI a permanent standing topic in every routine bank examination. Not a special-focus exam. Not a technology exam. Every exam. Every institution. Every cycle.
If your AI governance documentation isn’t ready for that conversation, your examiner is going to find out the hard way—and you’ll have the findings to prove it.
What Changed in June 2026
The regulatory framing has been building for a while. The April 2026 interagency model risk guidance (SR 26-2) updated the framework that had governed model risk since 2011, and it explicitly applied MRM principles to AI and LLM systems used in credit, fraud, AML, capital, and consumer-facing decisions. It also explicitly excluded generative AI and agentic AI from scope, with a request for information planned to address those systems separately.
But what happened in June 2026 is different in kind from what a guidance document says. Examiners at OCC and Federal Reserve were not waiting for the AI-specific guidance before asking AI questions. Regulatory reporting and interviews with bank compliance officers confirmed that AI governance, kill switches, and vendor risk became standing exam topics across all routine bank examinations—not just at the largest institutions, but across the board.
That means a $2 billion community bank getting its next CRA or BSA/AML exam is going to field AI questions it may never have prepared for. The examiner isn’t bringing a formal AI checklist derived from published guidance—because that guidance doesn’t fully exist yet. They’re asking about governance, documentation, and risk management under existing frameworks. Which is worse, in some ways, because the questions are harder to anticipate.
The SR 26-2 Paradox: A Governance Gap the Examiners Are Filling Themselves
SR 26-2 created an interesting problem. The guidance explicitly covers AI models used in credit scoring, fraud detection, AML/BSA monitoring, and capital calculations. It’s clear that validated, documented MRM treatment is required for those systems. But the same document explicitly excludes generative AI and agentic AI systems from its scope—precisely the tools banks have been deploying most aggressively over the past two years.
This means a bank’s ChatGPT Enterprise deployment used to assist with SAR narrative drafting, a Copilot integration in the credit underwriting workflow, or an agentic AI tool handling customer service inquiries is in a formal governance gray zone: SR 26-2 doesn’t require validation documentation for it, but examiners are asking about it anyway.
As covered in our analysis of the GenAI model risk gap, the agencies have been explicit that SR 26-2’s exclusion doesn’t mean GenAI is ungoverned—banks are expected to apply appropriate risk management principles consistent with the risk of each system. That’s a principle-based obligation, not a prescriptive one. And principle-based obligations are evaluated by examiners making judgment calls about whether your governance is proportionate.
The practical result: your GenAI governance is going to be evaluated at your next exam, but there’s no published standard specifying exactly what’s required. The closest thing to a standard right now is what examiners are actually asking about—which makes exam prep a matter of reverse-engineering the question list.
The Kill Switch Question
The first thing examiners want to know: can you shut an AI system down?
Not just “do you have the theoretical ability to turn it off.” The question is whether you have a documented, governance-approved process for triggering the shutdown of a specific AI model when it fails—and whether the people responsible for that action know it’s their responsibility.
A functional AI kill switch has three components:
1. A trigger threshold. What condition causes the kill switch to be invoked? Options include: sustained output anomaly (model producing results outside expected range), customer complaint spike that correlates with AI output, compliance team escalation based on model behavior review, or discovery of data boundary violation. Without a documented threshold, the kill switch doesn’t get triggered because no one knows when to pull it.
2. An authorization chain. Who can invoke the shutdown? Typically this is a combination of model owner escalating to CRO or CTO, with the AI governance committee or a designated senior decision-maker having final authority. Banks with governance-level AI risk reporting—documented in a formal AI decision log—can demonstrate this chain clearly. Banks without it cannot.
3. A downstream substitution plan. What happens to the process the AI model was handling when the model goes offline? If AI is augmenting fraud detection, what’s the manual fallback? If it’s handling first-pass AML alerts, how does the team absorb that volume? A kill switch without a substitution plan creates an operational gap the moment it’s invoked.
The 72% of banks that lack this capability typically don’t have a clean answer to any of these three questions.
The Data Boundary Question
The second area of examiner focus is data boundary enforcement—whether the AI tools deployed at your institution are accessing or ingesting data they were never authorized to use.
This question is particularly acute for enterprise AI tools (Copilot, Grammarly Business, enterprise ChatGPT) that integrate deeply with email, document management, and workflow systems. A bank employee using Copilot to draft credit analysis summaries may inadvertently feed MNPI, customer PII, or confidential counterparty information into a model that wasn’t authorized to process any of it.
Examiners are asking banks to demonstrate:
- What data inputs are authorized for each AI tool in production?
- What technical controls prevent employees or automated workflows from feeding unauthorized data into AI systems?
- How is that authorization documented, and who approved the boundary parameters?
This intersects directly with GLBA Safeguards Rule obligations around customer information protection and service provider oversight. If an AI vendor is receiving customer data that the bank never formally authorized for transmission to that vendor, you have a Safeguards Rule gap alongside the governance gap. Shadow AI deployments make this problem significantly worse because data boundaries are nearly impossible to enforce for tools the institution didn’t know it was running.
The Vendor Disentanglement Question
The third area is vendor risk—specifically whether you could realistically separate from your AI vendor quickly if you needed to.
Examiners are pressing banks on this because the AI vendor stack has created third and fourth-party dependencies that existing TPRM frameworks weren’t designed to handle. A bank using an enterprise AI tool powered by Azure OpenAI is effectively dependent not just on its direct software vendor but on Microsoft and on OpenAI’s underlying model infrastructure. If OpenAI experiences a security incident, a service failure, or becomes subject to a sanctions designation, the bank’s exposure runs through multiple layers of vendor relationships it may not have mapped.
The specific questions examiners are asking include:
| Examiner Question | What They’re Looking For |
|---|---|
| Can you exit this AI vendor in 30 days if needed? | Documented exit provisions in vendor contract; identified alternatives |
| Who are your AI vendor’s sub-processors and foundational model providers? | Fourth-party mapping completed; sub-processor disclosure in contract |
| Have you tested your ability to migrate this AI function to an alternative? | Evidence of tabletop or actual migration exercise |
| What happens to your [credit/fraud/AML] process if this vendor goes offline? | Manual fallback or alternative vendor documented |
Most bank vendor contracts with AI providers were negotiated before these questions were on the examiner’s list. Enterprise agreements with Microsoft, Google, and Anthropic often include minimal sub-processor disclosure, no meaningful exit provision beyond standard SLA termination, and no data portability commitment that would enable migration. Renegotiating those contracts is hard. But the documentation gap is immediate: if you haven’t mapped your fourth-party AI dependencies, you can’t answer the examiner’s question.
Building Exam-Ready AI Governance Documentation
Based on what examiners are actually asking in 2026 routine examinations, here’s the minimum documentation set to have ready:
AI Inventory Complete list of all AI tools in production or active pilot—including vendor-supplied and business-deployed GenAI tools. Each entry should include: tool name and vendor, use case and business function, data inputs (including whether customer data is processed), risk tier classification, validation status, and control owner.
Kill Switch Protocol For each material AI system: documented trigger thresholds, authorization chain (who can invoke), escalation path, and downstream substitution plan for when the model goes offline. This doesn’t need to be a 50-page document—a clean one-page protocol per material system is better than a general policy that doesn’t address specific models.
AI Vendor Contract Review For each significant AI vendor relationship: documented review confirming the contract includes model change notification, data handling and retention provisions, sub-processor disclosure, and exit provisions. Where contracts don’t include required provisions, the gap should be documented with remediation timeline.
Data Boundary Documentation For each AI deployment: authorized data inputs, technical controls enforcing the boundary, and who approved the authorization. This is especially important for enterprise AI tools that integrate with email and document systems.
AI Incident Escalation Path Written protocol for what happens when an AI model malfunctions—including consumer complaint pattern recognition, model output anomaly thresholds, escalation triggers, and regulatory notification considerations.
Board-Level AI Risk Reporting Evidence that AI risk exposure is being reported at the governance level on a regular cadence. The AI Risk Assessment Template & Guide includes governance reporting templates structured for board and committee presentation.
So What?
The 72% number is a planning number. If you’re in that majority, your next exam is going to surface documentation gaps that will be harder to close under a findings deadline than they would be if you started now.
The practical steps in priority order:
-
Run your AI inventory to confirm what’s actually deployed—most institutions discover 30-50% more AI footprint than their initial estimate. The AI governance decision log approach can help structure that inventory work.
-
Document a kill switch protocol for your three most material AI deployments. Credit scoring, fraud detection, and primary AML models are where examiners will focus if your institution uses AI in any of those areas.
-
Pull your AI vendor contracts and confirm what’s in them for model change notification, sub-processor disclosure, and exit provisions. Renegotiation takes time; the gap documentation should happen now.
-
Map data boundaries for any enterprise AI tools that integrate with email, document management, or core banking workflows. If you can’t describe what data the tool can access, you don’t have a data boundary—you have a data boundary assumption.
The agencies have been clear that AI guidance is coming in waves. SR 26-2 was the first wave. The RFI on generative and agentic AI is next. But examiner questions are already outrunning the formal guidance schedule—and institutions waiting for the rule before building governance infrastructure are behind.
The AI Risk Assessment Template & Guide includes kill switch protocol templates, AI inventory structure, vendor AI contract review checklist, and board-level AI risk reporting frameworks structured for 2026 examination expectations.
◆ Need the working template?
Start with the source guide.
These answer-first guides summarize the required fields, evidence, and implementation steps behind the templates practitioners search for.
◆ Related template
AI Risk Assessment Template & Guide
Comprehensive AI model governance and risk assessment templates for financial services teams.
◆ Immaterial Findings · Weekly
Sharp risk & compliance insights. No fluff.
◆ FAQ
Frequently asked questions.
What is an AI kill switch and why are bank examiners asking about it?
Why does SR 26-2 not cover generative AI and agentic AI—and what does that mean for exam prep?
What does 'vendor disentanglement' mean in the AI examination context?
What is data boundary enforcement and how should a bank document it?
What AI governance documentation should a bank have ready before a 2026 exam?
Is a 'kill switch' a formal regulatory requirement or just examiner preference?
Author
Rebecca Leung
Rebecca Leung has 8+ years of risk and compliance experience across first and second line roles at commercial banks, asset managers, and fintechs. Former management consultant advising financial institutions on risk strategy. Founder of RiskTemplates.
◆ Related framework
AI Risk Assessment Template & Guide
Comprehensive AI model governance and risk assessment templates for financial services teams.
◆ Keep reading
Related posts.
AI Risk
EU AI Act August 2, 2026: What's Going Live, What Got Pushed to December 2027, and What US Fintechs Need to Do This Week
August 2, 2026 is five days away. The Digital Omnibus deferral is now final law. Here's what actually goes into effect on August 2 vs. what got moved to December 2027 — and the two-hour compliance check US fintechs should run now.
Jul 27, 2026
AI Risk
AI Risk Assessment Questionnaire: Split the Questions Between the Business Owner, Technology Team, and Independent Reviewer
Build an AI risk assessment questionnaire with clear owners, evidence fields, and independent challenge instead of one unreliable respondent.
Jul 26, 2026
AI Risk
NIST AI RMF Implementation: The Minimum Artifact Set for a Team That Cannot Build 200 Controls
What a small risk team actually needs to produce for NIST AI RMF and FS AI RMF compliance — 12 artifacts across GOVERN, MAP, MEASURE, and MANAGE that hold up to examiner scrutiny.
Jul 24, 2026