Article 25 AI Act value chain responsibilities

Article 25 AI Act value chain responsibilities: what it asks and why it catches teams off guard

Teams that buy, rebrand, modify or repurpose an AI system need to answer one question before they ship: have they inherited the provider's duties? Under Article 25(1), a distributor, importer, deployer or other third party becomes the provider of a high-risk system in three situations: it puts its own name or trademark on the system, it makes a substantial modification that keeps the system high-risk, or it changes the intended purpose of a system that was not high-risk so that it becomes high-risk. The third trigger explicitly covers a general-purpose AI system. Article 25(3) adds a separate rule for Annex I Section A products: the product manufacturer is the provider of a high-risk safety component when that component goes to market under the manufacturer's name or trademark.

The original provider does not walk away when this happens. As amended in 2026, Article 25(2) requires it to cooperate with the new provider by sharing technical documentation, known limitations and failure modes, and targeted technical access for testing. The original provider is released from this duty only if it clearly specified that the system must not be changed into a high-risk system. Teams should check their licence terms, model cards and vendor documentation now for that explicit statement, and confirm with counsel whether the wording is sufficient. Article 25(4) requires providers and third parties supplying AI systems, models, tools, services, components or processes to agree in writing the information, technical access and assistance the parties need. Free and open-source tools are excluded, except general-purpose AI models.

Regulation (EU) 2026/1744 added Article 99(4)(da), which makes breaches of Article 25(2) and 25(4) subject to fines of up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher. The hard part is usually not the paperwork but the timing: the role change is often invisible until a product team ships a feature, retrains a model on new data, rebrands a tool for a client, or points an existing assistant at a hiring or credit decision. Illustratively, a team that adds a scoring step to a general-purpose assistant for loan applications may have become a provider without any contract change. Assign an owner to review every change to purpose, branding and model components before release.

Which parties and changes Article 25 covers in practice

Article 25 shifts provider duties to parties other than the original developer when they put their name on a high-risk system, change it substantially, or repurpose it. The cards below cover each trigger, the supplier side that must sign written terms, and the scoping decisions that determine how much work follows.

Name or trademark on a high-risk system

A distributor, importer, deployer or other third party becomes the provider of a high-risk system when it puts its own name or trademark on it. The original developer's branding no longer appears on the product, so the new provider takes on the full set of provider obligations. Check whether your organization is putting its name on a system built by someone else, including white-label or resold offerings, and whether the marking appears on the product, documentation or user interface. The change in status applies at the point of branding, so the question is answered before the system reaches the market.

Substantial modification that keeps high-risk status

A party that makes a substantial modification to a high-risk system becomes its provider if the system remains high-risk after the change. The scoping decision is whether the change is substantial, which the Act's own definitions and the Commission's guidance will shape. Retraining on new data, altering the model architecture, or widening functions can all fall on either side of the line. Record each change, its assessment and the reasoning behind it, so that you can show why a modification did or did not make you the provider.

Repurposing into a high-risk use

A party that changes the intended purpose of a system that was not high-risk can make it high-risk and become its provider. This applies to general-purpose AI systems as well. A chatbot or document tool that an organization adapts for employment screening, credit decisions or another Annex III use is the typical case. Map each internal use case against the intended purpose and the Annex III categories before deployment, because the same underlying model can be low-risk in one department and high-risk in another.

Annex I Section A product manufacturers

Under Article 25(3), the product manufacturer is the provider of a high-risk safety component of an Annex I Section A product when that product is placed on the market or put into service under its name or trademark. Manufacturers of machinery, medical devices and similar regulated products should confirm which of their safety components use AI and whether the sectoral conformity route already covers their documentation. Ask the component supplier which parts of the technical file it holds and which fall to the manufacturer.

Supplier written terms under Article 25(4)

Providers and third parties that supply AI systems, models, tools, services, components or processes must agree in writing the information, technical access and assistance the high-risk provider needs. Component, model and service suppliers are all in scope. Free and open-source tools other than general-purpose AI models fall outside Article 25(4), so an organization still needs to confirm what it has inherited from them. Ask which contract terms the supplier will accept, how long technical access lasts, and who pays for assistance. The AI Office may publish voluntary model contract terms that can serve as a starting point.

How assessors test Article 25 responsibilities

This table compares five test areas for Article 25: role-change determination, the original provider's cooperation duty, supplier agreements, the Annex I manufacturer rule and 2026 fine exposure. Read each row as a question an authority or notified body will ask, then check the evidence column against your own files before the review starts.

Test area	What the assessor checks	Evidence requested and common findings
Role-change determination	Whether a deployer, importer, distributor or third party put its name or trademark on the system, made a substantial modification that keeps it high-risk, or changed the intended purpose of a non-high-risk system	Dated change log, intended-purpose statement before and after, and the written analysis of whether the change was substantial. Finding: substantial modifications made in a product release without any recorded assessment
Original provider's cooperation package under 25(2)	Whether the initial provider shared technical documentation, known limitations, failure modes and targeted testing access, or had clearly stated the system must not become high-risk	Handover register listing each item, its recipient and date, plus the exclusion notice in the contract if relied on. Finding: an exclusion notice exists but was never added to user documentation or distribution terms
Supplier written agreements under 25(4)	Whether each supplier of models, tools, services, components or processes agreed in writing to provide the information, technical access and assistance the provider needs	Signed agreements with scope clauses covering documentation, access and support. Finding: agreements that omit technical access for testing, or that cover only commercial terms. Confirm whether any open-source component is outside the rule, since it excludes free and open-source tools other than general-purpose AI models
Annex I manufacturer rule under 25(3)	Whether a product manufacturer placing an Annex I Section A product under its name is treated as provider of the high-risk safety component	Product technical file, component register and conformity route for the product. Finding: the safety component is documented as a supplier part, with no owner named for the AI Act provider duties
Dates against the Article 113 timeline	Whether role-change and handover dates fall within the application dates set by Article 113, as amended in 2026	Timeline showing Annex III high-risk rules apply from 2 December 2027 and Annex I product systems from 2 August 2028. Finding: handover documents dated as if the 2026 original dates still applied
2026 fine exposure under Article 99(4)(da)	Whether breaches of 25(2) and 25(4) are covered by the fine tier of up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher	Board-level risk entry linked to the handover and supplier controls, with a named owner. Finding: no owner for supplier agreements, so breaches of 25(4) would not be detected before a review
Review by market surveillance authority or notified body	How the reviewer confirms the role-change decision, asks for handover documents and checks the chain of records from the original provider to the current one	Requests typically cover the role-change memo, handover register, supplier agreements and dated versions. Finding: records exist only as verbal confirmations or as undated email threads
Confirm with counsel and the authority	Whether national market surveillance practice or the AI Office's voluntary model contract terms change what a reviewer expects in the agreement	Written legal opinion on scope, plus any published voluntary terms the AI Office recommends. Confirm current status with the Commission before relying on them

How to implement Article 25 in six steps

This sequence turns Article 25 from a legal question into a working record: every AI system and supplier is known, every role change is decided and written down, and the handover and supplier terms exist before a system reaches the market. Each step closes with a document you can show an authority.

Inventory every AI system and its suppliers
Compile a register of every AI system your organization builds, buys, customizes or operates, including the models, tools, components and hosted services each one depends on. Assign a named owner to each entry and record the supplier behind each dependency. Include open-source components and general-purpose models so that none are missed when the role test runs. This step is done when the AI system inventory lists every system with its owner, intended purpose and supplier chain, and someone outside the project team has reviewed it for gaps.
Classify each system's high-risk status
For each inventory entry, record whether the system is high-risk, and by which route it qualifies: an Annex III use case or a safety component of an Annex I product. Record the intended purpose as written in your documentation, because Article 25 turns on what the system is designed and marketed to do. Ask legal counsel to confirm borderline cases, including any Article 6(3) exemption claim. This step is done when each system carries a documented classification with the reasoning and the approver's name.
Record a role-change decision for each change
For every rebrand, substantial modification or change of intended purpose, open an entry in a role-change register. Note whether your organization placed its name or trademark on the system, whether the change keeps a system high-risk, and whether a non-high-risk system, including a general-purpose AI system, now becomes high-risk. Where the answer is yes, record that your organization is the provider for the purposes of the Act. This step is done when every change in the period has a signed decision, reviewed by legal and product owners.
Issue the 25(2) handover package
Where a new provider takes over a high-risk system from an original provider, the original provider must cooperate under Article 25(2) by sharing technical documentation, known limitations and failure modes, and targeted technical access for testing. Ask the original provider to confirm in writing whether it specified that the system must not be changed into a high-risk system. Assemble the package from the documentation set, and log what was shared, when, and under whose approval. This step is done when the handover package and its transmittal record are filed with the role-change decision.
Put 25(4) written terms in every supplier contract
Under Article 25(4), providers and third parties that supply AI systems, models, tools, services, components or processes must agree in writing the information, technical access and assistance needed for compliance. Add these terms to each supplier agreement that touches a high-risk system, covering documentation, change notices, access for testing and cooperation with authorities. Note that the rule does not apply to free and open-source tools other than general-purpose AI models, so confirm the license and model type for each dependency. Check whether the AI Office's voluntary model contract terms fit your suppliers. This step is done when a supplier agreement register lists each agreement, its covered systems and its signed date.
Set a review trigger in change management
Add a mandatory role test to your change management process so that every release, rebrand, new intended purpose or change to a model or component reruns the classification and role-change steps before deployment. Tie the trigger to the system owner's sign-off, and route any change that could alter high-risk status to legal and compliance. Track the trigger outcomes in the change record so that auditors can trace each decision. This step is done when the change procedure contains the role test, a sample of recent changes shows it was applied, and the register stays current.

Evidence that shows Article 25 compliance and how to keep it current

Article 25 compliance rests on a small set of records that show who holds which role, what was handed over, and what each supplier agreed to. Each record below needs a named owner and a trigger that forces review, so the file stays accurate between audits rather than being rebuilt before one.

AI system inventory with role fields

The inventory lists every AI system in use or in development, with its intended purpose, Annex III or Annex I classification, and the organization's role for each system: provider, deployer, importer, distributor or other third party. The role field is the starting point for any Article 25 question. Keep it current by requiring a new or amended entry whenever a system is rebranded, retrained for a new purpose or changed materially. Check that every entry names a single accountable owner and a review date.

Signed role-change decision records

When your organization puts its name on a system, makes a substantial modification or changes the intended purpose of a system so it becomes high-risk, Article 25(1) may make you the provider. A signed decision record captures the facts, the assessment, the approver and the date. Keep it current by opening a record each time a product change, contract amendment or new use case is reviewed by legal and compliance. Check that records exist for past changes, not only new ones.

Article 25(2) handover index

Where you have become the provider, the original provider must cooperate with you by sharing technical documentation, known limitations and failure modes, and targeted technical access for testing. The handover index lists each item received, its version, the date and the gaps still open. Note any written statement from the original provider that the system must not be changed into a high-risk system. Refresh the index whenever the original provider issues a new documentation version or limitation notice.

Article 25(4) supplier agreement register

Article 25(4) requires providers and third parties supplying AI systems, models, tools, services, components or processes to agree in writing on the information, technical access and assistance needed. The register lists each supplier, the systems it touches, the clauses covering information and access, and the expiry or review date. Free and open-source tools other than general-purpose AI models are excluded from this duty, so record that exclusion with its reasoning. Review the register at each contract renewal and when a supplier changes its model or terms.

Dependency and component bills of materials

A software bill of materials and an AI component inventory show which models, libraries, datasets and services sit inside each system, and which suppliers you depend on for each. These records make the 25(4) register testable. Generate them from build pipelines, not by hand, so each release produces a new record. Tools such as OWASP Dependency-Track consume and produce CycloneDX SBOMs and VEX, and Trivy can produce SBOMs and scan existing ones. Confirm with your engineering team that AI model versions are captured, since those are often missing.

Version history of governance pages

Policies, role definitions, the handover index and the supplier register are only persuasive if you can show what they said at a given date. Version history records each change, who made it and when, and lets reviewers compare versions and restore earlier ones. Keep it current by making page edits go through a named approver and by linking each role-change decision to the page version it affected. Confirm that retention settings keep old versions for as long as your Article 18 retention plan requires.

What Article 25 compliance costs in money and effort

This table compares each cost component of managing an Article 25 role change, who is paid for it, whether it is one-time or recurring, and what drives it up. Use it to build a quote request and to see where open-source tools reduce spend and where staff effort remains. No prices or durations are stated because none are supplied for this topic; ask suppliers and advisers for written figures.

Cost component	One-time or recurring	What drives it	How to keep it down
Internal legal and engineering time for role-change decisions	One-time per change, recurring when products are modified	Number of modifications, whether a change keeps a system high-risk, and whether the intended purpose changes	Set a written decision test for name, trademark, substantial modification and intended purpose before work starts
Contract negotiation with suppliers	One-time per supplier, recurring at renewal	Number of component and model suppliers, depth of technical access requested, and negotiating leverage	Use the AI Office voluntary model terms as a starting draft where they fit, and standardize clauses across suppliers
Handover package for a new provider	One-time per transfer	Volume of technical documentation, known limitations, failure modes and testing access the original provider must share	Maintain the documentation in a versioned form so it can be released without rework
Supplier due diligence	Initial review plus recurring re-checks	Number of suppliers, sensitivity of the component, and how often suppliers change models or versions	Tier suppliers by risk and reuse assessments across systems that share the same component
Bill of materials upkeep	Recurring for the life of the system	Number of dependencies, release frequency, and whether the component inventory is generated automatically	Generate software bills of materials in CI and track them in a vulnerability and license tool, such as Dependency-Track, Trivy or similar, after confirming each tool's current capabilities
External legal or assessment review	Per engagement, sometimes recurring	Whether a notified body is involved, complexity of the contract set, and the number of role changes	Ask for a fixed-scope quote that names the documents reviewed and the number of review rounds
Open-source tooling licenses	Usually no license fee, but hosting and support may recur	Choice of self-hosted platform, infrastructure size and any paid support or retainer	Confirm licenses on each component and budget for hosting, staff time and any support contract separately
Staff effort to operate open-source tools	Recurring	Number of systems tracked, update frequency and integration with existing change management	Automate evidence capture so tools produce records as part of normal engineering work

Who owns Article 25: your team, an implementation partner and the assessor

Your organization owns every decision that determines who is the provider of a high-risk system and who carries the obligations that follow. Article 25 turns on facts about your own conduct: whether you put your name or trademark on a system, whether you made a substantial modification, and whether you changed the intended purpose of a system that was not high-risk. Those facts sit with your product, legal and procurement teams, so the role determination must be made and recorded by people who can answer for it. Negotiating and signing the written agreements with component and model suppliers also stays with you, because only your legal entity can bind itself to those terms.

Role determination: Record which party is the provider for each system, the basis under Article 25(1) or 25(3), and the date the decision was made.
Supplier contracts: Negotiate and sign the written agreements on information, technical access and assistance required by Article 25(4).
Initial provider cooperation: Decide what technical documentation, known limitations and failure modes you will share if you are the original provider under Article 25(2).
Intended purpose statements: Own the wording that states what the system may and may not be used for, since that wording drives the Article 25(2) analysis.
Final declaration of your own controls: Approve and sign off on the controls you claim, and accept accountability for them.

Check that each role determination has a named owner, a legal sign-off and a review date tied to any change in product scope.

Where organizations fall short on Article 25 and how to close each gap

Article 25 turns ordinary product and procurement decisions into provider duties. The gaps below tend to appear quietly in engineering and supplier management, so each one needs a named owner, a recorded decision and a check that runs whenever the system or its components change.

Role changes made without a decision

Teams often rebrand a model-based feature, add their name to a vendor product or repackage a general-purpose system for a new use without recording that they have become the provider under Article 25(1). The fix is a role determination record, signed by legal and the product owner, for every high-risk candidate, stating whether the organization now puts its name or trademark on the system, changes its intended purpose, or substantially modifies it. Review the record at each release.

Substantial modifications shipped as routine releases

A change that keeps a system high-risk and alters its compliance is a substantial modification, and it can shift provider duties to whoever made it. Teams that treat these changes as ordinary sprint work rarely assess them against the Article 25(1) test. Add a modification gate to the change process that flags retraining, new data sources, new intended uses and changed performance claims for legal and compliance review before release.

Supplier contracts missing required terms

Article 25(4) requires providers and third parties supplying models, tools, services or components to agree in writing what information, technical access and assistance the high-risk provider needs. Standard cloud and SaaS terms often omit these items. Review each supplier agreement for documentation access, performance data, change notice, testing access and support for incident investigation, and confirm with counsel which suppliers fall outside the clause, such as free and open-source tools other than general-purpose AI models.

No process to receive failure modes

Article 25(2), as amended in 2026, requires the original provider to share technical documentation, known limitations and failure modes with the new provider, and targeted technical access for testing, unless it clearly specified that the system must not be changed into a high-risk system. Many vendors have no channel for this. Name a contact, define a request procedure and keep a log of what was shared and when, so the new provider can rely on it in its own technical file.

Component inventory out of step with the build

A provider must document what its deployed system actually contains. When the bill of materials lists the models, libraries and data components from an earlier build, the Article 25 analysis rests on the wrong facts. Generate a CycloneDX software bill of materials from each release artifact with a tool such as Trivy, load it into Dependency-Track, and reconcile it with the model register and the supplier list before each release.

No recheck after a swap

Replacing a foundation model, a vendor component or a training dataset can change the system's risk profile, its intended purpose or its provider status. Teams often complete the original analysis and never repeat it. Attach a short re-assessment step to every model or component change, covering the role test, the supplier terms and the failure modes received from the upstream provider, and file the result with the version history of the technical documentation.

Article 25 questions buyers ask before hiring outside help

Does a deployer that fine-tunes an AI system become its provider?

Fine-tuning alone does not settle the question. Under Article 25(1), a deployer becomes the provider of a high-risk system if it makes a substantial modification that keeps the system high-risk, or if it changes the intended purpose of a non-high-risk system so that it becomes high-risk. Whether a particular fine-tune crosses that line depends on the definition of substantial modification and on the intended purpose the original provider stated, so confirm both before the change is made. Record what changed, why, and which requirements the change touches, and have counsel sign off on the classification decision. If the modification makes the system high-risk, the organization takes on the full provider obligations, including conformity assessment and registration. An implementation partner can map the technical scope of a change, but the classification decision stays with the organization.

How much effort does a supplier contract review take?

The effort depends mainly on how many suppliers and components the system relies on, and on how much existing contract language already covers information, technical access and assistance. Work from a written list of suppliers, including model, data, cloud and tooling providers, and check each contract against what the system will need. The main drivers are:

the number of suppliers and the depth of the supply chain
whether any supplier provides a general-purpose AI model
how much of the required information and access is already in current terms
how many rounds of negotiation each supplier requires

No duration figure is supplied for this work, so ask any partner for a written estimate tied to the supplier list you provide.

Can an original provider refuse the Article 25(2) cooperation duty?

Generally no, unless the original provider clearly specified that the system must not be changed into a high-risk system. As amended in 2026, Article 25(2) requires the initial provider to cooperate with the new provider by sharing technical documentation, known limitations and failure modes, and targeted technical access for testing. The exception depends on a clear written specification of the intended use and the prohibition on high-risk change, so a general disclaimer is unlikely to be enough. Check whether your existing terms contain that language, and if they do not, record the original provider's position in writing before you proceed. Breaches of Article 25(2) now carry the fines described in the 2026 amendment.

Can an implementation partner sign supplier terms on our behalf?

No. Article 25(4) requires providers and third parties to agree the terms in writing, and those terms bind the contracting parties, so an authorized signatory of each organization signs them. An implementation partner's role is to prepare the material the terms depend on, such as a list of required technical information, access arrangements, log and documentation specifications, and assistance schedules. Counsel should draft or review the legal wording. The AI Office may develop and publish voluntary model contract terms free of charge under Article 25(4), which can serve as a starting point. Confirm their current status and content on the official site before relying on them.

What does the 2026 fine for Article 25 breaches mean in practice?

Regulation (EU) 2026/1744 added Article 99(4)(da), which makes breaches of Article 25(2) and Article 25(4) subject to fines of up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher. In practice, two gaps are now directly fineable: refusing or failing to share documentation, limitations and testing access without a clear written reason, and operating without written agreements covering information, access and assistance. National market surveillance authorities enforce the Act for AI systems, while the AI Office handles systems built on a provider's own general-purpose model. Treat the ceiling as the reason to fix contracts early, and ask counsel to confirm how the fine applies to your specific roles.

Do free and open-source components need a 25(4) agreement?

Usually not for free and open-source tools. Article 25(4) does not apply to free and open-source tools other than general-purpose AI models, so libraries, frameworks and self-hosted platforms are generally outside the written agreement requirement. An open-source general-purpose model is not covered by that exemption, so check any model component against the Article 25(4) text with counsel. Whatever the license position, keep a current inventory of components. Dependency-Track consumes and produces CycloneDX SBOMs and VEX, flags known vulnerabilities and license risk, and tracks SPDX license IDs. Trivy can generate an SBOM from a target and scan existing SBOMs, which gives engineering a starting inventory.

What do our legal and engineering teams need to provide?

Legal owns the contracts, the classification sign-off and the negotiation with suppliers. Engineering supplies the facts those documents must describe. Expect to provide:

a current description of the system, its architecture and the model versions in use
the intended purpose statement and any original provider documentation
the supplier list, existing contracts and any open-source or model license records
access to logs, test environments and the people who can answer technical questions

The time each team spends depends on how complete these inputs are when work begins, so gathering them first usually makes the scope easier to agree in writing.

How do we get a fixed-scope quote for Article 25 work?

Start with a written scope, because DeployOpen does not publish a price list and a quote follows from that scope. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Send the supplier list, the system description, the intended purpose statement and copies of current contracts or term sheets. Ask the proposal to state its assumptions, its exclusions and which tasks stay with your legal and engineering teams. Ask for the deliverables in writing, such as a supplier requirements schedule, a cooperation procedure and the evidence set, so you can compare proposals on the same basis.

How DeployOpen scopes and prepares Article 25 evidence

DeployOpen prepares the systems and records that let an organization show who holds provider duties under Article 25 and what each supplier agreed to provide. We work inside your own infrastructure, and the organization keeps ownership of its controls, its contracts and its compliance decisions. Independent assessors and legal counsel remain the parties who judge the outcome.

How we scope

We list the AI systems in scope and record which ones could change role under Article 25(1), such as a deployer that rebrands a system.
The written scope names the suppliers, models and components whose contracts need Article 25(4) terms, and which of them are free and open-source tools.
Engagements are fixed-scope, so deliverables, responsibilities and timelines are agreed in writing before any work starts.

How we build

We set up a software bill of materials workflow using CycloneDX outputs, so component and model dependencies are recorded for each system.
We configure vulnerability and license tracking in OWASP Dependency-Track so changes to suppliers and components are visible to the owner.
We build a supplier information register and a template for the Article 25(2) and 25(4) handover data, for counsel to review and adapt.

How we hand over

We version the agreed documentation in XWiki so every change shows what changed, when and by whom, with rollback to earlier versions.
We set role-based access in BookStack so legal, engineering and procurement staff see only the pages their role requires.
We deliver a written handover pack, with the open items and the owner for each, that the organization can run without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
We rerun the dependency and component checks when a supplier, model or system changes, and update the evidence to match.
Your counsel and assessors decide whether agreements meet Article 25, and we confirm the current wording of the Act and any 2026 changes with you before each review.