September 30, 2026 · KI · Automatisierung · Regulatorik · Mittelstand

The Approval Nobody Sees

An approval can work exactly as planned and still wait unnoticed for a long time. Why waiting states in automation and AI agents need to be monitored.

Anyone who hands tasks to automations or AI agents builds a human into the critical points: before a change goes into production, data leaves the company or something can no longer be undone, someone has to approve. The principle is right, and regulatory frameworks take it up. One property of such approvals is rarely talked about: they are invisible as long as nobody is looking.

A typical scenario

Suppose an automated process – a data reconciliation, a software rollout, a permission change – reaches steps that need a human approval. They wait for many hours, unnoticed. Nothing is broken. The approval gate works exactly as it was built: it stops and waits. The only thing that fails is its visibility.

The reason is structural. A process that is blocked waiting for an approval usually does not report itself – it is, after all, blocked. From the outside, a waiting process looks like a quiet one: no error message, no alert, no output. Anyone who does not look specifically takes the silence for normal operation, or for a work step that is simply still running. And whoever would have to grant the approval may not even know it is pending – the request sits in an interface that nobody has open at the moment.

Such waiting times typically only become visible in hindsight, when someone evaluates the timestamps in the logs. A second point follows from this: without those timestamps, not even the order of magnitude would be known – only the vague impression that it “took a bit longer this time”.

What regulatory frameworks mean by human oversight

The European AI Act (Regulation (EU) 2024/1689) governs human oversight of high-risk AI systems in Article 14. These are to be designed so that natural persons can oversee them effectively during the period in which they are in use. Paragraph 4 lists what the persons exercising oversight are to be enabled to do. This includes monitoring operation in order to detect anomalies, dysfunctions and unexpected performance, as well as “to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)”, to disregard, override or reverse the output, and “to intervene in the operation of the high-risk AI system or interrupt the system through a ‘stop’ button or a similar procedure”.

Whether a specific system falls under this provision is a question of classification in the individual case. As a yardstick, the idea is useful even where the regulation does not apply.

The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) frames it as an organisational task: processes for human oversight are to be defined, assessed and documented (MAP 3.5), and roles and responsibilities for human-AI interaction clearly delineated (GOVERN 3.2). The framework also notes that it can be useful to collect data on how often and for what reasons humans override the outputs of deployed AI systems.

Both texts assume that the human is there when needed. How that human finds out in time is a matter of implementation – and that is exactly where the gap from the scenario lies.

Waiting is a state that must be monitored

Four rules can be derived from the scenario. They apply to scripts, pipelines and workflow tools just as much as to AI agents – and all the more, the more autonomously a process works, because the less often anyone is watching.

“Waiting for approval” becomes a state of its own, and a monitored one. With the time at which the request was made, an agreed threshold, and an alert when it is exceeded. The alert goes to a named point of contact with a deputy, not to a mailbox nobody reads. Because a process blocked waiting usually does not report itself, something else has to query the state – the monitoring comes from outside. The threshold depends on what is waiting behind the step: a nightly routine task can tolerate hours, a change a team is waiting on cannot.

Steps requiring approval are announced before they are triggered. Anyone who knows that a sign-off will be due in a few minutes will look. A short message to the approving person costs nothing – and it is the last message the process can still send itself before it blocks.

The step requiring approval goes at the end. If it sits in the middle of the process, everything that comes after it waits too – including work that needs no approval at all. At the end, it blocks only itself. Where that is not possible, independent steps should be completed beforehand or continued in parallel.

Waiting times are measured, not estimated. The start of the request and the time of the decision are in the logs; the difference is a metric that can be evaluated. This matches the NIST framework’s note on collecting data about human interventions: anyone who does not measure how oversight actually takes place does not know whether it takes place.

Too many approvals are not oversight either

The obvious reaction to an overlooked approval would be to build in more control. That only shifts the problem. Anyone who has to confirm ten times a day will at some point confirm without looking. The approval becomes a formality, and oversight exists only on paper – that is the form of automation bias Article 14 describes, just one level up.

The pattern is familiar from alerting. In the IT-Grundschutz module DER.1, the BSI describes as a threat that incorrectly configured alerting can lead to more false alarms; those responsible may then “possibly no longer be able to distinguish between a false alarm and a security-relevant event” and may not notice messages quickly enough. The same applies to approvals. Google’s SRE book formulates a principle for alerts that can be transferred: “Every page should be actionable.” An approval in which the approving person has nothing to decide is not one.

The other extreme – no approvals at all – is no solution either. The goal is few, meaningful approvals. Candidates for them are steps that cannot be reliably undone, whose effect reaches beyond one’s own area of responsibility, in which data leaves the company or in which permissions are granted. Anything that can be rolled back cleanly and whose result is checked automatically usually needs no human before it, but a check after it.

Checklist for approvals in automations

  • Every approval has a named responsible person with a deputy.
  • The “waiting for approval” state is visible, has a threshold and triggers an alert.
  • The approval is announced before the process blocks.
  • The step requiring approval comes as late as possible in the process.
  • Waiting times and decisions are logged and evaluated regularly.
  • The alert for open approvals has been triggered at least once as a test and has actually arrived.
  • The list of approvals is reviewed regularly as to whether each one still serves its purpose.

How sector7 supports you

Together with you, we assess what your use of AI triggers under the EU AI Act and set out risk classification, documentation obligations and clear responsibilities – more under sovereign AI. Our NOC monitors managed environments around the clock in an automated way; detected anomalies are handled according to the contractually agreed processes, as described under Managed Services & Support.

Sources

Let's talk about your situation.

Arrange a call+49 212 240915 0