Teams that ship machine learning features rarely stall on the maths. They stall on a quieter question: when the data scientists, the product lead, the platform engineers and the security reviewer all have opinions about a model going live, who actually says yes? This FAQ works through the practical questions people ask about decision rights in AI work, with an analytical eye on what tends to happen when the answer is vague and what changes when it is written down.

Why does an AI project need a named decision-owner at all?

Because AI work produces more reasonable disagreement than most engineering. A model can be slightly more accurate and slightly slower, cheaper to run but harder to explain, easy to deploy but awkward to monitor. Each trade-off has defenders. If no single person is empowered to weigh them, the group defaults to continued discussion, and continued discussion feels productive because everybody is contributing.

The evidence for the cost is mostly experiential rather than numerical, so it is worth being honest about that: no universal figure tells you how many weeks an unowned decision wastes. What practitioners consistently describe is a recognisable pattern. A choice is raised, deferred for more input, re-raised, and finally decided by whoever happens to be loudest or last in the room. Naming the owner up front replaces that accident with a deliberate process.

What exactly is a decision-owner supposed to do?

An owner is not a dictator and not a rubber stamp. The job has four parts: collect the relevant input from a defined set of people, decide within an agreed time, record the choice with its reason, and answer for the outcome. Notice that “answer for the outcome” does not mean “be blamed”. It means that when the model behaves oddly three months later, the team knows whom to ask what was weighed at the time.

How do I choose between consensus, majority and owner-decides?

Think of these as three tools with different costs.

• Consensus is appropriate when every party must live with the result and cannot easily route around it, for example agreeing on a data retention rule that engineering, legal and analytics all depend on. It is slow, and one holdout can stall it, so give it a deadline and a fallback.
• Majority suits questions where the group is roughly symmetric and the stakes are modest, such as picking the naming scheme for experiment runs. It is quick but can leave a resentful minority.
• Owner decides after consulting is the right default for most technical forks, because it combines speed with a clear line of accountability. The owner listens, then chooses.

The mistake is not choosing the wrong one of these; it is leaving the rule unstated, so that half the group thinks it is a vote and the other half thinks the lead will decide.

Who should be consulted, and who just needs to know?

A tidy way to separate input from information is to keep two short lists for each decision. The consulted list holds people whose knowledge or sign-off materially changes the answer: the engineer who runs the serving layer, the analyst who owns the evaluation set, the reviewer responsible for privacy. The informed list holds everyone affected who does not need to weigh in, such as support staff who will field questions. Keeping the first list small is a skill. Each additional consulted person adds delay, so ask whether their input would really change the outcome before adding them.

This also protects against a subtle failure: being informed is not the same as being heard. People on the informed list should hear about the decision promptly, in writing, with the reason, so they are not surprised.

What should the written record contain?

Keep it short enough that people actually write it. A useful decision note has the following fields:

1. The question, phrased as a single sentence.
2. The owner and the date by which the call will be made.
3. The rule: consensus, majority or owner decides.
4. Who was consulted and who was informed.
5. The outcome and the main reason it was chosen over the nearest alternative.
6. A date for looking back at whether it held up.

Teams working on analytics and automation will recognise the value of this immediately: a model card describes what a model does, while the decision note describes why the team chose to run it. Both are needed when someone new inherits the system. For a related angle on how AI changes the way organisations weigh options, see this piece on how machine learning feeds into everyday business choices, which pairs well with the governance question here.

Does naming an owner make decisions less careful?

In practice it tends to do the opposite. When responsibility is diffuse, each person assumes someone else is double-checking. When a single person owns the call, that person has a personal reason to ask the awkward questions: has the evaluation data drifted, does the rollback path exist, has the person who knows the legacy pipeline actually been consulted? Care becomes concentrated rather than assumed.

That said, the owner’s authority should be bounded. Some calls, such as deploying a system that affects how customers are treated, deserve a second named signatory, and the rule should say so in advance. The goal is clarity, not a single point of control for everything.

What if the owner is wrong?

Then the record helps. Because the reasoning is written down, the team can see whether the mistake came from missing information, a poor weighing of the options, or a changed environment, and adjust the process rather than assign fault. Good owners also set a review date precisely because they expect to be sometimes mistaken. Reversing a decision openly, with a note saying what changed, builds more credibility than defending it silently.

Does this idea apply outside engineering?

Yes, and the parallels are instructive. Any group that must act together under time pressure benefits from the same trio of owner, deadline and rule. Families organising medical travel for a relative, for instance, often face an unglamorous version of the stall: someone has to coordinate dates, someone the paperwork, someone the budget. An information portal like BestHeartSurgery, which presents itself as a resource for patients and families considering medical travel rather than a provider of treatment, can supply reading material, but the household still has to name who handles the practical arrangements.

What is a quick way to start on Monday?

Pick the single open question your team has argued about longest. Write the owner’s name, a date within the week and the rule beside it. Share it in the channel where the debate has been happening. If you want a companion exercise on weighing options once the owner is set, the walkthrough on how groups line up AI products against their needs offers a sensible starting structure. Then watch what happens: usually the argument ends within a day, not because anyone was overruled, but because everyone finally knew how the answer would be reached.