High-risk classification under the AI rules: what to do in the first ten days comes down to three moves: freeze further rollout of the system, map every actor that touches it in the chain, and open the conformity file before anyone questions the classification. Obligations attach the moment the criteria are met, not when a regulator confirms it in writing.
Who this concerns
This concerns any Swedish or foreign-parented company that provides, deploys or imports a system falling into one of the high-risk categories: workforce and recruitment tools, credit and insurance scoring, safety components in regulated products, biometric identification, and the handful of adjacent use cases the regime covers. It also concerns anyone downstream who integrates such a system into a larger product without checking whether the original classification still holds for the combined use.
The trigger is rarely a formal notice. More often a customer's procurement team asks for the conformity file, or a new compliance hire reviews the AI inventory and asks a question nobody had asked before. By then the system has usually been in production for months, and that gap, not the classification itself, is the real exposure.
It is also rarely the legal function that raises the flag first. Product and engineering teams tend to notice the operational friction, an oversight step that slows a release, a data request they cannot fully answer, well before anyone frames it as a compliance question. Whoever spots it first should escalate it as a classification question immediately, not as a product bug to be quietly worked around.
Read alongside the compliance, sanctions and cyber practice overview, this material covers what changes once the classification stops being provisional.
What the law says
Under Swedish law as it currently stands, a system meeting the criteria for high-risk classification carries a defined set of obligations that apply whether or not the provider has formally accepted the classification. The set typically includes a documented risk management process, technical documentation kept current with each material change, logging sufficient to reconstruct how a given output was produced, human oversight built into the actual workflow rather than added afterwards, and, before the system reaches the market or is put into service, a conformity assessment matched to its category.
None of this is satisfied by a policy document describing intent. The assessment looks at what the system does in production, not at what a deployment plan says it should do. That gap between the written control and the operational reality is exactly where a classification gets challenged later, whether by a regulator, an insurer, or a counterparty's own diligence team.
How it works in practice
Day one: stop the clock on new rollouts
Freeze any expansion of the system to new use cases, customers or jurisdictions until the classification question is settled. This is a pause, not a shutdown. Continuing to expand during this window is the most common reason the eventual file looks assembled after the fact rather than maintained as the system grew.
Days two to four: fix who is what in the chain
Obligations attach differently depending on whether the organisation is the provider, the deployer, or an importer bringing a third-country system into the EU market under its own name. Groups often find that the entity holding the customer contract is not the entity controlling the model, and the two have never agreed which carries which obligation. Fix that allocation before anything else; it determines who signs the conformity declaration.
Days five and six: sketch the technical file
The file does not need to be complete by day six, but its structure does: intended purpose and foreseeable misuse, risk management measures already in place, data governance for any training data still under the organisation's control, and how human oversight actually operates, not how it was specified on paper. Gaps found now are manageable; gaps found in an external audit are not.
Days seven and eight: pick the conformity route
Depending on the category, the assessment is either an internal self-assessment or one requiring a third-party notified body. Assuming self-assessment is available when it is not tends to surface only when a customer's compliance team asks for a certificate that does not exist. Confirm the applicable route in writing before booking any external resource.
Day nine: brief the board and any foreign parent
Where the group's parent sits outside Sweden, the classification rarely stays purely operational. A parent's risk committee, insurer or lender covenants may treat it as a disclosable event, and the Swedish entity is usually the only one with direct visibility into how the system actually runs. Decide who briefs whom and when, because a parent that hears about this from a customer complaint tends to respond by centralising control that the local team then has to unwind. The same check applies to any vendor or supplier sitting outside the EU: the contractual chain back to that vendor, and any cross-border data flow the system depends on, needs reviewing now, not after a warranty claim.
Day ten: lock the record
By day ten, there should be one internal document stating the classification decision, the reasoning, each entity's role, and the current state of the file. This is not the conformity assessment itself; it is the record that the decision was made deliberately, on a given date, on the facts available then. A classification that later proves wrong is defensible if the process was sound. One that was never actually decided, only assumed, is not.
What to check before this window closes
- Whether the system's current actual use matches what was originally assessed, not what the sales material describes.
- Whether any group entity outside Sweden has reached a different classification for the same system.
- Whether the vendor contract allocates responsibility for conformity documentation, or is silent on it.
- Whether the person exercising human oversight has the authority to override the output, not just log it.
- Whether the technical file reflects the version currently in production, not an earlier one.
Does a high-risk classification change who signs off on an AI-related acquisition?
Yes, in practice. Where the target's system meets the high-risk criteria, due diligence decision rights tend to shift toward whoever can read the conformity file and the provider or deployer split, not only the commercial or IP team. Missing that allocation before signing is a common way a deal's risk profile ends up understated.
If the group's parent sits outside Sweden, who is liable for a wrong classification?
Liability generally follows the entity that made the operational decision, usually the Swedish deployer, unless the parent directly controlled the call. Jurisdiction for a dispute typically follows where the harmful use occurred rather than where the group is headquartered, though internal group agreements can shift practical exposure without changing where a claim is filed.
Can a limitation of liability clause cap exposure from a high-risk AI system?
It can cap contractual exposure between the parties to that specific contract, but it does not touch regulatory obligations or third-party claims tied to the classification. Where the clause conflicts with a mandatory obligation the classification creates, the obligation is the part that survives, not the clause.
The numbers
The ten-day window here is a planning device, not a statutory deadline. Nothing in the current regime sets a fixed number of days between a system meeting the criteria and the organisation completing its response; the obligations run continuously from the moment the criteria are met. Ten days is enough time to complete the steps above without letting the system drift further into production while the position stays unresolved.
What varies considerably is what the eventual conformity work costs. The largest driver is not the assessment itself but how much of the technical file already exists in usable form. An organisation that has kept design records, version history and oversight logs current from the start spends most of its effort on the assessment. One reconstructing that history from emails after the fact spends most of its effort on reconstruction, and the assessment becomes the smaller part of the bill. Where the file is largely built already, effort concentrates on confirming and formalising it; where it is not, effort concentrates on correction, and the second scenario is materially heavier in almost every case of this kind.
The second driver is how many entities in the group need to agree on the classification before any external work starts. A single-entity provider resolves this internally. A group with a foreign parent, a separate deployer entity and a third-country vendor is coordinating three or four positions that all need to align first, and that coordination cost rarely shows up in the initial estimate.
Where it usually goes wrong
Self-declaration is not the same as classification. Some organisations conclude, on an internal read of the criteria, that the system falls just outside the high-risk category, without writing down why, and treat that as final. The position holds only until someone with an incentive to disagree, a competitor, a disappointed customer, a regulator responding to a complaint, looks at the same facts and reaches the opposite conclusion. Without a documented basis for the original call, there is nothing to defend it with.
Human oversight is often treated as a checkbox rather than a control. Naming a person to review the output satisfies the requirement only if that person has both the information and the authority to actually change the outcome. Where the reviewer sees a summary dashboard several steps removed from the actual decision, or has no practical way to override it, the requirement is not met even though a name sits on a policy document.
A provider or deployer split creates a specific failure pattern: each entity assumes the other is handling the conformity file, and neither actually is. This surfaces at the worst moment, usually when a customer's diligence team asks a direct question neither entity can answer alone.
A classification made for one version of the system does not carry over automatically to the next version. A material update to the model, the training data, or the intended use resets the analysis. Treating an earlier classification as still valid after a substantive change is one of the more common ways an otherwise careful process becomes indefensible. The same applies when the system is repurposed for a market or a customer segment it was not originally assessed against; the classification travels with the use, not with the code.
What to do next
The steps above cover what a compliance or legal team can complete without outside counsel: freezing rollout, fixing roles, sketching the file, locking the record. Where this stops being an internal task is the point where the classification itself, or the split of obligations between group entities, needs an independent read before it is relied on in front of a customer, an insurer or a regulator.
Where the same system also touches network and information security obligations, this scoping question is often run alongside a NIS2 scoping and registration assessment, since both exercises draw on the same technical file.
Where the internal work is done and the open question is whether the classification will hold up under scrutiny, get in touch to have that position assessed before someone outside the organisation tests it.