AI that understands the catalogue and respects the order

Retail AI begins with a trustworthy catalogue

A retail assistant is useful when it helps someone choose an appropriate product and complete a task with confidence. That requires more than fluent conversation. It requires reliable attributes, a clear relationship between parent products and variants, current availability, and a route to staff when the evidence is incomplete. A founder deciding whether to add AI should begin with a specific operational problem: customers cannot find compatible products, staff repeat policy explanations, or merchants struggle to correct inconsistent catalogue fields.

A retailer with a small, well-organized catalogue may already have enough capability in filters, synonyms, and a conventional search engine. Inspect those options before introducing a model. AI becomes a candidate when users express requirements in language that does not map neatly to existing categories, or when staff need assistance combining multiple approved records. The first scope should name the task, the person who owns the outcome, the records used, and the actions that remain outside the assistant’s authority.

Product discovery needs evidence and constraints

Treat catalogue preparation as product work. Define which fields are authoritative for dimensions, material, size, compatibility, warranty, and care instructions. Separate supplier claims from merchant-approved attributes. Record the source and review status of enriched descriptions so staff can identify an incorrect claim later. A generated draft should enter a review queue instead of silently replacing published content. When source records conflict, preserve the disagreement for correction; a confident synthetic answer does not resolve the underlying data issue.

Conversational search should translate the shopper’s request into inspectable constraints. A request for a compact bag that fits a particular device might require dimensions, internal capacity, and compatibility evidence. Show the selected filters and candidate products rather than pretending that semantic similarity proves suitability. Exact identifiers, exclusions, price limits, and delivery regions should remain ordinary application rules. Give shoppers a way to correct the interpretation and return to an accessible results page without repeating the entire conversation.

Evaluate discovery with queries drawn from actual catalogue difficulties, suitably stripped of personal information. Include misspellings, multilingual phrases, conflicting requirements, empty results, unsupported compatibility claims, and items with missing attributes. Compare the assistant with the current search experience. A useful result set needs relevant products and correct explanations; a response that sounds helpful while omitting an exclusion is a failure. Preserve the evaluation examples so a later model or catalogue update can be compared against the same expectations.

Inventory promises and order changes belong to operational systems

Search indexes and embeddings can lag behind stock changes. Before an assistant describes an item as available for purchase, the application should consult the inventory source for the relevant warehouse, channel, and variant. Before committing an order, use the existing reservation and checkout workflow. Define what happens when the stock service is unavailable, two customers request the last item, or an update arrives late. The interface should explain that availability cannot be confirmed rather than using a stale answer as a promise.

Google’s Merchant API documentation separates submitted product inputs from processed product records and their status. That distinction is a useful reference when planning feed reconciliation: submission and downstream acceptance are different states. In your own integration, record the submitted change, processing outcome, and correction route. This does not establish real-time stock guarantees across every sales channel. Inventory freshness, feed processing, reservation behavior, and customer communication still need explicit ownership and checks appropriate to the systems involved.

Returns support is another place where assistance and authority should be separated. The assistant can locate an order after authentication, collect the stated return reason, summarize evidence, and retrieve the policy that applies to the purchase. It should not invent an exception, imply that a refund has settled, or change financial records through an unrestricted tool. Keep policy versions, approval thresholds, staff decisions, and payment outcomes visible. Customers need a direct escalation route when the automated explanation is incomplete or disputed.

Personalization is a product choice, not a default data entitlement

Define the signals a recommendation feature actually needs. A customer’s explicit size choice, current category, or session request may be sufficient. If longer-term behavior is proposed, document its purpose, collection method, access, retention, and configured consent requirements with qualified privacy review. Offer an understandable preference control and verify that the non-personalized experience remains usable. Do not infer sensitive traits simply because a model can produce a plausible segment. Merchandising goals and customer permissions should be considered together during design.

Human operations remain part of the product. Merchandisers need queues for rejected descriptions and missing attributes. Support staff need the evidence behind proposed answers. Platform operators need the ability to pause an integration when a supplier feed is wrong or a model change creates misleading recommendations. Assign each queue an owner and define the route for urgent corrections. Avoid measuring success only through reduced staff involvement; an increase in well-routed escalation may reveal previously hidden catalogue or policy problems.

Agree on acceptance before broad rollout

An initial release can cover one category, one language, or one staff workflow where evidence and ownership are clear. Review factual accuracy, relevance, task completion, latency, cost, and escalation behavior separately. Business outcomes need their own measurement design because promotions, seasonality, prices, and stock can change at the same time. Do not promise a conversion lift from a demonstration. A release decision should reflect observed performance, known limitations, and whether staff can recover safely when assistance is disabled.

NIST describes its AI Risk Management Framework as voluntary support for considering trustworthiness through AI design, use, and evaluation. We use that framing as a reason to discuss ownership and evidence throughout the workflow, not as a claim of certification. Bring a representative catalogue, integration list, return policy, and the task you want to improve to the scope discussion. AI integration may fit an established store; a marketplace platform requires separate attention to vendors, approvals, transaction administration, and tenant boundaries.