Decision rights for AI-assisted decisions name, for each category of decision AI touches, who owns it, what authority they hold to accept or override what the AI produces, and how disagreement is resolved when a person and a system reach different conclusions. In my experience this is often not written down, including in organisations that think their AI governance is mature. Writing it down is the fastest way to make AI use accountable without slowing it.
Why decision rights have to be explicit, not assumed
Before AI, decision rights in most businesses were implicit and that mostly worked, because the pace of human decision-making gave everyone time to notice unclear authority and fix it informally. AI removes that margin. A decision category with unclear ownership no longer moves slowly while people work out who should weigh in. It moves at full speed with nobody clearly accountable, and the gap becomes visible only after something has happened, when fixing it is more expensive and more public than designing it in advance would have been.
The standards bodies point the same way. NIST's AI Risk Management Framework notes that human-AI configurations can span from fully autonomous to fully manual: a system can decide on its own, defer a decision to a human expert, or be used by a decision maker as an additional opinion. It says the human roles and responsibilities in decision making and in overseeing AI systems need to be clearly defined and differentiated. Article 14 of the EU Artificial Intelligence Act requires that high-risk systems be designed so natural persons can effectively oversee them, with oversight measures proportionate to the risks, level of autonomy and context of use. Both are saying the same thing as the sentence in the box above: somebody specific has to be able to take the decision back.
The three components decision rights for AI-assisted decisions need
Ownership comes first. It has to be a named person or a clearly defined role, not a team, a function or a vague sense that someone in the department is probably responsible. Diffuse ownership behaves exactly like no ownership once something goes wrong and everyone needs to know who answers for it. Authority comes second. Does the owner have explicit permission to override what the AI produced, and do they know they have it and feel licensed to use it, or do they treat a recommendation as something that needs special justification to disagree with?
Resolution is the third component and the one most often skipped. What happens when the AI recommends one thing and the owner believes another is right? Does the owner's judgement simply prevail because they hold override authority? Does the matter go to a second reviewer for high-stakes categories? Must the override carry a documented reason so that it becomes part of an auditable record? None of those answers is correct in every case. What matters is that the business chose one deliberately, and did not discover the gap in the middle of a real disagreement with consequences attached.
The three components
- Ownership: A specific named person or clearly defined role accountable for the decision category, never a diffuse team or function.
- Authority: Explicit, known permission to override the AI's output, understood well enough that the owner feels licensed to use it.
- Resolution: A deliberately chosen answer for what happens when human judgement and AI output disagree, decided in advance and not improvised under pressure.
A decision rights matrix you can copy
The mapping is more tractable than it sounds. List every decision category where AI plays a real role. Not a vague function such as hiring, but the specific decision, such as which candidates advance past initial screening. For each one, fill in a row. The table below is a template with illustrative rows. The categories and roles are examples I wrote for this article, so replace them with your own.
| Decision category (illustrative) | Owner | Override authority | Resolution of disagreement | Record kept |
|---|---|---|---|---|
| Which candidates advance past initial screening | Head of talent acquisition | May advance or reject any candidate regardless of the system's ranking, without special approval | Owner decides; a sample of overrides is reviewed monthly by the people leader | Candidate, system output, decision and one-line reason |
| Pricing exception above an agreed threshold | Commercial director | May reject the system's proposed price; may accept only with finance sign-off | Escalates to the CFO if the commercial director and finance disagree | Quote, proposed and final price, approver, reason |
| Customer-facing message drafted by AI | Head of the relevant service line | May edit, withhold or replace any message | Owner decides; complaints trigger a review of the category | Draft, edits, who approved, any complaint that followed |
| Forecast adjustment recommended by AI | Finance business partner | May overrule the recommendation within a set tolerance; beyond it needs the CFO | CFO decides; variance reviewed at quarter end | Recommendation, override, reason, later actual |
| Safety-relevant maintenance flag | Operations manager on shift | May override in either direction; an override of a safety flag needs a second reviewer | Second reviewer decides; both names recorded | Flag, override, both reviewers, outcome |
Where any of the three components is missing or vague, that is your priority list, ranked by how much consequence sits behind the category if it goes wrong. In my view the gaps are not evenly spread. Decisions with external consequence, such as customer-facing calls, financial commitments and personnel actions, are the ones I would check first, because they carry the most consequence. Where AI is adopted fastest, on the logic that speed matters most, it is easy for nobody to ask whether accountability has kept up.
Why the override question is harder than it looks
Granting override authority on paper is easy. Making it real is harder, because it runs against a psychological current. Once a system has produced good recommendations for a while, overriding it starts to feel as if it needs a stronger justification than the system's recommendation ever did. That inverts the normal burden of proof, and nobody decided it should. The risk is the one MIT Sloan Management Review and BCG describe in their 2025 responsible-AI research: without enough understanding of how the system reached its answer, human overseers can be reduced to rubber-stamping what machines decide. Of the experts they polled, 77% disagreed that effective human oversight reduces the need for explainability.
A right that exists on paper and is never used is a theoretical permission slip. The only way to tell is to check whether overrides happen at a rate that makes sense for the decision volume, not whether the policy allows them. The four actions below are the ones I ask owners to take.
- Name owners for specific decisions, not broad categories: "Marketing owns AI-assisted content decisions" is too vague. Name the specific decision and the specific accountable role.
- Confirm override authority is understood, not just granted: Ask the owner whether they know they can override the AI and whether they would feel comfortable doing so without extra justification. The answer is often no even when the policy says yes.
- Choose a resolution path deliberately, in advance: Decide now whether disagreement escalates, needs a documented reason or defers to the named owner. Do not improvise it during a real disagreement.
- Track whether overrides actually happen: A decision right with no recorded overrides over a meaningful period and volume is a signal to investigate, not proof that everything works.
How decision rights differ by decision type
Not every category deserves the same weight of structure. Treating them identically produces heavy process on trivial decisions and, worse, thin process on consequential ones, because the effort gets spread evenly and not by stakes. A low-stakes, high-volume decision, such as which product recommendation to show a browsing customer, can carry a lighter structure: a named team owner, a general understanding of override and periodic review. A high-stakes, lower-volume decision, such as a material pricing exception, a personnel action or a safety judgement, needs the full weight: a named individual, explicit override authority that is regularly exercised, and a documented resolution path with a record of every instance.
The more common mistake is not slightly mis-calibrating. It is not calibrating at all, and applying either a uniformly heavy process that slows the business everywhere or a uniformly light one that leaves the dangerous categories exposed. Calibration needs an honest conversation about which decisions carry consequence if they go wrong. Many leadership teams avoid that conversation because it forces prioritisation, and a comfortable, evenly spread policy is easier to write and much less useful.
Redesign the workflow before you assign the rights
The rights are easier to write once the workflow is clear, so I do that first. In one engagement we redesigned the workflow first, then added an agent to carry out defined steps with human sign-off at the risk points. Those sign-off points are where decision rights live: each one needs an owner and a rule for what happens when the person disagrees with the agent. With another client I named an accountable owner for every AI use case, defined what needed risk review and set clear rules for human oversight. We made the compliant path the easy one, and teams then moved faster because they knew the rules.
The same idea works outside AI. When I recommended that a transformation continue, I set conditions: one accountable executive owned the outcome, the benefits case was re-baselined with finance, and we agreed checkpoints at which the board could still stop the programme. The CEO accepted the conditions. The lesson carries over directly: decision rights work when they are specific, handed to a named person and checked against what actually happens. For the wider design, the guide to improving executive team decision making applies the same logic to the whole team, and the human and AI decision ladder shows how a decision can drift between people and systems.
What happens when decision rights are never tested
A decision right that is written down and never tested is an untested assumption, and the gap between the two shows at the worst moment. The first genuinely contentious disagreement is the wrong time to discover that the resolution path assumes a second reviewer who does not exist in the current organisation chart, or that the owner was never sure they could override.
The fix is to test the rights before you need them. Give the named owner a plausible, difficult scenario in which the AI's recommendation and good human judgement would reasonably diverge, and walk through the resolution path as if it were real. A dry run surfaces these gaps cheaply and calmly. Then repeat it when the system, the volume or the owner changes. Write down what the exercise found, because the next person to take the role will need it.
What decision rights look like at board level
A board conversation about AI risk goes differently once the rights are built. Instead of general reassurance about responsible use, the leadership team can walk through specific decision categories by name, say who owns each, describe the override authority in concrete terms and explain how disagreement resolves. That specificity shows the risk has been designed around and not left to chance and good intentions. The way to prepare is the same discipline I describe in managing up to your board: bring the decision required and what could go wrong, and not a general update.
For the executive-team side, how to build an AI ready executive team without another layer of management uses the same matrix idea across the roles you already have, and what an AI leadership operating model is places decision rights within the wider system. The leadership skills CEOs need in the age of AI covers the individual capabilities underneath. If you want a structured starting point, the AI leadership operating model page sets out how I approach it, and the AI leadership gap page describes the problem from the CEO's side. To work through your own matrix with me, see work with me. CapabilityAI applies the same decision-rights frameworks.
Decision rights for AI-assisted work
These rights are not a compliance exercise or a document built to survive an audit. They are the mechanism that decides whether speed and judgement can coexist as AI takes on more of the load. Skip the explicit design work and speed wins by default, one convenience at a time, until accountability has drifted somewhere nobody chose. Build it deliberately, name the owners, confirm the authority is real and choose the resolution path in advance, and the business gets the benefit of AI speed and a person who answers for where that speed leads.
Speed with no named owner is not agility. It is exposure. For another example of putting a structure around people decisions, see the staffing batting average, a process for people decisions.