How can a processor become a controller?

By determining the purpose of a processing operation itself. The most common route is a vendor deciding to use customer data to improve its own model: for the customer’s processing it acts on documented instructions and is a processor, but for its own model improvement it decides the purpose alone and is a controller for that operation. Roles attach to processing operations, not to companies, so one contract can carry both.

When does a deployer become a provider under the EU AI Act?

Under Article 25, when it puts its own name or trademark on a high-risk AI system, substantially modifies one, or changes a system’s intended purpose so that it becomes high-risk. The full set of provider obligations then applies: risk management, data governance, technical documentation, conformity assessment, CE marking, registration, quality management and post-market monitoring.

Is a controller the same as a provider?

No. They come from different regimes and are decided by different tests. A controller determines the purposes and means of processing personal data under the GDPR. A provider places an AI system on the market under its own name under the EU AI Act. The same organisation can be a controller and a deployer, or a processor and a provider — the roles are assessed independently and the regimes apply cumulatively.

Under EU AI Act Art. 25, which acts turn a deployer into a provider? (Select all that apply.)

Placing its own name or trademark on the high-risk system.

Making a substantial modification to the system.

Changing the intended purpose so the system becomes high-risk.

Rolling the system out to far more users than the vendor expected.

Deploying the system in a member state the vendor does not serve.

Two companies use the same analytics platform, each for its own commercial purposes, sharing infrastructure but deciding independently what to analyse and why. What is their relationship?

Separate controllers, each for its own processing.

Joint controllers, because they share the same infrastructure.

Controller and processor, with the larger firm instructing the other.

Joint controllers, because they use a common platform provider.

Is a GDPR controller the same thing as an EU AI Act provider?

No — different regimes, different tests, and both can apply at once.

Yes — controller and provider are the same role under two names.

No — a controller is always the deployer under the EU AI Act.

Yes, unless the organisation also processes data on someone’s behalf.

Older AIGP study material describes the party that uses an AI system at work as the "user". Why is that term a trap?

Early AI Act drafts said "user"; the final text renamed the role deployer.

The Act has never used the word "user" in any of its drafts or final text.

"User" refers to the provider in the Act, so the material is simply wrong.

The term is correct, but applies only to consumer rather than business use.

Roles, and how they change

The definitions are the easy part. What questions actually test is that roles attach to processing operations, not to companies — so one organisation can hold several at once, hold different ones under a single contract, and move between them by doing something entirely ordinary, like putting its own logo on a licensed tool.

GDPR roles

Controller

Determines the purposes and means of processing. Carries accountability, the lawful basis, transparency to individuals, and answerability to the supervisory authority.

Joint controllers

Two or more parties jointly determining purposes and means for the same processing. Art. 26 requires an arrangement setting out who does what, and its essence must be available to individuals — who may exercise rights against either party regardless.

Processor

Processes on the controller’s behalf, on documented instructions. Bound by an Art. 28 contract, must support the controller’s compliance, and may not engage sub-processors without authorisation.

Sub-processor

Engaged by a processor. The original processor remains fully liable to the controller for the sub-processor’s performance.

Representative

Art. 27. An EU-established point of contact appointed in writing by a controller or processor outside the Union that is nonetheless caught by Art. 3(2).

EU AI Act operators

Provider

Develops a system, or has one developed, and places it on the market or into service under its own name or trademark. Carries the pre-market weight: risk management, data governance, technical documentation, conformity assessment, CE marking, registration, quality management, post-market monitoring.

Deployer

Uses a system under its own authority in a professional capacity. Duties of use: operate per instructions, ensure human oversight by competent people, monitor, ensure input data is relevant, keep logs, inform affected persons, and run a FRIA where Art. 27 requires one.

Importer

Places a third-country provider’s system on the EU market. Verifies before import that the conformity assessment was done, the documentation exists, and the marking and provider details are present.

Distributor

Makes a system available in the supply chain without being provider or importer. Checks marking and documentation, and must not supply a system it believes non-conforming.

Authorised representative

Art. 22. Appointed in writing by a non-EU provider of a high-risk system. Holds the conformity documentation, keeps it available for authorities and cooperates with them. Does not perform the assessment.

The transitions

Each of these is a question waiting to be asked, because in every case the organisation has done something that feels routine and acquired a new set of obligations by doing it:

Processor → Controller

What triggers it: The vendor decides, on its own, to use customer data for a purpose of its own — most commonly to improve its general model.
Why: Role follows who determines the purpose of a given processing operation. For the customer’s processing the vendor acts on instructions and is a processor; for its own model improvement it decides alone and is a controller for that operation. One contract, two roles.
Worth watching: This is why a broad "we may use your inputs to improve our services" clause is a governance problem and not just a commercial one. It quietly makes your supplier a controller, with its own lawful basis and its own transparency duty to your customers.

Processor → Joint controller

What triggers it: The parties genuinely decide the purposes and essential means of the same processing together.
Why: Joint control needs converging decisions on the same operation, not merely a close commercial relationship or shared infrastructure. Two companies using the same platform independently are not joint controllers.
Worth watching: The CJEU has read joint control broadly. A party can be a joint controller without having access to the personal data at all, if it participated in determining the purposes.

Deployer → Provider

What triggers it: Putting your own name or trademark on a high-risk system, substantially modifying one, or repurposing a system so that it becomes high-risk.
Why: AI Act Art. 25. The Act attaches provider status to placing on the market under your own name, however the system was built — so licensing, white-labelling and fine-tuning can all trigger it.
Worth watching: The most expensive surprise in AI procurement. The full provider set arrives at once: risk management, Annex IV documentation, conformity assessment, CE marking, registration, quality management, post-market monitoring.

Distributor or importer → Provider

What triggers it: The same three acts as above — putting your name on it, modifying it substantially, or changing its intended purpose to a high-risk one.
Why: Art. 25 applies along the whole value chain, not only to deployers. A distributor that rebrands stops being a distributor.
Worth watching: The original provider’s obligations attach to the system it released, not to a substantially modified system it did not author.

Nothing → Both provider and deployer

What triggers it: Building your own model and using it yourself.
Why: Two sets of duties collapse onto one organisation, and there is no vendor to indemnify you when something goes wrong.
Worth watching: What you gain is control, data sovereignty and independence from vendor changes. What you lose is the absorbed obligations and the indemnity.

Don't map one regime onto the other

Controller-to-provider and processor-to-deployer look like clean analogies. They are not: the tests are different, and the two regimes apply cumulatively rather than alternatively.

Controller	GDPR	Determines purposes and means of processing personal data
Provider	EU AI Act	Places an AI system on the market under its own name
Processor	GDPR	Processes personal data on documented instructions
Deployer	EU AI Act	Uses an AI system under its own authority

A company can be a GDPR controller and an AI Act deployer at the same time, or a processor and a provider. Work out each independently. And note the historical trap: early drafts of the AI Act called deployers "users", so older material saying "user" usually means deployer — while the Act's own person-facing concept is the affected person, who is not an operator at all.

Test yourself

5 questions on what is above, with every option explained. Your score is kept in this browser and shown on your dashboard, and saved to your account if you are signed in.

Quick check: roles and how they change1 / 5 · score 0

A SaaS vendor processes customer data on documented instructions, and separately decides on its own to use that data to improve its general model. What is its role?

AController throughout, because it holds and operates the infrastructure.
BJoint controller with the customer across the whole relationship.
CProcessor throughout, because the customer supplied all of the data.
DProcessor for the customer’s processing, controller for the improvement.