Module 1 — Are You a Provider, and by Which Route?

Module 1 of the AI Act Provider certification: Art. 3(3), placing on the market versus putting into service, inheriting provider status through Art. 25, and the fork between the Annex I and Annex III regimes.

Before any of Chapter III matters, two questions have to be settled: are you a provider at all, and if so, which of the two high-risk regimes governs the system. Getting the second wrong sends a team down a conformity assessment route that does not apply to them, which is expensive in a way that only becomes visible late.

Art. 3(3), read carefully

'provider' means a natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge.

Four things are absent from that definition, and each absence catches someone.

Nothing about writing the code. "Or that has an AI system developed" covers commissioning. If you contracted a consultancy to build a system and you put it into service under your name, you are the provider and they are not.

Nothing about selling. "Whether for payment or free of charge" removes any commercial threshold.

Nothing about the market. Putting into service is defined as supplying for first use directly to the deployer or for own use. An internal model deployed to your own staff has been put into service. You are its provider.

Nothing about size. There is no SME exemption from provider status. There are proportionality allowances inside some obligations, and simplified documentation arrangements for smaller providers, but the status itself does not scale.

Placing on the market versus putting into service

The two concepts do different work.

Placing on the market — the first making available of an AI system on the Union market. This is the trigger most obligations are written against: the technical documentation must be drawn up before it, the declaration of conformity signed before it, the CE marking affixed before it.

Putting into service — supply for first use directly to the deployer or for own use, for the intended purpose. This is the route by which an organisation that never sells anything becomes a provider.

Both matter for a second reason: they fix the moment at which the system's compliance is assessed. A system placed on the market compliant does not become non-compliant because the law later changed — but a substantial modification re-opens the question, which Module 8 returns to.

Inheriting provider status through Art. 25

You can become the provider of a system somebody else built. Art. 25 makes a distributor, importer, deployer or other third party the provider of a high-risk system where it:

• puts its own name or trademark on a system already placed on the market;
• makes a substantial modification to a high-risk system that remains high-risk;
• modifies the intended purpose of a system — including a general-purpose AI system not classified as high-risk — so that it becomes high-risk.

The consequence is the whole of Art. 16, which is the whole of this track. Organisations meet this most often through the third trigger and through ordinary product evolution rather than through a decision.

Where Art. 25 fires, the original provider must cooperate closely and make available the information and technical access reasonably needed — unless it clearly specified that its system is not to be changed into a high-risk one. That final clause is why supplier terms increasingly say exactly that, and why the cooperation you need belongs in the contract rather than in a statutory duty you would have to argue for.

The fork: Annex I or Annex III

Art. 6 creates two routes into high-risk, and they behave differently.

Art. 6(1) — the Annex I route. An AI system is high-risk where it is intended to be used as a safety component of a product, or is itself a product, covered by the Union harmonisation legislation listed in Annex I — machinery, toys, lifts, radio equipment, medical devices, in-vitro diagnostics, civil aviation, motor vehicles, marine equipment and others — and that product is required to undergo a third-party conformity assessment under that legislation.

Consequences: the AI Act requirements are integrated into the existing sectoral conformity assessment rather than run alongside it, and the obligations apply from 2 August 2028.

Art. 6(2) — the Annex III route. A system is high-risk if it falls in one of the eight Annex III areas: biometrics; critical infrastructure; education and vocational training; employment and worker management; access to essential private and public services; law enforcement; migration, asylum and border control; administration of justice and democratic processes.

Consequences: conformity assessment normally by internal control under Annex VI, and obligations from 2 December 2027.

The practical test is whether the AI is functioning inside a product that already has its own CE regime. A diagnostic algorithm inside a medical device is Annex I. A CV screening tool sold as software is Annex III. A model that does both — say, a device-embedded algorithm also sold as a standalone service — is two products and needs two answers.

The Art. 6(3) filter, from the provider's side

Art. 6(3) allows a system in Annex III to be treated as not high-risk where it does not pose a significant risk of harm to health, safety or fundamental rights, including by not materially influencing the outcome of decision making, and where one of four conditions is met: narrow procedural task; improvement of the result of a previously completed human activity; detection of decision-making patterns or deviations without replacing or influencing previously completed human assessment; or a preparatory task to an assessment.

Two provider-side facts.

Profiling voids it. A system that performs profiling of natural persons is always high-risk. No condition survives.

Invoking it is not free. Art. 6(4) requires the provider to document the assessment before placing the system on the market and to register the system under Art. 49(2). You appear in the EU database either way. The derogation reduces the obligation set; it does not make you invisible, and a deployer doing proper diligence will ask you for both artefacts.

What to settle before development starts

Four determinations, written down, dated, and named against the version of the law they were made under:

1. Are we the provider? Under which limb — development, commissioning, or Art. 25 inheritance.
2. Which route? Annex I or Annex III, and if Annex I, which listed legislation.
3. Which Annex III point, and does a carve-out apply? The fraud-detection carve-out in 5(b) and the 1:1 verification carve-out in point 1 decide a great many real cases.
4. Are we relying on Art. 6(3)? If so, who is producing the Art. 6(4) documentation and when.

Deciding these after the model is built means retrofitting Art. 10 data governance onto a dataset assembled without it, which is the single most expensive rework in this field.

Check yourself

1. A consultancy built our system; we deployed it under our brand. Who is the provider? — You are. Art. 3(3) covers having a system developed and putting it into service under your own name.
2. We never sell the system, we only use it internally. — Putting into service includes own use. You are the provider.
3. Our algorithm is embedded in a Class IIa medical device. — Annex I route, integrated with the medical devices conformity assessment, obligations from 2 August 2028.
4. We are relying on Art. 6(3), so we have nothing to file. — Art. 6(4) requires documented assessment before market placement and registration under Art. 49(2).

Next: Module 2 — The risk management system (Art. 9) →