Build vs Buy Generative AI Governance for Banks: SR 26-2 Leaves the Control Design to You

What SR 26-2 changed, and what it did not

The Federal Reserve published SR 26-2 on April 17, 2026, alongside the OCC and FDIC. It sets out principles for model risk management covering model development and use, validation and monitoring, and governance and controls. Footnote 3 describes generative AI and agentic AI models as novel and rapidly evolving, and the guidance states they are not within its scope. Its principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI models. For tools, processes or systems it does not cover, a bank's risk management and governance practices should guide the appropriate governance and controls.

A Federal Reserve speech on May 1, 2026 described this as an amendment to prior model risk management guidance, made to clarify that it does not apply to generative or agentic AI. The speaker also said the Fed expects other risk management and governance practices to support adoption of these systems. Read plainly, the carve-out delegates the design of controls to institutional discretion. It does not remove the expectation that governance exists, and examiners can reasonably look to the bank's own framework.

The guidance is expected to be most relevant to banking organizations with more than $30 billion in total assets, and it calls for tailoring to size, complexity and risk profile. The same logic is a sensible way to justify how deep your generative AI controls go.

Mapping responsibilities across existing MRM, in-house build and purchased tooling

Existing model risk practices are a useful template, not a requirement, for generative AI. Effective challenge, monitoring plans and named responsibility can be reused. What they typically do not supply is enforcement inside the request path. The table separates the three sources of coverage.

• Inventory, documentation, validation: Existing MRM processes. Extend them to generative AI use cases by bank policy, not by SR 26-2 mandate.
• Ongoing monitoring and effective challenge: Existing MRM processes, adapted. Define what monitoring means for non-deterministic output.
• Policy enforcement on prompts, outputs and tool calls: In-house build or purchased tooling. Neither lifecycle review nor documentation acts on a live interaction.
• Human approval escalation: Build or buy for the mechanism. The bank assigns the approver roles and exception ownership.
• Interaction-level evidence and retention: Build or buy. The bank sets retention, export and examiner-request procedures.
• Third-party model version changes: Bank process, tooling, or both. Decide who compares versions before deployment and who escalates material differences.

What building takes on

Building runtime enforcement means owning a component that sits in the execution path of every governed interaction. At minimum that includes a policy engine, interception points for prompts, outputs and tool calls, an escalation workflow that pauses an action until a named person decides, and an evidence store. Each must work across every model and tool the bank uses, and each new model, agent framework or tool integration adds interception work.

The harder part is continuity. The component adds latency and becomes a dependency, so availability and failure behavior (fail open or fail closed) are risk decisions, not engineering defaults. Policy needs versioning so the bank can show which rule applied at the time of a given interaction. Evidence must be tamper-resistant, retained on a defined schedule and retrievable when an examiner asks. Third-party model changes can alter behavior without notice, so the team must keep testing current policies against them.

Ownership matters as much as code. The bank should name who defines policy, who operates enforcement, who handles exceptions and who reviews evidence. NIST AI RMF places governance and oversight with actors holding management, fiduciary and legal authority, so escalation and exception approval should map to those roles. This is an engineering and examiner-scrutiny decision. A build is credible when the bank can staff and sustain these duties for as long as the AI is in use.

Choosing build, buy or hybrid

NIST AI 600-1 notes that governance tools and protocols used for other AI systems can be applied to generative AI, and it organizes suggested actions under govern, map, measure and manage. That makes it a practical taxonomy for assigning each control to a bank process, an in-house component or a vendor. No source ties an examiner expectation to it, so treat it as a mapping aid.

A hybrid is often the practical result. The bank keeps what its MRM function already does well, namely inventory, documentation, challenge and monitoring design, and acquires or builds the runtime layer separately. Build when your architecture is narrow, a small number of models and tools, and you can sustain engineering and evidence operations. Buy when the estate spans many models and tools, or when you need consistent enforcement and evidence faster than a build can reliably deliver. Either way, record the rationale in your governance documentation, tied to your risk profile.

As one example of purchased runtime control, Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate for human approval at the level of individual interactions and tool calls. Enforcement generates audit-ready evidence, and deployment is self-managed in the customer's cloud with configurable retention and data residency. Trussed has run 18+ months in continuous production in a regulated enterprise and operates 100+ models under one policy plane. It does not cover model lineage, dataset provenance or end-to-end tracing of agentic workflows, so those remain with the bank's other processes.