Provider vs deployer is one of the highest-impact distinctions in the AI Act. Misclassifying your role can lead to under-scoped controls and avoidable legal exposure.
A provider typically develops an AI system or places it on the market under its own name. A deployer uses an AI system in operational contexts. Many SMEs are deployers by default, but role can change when modification, branding, or re-placement on market occurs.
Fast role tests
Ask these in order:
1. Do we build/train the system ourselves?
2. Do we place it on the market under our name?
3. Do we substantially modify model behavior and re-release?
4. Are we mainly operating a third-party tool internally?
"Yes" to 1-3 usually indicates provider exposure. "Yes" to 4 usually indicates deployer exposure.
Why mixed-role companies are common
An SME can be a deployer in HR automation while simultaneously acting as provider for a customer-facing AI module sold under its own brand. Role should be assigned per system/use case, not per company.
Operational implications
Provider-heavy obligations often include stronger lifecycle documentation, conformity routes, and system-level accountability. Deployer-heavy obligations emphasize appropriate use, oversight, transparency, logging, and operational governance.
30-day role-clarity rollout
Week 1: map all AI systems and ownership boundaries.
Week 2: tag each as provider/deployer/mixed with rationale.
Week 3: align obligations and controls by role.
Week 4: review with legal/compliance and freeze assumptions in documentation.
Common pitfalls
- Assuming vendor responsibility covers deployer duties.
- Ignoring substantial modification effects.
- No documented rationale for role classification.
- No process to reclassify after architecture changes.
Final takeaway
Role clarity is foundational. Once role is clear, control priorities become obvious. Without role clarity, compliance plans become guesswork.