AI loss prevention needs an assistant, not just a detector

There is an arms race in retail security, and it is being run almost entirely on one axis. Vendor after vendor competes on whose camera-side model can spot a concealment, a grab-and-run, or a face on a watchlist a little more reliably than the last release. That work matters, and we do it too. But if you are a loss-prevention lead, you have probably noticed that a better detector does not give you a quieter day. It gives you more alerts. Alert fatigue is the real condition of the job, and a more sensitive camera makes it worse before it makes it better.

So I want to make an argument that runs against the grain of most AI loss prevention marketing. The detector is not where most of your team's time is won or lost. The operator is. And the most useful place to put the next pound of AI is not on the glass, watching the shop floor, but behind the glass, sitting next to the person who has to make sense of what the cameras produce.

There are two places to put AI in a security stack

It helps to be explicit about this, because the two are usually collapsed into one word. When a vendor says they "use AI", they almost always mean the first one.

• Camera-side AI: the detector. It watches CCTV, classifies behaviour, matches faces against a banned-persons list, and raises an alert. This is the part everyone competes on. It is genuinely hard and genuinely valuable, and it is also the part that, on its own, generates work.
• Operator-side AI: the assistant. It does not watch anything. It sits with the human who reviews alerts, manages the watchlist, configures zones, and writes up incidents. It reads structured data from the platform, drafts the boring artefacts, and answers questions about the estate.

The industry has poured almost all of its attention into the first and almost none into the second. That is backwards. A hard-won improvement in detector recall is easy to erode with a few extra false alarms. A good operator-side assistant changes the shape of the working day, and it does so without touching a single model weight on the camera.

The operator, not the camera, is the bottleneck

Walk through what happens after a detection. A clip is flagged. Someone has to open it, decide whether it is real, check whether this face has been seen before and where, look at the audit trail, and then either reject it as a false alarm or take it forward. If it is real and serious, someone has to put together an evidence write-up: the face, the clip, the audit chain, the prior events, in a form a police officer or a court will accept. None of that is detection. All of it is operator work, and it is the part that does not scale.

Add more cameras and a better model on top, and the detection side scales fine. The review side does not. You cannot hire your way out of a large increase in alerts, and you should not want to, because most of those alerts will be noise. The constraint on a loss-prevention team is not how many things the cameras can spot. It is how many things a human can sensibly act on in a shift. That constraint lives entirely on the operator's side, which is exactly where the second AI belongs.

What "drafting a rule" actually looks like

Let me make the operator-side idea concrete, because it is easy to wave at and hard to pin down. We built an in-product assistant called Alex. It is not a free-text chatbot bolted onto a help page. It is a conversational layer that calls real platform endpoints, the same APIs the dashboard uses, and it can only do what those APIs allow for the signed-in user. We have mapped thirty retailer intents to it; sixteen are live today and the rest are on the roadmap.

One of those intents is turning a sentence into a zone rule. A store manager can type "alert me if more than eight people queue at the kiosk", or "arm the after-hours guard from 9pm". Alex drafts the rule: the zone, the rule type, the threshold. What it does next is the important part. It does not switch the rule on. It hands a draft to the dashboard, and a human reviews the polygon and the threshold and activates it. The AI did the tedious translation from English into configuration. The person made the decision.

The same shape applies across the rest of what Alex does. Ask it what happened overnight and it pulls the pending theft events and walks you through them. Ask for the audit chain on an incident and it surfaces the append-only trail, cross-referenced with the face graph and prior events. Ask for footfall today versus yesterday, or the false-alarm rate this week, and it answers from the platform rather than from a dashboard you would otherwise have to assemble yourself. The morning brief becomes a conversation instead of a half-hour of clicking.

It also drafts the artefacts nobody enjoys writing. Alex can draft a police report, the face, the clip, the audit chain and the prior events, in one place, ready for a human to check and finalise. It can pin an audit-logged note to an event or an individual. These are not flashy capabilities. They are precisely the time-consuming, error-prone tasks that sit between a real detection and a usable outcome, and they are where an operator-side AI earns its place.

Where the line has to sit

An operator-side assistant is only safe if the boundary is drawn in exactly one place and never moved: the AI drafts and surfaces, the human confirms and activates. That is not a slogan, it is how the thing is built. Every action that writes something requires an inline confirmation step: marking a theft confirmed, rejecting a false alarm, approving a confirmed theft for a police report, toggling a rule. Every one of those calls is gated server-side by role. Only a QEAdministrator can approve a consequential action. Alex asking is not Alex doing.

There are a few more guardrails worth naming, because they are the difference between a responsible assistant and a reckless one.

• No PII enters the model. Face vectors, ethnicity codes and raw video never go into the prompt context. Alex sees structured tool results, not embeddings and not footage.
• The model provider is a disclosed sub-processor. A tenant whose data protection agreement forbids it can disable Alex entirely, and the rest of the platform carries on without it.
• Same audit chain as the UI. An action initiated through Alex is indistinguishable in the append-only log from one done in the dashboard, and just as provable later.
• Graceful failure. If a tool errors or returns nothing, Alex tells you that, rather than inventing a confident answer to fill the silence.

Why operator-side AI is safer, not riskier, than autonomous action

There is a reflex that says any AI that can take an action is more dangerous than one that cannot. I understand it, but I think it gets the risk backwards. The dangerous design is the one that lets a model change a record or flag a person without a human in the path. An assistant that drafts a rule and waits, or proposes a status change and waits, has a human checkpoint on every consequential step by construction. The blast radius of a mistake is a draft someone declines, not a status change already committed.

It is also safer because it does not expand what the platform can do, it expands who can ask the platform to do it, within the same permissions. Alex cannot reach past the RBAC rules. It cannot see PII the rest of the system keeps out of reach. It cannot leave a fainter trace in the audit log. Everything it touches is already governed; it just makes the governed surface easier to operate. Compare that with a system trusted to commit a judgement about a real person on its own, every time, with no one looking. One of these is a sensible use of AI in retail loss prevention. The other is a headline waiting to happen.

What we would tell a loss-prevention lead evaluating an AI assistant

If you are weighing up an AI assistant for your security stack, the detector demos will look impressive and tell you very little about whether the thing is safe or useful in your estate. These are the questions we would ask in your position.

1. Can the assistant take an action on its own, or does every write require a human confirmation? If it can act unattended, walk away.
2. Does it call your real platform APIs under the same permissions as the UI, or is it a separate path that could drift from your access controls?
3. What enters the model context? Insist that face vectors, ethnicity codes and raw video stay out of the prompt, and ask to see how that is enforced.
4. Is the model provider a disclosed sub-processor in your DPA, and can you disable the assistant entirely if compliance requires it?
5. Does an assistant-initiated action land in the same append-only audit log as a UI action, with the same provability?
6. When a query fails or returns nothing, does it say so, or does it fabricate an answer? Ask for a live demo of the failure case, not just the happy path.
7. Which intents are actually live today versus on a roadmap? A mapped intent is not a shipped one. Get the real number.

If a vendor cannot answer those crisply, the assistant is either immature or designed without the line in the right place. Either way you will find out in production, which is the worst possible place to find out.

The detector arms race will carry on, and we will keep competing in it. But the next real gain for a loss-prevention team is not another point of recall. It is a second AI on the operator's side that drafts the rule, answers the question, and drafts the evidence, then stops and waits for a human to decide. That is the honest way for loss-prevention tools to use more AI. On your side of the glass, never on the enforcement side.