Why Factory Data Never Reaches AI: The Contextualization Gap

On October 9, 2026, IIoT World published a write-up of a panel at the Industrial AI Summit 2026 addressing a recurring question: why does factory data, collected for years, still fail to reach artificial intelligence in any meaningful way? The panelists' answer is that an intermediate stage is missing: contextualization.

A note on the source: the article is labeled as sponsored by HiveMQ and Cybus, although it describes itself as editorially independent, and two of the three panelists work for the sponsors. It should therefore be read as the opinion of a panel with commercial interests, not as a data-based study. Also, this summary relies only on the first part of the article; the FAQ section appeared to be truncated.

Collection Solved, Context Missing

The panel featured Jonathan Alexander (Albemarle), Peter Sorowka (Cybus) and Kudzai Manditereza (HiveMQ). Their starting thesis: manufacturers have invested in sensors and connectivity for 10-20 years, so collection is largely solved and historization is widespread. What is missing is the step in which raw readings acquire process knowledge, relationships between equipment and operating conditions.

That knowledge still lives in the heads of experienced operators, not in the systems.

For the panel, this is the main gap preventing AI from scaling.

Two Architectures Compared

The speakers criticize two common models. The first is the historian-centric architecture: it stores values and timestamps, but without relationships, context or access governance, and according to the panel it was never designed to serve AI. The second is application-centric integration: each project builds its own point-to-point connections, for example predictive maintenance first, then energy optimization, then quality monitoring. The result is a fragile "spaghetti" architecture, cited as one of the reasons AI remains confined to isolated pilots.

The proposed alternative is a shared, infrastructure-centric data platform: you connect once to all operational sources and expose standardized interfaces, so new use cases can be added incrementally. The article points to content on the unified namespace (UNS), but the part I read does not go into it in depth.

The Disagreement on LLMs

On the role of language models, the positions diverge:

• Alexander: frontier models have never seen plant-specific data such as P&IDs, process parameters and drawings. A general-purpose AI can solve a problem with a home air conditioner, but it failed on a plant's specific instrumentation.
• Sorowka: LLMs tolerate messy data, so the 90% labeling and cleaning effort typical of classical machine learning isn't worth it. Context can be supplied at inference time, even from a poorly scanned PDF; waiting for perfect data is not a good reason to postpone.
• Manditereza: knowledge graphs are needed for semantic context. An LLM reading isolated documents doesn't know which downstream processes stop if a work order fails.

All three agree on one point: operational data must be exposed to AI through an adequate, governed data infrastructure.

Governing AI Agents

The panel asks that AI be treated as an actor within the security architecture:

• a distinct identity for AI systems;
• access rules on which data they can read, which systems they can influence and which decisions they can trigger;
• audit trails of what the AI consulted, recommended and caused.

Without these elements, an AI can reach production readiness and then stall on security and compliance.

What to Do With It in Practice

Given the source's limitations (no quantitative data, sponsors who sell MQTT/UNS and data-ops platforms), the checklist is still useful for IT/OT leaders:

• check whether new AI projects reuse a shared data layer or add yet another point-to-point connection;
• decide where and how to capture process knowledge that today lives in people, in a contextual model;
• define identity, permissions and audit for agents before moving to production, not after.

The underlying message is that the bottleneck is not collecting more data, but making it interpretable and governable. Specific technology choices should be evaluated independently of the vendor.