Human oversight of AI can't mean *approving what 300 agents prepared*

The signing-off problem

Professor Niklas Kühl put it plainly at a recent AI summit in Munich: designing human oversight for AI systems cannot mean approving what 300 agents have prepared ^[1]. He is right, and the comment gets at something organisations are starting to feel: the AI Act says high-risk systems need human oversight, but what does that mean when you have dozens or hundreds of AI agents working at once?

It's a bit like being asked to check the shopping list after someone else has already filled the trolley, wheeled it to the checkout and started packing. You can refuse to pay, but by then the question is whether you trust the shopper, not whether you supervised the shopping.

Article 26 of the AI Act requires users of high-risk AI to ensure appropriate human oversight, but it doesn't say how ^[2]. For high-risk systems under Annex III, the requirement applies from 2 December 2027 ^[3]. The question is practical: what does oversight look like when AI agents are calling tools, making decisions and acting faster than a person can watch?

What the law asks for

Article 26 tells users of high-risk AI to use the system according to the instructions, ensure human oversight, monitor how it performs and inform people affected by its decisions ^[2]. The oversight must be appropriate to the risks, which sounds reasonable until you ask what it means on a Tuesday morning with agents running in parallel.

The AI Act doesn't require a human to approve every output. What it does require is that a competent person can intervene, and that the user has a way of understanding what the system is doing ^[2]. The rub is that understanding what 300 agents did yesterday is not the same thing as supervising them while they do it.

The evidence gap

Here is the bit that tends to come up later. Say an agent changes a customer's order, cancels a booking or pulls information from a restricted file. When the customer complains, or an auditor asks, the first question is: what did the agent actually do, and who asked it to?

If the only record is a line in a chat log that someone with administrator rights could have edited, oversight starts to look like hoping. Oversight that can be checked afterwards requires a record of what each agent did, which tool it called and what came back, sealed at the time so nobody can quietly tidy it up before the auditor arrives.

That is what Article 12 is getting at when it asks for automatic logging of events over the system's lifetime ^[4]. It doesn't say how to protect the logs, but an auditor who finds that the log could have been changed will ask whether it was.

What meaningful oversight requires

Meaningful oversight has three parts. First, the person supervising needs to know what the AI is doing, in terms they can actually follow. Second, they need to be able to stop it or correct it when it goes wrong. Third, when something is questioned later, they need to be able to show what happened.

The first two are design questions: how the system presents its actions and where the stop button is. The third is an evidence question, and it is the one that gets left until last. By the time someone asks what the agent did six months ago, the moment for thinking about records has passed.

Professor Kühl's point is that signing off after the fact is not supervision. The corollary is that supervision you cannot prove afterwards is hard to defend. A log that could have been edited is better than no log, but not by much.

How a digital witness fits here

This is a case where sealing records as they happen solves part of the problem. Not all of it: a sealed log doesn't make a system safe or a decision fair. What it does is let you show, later, that the record of what the agent did is exactly what was written at the time.

Here is what gets sealed: each instruction the agent receives, each tool it calls, the result it gets back and the action it takes. The fingerprint of that record is sealed when it happens, through WitniumChain's REST API, SDK or MCP server. The content stays in your systems. To check it, anyone you share the record with calculates the fingerprint again and compares it with the sealed one.

What it shows is that the record hasn't changed. What it doesn't do is authorise the action, prove it was correct or replace the oversight itself. It is the receipt, not the permission slip.

The practical benefit is shorter conversations. When an auditor asks what an agent did, you hand over a record and a way to check it. When a customer disputes an action, you have your own version of events, sealed at the time, that nobody could have quietly edited afterwards. The first 2,000 witnesses a month are free.

How it would work

1. Seal each agent action as it happens: instruction, tool call and result.
2. Keep the sealed fingerprints with your logs.
3. When questioned, share the record and let the other party check it.

What this means for you

If you are deploying AI agents, decide now what oversight means for your organisation. Ask:

• Can the person supervising see what each agent is doing, in real time or close to it?
• Can they stop an agent or override a decision?
• If an agent's action is questioned in six months, do you have a record that shows what it did, and can you prove nobody has changed it?

The third question is the one that comes up in audits, disputes and incident reviews. Leaving it to chance means leaving it to trust, and trust is what the oversight requirement is trying not to rely on.

What to watch

The human oversight requirement for high-risk systems under Annex III applies from 2 December 2027 ^[3]. Between now and then, expect more guidance on what appropriate oversight means in practice, particularly as AI agents become more common.

The question Professor Kühl raised is not going away. As systems act faster and at greater scale, the gap between signing off and supervising will only get wider. The organisations that answer it early will have simpler conversations with auditors, customers and supervisors later.