In April 2026, the Federal Reserve, OCC, and FDIC jointly issued SR 26-2, revised guidance on model risk management that supersedes the 2011 framework most banks have operated under for over a decade. The guidance is described as most relevant to banking organizations with more than $30 billion in total assets.
If you run a community bank or a credit union, it is tempting to file that under "not us." That instinct is a mistake. Examiners do not apply model-risk thinking only to the largest institutions. They apply it proportionately, everywhere, and the moment an AI model starts influencing a decision in your institution, the expectation to govern that model arrives with it, regardless of your asset size.
SR 26-2 is written for the big banks. The principles behind it reach you anyway, through your examiner and through your own obligation to manage risk. Community banks and credit unions inherit the expectations without inheriting the model-risk teams that large banks use to meet them.
What model risk management actually asks
Strip the guidance to its core and model risk management asks a few hard questions about every model that drives a decision. Can you validate it, meaning can a qualified, independent reviewer assess its conceptual soundness, monitor its performance, and analyze its outcomes? Can you document it in enough detail that someone unfamiliar with the model can understand how it works, what its limitations are, and what assumptions it rests on? And can you monitor and re-validate it over time as conditions and the model itself change?
For a traditional credit or fraud model, those questions are demanding but answerable. For an AI model, and especially a large language model, each one gets harder. The model is opaque by design. Its behavior shifts with prompt wording rather than code changes. It can produce fluent output that is simply wrong. And the version you validated can be replaced by the provider on a schedule you do not set.
The reframe: this is an architecture problem, not a paperwork problem
Here is where most of the advice gets it half right. The model-risk vendors and consultants will tell you to build an inventory, hire validators, write documentation, and stand up a governance committee. All of that is necessary. None of it is sufficient, because whether the model-risk lifecycle is even executable was decided earlier, by where and how the model runs.
Three mechanics make that concrete, and all three are architectural rather than procedural.
Version drift breaks your validation baseline. Model risk management expects you to re-validate a model when it changes. A managed AI model gets updated, retuned, and eventually deprecated on the provider's timeline, not yours. That means the model you validated in March can be quietly replaced by a different model in June, without a single change on your side and sometimes without timely notice. Your validation now describes a model that no longer exists.
Reproducibility is required, and managed AI does not guarantee it. Outcomes analysis and back-testing depend on being able to reproduce results from a fixed model. Between the non-deterministic nature of these systems and version changes you do not control, a managed endpoint cannot promise that the same input produces the same output six months from now. Without reproducibility, the outcomes analysis the guidance expects becomes very hard to perform honestly.
You cannot document a model you do not hold. The documentation standard is that an outsider should be able to understand how the model operates, its limitations, and its assumptions. You cannot write that for a proprietary foundation model whose weights, training data, and configuration you cannot see. You can document how you use it, but not the model itself.
Model risk for AI is usually written about as a governance problem you solve with process and tooling. The harder truth is that it is an architecture problem you solve, or fail to solve, at deployment. The validation tooling you buy afterward cannot recover what the deployment choice already foreclosed.
Why this lands hardest on community banks
A large bank can absorb a black-box model the hard way. It can put a dedicated model-risk team on behavioral testing, build monitoring around the endpoint, manage the vendor relationship, and document its way to a defensible position. It is expensive and imperfect, but a team with headcount and budget can do it.
A community bank or credit union usually cannot. There is rarely a dedicated model-risk function. The same handful of people own compliance, risk, and IT, and they depend on vendors for most of their technology. That dependence is exactly why the architecture choice matters more for a smaller institution, not less. When you have no team to compensate for what the architecture forecloses, you cannot afford to deploy AI in a way that makes governance structurally hard.
Put plainly: the large bank can buy its way past a poor deployment choice. You have to make the right one up front.
What controlled deployment actually buys a lean team
It is worth being honest about what controlled deployment does not give you. Running a model on your own infrastructure does not make a large language model interpretable. These systems are complex regardless of where they run, and anyone promising full explainability is overselling.
What controlled deployment does give you is the ability to execute the model-risk lifecycle in the first place. You decide when the model version changes, so a vendor update never silently invalidates your validation. You can reproduce results from a fixed model, which makes outcomes analysis and back-testing possible. You hold the model, its configuration, and its fine-tuning data, so you can document them. Every input, output, and retrieval source is logged inside your environment, which supports ongoing monitoring and gives an examiner a clear trail. And the model and the data sit inside one governance boundary you already control.
For a lean team, that is the difference between a model-risk obligation that is merely demanding and one that is effectively impossible.
One related point is worth separating out, because it comes up often. Teams sometimes answer a model-risk question with a security answer: the service is encrypted, isolated, and does not train on our data. All of that can be true and necessary. None of it makes a model validatable. Data security and model governance are different axes, and an examiner asking how you validated a model is not asking whether the data was encrypted in transit.
Sources: Federal Reserve SR 26-2, OCC, and FDIC, Revised Guidance on Model Risk Management (April 2026), which supersedes SR 11-7 (2011) and SR 21-8 (2021), and is described as most relevant to banking organizations with more than $30 billion in total assets; OCC Bulletin 2026-13. Long-standing model risk guidance (SR 11-7) establishing that use of vendor or third-party models does not reduce an institution's responsibility for model risk management, that vendor models must be validated to the same standard even where methodology is proprietary, and that documentation should let someone unfamiliar with a model understand its operation, limitations, and assumptions. This article is informational and not legal or compliance advice; confirm how these expectations apply to your institution with your own examiners and advisors.
Make Your AI Model Governable From Day One
Cognetryx runs AI inside your environment, where you control the model version, reproduce results, hold the documentation, and keep a complete audit trail. For a lean team, that is what makes model-risk expectations achievable rather than aspirational.
Book a Free AI Strategy Assessment →