The interesting question is not what your machines are capable of deciding. It is which of those decisions anybody authorised, and whose name is on the authorisation.
Ask a senior team to name the decisions in their business that a machine now makes without a person confirming them. You will usually get two or three: a fraud hold, a replenishment order, a bid, a routing choice. Then ask for the paper — the record showing when the enterprise stopped confirming, what bounds were set, who set them, and what would withdraw them.
In most organisations that document does not exist — not because it was mislaid, but because the moment it would have recorded never took the shape of a decision. Somebody adjusted a threshold. Somebody removed a confirmation step that had become a bottleneck. Somebody reassigned the two analysts who reviewed the queue. Each was defensible on its own terms and none was an authorisation, yet together they moved a class of decision out of human hands.
This is not a technology problem and it is not a future problem. It is a governance gap that has already opened, and the first executive act is to find out how wide.
The Strategic Context
Autonomy is not a state a system is in. It is a position on a ladder, and the rungs sit close together.
A system that ranks options for a person is advisory. A system whose top-ranked option is applied unless someone intervenes has moved: the default has changed hands, and defaults decide. A system that acts within pre-set bounds and reports what it did has moved again. One that acts and reports only exceptions has moved further. One whose exception queue nobody reads has arrived somewhere nobody chose.
Every step is small, locally sensible and cheap, and none presents as a delegation of authority. They present as an interface change, a threshold adjustment, a staffing decision, a backlog that quietly stopped being worked. The ladder is climbed by accretion, and accretion generates no minutes.
The subject here is narrow and worth stating plainly, because it sits beside a much larger body of practice that does not apply. The object of this delegation is a machine agent, not a person. Enterprises have hard-won discipline on human decision rights — who may change what an initiative is for, who may refuse a deliverable, who must be consulted. Very little of it transfers, because a human delegate can be asked why, can decline, can notice that a situation is unlike anything in their experience, and can be held personally accountable afterwards. A machine agent does none of those things.
Why This Never Reached the Board
It arrived as a system, so it was approved as a system. The paper that went up sought funding for a build — scope, cost, benefit, go-live date. It did not say: this transfers authority over a class of decision from named people to software. That consequence was real, foreseeable and unstated, and what was approved was expenditure.
The human in the loop is assumed to be a control. Frequently it is not. If a reviewer alters a very small share of what the system proposes, only two readings are available: the system is right almost always, in which case the review is ceremony and should be replaced with sampling and explicit escalation criteria; or the reviewer has stopped looking, in which case you have autonomous operation with a name attached for the purposes of liability. Both are defensible. Neither is what the control register claims. The measure that discriminates between them is the override rate, and few organisations collect it.
Model approval is mistaken for standing authority. A technical sign-off states that a system performed acceptably against a sample on a particular day. A delegation is a standing grant that must survive growth in volume, drift in the population it acts on, and conditions it was never tested against. Enterprises issue the first and behave as though they hold the second.
The boundary is drawn around the system rather than the decision. Governance attaches to platforms, because platforms have owners and budgets. Authority is exercised over classes of decision, and one platform routinely holds several: a scheduling engine that sequences maintenance is also, quietly, deciding which assets run to failure.
Reframing the Issue: A Delegate You Cannot Interrogate
The instrument required already exists in every enterprise of scale. A delegation of authority schedule names the holder, the class of decision, the limit, the escalation trigger, the review interval and the route by which the delegation is withdrawn. It is unglamorous, well understood and audited. Machine delegations are recorded as a system name, a sponsor and a go-live date.
The reframe is to put machine agents on the same schedule, with three adaptations. A machine's limit is not primarily monetary; it combines rate, population and reversibility. Its escalation trigger must be specified in advance, because a system cannot notice that a case is unusual unless someone defined unusual. And its delegation needs a reversal route with a tested duration, because withdrawing authority from software is an operational event, not a conversation.
None of this asks whether the system is any good. Competence and authority are separate questions, and they are conflated in both directions: a system can be demonstrably better than the people it displaced and still be operating outside anything the enterprise authorised, and a system can be properly authorised and nowhere near good enough to deploy [Related article: When Is a Model Good Enough to Deploy — and What Shelves It?].
Throughput Is the Exposure, Not the Error Rate
Executives instinctively evaluate automation on accuracy. The more consequential variable is what a wrong rule costs before anyone notices.
A person applying a flawed judgement makes a few dozen poor decisions before a colleague, a customer or a manager intervenes, and their errors are uncorrelated with everyone else's because people are inconsistent — which is precisely what automation is bought to eliminate. Uniformity is the benefit and it is also the mechanism: automate a decision and you remove the accidental diversification that inconsistency provided. Errors stop being scattered and become systematic, arriving at the rate the system runs.
Three quantities govern the exposure, and only one is technical: the rate of decision, the recoverability of a single wrong instance, and the latency of detection. The last almost never has an owner.
Consider, hypothetically, a national wholesale distributor that automates trade credit limits. The rule performs well overall and slightly misjudges customers with strong seasonal working-capital cycles. A credit officer making the same misjudgement affects a handful of accounts a month and hears about it from a sales manager within days. The automated version applies it to every seasonal account at once, and the signal arrives as a revenue variance a quarter later, by which time those customers have arranged finance elsewhere. The rule was as good as the person's. The exposure came from rate and detection latency, neither of which appeared in the business case.
Where the Ladder Is Climbed Fastest and Watched Least
Internal decisions escalate first: screening applications, allocating shifts, sequencing maintenance, ranking candidates for development, triaging tickets. They are cheap to automate, involve no external contract, and their sponsors face no customer.
They also carry the weakest feedback of anything the enterprise does. A rejected applicant does not complain, and would not know what to complain about. A maintenance job that was never scheduled does not report its own absence. A customer-facing error produces a call, a claim, a churn event; an internal one produces silence, and silence is routinely read as an absence of problems.
Autonomy therefore accretes fastest exactly where the organisation is least able to discover that it has gone wrong. The corrective is not to slow the automation but to build the missing channel deliberately: periodic re-decision of a random sample by experienced people, blind to what the system chose, with disagreements examined rather than counted. That is a modest standing cost, and the only thing between an internal delegation and undetected drift.
Whether the decision sits inside something you sell is a separate question, with a different liability profile and a different owner [Related article: Is Your AI a Feature You Sell, or a Tool You Use?].
The Accountability That Does Not Transfer
Authority moves; responsibility does not. Directors' duties and Australian consumer and privacy obligations are not suspended because a decision was executed by software rather than by a person, and an organisation unable to explain the basis of an adverse automated decision may be poorly placed if asked to [FACT CHECK REQUIRED]. This is general commentary, not advice, and requires verification by qualified professionals; ERANORTH is neither a law firm nor a financial adviser.
The consequence is a design requirement rather than a legal one. If you may have to reconstruct why a decision was made on a particular day, you must retain the version of the system that made it and the inputs it saw — an architecture and retention decision taken at the point of delegation, not an incident-response capability, and part of a wider question about who owns collection and definition across the business [Related article: Your Data Pipeline Is an Operating-Model Decision, Not an IT Project].
Decision Framework
Build one register — the machine delegation schedule — with a row for each class of decision rather than each system.
| Field | What it must state | The test that it is real |
|---|---|---|
| Decision class | The decision, in the language of the business, not the system name | An operating leader recognises it as theirs |
| Rung | Advisory, default-accepted, bounded action, exception-reported, unreviewed | Evidenced by override and queue data, not by design intent |
| Authorising officer | One named individual, not a committee or a function | They can state the bounds without reading the register |
| Bounds | Rate, population, value and the cases it must never decide | A test case exists that the system refuses |
| Escalation trigger | What the system must hand back, defined in advance | Triggered at least once in the last quarter |
| Detection channel | How a systematic error would be found, and how fast | A detection latency measured, not estimated |
| Reversal route | Who withdraws the delegation, how, and what happens to work in flight | Drilled, with a recorded duration |
| Review interval | When the delegation lapses unless renewed | The last renewal has a date and a signature |
Three tests apply it. The artefact test: for your three most consequential automated decisions, can you produce the document that authorised them and the name on it? The override test: what share of proposed actions does a human alter, and is anyone examining the alterations? A rate near zero is a finding, not a reassurance. The revocation drill: switch one delegation off in a controlled window and measure what it costs and how long it takes.
From Strategy to Execution
Immediately, run the census from what happens rather than from the systems inventory. Ask each operating leader which decisions in their area now proceed without a person confirming them, then ask the platform owners the same question. The gap between the two lists is the finding, and usually the most useful hour a leadership team spends on the subject.
Over the next two or three quarters, make a change of rung a governed event: any reduction in the level of human confirmation requires written authorisation, before it takes effect, from the named officer for that decision class. Instrument override rates and exception-queue ageing as standing management information rather than project metrics. Appoint officers where there are none, and expect several appointments to be contested — that contest is the work.
Over years, the harder exposure is external. A vendor release can climb a rung on your behalf, documented in a note that reaches an administrator and never an executive, and the enterprise will have altered a delegation without deciding anything. Contracts need a notification obligation for changes to automation defaults and thresholds, and someone accountable for reading them. The end state is one schedule covering human and machine delegates alike, reviewed by the same committee to the same standard of evidence.
Signals to Monitor
- Override rate trending towards zero on any decision where a human review is claimed as a control.
- Exception queues ageing, or exception reports distributed to a list nobody has revised in a year.
- Decision volume growing faster than review capacity, which converts a real control into a nominal one with nothing having been decided.
- Supplier release notes altering defaults or thresholds, and whether anyone senior reads them.
- Time since the last revocation drill, and whether the recorded duration is a measurement or an estimate.
- Near-zero appeal or complaint volumes from a large affected population, which is more often evidence of a missing channel than of correctness.
Questions for the Leadership Team
- Which three decisions in this business now proceed without a person confirming them, and who authorised each?
- For our most consequential automated decision, how long would a systematic error run before we detected it — measured, not estimated?
- Where we claim a human is in the loop, what share of proposals does that person change, and who reviews the changes?
- If we had to withdraw a delegation this week, who would do it, how long would it take, and what happens to the work in flight?
- Which automated decisions affect people who have no practical way to object, and what have we put in place instead?
Closing Perspective
There are two ways an enterprise ends up with machine agents acting on its behalf. It authorises them deliberately, in advance, with bounds and a name attached. Or it ratifies them retrospectively, usually in the week after an incident, when the authorisation is drafted by lawyers and the bounds are set by whoever is angriest.
The second route is not merely more expensive. It concedes the ability to say what the organisation intended. An enterprise that can produce the artefact can defend the decision, adjust it, or reverse it. One that cannot is left arguing that nobody chose this — which is true, and is exactly the problem.
The question is not whether machines should decide. In every organisation of scale, some already do. The question is whether the leadership can name what it has conceded, and whether it would concede it again on purpose.
About the author
Kevin Jogin is Founder & Principal Advisor at EraNorth. Meet the Founder.