Which decisions are still mine after AI arrives?

When an AI system starts doing part of someone’s job, the question that matters most to them, in our view, is a practical one: which decisions are still mine?

Other questions follow. Am I still responsible if the system gets something wrong? When can I override it? What am I now expected to check, and how carefully? What happens to the time I used to spend on the work it now does?

In our view these questions belong to the design of the system, not to a communication plan written after launch. If the people in a role cannot answer them, either the organisation has not finished deciding how the work will be done, or it has not yet told them.

Strategy reaches daily work through decisions

A strategy and an operating model set the direction: which work changes, what the system is for, which risks are acceptable. They become real for an accounts payable clerk only when they reach a Tuesday morning and an invoice the system has marked ready for payment. At that point the transparency people can use is narrower and more concrete: who decides what, in which situations, and on what basis.

That information exists only if someone has decided it. A project can specify precisely what the system does and still leave implicit what the person next to it does.

A system that works can still leave the job undefined

Consider a hypothetical industrial distributor. Its accounts payable team receives supplier invoices by email and through a portal. A new AI assistant will read each invoice, match it to the purchase order and the goods receipt, and propose one of two outcomes, ready for payment or query with the supplier, marking the invoices where it is uncertain. The assistant does not pay anything: invoices marked ready go into the usual payment run, which finance still approves. Until now the clerks have done this matching by hand. After go-live they will mainly handle the exceptions.

The assistant has been tested and gives good answers on the test cases. The open questions are elsewhere. If the invoice price is slightly above the order price, who decides whether the difference is acceptable? If a supplier’s bank details have changed since the last payment, does a person always check before the payment run? When a clerk disagrees with a proposal, can they stop it, and does anyone need to know? Is a clerk answerable for invoices they never saw because the system marked them ready?

These are not mainly technical questions. Together they define what the clerks’ job now is.

Write the answers down, one role at a time

We propose a short decision map for each role the system changes. One page, written in the language of the people who do the work, with five parts:

The system. What it does, and what it does not do.

You decide. The decisions that are yours, including the cases that always come to a person.

You check. What you are expected to review, and what “checked” means.

Who answers. Who is accountable for the result, including for work the person never sees, such as invoices the system marked ready.

Not decided yet. What is still open, who will decide it and when.

In the example, any change to a supplier’s bank details comes to the clerk, who confirms it with the supplier through a contact already on file, on a different channel from the one the change arrived through, before the invoice can join the payment run. The finance manager answers for the payment run as a whole. Separating who carries out a step, who decides and who answers for the result keeps responsibility from falling into the gap between the system and the people next to it.

The map does not replace the system’s permissions or the process documentation. It translates them into the terms of one role, so that a person can tell, in front of a specific invoice, whether the next move is theirs. Unlike a responsibility chart that assigns activities across a process, the map is checked against individual cases, says what “checked” means, and names what is still open.

People are ready when they can explain and handle real cases

Writing the map is not enough. Before go-live, sit with a few people from each affected role and walk through three or four real cases: a clean invoice, a price difference, a changed bank account, a case the system marks as uncertain. For each one, ask them what the system will do, what they will do, and who decides if they disagree with the system. Then ask them to do it in the test environment: stop a proposal, correct a match, send a changed bank account for verification. Explaining a step is not the same as having the information, the permission and the means to take it.

Where their answers match the map, that part of the rollout is ready. We would treat this as a go-live condition alongside technical acceptance: a role that cannot explain and carry out its cases is not ready, whatever the test results say. Where answers differ, the gap tells you something specific. In the example, the clean invoice matches the map. The price difference shows that the map never states the tolerance, so the map needs fixing. The changed bank account shows a clerk who believes the system handles it, while the map says the clerk decides, so the training needs fixing. The uncertain invoice shows that there is no way to stop it yet, so the system needs fixing. Each gap is easier to address while the people who set up the system are still involved. Repeat the same walk-through a few weeks after launch, when people have real experience of the system and can correct the map themselves.

This walk-through can be observed in a way that training attendance and usage figures cannot. Someone can use a tool every day and still not know whether they answer for what it approves.

Say what has not been decided yet

Some questions will not have an answer before go-live. A sensitive one is what happens to the time the system frees up. The organisation may not yet know how that time will be used.

In that case an honest map says so: not decided yet, who will decide, and by when. That is more useful than silence, which can leave people to fill the gap with their own assumptions, and more credible than a promise nobody is in a position to keep.

The map stays small because it tracks responsibilities, not features

The obvious objection is effort. A map for every role can sound like bureaucracy, it may look out of date by the next release, and some people would rather learn a tool by using it.

We agree that the map should stay small. It describes decisions, not features, so it changes when a responsibility changes rather than with every release. The walk-through is meant to take hours, not weeks. Proportion matters too: an optional writing assistant that moves no responsibility needs little more than a note on what not to share with it. The effort is justified where the system changes who answers for an outcome, such as a payment, a commitment to a customer or a safety-relevant decision.

Permissions are not responsibilities

AI platforms can provide roles, permissions, usage analytics and training material, and these are useful. Permissions define what the system and each user are able to do. They do not tell a clerk whether they answer for a payment they never saw, or when their judgment is expected. Usage analytics show that people use the tool, not that they understand where it needs them.

Those answers come from process design, governance and change work, done with the people concerned rather than for them. For Amigdala, this is part of what responsible AI means in practice: innovation that protects people starts with making sure they know what is still theirs to decide.

Before the next rollout, choose three real cases and ask the people whose work will change to walk you through them. If they can, you are close to ready. If they cannot, you have found the work that remains.