The EU AI Act's provider vs deployer distinction: what UK startups using AI APIs need to understand

TL;DR: Most UK SaaS startups calling third-party AI APIs are deployers under the EU AI Act with significantly lighter obligations than providers. But the line between the two is easier to cross than most founders realise and it can shift as the product evolves. This post explains what the distinction means in practice, which specific engineering decisions trigger a status change and what a startup should be building into their architecture now to avoid a compliance retrofit later.

The assumption most UK startups make about the EU AI Act is that it applies to the companies building the AI, not the companies using it.

For most startups calling third-party AI APIs that assumption is broadly correct. But the word "most" is doing a lot of work in that sentence, and the exceptions are exactly where the compliance gaps appear.

The provider versus deployer distinction is the single most consequential aspect of the Act for UK startups and it is the least understood. Getting it wrong does not just create a compliance problem. It creates one that is expensive to retrofit into an architecture that was not designed around it.

What the distinction actually means

The EU AI Act distinguishes between two roles in the AI value chain.

A provider is an organisation that develops an AI system and places it on the market or puts it into service under its own name or trademark. Providers carry the heaviest obligations under the Act: technical documentation, conformity assessment, quality management systems, post-market monitoring and registration in the EU AI database for high-risk systems.

A deployer is an organisation that uses a third-party AI system under its own authority in a professional context. Deployers carry lighter obligations under Article 26: appropriate use of the system, human oversight where required and transparency to end users. They are not responsible for the compliance of the underlying model.

The practical shortcut: if you call a third-party API to power a feature in your application you are typically a deployer. If you train or fine-tune a model, build the inference pipeline and ship it as a product under your own name you are a provider.

One important nuance worth building into how you think about this: these roles attach to each system, not to the company as a whole. A startup can be the provider of the AI system it builds and sells to customers and simultaneously the deployer of the third-party AI tools it uses internally. The roles are determined product by product, not company by company.

The three triggers that shift your status from deployer to provider

This is where most startups get caught out. Under Article 25 of the Act, a deployer is treated as a provider and takes on all provider obligations in three specific situations.

1. You place the system on the market under your own name or trademark

If you take a third-party AI system and offer it to customers under your own brand, you have become the provider of that system regardless of who built the underlying model. The trigger is not what you built. It is what you are placing in the market and under whose name.

A practical example from WCR Legal's analysis of common Series A and B configurations: a company that takes a third-party credit risk model, fine-tunes it on proprietary loan performance data and white-labels it to banking clients under its own brand is the provider of a high-risk AI system. Full Article 16 obligations apply.

2. You substantially modify the system

Substantial modification means changing the intended purpose of the system, retraining it in ways that materially affect its behaviour or altering it so that it no longer complies with the requirements it was originally assessed against.

Fine-tuning sits at the edge of this trigger. Light task-specific tuning that does not change the intended purpose of the system and does not affect its compliance with high-risk requirements typically does not shift provider obligations. Substantial changes to the system's classification behaviour, the data scope or the action space can shift it. The analysis needs to be deliberate and documented rather than assumed.

3. You change its intended purpose to a high-risk use case

If you take a system that was not classified as high-risk and deploy it in a context that makes it high-risk under Annex III, provider obligations follow. The most common version of this for startups is integrating a general-purpose AI model into a workflow that makes or informs consequential decisions about people: employment, credit, access to essential services, education.

Which engineering decisions are most likely to trigger the shift

Understanding the triggers in the abstract is less useful than understanding which specific decisions in a product build are most likely to move a startup from deployer to provider territory.

Using a third-party API for a user-facing feature. Standard deployer territory. You are using the system under the provider's instructions for its intended purpose. Lighter Article 26 obligations apply. Transparency to users under Article 50 may still apply depending on the nature of the output.

Fine-tuning a foundation model on your own data for internal use. Likely still deployer territory if the fine-tuning is light and task-specific and the system stays internal. Worth a deliberate Article 25 analysis rather than an assumption. If the fine-tuned model is then offered to customers under your own name, the analysis changes entirely.

Building a product that uses AI to make or inform consequential decisions about people. The risk classification question becomes important here. If the use case falls within Annex III categories including employment, education, credit or access to essential services the system is high-risk and provider obligations apply in full if you are the one placing it on the market.

Taking a third-party model, wrapping it with your own fine-tune and selling it as a proprietary product. Provider territory. You are placing a system on the market under your own name with modifications that may constitute substantial change. Full Article 16 obligations apply, and the compliance programme required is comparable in scope to medical device certification for high-risk systems.

What to build into your architecture now

The startups that will have the easiest path through EU AI Act compliance in 2026 and 2027 are the ones that built three things in from the start rather than retrofitting them later.

Role determination documentation. A clear written record of whether each AI system in your product makes you a provider or a deployer, the reasoning behind that determination and the triggers that would change it. This is not a legal document. It is an engineering and product decision record that demonstrates you have thought about the question deliberately. It needs to be revisited whenever the product evolves in ways that might affect the classification.

Logging and traceability for AI system behaviour. Deployers of high-risk AI systems are required under Article 26 to log the operation of the system to the extent they have control over it. Providers face more extensive logging requirements. Building logging into the architecture from the start is significantly easier than retrofitting it onto a system that was not designed to produce audit-ready records.

Human oversight mechanisms. For high-risk systems, the Act requires that the system be designed to allow effective human oversight. That is a technical requirement, not just a policy one. The system must be interpretable enough for a human reviewer to understand its outputs and controllable enough for a human to intervene. Designing this in from the start is a different kind of problem from adding it to a system that was built without it.

You can read more about the broader compliance in our August post on what the EU AI Act means for UK software teams.

What to ask your development partner

If you are commissioning a build that includes AI features, the compliance question starts at the architecture stage, not the legal review stage. Questions worth asking before you scope the work:

• Has the team considered the provider versus deployer classification for this specific product and can they explain which category applies and why?
• Do they build role determination documentation into the delivery process or treat it as something the client handles separately?
• How do they approach logging and traceability for AI system behaviour in the architecture rather than as an afterthought?
• What is their approach to human oversight mechanisms for systems that make or inform consequential decisions?

What to listen for is whether the answers engage with the specific technical implications for your product or stay at the level of a general commitment to compliance. A partner who can walk through the provider versus deployer analysis for your architecture has treated this as an engineering question. One who defers the whole conversation to legal counsel without being able to describe the technical implications has probably not yet built it into how they work.

Frequently asked questions

What is the difference between a provider and a deployer under the EU AI Act? A provider is an organisation that develops an AI system and places it on the market or puts it into service under its own name. A deployer uses a third-party AI system under their own authority in a professional context. Providers carry significantly heavier obligations, including technical documentation, conformity assessment and quality management systems. Most UK startups calling third-party AI APIs are deployers with lighter Article 26 obligations.

Does the EU AI Act apply to UK startups after Brexit? Yes. The Act has extraterritorial scope. If your software is used by EU customers or your AI outputs reach EU users, the regulation applies regardless of where your business is headquartered. The provider versus deployer distinction applies equally to UK businesses with EU exposure.

Does fine-tuning a third-party AI model make you a provider under the EU AI Act? It depends on the nature and extent of the fine-tuning. Light task-specific tuning that does not change the intended purpose of the system typically does not shift provider obligations. Substantial changes to the system's classification behaviour, the data scope or the action space can trigger the shift. If the fine-tuned model is then placed on the market under your own name, provider obligations apply in full. A deliberate Article 25 analysis is required rather than an assumption.

What happens if my startup's AI classification changes as the product evolves? Your role determination needs to be revisited whenever the product evolves in ways that might affect the classification. The triggers that shift a deployer to provider status include placing the system on the market under your own name, substantially modifying it and changing its intended purpose to a high-risk use case. A written role determination record that is updated as the product develops is the most practical way to manage this.

What obligations do deployers have under the EU AI Act? Deployers of high-risk AI systems have obligations under Article 26, including appropriate use of the system within its intended purpose, implementation of human oversight measures, logging of system operation to the extent they have control over it and transparency to end users. These are lighter than provider obligations but still require deliberate compliance work rather than an assumption that using a third-party system transfers all responsibility to the provider.

What should a UK startup ask a development partner about EU AI Act compliance? The most useful questions are operational rather than legal: has the team considered the provider versus deployer classification for this specific product; do they build role determination documentation into the delivery process; how do they approach logging and traceability for AI system behaviour in the architecture; and what is their approach to human oversight mechanisms for systems that make or inform consequential decisions.

How Aecor helps

We build software that includes AI features for UK startups and SaaS businesses. The provider versus deployer question comes up in almost every AI-integrated build now and we would rather address it at the architecture stage than as a compliance retrofit six months after launch.

For further reading, the official EU AI Act page covers the full timeline and obligation structure, and WCR Legal's provider versus deployer guide provides a clear analysis of the most common SaaS configurations at Series A and B stage. You can also read more about how we approach AI Automation as part of our engineering practice.

If you are building a product with AI features and want to understand what the distinction means for your specific build, a free technical discovery call is a good place to start.

Book your free Technical Discovery Call.