# EU AI Act Article 14: Human Oversight for AI Agents

A practical guide to Article 14 human oversight for AI agents: scope, tool-call controls, reviewer decisions, stop procedures, and logging.

By Ece Kayan. Published 2026-11-09.

An agent rejects a job candidate, sends the rejection email, and updates the applicant's record. The hiring manager sees it a few minutes later.

That is not human oversight. It is a notification.

This distinction matters for [Article 14 of the EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng). The article says that high-risk AI systems must be designed so that people can oversee them while they are being used. It does not say that somebody has to approve every action.

Add a human approval layer for actions that could have serious consequences. If the agent can change a credit limit, reject an application, or send an email that cannot be undone, a person needs to review it before the tool runs.

## What is human oversight under the EU AI Act?

Human oversight under Article 14 means giving people a real way to understand, monitor, override, and stop a high-risk AI system while it is in use. It is a capability the system must support, not a requirement to send every action to a person.

For an agent, that usually means separating its low-risk work from the actions that can change a person's rights, money, access, or records.

## Does Article 14 apply to AI agents?

A coding agent that opens a pull request is different from an agent that ranks applicants for a job. A support agent that explains an invoice is different from one that changes a customer's credit limit.

The [AI Act's Annex III](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng) covers uses such as recruitment, education, access to essential services and benefits, law enforcement, migration, and the administration of justice. Annex I covers AI used as a safety component of certain regulated products.

An agent that drafts interview questions is not doing the same thing as one that ranks candidates or marks a candidate as rejected. You need to look at the system's intended purpose and the part its output plays in the decision, not just the model or framework underneath it.

### When does Article 14 apply to AI agents?

The [Digital Omnibus on AI](https://eur-lex.europa.eu/eli/reg/2026/1744/oj) moved the application dates for the high-risk requirements in Chapter III, including Article 14:

| High-risk system | Article 14 applies from |
| --- | --- |
| Annex III use cases, such as employment, credit, education, and essential services | 2 December 2027 |
| AI systems in products covered by Annex I | 2 August 2028 |

## What does Article 14 require for AI agents?

The people responsible for oversight need to understand the system's capabilities and limitations, notice when it behaves unexpectedly, and avoid relying on it just because it sounds confident. They also need to be able to interpret its output, override it, and stop the system when necessary.

[Article 26](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng) adds the organisational part. The deployer has to assign the work to people with the right competence, training, authority, and support. [Article 12](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng) requires automatic event logging, and Article 26 requires the deployer to keep the logs under its control for at least six months.

None of that tells you to build a tool-call gate. The Act does not use that phrase. But for an agent, the tool call is a useful place to apply the requirement because it is where a plan becomes an action in another system.

Before `update_candidate_status` runs, a reviewer can see that the agent wants to set the status to `rejected` and send an email. After it runs, a log can tell you what happened, but it cannot give the reviewer the decision back.

**TL;DR:**

- Keep low-risk work automatic.
- Refuse actions that are never acceptable.
- Hold consequential actions until the right person decides.
- Keep enough context for that person to understand the action.
- Make sure the agent cannot bypass the check with another credential or tool.

## Where should human oversight sit in an AI agent?

There are three common answers.

The first is the prompt. You tell the model to ask before it deletes anything or changes a record. This is useful as a reminder, but it is not an enforcement boundary. The model can miss the instruction, misunderstand the action, or be persuaded by text it has read.

The second is the agent framework. LangGraph's `interrupt()` and the OpenAI Agents SDK's `needsApproval` can pause a run before a tool executes. This works well when one team owns the application and is happy to build the review screen, paused-run state, rules, and logs next to the agent.

The third is outside the agent: a hook, middleware layer, or gateway holds the call and asks an approval service what to do. This makes sense when several agents should follow the same policy or when different teams need to review different actions. You write the policy once instead of copying it into every agent codebase.

There is no magic in the third option. An agent that can read the service credential can go around the gate and call the API directly. If the check is meant to enforce anything, keep the credential out of the agent too.

## Which AI agent actions need human review?

The fastest way to ruin human review is to send every tool call to a person. If a reviewer gets a request for every read, search, and draft, they will learn to click through the queue. We saw this with coding agents. Permission prompts appeared so often that developers turned them off.

The useful split is based on impact and reversibility. Reading a record or preparing a draft can usually happen automatically. Exporting an entire candidate database or deleting production data should usually be refused outright. The calls in between are the ones a person should see: rejecting a candidate, changing an entitlement, moving money, or making a change that is difficult to undo.

That split is not something you set once and forget. If approvals are taking two seconds and almost all of them are accepted, the queue is probably full of work that should not be there. Reduce the routine cases until the reviewer is making a real decision.

## What should reviewers see before approving an AI action?

Show the exact arguments of the tool call being held for approval. The agent's explanation can help, but it is still the agent's account of what it is doing. Keep it separate from the facts the reviewer is checking.

The reviewer also needs authority over the decision. A shared Slack channel where anybody can click Approve is not a useful control if nobody in the channel owns hiring, credit, or production changes. Route each kind of request to the team responsible for it, and name a backup for when the first person does not answer.

## What happens when an AI approval request times out?

Every approval flow eventually meets a timeout, an outage, or somebody who is on a flight. Decide what happens before that day arrives.

For a consequential call that you have chosen to hold, the safe default is that it does not run without a decision. If you choose to let it continue after a timeout, document why that is proportionate to the risk. Do not leave the answer hidden in a retry loop.

When a call is denied, return the reason to the agent. It can ask the user for clarification, choose a different path, or stop. It should not keep retrying until somebody approves it by accident.

Article 14(4)(e) also calls for a stop button or a similar procedure. In an agent system, test that at two levels: stopping one misbehaving instance and stopping every instance when the problem is a shared prompt, tool definition, or model update. The stop is only real if the agent cannot use a credential it already has to keep acting somewhere else.

## What should you log for Article 14 human oversight?

The Act requires logging, but it does not give you a schema for agent approvals. The useful test is whether you could explain a consequential decision six months later without guessing.

Keep the agent and instance that made the request, the tool and its arguments, the rule that selected the outcome, and the version of that rule. Keep the people who were asked, their decision, the timestamps, and the final result, including an expiry or a failed execution.

The version matters. If the hiring team changes a rule in March, a January decision needs to show the January rule. The current configuration is not evidence of what applied in the past.

## How withHuman implements human oversight for AI agents

withHuman is an approval layer for AI agents. An adapter or SDK holds the tool call, sends it through your rules, and returns an approval, denial, expiry, or cancellation before the call runs.

*Diagram: Your agent's tool call is intercepted by the AAP layer, which sends a request to withHuman. Approval pipelines decide automatically and escalation paths ask a human about the rest. withHuman sends the decision back, and the call reaches your MCP tools only if it was approved.*

An applicant-tracking agent could send this request through the [Agent Approval Protocol](/docs/reference/agent-approval-protocol):

```json
{
  "tool": "update_candidate_status",
  "server": "ats",
  "arguments": { "candidate_id": "c_8812", "status": "rejected", "send_email": true },
  "agent_reasoning": "Candidate does not meet the minimum experience requirement.",
  "timeout": "4h"
}
```

[Approval pipelines](/docs/concepts/approval-pipelines) allow routine calls, refuse forbidden ones, and send the rest to a person. [Escalation paths](/docs/concepts/escalation-paths) decide who is asked and who is contacted next. The [review queue](/docs/web-app/review-queue) shows the arguments that will run, with [tool presentations](/docs/web-app/tool-presentations) for readable context.

An [agent or agent instance](/docs/web-app/agents) can be disabled so later calls are refused. The [MCP Gateway](/docs/getting-started/set-up-mcp-gateway) keeps MCP credentials out of the agent's reach. The hosted [audit log](/docs/web-app/audit-log) records the request, routing, reviewers, and outcome, while [revisions](/docs/concepts/immutability) preserve the policy that applied at the time.

## FAQ

### Does the EU AI Act require a human to approve every AI agent action?

No. Article 14 requires effective human oversight for high-risk AI systems, proportionate to their risk, autonomy, and context of use. Reviewing consequential, hard-to-reverse calls is usually more useful than approving every read or draft.

### When does Article 14 apply?

For relevant Annex III systems, the high-risk requirements apply from 2 December 2027. For AI systems in products covered by Annex I, they apply from 2 August 2028. Whether the system is high risk depends on its intended use, not on whether it uses an agent or an LLM.

### Can an AI model approve another AI agent's actions?

It can sort routine calls from uncertain ones. It cannot replace the person responsible for oversight of a high-risk system. That person still needs to be able to understand, override, and stop the system when appropriate.

### How long must AI agent records be kept?

Deployers of high-risk systems must keep automatically generated logs under their control for at least six months, unless other applicable EU or national law says otherwise. Sector-specific rules may require longer retention.

The [Quickstart](/docs/getting-started/quickstart) connects a coding agent. [Connecting agents built in code](/docs/getting-started/connect-agents-built-in-code) covers LangGraph, Pydantic AI, Mastra, and other frameworks.