Risk · R-080 · Model Performance & Reliability
Poor generalisation outside training conditions
The model meets inputs unlike its training data and fails, without signalling that it is outside its competence.
- Severity
- High
- Audience
- Heads-of · Practitioner
- Frameworks
- Article 15 · MEASURE 2 · Principle 3
- Responsible AI domain
- Lifecycle stage
- Reviewed
- 2026-11-10
What it is
A model interpolates within what it has seen. Asked about something different, it still answers, and the answer may be arbitrary. The difference from drift is that this is about individual inputs at any time, including the first day: the rare case, the new product, the customer who fits no pattern. An overfitted model, tuned too closely to its training data, generalises worst.
How it happens
- An input falls outside the ranges present in training.
- A combination of ordinary values occurs that the model never met.
- The format or quality of an input differs, such as a poor scan or an unfamiliar dialect.
- The model was fitted too closely to incidental features of its training set.
Why it matters
Unusual cases are often the important ones: the large transaction, the vulnerable customer, the edge of policy. A model that fails silently there concentrates its errors where they cost most.
Warning signs
- No test covers inputs at or beyond the edges of the training data.
- The system has no means of declining or referring a case.
- Errors cluster in small or new segments.
- Training accuracy is far above test accuracy.
Who owns it
The model owner is accountable for knowing the model's limits. Engineering implements detection of unfamiliar inputs and referral. The business owner decides what happens to referred cases.
In practice
A property valuation model trained on suburban sales is used for a remortgage on a listed building in a remote area. It returns a figure with the same confidence as any other. The same pattern generalises to any model applied to cases outside the range it learned from.
Mitigating controls
Primary controls
- Drift and performance monitoring Detective
- Detects inputs unlike the training data. Input distributions and output quality are measured in production against thresholds that trigger investigation, retraining or withdrawal.
- Pre-deployment testing and acceptance Preventive
- Tests behaviour on out-of-range and edge cases before release. Functional, safety, security and user tests defined in advance must pass, with results recorded, before an AI system is released.
Supporting controls
- Adversarial robustness testing Preventive
- Robustness testing covers perturbed inputs. A defined battery of adversarial tests is run against an AI system before release and after every material change, and release depends on the results.
Compensating controls
- Fallback and manual workaround Corrective
- Where the model cannot be made robust, hands off the cases it should not decide. A tested alternative, such as a manual process, a simpler model or a degraded mode, is ready to take over when an AI component fails or has to be withdrawn.
Framework and clause references
| Framework | Clause | Title |
|---|---|---|
| EU AI Act | Article 15 | Accuracy, robustness and cybersecurity Robustness. |
| NIST AI Risk Management Framework (AI RMF 1.0) | MEASURE 2 | Systems are evaluated for trustworthy characteristics Evaluation of robustness. |
| SS1/23: Model Risk Management Principles for Banks | Principle 3 | Model development, implementation and use Use within tested limits. |
Sources
- EU AI Act: Regulation (EU) 2024/1689 European Union (EUR-Lex) · official text
- SS1/23: Model Risk Management Principles for Banks Bank of England PRA · official text
- NIST AI Risk Management Framework (AI RMF 1.0) NIST · framework
Related terms
How to cite
Axiom Verity (2026). Poor generalisation outside training conditions. Reference Library, R-080. https://axiom-verity.com/risks/poor-generalisation-outside-training-conditions. Reviewed 2026-11-10.
Found an error or a better source? Report a correction.