You are the deployer: Article 26 read as an engineering backlog

Which AI Act duties land on you if you deploy someone else's system?

Most AI Act material is written for providers — the party that builds a system and places it on the market. Most organisations are not that party. They buy a system, wire it into a process, and run it. The Act calls that a deployer, and it gives deployers their own, much shorter obligation set in Article 26.

Shorter is not lighter. Every one of those duties is operational rather than documentary: they are things your system has to do, in production, with evidence. And there are three specific ways a deployer stops being a deployer and inherits the provider's entire obligation set — usually through an engineering decision that nobody flagged as a regulatory one.

This is engineering and practitioner guidance on how teams meet these obligations, grounded in production delivery of retrieval and agent systems. It is not legal advice and it is not a compliance guarantee. Classification is fact-specific and it is the question everything else hangs on. Verify your own against the Official Journal text and your own counsel.

The dates, precisely

The Digital Omnibus on AI is Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force since 27 July 2026. For deployer duties attached to the high-risk regime it moved:

• Stand-alone Annex III high-risk — 2 August 2026 → 2 December 2027
• High-risk embedded in regulated products (Annex I) — 2 August 2027 → 2 August 2028
• The AI regulatory sandbox obligation — → 2 August 2027

One detail is worth knowing because it changes how much you can rely on the date. The Commission's original proposal used a conditional trigger: the deadline would move only once harmonised standards were actually available. The co-legislators rejected that and chose fixed calendar dates instead, for predictability. That cuts both ways. You get a date you can plan against — and you lose the argument that obligations cannot bite while standards are still missing. December 2027 is not contingent on anyone finishing anything.

What did not move, and is live now: the Article 5 prohibitions and the Article 4 AI-literacy duty (both since February 2025), and the Article 50 transparency obligations, which applied on 2 August 2026 exactly as originally scheduled — the subject of our post on the deadline that moved and the one that didn't. Prohibitions bind you whatever your role. You cannot deploy a banned system and point at the vendor.

Article 26, read as an engineering backlog

Here is the article as work items rather than as a legal summary.

Use it the way the instructions say (26(1)). Appropriate technical and organisational measures to use the system in accordance with its instructions for use. This looks like the throwaway paragraph and it is actually the hinge: it makes the provider's intended purpose the envelope you operate inside. Keep a written record of what the vendor said the system is for and what you actually use it for. When those two drift apart — and they drift through ordinary product work, not through negligence — you are heading toward Article 25 below.

Human oversight by named people who can actually act (26(2)–(3)). The text asks for natural persons with the necessary competence, training and authority, as well as the necessary support. Four separate words, and the failure mode is failing on the last two. Oversight assigned to whoever is on shift, with no mandate to override the system and no time budgeted to look, is oversight on the org chart only. The reviewable version is: a named role, a documented competence basis, an explicit authority to reject or escalate, and a workload that leaves room to use it. You get to organise this how you like — paragraph 3 says so — but you have to organise it.

Input data you control has to be relevant and sufficiently representative (26(4)). This one is consistently under-read by engineers, because it sounds like a provider's training-data problem. It is not. To the extent you control the input data, its representativeness is your duty. In a retrieval system that means the corpus, the chunking and filtering, the freshness policy, and anything that decides which documents can be retrieved for whom. A RAG index quietly missing a region, a language or a customer segment is an Article 26(4) problem with your name on it, not the model vendor's.

Monitor, and notify without undue delay (26(5)). Monitor operation against the instructions; where you identify a risk within the meaning of Article 79(1) or a serious incident, inform the provider — and the relevant authorities — without undue delay. Two things follow, and both are build items: you need a detection capability, because you cannot report what you never see, and you need a route — a named contact at the provider, a known authority, and a runbook someone has read. Working out who to call is not something to do during the incident.

Keep the logs, at least six months (26(6)). Deployers keep the logs the system automatically generates, to the extent they are under their control, for a period appropriate to the intended purpose and at least six months unless other law says otherwise. Read "at least six months" as a floor, not a target. The engineering content: log the inputs, the model and its version, the retrieval sources where there are any, the output, and the human-oversight events — who saw it, what they did. Then hold that against GDPR data minimisation and storage limitation, because those pull the other way and the tension is real. Decide the retention deliberately, write down the reasoning, and make the log immutable enough to be worth something as evidence. Retrofitting this is the single most common way a programme slips, because the evidence every later obligation is written from is evidence you had to be collecting all along.

Tell the workers before you switch it on (26(7)). Deployers who are employers and put a high-risk system into service at the workplace must inform worker representatives and the affected workers that they will be subject to it, before use. This is a sequencing duty. It cannot be satisfied retroactively, and national labour law may add to it.

Public authorities check the EU database first (26(8)). If you are a public authority or an EU institution, verify the system is registered in the EU database before putting it into use; if it is not, do not deploy and tell the provider.

Feed the DPIA (26(9)). Where a DPIA is required under GDPR, use the information the provider gave you under Article 13 to do it. The DPIA obligation remains GDPR's; this paragraph makes the provider's documentation an input to it rather than a separate exercise.

Tell the people subject to the decisions (26(11)), and be ready to explain (Article 86). Where a high-risk system is used to make or assist decisions about natural persons, inform them that they are subject to its use. Separately, Article 86 gives a person affected by a decision taken on the basis of an Annex III high-risk system — one producing legal effects or similarly significantly affecting them, adversely, in their health, safety or fundamental rights — the right to a clear and meaningful explanation of the role of the system in the decision procedure and the main elements of the decision. That is a product requirement. "The model scored it 0.34" is not an explanation, and it is not something you can generate afterwards from a system that did not record why.

Cooperate with the authorities (26(12)). Short paragraph, ordinary consequence: someone has to be able to produce the above on request, in a form a regulator can read.

Article 27, narrower than the template vendors imply

The fundamental rights impact assessment binds a specific set of deployers: public bodies and private entities providing public services, plus deployers of the Annex III systems used for creditworthiness assessment and for risk assessment and pricing in life and health insurance. A private company deploying some other Annex III system is not obliged to produce a FRIA.

It remains a reasonable governance exercise, and much of its content overlaps with what you need for Article 26 anyway. But check whether the obligation binds you before buying a FRIA template that is sold as though it binds everyone.

The three ways you stop being a deployer

This is the part with the sharpest edge, and it is Article 25. A deployer (or distributor, importer, or any third party) is considered a provider of a high-risk system, with all the Article 16 provider obligations that implies, in three cases:

1. You put your name or trademark on it. Branding a system already on the market makes you its provider — without prejudice to contractual arrangements providing otherwise, which is precisely why the contract matters. Every white-labelled assistant sitting behind a customer's own brand lives here.
2. You substantially modify it in a way that leaves it high-risk under Article 6.
3. You change its intended purpose so that a system that was not high-risk — including a general-purpose AI model — becomes high-risk.

When any of those applies, the original provider stops being the provider of that system and you inherit the set: risk management, technical documentation, conformity assessment, quality management, registration, post-market monitoring. The original provider has to cooperate closely and supply the information and reasonably expected technical access you need — unless they had explicitly stated the system is not to be changed into a high-risk one.

Read point 3 again, because it is the one that catches ordinary engineering. Wiring a general-purpose model into a CV-screening flow, a credit pre-check, or an access-to-services decision is a normal sprint ticket. It is also, potentially, the moment your organisation became the provider of a high-risk AI system. Nobody on the board that day is thinking about Article 16.

The practical defences are unglamorous: keep an intended-use register that is reviewed when the use changes rather than when the system changes; make "does this change the intended purpose?" a question in the design review for anything touching people's employment, credit, education, essential services or health; and get the branding question into the contract explicitly, in both directions, rather than leaving it to be argued later.

What to build with the time

If the December 2027 date has bought you sixteen months, the productive way to spend them is in this order, because each item is the input to the next:

1. Classify, and write down the reasoning. Deployer or provider, per system. Annex III, Annex I, or neither. The reasoning is the artefact — the verdict alone does not survive being challenged.
2. Instrument. The Article 26(6) log schema, built before it is needed, with retention decided against GDPR rather than in ignorance of it.
3. Design the oversight and staff it. Named people, stated authority, budgeted time. Record the oversight events in the same log.
4. Prove the input data. For anything you control: what is in the corpus, what is excluded, and the evidence that it is representative for the purpose.
5. Write the incident route. Provider contact, authority, thresholds, runbook. Test it once against a synthetic incident, the way you would test a restore.
6. Answer the explanation question at design time. If someone adversely affected asks how the decision was reached, what does the system have to have recorded for that answer to exist? Retrofitting explainability into a system that logged only its output is not possible.

Steps 2 through 6 are engineering work, not documentation work, and that is the point. Compliance programmes that begin with documents produce documents describing systems that do not behave that way.

Where we stand

We build the log-first version by default, because the same structured record that answers a regulator is the record that lets us debug a retrieval system at all — that is not a compliance feature we bolt on, it is how the systems are legible to us. Our security and compliance pages set out the rest, and the deployment side of the same question — where inference runs, and who reaches it — is in our posts on private LLM inference and on air-gapped deployments.

If you are working out whether you are a deployer or, without meaning to be, a provider, that is a short conversation to start.