Problem Framing: Stating Intended Purpose and Out of Scope Uses

Video: Problem Framing: Stating Intended Purpose and Out of Scope Uses

Every model solves a specific problem for a specific context. That framing must be explicit and recorded. The EU AI Act and most regulatory frameworks require that you state the intended purpose of an AI system upfront.

Intended purpose means the specific task the model performs, the population it applies to, the decision-making context where it will be used and the foreseeable consequences of error in that context.

Consider a credit scoring model. Its intended purpose might be: “To assess creditworthiness for unsecured personal loans under GBP 10,000, for applicants aged 21-65 with UK residential address and at least three years of credit history.” That is far more precise than simply “predict loan default.”

The specificity matters because it sets the boundary for what the model is designed to do well. If someone later tries to use the same model to predict default for business loans, or to assess creditworthiness for mortgages with much larger amounts, or for applicants with no prior credit history, those are uses outside the model’s intended purpose.

The model was not trained on such applicants and may fail in ways you did not anticipate.

Problem Framing: Stating Intended Purpose and Out of Scope Uses Concept Diagram
Figure: Conceptual architecture and workflow for Problem Framing: Stating Intended Purpose and Out of Scope Uses

Out of scope uses are foreseeable but prohibited uses of the model. You must identify them explicitly and explain why the model should not be used that way. For the credit model, out of scope uses might include using it to estimate fraud risk (a different decision), using it in fully automated decisions with no human review (when the model was designed for assisted decisions), using it for employment discrimination (illegal), or using it to deny credit to any protected characteristic.

The act of naming out of scope uses is itself a regulatory requirement. It signals that you have thought through misuse and that your organisation’s system should block or flag such uses before they happen.

Problem framing also requires you to state what success looks like in measurable terms. That is not the same as accuracy. Success might mean: “The model approves 60 percent of applicants while maintaining a loan default rate within 3 percent.”

Or: “The model identifies 85 percent of high-risk transactions while holding the false positive rate below 2 percent for each ethnic or gender subgroup.” These specific success criteria guide which metrics you optimise for during training and which you test before deployment. Without clear success criteria, you cannot evaluate whether the model should be deployed.

Recording problem framing is not a bureaucratic formality. It is the foundation for every later decision about data, metrics and validation. If you cannot articulate the intended purpose clearly, you cannot evaluate whether the data you chose is appropriate for that purpose, whether the metrics you measured are the right ones to optimise for, or whether the model is safe to deploy.

Regulators use intended purpose as the measuring stick against which they evaluate everything else you did.

In practice, this process is essential for compliance and risk management. For example, a UK-based insurance company deploying an AI model to predict claims likelihood must define its intended purpose as applying to standard home insurance policies for properties in England and Wales. An out of scope use would be applying the model to commercial property claims or to policies in Scotland, where the data and risk profiles differ significantly.

This distinction is critical in audits and regulatory reviews. A model designed for standard residential claims may not account for commercial risks, and using it inappropriately could lead to underpricing or overpricing policies, resulting in financial losses or regulatory penalties.

Organisations must also consider how their models interact with existing systems and workflows. A healthcare AI system intended to predict patient readmission rates must clearly state its intended use within a hospital’s clinical decision-making process. An out of scope use would be deploying it to make treatment recommendations without human oversight.

This is not only a regulatory concern but also a safety one. A hospital in Birmingham, for example, may have specific protocols for how AI tools are integrated into patient care. If a model is applied outside those protocols, it could lead to misdiagnosis or inappropriate treatment decisions.

Therefore, stating the intended purpose and out of scope uses helps align AI tools with organisational policies and ethical standards.

When defining success criteria, it is important to consider both performance and fairness. A model used to screen job applications must not only meet accuracy benchmarks but also ensure that it does not disproportionately exclude candidates from protected groups. For instance, a recruitment model designed to filter CVs for administrative roles must be evaluated not just on how many qualified candidates it identifies, but also on whether it treats all applicants equally.

A company in Manchester using such a model must set success criteria that include both overall performance and demographic fairness. This means that the model must not only identify the top 70% of candidates based on job-related skills, but also ensure that the selection process does not result in a disproportionate number of candidates from any protected group being rejected.

Additionally, problem framing must account for the model’s lifecycle. A model created for fraud detection in online banking must be regularly reviewed and updated to reflect changing fraud patterns. Its intended purpose must include a clause about ongoing monitoring and updates.

An out of scope use would be continuing to use an outdated model after new fraud techniques have emerged. A financial services firm in London, for example, must update its fraud detection model annually or after major fraud incidents. If the model is not updated, it may miss new patterns and become ineffective, leading to increased fraud losses and regulatory scrutiny.

Organisations should also consider how their models interact with human decision-makers. A model designed to assist in medical diagnosis must be framed as a decision-support tool, not a replacement for clinical judgment. An out of scope use would be allowing the model to make final diagnoses without human review.

A hospital in Glasgow, for instance, must ensure that any AI model used in diagnosis is clearly marked as a support tool and that all decisions are reviewed by qualified clinicians. This helps prevent over-reliance on automated systems and ensures that human oversight remains a critical part of decision-making.

Finally, problem framing must be communicated clearly to all stakeholders. This includes data scientists, compliance officers, legal teams and business leaders. A model used in customer service chatbots must have its intended purpose and out of scope uses clearly documented and shared.

A company in Edinburgh, for example, must ensure that customer service teams understand that the chatbot is intended to handle standard queries and not complex disputes. This clarity helps prevent misuse and ensures that the model is used in ways that align with its design and regulatory requirements.