Governing AI decisions in retail and e-commerce: who may decide what, inside which bounds

Stage 1 is rarely a stage of inaction. Almost every retailer at this stage is already taking thousands of consequential automated decisions a day — they simply arrived with the software rather than through a decision to make them. The payment service provider ships fraud rules pre-configured. The returns platform ships an abuse score with a default action. The marketplace console ships listing filters that suppress and suspend. Nobody signed anything, and yet the estate refuses orders, refuses refunds, demotes listings and restricts accounts every hour of the trading day.

The tell is the checkout error. Ask what a customer sees when a card-not-present order is declined by the fraud model, and at stage 1 the honest answer is a generic message — 'something went wrong, please try another payment method' — chosen by whoever built the checkout, not by anyone who understood what the message was hiding. The decision was real, the consequence was real, and the person on the other end got no reason, no route and no record.

This stage is cheap to leave and expensive to sit in, and the expense is asymmetric. Nothing bad happens on most days. Then one decision class goes wrong at volume — a threshold change during peak, a vendor model update, a new market with address formats the model has never seen — and there is no register to consult, no owner to call, no bound that was breached and no log to reconstruct. The investigation starts by trying to work out which system made the decision, which is a week nobody has.

Stage 2 is where most retail and e-commerce estates sit, and it is a genuine achievement misread as a finished one. The register is real: someone walked the estate, found the decisions, wrote them down and put a name against each. It usually surfaces two or three decisions nobody knew existed — a dormant account-closure rule, an automatic seller warning, a price-match suppression — and that alone repays the fortnight it took.

What the register does not contain is authority. It says the returns-abuse model exists and that the returns operations manager owns it. It does not say whether that model may refuse a refund by itself, up to what order value, for which customer segments, in which markets, or what happens to the case that falls outside those limits. Authority is still whatever the vendor shipped, which means the estate's real behaviour is set by release notes rather than by anybody's decision.

The failure mode of stage 2 is slow and quiet: the document and the console diverge. Every vendor release, every threshold tweak made during a bad fraud week, every new market that inherits a default moves the live estate further from the written one. Because the register is reviewed on a governance calendar and the console changes on an engineering one, the gap is only ever discovered by an incident or an audit. Operators who have sat at stage 2 for two years typically have a register that is accurate about which decisions exist and wrong about nearly every threshold in it.

Stage 3 is the move from paper to path. The authority class — assist, bounded automatic, notified automatic, human-only — stops being a description and becomes a gate: the code that writes the hold, the refusal or the suspension first checks the bound, and an action outside it cannot execute. It queues. That single architectural change converts governance from an assertion into a property of the system, and it is the reason stage 3 survives staff turnover, vendor migrations and bad weeks in a way stage 2 never does.

The second thing that changes is what a threshold is. At stage 2 a threshold is configuration; at stage 3 it is a versioned artefact with an owner, a change history and a review — treated with the same seriousness as the model. This is where the operators who have imported software-engineering discipline pull away: they already know how to review a change, roll one back and tell you who approved it on which date, and they simply extend that machinery to decision bounds. Teams that keep bounds in a spreadsheet next to the console rediscover, expensively, why version control exists.

What stage 3 still does not have is the person on the other end. A bounded decision can be entirely defensible internally and still land on a customer as a silent refusal, on a seller as a listing that vanished, on a colleague as a shift that changed. The action was authorised, limited and logged — and the human affected by it received no reason and has no route back. That gap is what stage 4 exists to close, and it is also where most regulatory exposure in retail actually sits.

Stage 4 looks like a policy achievement and is almost entirely an engineering one. Contestability requires four things that rarely exist together: a record complete enough to reconstruct the decision months later, a reviewer with real authority to reverse it, a reversal action that actually exists in the system, and a clock that starts when the person asks. Retailers routinely have the first and the third and believe they have all four, because they have an inbox. An inbox is intake, not contestability.

The most underrated consequence of reaching stage 4 is the data. Upheld contests are labelled errors — cases where the automated decision was wrong, identified by the person best placed to know, at no acquisition cost to you. No offline evaluation produces a comparable signal, because upheld contests are drawn precisely from the tail the model handles worst. Operators who plumb the upheld set back into the bound and the model close the loop that every governance framework describes abstractly; operators who file them as complaints have a customer-service metric and no learning.

The discipline that fails first here is reviewer authority. It is easy to staff an appeals function and hard to give it a reverse button, because the original action was often executed by a pipeline that only runs forwards — a suspension writes a flag, a decline writes a status, and there is no supported path to unwrite either. Reviewers then 'recommend' reinstatement, an engineer runs a manual fix days later, and the published clock quietly becomes fiction. Build the reversal action at the same time as the action itself, or the appeals team is a complaints desk with a better name.

Stage 5 is narrower and less exciting than the word suggests, and it is emphatically not more autonomy. It is the opposite: an estate that continuously proves what its automation did. The decision record, the bound-breach log, the override and upheld-contest rates are produced as a matter of course, in a form a regulator, an auditor, a marketplace partner or a large customer can be handed. The characteristic experience of a stage-5 operator during an information request is a query rather than a programme.

The operating signal is the bound-review trigger. Override rate, upheld-contest share and attempted bound breaches are watched as leading indicators, keyed to the events that actually change the input distribution in retail: a market launch, a category expansion, a payment-provider migration, a peak trading week. When one of them moves, a bound review is raised automatically. This is where the discipline pays for itself, because a bound set under last year's conditions is not wrong on the day the conditions change — it is wrong quietly, for weeks, until someone complains loudly enough to be heard.

Stage 5 is also the stage most likely to regress, and the regression is always structural rather than negligent. A platform migration moves a decision out of the path where the bound was enforced. A newly acquired brand arrives with its own console and its own defaults. A vendor consolidates two decisions into one product feature. None of these looks like a governance event and all of them invalidate a bound. Maturity here is not the absence of regression; it is detecting it in days, from your own telemetry, before the people affected have to tell you.