What separates a working demo from a system you can trust every shift - and why it matters more than you think
At Berkvens Doorsystems, each team lead has been able to save between 30 and 60 minutes every morning. Their AI-powered maintenance briefing arrives before the shift starts. It contains a full breakdown of all current and ongoing activities, and any issues that were flagged overnight. What's more, it matches their own manual analysis at over 95% accuracy. That is a signal of what production-ready industrial AI is capable of when it is working.
It is also, in my experience, a lot rarer than the current enthusiasm around AI would suggest.
Most industrial organizations I speak with have run a pilot -many have run several. The results are often genuinely promising. But there is a consistent pattern in what happens next: the conversation about scaling stalls. The tool that performed well in a controlled setting starts to feel less certain when you imagine it running unsupervised across multiple shifts, multiple sites, and a workforce that was not involved in building it.
The pilot proved the concept; it did not prove the system.
That gap is where most industrial AI initiatives are stuck right now. And it is a gap that organizations attempting to build AI in-house have to bridge unexpectedly, and at considerably more cost than they planned for. Almost any pilot can be made to work. The real question worth answering is whether your people can depend on it, every shift, under real operational pressure. That is the only standard that counts.
What the data tells us about where AI lives
McKinsey's 2024 State of AI report found that while 72 percent of organizations globally have adopted AI in at least one business function, scaling from pilot to production remains the single biggest barrier cited. The real hurdle remains the organizational and operational infrastructure required to make AI deployment reliable.
That matches what I hear from maintenance leaders consistently. The limiting factor is rarely the AI model. It is everything that must surround the model for it to function safely and consistently in a real industrial environment: data quality, system integration, human workflows, governance, and the ability to explain what the system did and why, if someone asks.
These are operational prerequisites, which do not behave like technical features. They take time, depth, and genuine domain experience to get right. Organizations building AI in-house are starting that journey from zero. Organizations working with a platform that has been embedded in industrial operations for years are accelerating from a foundation others are still trying to build.
The data problem nobody budgets for
Industrial AI is only as good as the operational data behind it. That sounds obvious. In practice, it is the thing that catches in-house build projects off guard most consistently.
The average industrial facility has years of maintenance history distributed across structured records, free-text fields, handwritten notes, and the institutional knowledge of experienced technicians who have never been asked to document what they know. Gartner estimates that poor data quality costs organizations an average of $12.9 million per year, and that is before you ask an AI system to reason across it.
A production-ready AI system needs clean, structured, contextually rich operational data to function well. Not just a data export from a computerized maintenance management system (CMMS), but information that reflects how assets behave over time, how failures cluster, what repair approaches have held up under real conditions, and what the maintenance history looks like at asset level. Building that foundation is a sustained operational discipline, and it rarely appears on the plan for an in-house AI build.
This is part of why platforms with genuine depth in industrial operations carry an advantage that is harder to see from the outside. The data infrastructure already exists. The operational context is already embedded. A system built on that foundation does not have start from zero, because the vendor never did.
What reliability means on a production floor
In manufacturing, utilities, or port logistics, reliability has a specific meaning that differs from almost any other context. It does not mean "usually works;" it means "has not failed during the shift when it mattered most."
Unplanned downtime costs the world's 500 largest companies an estimated $1.4 trillion every year, according to Siemens' 2024 research. The moment when a maintenance system is most needed are precisely the moments when pressure, complexity, and time constraints are highest. An AI tool that performs well under normal conditions but becomes unreliable under pressure is a fair-weather assistant, and industrial operations cannot afford this risk when facing the perfect storm that is brewing.
Production-ready means the system behaves predictably across every condition: different shifts, different sites, different languages, different levels of data completeness in the incoming work request. It means the output does not vary depending on who is using it, or how much pressure they are under. And it means that when something goes wrong, there is a clear, auditable record of what the system recommended and what the human decided.
In regulated industries, that last point is not optional. It is the difference between a tool that passes an audit and one that creates a liability. AI-generated code and internally built systems face exposure here. Veracode's 2025 research found that AI-generated codebases contain 2.74 times more security vulnerabilities than human-written equivalents, with 45 percent of Open Worldwide Application Security Project (OWASP) Top 10 security tests failing on AI-generated software. For organizations subject to FDA 21 CFR Part 11, ISO 55001, or Occupational Safety and Health Administration (OSHA) requirements, that is not an abstract risk.
The human question that technology cannot answer
There is one dimension of production readiness that gets underweighted in almost every AI conversation, and it is the one I find most worth talking about: adoption.
A system your maintenance team does not trust is not a production system, regardless of its accuracy rate in a controlled test. Industrial AI sits inside workflows that real people have developed over years, sometimes decades. It surfaces recommendations to technicians standing in front of a machine with production waiting. It suggests priorities to planners who will be held accountable for the decisions, not the algorithm. For that to work, the AI must earn its place in the workflow - not by being impressive, but by being consistently useful.
Being consistently useful is harder than it sounds across a real industrial operation. Consider what that means: the system must perform the same way on the night shift as the day shift. It must work for the technician in the Netherlands and the one in India. It must handle work orders logged in three languages, asset records of varying completeness, and failure descriptions that range from precise engineering notation to "making a noise." The moment reliability becomes conditional - works well here, less well there, fine when the data is clean, unreliable when it isn't - people stop trusting it. And when people stop trusting it, they stop using it. At that point the problem is no longer the technology. The operation has developed a dependency on a system with a gap nobody planned for.
This is something the people who build internal AI tools tend to discover later than they expected. A prototype that performed well in a controlled test with clean data and a motivated pilot team starts to feel different when it goes across a whole plant. Different shifts have different habits. Different teams log things differently. The people who were not involved in building it have no reason to trust it yet, and with no one in charge of building the trust, this is not likely to change in the foreseeable future. At that point, the tool does not fail because the model is wrong; it fails because nobody owns the human side of making it work.
The newer generation of frontline workers adds another dimension here that often goes unacknowledged. They are not simply looking for a tool that makes their current job easier. They are looking for a system that supports their development - that shows them how to move from operator level one to operator level two, that gives them structured learning rather than a binder and a buddy. Research consistently shows that around 70 percent of employees who receive strong onboarding stay with an organization for three or more years. Industrial AI that is genuinely production-ready must speak to that expectation, not just to the efficiency targets on a project plan.
What this means in practice is that change management is more than a communications exercise that happens at the end of an implementation. It is part of what makes industrial AI production-ready or not. That means leadership visibility into adoption, not just accuracy metrics. It means training that reflects how people learn on a production floor, not how a vendor's onboarding deck assumes they do. It means identifying someone whose job it is to own the process, not just the software - to take operator feedback seriously, to iterate on how the system is used, and to make sure that what was promised in the pilot is what people experience on their third month of using it. APQC research shows that only 8 percent of organizations consistently capture knowledge from departing experienced workers. By treating adoption as a leadership responsibility, AI can help organizations close this gap successfully.
What separates a demo from something dependable
Production-ready industrial AI needs a data foundation that reflects real operational history. It needs integration deep enough to surface the right information at the right moment in the existing workflow, without requiring people to change how they work. It needs governance that can survive an audit. And it needs to earn genuine trust from the people who will rely on it under pressure.
None of those things are delivered by a model. They are built over time, through operational experience, customer feedback, and the kind of domain-specific iteration that only comes from being embedded in real industrial environments across hundreds of deployments. That is exactly why organizations like Berkvens are seeing results that go beyond a pilot, and why the gap between a promising demo and a dependable system is so much wider than most in-house build projects anticipate.
Moving from a pilot to operational success is less about ambition than about asking the right question at the start, focusing not on what to build, but on what the operation needs to be able to depend on, and where that trust actually comes from.
That shift in framing, is what separates the organizations that will have production-ready AI running in two years from the ones that will still be managing pilots.
