Key takeaways
- Model risk management (MRM) is the discipline that identifies, measures and controls the risk of loss from decisions based on incorrect or misused models.
- US supervisory expectations changed in 2026:
SR 26-2replaced the 15-year-oldSR 11-7, moving from mandatory annual revalidation to risk-based oversight tied to model materiality. SR 26-2deliberately leaves generative and agentic AI outside its formal scope, which opens a governance gap that AI-specific frameworks have to fill.- Machine learning and generative models break several assumptions behind classic MRM: they drift, they are opaque, and they behave non-deterministically.
- A modern program anchors MRM to a central model inventory and maps its controls onto the EU AI Act, ISO/IEC 42001 and the NIST AI RMF.
What is model risk management?
Model risk is the potential for adverse consequences, whether financial loss, poor decisions, regulatory censure or reputational damage, that follow from decisions based on models that are incorrect, misapplied or misunderstood. Model risk management is the set of policies, roles and controls an organization uses to keep that risk inside a defined appetite across the full model lifecycle. The reference definition comes from US banking supervision. In April 2011 the Federal Reserve and the Office of the Comptroller of the Currency issued SR 11-7 (OCC Bulletin 2011-12), which described a model as a quantitative method that applies statistical, economic, financial or mathematical theory to turn input data into a quantitative estimate. That guidance became the template for MRM well beyond banking. Two ideas do most of the work. First, every model is an approximation, so error is a property of a model, not a failure of it. Second, error becomes risk only when a model informs a decision. MRM therefore concentrates effort where a wrong output would cause the most harm, which is why materiality, the stakes attached to a model, sits at the center of every serious program. The same logic underpins broader AI risk management, of which model risk is one component.
The three pillars: development, validation, governance
SR 11-7 organized MRM into three pillars that still define the field. Development and implementation covers sound design, documented assumptions, appropriate data and testing before a model goes live. Validation is independent effective challenge: a team separate from the developers checks conceptual soundness, ongoing monitoring and outcomes analysis. Governance wraps both in policies, roles, an inventory and clear accountability, so the organization knows which models exist, who owns them and how they are controlled. These pillars map cleanly onto the wider taxonomy of AI risk that governance teams now track.
Where model risk comes from
Model risk has four recurring sources, and each one is amplified when the model is a machine-learning system. Data. A model is only as sound as the data it learns from and runs on. Sampling gaps, label errors, stale features and unrepresentative populations all propagate into outputs. Machine learning widens this exposure because models absorb quality issues at scale and reproduce them in every prediction. Design and assumptions. Every model encodes assumptions about the world. When those assumptions no longer hold, for example a scoring model built on pre-shock behavior, the outputs degrade even though the code is unchanged. Implementation. Errors enter when a model is coded, integrated or deployed: a mismatched feature pipeline, a rounding difference between training and production, or a silent library change. These defects are easy to miss because the model still returns plausible numbers. Use and misuse. The largest losses often come from using a model outside its intended purpose, trusting it beyond its tested range, or ignoring its limitations. Clear scope statements and user guidance are controls, not paperwork.
From SR 11-7 to SR 26-2: how the rules changed in 2026
For fifteen years, SR 11-7 was the fixed point of MRM practice. That changed on 17 April 2026, when the Federal Reserve, the OCC and the FDIC issued SR 26-2, revised interagency guidance on model risk management that supersedes SR 11-7. The direction of travel is risk-based and scalable. Supervisors now expect the depth of a program to match the size, complexity and risk profile of the institution, a clarification aimed at smaller and less complex firms. The most consequential operational change is that mandatory annual revalidation gives way to oversight tied to model materiality, so validation effort follows the stakes rather than the calendar. SR 26-2 also narrows what counts as a model, excluding simple arithmetic such as spreadsheet calculations, deterministic rule-based processes and ordinary software. The guidance is most relevant to banks above 30 billion USD in assets, is explicitly non-binding, and is paired with OCC Bulletin 2026-13. For regulated firms this is a chance to retire calendar-driven busywork and reinvest validation capacity where model risk is genuinely high. For everyone else it signals where supervisory thinking is heading: proportional, evidence-led control rather than uniform box-ticking. The same materiality-first logic runs through modern risk management compliance programs.
The generative-AI gap SR 26-2 leaves open
There is a deliberate limit. SR 26-2 keeps generative and agentic AI outside its formal scope, on the grounds that these technologies are new and moving quickly. That is a defensible supervisory choice, but it leaves the fastest-growing category of models with no dedicated MRM standard from US banking regulators. Firms deploying large language models or autonomous AI agents cannot wait for the next revision. They need to extend MRM principles to these systems now, using the AI-governance frameworks built for exactly that purpose.
Why AI and machine learning break traditional MRM
Classic MRM was designed for models that are relatively stable, inspectable and deterministic. Machine learning and generative systems violate all three assumptions, which is why validation teams cannot simply reuse the old playbook. Non-determinism. A generative model can return different outputs for the same prompt. Validation methods built around a single expected result do not translate to systems whose behavior is probabilistic by design. Drift. ML models degrade as the world moves away from their training distribution. Without continuous monitoring, a model that validated cleanly at launch can quietly become unreliable. Opacity. Complex models resist inspection, which complicates conceptual-soundness review and collides with regulatory expectations for explainability. Reviewers cannot always trace why an output was produced. Bias and adversarial exposure. Models trained on ungoverned data inherit and amplify bias, and generative systems add prompt injection and jailbreak risks that traditional validation never contemplated. Data leakage and provenance. When training data is poorly governed, sensitive information can surface in outputs, and the organization may be unable to prove what a model was trained on. The most acute case is the hallucination risk of generative AI, where a fluent, confident output is simply wrong.
Model risk management meets AI governance
The gap left by banking guidance is filled by three AI-governance instruments, and a mature program treats them as one connected control set rather than three separate audits. The EU AI Act puts MRM-style obligations into law for high-risk systems. Providers must run a risk management system across the lifecycle (Article 9), apply data governance (Article 10), maintain technical documentation (Annex IV), ensure human oversight (Article 14) and meet accuracy, robustness and cybersecurity requirements (Article 15), then pass a conformity assessment (Article 43). The operator’s guide to the EU AI Act sets out how these duties are allocated. The NIST AI RMF offers a voluntary structure through four functions, Govern, Map, Measure and Manage, that align naturally with development, validation and monitoring. Our NIST AI RMF guide walks through each function. ISO/IEC 42001 provides a certifiable AI management system with Annex A controls and a three-year certification cycle, which gives MRM an auditable management-system home, as explained in our ISO 42001 overview. Even sector supervisors are converging on the same expectations. The ECB Guide to Internal Models, revised in July 2025, added a dedicated machine-learning section covering explainability, the trade-off between performance and complexity, validation and model risk management for banks that use ML in regulated internal models.
One control set across frameworks
The frameworks overlap more than they differ. A single validation exercise can satisfy SR 26-2 effective challenge, EU AI Act Article 9, NIST Measure and ISO 42001 monitoring controls at the same time, provided the evidence is captured once and mapped to each requirement. Our cross-mapping of NIST AI RMF, ISO 42001 and the EU AI Act shows where the requirements meet, so teams avoid running the same control three times.
Building a modern model risk management program
A program that spans traditional and AI models rests on three operational foundations.
Model inventory as the foundation
You cannot manage what you have not catalogued. A complete model inventory, recording every model, its owner, purpose, materiality, data sources and validation status, is the precondition for every other control. The hardest inventory problem today is not the models IT knows about but the ones it does not, the spreadsheets, notebooks and third-party AI tools that make up shadow AI. A registry that discovers and tracks these systems turns MRM from a periodic exercise into a live capability.
Three lines of defense for AI models
Effective MRM separates duties. The first line, model owners and developers, builds and documents. The second line, independent validation and risk, challenges and approves. The third line, internal audit, tests that the process itself works. For AI models this structure needs cross-functional depth, because a single generative system can raise questions of data governance, security and ethics at once.
Continuous validation and monitoring
Because ML models drift, validation cannot be a one-time gate. A modern program monitors performance, data stability and outcomes continuously, and it re-validates when materiality or behavior changes rather than on a fixed schedule. This is exactly the materiality-driven posture that SR 26-2 now encourages, applied to systems that change faster than any annual cycle can track. Building this evidence trail is also what makes a system auditable.
Model risk management beyond banking
MRM began in finance, but the obligation is spreading to every sector that deploys consequential AI. Insurers use models for pricing and reserving, healthcare uses them for triage and diagnosis, and the public sector uses them for eligibility and enforcement, each with real human stakes. The EU AI Act does not care whether a high-risk model sits in a bank or a hospital: the risk management, documentation and oversight duties apply the same way. As a result, model risk management is becoming a general requirement of AI governance rather than a banking specialism, and organizations that already run a mature MRM function have a head start on compliance.
FAQ
What are the three pillars of model risk management? The three pillars come from SR 11-7: development and implementation, validation, and governance. Development covers sound design, documented assumptions and testing. Validation is independent effective challenge of a model’s conceptual soundness, monitoring and outcomes. Governance provides the policies, roles, inventory and accountability that hold the program together. SR 26-2 keeps the same logic while making the intensity of each pillar proportional to a model’s materiality. What is the difference between SR 11-7 and SR 26-2? SR 11-7 (2011) was the foundational US guidance on model risk management. SR 26-2, issued on 17 April 2026 by the Federal Reserve, OCC and FDIC, replaces it. The biggest changes are a shift from mandatory annual revalidation to risk-based oversight tied to model materiality, a narrower definition of what counts as a model, and expectations scaled to institution size. SR 26-2 also excludes generative and agentic AI from its formal scope. Does model risk management apply to generative AI? Not yet through US banking guidance, which is exactly the gap to watch. SR 26-2 leaves generative and agentic AI out of scope. In practice, organizations extend MRM principles to these systems using the EU AI Act, the NIST AI RMF and ISO/IEC 42001, which do address AI models directly. Generative systems also need controls for non-determinism, drift, opacity and prompt-based attacks that traditional validation was never built to handle. What is an example of model risk? A classic example is a credit-scoring model trained on data from a stable economy that keeps approving loans as conditions deteriorate, because its assumptions no longer hold. A modern example is a generative model that produces a confident but fabricated answer, a hallucination, which a downstream process treats as fact. In both cases the loss comes not from the model existing but from a decision made on its faulty output. How does model risk management relate to the EU AI Act? The EU AI Act turns core MRM practices into legal obligations for high-risk systems. Article 9 requires a lifecycle risk management system, Article 10 requires data governance, Annex IV requires technical documentation, Article 14 requires human oversight and Article 15 requires accuracy and robustness, all confirmed through conformity assessment under Article 43. An organization with a working MRM function already performs most of these activities and can map them to the Act rather than starting over. Who is responsible for model risk management? Responsibility is shared across three lines of defense. Model owners and developers build and document models. An independent validation or risk function challenges and approves them. Internal audit checks that the overall process works. Senior management and the board own the risk appetite and the framework itself. For AI models, this structure usually needs input from data, security and ethics functions as well, because a single system can raise all three concerns.
Conclusion
Model risk management has moved from a stable banking specialism to the connective tissue between quantitative-model discipline and AI governance. SR 26-2 modernized the US expectation, but by leaving generative and agentic AI out of scope it made one thing clear: the frameworks that govern AI models, the EU AI Act, ISO/IEC 42001 and the NIST AI RMF, now carry the weight. The organizations that come out ahead will treat these as one control set, anchored to a live model inventory that sees every model, including the ones no one registered. That is where model risk management and AI governance become the same programme. See how a registry-backed approach brings your models under AI governance control.