Evaluating AI Governance Platforms for Banks Under SR 26-2

What SR 26-2 covers, and what changed

The Federal Reserve, OCC, and FDIC issued revised model risk management guidance on April 17, 2026. It is published as SR 26-2 by the Federal Reserve and as OCC Bulletin 2026-13. The guidance discusses the factors that influence model risk and the features of effective model development and use, model validation and monitoring, and governance and controls. The OCC bulletin also addresses vendor and other third-party products.

A Federal Reserve speech on May 1, 2026 states that the agencies amended the guidance to clarify that it does not apply to generative or agentic AI. The speech adds that banks are relying on existing risk-management frameworks for these systems, and that supervisors expect other risk-management and governance practices to support their adoption. This is current as of November 2026.

The practical consequence is two scopes. Traditional and machine learning models within the model definition fall under SR 26-2. Generative and agentic systems are governed through the bank's wider risk and governance practices, which the guidance itself says should guide controls for tools and systems it does not cover. The guidance also recognizes that practices vary with a bank's risk profile and model usage, and each bank remains responsible for practices that are effective for its own risks. A platform evaluation should start from that split rather than from a single compliance checklist.

Capability categories and what each leaves open

The guidance describes supervisory expectations by lifecycle area. It does not name tool categories. The mapping below is analysis, intended to show where categories overlap and where they do not.

• Model inventory and validation tools: Support the model definition, inventory, development documentation, and validation. They describe how a model was built and tested, and generally do not show what a system does in production.
• AI governance and GRC workflow: Support policies, assigned responsibilities, approvals, and issue tracking. They record intended control and decisions, and the record is only as current as the process feeding it.
• Observability and monitoring: Support ongoing monitoring by tracking behavior and performance over time. Whether they can prevent an action, rather than report it, depends on the product.
• Runtime policy enforcement: Applies policy at the point of an interaction or tool call and produces evidence on each decision. It does not manage inventory, validation, or governance workflow.

The gap between documented policy and production behavior

The guidance says governance should be supported by clear policies and effective controls, and that internal audit generally evaluates whether practices are rigorous and effective and whether related policies are implemented accordingly. The word implemented matters. Validation reports, inventories, and approval records show that a process ran. They do not show that a written limit held on a given day.

This gap widens for systems whose behavior varies with inputs and tool access. A policy may state that certain data must not reach an external model, or that a payment-related tool call needs human approval. Pre-deployment testing can show the system behaved that way in test. Only a control in the execution path can show it behaved that way in production.

In our analysis, evidence an examiner can rely on has three properties. It is generated by the control itself rather than assembled afterward. It is tied to individual interactions or tool calls. It records the policy applied and the outcome, such as allowed, redacted, blocked, or escalated. Narrative summaries and sampled screenshots are weaker, because they depend on someone reconstructing events.

Implementation decisions and tradeoffs

Begin by documenting which AI use cases fall within the model definition and which do not. That decision determines whether SR 26-2 lifecycle expectations or your broader risk practices drive the controls.

Then calibrate. The guidance recognizes that practices vary with risk profile and usage, and the OCC notes its guidance does not require community banks to perform annual model validation. A platform configured for the largest institution is not the benchmark for every bank.

Finally, decide where each capability will live. A governance platform and a runtime layer solve different problems, so layering them is reasonable, but it adds a second system to own, a second set of policies to keep consistent, and a second evidence source to reconcile. The tradeoff is worth it only where you need proof of production behavior, which usually means systems that take actions or handle sensitive data.

Where runtime enforcement and Trussed fit

Trussed is a runtime control and evidence layer. It is not an AI governance platform, GRC tool, observability product, or pre-deployment testing product, and it does not replace inventory, validation, or governance workflow. It addresses the production gap described above.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites, and coding assistants. Policy is enforced at runtime, not reviewed after the fact: each interaction or tool call can be allowed, redacted, blocked, rate limited, or escalated for human approval. Enforcement produces continuous audit-ready evidence, mapped to NIST among other frameworks. Its scope is individual interactions and tool calls. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

Trussed has run continuously in production in a regulated enterprise for more than 18 months, with 99.95% uptime on live traffic, 100+ models under one policy plane, and over 30 GB of audit evidence generated per day. It holds SOC 2 Type II, HIPAA, GDPR, FERPA, and ISO 27001 compliance, and NIST AI RMF alignment. Its customers span insurance, pharma, healthcare, and education. Insurance is the regulated financial sector where Trussed is deepest.

For a risk leader, the useful framing is complementary. A governance platform records what the bank intends and approves. A runtime layer shows what each AI interaction was permitted to do and what happened.