Two roles, two sets of obligations
A provider develops an AI system or places it on the market under its own name. Its obligations for high-risk systems are extensive: a risk management system across the entire lifecycle, technical documentation, conformity assessment, CE marking, entry in a public EU database, a quality management system, and post-market monitoring. A deployer uses an AI system for its own professional purposes. Its obligations are noticeably lighter even in the high-risk case: use the system per the instructions, ensure human oversight by trained personnel, inform affected people, keep automatically generated logs for at least six months, and – in certain cases – carry out a fundamental rights impact assessment (see “Human Oversight and the Fundamental Rights Impact Assessment”).
The provider trap: three concrete triggers
You don't become a provider only through intent, but through three clearly defined actions (Art. 25):
- Your own brand: you place an existing high-risk system on the market under your own name or brand – even if you didn't develop it yourself.
- Substantial modification: you change a high-risk system already on the market such that it's no longer covered by the original conformity assessment.
- Repurposing a general-purpose system: you take a system that wasn't originally classified as high-risk and change its purpose so it now falls into a high-risk category.
What counts as a “substantial modification”?
A substantial modification isn't a trivial threshold. It exists when a change wasn't part of the original conformity assessment and affects compliance with the requirements – or when the system's intended purpose changes. Deliberately fine-tuning a model for a new, more sensitive use case is already enough, even if the underlying technical architecture stays the same.
Practice section: the role check before every new AI project
Before introducing a new AI system or adapting an existing one, three questions help: Is the system being passed on under your own name or brand? Is something being changed about the system's behaviour that goes beyond mere configuration? Is a previously harmless system being used for a new, potentially high-risk purpose? If the answer to any is yes, the role check belongs at the start of project planning – in the architecture decision, not as an afterthought once branding and code are already fixed. This classification doesn't replace case-by-case legal advice.