Most organisations deploy AI systems rather than build them. Article 26 sets out what that role carries: instructions for use, human oversight, input data, monitoring, logs and notification.

Provider obligations get most of the attention, and most organisations are not providers. If you have bought a high-risk AI system and put it to use, Article 26 is the article that describes your position.

What the article requires

Article 26(1) sets the frame: deployers shall take appropriate technical and organisational measures to ensure they use such systems in accordance with the instructions for use accompanying the systems. The instructions the provider supplies are not documentation to be filed. They define the boundary of compliant use.

The rest of the article adds five duties on top of that.

Paragraph	Duty
26(2)	Assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.
26(4)	To the extent the deployer controls the input data, ensure it is relevant and sufficiently representative in view of the intended purpose.
26(5)	Monitor operation on the basis of the instructions for use, inform the provider where relevant, and suspend use plus notify the provider or distributor and the market surveillance authority where the system presents a risk within the meaning of Article 79(1). Serious incidents go first to the provider, then the importer or distributor and the authorities.
26(6)	Keep the logs the system automatically generates, to the extent they are under your control, for a period appropriate to the intended purpose and at least six months, unless other Union or national law provides otherwise.

The three that are easy to underestimate

Human oversight is a staffing decision, not a checkbox

The wording of 26(2) is specific about what the assigned people need: competence, training, authority, and support. Authority is the demanding word. A reviewer who can see the system's output but cannot override it, or whose override is routinely reversed, does not have authority in any meaningful sense.

Input data, where you control it

Article 26(4) is scoped by control. Where you feed the system your own data, the relevance and representativeness of that data is your responsibility rather than the provider's. A recruitment tool given a skewed historical dataset produces skewed results, and 26(4) places that squarely with the deployer.

Suspension is an obligation, not an option

The wording in 26(5) is that where deployers have reason to consider the system may present a risk within the meaning of Article 79(1), they shall without undue delay inform the relevant parties and shall suspend the use of that system. Having a defined route to stopping the system, and knowing who can authorise it, is worth establishing before you need it.

Article 26(3) makes clear these duties sit alongside other obligations under Union or national law and do not displace them, and that the deployer remains free to organise its own resources to implement the oversight the provider indicates.

Two sector carve-outs worth knowing

Financial institutions already subject to internal governance requirements under Union financial services law are treated as meeting the 26(5) monitoring duty by complying with those rules, and maintain the logs as part of that documentation. Separately, the monitoring obligation does not cover sensitive operational data of deployers that are law enforcement authorities.

How EmberHound fits

Every duty above attaches to a specific system. Meeting them starts with a record of which AI systems you deploy, what each is used for, who is assigned oversight, and where the instructions for use are kept.

The AI Act Workspace holds that record and flags systems that may require review. It supports the documentation; the judgements stay with you and your advisers. Early access.

This article is general information, not legal advice. It describes Article 26 as consolidated at 27 July 2026.

Article 26: what a deployer of a high-risk system has to do