What Is Model Risk Management for AI Systems?

Model risk management (MRM) for AI systems is the set of practices a financial institution uses to identify, validate, monitor, and govern the risk that an AI model produces wrong or misused outputs that lead to bad decisions.

The Federal Reserve and the OCC set out those practices on April 4, 2011, in their Supervisory Guidance on Model Risk Management, and for fifteen years U.S. banks built their model risk management frameworks around it.

On April 17, 2026, the Federal Reserve, the OCC, and the FDIC replaced it with revised interagency guidance, issued by the Fed as SR 26-2 and by the OCC as Bulletin 2026-13, and a footnote in the new guidance places generative and agentic AI outside its scope.

That footnote matters more than its size suggests. Most of the AI conversations I have with banks today are about exactly those systems: assistants that summarize loan files, copilots for contact centers, and agents that take actions inside internal tools. The guidance leaves them out, the risk stays, and each bank is expected to govern it with its own framework.

In this article, I explain what MRM requires today, where AI strains it, and how to extend it with the evidence that disciplined testing produces.

What Is Model Risk Management?¶

Model risk management is how a bank controls the chance that a model's output leads to financial loss, reporting errors, or flawed decisions. The revised guidance defines a model as a complex quantitative method that applies statistical, economic, or financial theories to turn input data into quantitative estimates. Simple spreadsheet arithmetic and deterministic rule-based software fall outside that definition.

SR 11-7 described the two ways model risk arises, and they still hold. A model can have fundamental errors and produce inaccurate model output, or it can be used incorrectly or outside its model purpose. Errors can enter at any point from design through implementation, and usage risk appears when a model is applied to products, markets, or contexts it was not built for. Financial institutions use models to calculate credit scores, identify high-risk borrowers, set prices, detect fraud, and run capital stress testing, so the associated risks can lead to significant financial losses, regulatory penalties, and reputational harm.

The guidance describes model risk through four factors:

Exposure and purpose together define materiality, which decides how rigorous oversight needs to be. Sound MRM also relies on effective challenge, the critical review by objective experts with the independence and organizational standing to change what they find wrong.

Key Elements of a Model Risk Management Framework¶

In my view, an effective model risk management framework rests on four pillars, which follow the main components of the U.S. guidance:

1. Model governance. Clear ownership, roles, and policies, a centralized model inventory that tracks every model the organization uses, and documentation that explains each one.
2. Model development. A structured process for the model development process, from data selection and underlying assumptions to testing before deployment.
3. Model validation. An independent validation process that reviews the model's design, its underlying assumptions, and model performance, and challenges the results.
4. Ongoing monitoring. Performance monitoring in production to detect data drift, drops in model accuracy, and model usage beyond its intended purpose.

Together, they cover the full model lifecycle. Lifecycle management matters because a model that was right at launch can become a source of significant risks as markets, customers, and input data change, and a framework that watches the whole lifecycle helps the organization adapt to those changes.

What Changed in 2026: From SR 11-7 to SR 26-2¶

On April 17, 2026, the Federal Reserve, the OCC, and the FDIC issued SR 26-2, Revised Guidance on Model Risk Management. It supersedes SR 11-7 (issued in 2011) and SR 21-8, the 2021 interagency statement on model risk management for bank systems that support BSA/AML compliance.

The main points banks need to know:

• A risk-based, tailored approach. Practices are expected to match each bank's model risk profile and the size and complexity of its operations.
• A clearer audience. The guidance is expected to be most relevant to banking organizations with over $30 billion in total assets, and it can still apply to smaller banks with complex models.
• Guidance, with limits. It does not set enforceable standards, so non-compliance alone does not lead to supervisory criticism. Unsafe or unsound practices in managing model risk can still trigger supervisory action.
• The same core structure. Model development and use, validation (conceptual soundness, outcomes analysis, ongoing monitoring), governance (roles, inventory, documentation), and vendor models.

Where AI Fits in SR 26-2¶

SR 26-2 covers traditional statistical and quantitative models and non-generative, non-agentic artificial intelligence (AI) models. A footnote in the guidance states that generative and agentic AI models are novel and rapidly evolving, so they are outside its scope. The same footnote adds that a bank's own risk management and governance practices should guide the controls for tools the guidance does not cover.

In practice, this splits a bank's AI portfolio in two:

When I walk a bank's leadership through this table, the three generative and agentic rows start the longest conversation. Those are the systems I see banks adopting fastest, and SR 26-2 does not say when or how they will be covered. Meanwhile, the systems with the newest and least understood risks rely on frameworks each bank builds for itself.

Why Generative and Agentic AI Strain Traditional MRM¶

Traditional MRM was designed for predictive models that learn from historical data and turn it into a number, such as a probability of default. Generative and agentic AI behave differently in ways that matter for validation:

• More than one acceptable answer. The same input can produce different outputs, so validation works with evaluation sets and acceptance thresholds rather than a single expected value.
• Outputs that are text or actions. Outcomes analysis needs graded criteria such as groundedness, accuracy, policy compliance, and safety.
• Changes without a code deployment. A new prompt, an updated knowledge base, or a new version of a vendor model can change behavior overnight.
• Third-party foundation models. Banks rarely see a foundation model's training data or weights. SR 26-2 already states that model risk management principles apply to vendor models even when the vendor does not share the underlying code, data, or methodology, and that expectation fits generative AI well. Some institutions go further: one of our clients works with an open-source model installed locally, so its information stays in a controlled environment.
• Hallucinations and data provenance. NIST's Generative AI Profile calls hallucinations confabulation, the confident production of false content, and recommends tracking where data and content come from.
• Bias in training data. Biases in training data can lead to unfair outcomes, for example in credit decisions, so bias detection becomes part of every validation.
• Model complexity. Complex models such as large language models make the model's decision making process hard to trace, even for the data scientists who built them, so machine learning models and generative AI need specific controls for explainability.
• Agents that act. When an AI agent can call tools, update records, or send messages, its permissions become part of the risk.
• Shared dependencies. One foundation model often powers many use cases. SR 26-2 describes assessing model risk in aggregate, including reliance on common assumptions, data, or methodologies, as sound practice, and a shared model is exactly that.

At Abstracta, we deal with the third point in our own work. An agent is software, so it needs tests too: in Tero, we automate them with an LLM-as-a-judge approach to confirm the agent still behaves as expected when we switch to a faster or cheaper model. A model swap that looks harmless on paper can change how an agent answers, and the evaluation suite shows it before customers do.

How to Apply Model Risk Management to AI Systems¶

The MRM toolkit still works for the AI systems the guidance leaves out. What changes is the evidence each practice needs.

Two practices deserve extra attention. Outcomes analysis depends on the quality of the evaluation data, which should include common cases, edge cases, adversarial inputs, and the scenarios regulators care about, reviewed by people who know the business. Ongoing monitoring has to watch more than model drift, because a prompt edit or a knowledge base update can change outputs as much as a new model version. For machine learning models, outcomes analysis can include back-testing, and sensitivity analysis shows how outputs react to small changes in inputs and parameters.

In practice, applying MRM to AI follows a structured process: risk identification, risk assessment, risk mitigation, and continuous monitoring. Teams assess risks before deployment with robust validation protocols, use scenario planning and stress testing to find potential risks and unintended consequences before they occur, and keep mitigating risks after every release. Proactively identifying operational risks, such as an agent with more permissions than it needs, costs far less than explaining an incident later.

Data validation matters as much as model validation. High-quality data for training and evaluation prevents errors that later affect decision making, and regular validation catches them before they reach customers.

A concrete example helps. For Akua, an API-first payments company, we built an AI agent that reads Mastercard's protocol specification and generates country-level configuration files.

We used automated evaluations across multiple AI models to compare results and choose the best option. It shortened a three-month manual process to roughly three to five days, with a 95% success rate in configuration generation. That evaluation record is the kind of evidence an MRM team can review and challenge.

How to Document AI Models for Model Risk Management¶

Documentation is where effective model risk management becomes visible to auditors, risk managers, and business leaders. It should give a detailed description of the model purpose, intended use, limitations, data, and the results of each validation. For AI systems, three formats from academic research help enhance transparency:

• Model Cards. Proposed by Margaret Mitchell and colleagues in 2019, they detail a model's intended use, evaluation results across groups, training data, and limitations.
• Datasheets for Datasets. Proposed by Timnit Gebru and colleagues, they document a dataset's motivation, composition, collection process, and recommended uses, which helps reveal data quality issues and biases before they reach the training process.
• Risk Cards. Proposed by Leon Derczynski and colleagues for language models, they document one risk at a time: who could be harmed, under which conditions, and with sample prompts and outputs.

These documents only work if they stay current, so teams should update them with every new model version, prompt change, or validation finding. Transparent documentation also strengthens accountability, because each model has a named owner and a record of its decisions.

Ethical Risks and Regulatory Compliance in AI Model Risk Management¶

For financial institutions, regulatory compliance now includes ethical risks. A credit model that treats similar applicants differently, or a generative AI assistant that gives a customer wrong information, can create regulatory, legal, and reputational harm at the same time. That is why ethical considerations such as fairness, explainability, and human oversight belong inside the model risk management framework.

Model risk management also connects with other regulatory requirements. Data protection rules such as the GDPR apply when models process personal data, and information security standards such as ISO/IEC 27001 shape how the technology platform that runs the models is protected. Bringing these regulatory guidelines into one framework avoids gaps and duplicate controls.

Frameworks That Complement MRM for AI¶

Banks building governance for generative and agentic AI do not have to start from zero. These frameworks fit alongside an MRM program:

• NIST AI Risk Management Framework. A voluntary framework released in January 2023 and currently under revision. Its Generative AI Profile (NIST AI 600-1), released in July 2024, lists risks specific to generative AI and suggested actions.
• EU AI Act. Credit scoring of individuals and risk assessment and pricing in life and health insurance are high-risk uses. After the Digital Omnibus on AI, the Council of the EU confirmed that high-risk rules for stand-alone systems apply from December 2, 2027.
• ISO/IEC 42001:2023. The international standard for AI management systems, useful to structure policies, roles, and continuous improvement.
• NAIC Model Bulletin on AI. For insurers in the U.S., the bulletin adopted in December 2023 sets expectations for how AI use is governed.

Where Testing Fits in AI Model Risk Management¶

Model risk teams decide, and they need evidence to decide well. For AI systems, most of that evidence comes from disciplined testing: evaluation datasets, automated scoring, human review of ambiguous outputs, adversarial tests, and monitoring across releases.

At Abstracta, we see this as part of Quality Intelligence, the ability to combine technical context, business rules, and expert knowledge to make better release decisions. When banks build their own AI agents, the controls MRM teams ask for can be part of how the agent is built. Tero, our open-source agent harness, gives each agent a defined job, versioned behavior, encoded permissions, human approval points, and logs of every tool call and decision. Its key capabilities for regulated teams also include deployment in the client’s own cloud and a choice of AI models, including open-source models installed locally, so the platform itself supports effective risk management.

We hold our own agents to the same rules. Across Abstracta, AI agents built on Tero save our teams more than 2,000 hours a month, and we test them and trace every conversation, tool call, and decision they make.

What I Would Do First¶

The banking industry has fifteen years of MRM discipline to build on. If I were leading model risk at a bank today, I would start with three moves before the next AI release:

1. Inventory every AI use case, including the generative AI tools teams adopted on their own.
2. Tier them by materiality and pick the two with the most weight on credit, compliance, or customers.
3. Set acceptance criteria and build evaluation sets for those two, with the business experts who know what a good answer looks like.

That gives your MRM program a working pattern for generative AI and agents, built on evidence your validators can challenge, and it improves decision making across the business. To go deeper into the testing side, read our guide on how to test AI models and my article on how to validate AI models in regulated industries.