Agentic AI
Human oversight under the EU AI Act: what the provider builds and what the deployer keeps
Article 14 says how a high-risk AI system must be built so people can oversee it. Article 26 says what the deployer must do with it. Here is what each side keeps as evidence, and from when.
A bank that buys a high-risk AI system may be tempted to ask the vendor for "Article 14 compliance" and treat oversight as settled. The vendor can answer for how the system is built. It cannot answer for how the bank uses it. The EU AI Act splits human oversight between the two: the provider builds a high-risk system that people can oversee, and the deployer puts people in charge and uses the system as the provider instructs.
The split matters for evidence. Each side needs its own record, and neither record covers the other. For the high-risk uses listed in Annex III, such as evaluating the creditworthiness of natural persons, both sets of duties apply from 2 December 2027. That date comes from the Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026. It amended neither Article 14 nor Article 26.
Article 14 is a design requirement
Article 14 of the AI Act requires high-risk systems to be designed and developed, including with appropriate human-machine interface tools, so that natural persons can oversee them effectively while they are in use.
The oversight measures must be proportionate to the risks, the level of autonomy and the context of use. They take one or both of two forms (Article 14(3)):
- measures the provider identifies and builds into the system before it is placed on the market or put into service, where technically feasible;
- measures the provider identifies before that point as appropriate for the deployer to implement.
The system must reach the deployer in a form that enables the people assigned to oversight, as appropriate and proportionate, to (Article 14(4)):
- understand its capacities and limitations and monitor its operation, including to detect anomalies, dysfunctions and unexpected performance;
- remain aware of the tendency to rely too much on its output, called automation bias, especially when it recommends decisions that people take;
- interpret its output correctly;
- decide not to use it, or disregard, override or reverse its output;
- intervene in its operation or stop it safely.
For remote biometric identification, Article 14(5) adds that no action or decision follows an identification unless at least two people with the necessary competence, training and authority have separately verified and confirmed it. The two-person check does not apply to law enforcement, migration, border control or asylum where Union or national law considers it disproportionate.
The provider records its assessment of the oversight measures in the technical documentation (Annex IV, point 2(e), and point 3). It tells the deployer what those measures are in the instructions for use (Article 13(3)(d)).
Article 26 is what the deployer does
Article 26 sets the deployer's duties for a high-risk system:
- Use as instructed (26(1)): take appropriate technical and organisational measures to use the system in accordance with its instructions for use.
- Assign oversight (26(2)): give human oversight to natural persons with the necessary competence, training and authority, and the necessary support. The deployer remains free to organise its own resources to implement the oversight measures the provider indicates (26(3)).
- Input data (26(4)): where the deployer controls the input data, ensure it is relevant and sufficiently representative for the intended purpose.
- Monitor (26(5)): monitor the system on the basis of the instructions for use, inform the provider where relevant, and suspend use and inform the provider or distributor and the market surveillance authority where the system may present a risk. Serious incidents are reported to the provider first.
- Keep logs (26(6)): keep the logs the system generates, to the extent they are under the deployer's control, for a period appropriate to the intended purpose and of at least six months, unless other Union or national law provides otherwise.
- Inform workers (26(7)): before using a high-risk system at the workplace, inform workers' representatives and the affected workers.
- Data protection (26(9)): use the information from the instructions for use to carry out a data protection impact assessment where one is required.
- Inform the people affected (26(11)): deployers of Annex III systems that make or assist decisions about natural persons inform them that they are subject to the system.
Financial institutions subject to Union rules on internal governance meet the monitoring duty by complying with those rules, and keep the logs as part of the documentation they already keep under financial services law.
The fundamental rights impact assessment
Before first use, Article 27 requires a fundamental rights impact assessment from deployers that are public bodies or private entities providing public services, and from deployers of systems that evaluate creditworthiness of natural persons or price life and health insurance (Annex III points 5(b) and 5(c)). Among other things, it describes the deployer's processes, the people likely to be affected, the specific risks of harm and the implementation of human oversight measures according to the instructions for use.
Since the July 2026 amendment, where a data protection impact assessment already covers part of it, the deployer may cross-refer to that assessment or include the relevant parts.
The evidence each side keeps
The Regulation sets the duties; it does not prescribe the form of the deployer's records. The right-hand column below is our suggestion for records that let another officer reconstruct how oversight worked.
| Duty | Provider's record | Deployer's record |
|---|---|---|
| Oversight by design (14) | Annex IV point 2(e) and point 3; instructions for use, Article 13(3)(d) | The version of the instructions for use in force when the system was used |
| Who oversees (26(2)) | Not applicable | Named roles, the competence and training behind them, the authority to override, the date of assignment |
| Use as instructed (26(1)) | Instructions for use | The procedures and settings mapped to those instructions |
| Override and stop (14(4)) | Interface and controls described in Annex IV | Each override or stop, with the person, the time and the reason |
| Monitoring (26(5)) | Post-market monitoring plan, Annex IV point 9 | Monitoring results, notices to the provider, any suspension |
| Logs (12 and 26(6)) | Logging capability; how deployers collect and read logs, Article 13(3)(f) | The logs under the deployer's control, kept at least six months |
| Notices (26(7) and 26(11)) | Not applicable | What was said to workers and to affected people, and when |
| Impact assessment (27) | Information under Article 13 | The assessment, where Article 27 applies |
Article 14(4) requires that the people overseeing the system be able to override it, as appropriate and proportionate. Whether they do, and why, is the evidence that oversight took place. A record of overrides with the reason is the clearest way to show that someone actually exercised it. This is the same test our four-eyes review walkthrough applies to a human checker.
Questions to put to a provider before 2 December 2027
- Which Annex III point covers the system's intended purpose, if any? If you consider it not high-risk under Article 6(3), where is the documented assessment?
- Which oversight measures are built into the system, and which do you expect us to implement (Article 14(3))?
- How does the interface let our staff interpret the output, override it and stop the system (Article 14(4))?
- What does the system log, and how do we collect, store and read those logs (Articles 12 and 13(3)(f))?
- Which version of the instructions for use applies, and how will we learn of changes?
A deployer that puts its own name on a high-risk system, modifies it substantially or changes its intended purpose so that it becomes high-risk is treated as its provider (Article 25(1)). Check that before adapting a purchased system.
How cmpliance approaches this
Our initial scope is KYC/AML onboarding and EU AI Act risk assessment. For EU AI Act documentation, agents classify your AI system's risk level, prepare the Annex IV points they can, list what is missing, and assemble an evidence pack with regulatory references for reviewer approval. A workflow or evidence pack does not by itself establish compliance with a regulation.
For the dates, roles and classification questions in one place, see EU AI Act documentation. For the provider's side, see Annex IV technical documentation, point by point.
Agents do the work. Humans make the call.
Article 14 is a design requirement for the high-risk system, so the provider meets it. The deployer's duties sit in Article 26: use as instructed, competent overseers, monitoring, logs and notices.
For the high-risk uses listed in Annex III, both apply from 2 December 2027, the date set by the July 2026 amendment.
Each side needs its own record. The provider documents the oversight measures; the deployer shows who oversaw the system, how and with what authority.
→Does Article 14 apply to deployers?
Article 14 is one of the requirements a high-risk system must meet, so it is addressed to how the system is designed and developed. It does describe what the people overseeing the system must be enabled to do. The deployer's own duties are in Article 26, including using the system as instructed and assigning oversight to people with the necessary competence, training, authority and support.
→Who keeps the logs of a high-risk AI system?
The system must be able to record events automatically (Article 12), and the instructions for use describe how the deployer can collect and read those logs. The deployer keeps the logs under its control for a period appropriate to the intended purpose, of at least six months unless other law provides otherwise (Article 26(6)).
→Do banks and other financial institutions have different rules?
Partly. A financial institution subject to Union rules on internal governance meets the monitoring duty in Article 26(5) by complying with those rules, and keeps the logs as part of the documentation it already keeps under financial services law (Article 26(6)). The other deployer duties apply as for any deployer.
