High-risk classification under the AI rules: step by step means five decision points, not one: scope, risk-tier test, documentation, technical and organisational measures, and registration where it applies. Each step has a deadline and a consequence for missing it, and the most common failure sits in the documentation step, not in the classification itself.
Who this concerns
The classification exercise is run by three different actors, and each carries a different obligation. Providers, the organisations that build or substantially modify a system, run the primary test before placing it on the market. Deployers, the organisations that put a system into use inside their own operations, carry an independent duty to verify that classification before relying on it. They cannot simply adopt the provider's label without checking it against their own use case. Importers and distributors sit in between, and their obligations shift depending on whether they modify the system before it reaches the end user.
In practice, the organisations that raise this question with Lodline's compliance, sanctions and cyber practice are rarely the ones that built the system. They are banks and insurers running vendor-supplied credit-scoring tools, HR functions using third-party recruitment screening software, and group compliance teams trying to work out whether a system rolled out from a parent company abroad has already been classified correctly, or classified at all.
This concerns any organisation that deploys, resells or integrates a system touching employment decisions, access to credit or insurance, biometric identification, or evaluation of people in a way that affects their access to a service. It does not concern purely internal tools with no effect on a third party's rights, and it does not concern systems still confined to research or testing environments.
What the law says
Under EU law as it currently stands, the classification test has two layers. The first layer is a fixed list of use cases the regulation treats as high-risk by definition: biometric identification, access to essential services such as credit and insurance, employment-related screening and evaluation, and a small number of other categories tied to safety or fundamental rights. If a system's intended purpose falls inside one of these categories, the classification is not a judgment call. It is a lookup.
The second layer is a risk-based test for systems that sit outside the fixed list but produce a comparable effect on health, safety or fundamental rights. This is the layer that generates most of the disputed classifications, because it requires an assessment of the system's actual function rather than its marketing description. A tool sold as "decision support" can still land in the high-risk category if its output is, in practice, determinative of the outcome for the person it affects.
Liability for getting the classification wrong does not sit only with the provider. A deployer that puts an unclassified or wrongly classified system into use, and knew or should have known about the deficiency, carries independent exposure. That is the detail that turns a technical exercise into a governance question for the deploying organisation's own legal function, not just its IT function.
Foreign element. When the provider is established outside the EU, the classification obligation travels with the system rather than staying behind with the foreign entity. Whoever places the system on the EU market, typically an EU-based importer or an authorised representative appointed for that purpose, inherits the documentation duty and the exposure that comes with getting it wrong. For a Swedish deployer using a system built by a non-EU parent or vendor, this means the classification file the group holds centrally may not be sufficient on its own. The Swedish entity should confirm who inside the group is treated as the EU-facing provider for that specific system before relying on any classification decision made abroad.
How it works in practice
Step 1: Map the use case, not the technology
The first step is to describe what the system actually decides or influences for a real person, stripped of vendor language. A recruitment tool that "ranks candidates" and one that "screens out unqualified applicants" can be the same product with different framing, and the framing is not what the classification test looks at. Write the use case in one sentence: who is affected, what decision the output feeds into, and whether a human can meaningfully override it.
Step 2: Check the fixed list before running any risk analysis
Before assessing risk, check whether the use case already sits on the fixed list. This step is often skipped because teams move straight to a qualitative risk discussion when a five-minute lookup would have settled the question. Employment screening, credit and insurance access, and biometric identification are the categories most frequently missed because the system in question is described internally as an "efficiency tool" rather than by its actual function.
Step 3: Run the risk-tier test where the use case is not on the fixed list
Where the use case is not on the fixed list, the test shifts to the system's practical effect on health, safety or fundamental rights. This step should be documented as a reasoned assessment, not a checkbox. It should identify what could go wrong if the system's output is incorrect, who bears that consequence, and whether existing human oversight is capable of catching the error before it causes harm.
Step 4: Write the classification decision down before deployment
The classification decision itself, including the reasoning and the date it was made, needs to exist as a document before the system goes live, not reconstructed afterwards. This document is the single most frequently missing item when a supervisory authority or an internal audit asks for it. A verbal conclusion reached in a project meeting does not satisfy this step.
Step 5: Put the required controls in place before go-live
Once a system is classified as high-risk, a set of technical and organisational measures attaches to it: risk management, data governance, human oversight, logging, and, depending on the category, conformity documentation. These measures need to exist at the point the system enters use, not on a remediation timeline drawn up after a regulator asks questions.
Step 6: Register or notify where the category requires it
Certain high-risk categories carry a registration or notification duty to a national or EU-level database before the system is put into service. Where this applies, it is a discrete administrative step with its own timing, separate from the classification decision itself, and it is frequently the step that gets forgotten once the internal risk assessment is signed off.
Step 7: Re-run the test whenever the system or its use changes
A classification is tied to a specific use case and a specific version of the system. A material change, retraining on new data, a new deployment context, or an expansion of the population it affects, requires the test to be run again. Organisations that treat classification as a one-off exercise at procurement stage are the ones most exposed when the system's use quietly expands over time.
What to check before relying on an existing classification:
- Whether the classification document names the specific use case actually deployed, not a generic description of the product
- Whether the date on the classification predates or postdates the current version of the system in production
- Whether the deployer, not just the provider, has a copy of the classification reasoning on file
- Whether the human oversight measure described in the documentation is the one actually in place operationally
- Whether any registration or notification step that applies to the category has in fact been completed, and by which entity
- Whether the classification was made by an entity that is legally the EU-facing provider, where the underlying system was built outside the EU
How do you determine whether an AI system qualifies as high-risk?
You start by describing the system's actual decision-making effect on a person, then check that description against the fixed list of regulated use cases. If it is not on the fixed list, you run the risk-based test on the system's practical effect on health, safety or fundamental rights, and document the reasoning either way.
What happens if a system is misclassified as high-risk?
A deployer that knew or should have known a system was wrongly classified, or left unclassified, carries independent exposure regardless of what the provider stated. Correcting a misclassification means re-running the test, documenting the corrected outcome, and putting in place any control that was missing under the correct category, from that point forward.
Can a provider self-certify a high-risk system, or does it always need external assessment?
Whether external assessment is required depends on the specific high-risk category the system falls into, not on a general rule for all high-risk systems. Some categories allow the provider's own conformity assessment; others require involvement of an external body. This is precisely the kind of category-specific detail that should be checked against the current text of the regulation before a self-certification decision is finalised.
The numbers
The figures that matter here are not fixed amounts, they are variables tied to the category and the timeline. The compliance deadline for a given obligation depends on the transitional schedule attached to the regulation and on the point at which the specific system was placed on the market or put into service, so a deadline calculated for one system in a group cannot simply be applied to another system acquired at a different time.
The financial exposure for getting classification wrong is tiered, and the tier depends on the nature of the infringement rather than on the size of the organisation alone. The applicable percentage and the turnover base it is measured against are set out in the regulation itself and should be checked against the current text for the specific category in question rather than assumed from a general impression of "AI Act fines."
Where a norm, a deadline or a threshold figure is not confirmed against the current text of the applicable rules, it is not stated here as a number. That is a deliberate omission, not an oversight, because a wrong number in a classification file is worse than an acknowledged gap.
Where it usually goes wrong
The classification breaks down at the boundary between "not yet high-risk" and "high-risk because of a small change." A system procured for internal testing that quietly moves into production without a fresh classification run is the single most common failure pattern in group structures. The classification was correct on the day it was made and wrong on the day the use case expanded.
It also breaks down where the deployer assumes the provider's classification is final and does not verify it against its own actual use case. A system can be correctly classified as not high-risk for the provider's intended general purpose and still be high-risk for a specific deployer's narrower application of it. The obligation to check does not transfer away simply because a vendor's documentation looks complete.
Group structures create a distinct failure mode: the entity legally responsible for the classification is not the entity operating in Sweden, and the Swedish entity holds no copy of the underlying reasoning, only the vendor's marketing summary. When a Swedish regulator or a counterparty in due diligence asks for the classification file, "it exists somewhere in the group" is not an answer that holds up.
Finally, contracts that push classification responsibility onto the customer without giving the customer the technical access needed to actually verify the classification create a gap that neither party is positioned to close. If your organisation is already managing ICT risk under a separate regulatory framework, for example the ICT risk-management obligations that apply to financial entities, that existing governance structure is usually the right place to fold AI classification controls into, rather than building a parallel process from scratch.
What documentation must be kept once a system is classified as high-risk?
At minimum, the classification reasoning itself, the date and version of the system it was run against, the technical and organisational measures put in place as a result, and evidence of any registration or notification completed. This file needs to be held by the deploying entity, not only by the provider, and it needs to be updated whenever the system or its use case changes materially.
What to do next
Steps 1 to 6 above are work your own team can do without external input: mapping the use case honestly, checking it against the fixed list, and writing the reasoning down. Where the self-directed work usually stops is the risk-tier test for a use case that does not sit cleanly on the fixed list, and the question of which entity in a group structure is legally the EU-facing provider once a foreign parent is involved. Both of those points benefit from a second read before a classification decision is relied on operationally.
If your organisation is at that point, book a preliminary assessment of the specific system in question. A preliminary assessment is scoped to the classification question itself, before any wider compliance programme is discussed.