TL;DRFor years, industrial teams centralized data first and analyzed it later, a model built for reporting, not real-time operations. As AI and automation move onto the shop floor, the lag between data and decision has become the biggest constraint on scaling industrial AI.
- Centralizing operational data before acting on it creates a decision latency gap that real-time operations and AI cannot tolerate.
- Distributing intelligence to the edge lets the people closest to the data act on it while it still matters.
- Centralization still has a role, but for governance, standards and long-term optimization, not for minute-by-minute decisions.
Who this blog is for: The leaders and teams driving AI and data strategy across industrial operations, from business and operations executives to plant leaders, industrial data and AI architects, and the OT/IT teams responsible for scaling AI across distributed environments.
For more than a decade, the industrial playbook for turning data into insight has followed a single pattern: collect the data, move it to a central repository, and then analyze it. That model worked well for business analytics. For industrial AI at scale, that model is becoming an obstacle.
Operational data is continuous, time-sensitive and often safety-critical. By the time it's centralized, the moment to act on it has often passed, and the context that people closest to operations understand best gets lost along the way. Every movement of that data also raises security and governance questions that only grow as volumes scale.
We recently hosted a webinar Why Intelligence Needs to Be Distributed, Not Centralized with HiveMQ senior industrial solutions advocate, Kudzai Manditereza, and director of product marketing Shashank Sharma, walking through this challenge. Here’s the insight they shared.
The core problem with centralized intelligence in industrial AI
U.S. factory productivity was flat or declining from 2008 to 2023 despite heavy investment in industrial IoT, sensors and MES systems. What does that show us? Data access isn't the bottleneck; the bottleneck is turning surfaced data into decisions fast enough to act on. This "decision intelligence gap" or "decision latency gap" is costing industrial organizations in decisions made on stale data, man-hours wasted managing and maintaining complex data architectures, or even an agent making decisions based on bad data. The most expensive mistake that industrial organizations can make is treating this as a data-movement problem, when it is a data-meaning problem.
Markets now demand more flexibility e.g., switching a production line's output overnight, which the traditional centralized model wasn't built to support. ‘Collect, centralize, analyze’ may work for the dashboard era, but AI demands structure, governance and control in real-time.
Why the traditional "collect, centralize, analyze" model breaks down
This ‘old world’ model still works well for business-level decisions made over hours, days or weeks such as reporting or benchmarking. However, the cracks begin to show when that data is needed in real time. By the time data is transported, normalized and processed, the window to act has passed. Kudzai calls centralized dashboards "yesterday's metrics."
Central data teams become a bottleneck since every use case requires a custom pipeline, which in turn, perpetuates data silos. Shop-floor experts, who best understand the context behind the data, don't own the contextualization; central IT teams do it without full context, creating a frustrating, iterative back-and-forth.
The proposed fix: a hybrid, bottom-up model
So, what’s the solution? Push intelligence to the edge, closest to where data is generated, so it can be contextualized and acted on in real time by the people who understand it.
That’s not to say there’s no case for centralization at all. In this model, Kudzai recommends still centralizing loosely (standards, governance, KPIs, long-term optimization), but let the edge extend and customize those standards rather than dictate rigid ones top-down.
This three-stage approach sees:
- Connect - get data out of machines via protocol adapters into a standard format like MQTT.
- Contextualize and Analyze - turn it into continuously running analytics at the edge.
- Act - apply agentic AI to automate non-value-add tasks and eventually close the loop by acting on the data.
Architecture, in HiveMQ's terms
HiveMQ Edge connects machines/protocols (OPC UA, Modbus, BACnet) and converts to MQTT, organizing data locally. A site-wide broker aggregates that into a unified namespace (UNS), still real time, with governance applied centrally so business applications can rely on a consistent model.
Data intelligence layer adds validation, a data catalog and a semantic graph (knowledge graph) that grounds agentic AI and provides guardrails.
Long-term, non-real-time data still flows to a warehouse or lake for historical analysis.
HiveMQ already powers the data backbone of some of the world's best-known enterprises. Car giant Ford’s unified namespace, across global factories, improved fault detection and predictive maintenance, saving $24 million a year. Global pharmaceutical firm Eli Lilly (Lilly) started with a compliance use case (replacing paper records), scaling to a unified namespace across 15 sites and multiple use cases. BMW cut app-based car door unlock time from 30 seconds to under one second across 20 million vehicles. The common thread? Starting small with one use case on a reusable data backbone lets companies scale to additional use cases without rebuilding infrastructure each time.
What's next?
HiveMQ’s September webinar will go deeper into the what’s new from HiveMQ platform and how it splits distributed versus centralized responsibilities across the three layers (stream, build intelligence, activate AI).
