Article 26 deployer obligations, operationally

Deployers of high-risk AI systems carry their own obligations under the AI Act — independent of anything the vendor did. Here is each Article 26 duty translated into who does what, and what evidence shows it is actually running.

Updated July 16, 2026 · Informational guidance, not legal advice

Why deployer obligations are underestimated

Most AI Act attention goes to providers — the risk management systems, technical documentation, and conformity assessments of Articles 9–15 and 43. That framing leads many organizations to conclude that buying from a compliant vendor settles the question. It does not. Article 26 attaches duties to the deployer: the organization using a high-risk AI system under its own authority. These apply from August 2, 2026, and a market surveillance authority can address them to you directly.

The obligations, one by one

Use within intended purpose (26(1)): operate the system according to the provider's instructions for use. Evidence: the instructions on file, and a documented statement of your use case against the system's intended purpose. Using a system outside its intended purpose can also shift you into the provider role under Article 25.
Human oversight (26(2)): assign oversight to named natural persons with the competence, training, authority, and support to intervene. Evidence: an oversight assignment per system naming a person — not a team alias — plus the training or briefing record behind them.
Input data care (26(4)): to the extent you control input data, ensure it is relevant and sufficiently representative for the intended purpose. Evidence: a described input-data check for the systems where you control inputs.
Monitoring and escalation (26(5)): monitor operation per the instructions for use; if you have reason to consider the system presents a risk under Article 79(1), inform the provider and market surveillance authority without undue delay and suspend use. Serious incidents trigger Article 73 reporting with severity-based deadlines. Evidence: a monitoring cadence, plus a written escalation path with owners.
Log retention (26(6)): keep the logs the system automatically generates, to the extent they are under your control, for at least six months (longer where other law requires it). Evidence: where logs live, retention configuration, and who verified it.
Worker notification (26(7)): before putting a high-risk system into service in the workplace, inform affected workers and their representatives. Evidence: the notice and the date it went out.
Informing affected persons (26(11)): where the deployer makes or supports decisions about natural persons, tell those persons that a high-risk AI system is being used on them.
Cooperation (26(12)): cooperate with competent authorities on any action they take regarding the system.

Public-sector and public-service deployers

Deployers that are public bodies — and private entities providing public services — carry two extras: registration of use in the EU database (Article 49(3)) and a fundamental rights impact assessment before first use (Article 27). Article 27 also captures deployers of creditworthiness and life/health insurance pricing systems.

What proof looks like when someone asks

Every duty above shares a shape: a decision, an owner, and a dated artifact. That is what an authority, an enterprise customer's procurement team, or your own counsel will ask to see. "We take oversight seriously" is not an answer; an oversight assignment with a name, a date, and a review trail is.

A register entry per system with role and risk classification — Article 26 only attaches once you know a system is high-risk and you are its deployer.
An obligation map from each system to the specific 26(x) duties that apply, with owners.
Evidence items with review dates, flagged when they go stale — an oversight procedure written once in 2026 and never touched is a liability by 2027.
An audit trail showing the record was operated over time, not assembled the week someone asked.

Common failure modes

Relying on the vendor: the provider's conformity assessment does not discharge a single deployer duty.
Oversight assigned to a role, not a person — 26(2) requires natural persons with competence and authority.
Logs assumed but never located: if the vendor holds the logs, establish contractually that they are retained and retrievable; if you hold them, six months is the floor.
Worker notification skipped because the tool was 'just piloted' — putting into service in the workplace is the trigger, not full rollout.
Modifying or re-purposing a vendor system without checking Article 25 — substantial modification or rebranding can silently make you the provider, with the full Articles 9–15 load.

Turn Article 26 into an operating record

Attevera maps each of your systems to its Article 26 duties, assigns owners, flags stale evidence, and produces the packet a customer or authority can review.

See how the register works

Frequently asked questions

Do Article 26 obligations apply to AI systems that are not high-risk?

No — Article 26 attaches to deployers of high-risk systems as classified under Article 6 and Annex III. But limited-risk systems can still carry Article 50 transparency duties, and every organization carries the Article 4 AI literacy duty. Classification comes first.

Our vendor says their tool is 'AI Act compliant.' Does that cover us?

No. Provider and deployer obligations are separate. A vendor's claims can support your record — instructions for use, log access, technical documentation — but oversight, monitoring, retention, and notification duties are yours.

How long do we keep the logs?

At least six months for logs automatically generated by the high-risk system, to the extent they are under your control — longer where union or national law (for example financial-services record-keeping) requires it.

Who in the org should own Article 26?

In practice: one accountable owner for the register and rhythm (often product ops, risk, or compliance), with per-system oversight assigned to the people who actually operate each system. What matters is that each duty resolves to a named person with a dated artifact behind them.