EU AI Act
Article 26 is the deployer’s article. It requires use in accordance with the instructions, competent assigned oversight, control of input data, monitoring, log retention and — the duty most often overlooked — suspension of the system where use may present a risk. It is one of the few provisions Article 99 fines directly.
§ 1 — Who it binds
Any deployer of a high-risk system, under either Article 6 gateway — with four paragraphs narrower than the rest: 26(7) reaches employers deploying at the workplace, 26(8) public authorities and Union bodies, 26(10) post-remote biometric identification in law enforcement, and 26(11) Annex III systems that make or assist decisions about people. A third-country deployer is caught where the output is used in the Union.
§ 2 — In practice
Most of the high-risk regime binds providers. Article 26 is where an organisation that merely *uses* a system acquires duties of its own, and it is drafted as a working list rather than a principle: use per the instructions, assign oversight to people with competence, training and authority, keep input data relevant where you control it, monitor, retain logs, and tell affected people. A deployer that reads only Article 9 and concludes the vendor carries the compliance load has read the wrong article.
The paragraph with teeth is 26(5), and it is routinely mis-implemented as a notification duty. Where a deployer has reason to consider that using the system in accordance with its instructions may result in the system presenting a risk, it must inform the provider and the market surveillance authority and suspend the use of that system. There is no proportionality qualifier and no discretion. The threshold is lower than it looks, too: "risk" here carries the market-surveillance meaning — risk to health, safety or fundamental rights — not a model-performance threshold and not a materialised harm.
Two deeming provisions matter commercially and are missed in both directions. A deployer that is a financial institution subject to internal-governance requirements under Union financial services law is deemed to satisfy the monitoring limb of 26(5) by complying with those rules, and may keep logs as part of its financial-services documentation under 26(6). The limits are precise: the deeming covers monitoring only — not the duty to inform, and not the duty to suspend — and it reaches a defined population, not "regulated firms" generally.
The log-retention duty in 26(6) is qualified "to the extent such logs are under their control", which turns a compliance question into a procurement one. A deployer of a hosted system may hold no logs, be in literal compliance, and still be unable to evidence anything under 26(1), 26(4) or 26(5) — or to answer an authority. The duty that actually bites is the contractual right of access, negotiated before signature. Our note on what AI assurance actually means makes the same point about evidence you cannot reach.
§ 3 — What a weak answer looks like
An escalation path that ends in a ticket. Almost every deployer can produce a monitoring dashboard, an owner and a route to the vendor; far fewer can produce the point at which that route obliges them to stop. Article 26(5) is the only place in the deployer’s obligations where the required action is to cease using the system, and a runbook whose most severe step is "raise a P1 with the supplier" has quietly written the statutory step out.
§ 4 — What discharges it
The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.
01
Article 26(2) asks for competence, training and authority, and the necessary support. A rota naming who is on duty is not the artefact; the artefact is what qualifies them to override the system and what authority they hold to do it without escalating.
02
The clearest evidence that 26(5) is operating is an occasion when it fired. Where it never has, the record should show the threshold being applied and a reasoned conclusion that it was not crossed — which is the only version of this an assessor can test.
03
Because 26(6) is qualified by control, the deployer’s real exposure sits in the vendor agreement. The evidence is the clause, and a retrieval that was actually performed against it rather than assumed to be available.
04
Article 26(4) attaches only to the extent the deployer exercises control. The artefact is the boundary: which fields the deployer supplies, what checks run on them, and where responsibility passes back to the provider.
05
Under 26(11) a deployer of an Annex III system that makes or assists decisions about people must tell them so. Where the deployer is an employer, 26(7) separately requires workers and their representatives to be informed before the system is put into service.
§ 5 — Worked example
An insurer deploys a vendor model that prices life cover. Nine months in, an actuary notices that decline rates for applicants in two postcodes have drifted well above the book average. Nothing has breached a performance threshold, the model is operating within its documented parameters, and the vendor’s monthly report shows no anomaly. The team raises an internal ticket with the vendor and continues writing business.
Has the insurer met Article 26(5)?
No, and the gap is not the ticket — it is what did not happen alongside it. The trigger in 26(5) is having reason to consider that use in accordance with the instructions may result in the system presenting a risk to fundamental rights, which a postcode-correlated decline pattern in life pricing plainly supplies. Once that threshold is crossed the deployer owes three things at once: inform the provider, inform the market surveillance authority, and suspend use. The insurer did the first and neither of the others. Note what does not rescue it: the model operating within its documented parameters goes to whether the *provider* breached anything, not to whether the deployer has reason to consider a risk. And the financial-services deeming in 26(5) would not help either — it covers the monitoring limb, which the actuary discharged, and not the informing or the suspension.
§ 6 — Elsewhere
Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.
ISO/IEC 42001
Clause A.9 of ISO/IEC 42001 is the deployer-facing part of the standard — processes for responsible use, objectives for that use, and intended use of the system. It addresses the same territory as Article 26 from the management-system side.
GDPR and data-protection law
Article 26(9) directs the deployer to use the information supplied under Article 13 when carrying out a data protection impact assessment. The AI Act supplies inputs to that assessment; it does not replace it.
A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.
§ 7 — When it applies
2 December 2027
Annex III standalone high-risk systems. Moved from 2 August 2026 by the Digital Omnibus — a sixteen-month extension driven by undesignated national authorities and the absence of harmonised standards, not by any relaxation of the Section 2 requirements themselves.
2 August 2028
Annex I embedded high-risk systems — medical devices, machinery, vehicles — where AI Act requirements fold into the existing sectoral conformity assessment. Moved from 2 August 2027.
§ 8 — Exposure
€15 million or 3% of worldwide annual turnover, whichever is higher
Article 99(4)(e), which names deployer obligations pursuant to Article 26 directly — no chain through Article 16 is needed, unlike most of the high-risk requirements. Under Article 99(6) an SME pays the lower of the two figures, and Article 99(6a), inserted by the Digital Omnibus, extends the same treatment to small mid-cap companies. Where the deployer is a public authority, Article 99(8) leaves the extent of any fine to national law.
§ 9 — Where this is assessed
Examined in 3 credentials, in the domains named on each card.
Roles and duties · 20% of the paper
The EU AI Act as enacted: the risk-tier structure, the roles the Act defines, the obligations attaching to each, and the timeline on which they apply.
Governance and accountability · 20% of the paper
Employment-AI law and bias-audit fundamentals: automated employment decision tools under NYC Local Law 144, adverse impact and the four-fifths rule, and the EU AI Act’s high-risk employment scope.
Public-sector AI use and accountability · 25% of the paper
AI governance in government: public-sector AI use, algorithmic accountability and transparency obligations, and AI in public procurement.
§ 10 — provenance
This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.
§ 11 — Also read