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
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

FrameworkClauseTitle
EU AI ActArticle 15Accuracy, robustness and cybersecurity Robustness.
NIST AI Risk Management Framework (AI RMF 1.0)MEASURE 2Systems are evaluated for trustworthy characteristics Evaluation of robustness.
SS1/23: Model Risk Management Principles for BanksPrinciple 3Model 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

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.