The Pilot Problem: Why 95% of Manufacturers Bet on AI — and Their OT Data Can’t Keep Up

The models aren’t why your operational AI and predictive-maintenance programs stall. Your legacy OT data infrastructure is — and you don’t have to rip it out to fix it. 

Here’s a story I’ve heard some version of at a dozen manufacturers. A team stands up an operational AI or predictive-maintenance pilot on one line. It works. It catches a failing bearing three weeks out, or trims unplanned downtime on that one asset, and everyone’s thrilled. Then they try to roll it out across the plant — and across the other plants — and it stalls. Budgets get questioned, the data-science team gets blamed, the vendor gets blamed. The models were never the problem. The data underneath them was. 

Nearly everyone is making this bet. In Rockwell’s 2025 State of Smart Manufacturing, 95% of manufacturers said they’re investing in operational AI. And the prize is real: Siemens’ 2024 True Cost of Downtime research puts the predictive-maintenance upside at 85% better downtime forecasting, 50% less unplanned downtime, 55% more maintenance-staff productivity, and 40% lower maintenance costs. Nobody’s arguing about whether operational AI is worth it. They’re stuck on why it won’t scale. 

It’s Not the Models. It’s The Legacy OT Data Infrastructure Underneath. 

When these programs fail, they rarely fail on the algorithm. They fail because the data infrastructure feeding the algorithm was never built to feed it. Your historian was built to store and report — to log tags for trending and compliance — not to stream millions of live readings across a fleet to a hungry model in real time. The integrations around it are point-to-point: a custom connector here, a nightly batch export there, a spreadsheet somewhere in the middle. That holds up on one line in a proof of concept. It buckles the moment you ask it to move real operational data, at fleet scale, as the process is actually happening. 

Three things break it, in my experience. Protocol barriers — the plant floor speaks dozens of protocols your data pipeline doesn’t. Batch latency — data that shows up in nightly or hourly chunks is useless to a model that needs to see the process live. And brittle custom connectors — every one is a thing that breaks, and multiplied across sites it becomes a maintenance job nobody signed up for. That’s the legacy bottleneck. It’s the concrete reason the pilot dazzles and the rollout dies. 

You Don’t Have to Rip Out the Historian to Get Real-Time OT Data 

Here’s the good news, and it’s the part most teams brace against: fixing this doesn’t mean a rip-and-replace. You don’t tear out your historian, re-instrument the plant, or stand up a parallel data platform. The data you need is already being produced — by the sensors, HMIs, and historians you already run. The problem was never the data. It was getting the data out, in real time, in a form a model can use, without breaking anything. 

That’s what Industrial Data Streaming in the Dispel Zero Trust Engine does. It streams operational data in real time from the equipment already in place — format-agnostic, so it moves OPC UA, JSON, and native system data types without middleware or a rack of custom connectors. It reaches what the plant actually runs: 65,000+ protocols. And because it rides the same Zero Trust infrastructure as your secure remote access, the data flow inherits the exact access controls and audit trails you already trust for remote sessions. No new data infrastructure. No new attack surface. No second security model to build and defend. 

That’s the category we’re building: the secure data backbone for operational AI. Not another platform to buy, instrument, and defend — the layer that moves the data you already produce, in real time and under the controls you already trust, to whatever needs it. 

What A Modern OT Data Layer Should Look Like 

If you’re the person who has to architect this, here’s the short version of what “good” looks like: 

• Real-time or batch — stream live data when the model needs to see the process as it happens, or run scheduled batch posts for the jobs teams would rather handle that way. Both have value; you pick per use case instead of being forced into one. 

• Format- and protocol-agnostic — it takes what the plant produces instead of forcing everything into one schema through custom code. 

• Secure by inheritance — access control and audit come from the same platform governing remote access, not a separate security model you have to stand up. 

• Fleet-scale from day one — the path that works on one line works across every site, because it isn’t held together by per-line connectors. 

Get those four right and the pilot-to-fleet cliff disappears. The model that worked on one line works on fifty, because the thing feeding it finally scales. 

Not All OT Data Should Move the Same Way 

When a customer tells me they have a data streaming use case, my first question back is simple: what kind of data do you actually have? Because “stream my data to a vendor” isn’t one job — it’s three, depending on the data. We think about it in three states: unprocessed, cleaned, and enriched. Being a solid backbone means moving the data reliably. The value, and the interesting part, is in what state you move it in. 

Unprocessed is the raw stream, straight off the equipment. Sometimes that’s exactly what’s wanted — a customer sending temperature and pressure differentials to a third party that turns those raw readings into supply-chain signals, like how fast raw materials are being consumed. The receiving system does the interpreting, so all they need from you is a clean, reliable raw feed. 

Cleaned is where governance shows up. Say you want to send equipment logs to an outside partner to power predictive maintenance — useful, except the raw logs also carry elements that, under NERC CIP, aren’t permitted to leave the trust boundary. Send the raw stream and you’ve created a compliance problem, and NERC penalties run well into the millions. Clean it first — strip the regulated elements — and the partner still gets exactly what it needs to tell you which machines to investigate and when, without you ever sending data that shouldn’t leave. Cleaning is how you keep the compliance and governance layer intact while still getting value out of the data. 

Enriched is where separate streams become worth more than the sum of them. It’s something we already do inside the platform: a Dispel Intelligence risk score is a pile of independent logs — where someone connected from, what they did, how the session behaved — combined into a single fact you can act on. That’s enrichment. Applied to operational data, it’s consolidating several thin streams into one clean, decision-ready package, instead of shipping raw exhaust and hoping someone downstream makes sense of it. 

The point isn’t the labels. It’s that as you move along your data streaming journey, the question is never just “can you move my data?” It’s move which data, in what state, to whom — and does it stay compliant on the way? That’s the part a raw backbone alone doesn’t answer, and it’s where we spend a lot of our time. 

The Bottom Line 

The 95% betting on operational AI aren’t wrong. Most of them are just about to spend a year blaming their models for what is really a legacy OT data infrastructure problem. If your pilot works and your rollout stalls, look underneath the model before you touch it. The fix is usually not a smarter algorithm or a bigger platform — it’s a data layer that can move what your plant produces, in real time, securely, without you rebuilding a thing. 

See it on your data. See how operational data reaches your operational AI and predictive-maintenance platforms — securely, from the systems you already run — in a 20-minute walkthrough. Book a walkthrough →