Accountable autonomy: five levers for AI you can let act
Sai Krupa Sagar6 min readAgentic AI · Workflow design · Risk controls
Nobody will let an AI write all the code and ship it. Nobody will let it clear every shipment through customs, or run production infrastructure on its own. And they are right not to.
Why the model is not the problem
The usual explanation is that the models are not good enough yet. That is rarely true. The real problem is a mismatch: a probabilistic system is being put into a business that runs on deterministic accountability. Every serious process has an answer to one question — who answers for this? A typical AI build has no answer. So the people whose job is to ask — risk, compliance, finance, audit, the licensed broker, the release owner — say no. They are not being difficult. The system gives them nothing to say yes to.
Better prompts, retrieval and fine-tuning all help. None of them removes the probability. You can bound it, and then you must account for it. That is a design job, not a model job.
The standard we already apply to people
We trust people with consequential work all the time, but only under conditions. A junior adjuster settles up to a limit. A customs clerk classifies but cannot override a ruling. A developer merges to a branch but does not deploy to production. Their work is:
- Bounded — done within defined authority.
- Attributable — a named person owns the judgement.
- Verifiable — someone who was not there can reconstruct what was seen, which rule applied, and why.
Authority matrices, sign-offs and audit trails exist to make human work meet this standard. Accountable autonomy applies the same standard to AI. We do not ask people to trust the AI. We make the AI's work meet the standard they already apply to their staff.
Five levers do that.
The five levers
- Work classes — sort the work by what it costs to get wrong. Before any AI is built, classify each unit of work by consequence: how severe, how reversible, how quickly a mistake would be noticed, and whether there is a settled right answer or it needs judgement. A lint fix, a schema migration and a production deploy are not one class called "code." Clearing a routine screening false positive and overriding a customs ruling are not one class called "exceptions." Almost every AI programme skips this step — it classifies by feasibility or ROI instead — and that is why its controls end up uniform: either a human reviews everything, or the AI does everything. Anything unclassified defaults to the most restrictive class.
- Autonomy bands — decide how far the system may go, per class. Three bands are enough. Act: the system proceeds alone and humans sample. Ask: the system prepares everything and pauses for a named person. Stop: the system does not touch this, routes it to a person, and no model is ever called — so there is no plausible wrong answer to catch. The band is set by plain rules outside the model, and the system cannot widen its own band. Write down what is out of scope before what is in.
- Accountability gates — put a name on every pause. "Human in the loop" means nothing without four parts: a named person (never "the ops team"), a clock, the reason shown (which check failed), and the outcome recorded. The gate's shape depends on the class — pre-approval for irreversible work, sampling for reversible work. A gate that makes someone click OK on everything is a bottleneck, not accountability, and reviewers who average twelve seconds are not reviewing.
- Evidence trails — make every decision able to answer for itself. Logs say what happened technically. An auditor asks something different: what was decided, on what evidence, under which version of the rules, by whose authority, and what could not be established. That is a decision record, produced as a by-product of every decision. The test: could someone reconstruct it in eighteen months, in minutes, without interviewing the engineer? Design the reconstruction, not the log.
- Evaluation gates — grant autonomy on evidence, never assume it. A class moves from Ask to Act only when measured evidence clears a bar set before go-live: agreement with human decisions in shadow runs, accuracy against a golden set, error and coverage within tolerance. The same gate narrows autonomy when evidence degrades. Track the error that matters — the case waved through that should have been caught — together with coverage; either number alone can be gamed. And for the highest-consequence classes, the end state is permanent shared accountability, not a gradual handover.
Levers one to four bound the system. Lever five turns them into a loop instead of a fence.
One workflow, two builds
Invoice exception handling: an invoice does not match the purchase order or the goods receipt. Four cases arrive on a Monday:
| Case | Work class | Band | What happens |
|---|---|---|---|
| Price 1.8% over PO, within tolerance | Low severity, reversible, arithmetic decides | Act | Verified against the PO and tolerance rule, posted, decision record written |
| No goods receipt | Not decidable — evidence missing | Ask | System names the missing document and requests it from the warehouse |
| Euro invoice, sterling PO | Out of declared scope | Stop | Refused in milliseconds; routed to a person; no model called |
| 14% over, vendor under review | Money, vendor risk, judgement | Ask | Named AP lead, four-hour clock, failed condition shown; decision recorded as precedent |
In the usual build, every one of these gets an answer — including the euro invoice, which the model converts at some rate and reasons its way to a confident, calm, wrong recommendation that no guardrail flags. When audit asks about one decision seven months later, two engineers spend two days in the logs and produce "based on the prompt template we were using in March, it probably…".
In the accountable build, the audit question is answered in four minutes. And after a quarter of evidence, the evaluation gate widens the Act tolerance from 2% to 3%, while flagged-vendor cases stay in Ask permanently — by design.
The accountable build is not more sophisticated. It is less: fewer model calls, fewer moving parts, more things written down. When an AI system underperforms, most teams add components. The fix is usually the opposite: add boundaries, not parts.
Try this tomorrow
Take any AI system doing — or hoping to do — real work in your business, and ask one question per lever:
- Show me the work classes — what has this system been given, sorted by what it costs when it goes wrong?
- What will this system never do?
- Who is the named person for its exceptions, and what is the clock?
- Show me one past decision, reconstructed end to end — not a log.
- What evidence would widen its autonomy, and what would narrow it?
Good systems answer in minutes. Most cannot answer at all, and that gap — not model quality — is what keeps AI away from the work that matters.
Most AI programmes start by asking what the AI can do. Accountable autonomy starts by asking what it would cost if the AI got each thing wrong, and builds the controls in proportion to the answer.
By Sai Krupa Sagar. For help AI-enabling your business workflows, visit aiforgrowth.io.