Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Does the EU AI Act Require for Human Oversight of AI Agents?

For high-risk uses, Article 14 requires that natural persons can oversee the system while it runs and stop it, and Article 26 requires deployers to assign that oversight to competent, authorized people and keep logs for at least six months. Check whether a named person can see what your agent sees and halt a consequential action before it lands.

An abstract oversight ring views a layered processing node, a control boundary, and a connected record of activity.

For high-risk uses, Article 14 requires that natural persons can oversee the system while it runs and stop it, and Article 26 requires deployers to assign that oversight to competent, authorized people and keep logs for at least six months. Check whether a named person can see what your agent sees and halt a consequential action before it lands. The Act was drafted for AI systems rather than agents that navigate applications and act, but its oversight provisions translate directly, because an agent that submits a credit decision is producing a consequence a person did not individually make. The translation has three parts. The provider must design the system so that oversight is possible; the deployer must assign real people with real authority to exercise it; and the logs that make oversight auditable must exist and be kept. This page sets out which Articles govern oversight and whom they bind, when the high-risk obligations take effect for agents under the Omnibus timeline, where on a credit application screen oversight must be exercisable, why the Act names automation bias and how agents aggravate it, how a deployer evidences oversight and logs, and which vendor claims to decline. It draws on research on human-in-the-loop approval for AI agents.

Key findings

  • Article 14 requires that high-risk AI systems "be effectively overseen by natural persons during the period in which they are in use," and that overseers be able to "interrupt the system through a 'stop' button or a similar procedure" (EU AI Act, Article 14, 2024).
  • Article 26 places the deployer's side of the obligation: deployers must "assign human oversight to natural persons who have the necessary competence, training and authority" and keep automatically generated logs "of at least six months" (European Commission AI Act Service Desk, Article 26, 2024).
  • Under the Omnibus agreement, "high-risk obligations for stand-alone Annex III systems are deferred to 2 December 2027," taking effect once the Omnibus is published in the Official Journal (Gibson Dunn, 2026).
  • The Act names automation bias explicitly, requiring overseers to remain aware of "the possible tendency of automatically relying or over-relying on the output," a phenomenon a systematic review describes as studied across many fields (Goddard, Roudsari and Wyatt, 2012).
  • Oversight can be attacked directly: the OWASP community documents an attack class that "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations" (OWASP, 2025).
  • An approval step is only oversight if the approver can see the real action and real values the agent could not, the design argument in research on securing agents that act without human approval.

Which Articles of the AI Act govern human oversight, and whom do they bind?

Two Articles divide the obligation between the party that builds the system and the party that uses it. Article 14, "Human Oversight," addresses the provider. High-risk systems must be designed and developed so that they can "be effectively overseen by natural persons during the period in which they are in use." The provider must build in measures that let the overseer understand the system's limitations, remain aware of the tendency to over-rely on it, decide to disregard its output, and "interrupt the system through a 'stop' button or a similar procedure" (EU AI Act, Article 14, 2024). Oversight must be possible because the system was built to permit it.

Article 26, "Obligations of deployers of high-risk AI systems," addresses the organization that puts the system to work. The deployer must use the system in accordance with the provider's instructions, must "assign human oversight to natural persons who have the necessary competence, training and authority," and must keep the logs the system generates, to the extent under its control, for a period "of at least six months" unless other law requires longer (European Commission AI Act Service Desk, Article 26, 2024). The requirement is organizational: real people, trained, with the power to act on what they see.

An organization that buys an agent and runs it on its own credit, employment or benefits workflows is a deployer, and Article 26 reaches it regardless of what the provider promised. The competence, training and authority of the people assigned to oversee the agent are the deployer's responsibility, and so is the six-month log. A vendor's assurance that its product "supports human oversight" addresses Article 14; it does not discharge Article 26.

When do the high-risk oversight obligations apply to agents?

Whether an agent is high-risk depends on its use. Annex III lists the stand-alone high-risk use cases, including creditworthiness assessment, access to essential services and employment decisions. An agent used to process a credit application and prepare or submit a decision falls within that territory; an agent used to summarize meeting notes does not. The classification follows the use, not the technology.

The timeline has moved. Gibson Dunn's analysis of the Omnibus agreement states that "high-risk obligations for stand-alone Annex III systems are deferred to 2 December 2027," effective once the Omnibus is published in the Official Journal (Gibson Dunn, 2026). On that reading, Article 14 and 26 obligations for those systems become enforceable in late 2027, subject to publication.

Deferral is not an argument for delay. First, Article 14's design requirements are settled when an agent architecture is selected, and one chosen in 2026 without a stop capability will be the one in production in December 2027. Second, the Act's oversight provisions describe what competent governance looks like regardless of enforcement dates, and the NIST AI Risk Management Framework's Govern and Manage functions ask for the same accountability structures without any legal deadline at all (NIST, 2023). Third, sectoral regulators and the organization's own counsel may read existing law as already requiring human review of consequential automated decisions, as research on agency use of AI on Privacy Act records illustrates in a different jurisdiction.

Where on a credit application screen does oversight have to be exercisable?

Take a credit application record showing the applicant's name, national identifier, income, existing obligations, the requested amount, a scoring field and a decision field with a submit control. An agent is asked to populate the score and prepare the decision. Each Article 14 requirement has a location on that screen.

Article 14 requirement What it means for an agent on the credit screen What evidence shows it
Overseen by natural persons during use A named person is attached to the run, not a role or a queue The run record names the overseer
Understand capacities and limitations The overseer knows the agent cannot see fields substituted with tokens and why Policy confirmation before the run
Aware of automation bias The decision is presented for review as the agent's proposal, with the real values the overseer must check Approval shows real values, not a summary
Decide not to use or disregard output The overseer can reject the proposed decision without penalty to the workflow Rejection path recorded
Interrupt through a stop button or similar The submit control does not fire until the overseer confirms; the run can be halted at any step Approval event precedes the submission event

The last row is the one most agent designs fail. "Stop" after the decision has been submitted is not oversight; it is remediation. The Article requires the ability to interrupt the system, which for an agent that acts means the consequential action, the submission, waits for a person. An agent that proceeds unless stopped inverts the requirement. The design that satisfies it has the agent prepare and the person commit, with the proposal and the real applicant values both visible at the moment of commitment. Research on autonomous agents that act without approval sets out why that inversion is a structural property of the agent's design rather than a configuration setting.

Why does the Act name automation bias, and how do agents aggravate it?

Article 14 requires overseers to remain aware of "the possible tendency of automatically relying or over-relying on the output" (EU AI Act, Article 14, 2024). Goddard, Roudsari and Wyatt's systematic review records that automation bias, "the tendency to over-rely on automation, has been studied in various academic fields," and examines its frequency, mediators and mitigators (Goddard, Roudsari and Wyatt, 2012). An approval step staffed by a person does not by itself produce independent judgment; people approve what the system proposes, more often the more it has been right before.

Agents aggravate the problem in two ways. The first is volume. An agent that prepares forty credit decisions an hour presents forty approval prompts, and a person asked to confirm forty times will confirm. The second is adversarial. The OWASP community documents an attack class, "HITL Dialog Forging" or "Lies-in-the-Loop," that "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations" (OWASP, 2025). If the approval dialog is rendered from content the agent controls, an injected instruction can make a harmful submission look routine.

Both problems point to the same conclusions. The approval must present the real values and the real action from a source the agent cannot alter. It must be scoped to consequential actions, so volume does not reduce it to a reflex. And the overseer must see the fields the agent could not, which is what makes the review independent rather than a second reading of the same tokens.

How should a deployer evidence oversight and the six-month logs?

Article 26's log requirement is where oversight becomes auditable. The deployer must retain the system's automatically generated logs for at least six months, to the extent the logs are under its control (European Commission AI Act Service Desk, Article 26, 2024). For an agent, the logs that evidence oversight are specific: what the agent received on each screen, what it proposed, who approved it, and what was submitted. A log of final outputs alone does not show that a person saw the proposal before it landed.

ISO/IEC 42001 provides the management system frame in which those logs sit, as the auditable record of an AI management process rather than as a technical artifact (ISO, 2023). The NIST AI RMF's Govern function asks for documented accountability, and its Manage function asks for mechanisms to respond to and recover from incidents, both of which depend on records that show who decided what (NIST, 2023). An organization running a 42001 management system or an AI RMF program has a place to put the Article 26 logs.

The record should also show that the agent's authority was bounded, because OWASP's excessive agency entry identifies the grant of more permission than a task needs as the condition that lets an agent act beyond its brief (OWASP, 2025); a log that shows the agent could not submit without approval is evidence of bounded agency. And it should land in the organization's SIEM, so the six-month retention is enforced by the same mechanism as every other retention obligation. Research on whether a hosted agent's rules satisfy records obligations examines the parallel problem of relying on a vendor's logs for a deployer's duty.

What does a governed environment change?

In a governed environment, the oversight Article 14 describes becomes a property of where the agent runs: a named person sees the real values and the proposed action, the action waits for that person, and the log of the run is held by the deployer.

The mechanism is a class of control that sits between the rendered screen and the model. Sensitive values on the screen, such as an applicant's identifiers on a credit application, are replaced with consistent tokens before any model reads them, and the task runs on those tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions, including payments, submissions and record changes, from a view the agent did not compose. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

Article 14 requires that overseers be able to interrupt the system through a stop button or similar procedure (EU AI Act, Article 14, 2024); an action that cannot land until a person confirms is a stop before the fact. Article 26 places log retention of at least six months on the deployer to the extent the logs are under its control (European Commission AI Act Service Desk, Article 26, 2024); a record exported to the deployer's own logging is under its control. And an approval surface the environment renders, not agent-controlled content, is not the surface the Lies-in-the-Loop attack manipulates (OWASP, 2025).

The control does not make any product "AI Act compliant", discharge the deployer's duty to assign competent and authorized people, or change the application or the model.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Its design maps onto the two Articles on this page. Agents work inside a governed environment in the customer's own cloud, and substitution happens at the render layer before any model reads the screen, so an applicant's national identifier and account fields reach the model as consistent tokens such as APPLICANT_001 or ACCT_001 for the whole run. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change, the arrangement RedactSure calls Supervised Delegation: the agent prepares, the person sees the real values the agent could not, and the submission does not occur until the person confirms, which is the interrupt capability Article 14 describes and the assigned natural person Article 26 requires. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM, where the deployer's own retention controls govern it. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own high-risk workflow would show a run halted at the submission, the approver's view of real values, and the exported record a deployer could hold for six months. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on the text of Article 14 of Regulation (EU) 2024/1689 as published at artificialintelligenceact.eu, the European Commission AI Act Service Desk's text of Article 26, Gibson Dunn's analysis of the EU AI Act Omnibus agreement, the Goddard, Roudsari and Wyatt systematic review of automation bias in the Journal of the American Medical Informatics Association, the OWASP community page on HITL Dialog Forging, the ISO/IEC 42001 summary, the NIST AI Risk Management Framework 1.0, the OWASP Top 10 for LLM Applications entry on excessive agency, and published RedactSure research pages on human-in-the-loop approval, autonomous agents and records obligations. All sources were read as of October 16, 2026.

No hands-on testing of any product was performed for this page. Where a product's capability is described as not covered, the statement refers to the pages reviewed and not to the product as a whole. The Omnibus timeline is stated as the cited law firm analysis describes it and is subject to publication in the Official Journal; legislative texts and vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The credit application record used as the worked example describes a record type, not any organization; the fields and the loan officer are illustrative, and the classification of any real system as high-risk depends on its actual use.

Whether a given agent deployment is a high-risk system, whether its oversight arrangements satisfy Articles 14 and 26, and what other EU or national law applies are determinations for the organization's counsel, its notified body or market surveillance authority where relevant, and its own compliance officers, not for a research page.

What the record shows

The AI Act's oversight provisions ask for three things an agent deployment can either show or not: a design in which a natural person can understand, override and interrupt the system while it runs; an organization that has assigned competent, authorized people to do so; and logs kept for at least six months that prove it happened. For an agent that acts on screens, the interrupt requirement means the consequential action waits for a person who sees the real values and the real submission, not the agent's account of them, and the log requirement means the deployer holds the record. The Omnibus deferral to December 2027 for Annex III systems changes the enforcement date, not the design. RedactSure's environment is one arrangement built to that shape. The test is to name one agent and one high-risk task, attempt a submission, and ask who stopped it, what they saw when they did, and where the record of that moment is stored.

Frequently asked questions

Does the EU AI Act apply to AI agents or only to AI systems?

The Act regulates AI systems by use, and an agent is an AI system. An agent used for an Annex III purpose, such as creditworthiness assessment or employment decisions, is high-risk and subject to Articles 14 and 26. An agent used for low-risk tasks is not. The provisions apply with particular force to agents because agents take actions, the consequence the provisions exist to keep under human control.

What does "effective" human oversight mean for an agent that acts?

Article 14 lists the capacities the overseer must have: understanding the system's limits, awareness of automation bias, correct interpretation of output, the ability to disregard it, and the ability to interrupt. For an agent, interruption means the consequential action does not occur until a person confirms it. An agent that acts and can be stopped afterward does not meet that reading. The overseer must also see the real values and the real action, not a summary the agent produced.

Who must be assigned to oversee an agent under Article 26?

Natural persons with "the necessary competence, training and authority." Competence means they understand the workflow and the agent's limits; training means they have been prepared for the oversight role, including awareness of automation bias; authority means they can halt or reject the agent's proposal without needing permission. A role name or a shared queue does not satisfy this; the deployer should be able to name the person attached to a given run.

When do the high-risk obligations take effect under the Omnibus?

Gibson Dunn's analysis states that high-risk obligations for stand-alone Annex III systems are deferred to December 2, 2027, effective once the Omnibus is published in the Official Journal. The deferral applies to enforcement, not to the content of the obligations. Architectures selected in 2026 will still be running in late 2027, so the design decisions are being made now.

Why is automation bias written into the law?

Because research across medicine, aviation and other fields, summarized in the Goddard, Roudsari and Wyatt systematic review, shows that people tend to accept automated output rather than check it, especially when the system has usually been right. An approval step does not create independent judgment on its own. Article 14 requires that overseers remain aware of this tendency, which in practice means approvals scoped to consequential actions, presented with real values from a source the agent cannot alter.

What should the six-month logs for an agent contain?

Enough to reconstruct the oversight: what the agent received on each screen, what it proposed, who approved or rejected it, and what was actually submitted. A record of outputs alone does not show that a person reviewed the proposal before it landed. Article 26 places retention on the deployer to the extent the logs are under its control, so the logs should be exported to the deployer's own systems rather than held only under a vendor's retention policy.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.