EU AI Act Article 14: what human oversight actually requires
Article 14 of the EU AI Act requires that high-risk AI systems be designed so a human can effectively oversee them — understand the output, override it, and stop the system. The requirement is about demonstrable capability, not intention: you must be able to show that a specific person could intervene, and did, at a specific moment. In practice that means a reviewable record of what the system proposed, who reviewed it, what they decided, and why.
What the article actually says
Article 14 requires that high-risk AI systems be designed and developed so they "can be effectively overseen by natural persons" for the period they are in use. The oversight measures must be built into the system by the provider, or identified by the provider and implemented by the deployer.
The word doing the work is "effectively". A person nominally holding responsibility is not oversight. The article specifies that the human must be able to understand the system's capacity and limits, remain aware of automation bias, correctly interpret the output, decide not to use it, and intervene or halt it.
Where most implementations fall short
The common failure is treating oversight as a policy document rather than a runtime property. An organisation writes that a human reviews high-risk decisions, assigns the duty to a team, and considers the requirement met. When an auditor asks which human reviewed a particular decision on a particular date, there is nothing to show.
The second failure is the rubber stamp. An approval queue where every item is approved within seconds of arriving is evidence of a process that exists, and evidence that it is not functioning. Reviewers need enough context to make a real decision, and rejections need a recorded reason — otherwise the record cannot distinguish genuine oversight from a button being clicked.
What counts as evidence
Oversight evidence has to answer four questions about a specific event, after the fact, to someone who was not there:
- What did the system propose to do, and on whose behalf?
- Why was this surfaced for review rather than allowed to proceed?
- Which identified person reviewed it, and when?
- What did they decide, and what reason did they record?
Why the record has to be tamper-evident
An audit trail that the operator can silently edit proves nothing about the past — it proves only what the operator currently asserts. This is the gap between logging and evidence, and it is the distinction auditors increasingly probe.
The standard answer is hash chaining: each record commits to a cryptographic digest of the record before it, so altering any historical entry invalidates every entry after it. The chain does not prevent tampering. It makes tampering detectable by anyone holding the chain, including a regulator who does not trust either party.
Bulwark implements this with an HMAC-SHA256 chain and ships a standalone verifier that re-implements the hash rule rather than importing product code, so a trail can be checked without running or trusting our software.
Practical sequence
Oversight is not something to retrofit under audit pressure. A workable order of operations:
- Inventory the AI systems you actually run, including the ones no one registered.
- Classify which fall in scope as high-risk under Annex III.
- Define, per system, which actions require a human decision before they take effect.
- Route those actions to named reviewers with enough context to decide.
- Record the request, the reviewer, the verdict and the reason on a tamper-evident trail.
- Test the trail: export it and verify it independently, the way an auditor would.
Frequently asked
Does Article 14 require a human to approve every AI decision?
No. It requires that a human can effectively oversee the system, which for most deployments means human review of defined high-consequence actions rather than every output. The obligation is to design the system so intervention is possible and to show it happened where it was required.
Is an activity log enough to satisfy Article 14?
Usually not on its own. A log shows what the system did. Article 14 is about oversight, so the record also needs to show that a person could interpret the output, had the ability to intervene, and made a decision. A log with no reviewer identity and no recorded rationale does not demonstrate oversight.
What makes an AI audit trail acceptable to an auditor?
Completeness, attribution and integrity. Every reviewable event present, each tied to an identified person, on a record that can be shown not to have been altered after the fact. Cryptographic hash chaining is the usual way to demonstrate the third.
When do the AI Act obligations apply?
Obligations phase in by system category and date, and high-risk system requirements carry the longest lead time. Because oversight evidence is only useful if it was being collected at the time, the practical deadline for building the trail is well before the compliance deadline.
Bulwark does this in production
Agent registry, scope enforcement, human approvals and a hash-chained evidence trail you can verify without trusting us. Free Developer tier, 100,000 governed decisions a month, no card required.
Related guides
- AI agent audit trails: what makes a log hold up as evidenceThe difference between logging what your AI agents did and being able to prove it. Hash chaining, independent verification, and what auditors check.
- AI agent inventory: the register regulators will ask forWhat belongs in an AI system inventory, why "a spreadsheet of models" is the wrong shape, and how to keep it accurate as agents change.
- Shadow AI: how to find the agents already running in your companyMost organisations have more AI agents in production than anyone has written down. How to discover them from telemetry you already have.