What Article 14 actually requires
Article 14 doesn't ask for "someone watching" — it asks that the person watching can actually do something if something goes wrong. Specifically, the people responsible for oversight need to be able to:
- Understand the system's real capabilities and limits, not just its marketing description.
- Remain aware of automation bias — the natural tendency to trust what an automated system says, even when something doesn't add up.
- Correctly interpret the system's output, in its actual context.
- Decide not to use the output, disregard it, or reverse it when warranted.
- Intervene or stop the system at any time — what's often called the "stop button" in practice.
The rule adds something that's frequently overlooked: the people assigned to this role need the competence, training and authority to exercise it. A supervisor without enough technical knowledge, without real time to review each case, or without the authority to halt a decision without asking permission first, doesn't meet the spirit of Article 14 — even if their name sits on an org chart next to the word "oversight."
The delay doesn't mean "forget it until 2027"
There's a very concrete reason not to treat December 2027 as a distant date: GDPR already requires something very similar, and has since 2018. GDPR Article 22 gives every person the right not to be subject to a decision based solely on automated processing — including profiling — that produces legal effects or similarly significantly affects them, unless there's real human intervention in the process. If your AI system makes decisions about people (hiring, credit scoring, access to a service), you very likely already need something functionally equivalent to Article 14 oversight, even though the AI Act doesn't formally require it of you yet.
There's also a purely practical argument: human oversight is one of those pieces that's cheap to design from the start and expensive to add afterward. Deciding who oversees the system, with what information, and with what real ability to stop it, shapes architectural decisions in the system itself — it isn't a document you write at the end.
The most common failure: rubber-stamp oversight
The most frequent failure isn't the total absence of oversight — it's symbolic oversight: someone with the job title of "approving" every decision the system makes, but with no real time to review it, not enough training to catch an error, and so much accumulated trust in the system that approval becomes a reflex. That's exactly the automation bias Article 14 asks you to guard against — and it's precisely what regulators look for first when reviewing an oversight procedure: could this person actually stop the system in practice, or is their sign-off just a formality?
What a real procedure needs to include
- Who oversees each system, by name or role, not just by department.
- What information that person receives to actually judge the system's output, not just the final answer.
- A clear escalation protocol for when something doesn't add up — who gets notified, and how fast.
- Documented training for that person on the real capabilities and limits of the specific system they oversee.
- Evidence the "stop button" has actually been used, or that a real channel exists to use it — not just a theoretical one.