Bank board oversight of AI risk when SR 26-2 excludes generative AI

What the SR 26-2 exclusion does and does not change

SR 26-2 was issued on April 17, 2026 by the Federal Reserve, OCC and FDIC. It supersedes SR 11-7 and SR 21-8. In a May 1, 2026 speech, Governor Bowman said the agencies amended the model risk management guidance to clarify that it does not apply to generative or agentic AI. She said supervisors had expanded the earlier guidance beyond its original purpose, and that the Fed expects other risk management and governance practices to support adoption of these technologies.

The exclusion changes which document a bank cites for generative AI. It does not change who is accountable. SR 26-2 itself says a banking organization's own risk management and governance practices should guide the controls for any tools, processes or systems it does not cover. Bowman also said banks rely on existing risk management frameworks to guide their AI use.

The practical reading is that the bank must be able to explain its own framework for generative AI. A board that answers an examiner question with "the model risk guidance does not apply" has described a scope boundary, not a control environment.

Mapping existing board duties onto generative AI

Most of what a board needs is already in its governance structure. For banks covered by OCC Appendix D to Part 30, the risk governance framework is formal and written, designed by independent risk management and approved by the board or its risk committee. It includes delegations of authority from the board to management and risk limits for material activities. Independent risk management reviews and updates it at least annually, and as often as emerging risks require. Generative AI is an emerging risk that belongs inside that cycle.

The Comptroller's Handbook adds that the board should oversee and hold management accountable for meeting strategic objectives within risk appetite, and may rely on reports from independent risk management and internal audit to question and challenge management. That reliance only works if those functions cover generative AI. If neither has scoped it, the board has nothing to challenge.

SR 26-2's own principles transfer as design inputs: clear policies, effective controls, defined roles and accountability, and oversight proportionate to materiality. Applying them to generative AI is the bank's choice, made under its own framework. Third-party accountability also carries over. Fed guidance for community banks states that engaging a third party does not diminish the bank's responsibility to operate safely and soundly and comply with applicable law. A proposed interagency third-party guidance was open for comment as of November 2026, so the board should track it.

Six oversight elements the board should require

These elements give the board a structure it can test. Each should be owned by a named function and reported on a set cadence.

• Risk appetite: Add generative AI to board-approved appetite statements and risk limits, including which uses and data types are in or out of bounds.
• Inventory: Maintain a list of generative AI and agentic systems, including vendor-embedded features and coding assistants, with a business owner for each.
• Accountability: Document delegations of authority from the board to management, and assign who approves new uses and who can stop one.
• Enforceable runtime policy: Translate written policy into rules applied to interactions and tool calls, so limits operate during use and not only on paper.
• Escalation: Define which actions require human approval, which events go to independent risk management, and which reach the board or its risk committee.
• Evidence: Retain records showing what each system was permitted to do, what it did, and which policy version applied.

Policy reviewed after the fact versus policy enforced at runtime

This distinction is a design judgment, not a regulatory category, but it determines what evidence a bank can produce. Post-hoc review samples outputs or activity after the system has acted. It can find patterns and support improvement. It cannot show that a prohibited action was prevented, only that someone later noticed or did not notice it.

Runtime enforcement applies policy in the execution path, at the moment a model interaction or tool call is requested. A rule can allow the action, redact sensitive content, block it, or route it for human approval. Each decision is itself a record: the request, the rule applied and the outcome. That record speaks directly to the board's question of what AI was allowed to do.

The tradeoff is operational. Runtime rules need owners, testing and change control, because a badly written rule can block legitimate work or miss a risky one. Post-hoc review remains necessary for judgment calls that rules cannot capture. Most banks will use both. The board's concern is knowing which behaviors fall into which category, and whether the high-consequence ones are enforced before they complete.

Evidence and reporting the board should expect

Board reporting should combine inventory and ownership status, exceptions to risk limits, escalations and their resolution, and the results of independent testing. Independent risk management and internal audit should report on generative AI controls so the board can challenge management with something other than management's own account.

For retention, NIST AI 600-1 is a useful reference. It includes actions to keep a history of test, evaluation, validation and verification for generative AI, and to regularly verify that security measures remain effective. A bank can adopt these as internal practice. They are not an SR 26-2 requirement.

When judging whether a control produces audit-ready evidence, ask whether the record is created by the control itself or assembled afterward by a person. Records produced at the point of enforcement are harder to dispute and cheaper to retrieve than reconstructions. A bank should be able to show how its controls operated as designed, with records that stand without a narrative attached.

• Does each record identify the system, the requested action and the decision taken?
• Can you show which policy version applied at that time?
• Are human approvals captured with who approved and when?
• Are retention periods and data residency set deliberately, and do they match the bank's record rules?
• Can internal audit retrieve records independently of the team that operates the system?

Where Trussed fits

Trussed is control, provenance and evidence infrastructure for regulated enterprises that must show what their AI was allowed to do and what it did. It enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants. Policy is enforced at runtime, not reviewed after the fact: individual interactions and tool calls are allowed, redacted, blocked, rate limited or escalated for human approval.

Enforcement generates audit-ready evidence continuously, mapped to frameworks including NIST. It can be self-managed in the bank's own cloud, with configurable retention and data residency. Trussed customers are in insurance, pharma, healthcare and education, with insurance being where it is deepest. Its scope is individual interactions and tool calls, so other evidence needs, such as model lineage, must come from other controls.

A bank can apply the six elements above with or without Trussed. The test for any tool is whether it enforces the bank's policy in the execution path and produces evidence an examiner can inspect.