Industrial AI doesn't need better models. It needs DevOps and DataOps.

Your AI pilot worked. It ran on a spreadsheet somebody cleaned by hand, it impressed the right people, and then it never reached the plant. A year later nobody can say precisely what went wrong, and the quiet conclusion in the room is that the technology was oversold.

It wasn't the technology. The pilot died in the gap between a laptop and twenty sites, and that gap has a name in the software industry. Two names, actually, and neither has anything to do with AI.

Neither word is new. DevOps has been standard practice in software since roughly 2010, DataOps since about 2015. What is new is that both are finally possible on a plant floor, and that industrial AI is the first thing to make their absence expensive enough to notice.

Twenty years of doing the opposite, on purpose#

Automation didn't miss these ideas. It rejected them, and it was right to.

The plant floor spent two decades building the exact inverse of DevOps: change control. Freeze the system, document the change, schedule a window, test on a spare, get three signatures. That is not backwardness. When the downtime meter ticks in thousands of dollars a minute, and when a bad write can hurt somebody, reliability genuinely does beat innovation and slow is the correct answer.

The trouble is that change control optimises for one thing: not breaking what already runs. It has nothing whatsoever to say about building something new, quickly, twenty times. And that is precisely what an AI programme asks for.

What the model actually sees#

Here is the part that surprised me, and I only believe it because I measured it.

I built a small copilot over two Modbus devices, with a tag layer giving every value a name, a unit and a scaling factor. Asked properly, it answered well and refused to write a setpoint for exactly the right reasons. Then a block read failed, and my own code dropped the exception code on the floor, so the error arrived as an empty string.

The model didn't get confused. It reasoned carefully from nothing and diagnosed a fault that did not exist.

That is the finding worth carrying out of the last year of this work. Bad provenance does not produce obvious nonsense. It produces confident, well-argued errors — the single hardest failure mode to catch, because it looks exactly like competence. A wrong answer that sounds wrong gets caught in the review. A wrong answer that cites a reading and walks you through its logic gets actioned.

Which is the whole argument for DataOps, stated without the vocabulary: if you hand a model bare register values, you have built a machine for generating plausible mistakes. Context is not a nice-to-have layer on top of the data. It is the thing that makes an answer checkable.

The same lesson showed up from the other direction when I ran a commercial DataOps product against a live gateway. I modelled thirty-five stations properly, with descriptions and units on every attribute, then pointed an AI client at it and asked one operator-grade question. It could not see any of the modelling. The models, the namespace and the historian simply weren't on that surface. All it could reach was a folder of raw sine waves, which it would happily have reasoned about.

The two things that changed#

None of this was actionable ten years ago. Two categories had to appear first, and both did, quietly, while the industry argued about the cloud.

The first is a genuine new category of data transport. A Sparkplug B payload describes itself, so a consumer learns the tag list from the wire instead of being told, which is DataOps arriving as a protocol feature rather than a discipline somebody has to enforce every day. It is also not the whole answer the Unified Namespace crowd claims, and it has sharp edges: two mature implementations of the same published spec disagreed with each other in three places in my lab, every one of them failing silently.

The second is that SCADA configuration became files. Once Ignition 8.3 started writing projects as JSON and Python on disk, every technique the software world built for managing files became available. I have written about what that means for a fleet, so I won't relitigate it here.

What matters for this argument is the rebuild time above. An environment you can recreate in a minute is an environment you are willing to experiment on, and that is the entire unlock. Nobody iterates on a gateway they are frightened of.

Where the IT playbook has to stop#

I want to be careful here, because this is where these articles usually go wrong and start sounding like someone who has never been on a plant floor at three in the morning.

Continuous deployment does not belong anywhere near a running process. "Move fast and break things" is a slogan written by people whose worst case is a failed checkout, not a hurt operator. And rolling forward through a failure is an IT instinct that inverts badly in a plant, where the safe state is very often stopping.

What actually transfers is narrower and duller: the pipeline gets fast, the deployment stays gated. You keep every signature. You just stop doing the twenty-sites-by-hand part between them.

There is also a genuinely new problem that no IT playbook covers, and I hit it hard enough to be honest about it. Generating configuration is solved. Generating trust is not. Certificates and API tokens were the wall I could not automate past in the fleet lab, and they are what stands between a working pipeline and a real multi-site rollout. Anyone who tells you this is a solved problem has demoed it, not deployed it.

What it looks like when it works#

Thirteen of those fifteen weeks were spent getting to the starting line, and the tax is charged again on the next project, and the one after that. Delete it once and every subsequent AI request costs what it should have cost the first time.

That is the actual promise, and notice how unglamorous it is. No new model. No new vendor category. The plant floor gets to run AI projects at a normal pace because the two disciplines underneath them finally exist.

So what do you do on Monday#

Three things, in order, and none of them require buying anything.

Pick one tag and follow it. Take a value your business actually cares about and trace it from the sensor to whatever consumes it. Write down every point where it loses its unit, its scaling, or its quality flag. That list is your DataOps backlog and it will be shorter and more damning than you expect.

Try to rebuild one gateway. Not restore it, rebuild it, from whatever you have written down. Give yourself an afternoon. Whatever stops you is your DevOps backlog. Most sites discover they have a reproducibility problem rather than a backup problem about twenty minutes in.

Then re-ask the AI question. With those two lists closed, "can we predict which pumps are about to fail" stops being a research project and becomes a fortnight of ordinary work.

The industry keeps waiting for a model good enough to make sense of plant data as it currently arrives. That model is not coming, because the problem was never intelligence. Give a competent analyst bad provenance and you get confident mistakes, whether that analyst is silicon or human. Fix the plumbing and the intelligence you already have turns out to be plenty.