Accountability Cannot Be Delegated to a Model

"The agent decided" answers nothing — not legally, not organizationally, not to the person affected. What accountability actually requires has design consequences, including why a rubber-stamp gate is worse than none.

"The agent decided" is not an answer to "why did this happen." It isn't a legal answer, it isn't an organizational answer, and it isn't an answer that satisfies the person affected. Accountability requires a party who can be asked to explain and who bears consequences, and no amount of capability supplies that.

This has practical design consequences that get missed when the discussion stays philosophical.

What accountability actually requires

Three things, and a model provides none of them:

Someone who can explain the reasoning. Not a trace — an explanation from a party who can be questioned, whose account can be probed, who can say "I considered that and here's why I discounted it."

Someone who bears the consequence. Accountability without cost is a formality. A model faces no cost, which means it can't hold the position regardless of how good its judgment is.

Someone who could have chosen otherwise, and knew it. The essence of responsibility. A system executing its design didn't choose in the relevant sense.

The design consequences

Every consequential action needs a named human owner, recorded at the time. Not "the agent did it under policy X" — a person who authorized this class of action and can account for it. That means the audit record has to capture who, and "who" cannot be the service account.

Approval has to be real to be accountability-bearing. ⚠️ A person clicking approve on something they didn't read has not taken responsibility in any sense that survives scrutiny — but they have been placed in the position of nominally holding it. This is worse than no gate: it manufactures a responsible party without producing any of the review that would justify it, and the person on the hook is usually junior.

If you're going to have a human gate, it has to show enough for a decision to be genuine, and the volume has to be low enough that decisions actually get made. Otherwise you've built a liability-transfer mechanism, not a control.

Reversibility substitutes for accountability at small scale. Where an action can be undone cheaply, the accountability requirement is proportionally lower — a mistake is a nuisance, not a harm. This is a strong argument for designing reversibility into everything: it's the mechanism that makes autonomy defensible without a person in the loop.

The scope of what's authorized has to be stated in advance. "This agent may issue refunds up to X for orders meeting condition Y" is a decision a person made and can account for. "This agent handles refunds" is not — it delegates the boundary itself, and there's no answer to why any particular refund was appropriate.

What good practice looks like

Policy decided by a named person, enforced in code. The human decides the boundary once, deliberately, and the boundary holds mechanically. That's accountability for the class of action, which is the honest thing to be accountable for at volume.

Per-action approval reserved for irreversible, wide-radius actions, with enough shown to decide and low enough volume that reading is realistic.

Audit records naming the person and the authorization. "Taken under the policy set by A. Rivera on 2026-03-11, scope Y" — that's a chain someone can follow.

Escalation when the agent is outside its authorized scope, rather than a best guess. An agent that acts outside what was authorized has broken the accountability chain even if the action was correct.

💡 The part that's about people, not systems

There's an organizational failure mode worth naming: accountability that formally sits with someone who had no real ability to prevent the outcome.

The engineer who wired up the agent isn't accountable for a product decision it made. The reviewer who approved one of two hundred daily requests isn't meaningfully accountable for that one. Assigning responsibility to whoever is nearest the mechanism, rather than to whoever set the policy, is both unjust and useless — it doesn't produce better decisions, because the person named couldn't have made them.

→ The accountable party should be whoever decided the agent could do this, with this scope, under these conditions. That's a real decision made by a real person, and it's the one worth recording.

The takeaway

Accountability needs someone who can explain, who bears cost, and who could have chosen otherwise. Design for it explicitly: state the authorized scope in advance, have a named person own that policy, record the authorization in the audit trail, reserve per-action gates for irreversible actions and make them genuinely reviewable, and build reversibility everywhere else. And make sure the person named is the one who set the boundary — not whoever happened to be closest to the machine.

Keep reading

Similar posts

Matched on shared tags and category — the more bars, the stronger the overlap with what you just read.