← Back to all articles
Insights

Article 26 EU AI Act: A Plain-English Guide to Every Deployer Obligation

Generated image

Your organisation didn't build the AI system. You bought it, licensed it, or plugged it into your workflow. Under the EU AI Act, that makes you a deployer - and Article 26 of Regulation (EU) 2024/1689 places a distinct set of legal obligations squarely on your shoulders.

This guide walks through every one of those obligations in plain English. It is written for compliance leads, risk officers, and operations teams who need to understand what the law actually requires of them - not of the vendor who built the system.

Article 26 of Regulation (EU) 2024/1689 sets out the obligations of deployers of high-risk AI systems and sits within Title III, Chapter 3 of the Act.


Who Is a Deployer?

A deployer is any natural or legal person, public authority, agency, or other body that uses a high-risk AI system under its own authority - except where the use is purely personal and non-professional. If your organisation buys, licenses, or otherwise puts a high-risk AI system to work in a professional context, you are its deployer.

The EU AI Act deliberately splits responsibility along the supply chain. The provider must build the system to the legal standard; the deployer must use it safely and transparently. Both sides have duties, and "we just use a tool we bought" is not an exemption.

star Important

Deployer obligations cannot be contracted away. You can allocate operational tasks between teams or to vendors, but the legal responsibility under Article 26 remains with the deployer. A clause in your procurement contract does not transfer your regulatory exposure.


The Deadline Has Moved - But the Obligations Haven't

Before diving into the obligations themselves, you need the correct dates.

On 29 June 2026, the Council of the EU gave its final green light to the Digital Omnibus on AI simplification package, following the European Parliament's formal endorsement on 16 June 2026. This amended the original timeline for high-risk AI obligations, including those in Article 26.

The new structure is a two-tier system:

  • 2 December 2027 - for stand-alone high-risk AI systems listed in Annex III (covering, among others, recruitment tools, credit-scoring systems, biometric identification, law enforcement, education, and border control)
  • 2 August 2028 - for high-risk AI systems embedded as safety components in regulated products under Annex I (such as medical devices, machinery, and vehicles)

Stand-alone high-risk AI systems listed in Annex III were originally due to comply by 2 August 2026; the Digital Omnibus extends that deadline by 16 months to 2 December 2027.

These dates replace the original 2 August 2026 deadline for Annex III systems. Importantly, the delay is a calendar adjustment - the obligations themselves are unchanged. The extra time is there because key harmonised standards and national competent authority designations were not going to be ready in time. It is not a signal that the rules are softening.

warning Warning

Not everything moved. Article 50 transparency obligations — including informing people when they are interacting with an AI system — remain in force from 2 August 2026 on the original schedule. If you deploy consumer-facing AI in the EU, that deadline is live now. Confirm the exact applicable dates for your systems as implementing detail is finalised, and treat the extra time on high-risk obligations as a planning window, not a pause.


The 12 Deployer Obligations Under Article 26

1. Use the System in Accordance with the Provider's Instructions (Art. 26(1))

This is the foundational obligation. Deployers must take appropriate technical and organisational measures to ensure they use high-risk AI systems in accordance with the instructions for use supplied by the provider.

In practice, this means reading the instructions for use (required under Article 13), understanding the system's intended purpose and limitations, and not deploying the system for use cases the provider has not documented. It also means keeping those instructions current - if the provider issues an update, your deployment practices need to follow.

The phrase "appropriate technical and organisational measures" is structurally similar to the language in GDPR Article 32, where a decade of enforcement has established that "appropriate" is a moving baseline tied to the state of the art. Expect the same interpretive approach here.

2. Assign Human Oversight to Competent Natural Persons (Art. 26(2))

Deployers must assign the task of human oversight to natural persons who have the necessary competence, training, and authority, as well as the necessary support to carry it out effectively.

This obligation links directly to Article 14, which sets out the human oversight requirements that providers must design into high-risk systems. The deployer's job is to operationalise those design-time requirements: identify who will exercise oversight, ensure they are trained, give them the authority to intervene or suspend use, and resource them properly.

Named individuals, documented competence records, and a clear escalation path are the minimum evidence you will need to demonstrate compliance. Assigning oversight to a role rather than a named person - without ensuring that role is actually filled and trained - will not be sufficient.

3. Ensure Input Data Is Relevant and Representative (Art. 26(4))

Where the deployer exercises control over the input data fed to the system, it must ensure that data is relevant and sufficiently representative in view of the intended purpose of the high-risk AI system.

This obligation is conditional - it applies only to the extent you control the inputs. But many deployers do control inputs: the documents uploaded to a CV-screening tool, the financial data fed to a credit-scoring model, the images submitted to a medical imaging system. If that is your situation, you need a process for validating data quality before it enters the system.

4. Monitor Operation and Report Emerging Risks (Art. 26(5))

Deployers must monitor the operation of the high-risk AI system on the basis of the instructions for use. Where a deployer has reason to consider that use of the system may present a risk within the meaning of Article 79(1) - a risk to health, safety, or fundamental rights - they must, without undue delay, inform the provider or distributor and the relevant market surveillance authority, and suspend use if necessary.

This is an active, ongoing obligation - not a one-time check at deployment. It requires integrating AI monitoring into your existing operational processes: incident management, risk registers, and escalation workflows.

5. Serious Incidents: Immediate Reporting (Art. 26(5), linking to Art. 73)

Where a serious incident occurs, the deployer must immediately inform the provider first, then the importer or distributor, and then the relevant market surveillance authorities. Article 73 governs the serious incident reporting regime in detail.

The key distinction from the emerging-risk obligation above is urgency and sequence. Serious incidents require immediate action and a defined notification chain. Your incident response procedures need to reflect this - including knowing which national competent authority is your relevant market surveillance authority (this is determined by Member State, not by Brussels).

6. Keep Automatically Generated Logs for at Least Six Months (Art. 26(6))

Deployers of high-risk AI systems must keep the logs automatically generated by the system, to the extent those logs are under their control, for a period appropriate to the intended purpose of the system and of at least six months, unless applicable Union or national law requires a longer period.

This is the deployer log retention obligation, and it is one of the most practically demanding. Logs are your audit trail: they demonstrate that the system was used correctly, that oversight was exercised, and that outputs can be reviewed after the fact. Without them, you cannot prove compliance and you cannot investigate incidents.

Before deployment, confirm with your vendor: does the system generate logs by default? Where are they stored? Do you have access to them? Is six-month retention configured? If logs contain personal data, GDPR data minimisation and retention obligations apply alongside the AI Act requirement - the two frameworks need to be reconciled.

Financial institutions subject to internal governance requirements under Union financial services law must maintain logs as part of their documentation under that law.

7. Inform Workers' Representatives and Affected Workers Before Workplace Deployment (Art. 26(7))

Before putting a high-risk AI system into use at the workplace, deployers who are employers must inform workers' representatives and the affected workers that they will be subject to the use of the system.

This is a pre-deployment obligation, not a post-deployment notice. HR and operations teams deploying productivity monitoring, task allocation, performance assessment, or recruitment AI must satisfy this requirement before the system goes live. Document the notification - date, recipients, and the information provided.

8. Registration Duties for Public Authorities (Art. 26(8), linking to Art. 49)

Deployers that are public bodies must register their high-risk AI systems in the EU database before use and must not use unregistered systems. Article 49 sets out the registration requirements in detail. Private-sector deployers are not subject to this specific obligation, but should confirm whether their provider has completed the required registration on the provider side.

9. Inform Affected Natural Persons (Art. 26(11))

Where a deployer uses a high-risk AI system to make or assist in making decisions about natural persons, those persons must be informed. This applies to decisions that affect individuals - employment decisions, credit decisions, benefit eligibility, and similar.

The obligation is about transparency to the people affected, not just internal documentation. It sits alongside the right to explanation under Article 86, which gives individuals affected by decisions based on high-risk Annex III systems the right to a clear and meaningful explanation of the AI's role in the decision-making process.

10. Cooperate with Competent Authorities (Art. 26(12))

Deployers must cooperate with relevant competent authorities in any action those authorities take in relation to the high-risk AI system in order to implement the Regulation. This includes providing information, access, and assistance when requested.

Supplying incorrect, incomplete, or misleading information to national competent authorities in response to a request is itself a separate infringement under Article 99(5) - carrying its own fine tier of up to €7.5 million or 1% of global annual turnover.

11. Fundamental Rights Impact Assessment - Article 27 (Related Obligation)

Certain deployers must complete a Fundamental Rights Impact Assessment (FRIA) under Article 27 before first deployment. This applies to:

  • Bodies governed by public law
  • Private entities providing public services
  • Deployers of credit-scoring or life/health insurance systems (Annex III points 5(b) and 5(c))

The FRIA is a distinct obligation from Article 26 itself, but it is closely linked and must be completed before go-live for in-scope deployers. See our Article 27 FRIA guide for the full detail.


The Article 25 Trap: When a Deployer Becomes a Provider

This is the risk that catches organisations off guard. Under Article 25, a deployer is treated as a provider - and inherits the full, significantly heavier provider obligations under Article 16 - in any of the following situations:

  1. You put your own name or trademark on a high-risk AI system already placed on the market or put into service.
  2. You make a substantial modification to a high-risk system in a way that it remains high-risk.
  3. You change the intended purpose of an AI system (including a non-high-risk one) so that it becomes high-risk.

Under Article 25(1) of the EU AI Act, a deployer who makes a substantial modification to a high-risk AI system acquires all the obligations of a provider, including conformity assessment, CE marking, and the full technical documentation burden.

Standard configuration - setting parameters within the range the provider specifies - is not a substantial modification. But fine-tuning a model on your own data that shifts its capabilities significantly, adding use cases not covered in the provider's instructions, or integrating the system into a larger pipeline that materially changes how it functions can all trigger reclassification.

White-labelling a vendor's tool under your brand is the clearest trigger. Organisations that buy AI platforms with low-code or no-code customisation options need to assess each customisation against this threshold.

Isometric diagram showing a supply chain with three nodes: a provider building an AI system in a lab, a deployer using it in an office setting, and an arrow between them labelled 'instructions for use'. A second arrow loops back from the deployer node labelled 'Article 25 reclassification risk' when the deployer modifies or rebrands the system. Clean, professional, minimal colour palette.

What the Penalties Look Like

Under Article 99(4) of the EU AI Act, non-compliance with deployer obligations under Article 26 is subject to administrative fines of up to €15,000,000 or, if the offender is an undertaking, up to 3% of its total worldwide annual turnover for the preceding financial year, whichever is higher.

The 3% figure is calculated against global turnover - not EU revenue, not the revenue of the specific product line. For large organisations, the percentage will almost always exceed the flat cap. For SMEs and start-ups, Article 99(6) inverts the rule: the fine is capped at the lower of the two figures.

Supplying incorrect or misleading information to authorities carries a separate, lower tier: up to €7.5 million or 1% of global turnover.


Deployer Readiness: A Practical Checklist

Use this before your applicable deadline - 2 December 2027 for most Annex III stand-alone systems, 2 August 2028 for Annex I embedded systems.


Three Things to Do With the Extra Time

The Digital Omnibus delay is not a reason to stand down. Organisations that bank the extension and defer planning until mid-2027 will find themselves scrambling - the same position they were in before the Omnibus. Here is how to use the runway well:

1. Complete your AI system inventory now. Classification - determining which systems are high-risk under Annex III as amended - is the prerequisite for everything else. It cannot be done in the final quarter before a deadline.

2. Build deployer governance into procurement. Your contracts with AI vendors should require them to supply timely instructions for use, security patches, incident guidance, and updated documentation. Establish who owns the provider relationship and who monitors it.

3. Treat log retention as infrastructure, not paperwork. Six months of automatically generated logs, accessible to your team, reconciled with GDPR - this requires technical configuration, not just a policy. Start the conversation with your vendor now.


This post is for informational purposes only and does not constitute legal advice. Consult qualified legal counsel for advice specific to your organisation's situation. Deadlines referenced reflect the Digital Omnibus on AI as adopted by the Council of the EU on 29 June 2026; confirm the final applicable dates as implementing detail is finalised following Official Journal publication.