EU AI Act Risk Classification: The 4 Tiers Explained (2026)
EU AI Act risk tiers explained: Art 5 bans, Annex III high-risk (deadline 2 Dec 2027), Art 50 transparency, minimal-risk. Art 6(3) exemption filter covered.
The EU AI Act sorts every AI system into one of four risk tiers — prohibited, high-risk, limited-risk, or minimal-risk — and attaches obligations to the top two. Your tier determines whether you can operate at all, what documentation you must produce, whether a conformity assessment is required, and what fine ceiling applies if you get it wrong. Penalties range from €35 million or 7% of worldwide turnover for breach of the Article 5 prohibitions down to nothing for genuinely minimal-risk systems.
Classification is not optional, not self-determined, and not a one-time exercise. Regulation (EU) 2024/1689 requires you to classify every AI system before market placement and to reassess when functionality changes, training data shifts substantially, or the deployment context expands. A tool built for internal HR analytics that is then offered to external clients as a product may inherit a completely different set of obligations overnight.
This guide covers the legal basis for each tier, the classification decision sequence, the Article 6(3) exemption filter, the correct compliance deadlines under the Digital Omnibus agreed in May 2026, and where GPAI models fit as a cross-cutting category separate from the four tiers.
The Classification Decision Sequence
Before diving into each tier, run every AI system through this sequence in order. Stop as soon as a rule fires.
1. Is it banned under Article 5? If yes, the system cannot be placed on the EU market, imported, distributed, or deployed. No documentation, no risk mitigation, no conformity assessment changes that outcome. Cease and remove.
2. Is it in an Annex III area (Article 6(2))? Annex III lists eight use-case categories. If the system's intended purpose falls within any of them, it is provisionally high-risk.
3. Does the Article 6(3) exemption apply — and is there profiling? An Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights — for example, it performs a narrow procedural task, only improves the result of a human activity already completed, merely detects decision patterns without influencing human assessment, or does preparatory work. But the carve-out has a hard limit: any system that profiles natural persons is always high-risk, regardless of any other factors. Providers claiming the exemption must document the reasoning and register the assessment.
4. Does it trigger Article 50 transparency? Even if not high-risk, a system must comply with Article 50 if it is a chatbot or other conversational AI, generates or manipulates synthetic media (deepfakes, voice synthesis), recognises emotion from biometric signals, or categorises individuals biometrically (without identifying them).
5. Otherwise: minimal risk. No EU AI Act-specific obligations apply. Parallel frameworks — GDPR, product safety law, consumer protection — continue to operate.
Classification at a glance
| Step | Rule | Result if yes |
|---|---|---|
| Art 5 check | Matches a prohibition? | Banned — stop |
| Art 6(2) + Annex III | Matches an Annex III use-case area? | Provisionally high-risk |
| Art 6(3) filter | Does not pose significant risk AND no profiling? | Drops to minimal (document it) |
| Art 50 check | Chatbot / deepfake / emotion recognition / biometric categorisation? | Limited-risk — transparency obligations |
| No match | — | Minimal risk |
GPAI models do not fit in this table. They are governed by a separate cross-cutting framework in Chapter V (Articles 51–56) regardless of which risk tier applies to systems built on top of them.
Tier 1 — Prohibited AI Systems (Article 5)
Article 5 establishes absolute prohibitions. There is no threshold, no exception for consent, and no safeguard that renders a banned system permissible. These bans have applied since 2 February 2025.
The eight prohibited practices
Article 5(1)(a)–(h) lists:
- Subliminal manipulation — systems using techniques below the threshold of human perception to materially distort behaviour and cause harm.
- Exploitation of vulnerabilities — systems exploiting age, disability, or socioeconomic circumstances to distort behaviour harmfully.
- Social scoring by public authorities — AI assigning scores based on social behaviour or personal characteristics, used to restrict services or opportunities.
- Real-time remote biometric identification (RRID) in publicly accessible spaces — live facial recognition and similar biometric matching, with narrow law enforcement exceptions.
- Post-remote biometric identification — retrospective biometric matching in public spaces, again with limited law enforcement carve-outs.
- Emotion recognition in workplace or educational settings — AI inferring emotional states of workers or students.
- Biometric categorisation to infer sensitive attributes — systems deriving race, political opinions, trade-union membership, religious beliefs, sexual orientation, or health status from biometric data.
- Individual criminal risk assessment (predictive policing) — AI assessing a person's risk of committing offences based purely on profiling, without individualised objective evaluation.
The RRID exceptions: private sector has none
Real-time remote biometric identification is prohibited except when used by law enforcement to search for specific missing or exploited victims of crime, to prevent an imminent and serious threat to life, or to detect specific serious criminal offences as defined by law. A retail company deploying live facial recognition to identify shoplifters in real time cannot use these exceptions — they are available only to designated law enforcement authorities, subject to prior judicial or administrative authorisation.
Who is bound
The prohibition applies to providers, deployers, importers, and distributors equally. A company that imports a system containing prohibited functionality is liable regardless of where the system was built or whether the company knew of the prohibition.
Penalties
Breach of Article 5 carries the highest fine ceiling in the Act: €35,000,000 or 7% of total worldwide annual turnover, whichever is higher (Article 99(3)). For SMBs and start-ups, fines are capped at the lower of the percentage or the fixed amount (Article 99(6)).
The mistake that costs most
Organisations assume that adding consent mechanisms, transparency notices, or human-review steps can cure a prohibited system. They cannot. Article 5 does not create a balancing test — it creates a ban. If your system falls within one of the eight categories, it must be removed entirely.
Tier 2 — High-Risk AI Systems (Article 6 + Annex III)
High-risk is where most compliance effort concentrates. Getting into this tier triggers a stack of mandatory obligations that must be satisfied before deployment. Getting out of it wrongly — by claiming the Article 6(3) exemption without proper grounds — is itself a compliance failure.
How Article 6 works
Article 6 contains three classification routes:
- Article 6(1) — AI systems that are safety components of products covered by Union harmonisation legislation listed in Annex I (e.g. the Machinery Directive, the Medical Devices Regulation) are high-risk and subject to mandatory third-party conformity assessment.
- Article 6(2) — AI systems whose intended purpose falls within one of the eight Annex III categories are high-risk.
- Article 6(3) — An Annex III system is not high-risk if the provider documents that it does not pose a significant risk of harm to health, safety, or fundamental rights, provided it is not a profiling system (profiling always = high-risk regardless).
The eight Annex III categories — exact scope
1. Biometrics (where permitted): remote biometric identification systems; biometric categorisation systems inferring sensitive attributes; emotion recognition systems in employment or education — though note emotion recognition in employment is outright prohibited under Article 5(1)(f), so this Annex III entry matters primarily for other contexts.
2. Critical infrastructure: AI used as a safety component in the management and operation of road traffic, the supply of water, gas, heating, electricity, or critical digital infrastructure.
3. Education and vocational training: AI determining access to or admission into educational and vocational training institutions; AI evaluating learning outcomes, assessing students, or monitoring and detecting prohibited behaviour during tests.
4. Employment, workers management, and access to self-employment: AI for recruitment and selection (CV screening, shortlisting, interview assessment); monitoring and evaluating performance and behaviour of workers; making decisions on promotion, termination, or task allocation; monitoring compliance with contractual obligations.
5. Access to essential private and public services: AI for creditworthiness assessment and credit scoring (excluding fraud detection); assessing risk and pricing for health and life insurance; emergency services dispatch; determining eligibility for public-benefit programmes and social services.
6. Law enforcement: AI used to assess the risk of an individual offending or reoffending, or the risk of being a victim; polygraph-like tools; evaluating the reliability of evidence; predicting the occurrence of criminal acts; profiling natural persons (profiling is also the carve-out barrier in Art 6(3)); facial recognition in historical footage for investigations.
7. Migration, asylum, and border control: AI assessing the risk posed by individuals entering the EU; AI examining applications for asylum, visa, or residence permits; verifying travel documents; assisting in processing applications.
8. Administration of justice and democratic processes: AI assisting judicial authorities in researching facts and law, or interpreting the law; AI influencing the outcome of elections or referenda, including targeted political advertising.
A practical note on scope: the Act covers an AI system's intended purpose, not just how it happens to be used. If your product documentation, marketing materials, or API terms of service reference any of these use cases, you are in Annex III territory.
The Art 6(3) exemption filter in practice
A system can escape the high-risk label even if it falls in an Annex III area, but the conditions are stringent. The system must either: perform a narrow preparatory task with no direct influence on a decision; merely improve the result of human activity that has already been completed (post-hoc quality check, not decision support); detect patterns without replacing or influencing human assessment; or perform administrative tasks not related to individual decisions. The provider must write down the assessment and register it in the EU database under Article 49.
The profiling limit is absolute. If your system ranks, scores, predicts, or categorises natural persons based on their attributes or behaviour — even indirectly — the exemption does not apply.
Example: A system that auto-formats submitted CVs into a standardised template (for downstream human review) is likely not high-risk. A system that ranks CVs, flags candidates, or assigns suitability scores is.
What high-risk classification requires
Once a system is confirmed high-risk, the following obligations apply before it enters service:
| Obligation | Article | What it requires in practice |
|---|---|---|
| Risk management system | Art 9 | Documented, iterative process to identify, estimate, evaluate, and mitigate risks throughout the lifecycle |
| Data governance | Art 10 | Training and validation data quality; bias assessment; data minimisation and relevance checks |
| Technical documentation | Art 11 + Annex IV | Full system description, training data sources, testing protocols, performance metrics — retained 10 years |
| Record-keeping / logging | Art 12 | Automatic logging sufficient to trace decisions post-deployment |
| Transparency to deployers | Art 13 | Instructions for use that allow deployers to understand and apply the system correctly |
| Human oversight | Art 14 | Ability to monitor, override, interrupt, or reject system output; no fully automated final decisions without human review |
| Accuracy, robustness, cybersecurity | Art 15 | Documented performance levels; resilience to errors, faults, and attacks |
| Conformity assessment | Art 43 | Internal control (Annex VI) for most Annex III systems; third-party notified body for Annex I-embedded AI and biometric identification (Cat 1) |
| Quality management system | Art 17 | Formal QMS covering design, change management, post-market |
| EU Declaration of Conformity | Art 47 | Signed declaration that requirements are met |
| CE marking | Art 48 | Affixed only after successful conformity assessment |
| Registration in EU database | Art 49 | Before market placement for Annex III systems |
| Post-market monitoring | Art 72 | Continuous performance tracking; incident reporting (serious incidents within 15 days, Art 73) |
Providers carry the heaviest load. Deployers must follow the instructions for use (Art 26), ensure human oversight in their context, monitor the system in operation, and — if the deployer is a public-sector body or operates critical infrastructure — run a Fundamental Rights Impact Assessment (FRIA) under Article 27 before deployment.
Role shifts under Article 25
A deployer, distributor, or importer becomes a provider — with the full provider obligation stack — if it places its own name or trademark on a high-risk system, substantially modifies a high-risk system, or modifies the intended purpose of a system that was not previously high-risk. An insurance company that takes a general-purpose AI model, wraps it in its own product, and deploys it to assess health-insurance premiums is a provider under Article 25.
Compliance deadlines
Under the Digital Omnibus (Commission proposal November 2025; political agreement reached 7 May 2026, formal adoption expected before 2 August 2026):
- 2 December 2027 — stand-alone high-risk AI systems listed in Annex III.
- 2 August 2028 — high-risk AI embedded as safety components in Annex I regulated products.
The original 2 August 2026 date has been deferred. That is not the same as an extension of goodwill — the documentation required to satisfy Art 9–15 alone takes six to nine months to prepare properly. Starting in late 2026 leaves no margin.
Penalties
Non-compliance with high-risk obligations carries fines of €15,000,000 or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). The SMB cap (Article 99(6)) applies: for start-ups and small companies, the lower of the fixed sum or percentage applies.
Tier 3 — Limited-Risk AI Systems (Article 50)
Limited-risk systems carry transparency obligations only. No conformity assessment, no technical documentation pack, no notified body, no CE marking. The rationale is that these systems interact directly with people or generate outputs that influence behaviour, but they do not pose the systemic risks of high-risk AI.
What triggers Article 50
Four categories:
Chatbots and conversational AI: any system designed to engage in natural-language dialogue with a natural person, including customer service bots, virtual assistants, and support automation.
Synthetic media: systems that generate, manipulate, or alter images, audio, or video to create content that could falsely appear authentic — deepfakes, voice cloning, face-swapping.
Emotion recognition systems (where not prohibited): systems inferring emotional or psychological states from biometric signals in contexts outside the Art 5 prohibition (which covers workplaces and educational institutions). The majority of emotion recognition deployments are either prohibited or high-risk; the limited-risk transparency obligation covers remaining cases.
Biometric categorisation (non-identification): systems that classify individuals into categories based on biometric data but do not identify them — age estimation for content access, gender classification for audience analytics.
What the obligations actually require
Providers of chatbots must make clear to users, at the start of each interaction, that they are speaking with an AI. The disclosure must be clear and unambiguous — a small icon buried in a corner does not satisfy the obligation.
Providers and deployers of systems generating synthetic media must mark the output as AI-generated in a machine-readable format. The EU AI Act coordinates this with the amended Media Freedom Act and the Code of Practice on Disinformation.
Providers of emotion recognition systems must inform individuals that the system is in operation before it processes them.
There is a narrow exception: disclosures are not required where an authorised person specifically requests synthetic media for creative, satirical, or artistic expression and appropriate disclosure is made in another way.
Common mistake
Treating the transparency obligation as a one-off notice buried in terms of service. Article 50 requires disclosure to be effective, which means it must reach users at the point and time of interaction, not in a document they signed two years earlier. Ongoing notification, not historical consent, is the standard.
Compliance deadline
Article 50 transparency obligations apply from 2 August 2026 — unchanged by the Digital Omnibus, which only deferred the high-risk Annex III obligations.
Violations carry fines of up to €15,000,000 or 3% of worldwide annual turnover (Article 99(4)).
Tier 4 — Minimal-Risk AI Systems
Most AI deployed by SMBs falls here. Minimal-risk systems have no EU AI Act-specific obligations — no conformity assessment, no technical documentation under Article 11, no registration, no human oversight mandate. The regulation does not require providers or deployers to do anything specific with these systems.
What lands in this tier
Everything not caught by Art 5, Annex III, or Art 50. In practice: demand forecasting models, product recommendation engines, spam filters, pricing optimisation tools, churn prediction models, content moderation systems operating on text, and most process-automation tools. The common thread is that these systems either assist humans in low-stakes tasks or make decisions where errors are reversible and harm is limited.
A manufacturing SMB using AI to schedule preventive maintenance based on sensor data has no EU AI Act obligations. A logistics company using AI to optimise delivery routes has no EU AI Act obligations. An e-commerce business using collaborative filtering to recommend products is minimal-risk regardless of how sophisticated the underlying model is — sophistication and risk tier are not the same thing.
Where it gets tricky is systems that interact with individuals in ways that feel minor but actually influence access to something. A chatbot that handles customer service for a bank is likely limited-risk under Art 50, not minimal. An AI tool that suggests which contracts to prioritise for a legal team is likely minimal. The test is always: does this system's output affect an individual's access to something material (credit, employment, services, liberty), or does it just support internal workflows?
Reassessment when context changes
A system's minimal-risk status is tied to its current intended purpose and deployment context. If an e-commerce recommendation engine is extended to personalise pricing based on inferred financial vulnerability, the use case changes. If a content moderation tool is repurposed to screen job applications, the use case changes. Reclassification is required and the obligations that come with it follow immediately — there is no grace period for discovering mid-deployment that your system should have been high-risk.
The parallel frameworks that still apply
Exempt from the EU AI Act does not mean exempt from everything. Minimal-risk AI systems remain subject to:
- GDPR (Regulation (EU) 2016/679) — if personal data is processed, all data protection obligations apply.
- Product Liability Directive (as revised) — manufacturer liability for defective products.
- Consumer Rights and Unfair Commercial Practices Directives — transparency in automated decision-making.
- Sector-specific rules — MiFID II for financial services, MDR for medical devices, NIS2 for critical-sector operators.
A customer segmentation model is minimal-risk under the EU AI Act but still subject to GDPR's data minimisation and purpose limitation requirements. Document your risk assessment decision anyway — a brief written record that you considered the Annex III criteria and concluded the system falls outside them is sound risk management if a regulator ever asks.
Voluntary codes
Article 95 of the Act encourages industry associations to develop voluntary codes of conduct for minimal-risk AI providers who want to go beyond baseline requirements. These are genuinely voluntary, but they can provide useful structure for organisations that want a documented governance framework without the full high-risk obligation stack.
GPAI: A Cross-Cutting Category, Not a Fifth Tier
General-purpose AI models (GPAI) do not slot into the four-tier classification framework. They are governed separately under Chapter V (Articles 51–56) of the Act, and the rules apply regardless of which risk tier applies to the downstream application built on top of them.
Who is a GPAI provider
A GPAI provider is any organisation that trains and places on the market a general-purpose AI model — a model trained on large amounts of data, designed for a wide range of tasks, and capable of being integrated into downstream systems. Large language models, multi-modal foundation models, and large-scale image-generation models all qualify. The provider is the entity that trained the model, not the developer who builds a product on top of it.
Obligations for all GPAI providers (Article 53)
Regardless of whether the model carries systemic risk, every GPAI provider must:
- Prepare and maintain technical documentation (Annex XI) describing training methodology, data used, computational resources, and capabilities.
- Provide downstream providers with the information they need to comply with their own obligations.
- Put in place a copyright compliance policy covering training data.
- Publish a summary of the training data used (Annex XII).
These obligations have applied since 2 August 2025.
Systemic-risk GPAI models (Article 51 + Article 55)
A GPAI model is presumed to carry systemic risk if trained using more than 10^25 floating-point operations (FLOPs). The AI Office may also designate models based on other capabilities. For systemic-risk models, additional obligations under Article 55 apply: adversarial testing and red-teaming before and after release; assessment and mitigation of systemic risks; serious incident reporting; cybersecurity measures proportionate to the risk; and energy-efficiency reporting.
Why this matters for risk classification
GPAI providers need to understand that the Chapter V obligations are layered on top of the four-tier system, not inside it. An organisation building a chatbot on top of a third-party GPAI model is the deployer for Art 50 purposes. The GPAI provider itself is subject to Art 53–55, irrespective of how the model is used downstream.
Fine ceiling for GPAI obligations: €15,000,000 or 3% of worldwide turnover, imposed by the Commission (Article 101).
How to Classify Your AI System: The Decision Walk-Through
Start by documenting what the system does, who uses it, and in what context. Then work through the sequence above, recording your reasoning at each step.
Step 1: Establish the intended purpose
Write down the system's primary function, the end-users, and the scope of decisions it supports or makes autonomously. A system that "helps HR teams" is too vague. "Ranks job applicants by predicted suitability score, shortlisting the top 20% for human review, used by HR managers in hiring decisions for roles in Germany" is classifiable.
Use the Act's definition in Article 3(1): a machine-based system that, for a set of human-defined objectives, infers outputs such as predictions, recommendations, decisions, or content that influence real or virtual environments, and that is designed to operate with some degree of autonomy.
Step 2: Check Article 5
Go through each of the eight prohibited categories. If the system's intended purpose includes real-time biometric identification in public spaces, social scoring, subliminal manipulation, emotion recognition of employees or students, biometric categorisation to infer sensitive attributes, or individual predictive policing — it is prohibited. Stop.
Step 3: Check Annex III (Article 6(2))
Work through each of the eight categories. Use the system's intended purpose as documented in Step 1, not a description of how you hope it will be used in a best-case scenario. If there is a match, the system is provisionally high-risk.
Watch out for indirect matches. A workforce-analytics tool that evaluates individual employee productivity against benchmarks and generates reports for line managers is in Annex III point 4 (employment/workers management) even if the final termination decision is made by a human.
Step 4: Apply the Article 6(3) filter
If the system lands in Annex III, ask whether it actually poses a significant risk of harm. Work through the four safe-harbour conditions:
- Narrow procedural task only?
- Improves a result already produced by a complete human activity?
- Detects decision patterns without replacing or influencing human assessment?
- Preparatory work only?
If any condition fits AND the system does not profile natural persons, you may document the exemption claim and register it. Be conservative: regulators will scrutinise exemption claims closely in the early enforcement period.
Step 5: Check Article 50
If the system did not catch in Steps 2–4, check whether it is a chatbot, produces synthetic media, recognises emotion in permitted contexts, or categorises individuals biometrically without identifying them. If yes: limited-risk, transparency obligations apply.
Step 6: Document the classification and set your roadmap
Create a classification record for each AI system: system name and version, intended purpose statement, Annex III and Art 5 assessment results, Art 6(3) exemption analysis (if applicable), final risk tier, date, and the name of the person who conducted the assessment.
For high-risk systems, this record feeds directly into the Article 11 technical documentation. For systems where you claimed the Art 6(3) exemption, it must be registered under Article 49. For minimal-risk systems, it serves as an internal audit trail.
| Risk tier | Key obligations | Deadline |
|---|---|---|
| Prohibited (Art 5) | Cease operation immediately | 2 Feb 2025 |
| High-risk, Annex III stand-alone (Art 6(2)) | Arts 9–15, 17, 43, 47–49, 72–73 | 2 Dec 2027 |
| High-risk, Annex I embedded (Art 6(1)) | As above + mandatory notified body | 2 Aug 2028 |
| Limited-risk (Art 50) | Disclosure to users | 2 Aug 2026 |
| Minimal-risk | None specific to EU AI Act | — |
Risk Assessment Obligations by Role
Providers (Article 16)
The provider — whoever develops and places a system on the market under their own name — carries the full high-risk obligation stack. That means Articles 9 through 15 plus the QMS (Art 17), conformity assessment (Art 43), registration (Art 49), and post-market monitoring (Art 72). Most SaaS companies that build and sell AI-enabled products are providers.
The conformity assessment for most Annex III systems is internal control: the provider carries out the assessment itself against the requirements, without a notified body. The exceptions are systems used for real-time or post-remote biometric identification, and AI embedded in Annex I regulated products (e.g. a medical device) — these require mandatory third-party assessment. Self-assessment does not mean lower scrutiny; it means the provider must be able to defend every decision in the technical file if a market surveillance authority requests access.
After CE marking and market entry, providers remain accountable. Article 72 requires a post-market monitoring plan that tracks real-world performance against the metrics documented in the technical file. Where actual performance falls below documented specifications, or where a serious incident occurs, Article 73 requires reporting to the relevant market surveillance authority, generally within 15 business days.
Deployers (Article 26)
A deployer uses a high-risk AI system under their authority in a professional context. Deployer obligations are narrower but material: follow the instructions for use; assign a human able to monitor and override outputs; keep logs; inform workers before a system that monitors them is deployed; and run a FRIA (Art 27) if the deployer is a public body or operates critical infrastructure.
Most SMBs that use AI tools built by someone else — hiring software, credit-assessment tools, customer analytics — are deployers. The obligations are lighter than many founders fear. The part that bites most is the monitoring duty and the FRIA where it applies.
The Fundamental Rights Impact Assessment under Article 27 is required before deploying a high-risk system in a context affecting individuals when the deployer is: a public body; an operator of critical infrastructure; a financial institution using AI for credit scoring or insurance; an education provider; or any deployer whose system makes decisions about access to essential private services. The FRIA is a structured exercise that identifies which fundamental rights (dignity, privacy, non-discrimination, due process) could be affected, assesses the likelihood and severity of harm, and documents the measures taken to address them.
Importers (Article 23) and Distributors (Article 24)
Importers must verify the provider has completed conformity assessment and the EU Declaration of Conformity is issued before importing. Distributors must verify that required compliance documentation accompanies the system. Both must report non-compliance to the provider and to competent authorities.
Role shifts under Article 25
Deployers who put their own branding on a system, substantially modify it, or use it in a way that extends its intended purpose become providers for compliance purposes. This catches mid-market SaaS companies that license foundation models and add proprietary workflows on top.
A useful heuristic for SMBs: if you are purchasing a named AI product off the shelf and using it as intended, you are a deployer. If you are training a model, fine-tuning a foundation model for your specific use case, or building AI functionality into a product you sell to others, you are likely a provider.
How Confir Handles Classification
Confir runs a rule-based, deterministic classification engine — same inputs produce the same outputs, every time, with the rule that fired shown in plain language. There is no LLM making probabilistic judgements about your risk tier; the logic encodes Articles 5 and 6, the Annex III criteria, and the Art 6(3) filter in explicit rules that any compliance officer can audit.
When you register an AI system, Confir guides you through plain-English scenarios to establish intended purpose, use-case area, and deployment context. It then derives your risk tier and your role (Provider under Art 16 / Deployer under Art 26 / Importer under Art 23 / Distributor under Art 24) automatically, and outputs a classification record ready to feed into the Art 11 technical documentation pack.
For high-risk systems, Confir then drives you through the full obligation stack — risk management system (Art 9), data governance (Art 10), human oversight (Art 14), conformity assessment (Art 43), and the Art 27 FRIA where applicable — all mapped to specific Articles. Pricing starts at €600 per year.
Frequently Asked Questions
How do I determine whether my AI system is high-risk under the EU AI Act?
Work through Annex III to Regulation (EU) 2024/1689, which lists the eight high-risk use-case categories: biometrics (Cat 1), critical infrastructure (Cat 2), education and vocational training (Cat 3), employment and workers management (Cat 4), access to essential services including credit scoring (Cat 5), law enforcement (Cat 6), migration and asylum (Cat 7), and administration of justice (Cat 8). Also check Article 6(1) — if your system is a safety component of a product covered by Annex I legislation (e.g. the Medical Devices Regulation or Machinery Directive), it is high-risk by that route. If an Annex III category matches, apply the Article 6(3) filter: could the system avoid the high-risk label because it performs only narrow preparatory work and does not profile natural persons? Document the assessment either way.
What is the difference between high-risk and limited-risk AI?
High-risk systems — those in Annex III or embedded in Annex I products — require conformity assessment (Art 43), technical documentation (Art 11), a risk management system (Art 9), human oversight (Art 14), and post-market monitoring (Art 72). Limited-risk systems under Article 50 (chatbots, deepfakes, emotion recognition in permitted contexts, biometric categorisation) require only transparency disclosures. The compliance burden difference is enormous. A recruitment AI is high-risk; a customer service chatbot is limited-risk.
Does the Article 6(3) exemption mean I can avoid the high-risk label for an Annex III system?
Yes, but the conditions are narrow. The system must not pose significant risk to health, safety, or fundamental rights — meaning it performs only narrow procedural tasks, post-hoc quality checks, or purely preparatory work. And crucially: if the system profiles natural persons in any way, the exemption does not apply. Providers must document the exemption assessment and register it in the EU database under Article 49. Claiming the exemption without meeting the conditions is itself a compliance failure.
What are the correct compliance deadlines after the Digital Omnibus?
Under the agreement reached in May 2026: prohibited practices (Art 5) have been enforceable since 2 February 2025. Article 50 (limited-risk transparency) applies from 2 August 2026. Annex III stand-alone high-risk systems must comply by 2 December 2027. High-risk AI embedded as safety components in Annex I products must comply by 2 August 2028. The original 2 August 2026 high-risk deadline was deferred by the Digital Omnibus and no longer applies.
What penalties apply for getting risk classification wrong?
Placing a prohibited system on the market breaches Article 5 and carries fines of €35,000,000 or 7% of worldwide annual turnover, whichever is higher. Deploying a high-risk system without the required conformity assessment, documentation, or oversight breaches Articles 16/26 and the ceiling is €15,000,000 or 3%. The same €15M/3% ceiling applies to Article 50 transparency failures. For SMBs and start-ups, Article 99(6) caps fines at the lower of the fixed amount or the percentage.
Where do GPAI models sit in the classification framework?
GPAI models (large language models and similar foundation models) are not a fifth risk tier. They are governed by a separate cross-cutting framework in Chapter V (Articles 51–56), which applies regardless of the risk tier of any downstream application. All GPAI providers must produce technical documentation, provide information to downstream developers, and maintain a copyright compliance policy (Art 53). Providers of systemic-risk models (those trained above 10^25 FLOPs, per Art 51) must also run adversarial testing, mitigate systemic risks, and report serious incidents (Art 55). These obligations have applied since 2 August 2025.
Who is responsible for classification — the provider or the deployer?
The provider — the organisation that developed and placed the system on the market — classifies the system's inherent risk based on its intended purpose and performs the conformity assessment. The deployer assesses the specific operational context to identify deployment-specific risks and must follow the provider's instructions for use, ensure human oversight, and (where applicable) run a FRIA under Article 27. Where a deployer substantially modifies a system or applies its own branding, Article 25 converts the deployer into a provider — taking on the full provider obligation stack.
Related guides
- compliance software solutions
- AI governance tools comparison
- Article 11 technical documentation requirements
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →