Why Industrial AI That Works at One Plant Breaks at the Twentieth

On October 29, 2026, IIoT World published a summary of a panel at the Industrial AI Summit 2026 on a familiar problem: an AI project that works at one plant breaks when it is replicated across twenty. The panelists were Gaspard Duthilleul (Galyos), Sanjay Mahato (AWS), Ian Clark (InfluxData) and Tauseef Ahmed (Grayhawk Consulting Group).

A caveat: the article is labeled "Sponsored by InfluxData | Editorially Independent", and Ian Clark of InfluxData was among the speakers. It is therefore fair to expect a technology vendor's perspective, even though the content reflects real problems from the field.

Where scalability breaks down

A pilot works because its scope is narrow: one line, one team, well-known data. Extending it to twenty sites strains several things at once:

• Tag names that diverge: "compressor one" can mean different things at different sites.
• Clock drift between sources, which introduces timestamp errors into training data.
• Different data ownership and different definitions of "quality data" from site to site.
• Manual corrections and custom connectors built for a single site, which turn into technical debt.

There is also an economic angle. With traditional historian licensing based on tag count, cost grows with every sensor added, while AI models tend to perform better with more connected sensors. The economics, in short, work against scale.

Five requirements for an "AI-ready" data foundation

According to the panel, the data foundation must offer:

• durability with store-and-forward for network outages;
• nanosecond timestamp precision;
• open standards, to avoid vendor lock-in;
• support for both training and inference;
• a semantic layer that enforces consistent meaning across sites.

Context matters more than volume

According to the panel, manufacturers already have plenty of data; what is missing is context: asset identity, product being run, operating conditions, maintenance history and quality outcomes. Resolution matters too. Dashboards typically sample every 1-5 seconds, while anomaly detection models often need kilohertz-level signals: training them on dashboard-resolution data smooths out the very phenomena they are meant to detect.

The Volkswagen example

As reported, Volkswagen's Digital Production Platform covers 43 plants. Data is collected at the edge with metadata already attached at acquisition, stays within each plant, and a semantic layer ensures it carries consistent meaning. When one plant solves a quality problem with AI, the other 42 benefit. The architecture is reportedly set to be extended to another 70 plants.

Business case and numbers

The panel advises tying infrastructure spending to concrete problems (downtime, first-pass yield, maintenance and warranty costs, labor productivity) and treating data as a product, with an owner and a budget. In a live poll, 33% of attendees were scaling their data infrastructure and 41% did not see it as a priority. MIT research cited in the session estimates that about 95% of the $35-40 billion invested in AI worldwide each year fails to scale. The figure comes from the panel, and I have not verified the primary source.

Why this matters to automation professionals

Standardizing tags, synchronizing time and contextualizing data are PLC, SCADA and historian engineering tasks, and they must be completed before AI is extended to more plants.

A practical starting point: before the next pilot, check for a shared naming convention, clock synchronization (for example, via a common time source) and which metadata is attached to each signal. Then ask whether the acquisition resolution suits the intended model, not the dashboard.