Saying a human reviews it is not a human-oversight design

For a long time I answered the oversight question with a sentence: "a human reviews the output before it goes out." It sounded responsible. It was almost content-free, and it took an uncomfortable review meeting for me to see that.

The follow-ups were ordinary: who is that human, what authority do they have, and how do they stop it. I had a role label, not a design. Under the EU AI Act, Article 14 requires high-risk systems to be designed for effective oversight and Article 26(2) requires deployers to assign it to competent people. Both describe a control path, not a noun in an architecture diagram.

"Human in the loop" is not a control

The phrase hides three things that have to exist independently: the person, the mechanism by which they intervene or stop the system, and the conditions under which they are expected to use it. Most systems have the first, a vague second, and nothing for the third. Article 14 is written from the provider's side: the system must be built so a human can understand its limits, notice anomalies, interpret output, decide not to use it, and halt it. Article 26(2) is the deployer's mirror: assign oversight to natural persons with real competence, training, and authority. As a deployer you inherit both problems, since you cannot design the provider's system but you can be honest about whether the handover gives your named person anything real to do.

The three columns I started drawing

A table exposed the gaps. Column one: a named overseer, not "the team", with competence and authority written down. Column two: an override or stop path, meaning a specific action and the state the system enters when it is taken. Column three: the guards against bias, meaning conditions that force a genuine decision rather than a reflexive click. That third column is where you admit the review might be theatre, and it is the only one that changes behaviour: sample approved outputs for a second look, require a reason on override, make "stop" a button that is tested rather than a procedure in a document.

I built OversightKit to produce that table as a draft. You paste how you use AI, and it returns an Article 14 / 26(2) human-oversight design draft: a readiness read, named roles, an override and stop path, bias guards, and the gaps where no overseer is named. That is the whole feature set. It does not install a control, train staff, or observe whether anyone clicks the button.

A draft is not a runtime control

OversightKit writes down a design. The named person, the intervention mechanism, the escalation path, the training, and the authority to halt the system are still things an organisation has to put in place. A document saying "a named overseer approves high-risk outputs" changes nothing until there is a person, a button, and a consequence. The named-overseer gap is the part I find most useful: a thin description comes back with roles that have no name attached, and "the compliance team" is not a name. Friction is the point of oversight, but it costs throughput, and the right review level is a judgement for the people accountable for the system.

The limits, stated plainly

This is a decision-support tool. It is not legal advice, it is not a certification, and it is not a live audit harness. It does not control your system, train anyone, or decide whether Articles 14 and 26 apply to you. That depends on high-risk classification under the Act, including the Annex III use cases, and on whether you are a provider, a deployer, or both. If your system is not high-risk, most of this design work does not apply.

I am referencing real obligations, not a deadline, not a fine, and not a guarantee that a completed draft makes anything compliant. Article 14 is about designing for effective human oversight; Article 26(2) is about the deployer assigning it to competent people. The output is a design draft. It does not exercise it. If your oversight story is the sentence I used to give, the paste-first draft at OversightKit gives you a table to argue with.

FAQ

What does OversightKit produce?

An Article 14 / 26(2) human-oversight design draft from a description you paste: a readiness read, named roles, an override and stop path, bias guards, and the gaps where no overseer is named. A document, not a runtime control.

Does it add oversight to my system?

No. It does not install a control, train your staff, or observe whether anyone intervenes. The person, the mechanism, and the authority are yours to put in place.

Is this legal advice or a certification?

Neither. It is a decision-support draft, not legal advice, not a certification, and not a live audit harness. It cannot determine whether the obligations apply.

Do I need it if my system is not high-risk?

Probably not. These oversight duties are tied to high-risk systems, including the Annex III categories. If that is not your situation, most of the design draft will not apply.