You Bought the AI System. Three Things Can Still Make You Its Provider.
Most compliance plans sort the company into "deployer" on day one and stop there. The Act does not treat that label as permanent. Put your brand on the system, point it at a different purpose, or change it in a way its conformity assessment never covered, and the provider file moves to your side of the table.
The Label Is a Function of What You Do, Not What You Signed
Deployer obligations are real but comparatively light: use the system according to the instructions, assign competent human oversight, keep the logs you control, feed input data that is relevant for the intended purpose, inform the people subject to it, and tell the provider and the authorities when something goes wrong. Provider obligations are an entire compliance programme with a conformity assessment at the end of it.
The gap between those two positions is why the reclassification rule matters more than its share of most compliance decks. A team that considers itself a customer can walk across the line during an ordinary product sprint — a rebrand, a new use case, a retraining run — with nobody in the room aware that the legal position changed.
The Three Triggers, and What Each One Actually Looks Like
Name or Trademark on the System
IMMEDIATEReselling a vendor's high-risk system under your own brand, or embedding it so completely that the customer only ever sees your name. No modification needed — the branding alone moves the provider role.
Change of Intended Purpose
HIGHA document classifier sold for general workflow use, redeployed to rank job applicants or to decide who gets a payment plan. The system is now in an Annex III category it was never assessed for.
Substantial Modification
HIGHRetraining on your own data in a way that shifts performance characteristics, bolting on a decision layer the vendor never assessed, or changing how outputs are acted on so the documented human-oversight design no longer holds.
Not a Trigger: Foreseen Adaptation
SAFEConfiguration, thresholds, supported customisation interfaces, and continuous-learning behaviour the provider anticipated and covered in its assessment. Documented anticipation is what keeps this on the vendor's side.
What Lands on You the Moment a Trigger Fires
For a high-risk system, becoming the provider means owning the risk management system across the lifecycle, the data governance requirements for training, validation and testing sets, the Annex IV technical documentation, automatic logging, instructions for use for your own downstream deployers, the human oversight design, the accuracy, robustness and cybersecurity requirements, a quality management system, the conformity assessment and CE marking, the EU database registration, and post-market monitoring with serious incident reporting.
The practical problem is that most of that file describes the system's internals, and you do not have them. The original provider is obliged to cooperate and to supply the information and technical access needed — but "obliged to cooperate" is a poor substitute for a contract clause that names the artefacts, the format, and the response time.
Controls That Keep the Line Visible
The failure mode is not disagreement about the rule. It is nobody noticing the sprint that crossed it.
Audit your AI product's compliance exposure
RatedWithAI helps tech teams understand their compliance posture across accessibility, privacy, and AI regulation requirements. Start with a free scan.
Scan Your Product for Free →Frequently Asked Questions
We only changed the prompt and the system message. Is that a substantial modification?
Usually not on its own — prompting through a supported interface is the kind of configuration a provider anticipates. It becomes interesting when the prompt is what pushes the system into a new purpose, for example instructing a general assistant to score candidates. Then the trigger you hit is the change of intended purpose, not the modification.
The system keeps learning in production. Does every update reset the assessment?
No. Continuous-learning behaviour that the provider anticipated and covered in its conformity assessment does not count as a substantial modification, which is the point of assessing the learning behaviour rather than a frozen snapshot. What matters is whether the change was foreseen and documented, not whether the weights moved.
If we become the provider, does the original vendor walk away clean?
Not entirely. The original provider that placed the system on the market remains subject to obligations for what it placed on the market, and must cooperate with you and supply the information you need. But it is no longer the provider of your modified system, and enforcement for that system points at you.
Does this apply to non-high-risk systems too?
The heavy consequences attach to high-risk systems, because that is where the provider file exists. The move that catches most companies is exactly the one that creates a high-risk system where there wasn't one — taking something ordinary and directing it at an Annex III use.
How do we prove we stayed inside the vendor's assessment?
With the vendor's own written answer about which adaptations are covered, your change-control record showing what you changed and when, and the instructions for use you actually followed. Retrospective reconstruction is far weaker than a contemporaneous record, and the record costs nothing to keep.