What Zero-Touch is: a complete guide to narrowing what gets reviewed

Zero-Touch is an operating structure in which AI completes every case it can process normally and hands over only the low-confidence ones, narrowing what has to be reviewed at all.

Why Zero-Touch is needed

Accuracy went up and review stayed the same.

A recurring situation in organizations that have adopted document automation: recognition accuracy has reached 98 percent and the operator is still checking every case. There is no way to know where the two percent is hiding, so everything gets looked at.

In that state, another percentage point of accuracy changes nothing about the workload. What reduces review burden is not accuracy but the ability to tell which cases are safe and which are not. In real deployments, blanket recalculation became review of the 8 percent flagged as exceptions, cutting reconciliation effort by 92 percent, and full review became looking at only the 11 percent of documents routed as exceptions. Those came from changing the structure, not the accuracy.

What Zero-Touch actually is: how it differs from full automation

Full automation and Zero-Touch across three axes

First, the premise differs. Full automation assumes every case can be machine-processed. Zero-Touch assumes cases that cannot be processed will always exist and puts identifying them at the centre of the design.

Second, the objective differs. Full automation aims to eliminate human intervention. Zero-Touch aims to narrow precisely what a person has to look at. Documents that genuinely require judgment are safer routed to a person from the outset.

Third, the metrics differ. Full automation reads only the automatic processing rate. Zero-Touch reads the share completed without human intervention alongside the weight of cases routed to exceptions and whether those exception decisions were actually right. A low exception rate that let through cases which should have been caught is not good operation.

The two are not alternatives. Continually narrowing exceptions converges toward full automation. Where you start, though, decides how stable the operation is along the way.

Four conditions that create Zero-Touch

Four conditions that hold in real operations

First, confidence has to be produced per field. One score for the whole document gives no indication of which field to inspect. A threshold can only be drawn once every value carries its own confidence.

Second, business rules have to run as validation. Moving the conditions a person used to check — date ordering, sum reconciliation, name agreement across documents — into rules catches a substantial share of errors automatically.

Third, the definition of an exception has to be narrow. A setting that routes anything remotely ambiguous to a person does not reduce review burden. Define it by whether a divergence in that field actually affects the business.

Fourth, the threshold has to be adjustable. Setting it conservatively at launch and lowering it gradually as error history accumulates is the safe approach. Unless that adjustment is possible without code changes, it will not happen in practice.

How Zero-Touch is applied in practice

Use review history as the basis for the threshold

There is no way to set the threshold correctly from the start. The only basis is gathering the fields operators actually corrected once the system is live.

Fields with almost no corrections have their threshold lowered and move to automatic processing; fields corrected frequently have their threshold raised or a validation rule added. Repeating that adjustment quarterly brings the exception rate down naturally.

Build a separate path for exception cases

Mixing normal and exception cases on one screen makes the operator judge which is which every time. A separate screen holding only exceptions, showing why each became one, cuts confirmation time substantially.

Display the reason by category. Whether confidence was low, whether cross-document reconciliation diverged, or whether a business rule requires judgment changes where the operator needs to look.

Zero-Touch in the Korean environment

In Korean finance and the public sector, the scope of permissible automatic approval is frequently fixed by internal policy. Segments requiring human confirmation remain even where automatic processing is technically possible. Treating those as approval stages inside the flow, rather than as exceptions, is the better arrangement.

Audit requirements come alongside. Even automatically processed cases need a record of the basis on which they were judged normal. Retaining per-field confidence and the validation rules applied is the configuration this calls for.

Frequently asked questions