The Office of the Comptroller of the Currency has issued an examiner guide for banks’ use of “super intelligence,” its term for technologies previously described as artificial intelligence. Bulletin 2026-54, dated November 4, 2026, describes a risk-based supervisory resource—not a new bank rule, a mandated self-assessment, or an enforceable standard. Its central message is practical: the scrutiny applied to a use case should turn less on how technically impressive a system is than on what it can do, what could happen if it fails, and whether people can meaningfully intervene.

What the OCC issued—and what it did not

The OCC’s November 4 bulletin says the framework is designed to help its examiners evaluate banks’ use of SI in ordinary business activities. It explicitly says the guide does not establish supervisory expectations for banks, and that banks are not expected to use it as a self-assessment of their SI or risk management. The agency describes the document as an examiner resource intended to support judgment and says it may update the guide as technology, use cases and supervisory understanding develop. Those caveats matter: a guide can signal areas likely to receive attention without itself adding a binding obligation.

The OCC bulletin also says the agency does not treat SI as a separate risk category and does not require banks to create a separate SI risk appetite. Instead, SI-related issues may intersect existing model-risk, governance, technology, compliance and operational-risk practices. The underlying supervisory framework similarly frames its considerations as illustrative and proportionate. It uses “may” and “could” in describing measures that might be relevant; it does not turn every example into a universal checklist.

One element of the framing is terminology. The OCC uses “super intelligence,” referring to technologies previously encompassed by the statutory definition of artificial intelligence, and ties that usage to Executive Order 14434, cited in the bulletin. The label does not, by itself, mean that the guide covers only systems with capabilities beyond conventional AI. Baker Donelson’s November 6 analysis calls it a playbook and notes its emphasis on generative and increasingly agentic systems, while also acknowledging that it imposes no new regulatory requirements. Its headline refers to “new expectations,” but the OCC’s own text is clearer about legal status: the document says it establishes no new expectations or enforceable standards.

A consequence-first risk lens

The OCC’s overarching principle is that control intensity could rise with the potential consequences of an agent’s failure or misuse. It says classification may rest on consequences, transfer of agency and human oversight, rather than technical sophistication alone. The framework gives the intuitive contrast of a simple rules-based agent permitted to initiate transactions versus a sophisticated model confined to internal drafting: the former could warrant greater concern because it can directly act.

The detailed guide offers a broader set of considerations, not a fixed scoring formula. Examiners may consider the nature and consequence of the use case, its autonomy and complexity; the framework’s risk-classification section adds factors such as reversibility, customer and financial impact, data sensitivity, explainability, provenance, permissions and interdependencies. It also points to the possible significance of aggregate exposures, including shared providers or common weaknesses. These dimensions help explain why the same underlying model can pose different risks in different workflows.

For example, an internal tool that proposes a summary for an employee to check has a different action boundary from an agent that can submit payments or change customer records. That is an illustration of the framework’s logic, not an OCC determination that a particular deployed system is low or high risk. Consequences depend on implementation: the population affected, transaction size, reversibility, access granted, monitoring, and how quickly a mistake might spread all affect the real-world stakes.

The guide’s proportionality language is also important for smaller institutions. The bulletin says examiners may use the framework with community banks but should tailor reviews to a bank’s size, complexity and risk profile, proportionate to the nature, consequences, autonomy and complexity of its use cases. That is not an exemption for community banks, nor does it prescribe identical controls across institutions. It is an instruction about tailoring examiner work.

Autonomy makes oversight concrete

“Human oversight” can be a label rather than a functioning control unless the person reviewing an output has the information, competence, time and authority to challenge it. The OCC framework distinguishes human-in-the-loop review before an output or action is used from human-on-the-loop monitoring while a system operates, with practical ability to intervene. It suggests calibration to consequence, autonomy, reversibility and operating volume. These are illustrative considerations: the OCC does not state that every use case requires a human approval step.

For a consequential agent, a nominal approval click may not amount to meaningful review if a reviewer faces a high volume of decisions or cannot understand what the agent is about to do. The framework describes relevant considerations such as defining review triggers, logging overrides, setting escalation conditions, and assessing whether one person can credibly monitor the number of agents, accounts or actions assigned to them. It emphasizes practical capacity to reject, modify, pause or halt behavior. Whether a particular arrangement is adequate would depend on the bank’s circumstances and supervisory assessment.

Autonomy is not merely a model property. An apparently modest system can have far-reaching authority if connected to broad data, tools, accounts or business processes. Conversely, a technically advanced system may have a constrained role. The framework therefore focuses attention on permissions and action boundaries: what can invoke the system, which information and systems it can reach, and which actions it can execute without a checkpoint. This links architecture and operational governance to the risk discussion without treating model complexity as the sole proxy.

Six connected supervisory pillars

The framework organizes sixteen components beneath six pillars. Purpose concerns defining permitted actions and boundaries. Risk considers what could follow if an output or action is unfit for purpose. Control covers safeguards, including human controls and practices involving data, privacy, compliance, cybersecurity and model risk. Oversight addresses monitoring and accountability. Resilience concerns detecting, containing and recovering from failures while continuing critical operations. Assurance concerns evidence that controls continue to work, including testing, documentation, vendor risk and independent challenge.

Read together, the pillars describe a lifecycle rather than six independent compliance boxes. A bank defines a purpose and allowed actions; considers what could go wrong; sets controls and assigns accountable oversight; prepares to detect and recover from failure; and gathers evidence that the safeguards operate. A change in an agent’s permissions or use context could alter several of these questions at once. The framework says a purpose statement may be documented before deployment and after material change, and that an inventory may capture ownership, permissions, monitoring and continuity arrangements. It does not make the format of such a statement a prescribed regulatory form.

That lifecycle perspective also guards against treating a vendor relationship as an answer to accountability. The guide includes third-party and vendor risk within assurance and recognizes that providers, shared infrastructure and data can affect exposure. It does not relieve a bank of its own responsibility to understand how a technology is used in its operations. Specific contract provisions, testing regimes or audit arrangements must be considered in context; the guide’s examples should not be mistaken for a mandatory universal list.

What banks can take from the guide

Even though the OCC says banks need not use the document as a self-assessment, the framework provides a useful basis for internal discussion. A bank may find it helpful to know where SI is used, what each system is authorized to do, who owns the use case, and which systems or information it can access. That is a practical way to reason about the guide’s purpose and permission concepts, not a new OCC-mandated inventory requirement.

Institutions can also examine whether their existing processes distinguish support tools from systems that make or execute consequential decisions. The same question can be asked of changes over time: did an employee-facing summarizer become customer-facing, did a vendor add an agent feature, or did the tool receive broader access? The OCC framework specifically identifies scope drift and material changes as relevant concepts. Any review should remain proportionate to actual use, foreseeable harm and institutional context.

For oversight, useful questions include whether reviewers have authority to stop activity and whether monitoring volume allows a timely response. For resilience, a bank can consider how it would detect and contain an erroneous or unauthorized action, and how critical work would continue if a system were suspended. For assurance, testing and documentation can help demonstrate what boundaries were intended and whether they are operating as planned. These are sensible governance questions informed by the guide; they are not presented here as a checklist that the OCC has ordered banks to complete.

Finally, banks should read this document alongside applicable laws, regulations, existing supervisory materials and their own risk programs. The framework does not replace those sources. Baker Donelson observes that banks may regard it as a preview of questions examiners could ask, particularly for generative and agentic deployments. That is an interpretation by the law firm, not a formal OCC promise about examination procedures. The careful conclusion is narrower: examiners have been given an additional resource and the OCC has described factors it considers relevant to tailoring reviews.

Limits and open questions

The public bulletin supplies no numerical risk thresholds, mandated tier scores, or fixed minimum human-review ratios. Although Baker Donelson describes four illustrative risk tiers, the OCC bulletin itself emphasizes tailored examination and consequence-based classification, not a compulsory tiering system for banks. The framework’s individual examples should not be elevated into mandatory controls without a separate legal or supervisory basis.

Nor does the guide settle how examiners will apply every factor across different products, institutions or future systems. The OCC expressly says its understanding and the technology will evolve and that it intends to update the resource. There is consequently uncertainty about how emphasis may shift in later examinations. That uncertainty does not negate the framework’s present value as an explanation of examiner considerations, but it cautions against treating today’s examples as a final or exhaustive standard.

The independent analysis’s title can sound more prescriptive than the bulletin. In the article’s text, however, Baker Donelson says the framework creates no new requirements and is an examiner resource. We therefore give controlling weight to the OCC’s precise statement about the document’s status and attribute the law firm’s forward-looking interpretation as analysis, not fact. No implementation outcomes or examination findings are established by the materials reviewed here.

Frequently asked questions

Does Bulletin 2026-54 impose a new rule on banks?

No. The OCC says the framework is intended to help examiners and does not establish new regulatory expectations, enforceable standards or prescriptive requirements.

Must banks use the document as a self-assessment?

No. The OCC expressly says banks are not expected to use it to assess their SI use or SI risk management.

What drives the OCC’s risk lens?

The bulletin emphasizes use-case materiality and potential consequences. The framework also discusses autonomy, complexity, permissions, human oversight, reversibility and potential customer, financial or operational impacts.

Does the guide require a human to approve every AI action?

No universal approval rule appears in the bulletin. The framework discusses human-in-the-loop and human-on-the-loop controls as considerations that may be calibrated to potential consequences and the use case.

Does “super intelligence” mean only advanced autonomous systems?

No. The OCC defines SI broadly by reference to technologies previously encompassed by the statutory AI definition, while the guide gives particular attention to generative and agentic use cases.

References