Everyone says IT/OT convergence is the goal. Fewer people explain what it requires to get there — and almost no one talks about why so many attempts stall before they produce anything useful.
The answer, in most cases, comes down to data. Specifically, to whether the physical side of operations is generating data that the digital side can actually consume. That connection doesn’t happen by default. It requires a deliberate layer of technology — and understanding what that layer does, and why it matters, is the prerequisite to making IT/OT convergence real rather than aspirational.
What “OT vs IT” Actually Means
The OT vs IT distinction used to be simple: IT ran the business, OT ran the plant. Enterprise resource planning, email, reporting — that was IT. PLCs, SCADA systems, sensors, actuators — that was OT. The two worlds operated on different protocols, different update cycles, and different risk tolerances. And for decades, that separation was intentional.
IT systems are optimized for data processing, interoperability, and relatively fast change cycles. OT systems are optimized for uptime, determinism, and safety. A Windows patch that requires a restart is acceptable in a back-office environment. It is not acceptable on a PLC controlling a curing oven in an aerospace facility.
That fundamental tension has not disappeared. However, what has changed is the cost of keeping the two worlds apart. When AI and analytics tools operate only on enterprise data — on ERP records, purchase orders, and scheduled maintenance logs — they miss everything that actually happens on the floor. The real-time state of equipment is invisible. The actual pace of production goes untracked. And the gap between what the schedule says and what the operation is doing? That never surfaces at all.
That gap is the problem IT/OT convergence is trying to solve.
Why IT/OT Convergence Stalls
Most IT/OT convergence projects begin with good intentions and stall at the same point: the moment someone tries to get OT data into an enterprise system.
The problems are predictable. OT data is messy, high-frequency, and often proprietary. Legacy equipment communicates over protocols — Modbus, OPC-UA, proprietary vendor formats — that enterprise systems don’t natively understand.
The data arrives in bursts, not in the structured records that databases expect. And critically, OT environments are often air-gapped or heavily segmented for security reasons, which means you can’t simply route a sensor feed through the corporate network without introducing significant risk.
The result is that organizations end up with two pools of data that don’t talk to each other. IT has clean, structured, latent data — accurate but historical. OT has real-time, granular, messy data — timely but inaccessible. Neither pool, on its own, gives you what you actually need.
This is the problem a capture layer is designed to solve.
How the Capture Layer Works
A capture layer sits between the physical operational environment and the enterprise digital stack. Its job is to collect signals from the physical world — sensor readings, location pings, condition data, equipment status — and convert them into structured, accessible data streams that enterprise systems, analytics tools, and AI models can consume.
That sounds straightforward. In practice, it involves several distinct functions:
Signal Acquisition
The capture layer has to work with whatever is already in the environment. That means supporting multiple communication protocols — BLE (Bluetooth Low Energy), RFID, UWB (ultra-wideband), LoRaWAN, and legacy wired protocols — rather than requiring a rip-and-replace of existing equipment.
Hardware-agnostic acquisition is not a nice-to-have; it’s the difference between deployment and a multi-year infrastructure project.
Normalization
Raw sensor data is not useful data. A temperature reading means something different depending on what equipment it came from, where that equipment is, and what the expected operating range is. The capture layer has to apply context — location, asset identity, operational state — to raw signals before passing them upstream. Without normalization, you have data volume without data meaning.
Structured Delivery
Enterprise systems and AI tools expect data in specific formats through specific interfaces. The capture layer delivers normalized operational data via standard protocols — MQTT and REST APIs are the most common — so that downstream systems can consume it without custom integration work for every new tool.
Retention and Historization
Real-time visibility is valuable. Historical telemetry is what makes AI and analytics actually useful. A capture layer that only streams live data and discards it is a missed opportunity. The operational record — time-stamped, contextualized, permanent — is what enables anomaly detection, predictive models, and the kind of longitudinal analysis that changes how organizations make decisions.
When these functions are working together, IT/OT convergence stops being a conceptual goal and becomes an operational reality. The enterprise stack finally has access to what’s happening on the floor. And the floor stops being a black box.
The Connection to Physical AI
IT/OT convergence is, in important ways, the precondition for Physical AI — artificial intelligence that operates on real-time data from physical environments. You cannot run Physical AI without first bridging the gap between where physical events happen and where your AI tools live.
The models and the infrastructure are ready. What most organizations are missing is the data pipeline that connects them to the physical world. That pipeline is the capture layer.
This matters because the failure mode for AI in operations is not usually a bad model. It’s a model that’s been pointed at incomplete or lagged data and produces outputs that don’t reflect what’s actually happening. LLMs hallucinate when they lack grounded operational data — not because the model is flawed, but because it has nothing real to work with. Before connecting any AI to operations, get the data layer right first.
A well-built capture layer changes that equation. For example, when an AI tool receives a continuous stream of normalized telemetry — location, condition, utilization, environmental state — it can actually answer the questions that matter: which equipment is trending toward failure, where production is diverging from plan, what’s causing the throughput gap on Line 3.
Physical AI starts on the floor. IT/OT convergence is how you get the floor’s data to the place where AI can act on it.
What This Looks Like in Practice
Consider an aerospace manufacturer with a facility that contains several thousand tools — torque wrenches, drill motors, calibrated instruments — distributed across a large assembly floor. Theoretically, the ERP system knows when each tool was last calibrated. In practice, the ERP knows when the calibration record was updated. It does not know where the tool is, whether it’s been used since calibration, or whether it’s within its operating parameters right now.
That’s an OT vs IT gap. The physical reality and the digital record are not the same thing.
A capture layer, built on BLE beacons attached to tools and readers distributed across the facility, closes that gap. The system knows where every tool is in real time, can flag when a calibrated instrument moves out of its approved zone, and can alert maintenance when an instrument’s calibration window is approaching — not based on a scheduled date, but based on actual usage.
That operational data flows continuously into a visualization platform, and from there, via API, into whatever analytics or AI tools the organization is running. The ERP record is still useful. However, now it’s grounded in what’s actually happening — which is what IT/OT convergence is actually supposed to deliver.
The Architecture Question
IT/OT convergence conversations often focus on strategy and almost never get specific enough about architecture. That’s where most initiatives run into trouble.
The architecture question is: what, exactly, is sitting between your OT environment and your enterprise stack? Is it a point-to-point integration that breaks every time a vendor updates their firmware? Is it a proprietary platform that owns your data and charges you to access it? Or is it an open, hardware-agnostic capture layer that normalizes your operational data and delivers it via standard APIs to whatever tools you’re running?
The answer determines whether IT/OT convergence produces lasting value or just a different set of dependencies.
AI strategy starts at the data layer. The organizations getting this right are building capture infrastructure they control — open data delivery, no vendor lock-in on the hardware side, and normalized telemetry that plugs into their existing enterprise stack.
That is the architecture that makes IT/OT convergence durable. And it’s the architecture that makes Physical AI, when you’re ready for it, actually possible.