An AI model that works at one factory runs on known data, connects to a handful of systems, and depends on one team that controls the scope. Scaling that same model to 20 factories exposes every shortcut: inconsistent tag names across manufacturing execution systems, misaligned clock signals in data pipelines, and no shared definition of quality data. At the Industrial AI Summit 2026, Gaspard Duthilleul of Galyos, Sanjay Mahato of Amazon Web Services, Ian Clark of InfluxData, and Tauseef Ahmed of Grayhawk Consulting Group discussed why data architecture fails first when manufacturers attempt enterprise-wide AI deployment.
What Fails First When AI Scales Past One Factory?
A single-site AI project succeeds because its scope stays narrow: one machine, one production line, one team managing the data. The transition from one site to 20 forces every assumption about data consistency into the open. Tag schemas, naming conventions, clock synchronization, and data ownership structures all break simultaneously under the weight of replication.
Tag naming is among the first casualties. The probability that sensors carry consistent identifiers across 20 sites is low. Without a common standard, “compressor one” at one location could mean something different at the next. Clock skew in data pipelines is another failure point: when timestamps from multiple sources drift out of alignment, the training data fed to AI models carries errors invisible to the team that built the original project. Manual corrections, spreadsheets maintaining tag schemas, and custom integrations built for one location all become liabilities that multiply across every additional site.
Tag-based licensing in traditional data historians adds a separate cost barrier. AI models perform better with more connected sensors, but each additional sensor increases licensing cost. The economics of scaling work in the wrong direction. Historians designed for single-site visibility lack the architecture to feed real-time data across a factory network for AI inference and prediction.
| Factor | Single Site | 20+ Sites |
| Tag naming | One spreadsheet, manually maintained | Inconsistent across sites, naming drift |
| Data ownership | Single team, clear accountability | Multiple owners, competing definitions |
| Clock synchronization | Rarely noticed at small scale | Skew compounds across pipelines |
| Historian licensing | Affordable for limited sensors | Cost rises inversely to AI needs |
| Data corrections | Hand-applied fixes for edge cases | Every manual fix becomes a scaling liability |
| Integration approach | Custom connectors per system | Custom approach fails at replication |
What Makes a Data Backbone AI-Ready?
An AI-ready data backbone requires five capabilities beyond what traditional historians provide:
- Durability with store-and-forward for network outages
- Nanosecond timestamp precision
- Open data standards that prevent vendor lock-in
- Support for both training and inference workloads
- A semantic layer that enforces consistent meaning across every site
Durability is the first requirement because OT environments are unreliable, with network outages, sensor failures, and power interruptions routinely disrupting the telemetry streams that AI models depend on. A system that supports store-and-forward buffers data during these disruptions and backfills when connectivity returns, preserving the continuity that training and inference require. Timestamps must function as a first-class element of the data model: analytics in manufacturing make sense primarily in the context of time, and the volume and velocity of modern sensor data demand query performance that single-site historians were never built to deliver. Open data standards keep telemetry out of proprietary black boxes and allow analytics teams to collaborate across platforms.
Volkswagen Group’s Digital Production Platform applies these principles across 43 global plants. Volkswagen collects all available data at the edge without pre-selecting what to keep. Metadata about what product was being manufactured, what maintenance state the equipment was in, and what operating conditions applied travels with the data from the point of capture. Rather than centralizing everything, the company keeps data at each plant while a semantic layer ensures consistent meaning across every site. IT, OT, and engineering data connect into a single digital thread from order intake through manufacturing. When one plant solves a quality problem with AI, the other 42 benefit immediately. Volkswagen is expanding this architecture to 70 additional plants.
Is the Shortage Data Volume or Data Context?
Manufacturers do not have a shortage of data. MES systems, historians, ERP platforms, supply chain databases, and quality systems have been collecting operational data for years. The shortage is in usable data: readings that carry the asset identity, production context, maintenance history, and quality outcomes that AI models require for meaningful output.
A temperature reading by itself has limited business value. For it to serve an AI model, it needs to travel with the identity of the asset it belongs to, the product being manufactured at that moment, the operating conditions, the maintenance history of the equipment, and any downstream quality or warranty outcomes. Without that context, the reading is a number detached from the business process it describes.
Data meant for human consumption differs from data meant for machines. Dashboards present information at one-second or five-second sampling intervals, a resolution that humans can read. AI models detecting equipment anomalies often need access to kilohertz-level signals. When a manufacturer trains a model on dashboard-resolution data, the smoothing averages out the high-frequency phenomena the model was built to detect before they ever reach the training pipeline. Distinguishing what data serves operators from what data feeds AI systems, and preserving the full-resolution signal for machine consumption, is a prerequisite for physical AI.
How Should Manufacturers Justify Data Infrastructure Investment?
Framing data infrastructure as a standalone technology investment disconnects it from the outcomes that justify executive spending. A portfolio of specific business problems provides the starting point:
- Unplanned downtime and throughput constraints
- First-pass yield failures and quality defects
- Rising maintenance costs and warranty spikes
- Labor productivity shortfalls
Building the data platform as a reusable enterprise capability, one that serves multiple use cases across multiple plants, ties the infrastructure investment to measurable business outcomes rather than a one-time implementation for a single application.
A live poll during the session found that 33% of attendees had data infrastructure scaling already underway, while 41% said it was not currently a priority. An MIT survey cited during the session estimated that roughly 95% of the $35-40 billion invested globally in AI initiatives each year fails to scale. Reactive maintenance, unplanned downtime, and delayed detection of quality defects carry financial penalties that compound over time.
Manufacturers positioned to use AI at scale treat data as a product with a dedicated owner, ongoing budget, and continuous maintenance. Trusted data can support predictive maintenance today, quality analytics tomorrow, and autonomous decision-making in the future without requiring a new foundation for each use case.
Sources
- Physical AI in Production: The Data Infrastructure Gap, Industrial AI Summit 2026, hosted by IIoT World
Related from IIoT World
This article is based on a panel discussion with Gaspard Duthilleul of Galyos, Sanjay Mahato of Amazon Web Services, Ian Clark of InfluxData, and Tauseef Ahmed of Grayhawk Consulting Group, recorded at the Industrial AI Summit 2026 hosted by IIoT World. AI tools were used to help summarize and organize the content. Reviewed and edited by the IIoT World editorial team.
Sponsored by InfluxData
