Deciding Which Decisions to Delegate to AI

← Playbooks

Playbook · Recurring adoption decision · Technology × Organisations × Psychology

Most disappointing AI adoption is not a model problem. It is an unexamined question about which decisions were being handed over. This is a way to examine that first.

This is reusable guidance, not a record of what happened and not a procedure. It is a starting point for a situation that recurs in different forms — useful while its conditions hold, and worth abandoning where they do not.

The situation

Capability has been deployed — assistants, automation, generated content, scoring — and reported impact is lower than expected. The instinct is to change model, vendor or prompt. Nothing about the decision being delegated has been re-examined.

The question

Which decisions in this organisation can absorb machine judgement, and which cannot yet?

Conditions

What needs to be true, or examined, before this approach applies.

• The decision being delegated can be described precisely enough to say what a wrong answer looks like.
• Consequences of a wrong answer are bounded and observable.
• The context the decision needs is available in a usable form.
• Someone remains accountable for the decision after it is delegated.

Signals

What is worth paying attention to.

• Whether people quietly re-check the output, which indicates trust has not transferred.
• How often the system is right and still not used.
• Where the cost of an error lands, and whether whoever bears it chose the delegation.
• Whether the surrounding process changed at all, or only gained a tool.

Decisions

What may need to be decided, and by whom.

• Which class of decision to start with, and what makes it a defensible starting point.
• What evidence would justify widening the delegation.
• What the escalation path is when the system is uncertain.
• Who reviews delegated decisions, at what frequency, and against what.

A first useful move

Name one decision, describe what a wrong answer would cost, and check whether that cost is acceptable and observable. If it cannot be described, it is not ready to delegate regardless of the capability available.

Not yet

Do not extend delegation to judgement-heavy decisions because routine ones went well. Do not put adoption targets before the decision classes are understood — targets create adoption theatre rather than adopted decisions.

The trade-off

Delegating routine decisions recovers attention and also reduces the everyday exposure through which people build intuition about their own operation. Some of what looks like inefficiency is how understanding is maintained.

Assumptions

What this rests on, and what would change it.

What informed this

Technical reasoning about decision classes, combined with observation of adoption in organisations. Effects were observed qualitatively; no comparison against a control exists, and this should not be read as a proven adoption sequence.

What would change this approach

This changes materially where regulation constrains automated decisions, where errors are not observable until much later, or where capability changes what a decision class can absorb. Reliability boundaries move, so any classification made once should be revisited.

Where this stops being useful

It does not evaluate models, does not price implementation, and offers nothing about decisions whose consequences are diffuse or delayed — which is where the harder adoption questions actually sit.

Related

Related reading

Industry

• Retail
• BFSI
• Logistics
• Consumer Technology
• Enterprise SaaS

Knowledge · Architecture

• Where inference sits, and where human judgement stays
• Separating decision cadence from delivery execution
• Keeping the reasoning outside the tools that produced it

Evidence · Observed Situation

• When routine decisions were being escalated because no system carried the context

The situations linked above informed this guidance. They do not establish that it transfers to another environment — that remains a question about the specific organisation.

Knowledge →Work with Cralgo →