Provider — EU AI Act Definition, Obligations, and the Article 25 Role-Shift

Under Regulation (EU) 2024/1689, a provider is any natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model — or has one developed — and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge. The provider sits at the top of the EU AI Act's obligation stack. If your organisation falls into this category for a high-risk system, the compliance burden is substantial and begins well before launch.

The EU AI Act definition

Article 3, point 3 of Regulation (EU) 2024/1689 defines a provider as:

"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 that system or model on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge"

Three elements determine whether you are a provider. First, development — you built the AI system, or contracted a third party to build it on your behalf. Second, commercialisation — you place it on the market or put it into service. Third, attribution — it goes out under your name or trademark.

That last element is the one that creates the most confusion in practice. If a software company integrates a third-party model into its product and ships that product to customers under its own brand, the software company is the provider of the resulting AI system, even though it did not train the underlying model itself. The Act follows the name on the box, not the origin of the weights.

The definition also covers general-purpose AI (GPAI) models, which are governed under Chapter V (Articles 51–56). This glossary entry focuses on the provider obligations that apply to AI systems, particularly those classified as high-risk under Article 6 and Annex III.

What a provider must do

For high-risk AI systems, Article 16 sets out the full provider obligation stack. It is not a short list.

Risk management system (Article 9). Before a high-risk system goes to market, you must establish, implement, document and maintain a risk management system covering the entire lifecycle. The system must identify and analyse known and reasonably foreseeable risks, estimate the probability and severity of harm, and specify risk-mitigation measures. This is an ongoing obligation — not a pre-launch checkbox.

Technical documentation (Article 11 and Annex IV). You must draw up technical documentation before placing the system on the market, covering the nine content areas specified in Annex IV: the system description and intended purpose, design and development process, training data and methodology, validation and testing results, monitoring and post-market plan, and more. This documentation must be kept up to date throughout the system's lifecycle and retained for ten years after the last system is placed on the market (Article 18).

Data and data governance (Article 10). Training, validation and testing datasets must meet quality criteria: they must be relevant, sufficiently representative, and free of errors and gaps to the extent possible. Specific requirements apply where sensitive personal data is used for bias detection.

Record-keeping and logging (Article 12). High-risk systems must be capable of automatically generating logs — the technical capacity to reconstruct the circumstances surrounding incidents or non-conformities.

Transparency toward deployers (Article 13). The system must be transparent enough for deployers to understand its capabilities and limitations and use it as intended. You must supply instructions for use that, among other things, specify the intended purpose, the level of accuracy, and known risks when used as intended.

Human oversight (Article 14). Systems must be designed so that natural persons can effectively oversee the system's operation, intervene in real time, and override or halt it. This is a design requirement, not just a policy commitment.

Accuracy, robustness and cybersecurity (Article 15). High-risk systems must achieve appropriate levels of accuracy for their intended purpose and be resilient against errors, faults, and attempts by third parties to alter their outputs.

Quality management system (Article 17). You must put in place a quality management system covering policies, techniques, systematic actions, and procedures for high-risk AI — documented, proportionate to your size.

Conformity assessment (Article 43). Before placing a high-risk system on the market, you must undergo conformity assessment. For most Annex III categories (points 2–8: critical infrastructure, education, employment, access to services, law enforcement, migration, justice), the route is the internal control procedure set out in Annex VI. For biometrics (Annex III, point 1), where harmonised standards are not applied, the notified-body route under Annex VII is required.

EU Declaration of Conformity (Article 47). Once conformity assessment is complete, you must draw up a declaration of conformity confirming the system meets the requirements of the Regulation. The content of that declaration is set out in Annex V.

Registration (Article 49). Before placing a high-risk system on the market, you must register it in the EU database established under Article 71, unless a market-surveillance authority has granted an exemption.

Post-market monitoring (Article 72). You must establish and maintain a post-market monitoring system that actively collects and analyses data from deployers and users throughout the system's operational life. The data feeds back into the risk management system under Article 9.

Incident reporting (Article 73). You must report serious incidents — defined in Article 3(49) — to the market-surveillance authority of the member state where the incident occurred. The deadlines are tight: 15 days from awareness in most cases, 2 days for incidents involving widespread infringement or serious and irreversible disruption to critical infrastructure, and 10 days where a person has died.

The penalty exposure for providers who fail these obligations is real. Under Article 99(4), non-compliance with most provider obligations carries a maximum fine of €15,000,000 or 3% of total worldwide annual turnover in the preceding financial year, whichever is higher. For companies that are SMEs or start-ups, Article 99(6) caps the fine at the lower of the percentage or the fixed amount — a proportionality protection, not an exemption.

One practical note on the timing: under the Digital Omnibus agreed in May 2026, the high-risk obligations apply from 2 December 2027 for stand-alone Annex III systems, and from 2 August 2028 for high-risk AI embedded in regulated products under Annex I. The original 2 August 2026 deadline has been deferred. That is a meaningful extension, but the technical documentation under Annex IV, the risk management system under Article 9, and the conformity assessment under Article 43 all take months to assemble properly. Starting now is not early.

Provider vs deployer (and the Article 25 role-shift)

The EU AI Act draws a sharp line between providers and deployers. A deployer (Article 26) is a natural or legal person that uses a high-risk AI system under its authority in a professional context, for purposes other than personal non-professional use. Deployers carry real obligations — they must follow the provider's instructions for use, ensure human oversight is in place, monitor the system's operation, and retain logs for at least six months. If a deployer serving the public carries out a fundamental rights impact assessment under Article 27. But the deployer does not bear the Article 16 stack: no conformity assessment, no Annex IV technical documentation, no EU Declaration of Conformity, no registration obligation.

The distinction matters most for companies that buy and deploy third-party AI tools. A regional bank that licenses a creditworthiness-scoring model from a specialist vendor and runs it under that vendor's instructions is almost certainly a deployer, not a provider. The vendor who built and markets the model is the provider and carries the full Article 16 burden.

That line can shift, and Article 25 is the mechanism. Three situations convert a deployer, importer, or distributor into a provider, with the full provider obligation stack following:

1. Rebranding. You place a high-risk AI system on the market or put it into service under your own name or trademark.
2. Substantial modification. Defined in Article 3(23), a substantial modification changes the system's performance or intended purpose in a way that affects its compliance with the high-risk requirements. If you substantially modify a system you obtained from a third party, you become the provider of the modified system.
3. Change of intended purpose. If you put a system into service for a purpose other than the high-risk purpose for which it was already placed on the market, and that new purpose is itself high-risk, you acquire the provider obligations for that new deployment.

Article 25 also allocates residual provider responsibilities: where a provider is based outside the EU and has not designated an EU-authorised representative under Article 22, the importer carries those responsibilities on the EU market.

In practice, the Article 25 role-shift catches companies that white-label AI systems, integrate third-party models into their own products and ship those products under their own name, or repurpose a general tool for a regulated purpose. A SaaS company that integrates an AI hiring assistant into its HR software and ships it to customers is the provider of that hiring assistant — regardless of which underlying model the assistant runs on.

Examples

Company A: HR-tech firm shipping a CV-screening feature. A 60-person HR-tech company builds a feature that automatically screens and scores job applications, then sells its HR platform to employers under its own brand. The CV-screening feature falls under Annex III, point 4(a) — recruitment and selection. The company is the provider. It must complete a conformity assessment (Annex VI internal self-assessment), produce Annex IV technical documentation, draw up an Article 47 Declaration of Conformity, and register the system in the EU database under Article 49. It must maintain a post-market monitoring system under Article 72. The compliance deadline is 2 December 2027 under the Digital Omnibus. The company's customers — employers using the feature — are deployers under Article 26.

Company B: a deployer who rebrands a vendor system. A financial-services firm licenses a credit-risk model from a specialist AI vendor. The model is already CE-marked by the vendor (the provider). The financial-services firm deploys the model internally, following the vendor's instructions, without placing it on the market under its own name. It is a deployer. Its obligations under Article 26 apply: follow the instructions, assign human oversight, monitor and log, flag incidents to the provider. It does not owe conformity assessment or Annex IV documentation.

Now the firm decides to package the model and offer it as a service to smaller lenders under its own brand. The moment it places the model on the market under its name, Article 25 activates: it becomes a provider. It must now assume the Article 16 stack — including a fresh conformity assessment, because the original CE marking was the vendor's, not theirs.

Frequently Asked Questions

Q: We built an AI tool for internal use only, not sold to anyone. Are we still a provider?

The definition in Article 3, point 3 refers to placing a system "on the market" or putting it "into service." Internal deployment — using your own AI system within your own organisation, by your own staff — counts as putting it into service. If the system falls under high-risk categories (Article 6 and Annex III), you carry the provider obligations even if no commercial sale occurs. However, public authorities deploying high-risk systems solely for their own purposes may be subject to a streamlined process in certain circumstances — verify the specific carve-outs in Articles 16 and 17.

Q: We integrate an external AI model into our SaaS product. Are we the provider or is the model vendor?

You are the provider of the AI system you ship to your customers, even if it runs on a third-party model. Article 25 is clear: placing a system on the market under your name makes you the provider of that system. The model vendor retains its own obligations as a GPAI model provider under Articles 53 and 55, but the provider of your SaaS product — responsible for Article 16 compliance — is you.

Q: We substantially modified a third-party AI system. Does the original vendor's CE marking still cover us?

No. Under Article 25, a substantial modification (defined in Article 3(23)) transfers provider status to the entity that made the modification. The original conformity assessment and CE marking cover the unmodified system. You must carry out your own conformity assessment for the modified version, draw up a new Declaration of Conformity under Article 47, and re-register the system under Article 49.

Q: What is the fine exposure if we fail our provider obligations?

For non-compliance with the high-risk requirements and most other provider obligations (Articles 16, 17, 22, 23, 24, 25, 26), the maximum under Article 99(4) is €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For SMEs and start-ups, Article 99(6) caps the fine at the lower of the two figures. Supplying incorrect or misleading information to a notified body or competent authority is a separate, lower tier: €7,500,000 or 1% under Article 99(5).

Q: Our system might qualify for the Article 6(3) exemption from high-risk classification. Does that affect our provider obligations?

Yes, substantially. The Article 6(3) filter means that an Annex III system that poses no significant risk of harm to health, safety or fundamental rights — for example, because it performs a narrow procedural task or merely improves an outcome already completed by a human — is not treated as high-risk. If you can document that assessment, the Article 16 stack does not apply. But two conditions follow: you must document the assessment in writing and register the system in the EU database under Article 49. And any system that profiles natural persons is always high-risk, regardless of the Article 6(3) assessment.

Q: When do the provider obligations actually apply?

For AI systems classified as high-risk under Annex III (the stand-alone list — recruitment, credit, biometrics, law enforcement, etc.), the obligations apply from 2 December 2027, under the Digital Omnibus agreed in May 2026. For high-risk AI embedded in regulated products covered by Annex I product safety law (medical devices, machinery, vehicles), the date is 2 August 2028. Both dates replace the original 2 August 2026 deadline, which was deferred. The prohibitions under Article 5 — including prohibited uses of biometrics and social scoring — have been in force since 2 February 2025.

Related terms

• Provider vs deployer — role comparison
• Provider obligations under Article 16
• Article 16 — provider obligations explained
• Deployer — definition and obligations
• Operator — how the EU AI Act uses the term
• Substantial modification — Article 3(23) and the role-shift trigger