What the OCC and CSBS AI Supervisory Frameworks Mean for Banks

On November 4, the Office of the Comptroller of the Currency (OCC) released a supervisory framework for banks' use of "Super Intelligence," its new umbrella term for technologies previously described as artificial intelligence. The timing matters: The Conference of State Bank Supervisors (CSBS) released its own AI supervisory framework less than two months earlier.

Neither document is a new regulation. Neither creates a new rating system nor requires every bank to build a separate AI department. But dismissing the frameworks as "just examiner guidance" would be a mistake. Together, they offer the clearest preview yet of how examiners will locate AI use, determine where the risk belongs, and ask banks to prove that controls work.

AI is not becoming a new risk silo. It is becoming a stress test for every risk program a bank already has.

What the OCC AI Framework Is Really Saying

AI Changes Existing Risk. It Does Not Create a New Risk Category.

The OCC directs examiners to evaluate AI within existing model risk, governance, technology, compliance, operational risk, cybersecurity, privacy, credit, and third-party risk programs. AI can introduce, amplify, or modify those risks, but the framework says examiners should not treat it as a separate risk category. Banks also are not required to define a separate AI risk appetite.

That technology-neutral posture is important. An AI-generated customer response still has to be accurate. An AI-assisted adverse action still needs a defensible reason. A vendor-hosted tool does not outsource the bank's accountability. The legal and prudential obligations remain, even when the technology underneath them changes.

The Real Risk Question Is Not "How Advanced Is the Model?"

The OCC's organizing principle is consequence: Control intensity should increase with the potential impact of failure or misuse. Examiners may consider whether an action is reversible, whether the system advises or acts, how much authority and access it has, how long it can operate without a meaningful human checkpoint, and how broadly failure could affect customers, operations, finances, compliance, or markets.

A relatively simple agent authorized to release a fraud hold or initiate a payment may present more risk than a highly sophisticated model limited to drafting an internal memo. Model performance matters. Authority matters more.

Agentic AI Changes the Control Conversation

Generative AI creates output risk. Agentic AI adds action risk. Once a system can use tools, access accounts, update records, communicate externally, or move money, banks need controls for scope drift, excessive permissions, nondeterministic behavior, prompt manipulation, vendor changes, failed human oversight, and incorrect operation even when the system never goes offline. "System available" no longer necessarily means "system working safely." A bank may need to detect, contain, stop, recover from, and remediate an AI system that remains fully available but is operating incorrectly.

Six Pillars, One Examiner Logic

The OCC organizes 16 framework components into six pillars. The sequence is practical: Define the use case, understand the consequences, build controls, assign oversight, plan for failure, and produce evidence.  

• Purpose: What is the system allowed, and not allowed, to do?
• Risk: What happens if the output or action is wrong, misused, or difficult to reverse?
• Control: What prevents unauthorized, unsafe, or noncompliant action?
• Oversight: Who monitors the system, who can intervene, and who is accountable?
• Resilience: Can the bank contain failure, continue the process, and remediate harm?
• Assurance: What evidence proves the controls continue to operate effectively?

How Banks Can Integrate AI into Existing Governance

While the OCC is not calling for a separate AI compliance program, simply having an AI policy is not a control strategy. Banks do not explicitly need a separate AI risk category, a separate AI risk appetite, or a universal standalone governance structure. The better operating model is to extend existing processes and make AI visible within them.

The OCC is not requiring a new committee, a duplicate three-lines model, or a second enterprise risk management program. It does need AI-specific information and control points where the technology creates different failure modes.

• Inventory: Identify the use case, business owner, provider, deployment status, data, permissions, autonomy, human oversight, monitoring, continuity, and material changes, including AI embedded in products the bank already licenses.
• Risk assessment: Classify the use case by consequence, reversibility, customer impact, data sensitivity, access, autonomy, concentration, and transfer of agency.
• New product and change management: Revisit approval when the model, prompt, provider, data, permissions, purpose, or operating environment materially changes.
• Vendor management: Ask about embedded AI, model and feature changes, bank-data use, incident notification, testing transparency, responsibility for customer harm, audit rights, and exit options.
• Human oversight: Define whether a person approves before action or actively monitors during operation. Confirm that reviewer has the skill, information, capacity, authority, and time to intervene.
• Resilience and incident response: Plan for kill switches, rate limits, isolation, manual fallback, impact analysis, customer remediation, and a controlled restart.
• Independent assurance: Give validation, compliance, audit, and the board enough evidence to challenge the use case rather than simply accept it at face value.

The practical answer is to integrate AI into your existing governance programs, but make sure AI is specifically identifiable in your governance. AI does not need its own island. It does need a permanent address in the governance processes the bank already relies on.

How AI Examinations Will Meaningfully Change

The OCC is not creating a separate AI examination rating. The CSBS framework likewise routes deeper review into existing supervisory resources. Still, the scope, questions, walk-throughs, and evidence requests are likely to become more concrete.

• Examiners will test visibility: They may not accept "we do not use AI" at face value. Vendor inventories, recently enabled features, productivity suites, fraud platforms, SaaS products, employee-adopted tools, and public generative AI can expose gaps between the official answer and actual use.
• The exam will start with the use case, not the model: Expect examiners to follow the highest consequence uses end to end: what the system can do, what it can access, who approved it, where people intervene, how changes are governed, and what happens when it is wrong.
• "Human in the loop" will have to mean something: A named reviewer is not enough. Examiners may ask whether the person has expertise, context, authority, workload capacity, escalation triggers, and a practical ability to stop or override the system. Bulk approval can turn a supposed control into a rubber stamp.
• Resilience will expand beyond uptime to "harm": Banks may need to show how they detect a harmful output or action, stop the agent, isolate affected processes, continue critical operations, identify impacted customers or transactions, remediate harm, and safely return to service.
• Evidence will matter more than policy language: For material uses, be ready with purpose statements, inventory records, risk tiering, approvals, testing, monitoring, override logs, vendor documentation, change history, incidents, continuity plans, and independent review.

The CSBS Core Examiner Guide is especially direct about exam mechanics: initial scoping, a document request list, governance and oversight, inventory and use cases, generative and emerging AI, and referrals into third-party, model risk, consumer protection, and operational risk resources.

OCC vs. CSBS: Aligned Direction, Different Emphasis

The two frameworks are more aligned than different. Both are principles-based and proportional. Both begin with visibility and inventory. Both expect clear ownership, risk-based review, vendor oversight, data controls, monitoring, escalation, and evidence. Both direct serious weaknesses back into existing supervisory disciplines.

The simplest way to remember the difference: CSBS is the clearer exam playbook. OCC is the deeper agent-control framework. Banks operating across charters or state lines should be ready for both lenses. But regardless, the evidence is now official that both your national and state examiners are going to be digging into AI deeper than before.

What Banks Should Do Now

Do not create process for process's sake. Strengthen the places where examiners will look and where failures would cause the most harm.

• Finish the inventory: Include approved tools, embedded vendor features, pilots, employee-adopted tools, and shadow AI. If you cannot see it, you cannot govern it.
  
• Add AI fields to existing intake: Capture purpose, owner, data, permissions, autonomy, reversibility, customer impact, human oversight, provider concentration, and fallback before approval.
• Tier by consequence: Do not confuse sophistication with risk. Ask what the system can affect, how fast harm could spread, and how difficult the action would be to reverse.
• Make human oversight provable: Document qualifications, workload, decision authority, review triggers, overrides, escalation, and the time available to intervene.
• Update vendor controls: Require transparency on embedded AI, model changes, data use, incident notice, testing evidence, responsibility, auditability, and exit.
• Test failure, not just accuracy: Run scenarios for hallucination, prompt injection, drift, incorrect autonomous action, permission abuse, customer harm, kill switches, and manual fallback.
• Build the examination evidence package: For every material use case, assemble the purpose, owner, tier, approvals, controls, testing, monitoring, changes, incidents, continuity, remediation, and independent review.

Board-level question: Can management show the board not only where AI is used, but which use cases could create material harm, how those use cases are controlled, and whether the bank can stop them quickly?

Governance Is How Banks Earn the Right to Move Faster

The OCC and CSBS are not telling banks to choose between innovation and control. They are making the opposite point: Disciplined risk management is what allows responsible innovation to scale. Interestingly enough, this has always been the correlation between the speed of adoption of new technologies and risk management. The better your institution is at risk management, the faster you can adopt new technologies safely and responsibly.

The institutions positioned to move fastest will be those that can explain what AI is doing, why it is allowed, who owns the outcome, who can stop it, and what happens when it is wrong. This isn't about bureaucracy; it's a strong risk management posture and confidence in your team to truly manage cyber risk.

The examiner question is no longer hypothetical: If AI is already in the bank, is the governance already there too?