The sentence shows up in nearly every compliance call: «we are not a provider, we just use the tool». It gets said with relief, because everyone has worked out that the user gets the short list and the builder gets the long one. And it gets said without running the check, which takes twenty minutes and four questions.
The thesis in one line: under the EU AI Act, the role that binds you is not decided by your contract or your invoice. It is decided by what you do to the system. One article — Article 25 — exists purely to reclassify you as a provider the moment you put your brand on it, modify it substantially, or change its intended purpose. Configuring a custom agent on a third-party platform brushes all three doors at once, and almost nobody has looked.
Two notes before going further. First, this is an operating map for knowing what to ask, not legal advice: the role that applies turns on your specific facts and has to be closed out with counsel. Second, if you are reading this from the US and assuming European law is somebody else’s problem: the Act reaches providers who place systems on the EU market regardless of where they are established, and providers and deployers in third countries where the system’s output is used in the EU. Source: Article 2: Scope, Regulation (EU) 2024/1689, accessed 2 October 2026. There is no federal US equivalent to argue with — which means the EU text is, for now, the one that writes your documentation requirements.
EU AI Act provider vs deployer: the label follows what you do, not what you sign
The regulation splits duties by role, not by company size. The provider develops an AI system and places it on the market or puts it into service under its own name or trademark. The deployer uses it under its own authority in the course of its activity. Everyone’s instinct is that buying a licence files you under the second group permanently. Article 25 exists precisely so that it does not.
The mechanism is blunt: a distributor, importer, deployer or any other third party shall be considered a provider of a high-risk AI system — and picks up the provider obligations that come with it — if any one of three things happens. Source: Article 25: Responsibilities along the AI value chain, Regulation (EU) 2024/1689, accessed 2 October 2026.
| Article 25 trigger | What it looks like when you do it | Why it crosses the line |
|---|---|---|
| You put your name or trademark on a high-risk system already on the market | Skinning the assistant with your logo and serving it on your own domain | From the outside the system is yours. Nobody using it can tell your layer from the engine underneath |
| You make a substantial modification and the system stays high-risk | Wiring in your own data sources, rewriting the instructions, widening what the system is allowed to execute | You changed how the system behaves, and the original conformity assessment no longer covers what you built |
| You change the intended purpose of a non-high-risk system so that it becomes high-risk | Taking a general-purpose model and pointing it at screening applicants or triaging customer cases | Intended purpose is what drives classification. Changing it reclassifies the system, and whoever reclassifies answers for it |
The third row catches the most people, and it is also the easiest to cross with no meeting and no minutes. Nobody signs a document saying «we are changing the intended purpose». What happens is that an assistant that summarised documents starts, three iterations later, ranking a queue of applicants, because someone saw it demo well and adding it took an afternoon.
What being a deployer costs you: Article 26 as a list
If the check comes back clean and you are a deployer, your list is Article 26. It is demanding but operational: most of it is things you either do or do not do in the daily life of a running system, not documents you write once.
- Use the system in line with the provider’s instructions for use. Not a detail: stepping outside those instructions is one of the routes by which responsibility shifts onto you.
- Assign human oversight to natural persons with the necessary competence, training and authority. All three, and authority is the one most often missing — oversight without the power to stop is just watching.
- Monitor operation, and where you have reason to think that use per instructions creates a risk, suspend use and inform the provider and the authority.
- Make sure input data is relevant and sufficiently representative for the intended purpose, to the extent you control that data.
- Keep the automatically generated logs for at least six months, unless Union or national law — data protection in particular — says otherwise.
- Inform workers’ representatives and affected workers before putting a high-risk system into service in the workplace.
Source: Article 26: Obligations of deployers of high-risk AI systems, European Commission AI Act Service Desk, accessed 2 October 2026. The article also carries duties to inform people affected by the system’s decisions and, for certain uses, a fundamental rights impact assessment.
Read closely, Article 26 is a description of what running something in production actually means: someone watching, with authority to switch it off, a record that is kept, and a view on the data going in. It is the same substance that governance and control of AI automation solves for reasons that have nothing to do with a regulator. Teams that already built it clear Article 26 almost by accumulation. Teams that did not discover the law is asking them to build the operation they never built.
What being a provider costs you: the full Article 16 package
Here is the asymmetry that makes the question worth answering. Becoming a provider is not «a bit more paperwork». It is a different regime, with obligations you cannot improvise in the quarter you find out about them.
| Provider obligation | Reference | What it means building |
|---|---|---|
| Risk management system across the lifecycle | art. 9 | A continuous, documented process of identification, assessment and mitigation — not a matrix filled in once |
| Data governance for training, validation and testing data | art. 10 | Provenance, collection criteria, biases examined, known gaps |
| Technical documentation | art. 11 and Annex IV | A file that describes the system and lets an authority assess its conformity |
| Automatic record-keeping of events | art. 12 | Traceability by design, not application logs repurposed |
| Instructions for use and transparency toward the deployer | art. 13 | Product documentation: capabilities, limits, expected oversight |
| Human oversight designed into the system itself | art. 14 | Intervention points that are built, not a policy written next to it |
| Accuracy, robustness and cybersecurity | art. 15 | Declared levels, held over time |
| Quality management system | art. 17 | Written procedures that are actually followed, with owners |
| Conformity assessment, CE marking and EU database registration | arts. 43, 48 and 71 | A procedure that assumes everything above exists and can be demonstrated |
| Keep the documentation for ten years | art. 18 | Ten years, not six months. The change in order of magnitude is the whole difference |
Source: Article 16: Obligations of providers of high-risk AI systems, Regulation (EU) 2024/1689, accessed 2 October 2026. Article 16 points back at the Chapter 2 requirements — Articles 9 through 15 — and adds the quality system, the conformity assessment and the registration.
Hold the two columns side by side as they land in real life: the deployer keeps logs for six months, the provider keeps the file for ten years. The deployer monitors, the provider demonstrates. That is the border, and it gets crossed by decisions that feel like product calls at the time.
The three Article 25 doors people walk through by accident
All three get crossed in the ordinary work of shipping a useful agent. None of them involves bad faith. All of them involve nobody asking the question at the moment it mattered.
- The brand. The assistant ships with your name, your domain and your visual identity, because presenting it as «some vendor’s chat» looked weak. For Article 25, putting your mark on a high-risk system already on the market is the most literal of the three triggers.
- The substantial modification. Your own data sources, rewritten instructions, new tools the system can execute, a flow that decides when to escalate to a human. Each change feels like configuration. The sum, six months on, is a system whose behaviour is no longer the one the provider assessed.
- The intended purpose. The quietest one. A general-purpose system that starts out summarising and ends up deciding, in a domain Annex III treats as high-risk — employment, education, essential services, credit. Nobody decided to reclassify anything. The scope just grew.
The practical way not to cross without knowing is not to ban changes: it is to have written down how far each system is allowed to grow on its own and who signs off on the next step. That is exactly the conversation in the autonomy levels of an AI agent. The ladder that controls operational risk there controls classification risk here: every rung you climb is a point where the four questions get asked again.
The original provider does not vanish, but stops answering for that system
There is a consequence of Article 25 that almost nobody reads and that changes how contracts get negotiated: when someone becomes a provider through one of those three routes, the original provider shall no longer be considered the provider of that specific system. It is not a split; it is a handover. The original is bound to cooperate closely, make the necessary information available and give the reasonably expected technical access so the new provider can comply — but the one who answers is the new one.
The same article expects providers and the third parties supplying systems, models, tools, services, components or processes that get integrated to specify in writing the information, capabilities and technical access required. Translated: that clause is not a lawyer’s extra, it is the condition for the handover to be operable. Without it you are demonstrating conformity over a box you cannot open.
When it bites: the calendar moved, the classification did not
The high-risk regime lands later than the 2024 announcements implied. Per Orrick’s July 2026 analysis of the Digital Omnibus and the eight compliance changes it finalises, obligations for stand-alone Annex III high-risk systems are deferred to 2 December 2027, and those for AI embedded in Annex I regulated products to 2 August 2028, while the Article 50 transparency duties have applied since 2 August 2026 unchanged.
The lazy read of that deferral is «we have time». The correct read is different: what moved is the enforcement date, not the moment you make the decision that classifies you. If the agent you ship this quarter carries your brand and has changed purpose, December 2027 will not find you starting a file. It will find you reconstructing eighteen months of history for a system that has already been deciding things. Technical documentation and event records are not written retrospectively — either they are generated from day one or they do not exist.
And the clock runs against a fast-growing installed base. In 2025, 20.0% of EU enterprises with ten or more employees used AI technologies, up from 13.5% in 2024, per Eurostat (data extracted December 2025). Scope: European Union, enterprises with ten or more employees. That figure sizes the problem — how many organisations already have something to classify — not our result or anybody else’s.
How to answer the question this week
The check is short. What is not short is having the list to run it against, which is why almost nobody has run it.
- List the AI systems in use, each with an owner. If you cannot name them, the work starts here and not at classification: you cannot categorise what has not been counted.
- For each one, decide whether its purpose lands in a use Annex III treats as high-risk. If it does not, the provider-versus-deployer question loses most of its weight. If it does, carry on.
- Ask the three Article 25 questions: does our brand appear on it? have we modified it substantially? have we changed its purpose relative to what the provider documented?
- Write the resulting role next to the system, with a date and the name of whoever decided it. A label without an owner gets reopened in the next meeting.
- Keep the reasoning, not just the conclusion. What you will be asked for is not the label: it is why you picked that one and on what information.
Step five is the one almost nobody does and the one that pays. A classification with no stored reasoning is an opinion with a date on it, and it collapses the day the team changes or the vendor updates the model. Building that file while the system runs — inventory, risk category, role, documentation and oversight, each with an owner — is complying with the AI Act while you operate your AI, and half the work is making the trail generate itself instead of being rebuilt in a panic. The piece that makes it demonstrable, being able to explain one specific decision months later, is traceability of AI decisions.
The question today is not whether the hard regime will land on you. It is whether anyone at your company has looked. Four questions per system, one afternoon and a boring document separate the people who know which role applies from the people who will find out when nothing can be changed.