Risk classification under the EU AI Act: step by step
How to classify your AI systems under the EU AI Act: provider or deployer, the four risk levels, the Article 6(3) exemption, and what each category requires.
Risk classification is the first step toward EU AI Act compliance, and it is where most Swedish SMBs get stuck. Our guide to the EU AI Act for businesses covered the overview: the four categories, deadlines and penalties. This article goes deeper and gives you a concrete, step-by-step method to classify every AI system you use. We start with the question most people skip, work through the levels in the right order, and explain the Article 6(3) exemption that actually decides whether a system is high-risk. All under Regulation (EU) 2024/1689.
What does risk classification under the EU AI Act mean?
Risk classification under the EU AI Act means placing every AI system into one of four levels (prohibited, high-risk, limited risk, minimal risk) while also deciding whether it is a general-purpose AI model. The level decides which requirements apply and who is responsible.
The logic is hierarchical. You test a system against the strictest level first and work downward. A system can only land in one level, but a general-purpose AI model (GPAI) follows its own track alongside the ladder. The full regulation is available at EUR-Lex in 23 languages.
One thing to understand up front: the Digital Omnibus proposal from 7 May 2026 does not change the classification itself. What is moving in 2026 is timelines and guidance, not the ladder. Articles 5, 6, 50 and 51 stand unchanged. That means the classification work you do now holds even if deadlines shift. For deadlines and penalties in detail, see our EU AI Act guide.
Why start with classification? Because it governs everything else. Which documentation you need, whether the system must be registered, which transparency rules apply and how much risk you carry all follow from the level a system lands in and the role you have. Classify wrong at the start and you either build documentation needlessly or miss requirements that genuinely apply. For most Swedish SMBs the majority of systems land in the two lowest levels, but you cannot know that without going through each system. It is a couple of hours of work for a typical business, and it pays for itself many times over.
Step 0: are you the provider or the deployer of the system?
Before you classify the risk level you have to settle your role, because the role decides which obligations the classification triggers. A provider develops an AI system or places it on the market under its own name. A deployer uses a system in its professional activity. Most SMBs are deployers.
The difference matters. If you buy a finished AI service as SaaS you are almost always a deployer, and the heavy documentation requirements sit with the provider. If you build your own model, or resell someone else's AI under your own brand, you become a provider and inherit the provider's full responsibility.
A common pitfall concerns general-purpose models. Integrating a GPAI model such as ChatGPT or Claude does not automatically make you the provider of the model. But if you substantially fine-tune it you can be classed as a provider. The European Commission's GPAI guidance uses a rule of thumb around one third of the original training compute as the marker for when responsibility shifts.
Write down for every system: are we the provider or the deployer here? You need that answer in every later step.
Step 1: is the system prohibited under Article 5?
The first risk test is the hardest. Article 5 lists eight prohibited AI practices that have applied since 2 February 2025. If your system matches one of them it is prohibited, regardless of your role, and use must stop.
Two prohibitions are especially relevant for Swedish SMBs. The first is manipulative techniques that exploit psychological vulnerabilities, for example sales psychology aimed at vulnerable groups. The second is emotion recognition in the workplace, meaning AI that reads employees' mood through camera or voice. Both are off limits no matter how well they work technically.
The rest of Article 5 covers social scoring, untargeted facial scraping and biometric categorisation of sensitive traits. Most SMBs never touch these areas, but it takes two minutes to confirm and should be your clear no-go zone when you evaluate new vendors.
A note on 2026: the Digital Omnibus draft proposes new prohibitions (among them AI tools for creating abuse material), with a provisional deadline in December 2026. The proposal is not yet formally adopted, so treat it as a signal, not current law.
Step 2: does the system count as high-risk under Article 6?
If the system is not prohibited, the next question is whether it is high-risk. Article 6 points out two routes into the category: the system is a safety component in a product that is already regulated (Annex I, for example machinery or medical devices), or it is used in one of the eight areas in Annex III.
Annex III lists the eight high-risk areas: biometrics, critical infrastructure, education, employment and recruitment, access to essential services (including credit assessment and insurance), law enforcement, migration, and the administration of justice and democratic processes.
Two areas are most common for Swedish SMBs. Recruitment AI that filters applications or ranks candidates falls under employment. Credit assessment and risk pricing in insurance fall under essential services. Fraud detection is explicitly excluded from the credit point. If you use AI in either of these ways, the starting point is high-risk, and then you need to move to the next step before drawing a conclusion.
Step 3: does the Article 6(3) exemption apply?
This is the nuance most people miss. Even if a system falls within Annex III it is not high-risk if it does not pose a significant risk to the health, safety or fundamental rights of natural persons, and it also meets at least one of four conditions in Article 6(3). The four conditions are:
- The system performs a narrow procedural task.
- The system improves the result of a previously completed human activity.
- The system detects patterns or deviations without replacing or influencing a human assessment without proper review.
- The system performs a preparatory task ahead of an assessment.
But there is a hard line: a system that profiles natural persons is always high-risk, regardless of the conditions above. This is where many SMBs land wrong. A recruitment tool that only converts a CV into structured text can be a narrow procedural task. A tool that ranks and screens candidates profiles them, and is therefore always high-risk.
One more condition: if you, as a provider, claim that an Annex III system is not high-risk, Article 6(4) requires you to document that assessment before the system is placed on the market and to register it. The exemption is not a shortcut past the paperwork, but a decision you must be able to defend.
On 19 May 2026 the European Commission published draft guidelines on high-risk classification with a consultation open until 23 June 2026. It is still a draft, but it gives the most detailed guidance so far on how Article 6 should be interpreted. Follow the final version before you make borderline decisions.
Step 4: do the transparency rules in Article 50 apply?
If the system is neither prohibited nor high-risk it can still be covered by transparency rules. Article 50 governs four cases, and responsibility is split between provider and deployer. The requirements start to apply on 2 August 2026.
| Case | Who informs |
|---|---|
| AI that interacts directly with people (chatbots) | Provider |
| Marking of synthetic content (image, audio, video, text) | Provider |
| Emotion recognition or biometric categorisation | Deployer |
| Deepfakes and AI text on matters of public interest | Deployer |
The most common case for SMBs is chatbots and AI agents that meet customers. The person must be told they are talking to AI, unless it is obvious. The difference from an internal automation matters: a customer-service bot is covered by the rule, while an AI that counts inventory or prices in the background never meets the end customer and therefore lands in minimal risk. To understand where that line runs, read our comparison of AI agents and chatbots. The transparency rule targets the interface with the human, not the logic behind it.
How are general-purpose AI models (GPAI) classified?
General-purpose AI models follow their own track alongside the risk ladder, governed by Articles 51 to 55. All providers of GPAI have documentation obligations since 2 August 2025. Models with so-called systemic risk get additional requirements for evaluation, testing and incident reporting.
The threshold for systemic risk sits at training compute above 10^25 FLOP, according to the Commission's GPAI guidance. It is a threshold only the largest model makers cross, not Swedish SMBs.
For those of you who use ChatGPT, Claude or Gemini internally, the message is simple: the obligations for the model itself sit with OpenAI, Anthropic and Google. Your role is deployer. What you are responsible for is how you use the model, meaning which risk level your own use case lands in according to the steps above, plus AI literacy among your staff.
How are four common SMB systems classified in practice?
Four concrete examples show how the same method gives different outcomes: a customer-service chatbot becomes limited risk, a CV screening tool becomes high-risk, an internal ChatGPT becomes minimal risk, and an image generator for marketing becomes limited risk. The difference lies in what the system does and who it meets.
Example 1: a customer-service chatbot at an e-commerce store. Role: deployer, since the bot is a purchased service. It is not prohibited, and customer service is not among the Annex III areas, so it is not high-risk. But it talks directly to customers, which triggers Article 50(1). Outcome: limited risk. Action: a clear notice that the customer is chatting with an AI assistant at first contact.
Example 2: a tool that screens and ranks job applications. Role: deployer. Not prohibited. Recruitment is in Annex III point 4, so the starting point is high-risk. You then test Article 6(3): does the system only perform a narrow procedural task? No, it ranks and screens candidates, which is profiling. Profiling of persons is always high-risk. Outcome: high-risk, with technical documentation, a risk management system, human oversight and registration. This is a project of months, not an afternoon.
Example 3: ChatGPT used internally for drafts and analysis. Role: deployer of a general-purpose model. Not prohibited, not in Annex III, no customer contact. Outcome: minimal risk. The provider obligations for the model itself sit with OpenAI. The only requirement on you is AI literacy among staff under Article 4, plus an internal policy on which systems are approved for use.
Example 4: AI that generates images for marketing. Role: deployer. Not prohibited, not high-risk. But you publish synthetic content, which triggers Article 50. The provider must mark the material in a machine-readable way, and you must disclose that an image or video is AI-generated where it is relevant. Outcome: limited risk with a marking obligation.
Note that all four systems can exist in one and the same company, yet land in three different categories. That is why you must classify per system and per role, not draw a single conclusion for the whole business.
What are the most common risk classification mistakes?
Four errors keep recurring among Swedish SMBs: skipping purchased AI in the inventory, confusing provider and deployer, labelling every chatbot as high-risk, and leaning on the Article 6(3) exemption for a system that in practice profiles people. All four can be avoided with the method above.
Skipping purchased AI. Many classify only systems they built themselves and forget AI built into CRM, HR tools and accounting software. Everything belongs in the inventory, even if the requirements mostly land on the provider. You cannot classify a system you do not know you have.
Confusing the roles. If you assume provider responsibility for a service you only use, you build documentation needlessly. If you assume the deployer role when you are actually reselling AI under your own brand, you miss requirements that genuinely apply to you. The role is decided per system, not once for the whole company.
Over-classifying chatbots. A chatbot that talks to customers is limited risk, not high-risk. It needs a transparency disclaimer, not a full risk management system. Over-classification costs time and money without reducing any real risk.
Missing the profiling rule. The most serious error is to invoke the Article 6(3) exemption for a system that ranks or assesses people. If the system ranks candidates or customers it is always high-risk, no matter how narrow the task looks on paper. This is where the real compliance risk arises.
What do you do once the risk classification is done?
Once every system has a level and a role you take the actions that belong to it. Document the classification for all systems, especially if you claim the Article 6(3) exemption, since that assessment must be available for inspection. Then you follow the requirements per category.
Prohibited systems are stopped. High-risk systems require technical documentation, a risk management system, human oversight and registration, work that takes months rather than days. Limited-risk systems need clear transparency disclaimers. Minimal risk requires no specific action, but an internal inventory is wise ahead of any review.
Whatever the category, three things are worth formalising right away. Appoint a responsible person who owns the AI inventory and updates it when new systems arrive or are used in new ways. Save every classification decision in writing, with the date, the chosen category and a short rationale, so you can show how you reasoned. And ensure AI literacy under Article 4, which applies regardless of risk level: a short internal session on what your AI systems can and cannot do goes a long way for most SMBs. This costs almost nothing in time now, but it is the difference between a calm and a stressful conversation the day a supervisory authority, a customer or an investor asks questions.
The most important advice is to build it right from the start. When you develop new AI flows, design them with the classification in mind, so you avoid expensive rebuilds later. It is the same principle we follow when we build AI agents for Swedish SMBs: transparency where it is required and documentation as standard. A well-considered risk classification early is cheaper than a fix under time pressure near a deadline.
Frequently asked questions
Yes, include them in the inventory. AI in your CRM, HR system or accounting software counts. As a deployer the heavy requirements usually sit with the provider, but you are responsible for knowing which risk level your use lands in and that the provider meets its obligations.
Classify by the strictest level the system touches. The logic is hierarchical: test prohibited first, then high-risk, then transparency. A system that both talks to customers and assesses creditworthiness is high-risk, and the transparency rule also applies to the chat part.
Yes, but the result is usually minimal risk. Internal use of a general-purpose model for productivity without customer contact has no specific requirements on you as deployer. Still document that the system exists, and make sure staff have the AI literacy Article 4 has required since February 2025.
You are always responsible for classifying your own use. The vendor is responsible for its obligations around the system itself, but no authority or vendor does the classification for you as a deployer. That is why inventory and role assessment is the first thing you must do yourself.
No. The agreement from 7 May 2026 concerns deadlines and guidance, not the classification logic in Articles 5, 6, 50 and 51. The classification work you do now holds even if the high-risk deadline moves. The proposal is also not yet formally adopted.
Redo it when something material changes: you take on a new AI system, change how an existing one is used, or shift from deployer to provider. Otherwise an annual review is enough. Keep the documentation so you can show how you reasoned at each assessment.
Under-classification is the most expensive. Treating a high-risk system as minimal risk exposes you to penalties and a shutdown if an authority intervenes. For SMBs the lower of the amount and percentage applies under Article 99(6). Over-classification instead costs needless work and documentation with no benefit.
AI to work?