# The pre-deployment checklist for retail AI
It's 6am on launch day. A national apparel retailer is one sign-off away from switching on an AI chatbot that will handle returns and price-match requests for millions of customers. The bot can approve refunds, issue store credit, and match competitor prices, all without a human in the loop. Then someone on the legal team asks a simple question: "What happens when it gets one wrong, at scale, before lunch?"
Nobody has a good answer. The launch gets delayed 48 hours.
That delay is the cheapest insurance the retailer will ever buy. This lesson builds the checklist that should exist before any customer-facing or money-touching retail AI system goes live.
Retailers often treat customer service bots as "low stakes" because no single transaction is large. That's a mistake. Three features make these systems riskier than they look:
This is why regulators increasingly treat automated decision systems that affect consumers' money as higher-risk, even when the underlying model is "just" a language model. In the EU, the AI Act
Before launch, demand that every automated decision (approve refund, deny price-match, escalate to human) produces a decision log: what data the model saw, what rule or model output triggered the outcome, and a plain-language reason a customer service rep could read aloud.
This isn't optional politeness. It's what lets you answer a chargeback dispute, a regulator inquiry, or a customer complaint without saying "the AI decided, we don't know why."
Concrete test before go-live: pull 20 random transcripts and ask the vendor to produce, within one business day, a written explanation of each decision. If they can't, you don't have explainability, you have a black box with a nice UI.
MapMapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Voir la définition complète → every decision the bot can make, then draw a hard line: which ones can it finalize alone, and which ones must route to a human before anything happens?
A reasonable baseline for a returns/price-match bot:
| Decision type | Autonomous OK? | Why |
|---|---|---|
| Refund under a low fixed threshold (e.g., under $50) for a standard return | Yes, with logging | Low financial exposure, high volume, well-defined policy |
| Refund above threshold, or repeat requests from same customer | No, human review | Fraud pattern risk, higher exposure |
| Price-match against a competitor's advertised price | Yes, if price is verified via approved data feed | Objective, verifiable input |
| Price-match based on customer's unverifiable claim ("I saw it cheaper somewhere") | No, human review | High dispute and fraud risk |
| Any request involving abusive language, self-harm mentions, or legal threats | No, immediate human handoff | Outside model's competence, reputational and duty-of-care risk |
The point isn't the exact thresholds, it's that thresholds exist, are written down, and are tested before launch, not discovered after a viral complaint.
Every retailer needs an incident response plan specific to the AI system, not a generic IT outage plan. Ask before go-live:
A useful benchmark: financial services firms subject to model risk management guidance (see the US Federal Reserve's SR 11-7 framework, originally for banks but widely adopted as best practice) require ongoing monitoring and defined escalation triggers for any deployed model. Retail hasn't been forced into this yet by law in most jurisdictions, but the discipline transfers directly and cheaply.
Most retail AI chatbots run on a vendor's platform (built on top of a foundation model from OpenAI, Anthropic, Google, or similar). Before signing or renewing:
If a vendor won't put these in writing, that itself is the answer to whether you should launch.
Vérification des acquis
1. Why is a retail customer service bot that handles refunds considered higher-risk than a typical FAQ chatbot, even though no single transaction is large?
2. A retailer's legal team argues that a price-match bot should be treated like a 'low-stakes' system because each individual price adjustment is small. What is the strongest counterargument based on the lesson's framework?
3. What is the significance of the 48-hour launch delay described in the opening scenario?
4. Select ALL correct answers about the factors that make a retail AI system 'high-risk' according to the lesson.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers about how regulatory frameworks are treating consumer-facing AI systems that affect financial outcomes.
Sélectionnez toutes les réponses correctes.
Even non-technical governance teams can run this before signing off. It's not code the retailer needs to write, it's a test protocol to demand from the deployment team:
PRE-LAUNCH TEST SET (run against staging, not production)
1. Adversarial refund test:
- Submit 10 refund requests slightly above/below each threshold
- Confirm routing matches the policy table exactly
2. Price-match spoofing test:
- Submit a fake/unverifiable competitor price
- Confirm bot escalates to human, does not auto-approve
3. Explainability audit:
- Pull 20 random decisions
- Require plain-language rationale within 1 business day
4. Kill switch drill:
- Trigger the pause mechanism
- Time how long until all decisions route to humans (target: minutes, not hours)
5. Data residency check:
- Confirm where transcripts/PII are stored and for how longIf any of these five fail in staging, the system is not ready for production, full stop.
🎬 [VIDEO: "How AI Chatbots Are Regulated: A Business Guide" - youtube.com - search for recent explainer content from a reputable business or legal channel covering AI Act and FTC consumer protection basics as they apply to customer-facing bots]