EU AI Act Article 14 on AWS: Human Oversight That Works, Not a Checkbox

Article 14 requires high-risk AI systems to be designed so people can understand, override and stop them. What that means for Bedrock agents and AI pipelines on AWS, and the patterns we use.

Article 14 of the EU AI Act is the requirement most teams think they have already met. There is a human in the loop somewhere, a reviewer clicks approve, so oversight is covered. Then someone reads the article closely and finds it asks for much more: people who understand the system's limits, who are protected against automation bias, who can override or reverse its output, and who can stop it. Bolted on at the end, none of that works. Designed in, most of it is ordinary engineering on AWS. This post covers what Article 14 asks for and the patterns we use to build it.

When it applies

Article 14 is one of the requirements for high-risk AI systems in Chapter III of the Act. Following the Digital Omnibus on AI (Regulation (EU) 2026/1744), those requirements apply from 2 December 2027 for stand-alone high-risk systems listed in Annex III, and from 2 August 2028 for AI embedded in products covered by Annex I. If you are not sure whether your system is high-risk, start with our plain-English guide to Annex III.

The obligation is shared. Providers must design the system so it can be effectively overseen (Article 14). Deployers must assign oversight to people with the necessary competence, training and authority, and give them the support they need (Article 26). If you build and run the system yourself, you hold both.

What Article 14 actually asks for

Reduced to engineering requirements, the people overseeing the system must be able to:

1. Understand its capacities and limitations and monitor its operation, including spotting anomalies and unexpected behaviour.
2. Stay aware of automation bias, the tendency to over-rely on the system's output.
3. Correctly interpret its output, using the tools and information available.
4. Decide not to use it, or to disregard, override or reverse its output in any particular situation.
5. Intervene or interrupt it through a stop button or a similar procedure that brings it to a halt in a safe state.

For remote biometric identification systems, Article 14(5) adds that no action or decision may be taken on the basis of an identification unless it has been separately verified by at least two people with the necessary competence, training and authority.

The oversight measures must be proportionate to the risks, the level of autonomy and the context of use. A system that drafts suggestions for an expert needs less than an agent that executes decisions on its own.

Pattern 1: approval gates on consequential actions

For agentic systems, the most important design decision is which actions the system may take on its own and which require a person. Classify every tool or action by consequence: reading data, drafting, and recommending are usually autonomous; changing records, sending communications, moving money, or making decisions about people usually need approval.

On AWS, two mechanisms cover most cases:

• Bedrock Agents user confirmation and return of control. Action group functions can be configured to require user confirmation before the agent invokes them, or to return control to your application with the intended action and parameters instead of executing it. Your application shows the proposed action to the responsible person, and only executes it on approval.
• Step Functions callback tasks. For pipelines and back-office workflows, a state with .waitForTaskToken pauses the workflow and hands a token to a review application. The workflow resumes only when a reviewer approves or rejects, and the decision is part of the execution history.

"AwaitHumanApproval": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken",
  "Parameters": {
    "FunctionName": "notify-reviewer",
    "Payload": {
      "taskToken.quot;: "$.Task.Token",
      "proposedAction.quot;: "$.proposedAction",
      "modelRationale.quot;: "$.rationale"
    }
  },
  "TimeoutSeconds": 86400,
  "Next": "ExecuteApprovedAction"
}

For structured review queues of model output (document extraction, classification), Amazon Augmented AI (A2I) provides human review workflows with conditions for when a prediction goes to a person, for example below a confidence threshold.

Pattern 2: least privilege as the outer boundary

Approval gates live in application logic, which can have bugs. The outer boundary should not. Give the agent's execution role and each action group's Lambda only the permissions for the actions they are allowed to take, so an action that requires approval is executed by a different role that only the approval path can use. Then even a prompt injection that convinces the model to skip the gate cannot carry out the action. This is also the strongest evidence you can show an assessor that the oversight design is enforced, not just intended.

Pattern 3: a stop button that actually stops

"Intervene or interrupt through a stop button" needs a mechanism that works under pressure, without a deployment, and is tested. Options, from softest to hardest:

• A feature flag (for example in AWS AppConfig) that the application checks before each model call or action, switching the system to a safe fallback: manual processing, a static response, or queueing requests for later.
• Disabling the entry point, such as setting a Lambda function's reserved concurrency to zero or detaching an API stage, which stops new requests immediately.
• An IAM deny attached to the agent's execution role, which stops all actions regardless of what the application does.

Define what "safe state" means for your system in advance: in-flight transactions completed or rolled back, users told the service is in manual mode, queued work preserved. Write a runbook, name who may press the button, and rehearse it. An untested stop button is not evidence of anything.

Pattern 4: design the review screen against automation bias

The most common oversight failure is not a missing approval step. It is a reviewer approving everything because the system is usually right and the screen makes approval the easy path. Article 14 specifically names automation bias, so the review interface is part of compliance:

• Show why, not just what. The sources retrieved, the key inputs, and the model's stated rationale alongside the proposed output.
• Show uncertainty. Confidence scores, or flags when the input is unlike the system's usual inputs.
• Make disagreement as easy as agreement. Edit, reject and escalate as prominent as approve.
• Require a reason for high-impact approvals, not just a click.
• Sample and measure. Track override rates per reviewer and per decision type. A reviewer who has never overridden anything in six months is a signal, and so is an override rate near zero across the team.

Pattern 5: log every oversight decision

Each approval, rejection, override, escalation and stop is evidence for Article 14, and for the record-keeping in Article 12 and the deployer's monitoring duties in Article 26. Record who acted, when, on which output, what they decided and why, linked to the model invocation that produced the output. We cover the logging architecture in detail in Article 12 traceability on AWS; oversight events belong in the same pipeline, written to immutable storage with the same retention.

Competence is part of the design

Article 26 requires deployers to assign oversight to people with the competence, training and authority to do it. That is an organisational duty, but it has system implications: role-based access so only trained, authorised people can approve, training records you can produce on request, and documentation of the system's limits written for the reviewers rather than for engineers. Article 13's instructions for use are where providers give deployers that information.

Where it fits with the rest of the Act

Human oversight does not stand alone. Your Article 9 risk management system identifies which risks oversight is meant to control; Article 12 logging records that it happened; and Article 15 accuracy and robustness work, including guardrails, reduces how often reviewers need to intervene. Designing them together is far cheaper than retrofitting each one.

What this looks like at ccX

Human oversight design is a standard part of our EU AI Act readiness audit for AWS-hosted systems. We map each action your system can take to its consequence, design the approval gates, IAM boundaries and stop mechanism, review the reviewer interface for automation bias, and connect oversight events to your logging and risk management evidence. The output is a remediation plan your team can build, mapped to Articles 9, 12, 14 and 26.

If your system has a human in the loop but you are not sure it would satisfy an assessor, book a 30-minute scoping call.

Where to go from here

• Annex III in plain English - is your system high-risk?
• Article 9 Bedrock reference architecture
• EU AI Act AWS checklist
• EU AI Act readiness

This post is engineering guidance, not legal advice. Article references reflect the AI Act as amended by Regulation (EU) 2026/1744; confirm how they apply to your system with your legal team.

Sitemap

• Read this post on the web
• All blog posts
• Full site map
• Home
• Services
• EU AI Act Compliance
• AWS GenAI Production Readiness
• Glossary
• Contact