Your legal team probably hasn't read Article 26. Your procurement team definitely hasn't. And whoever approved your Copilot rollout last quarter? They almost certainly had no idea it made you a deployer under EU law.
That is not a criticism. It is just where most mid-market organisations are right now - using AI across the business, and genuinely unaware that the EU AI Act already has a name for what they are doing and a set of rules that come with it. The rules are not optional. Different obligations under the EU AI Act are enforceable on different timelines: prohibited-practice and AI-literacy rules have applied since February 2025, GPAI model obligations since August 2025, and transparency duties under Article 50 since August 2026. The deployer obligations this article focuses on - Article 26, for high-risk systems - become binding on 2 December 2027, following a 16-month deferral under the Digital Omnibus on AI (Regulation (EU) 2026/1744). Penalties for non-compliance, once obligations apply, reach up to €15 million or 3% of global annual turnover.
The Act splits the world into two roles: provider - the company that built the AI - and deployer - the company using it. Most published guidance focuses almost entirely on providers. Most organisations reading this article are deployers. That gap is exactly where compliance failures happen.
What follows is a plain-language breakdown of what those two definitions actually mean, what deployers are legally required to do, and the scenario most compliance teams are completely unprepared for: being both at once.
"We built Montro because we kept seeing the same thing - companies with 40, 50, 60 AI tools in use, and a compliance team that only knew about three of them. You cannot govern what you cannot see. And you cannot meet your Article 26 obligations for systems you didn't know you were running." - Ankur Arora | Co-Founder, Montro
The Legal Definitions
The EU AI Act (Regulation (EU) 2024/1689) draws a precise and legally consequential line between two roles in Article 3. The distinction mirrors the controller/processor model from GDPR - it is based on the function you perform, not on any contractual label you assign yourself.
Provider - Article 3(3)
Article 3(3) - Legal Definition of 'Provider' "A natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge." |
The operative words are "places on the market" and "under its own name or trademark." A provider does not necessarily build the AI themselves - commissioning a third party to develop a system that you then brand and distribute makes you the provider. Equally, geography is irrelevant: a US company selling AI software to EU customers is a provider under the Act.
Concrete provider examples: OpenAI (GPT-4o), Microsoft (Azure AI), Salesforce (Einstein), any SaaS company deploying an AI feature to customers under their platform name, or an enterprise that commissions bespoke AI development and markets it internally or externally.
Deployer - Article 3(4)
Article 3(4) - Legal Definition of 'Deployer' "A natural or legal person, public authority, agency or other body using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity." |
A deployer uses an existing AI system under their own authority for their own operational purposes - but does not develop or market it as their own product. The threshold is low: any organisational use of an AI system qualifies unless it is a personal, non-professional activity. Public authorities, financial institutions, healthcare organisations, and every mid-market company using third-party AI tools are deployers by default.
Concrete deployer examples: A bank that licences a third-party credit scoring model. A hospital implementing an AI triage tool from a health-tech vendor. An HR department using an AI-powered recruitment screening platform. A logistics firm using a route-optimisation AI.
Provider vs Deployer at a Glance
Dimension | Provider (Art. 3(3)) | Deployer (Art. 3(4)) |
Legal Definition | Develops & places AI on market under own name/trademark | Uses AI system under own authority for business purposes |
Typical Example | OpenAI (GPT-4), Salesforce (Einstein), SAP AI | A bank using Salesforce Einstein; HR team using Copilot |
Compliance Burden | Heavy - full risk management, CE marking, DB registration | Lighter - but Art. 26 obligations are legally binding |
High-Risk AI Duties | Conformity assessment, technical docs, QMS (Arts. 9–17) | Use per instructions, human oversight, log retention |
Who bears primary liability? | Provider - unless deployer causes harm by misuse | Deployer - if harm results from non-compliance with Art. 26 |
Can be BOTH? | Yes - if the organisation builds on GPAI models (Art. 25) | Yes - simultaneously deployer of base model + provider of custom system |
The Deployer - Who This Is in Practice
The honest answer to 'who is a deployer?' is: the overwhelming majority of organisations operating in the EU. If you are not an AI product company that sells AI under your own brand, you are almost certainly a deployer. The arrival of enterprise AI tools across every business function has made deployer status the rule, not the exception.
20% of EU enterprises (10+ employees) used AI technologies in 2025 - up from 13.5% in 2024 and just 7.7% in 2021. Every single one of these organisations has deployer obligations. Source: Eurostat, ICT Usage Survey 2025 |
Consider the AI tools most commonly adopted by mid-market organisations today:
- Microsoft 365 Copilot - using it for email drafting, meeting summaries, or document creation: deployer.
- Salesforce Einstein - using it for lead scoring, customer segmentation, or sales forecasting: deployer.
- ChatGPT Enterprise - using it for internal knowledge management or customer support: deployer.
- An AI-powered ATS (applicant tracking system) from a third-party HR vendor: deployer.
- A fraud-detection or credit-risk AI system licensed from a fintech provider: deployer.
None of these organisations built the underlying AI. All of them are deployers under Article 3(4) - because they are using the systems under their own authority, for their own business purposes. The compliance burden is real, even if it is lighter than a provider's.
41% of large EU enterprises (250+ employees) used AI in 2024, vs. just 11% of small firms. Large-company deployers face the full weight of Article 26 high-risk obligations from August 2026. |
It is also worth noting what deployer status is not about. Receiving, evaluating, or piloting an AI system does not automatically trigger all Article 26 obligations - it is the active use under your authority that triggers them. But once you move to production, the clock is running.
Decision Flowchart: Provider or Deployer?
Are you an EU AI Act Provider or Deployer? | ||
Q1: Are you building or commissioning an AI system to place on the market or put into service under your name? | ||
YES → You are a PROVIDER | NO → Continue to Q2 ↓ | |
▼ | ▼ | |
PROVIDER OBLIGATIONS • Risk management system (Art. 9) • Technical documentation (Art. 11) • Conformity assessment & CE marking • EU database registration (Art. 49) • Post-market monitoring (Art. 72) • Serious incident reporting (Art. 73) | Q2: Are you using an AI system under your authority for your own purposes? YES → You are a DEPLOYER | |
▼ | ||
DEPLOYER OBLIGATIONS (Art. 26) • Use AI per provider instructions • Ensure human oversight (Art. 26.2) • Inform workers before deployment • Monitor & report risks/incidents • Retain logs ≥ 6 months (Art. 26.6) • Conduct FRIA if required (Art. 27) | ||
BOTH? If you build AI on top of a GPAI model (e.g. ChatGPT API) and offer it under your name, you are a PROVIDER for the downstream system - even if you are a deployer of the base model. | ||
Source: EU AI Act (Regulation (EU) 2024/1689), Articles 3(3), 3(4) and 26 | Official Journal, 12 July 2024
What Deployers Must Actually Do - Article 26 Obligations
Article 26 is the core compliance text for deployers of high-risk AI systems. It contains six operationally meaningful obligations. These are not advisory - they are legally binding from 2 December 2027 for high-risk AI systems, following the Digital Omnibus on AI's deferral of the original 2 August 2026 date, and failure to comply risks significant regulatory action. The infographic below maps each obligation to its article reference and practical interpretation.
Article 26 Obligations - Full Reference Table
SI. No | Obligation | Article Ref. | What It Means in Practice |
1 | Follow Instructions | Art. 26(1) | Deploy AI systems strictly in line with the provider's instructions for use. Document all intended use cases. |
2 | Human Oversight | Art. 26(2) | Assign named, trained, and authorised staff to oversee AI outputs. They must have real authority to override. |
3 | Inform Workers | Art. 26(7) | Before rollout: notify workers' representatives and all affected employees in writing, per local labour law. |
4 | Monitor & Report | Art. 26(5) | Actively monitor AI system performance. Report risks to providers; serious incidents to market surveillance authorities. |
5 | Retain Logs | Art. 26(6) | Keep auto-generated system logs for a minimum of 6 months (longer if sector rules require, e.g. financial services). |
6 | FRIA (if required) | Art. 27 | Public bodies & some private deployers (credit scoring, life insurance) must complete a Fundamental Rights Impact Assessment before deployment. |
Source: EU AI Act (Regulation (EU) 2024/1689), Article 26
Obligation 1: Use AI as Instructed - Article 26(1)
Deployers must implement 'appropriate technical and organisational measures' to ensure they use high-risk AI systems strictly in line with the provider's instructions for use. This is not a passive obligation - it requires actively operationalising the provider's guidance into your internal procedures, training, and governance. If your team uses an AI system for a purpose beyond what the provider specified, liability can shift to you under Article 25, which is why AI risk classification of each use case, not just each tool, is a deployer obligation, not a provider one.
Obligation 2: Ensure Human Oversight - Article 26(2)
Human oversight must be assigned to specific named individuals - not a team, not a policy document. Those individuals must have the necessary competence, training, and authority to intervene, override, or suspend the AI system's decisions or outputs. In practice, this means defining oversight roles in job descriptions, providing documented training, and creating a mechanism for overrides that is actually used - not just theoretically available.
Obligation 3: Inform Affected Workers - Article 26(7)
Before deploying a high-risk AI system in the workplace, deployers who are employers must notify both workers' representatives and the affected workers themselves - in writing, in advance, and in accordance with applicable national labour law. In several EU member states, this obligation may trigger formal consultation or co-determination procedures. A general privacy policy does not satisfy this obligation.
Obligation 4: Monitor & Report Risks/Incidents - Article 26(5)
Deployers must actively monitor the AI system's performance against the provider's instructions. If operation reveals a risk to health, safety, or fundamental rights, the deployer must without undue delay notify the provider or distributor and the relevant market surveillance authority - and suspend use if necessary. A serious incident (leading to death, serious harm, or critical infrastructure disruption) triggers an immediate reporting obligation.
Obligation 5: Retain Logs - Article 26(6)
Automatically generated logs must be retained for a minimum of six months, or longer if applicable sector regulation (e.g. financial services law) requires it. Critically, this obligation only applies to logs 'to the extent such logs are under the deployer's control' - making it essential to confirm with your provider, at contract stage, that you have actual access to and control over the relevant log data.
Obligation 6: Fundamental Rights Impact Assessment - Article 27
A Fundamental Rights Impact Assessment (FRIA) is required for public bodies and private entities providing public services deploying any Annex III high-risk AI system, and for any deployer using AI for credit scoring or insurance risk assessment. The FRIA must be conducted before deployment and must be notified to the relevant market surveillance authority. Results should feed directly into your DPIA process under Article 35 GDPR.
"Article 26 is not a paperwork exercise. Every obligation in it - human oversight, worker notification, log retention - requires something to actually exist in your organisation. A policy that references it is not the same as a person who owns it. Regulators will ask for both." - Namita Razdan | Co-Founder, Montro
When an Organisation Is Both Provider and Deployer
The provider/deployer binary breaks down as soon as an organisation begins customising or building on top of third-party AI. Article 25 of the EU AI Act addresses this directly: a deployer, distributor, or importer must assume provider obligations when they:
- Put their own name or trademark on a high-risk AI system already on the market;
- Make a substantial modification to a high-risk AI system that maintains its high-risk classification;
- Change the intended purpose of a system originally classified as non-high-risk so that it becomes high-risk.
Organisations rarely discover they are both provider and deployer through a legal review. It tends to happen through a contract. A vendor sends a data processing agreement that references the organisation's custom AI layer, and someone from the legal team reads it carefully. The DPA assumes that the organisation is distributing AI capabilities rather than just consuming it, and the assumption is correct. The organisation has been building on a GPAI model, wrapping it in proprietary logic, and deploying it internally across business units. During all this process, nobody mentioned the term 'provider' to describe what they were doing, but the contract did. Namita Razdan, Co-Founder, Montro |
The most common scenario in practice - and the one most compliance teams are unprepared for - is building custom AI applications on GPAI models. Consider this:
Real-World Example: The 'Both' Scenario A financial services firm licences the OpenAI API (acting as a deployer of the GPAI model). They build a custom credit risk assessment tool on top of it, branded as their own product and used to make lending decisions. Result: they are simultaneously a deployer of the OpenAI GPAI model AND a provider of their custom high-risk AI system - triggering the full suite of provider obligations (risk management system, technical documentation, conformity assessment, CE marking, EU database registration) in addition to their deployer obligations. |
This scenario is increasingly common in tech companies, InsurTech, LegalTech, and HealthTech organisations that treat GPAI models as infrastructure and build proprietary applications on top of them. The compliance implication is significant: the moment your custom layer is substantial enough to constitute a new AI system placed on the market under your name, you carry provider liability for it.
The EU AI Act does not offer a bright-line test for 'substantial modification' in the Act's text itself. The European Commission published draft guidelines on the classification of high-risk AI systems on 19 May 2026, which address the Article 25 triggers including substantial modification, but these remained in stakeholder consultation and had not been formally adopted as of this writing. Dedicated guidance on Article 25 value-chain responsibilities specifically is still to come. Until the guidelines are finalised, legal counsel should be involved in any customisation assessment.
The Deployer's Documentation Requirements
While providers carry the heaviest documentation burden under Articles 11–19, deployers operating high-risk AI systems are not off the hook. Article 26 and the broader accountability framework under the EU AI Act require deployers to maintain a structured, auditable set of records for each high-risk AI system they operate. These records must be available to supervisory authorities on request.
What records must contain:
- Identity of the AI system: Name, version, provider, intended purpose, and the specific use case for which you are deploying it.
- Instructions for use: The provider-supplied instructions, supplemented by your internal operational SOPs referencing them.
- Human oversight assignment: Named individuals, their competencies, training records, and any logged override decisions.
- Automatically generated logs: Retained for a minimum of six months, with access rights and storage arrangements documented.
- Worker and individual notifications: Dated evidence of notification to affected workers and, where applicable, individuals subject to AI-assisted decisions.
- Incident and risk register: Details of any risks identified or serious incidents reported, actions taken, and authorities notified.
- FRIA documentation (if applicable): Assessment results and notification to market surveillance authority.
How long to keep records: Article 26(6) specifies a minimum of six months for automatically generated logs. Other documentation should generally be retained for the duration of the AI system's use plus a reasonable period after decommissioning - many legal advisors suggest aligning with GDPR retention principles and sector-specific requirements. Financial services deployers subject to DORA or sector governance rules should align records to those frameworks.
Deployer Documentation Requirements
Document / Record | What to Capture | Status |
System Identity Register | Name, version, provider details, intended use case per deployment | MANDATORY |
Instructions for Use | Provider-supplied docs; your operational SOP referencing them | MANDATORY |
Human Oversight Log | Named oversight roles, competencies, training records, decision overrides | MANDATORY |
Auto-Generated Logs | Raw AI system logs; min. 6-month retention; access rights confirmed | MANDATORY |
Worker Notification Records | Dated proof of notification to workers' reps and affected staff | MANDATORY |
Incident/Risk Register | Date, nature of risk/incident, actions taken, authority notified | MANDATORY |
FRIA (if applicable) | Fundamental Rights Impact Assessment for qualifying deployments | MANDATORY |
Vendor Due Diligence File | Provider compliance docs, CE marks, EU DB registration numbers | RECOMMENDED |
Source: EU AI Act, Article 26 & Article 27 | Regulation (EU) 2024/1689
€15M or 3% Maximum penalty for deployers who breach Article 26 obligations - whichever is higher. These obligations, for high-risk AI systems, become enforceable on 2 December 2027, following the Digital Omnibus deferral from the original August 2026 date. Source: EU AI Act, Article 99 | Regulation (EU) 2024/1689 | Digital Omnibus on AI, Regulation (EU) 2026/1744 |
Frequently Asked Questions
Does deployer status apply to us if we only use AI tools occasionally or in a pilot?
Receiving or evaluating an AI system does not automatically trigger Article 26 obligations. Active use under your authority for your own operational purposes is what creates deployer status, and once a system moves to production, the obligations apply regardless of how frequently it is used. The threshold is lower than most organisations assume. A system used by one team in one business function, if it qualifies as high-risk AI systems under Annex III, carries the full set of Article 26 AI governance obligations from the moment it is in live use.
If a SaaS vendor enables an AI feature in a tool we already use, does that make us a deployer for that feature?
Deployer status attaches to use under your authority, not to procurement decisions, so yes, using a vendor-enabled AI feature in your environment can make you a deployer for that feature. Whether the heavier Article 26 obligations apply depends on whether the feature qualifies as a high-risk system under Annex III. But the broader deployer status, and the accountability that comes with it, is not limited to high-risk systems alone. This is one of the most common compliance gaps in mid-market organisations, AI that arrives through vendor updates rather than procurement decisions, and is never assessed because it was never formally adopted.
What does "human oversight" actually mean in practice under Article 26(2)?
It means a named individual - not a team, not a policy document, with documented competence, training, and the actual authority to intervene, override, or suspend the AI system's outputs. A human in the loop who has no practical ability to override the system does not satisfy the obligation. The oversight must be genuine, not nominal. In practice this means defining oversight roles in job descriptions, providing documented training for those individuals, and maintaining a record of any override decisions made.
When is a Fundamental Rights Impact Assessment required, and how does it relate to a GDPR DPIA?
A FRIA is required for public bodies and private entities providing public services deploying any Annex III high-risk AI system, and for any deployer using AI for credit scoring or insurance risk assessment. It must be completed before deployment and retained as part of the deployer's compliance documentation. Certain contexts may also require engagement with the relevant supervisory or market surveillance authority. The FRIA and DPIA are complementary rather than duplicative, a DPIA under GDPR Article 35 addresses risks to individuals from personal data processing, while a FRIA addresses fundamental rights impacts more broadly, including non-discrimination, dignity, and access to justice. Where both apply, the EDPB has confirmed a combined assessment is permissible, and extending an existing DPIA template is the most practical approach for most organisations.
