EU AI Act High Risk Systems for SMEs: Classify and Document by 2027

An AI system becomes high-risk under the EU AI Act through one of two legal routes: it is a safety component of a product already covered by EU product safety law, or it is deployed for a sensitive purpose listed in Annex III, such as recruitment, credit scoring, or law enforcement. Either route triggers the full weight of Chapter III obligations for providers, plus separate duties for deployers, and the deadlines for compliance are already staggered and running.

TL;DR:

  • Most organizations overlook the Annex III list of high-risk AI use cases, including biometric, critical infrastructure, employment, and law enforcement applications.
  • Compliance requires detailed documentation, risk management, and lifecycle oversight from providers, and strict purpose-based classification from deployers.
  • Deadlines for high-risk obligations are staggered for 2027 and 2028, with enforcement carried out by national authorities, and penalties increase with breach severity.
  • System classification depends on purpose, use, and risk impact, with profiling of individuals always subject to high-risk designation regardless of task narrowness.
  • Automating assessments, documentation, and evidence collection helps operationalize compliance but human judgment remains essential for classification and exception justification.

Table of Contents

What counts as an ai act high risk systems classification

Two doors lead into high-risk territory, and most organisations only know about one of them. The first is the Annex I route: your AI system is a safety component of a product, or the product itself, that already sits under EU harmonisation legislation requiring third-party conformity assessment. Think medical devices, lifts, or machinery where a CE mark already applies. If your AI touches that certification process, it inherits high-risk status automatically.

The second door is Annex III, and it catches far more organisations by surprise. The European Commission's Annex III list names eight domains where AI use is presumed high-risk:

  • Biometrics — remote identification or categorisation of people from facial or physical traits.
  • Critical infrastructure — AI managing safety in water, gas, or electricity networks.
  • Education — systems scoring exams or deciding admission to institutions.
  • Employment — CV-screening tools or software that ranks candidates for interview.
  • Essential services — credit-scoring engines and insurance risk-pricing tools.
  • Law enforcement — risk-assessment tools used to profile suspects or predict offending.
  • Migration and border control — visa-processing or asylum-risk assessment systems.
  • Administration of justice — tools assisting judges or tribunals in interpreting facts or law.

None of this depends on what a vendor calls their product. Article 6 makes classification purpose and use driven: the same underlying model can be minimal-risk chatbot software in one deployment and a high-risk employment tool in another, depending entirely on what decision it feeds into.

What does Article 6 actually require you to test?

Article 6 is short, but it carries the entire weight of the regulation, so it rewards a careful read rather than a skim.

For the Annex I route, Article 6(1) sets a twofold test: the product must fall under listed EU harmonisation legislation, and it must be required to undergo third-party conformity assessment under that legislation. Both conditions have to be met. A product covered by harmonisation law that only needs a self-declaration does not qualify.

For the Annex III route, Article 6(2) is the trigger, but Article 6(3) carves out an exception that trips up a lot of otherwise careful compliance teams. An Annex III use case can escape high-risk classification if it does not pose a significant risk to health, safety, or fundamental rights, specifically where it:

  • Performs a narrow procedural task rather than shaping the substantive outcome.
  • Improves the result of a human-led activity without replacing human judgement.
  • Detects decision-making patterns without materially influencing the final decision.
  • Performs preparatory work that feeds into, but doesn't determine, the Annex III assessment.

There is one hard limit on that exception: profiling of natural persons is excluded from it entirely. If your system profiles individuals, the significant-risk derogation does not apply, full stop, and you land in high-risk territory regardless of how narrow the task looks on paper. The Commission's draft guidelines also confirm the Commission retains a standing power to amend the Annex III list itself, so today's minimal-risk use case could shift tomorrow.

How do you classify a system step by step?

Run this sequence in order, not in whatever order feels convenient. Skipping ahead is how organisations miss a prohibition and only discover it during a market surveillance enquiry.

  1. Check Article 5 prohibitions first. If your system falls into a banned practice (social scoring, manipulative techniques, real-time biometric categorisation in public spaces without exemption), stop deployment. Nothing downstream matters if the use itself is prohibited.
  2. Run the Annex I test. Does the system act as a safety component, or is it the product itself, under EU harmonisation legislation requiring third-party assessment? Gather the relevant harmonisation directive reference and the conformity assessment route it prescribes.
  3. Run the Annex III test. Assess the system's intended purpose against the eight domains, and ask honestly whether it materially influences a decision affecting a person's rights, safety, or access to a service.
  4. Apply the Article 6(3) significant-risk test where it might apply. If the use case is narrow, preparatory, or purely corrective of human work, and does not involve profiling, document the justification for excluding it from high-risk status. Keep this written; regulators expect a reasoned file, not a verbal assurance.

Pro Tip: Treat every classification decision as evidence, not opinion. Keep a one-line register entry per system recording its purpose, its owner, the tier assigned, the date reviewed, and the justification. That single habit is what turns a defensible compliance position into an indefensible one when an auditor asks "show me why."

At each gate, retain the underlying documentation: a purpose statement written before procurement, any data protection impact assessment triggered by personal data use, and the test records that back up your tier decision. Reassess whenever the system's purpose changes or it moves into a new deployment context.

What do providers and deployers have to actually deliver?

The obligations split by role, and confusing the two is one of the more expensive mistakes SMEs make when a vendor's AI tool gets embedded into their own operations, as outlined in Agentic AI: What It Means for the Future of Compliance, Risk, and Decision‑Making.

Providers, meaning whoever develops the system or places it on the market under their name, carry the heavier burden. Under Articles 8 to 15, a provider of a high-risk system must maintain:

  • A risk management system running across the system's whole lifecycle, not a one-off assessment.
  • Data governance covering training, validation, and testing datasets, including bias checks.
  • Technical documentation meeting the Annex IV content list before the system goes to market.
  • Automatic logging capable of tracing the system's operation for traceability.
  • A human oversight mechanism that gives a real person the ability to intervene.
  • Demonstrated accuracy, robustness, and cybersecurity appropriate to the use case.
  • A post-market monitoring plan, with incident reporting obligations once deployed.

Deployers, meaning the organisations actually using the system in their operations, carry a narrower but still binding set of duties: use the system strictly within its intended purpose, assign competent human oversight, monitor its operation, and report serious incidents or malfunctions back to the provider or the relevant authority.

Annex IV technical documentation is not a light formality. It runs to a detailed content list covering system architecture, training methodology, performance metrics, and risk mitigation measures, and it has to exist before the system reaches the market, not retrospectively. Practical files worth assembling now include the technical file itself, validation test logs, the DPIA where personal data is involved, a documented human-oversight plan, and a retention policy for post-market monitoring records, a point the Commission's own explanatory guidance reinforces directly. The interplay between these robustness obligations and your existing cybersecurity controls is worth mapping early, since duplicating effort across frameworks wastes budget you'll want later.

What do providers and deployers have to actually deliver? — overview diagram

When do the deadlines actually bite, and who enforces them?

The AI Act's obligations are staggered, not simultaneous, and that phasing is a gift if you use it to prioritise rather than an excuse to delay everything. Article 50 transparency obligations and GPAI (general-purpose AI) model rules moved first. Recorded political agreement pushed the application of Annex III high-risk obligations to a date in late 2027, with Annex I embedded-product obligations following in 2028, though these later dates warrant a check against the Official Journal before you treat them as final for board reporting.

Enforcement sits with national competent authorities and market surveillance bodies in each member state, working alongside the European Commission's AI Office for cross-border and GPAI matters. These authorities can demand documentation, order corrective action, and investigate post-market incident reports.

  • Penalties scale with severity, with the highest ceilings reserved for prohibited-practice breaches.
  • High-risk non-compliance carries its own substantial penalty band, separate from the Article 5 tier.
  • Practical prioritisation matters here: systems affecting safety or fundamental rights should move to the front of your triage queue regardless of which deadline technically applies to them.

How do you turn these obligations into a working operational plan?

Legal text becomes compliance only once someone assigns it to a task, an owner, and a deadline. Mapping the obligations above to concrete workflow is where most SMEs stall, not because the law is unclear but because nobody owns the translation step.

A platform built for this maps naturally onto the same gates described earlier:

  • An asset inventory that captures every AI system in use, not just the ones IT remembers deploying.
  • Automated assessments with scoring and gap analysis against Annex IV's documentation requirements.
  • Template-driven technical documentation, cutting the drafting time for a provider's compliance file.
  • DPIA workflows linked directly to systems that touch personal data.
  • Centralised logging evidence collection, so traceability records exist before an auditor asks for them.
  • Deadline tracking against the staged 2027 and 2028 dates, tied to each system's assigned tier.

Automation genuinely helps with the repetitive parts: evidence collection, version control on policies, gap scoring against a checklist. It cannot replace the human judgement call on whether a system materially influences a decision, or whether your Article 6(3) exception justification would survive scrutiny. ShieldIQ's EU AI Act compliance tools are built around that split: automate the paperwork, leave the judgement to your team.

What should boards actually prioritise first?

Most boards get this backwards. They wait for a vendor contract to force the classification question, when the honest starting point is a live inventory of every AI system already in use, classified by purpose before procurement even begins.

Staged deadlines exist to help you triage, not to buy time. Systems touching safety, employment decisions, or fundamental rights deserve attention now, regardless of whether their formal deadline sits in 2027 or 2028. Assign a named owner for each system, cross-functional between legal, security, and the business unit using it, and require the evidence artefacts covered above at procurement and again at go-live. Compliance that gets bolted on after launch always costs more than compliance built in at the specification stage.

— Matthew Lemon

Get audit-ready for the EU AI Act without hiring a compliance team

Certain platforms turn the classification checklist above into a working system rather than a spreadsheet nobody updates, running automated assessments against Annex IV's documentation requirements, generating audit-ready technical files, and tracking the staged 2027 and 2028 deadlines against each system's assigned risk tier, all from one dashboard.

ShieldIQ

For SMEs, the practical outcome is fewer hours lost to manual document drafting and one central place holding your DPIAs, register entries, and evidence logs, rather than that trail scattered across shared drives and email threads. That matters most when a regulator or a customer's procurement team asks for proof, not promises.

If your organisation prefers hands-on support alongside the platform, ShieldIQ also offers consulting services for audit preparation and implementation. Visit the EU AI Act compliance page to see how the assessment and documentation tools apply to your own system inventory, and start your classification before the next deadline forces the decision for you.

Get audit-ready for the EU AI Act without hiring a compliance team — overview diagram

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

Recommended