EU AI Act Article 14 human oversight: what must a deployer actually show?

Under Article 14 of the EU AI Act, a deployer of a high-risk AI system must show that a competent, named person can understand what the system produced, judge whether to rely on it, and stop or override it, and that this oversight genuinely happened on the record. In practice this reduces to three things an auditor can inspect: defined human review points before a consequential decision takes effect, a working ability to intervene and halt the system, and a tamper-evident record proving that a specific person was in the loop for a specific decision. Article 14 treats oversight as an operating outcome, not a filed policy, so a written procedure with no evidence of use does not discharge the duty.

The timing has shifted, which matters for planning. The high-risk obligations in Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with high-risk systems embedded under Annex I moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read the new date as a build window and not a reprieve, because oversight evidence is produced by how a system is architected, and architecture cannot be retrofitted the week before an audit.

What exactly does Article 14 require a deployer to do?

Article 14 requires that high-risk AI systems be designed so natural persons can effectively oversee them while in use. The provider builds in the oversight measures, and the deployer operates them. For the deployer, the assigned person needs the means to do five things.

• Understand the system's capacities and limits well enough to spot a wrong output.
• Stay alert to automation bias, the tendency to over-trust a confident machine answer.
• Interpret the output correctly, using the tools and information provided with the system.
• Decide, in a given case, not to use the system or to disregard, override or reverse its output.
• Intervene or stop the system through a halt control that actually works.

A person nominally in charge with no genuine ability to say no does not meet this; the duty is effective oversight, and effectiveness is what an auditor tests.

How do you turn human oversight into controls an auditor can check?

The abstract duty maps onto three concrete controls, each producing its own evidence.

• Recorded review points: named checkpoints where a decision pauses for a human to approve, edit or reject before it takes effect, each one time-stamped and attributed.
• Intervention and stop: a tested control that lets the overseer halt or override the system in operation, with the halt itself logged as an event.
• A sealed in-the-loop record: an entry that binds a specific human identity to a specific decision at a specific time, and cannot be edited afterwards without detection.

An auditor does not want to read your policy; they want to pick a past decision at random and see who reviewed it, when, what they could have done differently, and proof the record was not rewritten later.

“Human oversight is not a clause in a policy, it is a sequence of recorded human decisions that a third party can verify without having to trust the operator.”

Which rule makes a sealed, tamper-evident record necessary?

The demand for a trustworthy record is reinforced across the wider regime. The GDPR accountability principle requires you to demonstrate compliance, not merely assert it. For regulated sectors, DORA, in force since January 2025, and NIS2 expect operational resilience and auditable control over critical systems. A record the operator can quietly edit is not evidence. This is why the seal matters: the audit ledger is signed with post-quantum digital signatures, using FIPS 204 (ML-DSA) as the primary standard and FIPS 205 (SLH-DSA) alongside it, so any later tampering breaks verification. These are signature standards; key encapsulation under FIPS 203 (ML-KEM) protects data in transit and never signs the ledger.

Why can a public cloud AI service struggle to prove this?

Public cloud AI services are useful, but as an architecture they make the deployer's evidence harder to own. The prompts, outputs and logs pass through infrastructure the deployer does not control, and the record of who oversaw what sits with the provider rather than the operator. Under the US CLOUD Act, data held by US-linked providers can be reached by foreign legal process regardless of where it is stored. This is a design observation, not an accusation: if the proof of human oversight lives in someone else's tenancy, the deployer cannot fully guarantee it was not altered, withheld or exposed.

How does a Sovereign Intelligence Operating System produce the evidence?

Mickai is a Sovereign Intelligence Operating System, a SIOS that runs offline on operator-owned hardware with every action cryptographically sealed. Review points are enforced as native checkpoints, so a consequential output waits for a human decision. A zero-egress inbound perimeter means no prompt or record leaves the operator's boundary. Hardware-attested identity binds each human action to the audit chain, so the person recorded is provably the one who acted. The ledger is sealed with post-quantum signatures and can be verified offline by a third party. This architecture is the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; these remain filed applications, never granted or patented.

What should a deployer do before December 2027?

Treat the deferral as build time. Inventory which systems fall in scope as high-risk, then define the review points where a human must approve before a decision lands. Test the stop control and prove it works under real conditions. Confirm every oversight event is written to a record that is attributed, time-stamped and sealed. The deployer who can hand an auditor a verifiable trail of human decisions will pass Article 14; the one holding only a policy document will not.

Frequently asked questions

Is 2 August 2026 the deadline for high-risk AI system obligations?

No. The high-risk obligations in Annex III once set for 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027. High-risk systems embedded under Annex I move to 2 August 2028, while the Article 50 transparency duties are largely unchanged. Treating the new date as a pause rather than a build window risks arriving unprepared.

Does a written human oversight policy satisfy Article 14?

Not on its own. Article 14 asks for effective oversight in operation, which means a competent person must be able to understand, override and stop the system, and that this must actually occur. An auditor looks for evidence that oversight happened on specific decisions, not just a document describing how it should.

What is the difference between Article 14 and Article 50?

Article 14 governs human oversight of high-risk AI systems, the duty to keep a competent person able to understand, intervene and stop. Article 50 governs transparency, such as telling people they are interacting with AI or that content is machine generated. They address different risks, and the Digital Omnibus left Article 50 largely intact while deferring the high-risk timeline.

Can we use a public cloud AI service for a high-risk system and stay compliant?

It is possible, but the deployer still has to prove human oversight, and that is harder when prompts, outputs and logs sit in a provider's infrastructure. Under the US CLOUD Act, records held by US-linked providers can be reached by legal process. The safer architecture keeps the evidence inside the operator's own boundary.

What makes an audit record tamper-evident?

A tamper-evident record is signed so that any later change breaks verification. In a sound design the audit ledger is sealed with post-quantum digital signatures, with FIPS 204 (ML-DSA) as the primary standard and FIPS 205 (SLH-DSA) alongside it. Because the signature covers the recorded decision, an auditor can confirm offline that no entry was altered after the human acted.