打造零售 AI Copilot 前，先訂立權威資料來源契約

A retail AI copilot rarely fails because it cannot write a sentence.

It fails because somebody asks a deceptively ordinary question — “Can I collect this today?”, “Does this offer apply to me?”, “Can I return it after opening it?” — and the answer arrives with all the confidence of a person who has never had to apologise at a service desk.

The model is only the visible part of the system. The difficult part is deciding which information it may use, who owns that information and what should happen when the information is incomplete.

Before building a retail copilot, write a source-of-truth contract.

Not a forty-page governance document. One page is enough for a pilot. It should be clear enough that an engineer, a store manager and a customer-service lead can all tell when the tool is helping and when it should hand off.

The contract begins with a question, not a model

Pick one decision that happens often enough to matter and is narrow enough to test. For example:

“Help a store colleague compare two items for a customer without promising stock, price or policy terms that have not been verified.”

This is much better than “build a product adviser.” The first statement gives you boundaries. The second one gives you a project that will slowly collect every unresolved business question in the company.

For each answer the tool gives, define four fields.

Field	Question to settle
Source	Which approved system or document provides the fact?
Freshness	How old may that fact be before the answer must qualify itself?
Owner	Who can correct the source or the rule?
Handoff	What does the colleague do when the fact is missing, contradictory or sensitive?

The table looks simple because it is. Simplicity is a feature when the customer is standing in front of somebody who has thirty seconds to decide whether an answer is safe to say aloud.

Inventory is not one number

Developers are often handed a request such as “connect the copilot to inventory.” That sounds precise until the first integration meeting.

Inventory can mean stock in a warehouse, stock on a shelf, stock reserved for another customer, stock allocated to an order, stock awaiting a return inspection or a number that last updated forty minutes ago. Shopify documents several separate inventory states, including on hand, available, committed and reserved. Those distinctions are not implementation trivia. They decide whether a colleague can make a customer promise.

A good copilot does not flatten that uncertainty into “yes, it is available.” It might say:

“This item appears available online. I cannot confirm same-day collection from this store yet. Here is the next check.”

That answer may feel less magical. It is more useful because it leaves the customer with a truthful next step instead of a future frustration.

Make the system show its work

The user interface does not need to expose a prompt trace. It should, however, make the operational basis of an answer easy to inspect.

For a pilot, show a compact source label such as:

Product specification — catalogue record, updated today
Offer terms — promotion system, expires 23:59
Store availability — unconfirmed; check store system

The label helps the colleague use judgement without turning them into a data engineer. It also gives the implementation team better bug reports. “The bot was wrong” is vague. “The offer source was two campaigns behind” is fixable.

Treat a safe refusal as a product feature

Every pilot should have a small set of answers it will not improvise: medical or legal product claims, privacy-sensitive account details, an exception to a returns policy, a live stock promise without the right source, or a decision that requires an authorised manager.

The fallback should not be a dead end. “I cannot help with that” is technically safe and commercially useless. A useful fallback says what can be checked, who owns the decision and what information is needed next.

NIST's AI Risk Management Framework describes the lifecycle in terms of governing, mapping, measuring and managing risk. In retail, those words become very practical. Who owns the product fact? Can a colleague see when the answer has exceeded its evidence? How do we log a bad promise? Who changes the process after the log identifies a pattern?

Build the log before the dashboard

For the first few weeks, an exception log is more valuable than a glossy analytics screen. Record cases where the tool:

used an outdated source;
made a claim that needed correction;
could not answer but found a good handoff;
sent a colleague on a longer path than the existing process;
exposed a missing policy or unclear ownership.

Review the log with the people who can change the catalogue, offer, policy or workflow. If the same exception returns every week, prompt tuning is unlikely to be the real fix.

The best early retail AI product may be a modest one: a tool that helps somebody locate a verified answer faster and knows when it does not have one. That is not a compromise. It is the beginning of a system customers can trust.

Sources: NIST AI Risk Management Framework and Shopify inventory states.

Author: Kirill Naumov is a consultant and entrepreneur with 16 years of experience across retail, construction and hospitality, including 11 years with Apple and seven years teaching MBA participants. Further information.