The Model Risk Frame You Already Have
Model Risk Was Defined Long Before AI
Model risk is conventionally defined as the potential for adverse consequences from decisions based on incorrect or misused model output, and it has two sources: the model may be fundamentally wrong, or it may be sound but used outside the purpose it was built for. The second source causes more damage in practice than the first. Supervisory guidance in US banking sets expectations across three areas — robust development, implementation and use; effective independent validation; and governance, policies and controls that make the first two happen. The UK prudential regulator has published its own model risk management principles for banks, and comparable expectations appear in other jurisdictions. This frame is older than the current technology and it is where AI features land.
- Two sources of model risk: the model is wrong, or it is right and used outside its intended purpose
- Misuse outside intended purpose is the more common and more expensive failure of the two
- The frame has three parts: development and use, independent validation, and governance and controls
- US banking supervision and the UK prudential regulator both set model risk expectations; other regimes mirror them
Independent Validation and Effective Challenge
Validation is not testing performed by the team that built the model. It is a separate exercise carried out by people with the competence, the standing and the incentives to say no — the quality usually described as effective challenge. It covers conceptual soundness, meaning the design and assumptions make sense for the intended use; ongoing monitoring, meaning performance is tracked against thresholds after deployment; and outcomes analysis, meaning results are compared against realised outcomes and sensible benchmarks. Challenge fails quietly when the validator reports to the model owner, is under-resourced, or arrives after the launch date has been announced publicly — which is to say that most validation failures are organisational rather than technical.
- Validation is independent of development, with authority and standing to reject the model
- Three components: conceptual soundness, ongoing monitoring, and outcomes analysis against benchmarks
- Effective challenge requires competence and incentive — one without the other produces a rubber stamp
- A launch date announced before validation completes has already decided the validation outcome
Where AI Features Strain the Frame
The frame holds, but several of its assumptions break. There is often no single realised outcome to backtest a text output against. The input is a prompt and a retrieved corpus, both of which are part of the model whether or not anyone documented them that way. Outputs may vary between identical runs. The population the system sees has no stable definition. And the provider controls the weights, so the model can change without a release on your side. Firms also argue about whether an LLM feature is a model at all under their own policy. The answer that survives supervision is to bring it into scope explicitly, tier it by materiality, and adapt the validation techniques rather than skip the validation. Does Your AI Actually Work? covers how those evaluation sets get built.
- No single realised outcome to backtest against, and no stable population definition
- The prompt and the retrieval corpus are part of the model and belong in its documentation
- Identical inputs may produce different outputs, which breaks conventional reproducibility tests
- Bring it into scope and tier it by materiality — arguing it is not a model is the answer that fails
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.