Provider or deployer? The Art. 25 reclassification trap
Most organisations assume that buying a system makes them a deployer. Article 25 can move them into the provider's obligation set anyway, without them ever training a model. The three triggers.
The intuitive split is that whoever builds the system is the provider and whoever uses it is the deployer. It holds often enough to be dangerous, because Art. 25 reassigns a deployer of a high-risk system into the provider's obligations when any of three things happens.
The three triggers
- Putting your own name or trademark on it. A high-risk system already on the market, rebadged and supplied under your brand, pulls provider duties toward you.
- Substantial modification. A change not foreseen in the original conformity assessment that affects compliance. In practice this is why fine-tuning on your own data, or rebuilding a retrieval pipeline, belongs in the triage rather than in the changelog.
- Changing the intended purpose so that a system which was not high-risk becomes one.
Why this is the wrong thing to guess at
The two obligation sets are not close in weight. Provider duties for high-risk systems run to a risk management system, technical documentation, data governance, conformity assessment, registration, and post-market monitoring. Deployer duties under Art. 26 are real but far lighter. Getting the role wrong therefore means either carrying a programme you do not owe, or — worse — missing one you do.
RoleTriage records which trigger fired and which inputs produced that conclusion, so the decision can be reviewed rather than rediscovered. It does not make the determination for you.
Decision-support only. Article 25 determinations belong with qualified counsel, and the Commission guidance on substantial modification is still developing.