Deployer Obligations for High-Risk AI Systems (Article 26)

Most writing about high-risk AI compliance describes what a provider owes. Article 26 is the other list, and an organisation that buys a high-risk system rather than building one is bound by it directly — several of its duties cannot be contracted back to the vendor because they are about what happens inside your operation.

Use in accordance with the instructions

Article 26(1) of Regulation (EU) 2024/1689 requires deployers of high-risk AI systems to take appropriate technical and organisational measures to ensure they use such systems in accordance with the instructions for use accompanying them. The full text is on EUR-Lex.

The instructions for use are not marketing collateral: Article 13 specifies what they must contain, including the system's intended purpose, its known limitations, its expected level of accuracy and the human oversight measures it is designed for. Article 26(1) turns that document into a binding operating envelope for you. Going outside it has a further consequence under Article 25(1)(c): a deployer who modifies the intended purpose of a high-risk system becomes a provider of it, inheriting the entire Chapter III provider regime. The general split is on the provider versus deployer page.

Assigning human oversight

Article 26(2) requires deployers to assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support. Every one of those four words is a separate test, and this is the most frequently under-implemented duty in the article.

• Natural persons. Named individuals. “The compliance team” is not an assignment.
• Competence and training. The person must actually be able to do the job the provider's Article 14 oversight design assumes — to interpret the output, understand the automation bias risk, and know when to disregard the system. This is where the Article 4 AI literacy obligation meets a specific duty; see the AI literacy page.
• Authority. The power to override or stop the system. An overseer who can flag but not intervene does not satisfy this, and it is a question about your internal governance, not about software.
• Support. Time, tooling and escalation. A reviewer given four seconds per decision has been assigned oversight nominally.

Article 14 is the provider-side counterpart: it requires the system to be designed so oversight is possible. Article 26(2) requires you to staff it. See the Article 14 page. Article 26(3) makes clear that these duties are without prejudice to other obligations under Union or national law and do not affect the deployer's freedom to organise its own resources and activities.

Input data relevance

Article 26(4) applies to the extent the deployer exercises control over the input data: it must ensure the input data is relevant and sufficiently representative in view of the intended purpose of the high-risk AI system.

The conditional matters. A deployer using a system on data it does not choose is in a different position from one feeding in its own historical records. But the second case is extremely common — a recruitment system scoring your applicant pool, a credit system reading your customer file — and there the duty is squarely yours. The provider's Article 10 data governance obligations concern the training, validation and testing data; Article 26(4) concerns what you put in at run time, and no amount of provider-side work discharges it. The two duties are complementary and neither absorbs the other.

“Sufficiently representative” is the phrase to reason about before deployment rather than after. A system validated on a population that does not resemble yours is being used outside the conditions its accuracy claim rests on, which is both an Article 26(4) problem and an Article 26(1) problem.

Logs, and the six-month floor

Article 26(6) requires deployers to keep the logs automatically generated by the high-risk AI system, to the extent those logs are under their control, for a period appropriate to the intended purpose of the system, of at least six months, unless provided otherwise in applicable Union or national law, in particular Union law on the protection of personal data.

Read that as a floor with two qualifications rather than as a retention period. Six months is a minimum, not a target; “appropriate to the intended purpose” will often mean longer, because a system whose decisions can be challenged years later needs logs that outlive the challenge window. And the data protection carve-out cuts the other way — GDPR storage limitation can make a long retention unlawful, so the two constraints have to be reconciled rather than maximised. That tension is worked through on the log retention page, and what the logs themselves have to contain is set by the provider's Article 12 design obligation rather than by Article 26.

“To the extent the logs are under their control” is the clause to check in a vendor contract. If the system is operated as a hosted service and the logs sit with the provider, you need a contractual route to them — otherwise you have an obligation you cannot discharge and a supplier with no duty to help. That belongs in the contract before deployment, alongside the audit and cooperation rights the rest of Article 26 assumes you have.

Monitoring, workers and telling people

The remainder of Article 26 is a set of duties that are easy to miss because they are unglamorous:

• Monitoring and escalation (26(5)). Monitor operation on the basis of the instructions for use. Where there is reason to consider that use in accordance with the instructions may present a risk within the meaning of Article 79(1), inform the provider or distributor and the relevant market surveillance authority, and suspend use without undue delay. Where a serious incident is identified, immediately inform first the provider, then the importer or distributor and the relevant market surveillance authorities.
• Workers (26(7)). Before putting a high-risk system into service or using it at the workplace, deployers who are employers must inform workers' representatives and the affected workers that they will be subject to its use. This is a floor: national works council and employee consultation law frequently requires more, and earlier, than the AI Act does.
• Registration (26(8)). Public authorities and Union institutions must comply with the Article 49 registration obligations, and if they find the system is not registered in the EU database they must not use it and must inform the provider or distributor. Note the direction of that duty: a missing registration is a reason for a public deployer to stop, not merely to complain.
• Data protection (26(9)). Where applicable, use the Article 13 information to carry out a DPIA under Article 35 GDPR.
• Telling affected people (26(11)). Without prejudice to Article 50, deployers of Annex III high-risk systems that make or assist in making decisions about natural persons must inform those persons that they are subject to the system's use.
• Cooperation (26(12)). Cooperate with the relevant competent authorities on any action taken in relation to the system.

Some deployers additionally owe a fundamental rights impact assessment under Article 27; who exactly is on the FRIA page. On timing, the headline date moved. Article 26 was originally to apply from 2 August 2026 under Article 113; for stand-alone high-risk systems under Annex III that date is now 2 December 2027, postponed by Regulation (EU) 2026/1744. Where the high-risk system is embedded in a product regulated under Annex I, the date is 2 August 2028. The Article 111(2) transitional rules for systems already on the market continue to apply on their own terms.