Monitoring and Governing Ecommerce AI

Foundation · 6 min

What you will learn

Why most stores have more AI running than they think
The seven things to record about each use, and the field everyone skips
What to monitor, and why uptime is the wrong number
How to handle changes you did not make

Nobody decided to deploy AI, which is the problem

It arrives feature by feature. A support tool adds reply drafting. A marketing app adds subject-line generation. A search provider turns on semantic matching. None of it looked like an AI decision at the time, so none of it got an AI review.

So no one owns it. Each feature was switched on by whoever was using that tool that week. When something goes wrong, the first hour goes on working out which system produced the output, and sometimes that is the whole incident.

A list beats a policy. For most stores, the entire gap between no governance and adequate governance is a spreadsheet with seven columns and a name in each row. The policy document can wait, probably forever.

What to record about each use

Record this	Because
What it does, in one line	If nobody can state it plainly, nobody can judge whether it is working
Who owns it	One named person, not a team. This is the field most often left blank
Where it came from	The provider or app, so you know whose change notice to read
What data it reads	Decides your privacy exposure and what breaks when a field changes
What it is allowed to do	Draft, recommend or act. The difference governs everything else
Who sees its output	Internal only, or customers. Customer-facing raises every threshold
What happens if it stops	The fallback. If there is none, that is the finding, not the feature

The owner field is the one most often left blank, and it is the one that makes the rest work. Put the name of the person who owns the area the feature touches, not the person who installed it.

Classify by what happens when it is wrong

Controls should follow consequence rather than apply evenly. Copy a person approves before publication needs editorial review and nothing else. Advice a shopper acts on needs accuracy monitoring and an escalation path. Anything that changes price, stock, an order or an account needs permissions, thresholds, logging and reconciliation.

When the risk of a use exceeds the controls you can realistically run, the answer is to narrow its scope or switch it off, not to accept it and hope. That is a legitimate governance outcome and the one teams avoid stating.

Decide what passing looks like before launch

Write the thresholds down first: factual accuracy against the source, task completion, outputs that are never acceptable, response time, cost per use and the business number the feature is supposed to move. Then test against the awkward cases rather than the demo, because the demo was chosen to work.

If you cannot say what would make you turn the feature off, you have not finished this step. A launch with no stop condition is a launch nobody can reverse without an argument.

Monitor outcomes, not uptime

Technical dashboards will show an AI feature as healthy while it gives poor advice all day. Watch the things customers feel: unsupported or wrong answers, failed actions, how often staff override it, escalations, complaints, and the conversion or resolution number it was meant to improve. Add cost, which tends to drift upward unnoticed.

Sampling real conversations is the most useful review anyone does, and it needs a documented process and the same restraint on personal data you apply everywhere else. Read twenty, not two thousand, and read the ones that ended badly.

Control changes, and keep an exit

Four things change behavior without anyone touching the feature: the model, the prompt, the retrieval setup and your own catalog. Record the versions that matter and re-run your tests after any of the four moves. The catalog is the one teams forget, because adding products does not feel like a change to the AI.

Keep the ability to disable the feature without a release or a vendor ticket, and make sure the store behaves sensibly with it off. A feature that cannot be switched off quickly will stay on through the incident that should have ended it.

Key takeaways

Most stores already run AI they never reviewed. Start with the list, not the policy.
One named owner per use, from the area it touches rather than whoever installed it.
Scale controls to consequence. Drafting is a line in a list. Moving money is not.
Agree the pass thresholds and the stop condition before launch.
Watch outcomes rather than uptime, and re-test when the model, prompt, retrieval or catalog changes.