Owners, Consequence and Decision Rights

AI programmes seldom stall because a model is weak. They stall because nobody can say who decides. A tool is launched, usage climbs, and then a question arrives that no one is empowered to answer: is it working, may staff paste client data into it, who approves the next change? Governing AI as it scales starts with naming people, matching effort to consequence, and knowing which decisions sit where.

Three owners, named before launch

Every launch needs a named person for three different things. The outcome owner answers whether the work is better, measured against a result the business cares about, not against how many people logged in. The adoption owner answers whether the right people use the tool in the intended way. The policy owner answers what is permitted: which information may go in, what must be reviewed, what is out of bounds. One person can hold more than one role, but each role needs a name. A steering group, a vendor contact or an IT administrator supports an owner but is not one.

When two records disagree

Organisations keep several records: a service register, a project charter, a risk policy, a contract. They drift. If the register says the head of operations is accountable and the charter says the IT director is, do not quietly pick the one that looks newer, and do not call both people co-owners to avoid an awkward conversation. Surface the conflict. State what each record says, say what it affects (typically who approves changes to the tool's rules and who answers if something goes wrong), and identify the authorised decision route: the person or board that your own governance documents empower to settle ownership. Then record the ruling in both places.

Match controls to consequence

Not every use deserves the same scrutiny, and uniform heavy control is as much a failure as uniform light control. Three questions set the level. How large a financial loss could one error cause? Does the workflow touch personal data? Can the effect be reversed once it has happened? A tool that suggests names for an internal workshop sits at one end; one that drafts payment instructions or messages to customers about their money sits at the other. Controls should follow: light approval and sampling for low consequence, named sign-off, privacy review and verification before release for high.

Humans who can verify and decide

Where an error is costly, a person should verify the output before it takes effect, and that person needs the source material, the time and the authority to stop it. Sampling suits low-consequence work, not a message telling a customer their loan terms have changed. You also need a named person to decide exceptions: the case where the draft and the source disagree, or the reviewer is unsure. That person records the reason.

One rule is easy to break by accident: the tool must not decide which of its own outputs need human review. A feature that lets the tool mark its own answers as low risk so staff can skip them has the system grading its own homework. Review triggers belong to the workflow owner and should rest on facts the tool does not control, such as the value involved, the type of message, a new counterparty or an unusual format.

Decision rights: sponsor and workflow owner

A workflow owner can approve what is inside the approved scope: adjusting a template, naming a reviewer, scheduling training, approving a revised checklist. Three kinds of decision go to the executive sponsor: funding beyond the owner's delegated authority, claiming capacity shared with other teams, and changing a company-wide rule. When you ask the sponsor, ask for a specific decision: the amount, the time period, the date needed and what happens if the answer is no.

Exceptions to data rules follow the same logic. If a team wants to keep prompt logs beyond the retention schedule, the decision belongs to the authorised privacy or data owner. Record the request, the owner who decided, the conditions and the review date.

A worked example

Calder and Ross is an invented building society. It launched an assistant that drafts replies to members about mortgage changes. The launch plan named a project manager, a vendor contact and an IT administrator. Six weeks in, replies were fast but two members received wrong payment dates. Operations said the tool belonged to IT; IT said policy belonged to compliance; the register named the head of operations while the charter named the IT director. Nobody could say whether to pause.

The sponsor did four things. She had the conflict written up: what each record said, that it affected who could approve a pause, and that the governance board chair was the authorised route. The chair ruled that the head of operations owned outcome and adoption, and compliance owned policy. Because payment dates are financial and irreversible once sent, a trained colleague now verifies each message against the mortgage system, and the head of operations decides exceptions and records why. Finally, the tool no longer tags its own drafts as safe to skip.

As of 24 September 2026.