The Provider: The Architect of the System
You are a Provider if you develop an AI system, or commission it for placement on the EU market or for use under your brand.
- The burden: Highly technical. Providers must build a Risk Management System (Article 9), prepare Annex IV Technical Documentation, and apply CE marking if the system is high-risk.
- Example: A startup that builds an LLM-powered resume ranking tool and sells access via API to HR departments.
The Deployer: The Operational Operator
You are a Deployer if you use an AI system under your own authority in a professional or commercial activity.
- The burden: Operational. Deployers must ensure input data matches the intended purpose, monitor for anomalies, and retain logs for at least six months.
- Example: An insurance agency that uses a third-party AI claims processing tool with its internal customer database.
The critical traps: When a Deployer becomes a Provider
If a Deployer makes a substantial modification to a high-risk AI system, or alters its intended purpose so it becomes high-risk, they inherit the Provider’s technical responsibilities.
What triggers the switch?
- Substantially changing model behavior or decision logic.
- Changing intended use from a limited-risk task to a high-risk application.
- Adding a new downstream service that converts an advisory tool into a decision-making system.
How to allocate compliance effort correctly
Match your team responsibilities to the role you play:
| Role | Main Responsibility | Typical Deliverables |
|---|---|---|
| Provider | Technical design and conformity | Annex IV docs, model risk management, CE marking |
| Deployer | Safe operation and monitoring | Input validation, logs, oversight procedures |
Evaluate your system today
Your compliance obligations depend on your exact position in the value chain. A simple misclassification can either overburden engineering or leave the company exposed to regulatory fines.