How should organisations determine whether a credit scoring model falls under the EU AI Act high-risk rules?

When a credit scoring model becomes high-risk under the EU AI Act

Credit scoring sits close to a regulated decision boundary because it can determine whether a person gets access to loans, credit products, or different pricing terms. Under the eu ai act, the key question is not whether the model is branded as “AI” in marketing or owned by a data science team, but whether it assesses a natural person’s creditworthiness or materially influences a lending decision. That is why the same model may be low concern in one workflow and in scope in another. The EU AI Act regulatory framework makes this distinction part of the legal test rather than a matter of internal terminology. In practice, many security and compliance teams encounter scope issues only after a model has already been embedded into underwriting or pre-screening workflows, rather than through an intentional classification exercise.

How organisations should test the real decision path

The practical test is to trace what the model actually does in the business process. A model may be used as a direct score, a risk band, an approval flag, a referral trigger, or a feature within a broader decision engine. If the output helps determine credit eligibility, price, limit, or routing to manual review, it may still fall within the high-risk logic even when a human underwriter has the final sign-off. The relevant question is whether the model materially informs the decision about a natural person, not whether a person signs the last step.

That means organisations should document the decision chain from input data to business outcome. They should identify whether the model is used for eligibility, ranking, triage, or exception handling, and whether the output can be overridden in a meaningful way or is effectively decisive. If the model is only used for fraud analytics, portfolio reporting, or generic operational forecasting, the classification may differ. The same is true where the model supports a corporate lending process without assessing an individual natural person.

• Map the model to the exact decision it supports, not the team that built it.
• Check whether the output affects access, pricing, terms, or approval path.
• Separate descriptive analytics from models that influence lending outcomes.
• Record whether human review is substantive or mostly procedural.

Organisations should also be careful about model decomposition. A vendor score, a rules layer, and an internal override process can together create a lending decision even if none looks high-risk in isolation. The guidance becomes weaker where the model is used outside a consumer-credit context, where the decision does not concern a natural person, or where the output is too remote from the final lending outcome to be material.

Borderline credit models, outsourced scoring, and mixed-use cases

Tighter scope analysis often increases governance overhead, requiring organisations to balance faster model deployment against a more defensible classification record. That is especially true where a single scoring service is reused across product lines, geographies, or channels. The difficult cases are usually not the obvious consumer lending models, but shared models that support both underwriting and adjacent functions such as collections, portfolio segmentation, or account management.

Where the same model serves multiple purposes, organisations should classify it by its most consequential use case, not by its most convenient label. If one deployment route materially informs a lending decision, the model may need to be treated as high-risk even if other uses are non-credit. This is also where vendor contracts can mislead teams: an external supplier’s assurance that a tool is “decision support only” does not override how the model is actually used in the organisation’s process.

Another edge case is credit scoring augmented by explainability or policy rules. Adding interpretability does not remove scope if the underlying model still assesses creditworthiness. Likewise, a human reviewer does not automatically break the chain if the reviewer mainly rubber-stamps a recommendation. The safer approach is to test the operational reality of the workflow, not the design intent on a slide deck. In practice, many organisations discover the need for reclassification only after a shared scoring model has already been reused across products and the decision path has become harder to untangle.

Practitioner Guidance

What to prioritise: Treat decision mapping as the first control, because scope depends on how the model is used rather than how it is named internally. The most reliable evidence is the actual workflow, including where the score enters underwriting, triage, pricing, or exception handling.

What to verify: Confirm whether the model assesses a natural person’s creditworthiness or materially shapes a lending outcome. If the answer is yes, document the rationale, the decision owner, and the points where the model can influence the result even if a human remains in the loop.

Common mistake: Assuming that manual review, vendor branding, or internal team ownership removes high-risk exposure. That shortcut fails when the model output still meaningfully affects the credit decision.

Practitioner takeaway: The decisive question is not who presses the final approval button, but whether the model is functionally part of the credit decision chain.

Related resources from NHI Mgmt Group

• How should teams implement high-risk AI model evaluation under the EU AI Act?
• When do AI systems move into high-risk territory under the EU AI Act?
• How should security teams implement continuous AI security testing for high-risk systems under the EU AI Act?
• What is the difference between transparency controls and high-risk AI controls under the EU AI Act?