Most organisations don’t build high-risk AI — they buy it and use it. If that’s you, you are a deployer, and Article 26 is your article. Here is what you actually have to do, and the line you must not cross by accident.
The EU AI Act’s heaviest design duties — risk management, technical documentation, quality management — fall on the provider. But the Act does not let users off the hook. If you deploy a high-risk AI system in your business, Article 26 gives you a distinct, operational set of obligations.
The Act splits responsibility by role. A provider develops a system or places it on the market under its own name. A deployer is a natural or legal person using an AI system under its authority — except for purely personal, non-professional use. A bank running a vendor’s credit-scoring model, an HR team using a third-party CV-screening tool: both are deployers. The provider owns conformity; the deployer owns correct, accountable use.
Article 26 of Regulation (EU) 2024/1689 lists the operational obligations of a deployer of a high-risk AI system. The core of them:
| Art. | Duty | What it means in practice |
|---|---|---|
| 26(1) | Use per instructions | Take technical and organisational measures to use the system in accordance with its instructions for use |
| 26(2) | Assign human oversight | Give oversight to natural persons with the necessary competence, training, authority and support |
| 26(3) | Control input data | Where you control the input data, ensure it is relevant and sufficiently representative for the intended purpose |
| 26(5) | Monitor & report | Monitor operation per instructions; where use may present a risk, inform the provider and the market surveillance authority and suspend use |
| 26(6) | Keep logs ≥ 6 months | Retain the system’s automatically generated logs for at least six months, to the extent they are under your control (unless other law says otherwise) |
| 26(7) | Inform workers | Before using a high-risk system at work, inform workers’ representatives and affected workers |
| 26(11) | Inform affected people | Where the system makes or assists decisions about individuals, inform those persons they are subject to its use |
Two more attach in specific cases: 26(8) requires deployers that are public authorities to register their use in the EU database (Article 49), and 26(9) ties in to any data protection impact assessment you owe under GDPR Article 35.
The six-month log rule bites quietly. Article 26(6) means that for every high-risk system you deploy, someone has to know where its logs are kept, that retention meets the six-month floor, and that the clock is actually running. “The vendor probably keeps them” is not an answer a regulator accepts.
Here is the line that catches sophisticated teams. Under Article 25(1), a deployer (or distributor or other third party) is treated as a provider of a high-risk system — inheriting the full provider obligations — if it:
This is exactly what happens when a data-science team takes a vendor or open-source model and fine-tunes it, re-purposes it, or ships it under the company brand. The legal status can flip from “user” to “manufacturer” without anyone signing off on it — and with it come Articles 9, 11 and 17.
One duty does not wait for 2026. Article 4 requires providers and deployers to ensure a sufficient level of AI literacy among staff and others operating AI on their behalf — and it has applied since 2 February 2025.
A duty you can act on today. You cannot train the right people on AI literacy until you know which AI tools your teams actually use. Article 4 turns “build an AI inventory” from a 2026 project into a present obligation.
Some deployers carry an extra duty under Article 27: a Fundamental Rights Impact Assessment before deploying certain high-risk systems. It applies to deployers that are bodies governed by public law, private entities providing public services, and deployers of the Annex III systems used for creditworthiness / credit scoring and risk assessment and pricing in life and health insurance. (The EU-database registration of those private uses sits with the provider under Article 49, not the deployer — a distinction worth getting right.)
Every Article 26 duty attaches to a specific system: this model’s instructions, that model’s oversight owner, this system’s log-retention status, that deployment’s worker notice. None of it is manageable as a policy in the abstract — it has to be tracked per system, with an owner and a status. That is precisely what an inventory is for: the place where each high-risk system carries its deployer obligations and the evidence that they are being met.
Model Inventory for Jira makes each AI system a Jira work item, so you can assign the human-oversight owner, link its instructions for use, record where its logs are kept and that retention is on track, and raise governance work items for monitoring and worker/individual notices — each one attached to the system it belongs to, with an immutable change history. That same history is your early warning for the Article 25 line: when a model is modified, the record shows it. Model Inventory for Jira doesn’t store the AI system’s runtime logs or perform your assessments — it gives every deployer duty a named owner, a status and an audit trail in the Jira you already run.
See how it worksThis page is a practical explanation, not legal advice. Always confirm requirements against the official text of Regulation (EU) 2024/1689.