In early 2026, US SaaS companies expanding into the European market began running into the same procurement friction: EU buyers pausing contracts to ask for a formal answer to one question - does this tool fall under Annex III of the EU AI Act? The question surfaces most often in recruitment tooling, credit assessment platforms, and decision-support software sold to regulated customers.

The stakes behind that question are concrete. Classification under Article 6 and Annex III determines whether an AI system is a high-risk AI system - and therefore whether mandatory risk management, data governance, technical documentation, human oversight, logging, post-market monitoring, conformity assessment, CE marking, and EU database registration all apply. Get the answer wrong and you inherit the full compliance stack you weren't scoped for. Get it right and you can move procurement conversations forward with evidence.

One pattern repeats across companies that have already been through this: those who classified early avoided operational disruption. Those who postponed classification encountered it at the worst possible moment - mid-procurement, during customer audits, or after an incident had already forced it.

How Article 6 actually decides what is high-risk

Article 6 sets the classification rules. There are two routes into the high-risk tier:

  • Article 6(1) covers AI systems that are safety components of products - or that are themselves products - regulated under EU harmonisation legislation listed in Annex I (medical devices, machinery, toys, vehicles, and more). Obligations for this route apply from 2 August 2027.
  • Article 6(2) covers AI systems that match use cases listed in Annex III. Obligations for this route apply from 2 August 2026 (subject to the Digital Omnibus outcome).

Most SaaS products sit on the Annex III route. A system listed in Annex III is presumed high-risk unless it meets one of the narrow exceptions in Article 6(3). The exceptions are genuinely narrow, and there is one override that catches many teams by surprise:

"An AI system referred to in Annex III shall always be considered to be high-risk where the AI system performs profiling of natural persons." - Article 6(3), second subparagraph

"Profiling" takes its meaning from Article 4(4) of the GDPR - automated processing of personal data used to evaluate personal aspects of a natural person, including performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location, or movements. If your system does that, no Article 6(3) exception is available, full stop.

The eight Annex III categories

The current Annex III covers:

  1. Biometrics (where legally permitted) - remote biometric identification (excluding simple verification), biometric categorisation inferring sensitive attributes, and emotion recognition systems.
  2. Critical infrastructure - AI used as safety components in digital infrastructure, road traffic management, or the supply of water, gas, heating, and electricity.
  3. Education and vocational training - admissions, allocating students to institutions, evaluating learning outcomes and steering the learning process, assessing appropriate level of education, and monitoring prohibited behaviour during tests.
  4. Employment, worker management, and access to self-employment - recruitment or selection (including targeted job advertising, application filtering, and candidate evaluation); decisions on promotion, termination, or task allocation based on individual behaviour or traits; and performance and behaviour monitoring.
  5. Access to essential private and public services and benefits - eligibility for public assistance or healthcare, creditworthiness evaluation and credit scoring (fraud detection excluded), life and health insurance risk assessment and pricing, and dispatch or prioritisation in emergency services.
  6. Law enforcement (permitted uses only, and subject to Article 5 prohibitions) - assessing the risk of a person becoming a victim of crime; evaluating reliability of evidence in investigations; assessing the risk of a person offending or reoffending based on more than profiling; and profiling of natural persons in the detection, investigation, or prosecution of offences.
  7. Migration, asylum, and border control management - polygraph-type systems, risk assessments of persons entering or intending to enter a Member State, examination of asylum or visa applications, and detection or identification of persons (document verification excluded).
  8. Administration of justice and democratic processes - AI used by a judicial authority or on its behalf to research and interpret facts and the law and apply them; AI used in alternative dispute resolution; and AI systems intended to influence the outcome of an election or referendum or the voting behaviour of natural persons (purely logistical or administrative campaign tools excluded).

The most common SaaS landings in Annex III are category 4 (recruitment screeners, performance dashboards) and category 5 (credit decisioning, consumer insurance pricing).

The current guidance gap

Article 6(5) required the Commission, no later than 2 February 2026, to publish guidelines specifying the practical implementation of Article 6 together with a comprehensive list of practical examples of AI systems that are and are not high-risk. That deadline was missed. A second revised timeline has itself slipped, with expected final adoption now projected for March or April 2026. This missing guidance is a direct driver of the Digital Omnibus delay proposal - companies cannot perform defensible self-classification against criteria the Commission has not yet published. In the meantime, the recitals of the regulation (especially Recital 53), the text of Article 6(3) itself, and the narrow construction preferred by published legal commentary are the available anchors.

A practitioner's five-step classification process

Step 1 - Build a full AI system inventory

List every model, feature, and integration that infers outputs from inputs and influences a decision, a recommendation, or an environment. Include embedded tools in your SaaS platform, internal analytics, customer-facing modules, and any third-party AI services your product routes through. Capture intended purpose, data inputs, output type, user base, and deployment geography. Product, engineering, and legal need to sign off jointly - if a model is in scope and no one on one of those three teams can explain what it does, the inventory is not complete.

Step 2 - Check Article 5 before anything else

Before Annex III, run every system through Article 5, the list of prohibited practices that has been in force since 2 February 2025. Article 5 catches subliminal manipulation causing harm, exploitation of vulnerabilities, social scoring by public authorities, predictive policing based solely on profiling, untargeted facial recognition database scraping, emotion recognition in workplaces and educational institutions (narrow exceptions apply), biometric categorisation using sensitive attributes, and real-time remote biometric identification in public spaces for law enforcement (with narrow exceptions). Prohibited practices carry the top-tier Article 99(3) penalty - up to €35 million or 7% of worldwide turnover.

Step 3 - Map each system to Annex III categories

Cross-reference each surviving system against the eight Annex III categories above. Document each match with the specific sub-point you believe applies (for example, "Annex III, point 4(a) - recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates"). If no match, move the system out of the high-risk track and record the reasoning; it may still have transparency obligations under Article 50, which applies in parallel.

Step 4 - Test against the Article 6(3) exceptions

For each Annex III match, ask the four Article 6(3) questions in turn. An AI system is not high-risk if it does not pose a significant risk of harm - including by not materially influencing decision outcomes - and it falls into one of these:

  • Narrow procedural task.
  • Improving the result of a previously completed human activity.
  • Detecting decision-making patterns or deviations from prior decision-making patterns, without replacing or influencing the human assessment without proper human review.
  • Performing a preparatory task for an assessment relevant to use cases listed in Annex III.

Then apply the profiling override: if the system profiles natural persons as defined in GDPR Article 4(4), the exception is unavailable regardless of the four conditions above. Record the evidence in a formal assessment memo. Under Article 6(4), a provider claiming the exception must document the assessment before placing the system on the market or putting it into service - and must register the system in the EU database under Article 49(2) with a public summary of the justification (Annex VIII, Section B, point 7). Relying on the exception without this paper trail is one of the sharper enforcement risks, because Article 80 gives national authorities a specific procedure to review such self-classifications.

Step 5 - Activate the high-risk compliance stack

For every confirmed high-risk system, stand up the Section 2 requirements:

  • Article 9 - risk management system across the lifecycle.
  • Article 10 - data and data governance (representativeness, bias examination, documentation of collection and labelling).
  • Article 11 - technical documentation per Annex IV.
  • Article 12 - automatic logging, technically built into the system.
  • Article 13 - transparency and instructions for use for deployers.
  • Article 14 - human oversight design.
  • Article 15 - accuracy, robustness, and cybersecurity.

Then run conformity assessment (typically internal control under Annex VI for Annex III systems, notified-body involvement under Annex VII for remote biometric identification), draw up the EU declaration of conformity, affix the CE marking, and register the system in the EU database under Article 49. Assign a compliance owner and a review cadence. Note that Article 27 also obliges certain deployers - public bodies, private operators providing public services, and deployers of specified credit and insurance systems - to carry out a Fundamental Rights Impact Assessment before first use.

Provider versus deployer liability

Classification alone does not settle who is on the hook. Role determination under Article 25 matters just as much:

  • A provider develops or has developed an AI system or GPAI model and places it on the EU market or puts it into service under its own name or trademark. Providers carry the full Section 2 compliance load, maintain a quality management system, complete conformity assessment, and register systems in the EU database.
  • A deployer uses an AI system under its authority. Deployers carry the operational duties in Article 26: follow the provider's instructions, assign competent human oversight, ensure representative input data where they control it, monitor operation, report serious incidents, and retain automatically generated logs for at least six months.
  • A deployer can flip to provider status under Article 25(1) by putting its own name or trademark on a high-risk system, substantially modifying it, or changing its intended purpose in a way that makes it high-risk.

Fines for provider or deployer breaches of Articles 16, 22, 23, 24, 26, or 50 reach €15 million or 3% of worldwide annual turnover, whichever is higher, under Article 99(4). SMEs and start-ups pay the lower of the two under Article 99(6). Extraterritorial reach applies whenever the output of a system is used in the EU - a US headquarters offers no shield.

An illustrative scenario

The following is a hypothetical constructed to illustrate how the rules interact. It does not describe any real enforcement action.

Imagine a US HR SaaS company launches an AI talent-acquisition platform that parses résumés, scores candidates on inferred personality traits, and ranks shortlists. A French multinational deploys it for a large hiring round. A rejected candidate files a complaint with the French national competent authority under Article 85. The authority opens a procedure under Article 79.

Under Annex III point 4(a), the system is squarely in the recruitment category. Because it scores candidates on inferred personality traits, it performs profiling within the GDPR Article 4(4) meaning - so no Article 6(3) exception is available. As the party placing the system on the EU market under its own brand, the US company is the provider under Article 25 and carries the Article 16 obligations. If the authority finds the provider cannot produce the Article 10 bias examination records, the Article 11 technical file, or the Article 12 logs, it can issue an administrative fine in the Article 99(4) tier (up to €15 million or 3% of turnover) and order the system withdrawn from the EU market until conformity is restored. In practice, the larger cost in this class of scenario is usually the commercial fallout - contract cancellations by EU customers whose own compliance teams demand documentary evidence for renewal.

Classification FAQ

How do I determine whether my SaaS tool qualifies as high-risk under Annex III when customers control deployment?

Classification follows the intended purpose declared by the provider in its documentation, not who operates the tool in practice. A recruitment evaluator or credit-scoring engine is Annex III regardless of which customer deploys it. A provider cannot shift classification exposure to deployers through contract terms; what it can allocate is operational compliance work via clear instructions for use and data flow obligations.

Can I claim an exemption for an AI that only assists human reviewers without replacing decisions?

Sometimes - but narrowly. Article 6(3)(b) covers systems that improve the result of a previously completed human activity; Article 6(3)(c) covers systems that detect decision-making patterns or deviations without replacing or influencing human assessment without proper human review. The exception is unavailable if the system performs profiling or materially influences the decision outcome. Document the human review process rigorously, register the exemption in the EU database under Article 49(2), and keep the evidence ready for an Article 80 review.

Does compliance with California or Colorado AI laws satisfy Annex III requirements?

No. Colorado SB 24-205 (effective 30 June 2026) focuses on algorithmic discrimination disclosures and duties of care around consequential decisions. California's CCPA/CPRA framework and the California Privacy Protection Agency's automated decision-making regulations cover notice, opt-out, and risk assessments. Neither imposes conformity assessment, CE marking, or EU database registration. Treat US state compliance as a baseline and layer EU requirements on top if you serve both markets.

When must I register a borderline high-risk system in the EU database?

Two separate registration obligations exist. If you confirm the system is high-risk, the provider must register before market placement under Article 49(1). If you claim the Article 6(3) exception, you must still register under Article 49(2), including a public summary of the justification per Annex VIII, Section B, point 7. Public-authority deployers have a separate registration duty under Article 49.

Is the August 2026 deadline still real as of April 2026?

Legally, yes - until the Digital Omnibus is adopted. The Commission proposed the delay on 19 November 2025. The Council of the EU adopted its position on 13 March 2026 (stand-alone high-risk: 2 December 2027; embedded: 2 August 2028). The European Parliament voted on its position on 26 March 2026. Trilogue is ongoing. EU procurement teams are writing AI Act evidence requirements into contracts independently of the political timeline.

The bottom line

Annex III classification is not a regulatory checkbox - it is the gate that decides documentation scope, product architecture, customer contract language, and long-term EU market access. The companies that conduct structured classification assessments early can scope technical documentation accurately, allocate compliance budget proportionately, and put evidence in front of EU buyers when procurement asks. The companies that postpone classification end up doing it under pressure during sales cycles, audits, or incident reviews - which is exactly when it is most expensive to get wrong.

As of April 2026, the Commission's Article 6 guidelines are late, the Digital Omnibus may or may not push stand-alone high-risk obligations to December 2027, and national enforcement infrastructure is uneven across Member States. None of that changes what a defensible classification memo looks like. Intended purpose, Annex III fit, Article 6(3) analysis, profiling check, documented assessment, database registration if applicable - that sequence still holds, regardless of which deadline applies in the end.

Last updated: April 2026. This article is educational content and is not legal advice. Obligations depend on jurisdiction, system classification, and business model. Consult qualified counsel before making compliance decisions.