Article 26 EU AI Act: the obligations for deployers of high-risk AI explained

Discussions about the EU AI Act tend to focus on providers: the parties that develop AI systems and place them on the market. But most organisations do not build AI, they use it. If you operate a high-risk AI system for recruitment, credit scoring or access to public services, you are a deployer in the terminology of the regulation, and Article 26 applies to you. That article contains its own list of obligations, separate from what the provider has to do. This article walks through the paragraphs of Article 26 and translates them into what you need to organise.

Who is a deployer?

A deployer is an organisation that uses an AI system under its own authority in a professional context. The distinction from the provider determines which obligations apply: the provider must ensure the system meets the product requirements, the deployer must ensure it is used responsibly. Note that a company that offers a purchased system under its own name, or substantially modifies it, can become a provider itself, with the heavier regime of Article 16 and onwards.

Article 26 only applies to high-risk AI systems: the systems listed in Annex III (such as AI for recruitment and selection, credit scoring and biometric identification) and AI used as a safety component in regulated products (Annex I). To determine whether your application qualifies, see our article on risk classification and the self-assessment at /ai-act-check.

The obligations per paragraph

Use according to the instructions for use (paragraph 1). The deployer must take appropriate technical and organisational measures to use the system in accordance with the provider's instructions for use. That sounds obvious, but it means someone has to have read those instructions, translated them into working procedures and assigned them to the teams working with the system.

Human oversight by competent people (paragraph 2). Oversight of the system must be assigned to natural persons who have the necessary competence, training and authority, and the necessary support. Authority is the key word: the person overseeing the system must be able to intervene, not just watch. An officer who spots deviating output but has no mandate to stop the system does not fulfil this requirement.

Relevant and representative input data (paragraph 4). To the extent the deployer exercises control over the input data, that data must be relevant and sufficiently representative in view of the intended purpose of the system. If you feed an external recruitment system with your own vacancy and candidate data, the quality of that data is your responsibility.

Monitoring, suspending and reporting (paragraph 5). The deployer must monitor the operation of the system on the basis of the instructions for use. If there is reason to consider that use in accordance with the instructions still results in a risk within the meaning of Article 79(1), the deployer must inform the provider or distributor and the market surveillance authority without undue delay, and suspend use of the system. For a serious incident there is a reporting chain: first the provider, then the importer or distributor and the market surveillance authorities. For financial institutions already subject to internal governance requirements under financial services law, the monitoring obligation is deemed fulfilled through those existing rules.

Retaining logs (paragraph 6). Logs automatically generated by the system must, to the extent they are under the deployer's control, be kept for a period appropriate to the intended purpose, with a minimum of six months, unless other Union or national law provides otherwise, in particular data protection law.

Informing workers (paragraph 7). If you deploy a high-risk AI system in the workplace as an employer, you must inform workers' representatives and the affected workers before putting it into use that they will be subject to the system. Think of AI that pre-sorts job applications or monitors performance. The works council should not learn about this after the fact.

Registration duty for public authorities (paragraph 8). Public authorities and EU bodies deploying a high-risk system must comply with the registration obligations of Article 49. If the system turns out not to be registered in the EU database, they must not use it and must inform the provider or distributor.

Link with the DPIA (paragraph 9). Where a data protection impact assessment under Article 35 GDPR is required, the deployer must use the information the provider has to supply under Article 13 of the AI Act. The provider's technical documentation and your own DPIA are not separate worlds.

Informing affected persons (paragraph 11). Deployers of Annex III systems that make decisions about natural persons, or assist in making them, must inform those persons that the high-risk system is being applied to them. This applies in addition to the general transparency obligations of Article 50.

Cooperating with authorities (paragraph 12). The deployer must cooperate with any action competent authorities take in relation to the system. Paragraph 10 also contains a specific regime for post-remote biometric identification in law enforcement, including an authorisation requirement; that is mainly relevant for police and judicial authorities.

What this means operationally

The common thread: Article 26 assumes you know which AI you use and that someone is responsible for it. In practice that starts with an AI inventory and a risk classification per system. For the systems that qualify as high-risk, a short list of setup questions follows. Have we received the instructions for use and the Article 13 information from the supplier, and turned them into working procedures? Who provides oversight, and does that person have a mandate and training? Where are the logs, who manages them and is the retention period arranged? Is there a route to suspend use and inform the provider and the authority when signals arise? And have the works council, employees and affected persons been informed where required?

Organisations running an AI management system under ISO 42001 will recognise almost all of these elements: the AI inventory, human oversight, logging and monitoring and supplier information all have a fixed place there. The AIMS is a logical vehicle for demonstrably meeting Article 26.

From when does this apply?

The original application date for the high-risk obligations was 2 August 2026. Through the Digital Omnibus package, finally approved by the European Parliament and the Council in June 2026, those dates have shifted: the obligations for Annex III systems will apply from 2 December 2027, those for Annex I systems from 2 August 2028. A delay is not a cancellation, and some elements take months to prepare: adjusting supplier contracts, assigning and training oversight roles, arranging logging. Public bodies and certain other deployers additionally face the fundamental rights impact assessment of Article 27, which we covered in a separate article. If you lay the groundwork now, the end of 2027 becomes a matter of verification rather than a scramble.

Non-compliance with the deployer obligations of Article 26 can result in a fine of up to 15 million euros or 3 percent of worldwide annual turnover (Article 99(4)). Want to know where your organisation stands? Take the self-assessment at /ai-act-check or get in touch.

Source: Regulation (EU) 2024/1689 (AI Act), Article 26, via EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689/oj. The new application dates follow from the Digital Omnibus amendment, finally approved in June 2026.