Provider vs. Deployer Under the EU AI Act
The Line That Moves When You're Not Looking.
I was reviewing a contract last month.
A mid-sized bank licensing an AI-powered credit scoring system from a fintech vendor.
Standard setup. The vendor builds it, the bank uses it. Clean.
Then I got to the section on customization.
The bank’s data science team had been training the model on the bank’s own lending data. Five years of loan applications, defaults, repayments.
They’d also adjusted some of the decision thresholds. And someone — probably an ambitious junior data scientist — had integrated an additional ML component that post-processes the vendor’s output before it reaches the credit committee.
The contract called the bank a “deployer”.
I sat there thinking — are you, though?
If you’ve worked through GDPR, the exercise will feel familiar. Controller or processor? You had to figure out your role before you could figure out your responsibilities. The answer determined which obligations applied, how much documentation you needed, and what happened when something went wrong.
The AI Act follows the same logic. Different terms — provider and deployer instead of controller and processor — but the same structural question: what is your role in relation to this AI system, and what follows from it?
The consequences, though, are not the same. Under GDPR, both controllers and processors carry real obligations. Under the AI Act, the gap between provider and deployer is enormous. A deployer’s obligations fit on one page — use the system properly, keep humans in the loop, tell people when AI is making decisions about them. A provider is responsible for the system itself — its design, its documentation, its conformity assessment, its safety. That’s not a difference in degree. That’s a different job.
And your role can change. You can start as a deployer and end up as a provider — not because you decided to be one, but because of what you did with the AI system.
The Definitions
The AI Act defines both roles in Article 3.
A provider is a person or entity that develops an AI system — or has one developed — and places it on the market or puts it into service under its own name or trademark. Two things matter: developing (or commissioning the development), and putting your name on it.
A deployer is a person or entity using an AI system under its authority. That’s it. You use the AI system. You didn’t build it. You’re not selling it. You’re operating it.
On paper, the line is clean. One builds, one uses.
In practice, companies buy AI systems and then customize them, train them on proprietary data, integrate them into larger pipelines, repurpose them for new use cases. The neat definition breaks down the moment real business happens to it.
Three Triggers That Make You a Provider
Article 25. “Responsibilities along the AI value chain.” Sounds like the title of a slide deck nobody wants to sit through. What it actually does: define the three moments when a deployer becomes a provider.
Three triggers. Any one is enough.
You put your name on it. You buy a high-risk AI system from a vendor. You rebrand it. Call it yours. Put your trademark on the interface. From the outside world, it looks like your product. Under the AI Act, it now is your product — even if you didn’t change a line of code.
You substantially modify it. You change a high-risk AI system in a way that wasn’t foreseen in the original conformity assessment — and that change affects compliance or intended purpose. You just became the provider.
You repurpose it into high-risk. You take an AI system that wasn’t classified as high-risk and use it for something that is. You didn’t touch the AI system itself. You just used it differently.
That third trigger is the one that is easy to miss. You don’t have to modify the AI system. You just have to use it wrong.
One Bank, Five Ways to Get It Wrong
Credit scoring.
One of the clearest high-risk use cases under the AI Act — Annex III, point 5(b), AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score. No ambiguity about the risk classification.
The only question is about the role. And it turns out there are at least five versions of that question — all sitting inside the same bank.
The simple version
The bank licenses a credit scoring AI system from a fintech vendor. Plugs it in. Follows the instructions. Doesn’t touch the internals.
Deployer. Article 26 obligations — operational stuff. Use the system according to instructions, assign competent people for human oversight, make sure the input data is relevant, inform applicants that AI is involved in the credit decision, cooperate with authorities if they come asking.
What the bank does not have to do: conformity assessment, CE marking, technical documentation, quality management system, registration as provider, post-market monitoring system. None of it.
That’s a comfortable position. Most banks want to stay there.
Few do.
The obvious version
The bank builds its own credit scoring model from scratch. Data science team trains it on the bank’s lending data, validates it, deploys it. The bank’s name is the only name on it.
Provider. Not because of Article 25 — this isn’t a transformation question. The bank developed an AI system and put it into service. That’s the definition, full stop.
Full provider obligations. Quality management system (QMS). Technical documentation per Annex IV. Conformity assessment before putting the system into service. EU declaration of conformity. CE marking. Registration. Automatic logging. Post-market monitoring. Serious incident reporting.
The list goes on. I’ll come back to the full comparison. But the gap between this and the deployer list isn’t incremental — it’s structural.
The version that keeps me up at night
The bank licenses a credit scoring system. The system is designed to be trained on the deployer’s data — that’s the product.
“Bring your own data” the vendor’s sales deck probably said.
The bank feeds in five years of lending history. The model learns the bank’s patterns. Parameters change. The model now behaves differently than the vanilla version.
Still a deployer?
Everything turns on one phrase in Article 3(23) — the definition of “substantial modification”: not foreseen or planned in the initial conformity assessment.
If the vendor’s conformity assessment explicitly accounted for retraining on deployer data — specified what kind of data, assessed how retraining affects performance, set guardrails — then the bank is likely still a deployer. Recital 128 backs this up: changes that were “pre-determined by the provider and assessed at the moment of the conformity assessment” are not substantial modifications. The vendor planned for this. The AI system was designed to be trained this way.
If the vendor didn’t account for it — if the sales team said “you can train it on your data” but the conformity assessment never assessed the impact of that retraining — the bank just made a substantial modification. Not foreseen. Affects accuracy, fairness, robustness. The bank is a provider.
The practical problem is that most vendor contracts and conformity assessments aren’t drafted with this level of specificity. Not yet.
Many vendors offer customization without formally assessing it in the conformity assessment. Which means many banks doing what feels like routine customization may already be providers without knowing it.
If that sounds like the early days of GDPR — when half the companies processing personal data didn’t know they were controllers — the parallel is intentional. Same logic. Same trap. Different regulation.
The version where it’s not even close
The bank doesn’t just train the model on new data. It modifies the architecture. Adds features. Changes the weighting logic. Adjusts decision thresholds beyond what the vendor’s instructions permit. Integrates an additional ML component that post-processes the output.
This was the bank in the contract I was reviewing. And no — there’s no grey zone here. Architecture changes, additional components, modified decision logic — none of this was foreseen in the vendor’s conformity assessment.
The bank is a provider. Probably has been since the first architecture change. It just didn’t notice.
The contract still said “deployer.”
The version you didn’t see coming
The bank licenses a general-purpose chatbot. Customer service tool. Not high-risk.
Then someone in the product team has an idea: use it to screen loan applicants, ask financial questions, feed the responses into the credit pipeline.
No code changed. No model retrained. Just a decision about how to use it.
The vendor’s intended purpose was customer service. The bank’s use — creditworthiness assessment — falls under Annex III. The system is now high-risk, and the bank is its provider under Article 25(1)(c).
A tool bought for one purpose, quietly repurposed for another. Nobody flagged it because nobody changed the system. But Article 25 doesn’t require you to change the system. It just requires you to change what you use it for.
Provider of What, Exactly?
When the bank crosses the line, a question follows that almost nobody answers clearly: does it become the provider of the entire system, or just the part it modified?
Article 25(2) says “the provider that initially placed the AI system on the market or put it into service shall no longer be considered to be a provider of that specific AI system.”
“That specific AI system.” Not “the modified portion of that AI system.” Not “the component the deployer changed.” The whole system. The original provider drops out entirely. The bank steps in.
My reading — and I want to be clear this is interpretation, because the Commission hasn’t addressed it explicitly — is that the bank becomes provider of the AI system as a whole. Full conformity assessment of the entire system. Full technical documentation. Full quality management coverage.
You can’t do a conformity assessment of half a system. When the bank changes the model’s architecture, the entire system’s compliance profile shifts — inputs, processing, outputs, everything.
One exception worth noting — for general-purpose AI models (not systems), the GPAI guidelines suggest the modifier’s obligations concern “the portion of the model that has actually been modified.” But that’s a different regulatory chapter, different rules. Don’t mix them up.
Now, Article 25(2) anticipated that this would be hard. The original vendor must cooperate with the new provider — hand over information, provide technical access, assist with conformity assessment. The bank needs to assess a system it didn’t fully build. The vendor has to make that possible.
Except — and this is where the regulation argues with itself — Article 25(5) says all of this cooperation is “without prejudice to intellectual property rights, confidential business information and trade secrets.” The bank needs access to comply. The vendor may resist on IP grounds.
The regulation creates the obligation in one paragraph and its own exception three paragraphs later. I’ll let you sit with that.
What Actually Changes When You Become a Provider
The list comparison tells the story faster than I can.
A deployer under Article 26: follow the provider’s instructions, assign competent humans for oversight, ensure input data is representative, inform people when AI affects their decisions, cooperate with authorities. Operational. Manageable.
A provider under Articles 16-21: quality management system covering design to post-market. Technical documentation per Annex IV — before the system goes live. Conformity assessment. EU declaration of conformity. CE marking. Registration in the EU database. Automatic logging capability built into the system. Post-market monitoring system. Serious incident reporting. Corrective actions when something goes wrong.
For a bank that was comfortably a deployer and becomes a provider because it fine-tuned a model too aggressively — the compliance burden doesn’t just increase. It transforms. The bank needs documentation it doesn’t have. A conformity assessment it wasn’t planning for. A quality management system covering AI-specific requirements it probably hasn’t built.
One sliver of relief. Article 17(3) allows financial institutions subject to EU financial services law to satisfy the quality management requirements through their existing internal governance. Banks already have governance structures under EU banking regulation. They don’t need to build a separate AI-specific QMS from scratch — they can adapt what exists. (One caveat: points (g), (h), and (i) of Article 17(1) — covering post-market monitoring, incident reporting, and communication with authorities — are excluded from this deemed-compliance provision. Those you still need to build.)
But “we already have governance” isn’t the same as “our governance covers AI Act QMS requirements.” Anyone who’s worked in banking compliance knows how far apart those two sentences can be.
And there’s no grace period. None. Article 25 triggers are immediate. The moment the bank makes a substantial modification, it’s a provider. Not “you have six months to figure it out.”
The bank should have completed the conformity assessment before putting the modified system into service. In practice, most banks won’t realize they’ve crossed the line until after they’ve deployed the modified system.
The fines reflect the stakes. Non-compliance with high-risk AI system obligations: up to €15 million or 3% of global annual turnover, whichever is higher.
The Questions I Can’t Answer Yet
A few things the regulation leaves open — and that the Commission’s still-pending guidance on substantial modification needs to address.
How specific does “foreseen” need to be? A generic “this system may be customized” in the vendor’s documentation — is that enough? How detailed does the foreseeability assessment need to be? Who bears the burden of proving it — the vendor claiming they foresaw everything, or the regulator saying they didn’t foresee this specific change?
What counts as “affects compliance”? Almost any modification to an ML model can theoretically affect accuracy, fairness, or robustness — all Chapter III requirements. If any performance change counts, then any customization is a substantial modification. If only material degradation counts, the regulation doesn’t say so.
Cumulative drift. Recital 128 says pre-determined continuous learning isn’t a substantial modification. Fine. But a system learning on the bank’s data will, over time, diverge from the version the vendor assessed. Each individual step is pre-determined. The cumulative result might not be. At what point does a series of small, foreseen changes become a material departure from the assessed system? Nobody knows.
Cooperation vs. IP. When the bank needs the vendor’s proprietary model architecture to perform a conformity assessment, but the vendor claims trade secret protection — what happens? The regulation doesn’t resolve this. And I suspect it will take actual litigation to draw the line.
The Exercise
Same logic as GDPR. Different stakes.
Map every AI system you use. For each one — are you the provider or the deployer? Have you modified it? How? Was that modification foreseen in the vendor’s conformity assessment? Can you prove it?
Check your vendor contracts. Do they address AI Act compliance? Do they specify what customization falls within the conformity assessment? Do they include the cooperation obligations Article 25(2) requires?
And if you’ve already modified a vendor’s system — already trained it on your data, already adjusted its parameters, already integrated it into a larger pipeline — you’re not looking at a future compliance question.
You’re looking at one that already triggered.
August 2, 2026. That’s the deadline for high-risk AI system obligations — at least, that’s the date in the AI Act as published. The Commission’s Digital Omnibus proposal, currently in trilogue, would push it to December 2027. But even if the deadline shifts, Article 25 doesn’t shift with it. The question of whether you’re a provider or a deployer isn’t waiting for a legislative amendment.
That question is already live.
The "bring your own data" trap is the sharpest point here. Most banks think retraining on proprietary data is routine customization. Whether it crosses into substantial modification entirely depends on whether the vendor's conformity assessment explicitly scoped it and most don't.
The cumulative drift question is the one that'll produce the first major enforcement case. Each step is foreseen, the destination isn't. Nobody has an answer for that yet.
I build production AI systems in regulated environments this is exactly the compliance surface I think about. Worth a subscribe here too.