Which work a company should never automate

When an organisation discusses automation, the same hope is usually present: less waiting, less manual work, more capacity. That is legitimate. It becomes problematic when the question turns into which role can still be automated away. A decision about work then quickly becomes a decision about accountability that no one has made explicitly.

My judgement is clear: an organisation should never outsource entrepreneurial responsibility, value judgements and the ability to intervene appropriately to a model. This is not a blanket or permanent ban on technology. Tasks change, models change and tested risk boundaries can change. What does not disappear is the duty of a responsible person to weigh consequences, stand behind a decision and intervene when new information emerges.

The relevant unit is therefore neither the job title nor the entire end-to-end process. It is the individual task in the context of a decision. A model can organise information, check a contract draft against a clause library or flag an exception in a policy. It should not itself decide whether a non-standard contract is acceptable, which customer receives a discretionary exception or how a sensitive personnel conversation should be conducted. These are illustrative situations, not an exhaustive prohibited list.

The distinction matters commercially. When tasks are defined incorrectly, the result is not just errors. It is unclear liability, poor handling of exceptions, an overloaded control team and decisions that no one can explain when challenged. That erodes speed precisely where automation is supposed to create it.

I would keep three operating modes clearly separate.

Assistance provides a suggestion, research, a summary or an initial structure. A responsible person reviews and decides. This mode can save considerable time without shifting decision rights.

Bounded, rules-based execution completes a clearly defined action within pre-approved rules. A system may, for example, transfer complete data into an existing system or trigger a standard process when conditions are unambiguously met. Exceptions need a route back to a person.

Autonomous decision-making chooses between options with different consequences. It can determine prices, approvals, priorities or communications. The greater the impact on customers, employees, contractual obligations, safety or reputation, the less sufficient a retrospective glance at a dashboard metric becomes.

This is not a semantic nicety. Contract preparation can be assistance. Deciding on a liability provision is a value judgement under uncertainty. An exception approval may contain a rules-based element. Whether it is fair, appropriate and commercially viable in a specific situation often cannot be derived fully from historical data.

People also make poor decisions and bring their own biases. That does not mean, however, that a human name beside a model recommendation is enough. Human oversight is only oversight when the person is competent, sees the material information, has time to review, is allowed to disagree and has a real ability to stop or fall back.

The cause is rarely a single poor model. More often, it begins earlier, in how the work is described.

First, tasks are defined too broadly. “Process a contract”, “decide on a customer” or “resolve an employee case” sounds like a task. In fact, each formulation contains research, rule checking, communication, assessment of exceptions and a decision about consequences. When all of this is treated as one automation case, the normative decision quietly moves into the system with it.

Second, model capability is confused with operational acceptability. A plausible draft does not prove that a model may safely make a decision. The question is not only: Can the system produce a good answer in a test? It is also: Does that performance hold in this data context, for this exception, with this pattern of harm and with this fallback process?

Third, the wrong metric is often in the foreground. Those who measure only cases processed or cycle time reward the transfer of difficult cases to downstream teams. Review effort, corrections, escalations and the quality of the final decision then disappear from view.

Fourth, “human in the loop” is used as a label. An approval click at the end of a long chain is not an independent review if the reviewer can understand neither the underlying data nor the rule boundary. Nor is a person under high throughput pressure a robust control function.

The question is not whether AI can be useful. It can be, if people remain accountable within the process. A study published in the Quarterly Journal of Economics in 2025, involving 5,172 customer-support agents at a Fortune 500 provider of business-process software, observed 15% more successfully resolved enquiries or chats per hour after staff gained access to a GPT-3-based response assistant. The employees remained responsible for the conversation and could change or ignore suggestions. This is evidence of an opportunity for human-accountable assistance, not proof of automatic cost savings or of general transferability to other organisations. The effect also varied by experience and capability. The staggered introduction of an assistant in one firm is not an experiment in autonomous action. 1

The boundary matters just as much. In a preregistered randomised experiment with 758 BCG consultants, published online in 2026 and conducted with GPT-4 as available in June 2023, the probability of a correct solution among the AI-assisted groups for a selected complex management task outside the identified GPT-4 capability boundary fell by around 19 percentage points compared with the control group. This is not a general error rate and not a judgement on all current models or business decisions. It is a precise indication that, even with capable technology, permissible automation depends on the specific task and its tested boundary. 2

These findings do not contradict one another. They concern different tasks and systems, but illuminate two sides of the same leadership question. Assistance can improve performance. Outside a recognised capability boundary, a persuasive-looking suggestion can reduce decision quality. An organisation must therefore not infer autonomous accountability from a successful demonstration.

The NIST AI Risk Management Framework offers a voluntary framework for orientation. It is neither a binding Swiss or EU legal requirement nor a certification. NIST stresses documented roles, leadership accountability for AI risk decisions, differentiated human oversight, testing in the intended operating environment, monitoring and safe options to modify or stop. These are precisely the elements that turn an abstract call for control into a testable operating decision. 3

Before an organisation moves a task from suggestion to rules-based execution or from there to autonomous decision-making, I would require four questions to be answered in writing. Not as governance theatre, but as the approval basis for the accountable owner.

Does someone own the decision and its consequences?

Every outcome needs a named person or function that can stand behind the decision. This responsibility cannot be delegated to a model. If no one can say who corrects an erroneous exception, informs a customer or assesses a loss event, the automation boundary has been set incorrectly.

The criterion is particularly stringent when a decision is difficult to reverse. A flawed draft can be corrected. An unjustly rejected legitimate complaint or a mishandled personnel interaction can damage trust before a team intervenes.

Does the task contain an uncodified value judgement?

Rules can represent clear conditions. They cannot automatically decide every trade-off. Discretion versus equal treatment, short-term margin versus the customer relationship, speed versus safety or formal rule versus a legitimate special interest require conscious weighting.

The organisation should therefore not ask whether a model can formulate a rationale. It should ask whether the underlying trade-off exists as a stable, approved rule. If it does not, the decision remains with a qualified person. The model may prepare and make alternatives visible.

Can the control genuinely disprove the suggestion?

A control must be able to do more than agree. The reviewer needs access to the relevant source data, the applicable rules and the information that the case requires outside the normal range. They must be able to reject, amend, stop and escalate a suggestion without KPI pressure.

In practice, that means documenting more than the final recommendation. The basis for the decision, the context used, the exception and the correction must also be visible. Where independent review is not possible, automation must not be legitimised by a formal approval step.

Is the boundary tested and is the fallback operationally ready?

A permissible boundary is not an assumption made at project launch. It is tested for the intended operating environment. Which cases may the system handle? What data quality is assumed? At which signal does execution stop? Who takes over then, within what time and with what information?

The fallback process is not a technical emergency exit for a presentation. It is part of performance. If a team does not know how to take over a case correctly after a stop, automation shifts risk instead of managing it. Monitoring matters just as much: new products, changed policies, different customer groups or changing data can shift the tested boundary.