Category: Deployment Practices

Model Limitations and Use Restrictions

Also known as: Model Limitations, Use Restrictions

Simply put

Model limitations are the aspects of a model that make it imperfect or unreliable in certain situations, such as the conditions it was not designed to handle or the assumptions it depends on. Use restrictions are the boundaries placed on how, where, and for what purposes a model may be used, so that it is not relied upon beyond what it can properly support. Together, these help ensure a model is applied only in ways consistent with what it can actually do.

Formal definition

Model limitations refer to the intrinsic and situational constraints on a model's reliability, arising from its underlying assumptions, data, methodology, and scope of applicability; as commonly noted in modelling practice, all models have limitations, and the practically important task is identifying which limitations are material to a given use. Use restrictions are the documented conditions and prohibitions governing the acceptable application of a model, typically defining approved use cases, populations, input ranges, and boundaries beyond which model output should not be relied upon. In many model risk management practices these are treated as complementary: limitations describe what a model cannot or may not reliably do, while use restrictions operationalize those findings into constraints on deployment. Note that 'limitations' and 'restrictions' are distinct: the former characterize the model's inherent constraints, the latter are externally imposed controls on its use. The precise definitions and required documentation of both are context- and framework-dependent, and this entry does not assert a single authoritative standard.

Why it matters

Documenting model limitations and use restrictions is central to keeping a model applied within the boundaries of what it can actually support. As commonly noted in modelling practice, all models have limitations; the practically important task is not to eliminate them but to identify which limitations are material to a given use. Without that identification and the corresponding constraints on deployment, an organization risks relying on model output in conditions the model was never designed to handle—for example, applying a model to a population, input range, or economic environment outside its scope of applicability—where its reliability is unknown or degraded.

Use restrictions translate those findings into operational controls, defining approved use cases and the boundaries beyond which output should not be relied upon. This distinction matters because limitations and restrictions are not the same: limitations characterize a model's inherent constraints, while restrictions are externally imposed controls on its use. Blurring the two can lead teams to assume that merely knowing a limitation exists is sufficient, when the risk is only managed once a corresponding restriction is documented and enforced. Conversely, restrictions that are not grounded in a clear understanding of the underlying limitations may be arbitrary or miscalibrated.

Because the precise definitions and required documentation of both are context- and framework-dependent, their treatment varies across sectors and regulatory regimes. What constitutes a material limitation in a banking model risk context may differ from a general enterprise AI setting. Governance controls of this kind reduce and help manage the risk of model misuse; they do not eliminate it, and they are effective only to the extent that limitations are honestly surfaced and restrictions are actually observed in deployment.

Who it's relevant to

Model risk managers and model owners

These professionals are typically responsible for ensuring that material limitations are identified and that corresponding use restrictions are documented and enforced. The concept helps them separate what a model inherently cannot do from the externally imposed controls needed to keep it within scope, and to prioritize limitations by materiality rather than attempting to catalogue every imperfection.

Model validators

Validators assess whether a model's stated limitations are complete and accurate and whether the associated use restrictions are appropriate to those limitations. Their work depends on the ability to trace each restriction back to an underlying limitation, and on recognizing that documentation requirements are framework- and context-dependent rather than governed by a single standard.

Model users and business lines deploying models

Those who apply model output in decisions need to understand the approved use cases, populations, and input ranges, and the boundaries beyond which output should not be relied upon. For this audience, the practical risk is applying a model outside its scope of applicability without realizing that its reliability there is unknown.

Auditors and compliance reviewers

Auditors check that limitations and restrictions are documented and that restrictions are observed in practice. The distinction between inherent limitations and imposed controls is relevant to their testing, since knowing that a limitation exists is not the same as having an enforced control that manages the associated risk.

Data scientists and model developers

Developers surface limitations arising from a model's assumptions, data, methodology, and scope during development, and may build parameter constraints directly into a model's structure. Distinguishing such structural constraints from governance use restrictions on deployment helps them communicate accurately with risk and validation functions.

Inside Model Limitations and Use Restrictions

Documented Limitations

A written articulation of the conditions under which a model's outputs are known or expected to be unreliable, including boundaries of the training data, assumptions embedded in the model, and scenarios the model was not designed to address.

Approved Use Cases

An explicit statement of the purposes for which the model has been validated and authorized, typically defining the intended population, data inputs, and decision context in which the model may be relied upon.

Use Restrictions and Prohibited Uses

Constraints that specify contexts, populations, or decisions where the model must not be applied, often reflecting areas where performance is untested, where risk is judged unacceptable, or where regulatory or ethical concerns arise.

Assumptions and Data Boundaries

The conditions, ranges, and data characteristics assumed during development; outputs generated outside these boundaries (for example, out-of-distribution inputs) are commonly treated as less reliable.

Conditions Requiring Human Review or Override

Situations where model outputs should be subject to human judgment, escalation, or compensating controls rather than automated reliance, as commonly defined in model risk management practice.

Monitoring Triggers Tied to Limitations

Thresholds or indicators that signal when a model may be operating near or beyond its stated limitations, supporting ongoing monitoring and potential re-evaluation.

Common questions

Answers to the questions practitioners most commonly ask about Model Limitations and Use Restrictions.

Does documenting a model's limitations mean the associated risks have been eliminated?

No. Documenting limitations and use restrictions is a risk management and transparency measure, not a risk elimination measure. As commonly framed, identifying where a model performs poorly, the assumptions it depends on, and the conditions under which its outputs are unreliable helps stakeholders reduce and manage residual risk—it does not remove it. A model can be fully documented and still produce erroneous outputs if used outside its intended conditions.

Are model limitations and use restrictions the same thing?

They are related but distinct. A limitation typically describes an inherent weakness or boundary of the model itself—such as reduced accuracy on certain populations, sensitivity to data quality, or assumptions that may not hold. A use restriction is a control placed on how, where, or by whom the model may be applied, often derived from those limitations. In practice, restrictions are the operational response to documented limitations, and conflating the two can obscure whether a control has actually been implemented or merely noted.

Where should model limitations and use restrictions be recorded so they remain actionable?

In many frameworks, these are captured in model documentation and, where applicable, in validation reports and model inventories, so that both the developers (often first line) and independent reviewers (often second line) can reference them. To remain actionable rather than archival, limitations and restrictions are typically also reflected in operational artifacts users actually consult—such as approved-use statements, deployment configurations, or user-facing guidance—rather than only in a static technical file.

Who is typically responsible for defining and enforcing use restrictions?

Responsibilities are commonly distributed across lines of defense. Developers and model owners (frequently the first line) identify limitations and propose restrictions; independent validation or model risk functions (frequently the second line) may challenge, confirm, or expand them; and internal audit (frequently the third line) may assess whether restrictions are being observed. Enforcement usually depends on process and access controls rather than the documentation alone, so ownership for monitoring adherence should be assigned explicitly.

How can teams detect when a model is being used outside its stated restrictions?

Detection typically relies on monitoring the inputs, populations, and use cases the model actually encounters against its documented intended-use conditions. Approaches can include input distribution checks, tracking whether the deployment context matches approved scenarios, and periodic review of how outputs are being consumed downstream. Because a model may drift into unintended use gradually, ongoing monitoring is generally treated as more reliable than a one-time approval.

How often should documented limitations and use restrictions be reviewed?

There is no single universally mandated cadence, and appropriate frequency often depends on the model's risk tier, sector, and how much its operating environment changes. In many programs, review is triggered by scheduled periodic assessment as well as by events such as material changes to input data, observed performance changes, new use cases, or regulatory changes. Treating the review as event-driven in addition to calendar-driven helps ensure restrictions stay aligned with how the model is currently used.

Common misconceptions

Documenting a model's limitations and use restrictions eliminates the associated model risk.

Documentation and restrictions are risk-management measures that reduce or contain residual risk; they do not remove it. Limitations can be misunderstood, ignored in practice, or become outdated as conditions change, so they typically require ongoing monitoring and control rather than being treated as a one-time safeguard.

Stating limitations is a validation activity, so the two are interchangeable.

Documenting limitations records where a model should and should not be used, whereas validation is the independent assessment of whether the model is sound and performs as intended. Limitations may be an input to or output of validation, but recording them is not itself the act of validating the model.

Use restrictions defined for one model or context apply automatically to other deployments or jurisdictions.

Approved uses and restrictions are scoped to a specific intended purpose, data, and context. Applying the same model elsewhere generally requires reassessment, since limitations that were acceptable in one setting may not hold under different data, populations, or regulatory expectations.

Best practices

Document limitations and approved use cases in terms specific enough to guide day-to-day decisions, identifying the intended population, data inputs, and decision context rather than relying on general disclaimers.

Explicitly state prohibited or out-of-scope uses alongside approved uses, so that users understand not only where the model applies but where it must not be relied upon.

Tie stated limitations to concrete monitoring triggers and thresholds so that operation near or beyond documented boundaries can be detected and escalated.

Define the conditions that require human review, override, or compensating controls, and ensure first-line users are aware of them rather than assuming automated reliance is always appropriate.

Review and update limitations and use restrictions on a defined cadence and after material changes to data, environment, or intended use, treating them as living rather than static documentation.

Reassess and re-approve use restrictions before extending a model to new populations, contexts, or jurisdictions, rather than assuming prior approvals transfer.