A global logistics company ran a demand forecasting pilot in 2023 using a gradient-boosted model trained on three years of shipment data. The pilot covered four trade lanes. Forecast accuracy improved by 23 percentage points over the statistical baseline. The chief supply chain officer declared it a success at the annual technology conference. Eighteen months later, the model is still running on four trade lanes. Nothing has been scaled.
This is not an unusual outcome. Across procurement, logistics, and inventory management, AI pilots demonstrate clear value and then stop. The diagnosis offered is usually technical: insufficient data, model drift, integration complexity. These are real issues, but they are rarely the primary cause of failure. The primary cause is that the pilot was designed to prove a hypothesis, not to build an operating capability — and those are structurally different things.
Why pilots work and production does not
A pilot is designed to succeed. It operates on a carefully scoped set of data that is cleaned for the purpose. It has a dedicated data scientist or vendor team providing intensive support. The success metric — usually forecast accuracy or cost reduction against a baseline — is chosen because it is measurable in the pilot window. The business case is clear and the stakeholders are engaged because the pilot is new.
Production is different. The data is not clean; it comes from multiple systems with inconsistent schemas, delayed updates, and missing fields. The dedicated support team has moved to the next pilot. The success metric in production needs to connect to a business outcome — inventory turns, service level, working capital — not a model metric. And the stakeholders are no longer engaged because the technology is no longer new.
The transition from pilot to production requires three things that pilots do not require: clean master data at scale, process redesign to incorporate AI outputs into decision-making workflows, and a clear ownership structure for the model's outputs once the implementation team has left.
Demand sensing versus demand forecasting: the critical distinction
Before discussing what production-grade AI deployment requires, it is worth establishing a distinction that is frequently confused in procurement and supply chain circles. Demand sensing and demand forecasting are not the same thing. They answer different questions, operate over different time horizons, and require different data inputs. Deploying one when you need the other produces confident wrong answers faster than manual methods.
Demand forecasting operates over medium to long time horizons — typically four to twenty-six weeks out. It uses historical sales data, promotional calendars, seasonal patterns, and macroeconomic indicators to project future demand at the SKU or product family level. It is the right tool for production planning, supplier capacity booking, and safety stock calculation. Its data requirement is primarily internal historical data and structured external signals.
Demand sensing operates over a short horizon — one to fourteen days. It uses real-time or near-real-time signals: point-of-sale data from retail channels, distributor sell-through data, web traffic, social sentiment, and weather data. It is the right tool for distribution centre replenishment, last-mile logistics optimisation, and promotional response. Its data requirement is external, granular, and time-sensitive — and most supply chain organisations do not have a reliable feed of that data.
"The organisations that get value from AI in supply chain are those that ask first: what decision does this model need to improve? That question determines the time horizon, the data requirement, and the integration architecture. The model architecture is the last thing to decide, not the first."
The practical implication is that many companies buying demand forecasting software actually have a demand sensing problem — their medium-term forecast is acceptable, but their short-term execution is chaotic because they cannot see real-time channel data. A better statistical model applied to weekly shipment data does not fix a sensing gap. It produces a more precise estimate of a number that is already wrong.
Data quality: the problem that precedes the model
In production AI deployments across supply chain, data quality problems account for more value destruction than model quality problems. The sequence in which organisations approach this is almost always inverted: they invest in selecting and configuring a model before they have established that the data feeding it is reliable.
The data requirements for production-grade AI in supply chain are specific. Demand forecasting models require a minimum of two to three years of demand history at the appropriate granularity — and that history needs to be demand history, not shipment history. These are frequently different: shipment history captures what was dispatched, which reflects supply constraints, stockouts, and order batching as much as it reflects true demand. Organisations that train demand models on shipment data train models to replicate historical supply patterns, not to predict future demand.
Master data — the definitions of products, customers, locations, and time periods that structure every transaction record — needs to be standardised before model training. A product that exists under three different SKU codes in three different systems, or a customer that appears under two different names after a business unit restructure, produces training data that will confuse any model.
In the Indian and GCC context, distribution complexity adds another layer. Supply chains serving fragmented retail — kirana stores in India, independent traders in the GCC — typically lack point-of-sale visibility. Demand is inferred from distributor orders, which are themselves batch-driven and forward-bought. AI models trained on distributor order patterns effectively forecast distributor purchasing behaviour, which is a noisy proxy for actual consumer demand.
Process redesign before automation
The most common mistake in supply chain AI deployment is automating an existing process without first asking whether the process itself is correct. If the demand planning process produces a consensus forecast through a series of committee meetings in which the sales team's number is adjusted upward and the operations team's number is adjusted downward until a political compromise is reached, then automating that process produces a faster political compromise — not a better forecast.
Production-grade AI deployment requires a clear decision about what the model's output is supposed to replace. If the model produces a baseline forecast, who adjusts it, by how much, based on what criteria, and with what accountability for the adjustment? If the model recommends a procurement quantity, who approves it, what is the override threshold, and what happens to overrides in model retraining?
These are not technology questions. They are process and governance questions, and they need to be answered before the model goes live — not discovered in the first month of operation when planners are adjusting model outputs by forty percent because they do not trust them.
Ownership after implementation
The final structural gap between pilot and production is ownership. In a pilot, the technology vendor or the internal data science team owns the model. They monitor it, retrain it when accuracy degrades, and handle integration issues. When the pilot ends, that ownership needs to transfer to a business team — but the business team has rarely been prepared for model ownership.
Production AI in supply chain requires a model owner who understands what inputs the model uses, what signals indicate model drift, how to interpret accuracy metrics, and when to escalate a technical issue versus when to adjust a business parameter. This person is not a data scientist. They are a supply chain professional with sufficient technical literacy to distinguish between a model problem and a data problem.
Building that capability takes longer than building the model. Organisations that treat it as a training exercise at go-live — rather than as a capability that needs to be developed throughout the pilot phase — end up with production models that degrade quietly over six to twelve months and are eventually switched off by planners who have lost confidence in the outputs.