Home/Frameworks/Capability, authority, accountability
Capability, authority, accountability
Three questions to ask of any AI proposal that reaches your desk. Most proposals answer the first and quietly skip the other two.
Organisations are not short of AI capability. They are short of a way to decide what to let it do. These three questions separate what a system is able to do from what it is permitted to do here, and both of those from who carries the consequence when it is wrong.
They are deliberately blunt. The value is not in their subtlety, it is in noticing which one a confident answer has skipped.
The three questions
| Question | What it asks | What answers it | Who owns it |
|---|---|---|---|
| Capability | What can it do? | Measurement against your own data and your own edge cases, not a vendor demonstration. | The team building or buying it. |
| Authority | What may it do here? | An explicit decision about scope: which actions, which cases, which limits, and when it must stop and ask. | The business owner of the process. |
| Accountability | Who answers for the outcome? | A named person who can be asked afterwards, and who had a real opportunity to intervene beforehand. | Never the system. |
A powerful model settles the first question. It does not settle the other two, and the third never moves to the machine.
Why capability and authority are different questions
Capability is a property of the technology and travels with it. Authority is local, and does not travel at all. The same model that may draft a reply in one process must not send one in another, and may be barred entirely from a third. Nothing about the model changes between those three cases. What changes is the permission, and therefore the consequence.
This is the distinction that collapses most often in practice, because capability improves on its own and authority does not. A system quietly becomes more capable between one release and the next. Its authority only changes when somebody decides to change it. When nobody is watching that gap, capability outruns the permission it was granted under, and the first sign is an incident.
Why accountability is not a third kind of control
Accountability is often treated as the paperwork that follows the other two. It is not. It is the question that decides whether the first two were answered honestly.
A human reviewer who receives an output with no evidence, no time, and no realistic ability to say no is not accountable for it. They are a signature. If the answer to "who answers for this" is a role that cannot actually refuse, the system has more authority than the organisation believes it granted.
Where a capable system fails
Capability rarely fails on its own. These are the four places where a system that works in isolation goes wrong in a process, and the control that addresses each.
| Fails at | Looks like | A useful control |
|---|---|---|
| Evidence | An outdated policy is retrieved and cited confidently. | Versioned, authorised sources, with supersession visible. |
| Reasoning | An answer the retrieved material does not actually support. | Evaluate whether the evidence supports the claim, and surface uncertainty. |
| Action | The right decision applied to the wrong record. | Validation at the boundary and narrow permissions. |
| Authority | A document instructs the system to ignore its rules, and it complies. | Separate content from instructions. Never let retrieved text grant permission. |
Using it on a real proposal
Take a concrete case. A customer's order is late. The system can check the order, draft a reply, and issue a refund.
- Capability. It can do all three. That is settled, and it is the least interesting thing about the proposal.
- Authority. Version one reads the order status and drafts a reply for a person to send. It does not decide the refund. That boundary is chosen, written down, and can be widened later on evidence.
- Accountability. The person who sends the reply owns it, and has the order history in front of them when they do. Before widening anything: measure wrong drafts, review time, and whether the customer was actually helped.
That is deliberately not maximum autonomy. It is one defensible answer, not the only one. The point of the model is not that it produces this answer; it is that it makes the three decisions visible enough to argue about.
The failure this is meant to catch
An organisation that has answered capability and authority, and believes it has therefore answered accountability. It has a capable system, a documented scope, a human in the review step, and no one who could actually have stopped the thing that went wrong. All three questions had answers. Only two of them were real.
Revisions
- First published. Drawn from the guest lecture delivered at Amsterdam Business School on 16 September 2026.
First-person account of the presenter's own practice. The framework is a teaching tool, not a legal taxonomy or any employer's policy. See how I make claims.