Why Plant Data Never Reaches AI: The Contextualization Gap

On October 9, 2026, IIoT World published a summary of a panel at the Industrial AI Summit 2026 featuring Jonathan Alexander (Albemarle Corporation), Peter Sorowka (Cybus) and Kudzai Manditereza (HiveMQ). The central thesis: collecting data on the plant floor is largely a solved problem, but the data collected does not reach AI in a usable form.

A note on transparency: the article is labeled as sponsored by HiveMQ and Cybus, although it declares itself editorially independent, and these companies sell exactly the kind of infrastructure under discussion. It also presents no survey data, apart from a reference to the 90% of effort in traditional machine learning. It should be read as an authoritative point of view, not as a measure of the market.

The real bottleneck: contextualization

According to the panel, manufacturers have spent 10–20 years installing sensors and connecting machines. Historization is widespread, but data is stored without structure or governance. What is missing is contextualization: the step in which raw readings acquire process knowledge, relationships between equipment and operating conditions. The article observes that this knowledge still lives in the heads of experienced operators rather than in systems.

Hence the criticism of historian-centric architectures: they record values and timestamps, but not relationships, operational context or access rules. They were not designed to support AI decision-making.

Applications or infrastructure

Point-to-point integration works for a single use case. But if predictive maintenance is followed by energy optimization and quality monitoring, each project requires new connections. The result is a fragile "spaghetti" architecture that keeps AI stuck in the pilot phase.

The alternative is a shared data platform: you connect once to all operational sources and expose the data through standardized interfaces. New use cases are then added incrementally.

The disagreement over LLMs

On the role of language models and data quality, the positions diverge:

• Alexander: frontier models have not been trained on plant-specific data such as process parameters, drawings and P&IDs. In his test, a general-purpose AI could solve problems in a home HVAC system, but failed on the process instrumentation of a plant.
• Sorowka: LLMs tolerate messy data. Traditional ML required about 90% of the effort in labeling and cleaning; LLMs do not. Context can be supplied at inference time, even from a badly scanned PDF or a photo, so waiting for perfect data is not a good reason to postpone.
• Manditereza: knowledge graphs are needed for meaning, for example to understand which downstream processes stop if a work order fails. That context lives in the relationships between systems, not in individual documents.

On one point the three agree: operational data must be exposed to AI through proper, governed data infrastructure.

Governance: AI as a subject with an identity

Because AI can act, while a historian merely stores data, the panel points to governance requirements covering behavior, permissions and accountability:

• a distinct identity for AI systems within the security architecture;
• access rules defining which data they can read, which systems they can influence and which decisions they can trigger;
• an audit trail of what the AI accessed, what it recommended and what it triggered.

Key takeaways

For those working with PLCs, SCADA and historians, the message is practical: value is shifting from connecting one more source to building contextualization layers and shared data, such as a unified namespace, instead of new point-to-point links. Before a new AI project, it is worth asking whether the existing data has an explicit model, relationships and access rules, and whether the work done can also serve the next use case.

Finally, the LLM debate suggests a balanced approach: don't wait for perfect data, but don't ignore that plant context must be made available and governed.