Right now, many organizations are answering that question with the same instinct: let's build it ourselves. And the logic is sound, up to a point. AI has made creating software dramatically faster and easier. A capable engineer can prototype a connected-maintenance tool in an afternoon. A continuous improvement specialist can have a working dashboard before the end of the week. For internal tools with a small blast radius - a tracker used by one team, a report visible only to a department - that instinct is not just defensible, it is probably right. Building those things develops AI literacy in-house, and that matters. The organizations that will use industrial AI well in five years are the ones learning how it works today.
The problem is not building. The problem is when something built for one team's visibility quietly becomes the system an entire plant depends on. That transition - from useful internal tool to operational infrastructure - is where the logic of building starts to break down, and where the real cost surfaces. Not on the day the prototype is finished, but six months later, when the person who built it has moved on, the integration with the ERP has started producing errors nobody knows how to diagnose, and the audit requires documentation the system was never designed to produce. Building something is not the same as running it. And in industrial operations - where assets cannot fail, audits are non-negotiable, and the experienced workforce is retiring faster than it can be replaced - the gap between those two things is where the bill arrives.
The bill arrives later
McKinsey and the Standish Group's 2024 CHAOS Report documented what most internal IT teams already know from experience: large custom software projects run an average of 45 percent over budget and deliver 56 percent less value than planned. More than a third are abandoned entirely before they ever reach production.
Those numbers do not come from organizations that lacked ambition or talent. They come from the structural reality that building software and operating it successfully in a complex industrial environment are fundamentally different disciplines. The prototype is always the cheapest part. Forrester's 2024 research puts it precisely: roughly 78 percent of a software system's lifetime cost accrues after launch - in maintenance, security patching, integration work, and the ongoing overhead of keeping something alive that the business now depends on.
In a manufacturing plant or a utility network, that overhead does not sit quietly in a backlog. It pulls your best engineers away from the operation itself. Every hour spent troubleshooting an integration with the enterprise resource planning (ERP) system, managing a model update that broke something, or rebuilding a report that stopped working is an hour not spent reducing unplanned downtime - which, according to Siemens' 2024 research, costs the world's 500 largest companies $1.4 trillion every year.
You can only ask what you already know
There is a subtler problem that rarely comes up in the build-versus-buy conversation, and I think it is the most important one.
When an internal team builds an AI solution, the output reflects the knowledge already in the room. If the engineer writing the prompt has never seen how maintenance operations at a hundred different plants have approached failure classification, or how the most reliable organizations structure their preventive maintenance cycles, those insights never make it into the application. AI is only as useful as the operational context behind it. If it lacks the institutional knowledge and doesn't understand asset hierarchies, maintenance histories, safety logic, and proven workflow patterns, you risk digitizing current practice without improving the way work gets done.
This is the difference between a tool that digitizes your current practice and a platform that carries the accumulated experience of thousands of real operational deployments. The former is faster to build. The latter is worth more on day one, and compounds in value every year after.
I often use what I call the Excel guru scenario to make this concrete. Every organization has one - the person who built a magnificent, intricate spreadsheet that now runs a critical process. It works beautifully, until the formula breaks, the data structure changes, or the guru accepts a better offer. AI-built internal tools carry the same risk, only with higher operational, security, and compliance stakes.
The audit question nobody asks in the planning meeting
For organizations in regulated industries - chemicals, energy, utilities - there is a third dimension that tends to surface at the worst possible moment: traceability.
An auditor does not care whether your AI tool works. They want to know whether you can demonstrate, precisely and completely, what every operator saw, on every shift, in every location, and who changed what and when. That level of traceability cannot be bolted on after go-live; it must be designed into the operational architecture.
Veracode's 2025 research found that AI-generated codebases contain 2.74 times more security vulnerabilities than their human-written equivalents. For teams building internal tools with generative AI assistance, this is not a theoretical concern. It is a compliance exposure that becomes visible the moment an ISO 55001 audit, an OSHA inspection, or an FDA 21 CFR Part 11 review asks questions the system was never designed to answer.
What this means in practice
None of this is an argument against using AI. The opposite, in fact. The organizations getting the most from industrial AI right now are the ones who made a clear-eyed decision about where to invest their energy.
At Berkvens Doorsystems, AI agents now save each team lead 30 to 60 minutes every morning and match their manual analysis at over 95 percent accuracy. That result did not come from building something from scratch. It came from a platform that already understood asset hierarchies, maintenance workflows, and operational context, and from a team that focused their expertise on the operation rather than on owning the software.
The real question industrial leaders need to put on the table is not "can we build this?" Almost anyone can build something today. The question is: "Is building this the best use of critical resources: our team's time, attention, and expertise - and can we operate it reliably, securely, and at scale five years from now?"
For most industrial organizations, the strongest path is to choose a platform already built for the way work gets done in maintenance and operations. Choosing a platform that already understands asset hierarchies, maintenance workflows, safety requirements, and operational governance keeps scarce internal expertise focused where it matters most: improving performance, increasing safety, and keeping operations moving.
