EU AI Act Article 25. When a deployer or distributor becomes the provider.

Article 25 is addressed to the entire supply chain, not only to providers. It is the mechanism by which the EU AI Act reaches parties who did not develop an AI system but who deploy, rebrand, or modify it in ways that make them responsible for its conformity. For fine-tuners, white-label buyers, and deployers who repurpose AI for high-risk applications, this provision is the single most consequential in the Act.

The four triggers in Article 25(1)

Article 25(1) operates as an exhaustive list of the conditions under which a non-provider becomes a provider. The triggering actors are any distributor, importer, deployer, or other third party in the value chain. The act does not limit the provision to commercial actors: a large enterprise integrating a third-party AI tool into an internal HR process and making a substantial modification in the process of doing so will become a provider under Article 25(1)(c).

The four triggers in sequence are as follows. First: placing a high-risk AI system on the market or putting it into service under the actor's own name or trademark, regardless of whether a contractual arrangement exists with the original developer. Second: modifying the intended purpose of a high-risk AI system already placed on the market or put into service. Third: making a substantial modification to a high-risk AI system already placed on the market or put into service. Fourth: modifying a general-purpose AI model such that it becomes a high-risk AI system as referred to in Article 6 of the Act.

Each trigger is independent. Meeting one is sufficient to assume full provider obligations. The analysis below reads each in turn.

Trigger one: rebranding under your own name or trademark

Article 25(1)(a) is the rebranding trigger. Any party that places a high-risk AI system on the market or puts it into service under their own name or trademark is treated as the provider for the purposes of the Act. The article makes no exception for parties who disclose that the underlying system was developed by another party.

This provision captures the white-label AI market directly. A legal tech company that purchases an AI contract review engine from a foundation model provider and presents it to clients under its own product name is a provider under Article 25(1)(a) from the moment of first client deployment. It must conduct its own conformity assessment, draw up its own declaration of conformity, affix the CE marking, and satisfy all Article 16 provider obligations. The contract with the original developer does not transfer these obligations: it creates them for the rebranding party.

The original developer does not thereby cease to be a provider for its own version of the system. Both parties hold provider obligations independently for the versions they respectively offer. This creates a practical question about the allocation of conformity assessment documentation, which Article 25(2) addresses by imposing an information transfer duty on the upstream developer.

Trigger two: modifying the intended purpose

Article 25(1)(b) addresses purpose modification. The intended purpose is the use for which an AI system is designed as specified by the provider in the instructions for use, technical documentation, and marketing materials. A system placed on the market for administrative scheduling is not high-risk. The same system repurposed by a deployer to screen job applications falls under Annex III, point 4, and becomes high-risk at the moment of that repurposing.

The deployer who changes the intended purpose does not need to modify the system technically. The reclassification from non-high-risk to high-risk is triggered by the change in use, not the change in code. A legal services firm that takes a general document summarisation tool and integrates it into a process that makes recommendations affecting access to justice is potentially within Annex III, point 8. It should conduct a purpose-modification analysis before deployment, not after.

The practical challenge of trigger two is that many deployers do not have formal processes for assessing whether an intended-purpose modification has occurred. Procurement teams approve AI tools against stated product descriptions. The actual deployment context is decided by operational teams months later. A compliance gap between procurement approval and operational deployment is the most common Article 25(1)(b) exposure in enterprises using general-purpose AI.

Trigger three: substantial modification

Article 25(1)(c) is the provision most directly relevant to the fine-tuning and customisation market. A substantial modification of a high-risk AI system already placed on the market or put into service triggers full provider status. The definition of substantial modification in Article 3(23) sets two alternative criteria: a change that affects the system's compliance with the requirements of Chapter III, Section 2; or a change that results in a change to the intended purpose.

The AI Office has issued guidance on what constitutes a substantial modification. The guidance identifies the following as potentially substantial: fine-tuning on new domain data that materially shifts the distribution the system was validated on; changes to the loss function or objective; integration of additional input modalities; expansion to a significantly different user population; and integration into a system architecture that alters how outputs are used. Routine software updates that maintain operating conditions and performance within the validated range are not substantial modifications.

The practical test that emerges from Article 3(23) and the AI Office guidance is whether the fine-tuner or integrator's changes require a new or updated conformity assessment to establish that the modified system still meets the Chapter III, Section 2 requirements. If the answer is yes, the modification is substantial and the modifying party becomes the provider. The original provider's conformity assessment documents do not cover the modified system.

For context on the Article 9 risk management system that a new provider must build after Article 25 is triggered, see the Article 9 risk management system analysis.

Trigger four: general-purpose AI models repurposed as high-risk systems

Article 25(1)(d) extends the value-chain analysis to the general-purpose AI model market. Where a party modifies a general-purpose AI model such that it becomes a high-risk AI system within the meaning of Article 6, that party becomes the provider of the high-risk system. This trigger is distinct from Articles 51 to 56, which govern GPAI model obligations for the model developer. Article 25(1)(d) governs the downstream party who converts a GPAI model into a high-risk application.

The practical scenario is a developer who takes a large language model and fine-tunes it for use in credit scoring, biometric identification, or an employment decision context. The LLM provider has its own GPAI obligations under Articles 53 and 55. The fine-tuner who creates a high-risk application on top of that model is the provider of the high-risk application and holds full Chapter III obligations for it, independent of whatever the LLM developer's own compliance posture is.

This creates a stacked liability structure: the LLM developer holds GPAI provider obligations, and the fine-tuner holds high-risk AI system provider obligations. Article 25(2) addresses the information flow that makes this workable in practice.

Article 25(2): The contractual information duty

Article 25(2) requires providers to make available to distributors, importers, and deployers all the information necessary for those parties to comply with their respective obligations under the Act. This is a statutory duty on the upstream party, not a negotiating position for the downstream party. The information transfer must happen; the question is only whether it happens by voluntary contractual provision or by regulatory enforcement.

The minimum package of information that Article 25(2) requires in the context of a high-risk AI system deployment includes: the instructions for use required under Article 13 and Annex XIII; the technical documentation required under Article 11 and Annex IV, to the extent necessary for deployer compliance; the conformity assessment documentation and EU declaration of conformity; and information about the intended purpose, validated operating conditions, and any known limitations or accuracy levels at which the system was assessed.

Contracts between AI providers and enterprise deployers routinely fail to include this package. Standard SaaS agreements often include an API reference, a data processing agreement, and a limitation of liability clause. They rarely include a structured transfer of the Article 25(2) information set. Deployers who have signed such agreements should treat this as a gap in their compliance position, not as a completed step.

For distributors and importers, Article 25(2) also means that they hold a right to request and receive this information from the provider. Distributors who cannot obtain the Article 25(2) package from a provider cannot satisfy their own obligations to verify that the system has undergone a conformity assessment and that the relevant documentation is available.

The Article 16 provider obligations analysis covers the full set of obligations that a party assuming provider status under Article 25 must then satisfy. See the Article 16 analysis for the complete provider obligation set.

Liability allocation across the value chain

Article 25 does not establish an express liability allocation regime between value chain participants. What it does is establish which party holds provider obligations at each point in the chain. The liability that flows from those obligations then applies to that party.

The allocation logic can be stated in three layers. The original developer holds provider obligations for the system as it was placed on the market, including the conformity assessment, the technical documentation, and the system-level performance claims. A fine-tuner who makes a substantial modification under Article 25(1)(c) becomes the provider of the modified system and holds provider obligations for everything that changed. The original developer's conformity assessment no longer applies to the modified system. The deployer holds deployer obligations under Article 26 for how they use the system within the parameters the provider has assessed, and becomes a provider under Article 25(1)(b) if they modify the intended purpose.

Where a failure occurs, the supervisory authority will trace the failure to the responsible layer. If a high-risk AI system produces a discriminatory outcome that results from a flaw in the original training data, the original developer is exposed even if the deployer holds Article 25 provider status for a subsequent modification. If the outcome results from a deployment outside the instructions for use, the deployer holds primary exposure under Article 26(1). If the outcome results from a fine-tuner's modifications, the fine-tuner is exposed as the Article 25(1)(c) provider.

The penalties under Article 99 of Regulation (EU) 2024/1689 apply to the actor in breach of their obligations. The top tier, up to EUR 35 million or 7 per cent of worldwide annual turnover, applies to placing non-compliant high-risk AI systems on the market. The second tier, up to EUR 15 million or 3 per cent, applies to failure to satisfy provider or deployer obligations. Where multiple actors in the chain have failed in their respective obligations, multiple penalty proceedings can run in parallel.

The Product Liability Directive layer

Article 25 of the EU AI Act allocates regulatory obligations. Product Liability Directive 2024/2853 (PLD) operates in parallel and allocates civil liability for damage to natural persons caused by defective products, including AI systems and software.

Under PLD Article 4, the manufacturer of a defective product is liable for damage caused by the defect. An AI system that produces a harmful output due to a defect introduced at the foundation model level will expose the original developer to PLD claims even where the deployer holds the Article 25 provider role for a modified version. PLD Article 4 also makes importers and authorised representatives liable where the manufacturer is not established in the EU. Distributors and deployers who modify the product in a way that makes them subject to the same obligations as a manufacturer are also exposed.

The intersection of Article 25 and the PLD creates a situation where an enterprise fine-tuner faces both regulatory exposure as an Article 25 provider and civil liability exposure as a PLD manufacturer. These are not alternative exposure routes: the same act of substantial modification that triggers Article 25(1)(c) can simultaneously trigger PLD manufacturer status. Insurance coverage designed for AI operator exposure must be evaluated against both regimes. Products such as Munich Re's aiSure and Armilla's model performance warranties address elements of this combined exposure. Lloyd's syndicates and Counterpart have developed endorsements addressing AI regulatory penalty exposure, though coverage terms vary materially by policy form. Current availability and scope should be confirmed with a specialist broker.

High-risk repurposing: the critical practical scenario

The scenario that most consistently triggers Article 25 in enterprise environments is the high-risk repurposing of a general-purpose AI tool. An organisation licenses a document analysis tool from an AI vendor for contract review. Several months into deployment, the same tool is used by HR to screen CVs against job descriptions. The tool was not assessed for employment decision use. Annex III, point 4 of Regulation (EU) 2024/1689 covers AI systems used for recruitment and selection purposes. The deployer has changed the intended purpose within the meaning of Article 25(1)(b) and become the provider of a high-risk AI system.

In this scenario the organisation must: conduct or commission a conformity assessment for the employment use case; draw up a declaration of conformity; affix the CE marking if placing on the EU market (or satisfy the equivalent internal deployment conditions); register in the EU database under Article 26(10) if the deployer is a public authority or the system falls within Annex III, point 1; and satisfy all Article 16 provider obligations going forward. The vendor from whom the licence was purchased does not hold these obligations and cannot satisfy them on the organisation's behalf.

The cases Moffatt v. Air Canada (British Columbia Civil Resolution Tribunal, 2024) and Mata v. Avianca (SDNY, 2023) are instructive on the direction of travel in AI responsibility attribution, though they arise in non-EU jurisdictions. Both cases turned on the question of which organisational actor could be held accountable for the AI output that caused harm. The EU AI Act resolves this question structurally through Article 25: the actor who placed the system in its current form into service is the provider and holds primary regulatory accountability.

Building Article 25 into procurement and onboarding

The practical implication of Article 25 is that AI procurement, integration, and onboarding workflows must include an Article 25 screening step. Before a system is deployed or modified, the deployer should assess: does the deployment or modification meet any of the four Article 25(1) triggers? If yes, what are the provider obligations that now apply? Is the organisation prepared to satisfy those obligations, including conformity assessment, technical documentation, CE marking, and registration?

Supply contracts with AI vendors should include: an explicit representation from the vendor as to the system's intended purpose and the scope of the conformity assessment; a structured information transfer under Article 25(2) as a contract deliverable; notification obligations if the vendor makes changes to the system that may affect the deployer's compliance position; and an allocation of indemnity and cost-sharing for regulatory proceedings arising from failures in each party's respective layer.

Where an organisation anticipates making substantial modifications, the contract should also address access to the technical documentation required for the new conformity assessment, co-operation obligations during any market surveillance investigation, and the transfer or licence of any test data or validation records that the fine-tuner will need to establish its own compliance record.

For the full deployer obligation set that applies once an organisation is operating a high-risk AI system, whether as an original deployer or as an Article 25 provider, see the complete Article 26 analysis.