EU AI Act compliance for a commissioned AI system usually lands on the company that ordered it, not the team that wrote it. If you commission a system and ship or use it under your own name, Article 3(3) likely makes you the provider, even if a contractor wrote every line. A development contract can allocate work and cost between you and the supplier, but the role itself follows the facts. The high-risk dates have also moved: Annex III systems now apply from 2 December 2027 and Annex I systems from 2 August 2028. This piece sits inside our wider guide to EU engineering hiring compliance: contracts, IP and GDPR, and it covers the AI-specific part of that contract.
It informs, it doesn't advise. Have counsel review anything you put in a signed agreement.
Who is the provider when an external team builds the system?
The definition in Article 3(3) of the AI Act includes a party that "has an AI system ... 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 phrase "has developed" is the one that matters for outsourcing. It covers the company that commissions the build, not only the one that writes the code.
So the test is whose name is on the system when it reaches users or goes into service. Who typed the training script doesn't decide it. GDPR works the same way: a vendor labelled "processor" in the contract becomes a controller if it decides the purposes of processing, because function beats label. A contract line saying "Contractor is the provider" doesn't change who meets the definition, since the definition turns on who has the system developed and under whose name it ships. For the basic provider and deployer definitions, see Article 50 transparency duties for engineering teams.
When the contractor can be the provider
The reverse case exists. If the development company sells or markets the system under its own name or trademark, it's the one placing it on the market. That's the white-label product: the supplier built a general tool, and you license it. Then you're closer to a deployer, unless you modify it in ways that move you back into provider territory (see the Article 25 section below). Which side of the line you're on depends on the facts of each build, so write them down at the start.
What the provider role means for a commissioned build
The heavy set of provider duties attaches to high-risk systems. Those are the systems in the Annex III use cases (certain high-risk areas) and the Annex I category (systems integrated into products such as lifts or toys). For systems outside those lists, the obligations are far lighter. Transparency duties under Article 50 are a separate track and sit with the Article 50 piece linked above, so this article leaves them there.
That makes classification the first job, and it belongs before the contract, not after. Ask four questions in order. Is the intended use prohibited? Is it high-risk under Annex III or Annex I? Does it only trigger transparency duties? Or is it minimal risk? A resume-screening feature and an internal code-search tool can come from the same contractor on the same sprint cadence and sit in different tiers. The answer changes what the contract has to carry, which is why the steps below start with it.
When you become the provider of someone else's system (Art 25)
Sometimes the system isn't yours to begin with. You rebrand or change someone else's product that's already on the market. Article 25(1) says a third party becomes the provider of a high-risk system if it puts its name or trademark on a high-risk system already on the market, makes a substantial modification to a high-risk system already placed on the market or put into service such that it remains high-risk, or modifies the intended purpose of an AI system that wasn't classified as high-risk and was already on the market, so that it now is.
That third case catches teams by surprise. A general-purpose chatbot isn't high-risk. Point it at a hiring workflow and the intended purpose has changed, which makes you the provider of whatever results.
Building your own system on a base model is a different situation. A nearshore team that fine-tunes a base model into your product is building your system, so Article 3(3) already makes you the provider. Article 25 is about modifying someone else's system that's already on the market.
Article 25(2) puts a duty on the other side. Where the original system is high-risk and already on the market, the initial provider has to cooperate closely with the new provider and make available the necessary information, plus the reasonably expected technical access and other assistance. That duty doesn't apply where the original provider clearly specified that its system isn't to be changed into a high-risk system. In practice the help means technical documentation, known limitations and failure modes, and targeted technical access. Who's on the team matters here too, and vetting AI engineers before they touch your system covers that side.
How to allocate AI Act duties in a development contract
Not every system needs all ten steps. Steps 3 to 6 matter most when the system is high-risk or might become so. The generic clauses (payment, warranties, termination) are covered in clauses a software development agreement needs, so these steps only add what's AI-specific.
1. Classify the system and write the classification into the SOW
State the intended purpose in the statement of work, say whether it falls under an Annex III use case, and record the reasoning. A one-page classification note attached to the SOW is enough. It also gives you something to point to when the scope later drifts.
2. Name the provider of record and the supplier role
Write down which party is the provider (you, in most commissioned builds) and which is the supplier. This doesn't move the legal role, but it removes ambiguity about who holds the file, who answers regulators, and who the contractor reports to.
3. Make documentation inputs an acceptance criterion
High-risk providers need technical documentation, and they can only write it with inputs from the people who built the system. List the inputs: design decisions, data sources, training and test evidence. Make delivery part of acceptance, so a sprint isn't "done" until the evidence is in your repository.
4. Put logging and traceability in the spec
If the system needs to record events for later review, treat that as a feature with its own ticket. Specify what's logged, where it's stored, and who can read it. Writing it into the first spec is the safer route, because adding traceability after launch means reworking a system that's already running.
5. Allocate quality management and risk-management evidence
Decide who produces the risk assessments, test reports and QMS records, who retains them, and for how long. Contractors rotate engineers and close projects. Evidence kept only on their side is gone when the engagement ends.
6. Add a supplier clause modelled on Article 25(4)
Article 25(4) requires written agreements specifying "the necessary information, capabilities, technical access and other assistance based on the generally acknowledged state of the art." The requirement is framed around the provider of a high-risk system and the third party that supplies an AI system, AI model, tools, services, components, or processes that are used or integrated in a high-risk AI system. It excludes third parties making accessible to the public tools, services, processes, or components, other than general-purpose AI models, under a free and open-source licence. Open-weight general-purpose AI models aren't covered by that exclusion. Whether your contractor counts as such a supplier depends on how the build is structured, so treat a clause in this style as a sensible template rather than a confirmed obligation for every commissioned build.
The article also says the AI Office may develop and recommend voluntary model terms for these contracts. Check whether any have been published before drafting from scratch.
7. Require disclosure of open-source and third-party components
Ask for a list of every model, library and dataset in the system, with the licence for each. Licence terms decide what you can ship, and the open-source exclusion in Article 25(4) makes the licence status of each component relevant to the AI Act analysis too. Note that the exclusion doesn't cover general-purpose AI models, so an open-weight model still needs its own entry and supplier terms.
8. Set change control for modifications
Under Article 25(1), a substantial modification can change who the provider is. Write a clause that obliges either side to flag proposed changes to the model, training data or intended purpose before they happen, and to re-run the classification when they do.
9. Plan the exit
At the end of the engagement you need the code, model weights, datasets, evaluation scripts and documentation. Ownership defaults for code are in who owns code a contractor writes under EU law, but model weights and datasets rarely get named in a standard IP clause. Name them.
10. Cover cooperation, incidents and liability
Require the contractor to support regulator requests and to report serious incidents within a fixed window you set. That window has to be shorter than the provider's own deadlines under Article 73 on serious incident reporting: 15 days after becoming aware, 10 days in case of death, and 2 days for a widespread infringement. Liability allocation between the parties is a negotiation, and counsel should review that clause in particular.
Dates after the digital omnibus
The digital omnibus amendment entered into force on 27 July 2026, according to the Commission's AI regulatory framework page. It moved the high-risk dates. Some guides still give 2 August 2026 or 2 August 2027 as the high-risk dates. Those dates are outdated.
| Date | What applies |
|---|---|
| 1 August 2024 | AI Act enters into force |
| 27 July 2026 | Digital omnibus amendment enters into force |
| 2 August 2026 | AI Act becomes applicable |
| 2 December 2027 | Rules for Annex III high-risk areas apply |
| 2 August 2028 | Rules for Annex I products (such as lifts or toys) apply |
The Commission page describes the Annex III rules as covering "systems used in certain high-risk areas," and the Annex I rules as covering systems integrated into products. Other dated obligations, including the Article 50 grace period, are covered in the Article 50 piece. The 2027 and 2028 dates only govern the high-risk set, so they don't change when the Act as a whole became applicable.
FAQ
Is the nearshore development company the provider under the EU AI Act?
Usually not, if you commission the system and ship or use it under your own name. Article 3(3) covers a party that has an AI system developed and places it on the market or into service under its own name or trademark. The contractor can be the provider if it sells or markets the system under its own name, as in a white-label product. It depends on the facts of each build.
Can a development contract shift AI Act provider duties to the contractor?
A contract can allocate tasks, evidence and cost. The role itself is defined by Article 3(3), which turns on who has the system developed and whose name it carries, not on what the agreement calls each party. A clause that names the contractor as provider doesn't change who meets that definition. Have counsel review how any allocation interacts with it.
Do I need an Article 25(4) agreement with my AI development supplier?
Article 25(4) requires written agreements between the provider of a high-risk system and the third party that supplies an AI system, AI model, tools, services, components, or processes that are used or integrated in a high-risk AI system. It excludes tools, services, processes and components made public under a free and open-source licence, but not general-purpose AI models. If your system isn't high-risk, the article doesn't apply in that form. If it is, whether your contractor is a supplier in that sense depends on the build, so counsel should confirm. A clause in that style is a reasonable template either way.
Does the 2027 delay mean I can wait to put AI Act terms in the contract?
The Annex III high-risk rules apply from 2 December 2027 and the Annex I rules from 2 August 2028, so the heavy provider duties for those systems aren't live yet. A contract that runs past those dates will need to cover them, and it's easier to specify documentation, logs and evidence at the start than to add them later. The delay changes when duties begin, not what the signed agreement will need to say.
What if our contractor fine-tunes a third-party model for us?
If you're building your own system on that model, Article 3(3) already makes you the provider, and the contractor's fine-tuning doesn't change that. Article 25 is about modifying someone else's system that's already on the market: a third party becomes the provider if it substantially modifies a high-risk system already placed on the market or put into service so that it remains high-risk, puts its name on one, or changes the intended purpose of a non-high-risk system so that it becomes high-risk. The Article 25(2) cooperation duty applies where the original system is high-risk and on the market, and not where its provider clearly specified it isn't to be changed into a high-risk system.