Most mid-market teams first encounter the EU AI Act through a vendor contract — then discover that buying software does not outsource compliance. The Act deliberately assigns overlapping but distinct duties to providers (who put a system on the market) and deployers (who use it under their authority). Getting this wrong is one of the fastest ways to end up under-documented on the eve of enforcement.
This guide explains the split in practical terms, without replacing legal advice from counsel in your jurisdiction.
Definitions in Plain Language
Provider — The natural or legal person that develops an AI system or has it developed with a view to placing it on the market or putting it into service under their own name or trademark. In practice: the product company, the integrator who white-labels a model, or sometimes your own organisation if you build in-house tools for others.
Deployer — The person or organisation using an AI system under their authority, except where the system is used in a personal non-professional activity. In practice: your company when you run HR scoring software, credit decisioning tools, or customer-risk models — even if every line of code was written by someone else.
A single entity can be both provider and deployer for different systems, or even for the same lifecycle if you fine-tune a vendor model and put it into production under your brand.
Why the Distinction Matters
Obligations under the Act are not “whoever has the best lawyers”. They attach to the role you play for a given system:
- Technical documentation (Article 11 / Annex IV) is primarily a provider burden for high-risk systems — but deployers must still be able to demonstrate conformity in use, work with incomplete vendor packs, and in many cases produce deployer-specific records (for example logs, use policies, and fundamental rights assessments).
- Post-market monitoring (Article 72) expectations apply along the value chain; deployers often hold the operational data that makes monitoring meaningful.
- Human oversight, accuracy, and robustness in real deployment contexts are frequently deployer responsibilities — because only the deployer controls workflows, thresholds, and human-in-the-loop design in production.
If your procurement checklist only asks “Is the vendor certified?”, you may be missing half of the compliance story.
Typical Split for Enterprise SaaS
For a standard third-party high-risk AI product:
| Topic | Usually provider-led | Usually deployer-led |
|---|---|---|
| Core Annex IV technical documentation | Yes | Contributes use-case specifics |
| CE / conformity assessment narrative (where applicable) | Yes | Interfaces with notified bodies where required |
| Fundamental rights impact assessment (where required) | Supports with product info | Owns for actual deployment context |
| Operational logging & incident escalation | Provides tooling hooks | Owns processes and retention |
| Staff training on oversight | May offer materials | Owns role design and enforcement |
| Procurement & vendor due diligence | N/A | Owns |
Your risk classification should record both parties and flag missing artefacts early.
Practical Steps for Compliance Teams
-
Tag each system with roles — For every row in your inventory, record provider name, deployer (often “us”), and whether you are also a provider for any variant (custom model, embedded agent, etc.).
-
Request the provider pack in structured form — Ask for Annex IV-aligned documentation, not a generic security white paper. Align requests to the Annex IV checklist so gaps are obvious.
-
Run deployer assessments on your use — Same model, different geography or decision threshold can change risk. Treat vendor statements as inputs, not conclusions.
-
Contract for cooperation — Ensure your agreements include incident cooperation, model update notifications, and documentation updates when the system changes.
-
Plan for operational monitoring — See our overview of post-market monitoring and the monitoring setup guide for how Aikraft supports drift logging and regulatory alerts.
Closing Thought
The EU AI Act assumes adults at both ends of the wire: vendors who document what they ship, and organisations who govern how it is used. Mid-market deployers who ignore their side of the ledger are taking on silent liability — often for systems they did not build but fully control in operation.
If you are unsure where your organisation sits, start with inventory and classification, then map obligations role-by-role. When you are ready to operationalise, get started with Aikraft or take the free risk quiz for a first-pass read on exposure.