Keeping a person involved in the decision-making process doesn't mean automation has failed; it means it's been well-designed. Most of the savings from an automated process are in the preparation—gathering, comparing, drafting, and proposing—not in the final approval click. Eliminating that click adds almost all the risk in exchange for almost no savings.
The discussion about full autonomy is often framed as a question of technological maturity. It is more useful to frame it as a question of economics: where is the expensive labor and where is the expensive risk?.
Let's take a typical incident resolution process. Time is distributed approximately as follows:
A system that automates the first and third steps captures most of the savings. The decision, where the risk lies, is now in the hands of one person who has everything they need and takes one minute instead of twenty.
This is why the most profitable pattern we've measured isn't autonomy: it's the Complete preparation with human approval.
Model | How it works | When is it convenient |
|---|---|---|
Prior approval | Nothing is executed without validation. | Irreversible actions: payments, external communications |
Exception | It is executed except in defined cases | High volume, limited risk |
Sampling | Everything is executed, a part is reviewed | Low risk, need for quality control |
Subsequent review | It is executed and then audited | Only if the action is reversible |
The common mistake is choosing the model based on the level of confidence in the system, when it should be chosen due to the reversibility of the action. An excellent model executing payments without validation is still a bad design decision; a mediocre model classifying tickets with sample review is perfectly reasonable.
The legitimate objection is that human validation negates the savings if it's poorly designed. Four rules prevent this:
The system delivers the prepared case, not the question. The person should see the proposal, the information it is based on, and the alternatives; they shouldn't have to search for anything.
Approval is the default action. If validation requires more clicks than doing it manually, the process will be abandoned.
The validations are grouped together. Twenty consecutive approvals cost much less than twenty interruptions throughout the day.
It is recorded what is corrected. This is the key point, and the one that almost no one implements: every correction is a piece of data about the actual quality of the system, as we explained in Automation without observability is irresponsible
The decision to remove human validation should be based on data, not trust. Three cumulative conditions:
If all three conditions are met, it makes sense to move from prior approval to supervision by exception in lower risk cases, while maintaining validation in the rest.
And one rule that should be put in writing: Supervision is not withdrawn due to scheduling pressure. It is the most common cause of incidents in automated systems, and it is a decision that is usually made in a meeting without minutes.
From 2025 onwards, there is an additional reason that is not subject to anyone's judgment. The European AI Regulation requires demonstrable human oversight for certain categories of systems, and not in the abstract: it must be possible to prove who reviewed, what they saw, and when.
This makes recording the validation a requirement, not a best practice. And it has a design implication: monitoring that occurs but isn't recorded proves nothing.
When someone proposes eliminating human validation to increase efficiency, the useful question isn't whether the model is good enough. It's: How much exactly do we save by removing that step, and what is the cost of an error that no one detects?
In most processes with economic impact, the first number is small and the second is large. When both are on the table, the conversation resolves itself.
This design involves human intervention in the decision-making process of an automated system. It doesn't indicate a failure of the automation itself: most of the savings are in case preparation, not final approval, so maintaining validation preserves almost all the benefits and eliminates almost all the risk.
Four: prior approval, where nothing is executed without validation; supervision by exception, where it is executed except in defined cases; sampling, where everything is executed and a part is reviewed; and subsequent review, applicable only if the action is reversible.
Because traditional automation was deterministic and therefore predictable,
The reversibility of the action is the deciding factor, not the level of trust in the system. An excellent model processing payments without validation is still a poor design choice, while a mediocre model classifying tickets with sample-based review is reasonable.
which allowed for coexistence with the lack of documentation. By incorporating decision-making components, the same case can be resolved differently, and without a record, there is no way to reconstruct why.
With four rules: that the system delivers the prepared case with proposal, evidence and alternatives; that approval is the default action and requires no more clicks than doing it manually; that validations are grouped instead of interrupting; and that what is corrected in each review is recorded.
When three cumulative conditions are met: a high and stable approval rate without changes in real-world cases, low-impact errors with a known distribution, and reversible actions or actions with a limited amount. Never due to calendar pressure.
Yes. The European AI Regulation requires demonstrable human oversight for certain categories of systems, which means being able to prove who reviewed the system, what information they had access to, and when. Oversight that occurs but is not recorded does not allow for demonstrating compliance.
Where should a person intervene in your automated process? We designed the control point, the validation interface, and the registration required by the regulations, without turning supervision into a bottleneck. Let's talk →