“Keep a human in the loop” is the easy summary. Article 14 is far more specific: it spells out exactly what that human must be able to do, and designs the obligation into the system itself.
Article 14 applies to every high-risk system and is the human counterweight to automation. It is not satisfied by a person nominally “in charge” — it requires that the system be designed so a named person can genuinely understand, question, override and stop it.
Article 14 of Regulation (EU) 2024/1689 opens with the design obligation:
“High-risk AI systems shall be designed and developed in such a way … that they can be effectively overseen by natural persons during the period in which they are in use.”
Regulation (EU) 2024/1689, Article 14(1)The purpose (Article 14(2)) is to prevent or minimise risks to health, safety or fundamental rights that can arise when a high-risk system is used as intended or under reasonably foreseeable misuse — especially where those risks persist despite the other safeguards in the Act.
Oversight measures must be proportionate to the system’s risks, its level of autonomy and its context of use. Article 14(3) gives the provider two ways to deliver them:
This is why oversight shows up in the Article 13 instructions: the provider has to tell the deployer which oversight measures it is expected to operate.
Article 14(4) is the operational heart of the article. The system must enable the person assigned to oversight to:
| The overseer can… | Why it matters |
|---|---|
| Understand the system’s capacities and limitations and monitor its operation | You cannot supervise what you do not understand |
| Remain aware of automation bias | Guards against over-trusting the output, especially in repetitive use |
| Correctly interpret the output, using the tools provided | Output without interpretation is not oversight |
| Decide not to use the system, or to disregard, override or reverse its output | The human retains genuine authority over the decision |
| Intervene or interrupt the system via a stop button or similar | A safe-state exit must always exist |
Article 14(5) adds a heightened safeguard for the highest-stakes case — remote biometric identification systems under Annex III point 1(a):
“… no action or decision is taken by the deployer on the basis of the identification resulting from the system unless that identification has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority.”
Regulation (EU) 2024/1689, Article 14(5)Certain specified law enforcement, migration, border control and asylum uses may be exempted from the two-person requirement where it would be disproportionate under Union or national law.
Oversight is a role, not a checkbox. In practice Article 14 means naming who oversees each high-risk system, ensuring they have the competence and authority to override it, and recording that this oversight is actually exercised. Across a portfolio, that quickly becomes an accountability-mapping problem: which person owns oversight of which system?
Effective oversight has to be assigned and evidenced per system. For each high-risk system you need to know who the responsible overseer is, what oversight measures apply (built-in and deployer-side), and a record that reviews and interventions happen. That ownership and accountability layer belongs in the inventory, alongside the system’s classification and risk record.
In Model Inventory for Jira, each AI system is a Jira work item — so ownership, assignees and review work items attach directly to the system. Oversight responsibilities become assigned, trackable work with a Jira change history, rather than an undocumented assumption. The judgement that oversight is adequate remains yours; the inventory is where you record who owns it and that it happened.
See how it worksThis page is a practical explanation, not legal advice. Always confirm requirements against the official text of Regulation (EU) 2024/1689.