Intended Use Statement

A model is validated on one population for one decision. It is then reused, usually by a different team, for an adjacent decision on a different population — and nothing in the artefact says that this is out of scope, because the artefact describes architecture and metrics.

The intended use statement is the part of the documentation that constrains deployment, and it is the section technical write-ups most often omit. The model card format published by Mitchell and colleagues in 2019 put it first for that reason.

It has two halves, and the second is the one that does the work: what the model is for, and what it is explicitly not for.

Why it matters

Misuse is more common than malfunction. A churn model reused for pricing, a fraud score reused for account closure, a model trained on one country's applicants applied to another: each is a correct model producing damaging output, and each is invisible to monitoring because the model is behaving exactly as it did in validation.

It also matters for obligation. Under the EU AI Act, in force since 1 August 2024 with most high-risk obligations applying from 2 August 2026, the tier that attaches to a system depends on what it is used for, so a documented intended use is part of what determines which rules apply.

Implementation patterns

• Write both halves, and make the out-of-scope list concrete: populations, decisions, geographies, thresholds. "Not validated for applicants under 21" is usable; "use responsibly" is not.
• Bind it to the serving path. The statement is enforceable if the model is served through a gateway that knows which consumer is calling and what they declared it for.
• Name the validated population explicitly, including its time window, because population drift makes a two-year-old validation a statement about a different population.
• Version the statement with the model and require re-approval when a new consumer appears, which is the moment most misuse begins.
• Record the decision threshold and who owns it. Most reuse harms come from a different threshold rather than a different model.

Industry example

Public model cards from major model providers and hub platforms have carried intended-use and limitation sections since the format spread from the 2019 paper through the Hugging Face model card template. The practice migrated into regulation: sectoral model risk guidance for banks had already required documented model purpose and limitations for years, and the AI Act generalises the same requirement to high-risk systems. The convergence is the point — supervisors of very different industries independently arrived at "say what it is for" as the first control.

Failure scenarios

• Silent reuse by a second team who found the endpoint and assumed it applied to their case.
• A statement written after deployment to satisfy a reviewer, which describes what is happening rather than constraining it.
• A validated population that has drifted, so the statement is technically accurate and practically wrong.
• Out-of-scope uses phrased as advice, which no gateway can enforce and no reviewer can test.
• A threshold changed by a consumer without revalidation — moving a cutoff from 0.6 to 0.7 can shift the approval rate by 5% or more, turning a calibrated score into a different decision.

Trade-offs

A narrow statement constrains the model's value and forces revalidation every time someone finds a new use; a broad one is cheap to write and protects nobody. The honest position is that the statement's usefulness is proportional to how uncomfortable it is to write, and the discomfort lands on the team that owns the model rather than on the one that wants to reuse it.

When not to use it

For a model with a single consumer inside one team, on a low-consequence decision, a one-line scope note is proportionate and the full apparatus is ceremony. The weight should follow consequence and audience, not technical sophistication: a rules engine deciding benefit eligibility needs a careful statement, and a large model ranking internal search results does not.

Interview question

Q: A team wants to reuse an existing credit-risk model for a new product aimed at a younger customer segment. The model's documentation says it was validated on the existing portfolio. What do you require before this goes live, and what do you tell the product owner about timelines?

What a strong answer covers: the population difference as the central risk rather than model quality; requiring performance disaggregated on the new segment before deployment, not after; threshold recalibration as a separate decision with its own owner; a monitoring plan that disaggregates by segment so drift in the new one is visible; an updated intended-use statement covering both populations; and being direct with the product owner that the validation work has a lead time, because the alternative is shipping and discovering the gap through complaints.

Quick check

Quiz: Which half of an intended use statement does the real work? — The out-of-scope half: what the model must not be used for, stated concretely enough to test.

Flashcard: What is the most common way a well-built model causes harm? — Reuse outside its validated population or decision, where the model behaves exactly as validated and the outcome is still wrong.