Is My AI System High-Risk Under the EU AI Act, and Who Does the Conformity Assessment?

The question every team building or buying an AI agent eventually asks is the same: is my AI system high-risk under the EU AI Act, and if so, who signs off on it? The honest answer is that the classification is more mechanical than most people fear, the assessment is lighter than the headlines suggest, and the real risk is misreading either one and discovering it late.

This note walks the logic the way a careful build team would: what makes a system high-risk, who carries the obligation, what the conformity assessment actually involves, and when the clock runs out. We have linked the primary articles so you can check us against the source.

The two ways an AI system becomes high-risk (Article 6)

The Act describes two routes, and your system only needs to hit one. The first, under Article 6(1), catches AI that acts as a safety component of a product already covered by EU product-safety law — machinery, medical devices, lifts, toys — where that product already needs third-party checking before it goes to market. If you are not embedding AI into a regulated physical product, this route rarely applies.

The second route is the one that catches software and agents. Under Article 6(2), any system used for a purpose listed in Annex III is high-risk by default. The Annex III list is built around consequences to people, not technology. It covers AI used in employment (CV screening, ranking candidates, monitoring or evaluating workers), access to essential services (credit scoring, insurance pricing, eligibility for benefits), education (scoring exams, admissions), biometrics, critical infrastructure, law enforcement, and migration.

So the test for is my AI system high-risk under the EU AI Act is not "how advanced is it" — it is "what decision about a person does it touch?" A chatbot that answers general questions about your opening hours is almost certainly not high-risk. The same underlying model, pointed at ranking job applicants or deciding who gets a loan, is.

The exemptions that quietly save most agents — and the trap inside them

Annex III is not the end of the analysis. Article 6(3) lets a system that appears on the list step back out, if it genuinely poses no significant risk to health, safety or fundamental rights. There are four exemption conditions, any one of which can apply:

• The system performs a narrow procedural task only.
• It improves the result of a completed human activity rather than driving the decision.
• It detects patterns or deviations from prior decision-making without replacing the human assessment, subject to proper review.
• It performs a preparatory task ahead of one of the Annex III use cases.

This is where the EU AI Act high-risk classification under Article 6 gets dangerous, because the exemption is conditional and you have to prove it. There is also a hard override: Article 6(3) states that a system always counts as high-risk where it performs profiling of natural persons. No exemption survives profiling. An agent that scores, segments or predicts individual behaviour cannot quietly exempt itself, however "preparatory" it feels.

And even when an exemption genuinely applies, you are not off the hook administratively: the provider must document the assessment before the system goes to market and register it. The exemption removes the heavy obligations; it does not remove the paperwork that justifies the exemption. A claim with no file behind it is the worst of both worlds — you carry the risk of a wrong call and have nothing to show a regulator.

Provider vs deployer: which obligations are actually yours?

Before working out who does the conformity assessment, work out which hat you are wearing, because the obligations split sharply.

The provider is whoever develops the system, or has it developed and puts it on the market under their name. Providers carry the heavy lift: the conformity assessment, the technical documentation, registration in the EU database, and — if they sit outside the EU — appointing an authorised representative inside it.

The deployer is whoever uses the system in a professional capacity. If you buy an off-the-shelf high-risk tool, you are a deployer, and your duties are narrower but real: use the system per the provider's instructions, assign genuine human oversight, retain the system's logs (the Act sets a six-month minimum), and inform people who are affected by it.

The provider-versus-deployer distinction in the AI Act trips up small businesses most. As the IAPP has noted, deployers cannot simply file the vendor's certificate and consider themselves covered — "the vendor's certifications, audit evidence or system profile is not a substitute for the organisation's own evidence." You still have to evidence your oversight, your logging, your incident handling. And if you materially fine-tune a bought-in system or rebrand it as your own, you can become the provider — and inherit the heavy obligations. That reclassification is exactly the kind of thing that turns a cheap subscription into a compliance programme.

Who does the conformity assessment — and the surprise most teams welcome

Here is the part that calms most rooms down. For the bulk of high-risk AI systems on the Annex III list — points 2 through 8, which is where employment, credit, insurance, education and essential-services tools live — the conformity assessment is internal control under Annex VI. That means the provider assesses their own system against the requirements using their quality-management system and technical documentation. There is no notified body. No external auditor. No CE certificate from a third party.

So on the recurring search of EU AI Act conformity assessment, who does it: for most agents, you do. The notified-body-versus-self-assessment question under the AI Act only swings towards a notified body in a narrow zone — Annex III point 1, biometric systems, and even there only where the provider has not applied the relevant harmonised standards in full (per Article 43). Apply the standards properly and even biometric providers can self-assess. The other third-party trigger is Annex I products that already need external assessment under existing product law.

People ask whether they need CE marking for an AI system. High-risk systems do carry a CE mark and a declaration of conformity — but for the self-assessment route, you affix it yourself once your documentation is in order. CE marking is not, in most cases, a queue at an external lab.

What "self-assessment" actually costs you in documentation

"You assess it yourself" is not the same as "it's free." The AI Act's technical documentation requirements are substantial and have to exist before the system is placed on the market: a description of the system and its intended purpose, the data and data-governance behind it, the risk-management process, accuracy and robustness testing, logging design, and the human-oversight measures. For higher-stakes deployments, a fundamental-rights impact assessment under Article 27 can apply — and it reaches private bodies providing public services and certain creditworthiness and insurance uses, not just public authorities.

This is the unbudgeted-project risk in concrete form. None of these artefacts are exotic, but they have to be true, maintained, and reconcilable with how the system actually behaves. Retrofitting them onto an agent that was shipped first and documented never is far slower than building the evidence trail as you build the system. EU AI Act compliance for SMEs in 2026 is mostly a documentation-discipline problem, not a legal-theory one.

The deadline moved — but the work didn't shrink

The original date for Annex III high-risk obligations was 2 August 2026. That is the figure still circulating in most coverage, and it is why teams have been treating this as a 2026 fire drill. The picture changed on 7 May 2026, when the Council, Parliament and Commission reached a provisional agreement on the so-called Digital Omnibus, deferring Annex III high-risk obligations to 2 December 2027, and the Annex I product route to 2 August 2028. The deferral was granted largely to give standards bodies such as CEN-CENELEC time to finish the standards that self-assessment leans on.

Two cautions, stated plainly. First, this is still a provisional agreement at the time of writing — formal adoption was anticipated in June and publication in July 2026, so treat the new dates as near-certain but not yet law. Second, the Omnibus moves the timeline and lightly refines the "safety component" definition; it does not rewrite the Article 6 classification logic. Whether your agent is high-risk is decided by the same test it always was. A later deadline is more runway to do the documentation properly — it is not a reprieve from doing it. Notified-body capacity for the cases that need it is already tight, and that does not improve by waiting.

The penalty for getting the obligations wrong is not trivial — up to €15 million or 3% of global annual turnover, plus the power to pull a non-compliant system from the EU market. One misclassification doesn't just risk a fine; it can strand a product you've already built.

How to settle this in an afternoon, not a quarter

If you want a clean answer for your own agent, the sequence is short. Inventory every AI system that touches a decision about a person. For each, ask whether the use case sits in Annex III. If it does, test it honestly against the Article 6(3) exemptions — and check the profiling override before you celebrate. Decide whether you are provider or deployer for each one, write the classification rationale down, and only then size the documentation work. Most teams find the list of genuinely high-risk systems is shorter than they feared and the assessment lighter than they were told — but the few that are high-risk need real evidence, started early.

If your honest read is that nothing you run is high-risk, the right move is to document why and get on with building. We would tell you that plainly rather than sell you a compliance programme you do not need. Where it does bite, the cheapest version is the one where classification and documentation are designed into the build from the first commit — not bolted on the week before a deadline that has a habit of arriving early.