Which work AI can take on, and which it cannot

Checking means someone who did not produce the output can tell whether it is right, quickly, without redoing the work. Sorting an incoming enquiry into a category can be checked at a glance: the category is visibly right or wrong. Deciding whether a customer deserves a refund cannot, because the only way to check the judgment is to make it again.

Where the output cannot be checked, the machine is not the problem. The problem is that nobody would know if it were wrong, and a mistake nobody can see is a mistake that repeats.

This is a question about what happens next, not about how often the mistake occurs. A wrong label on an internal record is undone in a second. A wrong figure in a message already sent to a customer cannot be unsent, and it may have been acted on. The cost of the mistake is set by whether the output leaves the building before anyone has looked at it.

That is also where the cheapest improvement sits. Many tasks fail this question only because the output goes straight out. Put a checkpoint between the draft and the send, and the same task becomes one where a mistake costs a glance.

Every task that is handed over still produces cases it cannot settle: the odd order, the unusual request, the document that did not arrive. Someone has to receive them, and that someone needs a name, not a shared inbox. A task with no owner for its exceptions does not fail loudly. It fails by the exceptions piling up where nobody looks, which is worse than the task being done by hand.

Owning exceptions also means having the time for them. An exception pile that lands on a person whose week was already full is a hidden cost of the handover, and it belongs in the sum as hours, as the comparison with hiring does.

Take two tasks that are invented for this illustration, in an invented small business. The first is sorting incoming enquiries by type and sending a standard acknowledgement. The output is checked at a glance, a wrong sort is corrected in seconds, and the owner of the leftover pile is the person who reads the enquiries labelled other. It passes all three as it stands.

The second is sending each customer a quote. A person can read a quote, so the output can be checked. But a wrong figure sent to a customer is not cheap to undo, so the task fails the second question. The single change is a checkpoint: the system prepares the draft, a named person approves it, and only then does it go out. The task now passes, and a person remains in the loop by design, not by accident.

Some work fails more than one question and no checkpoint fixes it. Decisions about individual people are the plainest example: the output cannot be checked without making the decision again, and a mistake lands on a person. In hiring, that is the reason software may sort, flag and prepare, while the decision that someone is not moving forward stays with a named human being, as the hiring page sets out.

Refusing a task is a result, not a failure of the method. A sort that returns nothing to hand over is useful, because it stops money being spent on automating something that would have cost more to supervise than to do.

It says nothing about any named model or product, because what those can do changes faster than a guide can be updated, and a capability claim written today would be stale soon. It is a way of asking about the task, which stays the same while the tools change.

Nor does it say how much a handed-over task is worth. That is a separate question about hours and baselines, and the savings estimator is where it starts. Passing the test makes a task a candidate. It does not make it worth doing.