Pre-deployment checks for pricing, promotion and supply-chain AI

# Pre-deployment checks for pricing, promotion and supply-chain AI

At 6am, three weeks before a major retailer's category review, a beverage company's pricing algorithm proposes a 4% price cut on a flagship SKU across 2,000 stores. Nobody signed off on it. The model saw a demand dip, extrapolated from a promotion two months earlier, and moved. Because the company runs a pre-launch checklist with a mandatory human override gate, a category manager catches it before it reaches the retailer's system. Without that gate, the price change would have gone live automatically.

This is the discipline this lesson covers: the concrete checks FMCG (fast-moving consumer goods) companies run before pricing, promotion or supply-chain AI touches real transactions.

Why pre-deployment checks matter specifically in FMCG

FMCG pricing and promotion AI operates at a scale where small errors multiply fast. A single mispriced SKU can propagate across thousands of stores within hours through automated retailer feeds. Promotion engines that mis-forecast uplift can trigger stockouts or write-offs across an entire category. Supply-chain AI that misreads a demand signal can idle a production line or overstock a warehouse.

Unlike a one-off marketing mistake, these are automated, repeatable, and often invisible until the invoice or the shelf tells you something went wrong.

Model risk: what can actually go wrong

Model risk is the risk that a model is wrong, misused, or poorly understood, and that this causes financial or reputational harm. In FMCG AI, four failure modes recur:

Data lineage failures. Data lineageData lineageData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.Voir la définition complète → is the traceable path data takes from source to model input. If a pricing model ingests promotional data that double-counts a discount (say, a retailer's own markdown stacked on top of a manufacturer rebate), the model learns a distorted price elasticityprice elasticityHow sensitive demand is to a price change. High elasticity means customers react strongly to price increases.Voir la définition complète → and recommends prices based on a fiction.

Distribution shift. A demand-forecasting model trained on 2023-2024 data may not handle a genuine shock (a competitor's aggressive promotion, an input-cost spike, a geopolitical disruption to a co-packer). The model keeps producing confident forecasts that are quietly wrong.

Feedback loops. Pricing algorithms that both influence and observe the market can reinforce their own errors. If the model cuts price, sees volume rise, and treats that as confirmation of correct elasticity, it may keep cutting price past the profitable point.

Automation bias. Category managers or supply planners start trusting the model's output by default, even when it contradicts obvious ground truth (a known supply disruption, a competitor stockout). This is a human governance failure, not a technical one, and it is one of the most common root causes of AI incidents in retail and CPG.

The core checklist: four pillars

1. Data lineageData lineageData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.Voir la définition complète → checks

Before any model goes live, trace every input field back to its source system. For a pricing model this typically means: point-of-sale (POS) feeds, retailer scorecard data, promotional calendars, cost inputs (commodity, freight, packaging), and competitor price scrapes.

Concrete check: reconcile a sample of model inputs against the source system for a fixed period (commonly 4 to 8 weeks) and flag any discrepancy above a defined tolerance (commonly 1 to 2%). If lineage cannot be verified, the model does not launch, regardless of how good its backtest looks.

2. Shadow testing

Shadow testing means running the model in parallel with existing decision processes, without letting its output act on the real world, and comparing results. A pricing algorithm might run in shadow mode for 8 to 12 weeks alongside the incumbent process (human pricing team or legacy rules engine), with every recommendation logged but not executed.

This surfaces two things: how often the model would have deviated from what humans actually did, and whether those deviations would have been profitable or damaging. Shadow testing is the single most effective way to catch a model's blind spots before they cost real margin.

3. Override rights

Override rights are the formal, documented authority for a named human role to reject, modify, or pause a model's output before it executes. In pricing, this usually sits with a category or revenue management lead. In supply-chain AI, it typically sits with a planning manager.

Two design details matter:

• Thresholds. Define in advance which recommendations require mandatory human sign-off (for example, any price move above 3%, any promotion depth above historical maximum, any production plan change above a defined volume threshold).
• Friction, not paralysis. Override should be fast (minutes, not days) or people will bypass it under deadline pressure.

4. Kill switches

A kill switch is a pre-built, tested mechanism to immediately halt a model's live outputs and revert to a fallback process (manual rules, previous model version, or human decision-making). This is distinct from override: override stops one recommendation, a kill switch stops the whole system.

Kill switches need to be tested before go-live, not designed and left untested. A company that built a kill switch for its trade promotion optimization model but never rehearsed triggering it discovered, during an actual pricing anomaly, that the switch depended on a system that was itself down. The fallback failed because it had never been drilled.

A simple worked example: setting a shadow-test tolerance

Say a beverage company shadow-tests a promotion-uplift model against its incumbent forecasting method for 10 weeks across 50 SKUs.

• Incumbent method average forecast error (mean absolute percentage error, MAPE): 18% (estimate, typical range cited in CPG demand planning literature)
• New model's shadow MAPE: 13%

That is a meaningful improvement, but the check is not just the average. The company also looks at the worst-case SKUs: if the new model's error exceeds 30% on more than 5% of SKU-weeks, that triggers a mandatory review of those specific product categories before full rollout, even though the average looks good. Aggregate performance can hide category-specific blind spots (seasonal items, new launches with thin history).

Regulatory and governance context

There is no FMCG-specific AI law yet, but two frameworks shape governance obligations for pricing and supply-chain AI operating in relevant markets:

• The EU AI Act (entered into force 2024, obligations phasing in through 2026-2027) classifies AI systems by risk tier. Most FMCG pricing and supply-chain tools fall into the "limited risk" or unregulated tier, but companies using AI for consumer-facing decisions should monitor how "high-risk" classifications evolve, and transparency obligations apply broadly. See the European Commission's AI Act overview for the current state.
• Competition law (enforced in the EU by the European Commission, in the US by the FTC and DOJ) is the sharper near-term risk. Algorithmic pricingAlgorithmic pricingAutomatically adjusting prices in real time based on demand, competition or user behaviour to optimise revenue, margin or conversion.Voir la définition complète → that leads to tacit coordination between competitors, even unintentionally, has drawn regulatory scrutiny in multiple sectors. The OECD's work on algorithmic collusion is a good primer on this risk.

Internal governance (model risk committees, documented sign-off chains) is currently doing more work than external regulation for most FMCG AI deployments, which is exactly why the pre-deployment checklist matters.

Building the checklist into a real launch gate

A practical governance structure ties these four pillars to a go/no-go gate, reviewed by a cross-functional group (data science, category management, legal/compliance, IT security) before any model touches live retailer or supply-chain systems:

LAUNCH GATE CHECKLIST (pricing AI, example)
[ ] Data lineage verified against source systems (tolerance: <2% discrepancy)
[ ] Shadow test completed (minimum 8 weeks, documented MAPE vs incumbent)
[ ] Override thresholds defined and assigned to named roles
[ ] Kill switch built AND tested (simulated trigger within last 30 days)
[ ] Bias/fairness check on any consumer-facing pricing logic
[ ] Sign-off: data science lead, category lead, compliance

No single check is sufficient alone. A model can pass shadow testing beautifully and still fail in production if the kill switch was never tested, or if override thresholds are set so high nobody ever intervenes.

🎬 [VIDEO: "How AI is Changing Retail Pricing" - youtube.com/@McKinsey - a McKinsey discussion of dynamic pricingdynamic pricingAutomatically adjusting prices in real time based on demand, competition or user behaviour to optimise revenue, margin or conversion.Voir la définition complète → algorithms in retail, useful context for how pricing AI decisions get made and governed]

Key Takeaways

• Pre-deployment checks exist because FMCG pricing, promotion and supply-chain AI acts at scale and speed: a bad model can move prices across thousands of stores before a human notices.