Who owns a process once AI is doing the work
Name one accountable owner, give them visibility and the power to stop the process, and plan for what changes in the team. A practical guide to ownership.
In this essay
One named person owns the outcome.
Every automated process needs a single person who answers for the result. This is the same person who would answer if a colleague had done the work. The owner is accountable to the business for whether the process produces correct results, on time, at an acceptable cost.
A team or a committee cannot hold this role, and neither can the vendor or the person who built the system. When something goes wrong, the question "who decides what happens now" needs one answer.
The owner must be able to see and stop it.
Accountability without visibility is a title. The owner needs to read what the process did on any given day, in plain language and not only in logs an engineer can parse. They also need the authority to pause the process, or to send all cases to a person, without asking for permission first.
Check this early by asking the owner to find, within a few minutes, what the process did with one specific case last Tuesday. If they cannot, the setup is not finished.
Some roles sit beside the owner.
Reviewers judge samples of results against the written standard and record what they find. They do not need to be the owner, and it helps if they are people who know the work well. A maintainer changes the instructions and the connections to other systems when the business changes, for example when a price list or a policy is updated. In a small company one person can hold more than one of these roles, but they should be clearly named separately so that none is forgotten.
Each person should have a deputy. A process owned by someone who is on holiday is, for that week, owned by nobody.
For the team, less of the doing and more of the checking.
People who used to carry out the work now spend their time reviewing results, handling exceptions and improving the instructions. This takes different skills from doing the work, though they rest on the same knowledge. The best reviewers are usually the people who did the work for years, because they recognise a plausible but wrong answer.
Plan for this openly. Say what each role will be doing in three months, and give people time to learn it. Teams that are only told the tool has arrived tend to check results less carefully, or avoid the tool.
Responsibility to the customer does not change.
A customer who receives a wrong answer does not care how it was produced. The company is responsible for it, and a named person is responsible within the company. Decisions with real consequences, such as refunds above a set amount or changes to contract terms, should stay with a person who has the authority to make them. Write that list down and put it where the team can find it.
Ownership must survive a change of staff.
Write down how the process works, what the standard for a correct result is, who holds each role, and how to change the instructions. Store it where the team works. If the owner leaves, a new owner should be able to take over from those notes in a few days.
This is also the test of whether the work has really been handed over. If the people who set up the process are needed for it to keep running, it still belongs to them.