The industrial AI trap: when transformation thinking kills real progress
Posted in Blog on February 23rd, 2026
Most digital transformation programmes are doomed from the start.
Three quarters of UK manufacturers plan to invest in digital technologies, AI and automation this year. The intent is clear, but the results, often, are not. Research shows that 70% of transformation initiatives – whether digital, AI, or cloud – fail to meet their objectives. Not because the technology is flawed, but because transformation has become the strategy when it should be the outcome.
Here’s what that looks like in practice. Companies launch enterprise-wide transformation programmes – new platforms, new infrastructure, multi-year roadmaps. But too often these programmes are built around theoretical best practice rather than real-world problems, and they fail to translate into operational impact. So, you expend time and money with no return on investment.
Meanwhile, an engineer using ChatGPT performs a quick machine learning pilot that genuinely solves a planning bottleneck. It works, and operations want it – but it can’t be deployed. It’s been created off-piste without governance or security clearance, and outside the bounds of the enterprise architecture. So, the pilot that solves a real problem stays a pilot.
The question isn’t whether to invest in AI. It’s whether you’re solving real problems or chasing transformation for its own sake. And if you’re solving real problems, how do you ensure they’re the right problems – the ones that scale from proof-of-concept to genuine operational impact?
Technology evolves, but the core industrial problems haven’t changed. Productivity gaps, unaccounted downtime, quality failures, planning bottlenecks – these have persisted for decades. What has changed is how we solve them. Data science and AI offer genuine opportunities to address expensive operational failures, but only with deliberate deployment and the right governance from day one.
At ITI Group, data science has always been at the core of our solutions. Our approach to AI and machine learning is built on a simple principle: solve discrete operational problems, one at a time, with scalability built in from the start.
Problems first, platforms second. The cumulative effects are transformational.
1. Why AI projects hit a wall
Most AI projects stall because companies fall into one of two traps. Both start with good intentions. Both end at proof-of-concept.
i. The infrastructure-first trap
One of the most common mistakes when industrial operators build digital or AI infrastructure is starting with technology instead of intent.
Too often, organisations invest heavily in data platforms, data historians, cloud stacks, or AI tools. They connect machines and systems because that’s what the industry expects; they collect vast amounts of data without a clear idea of how it will be used. The result is often technically impressive infrastructure that delivers very little business value.
This happens for understandable reasons. There’s a real pressure to be “AI-ready”, but when the reasoning behind this isn’t interrogated, infrastructure projects become capability-led rather than problem-led.
The core problem is data without decisions. AI in industrial operations only creates value when it improves a decision, automates an action, or changes a behaviour on the shop floor or in planning. When organisations say, “We have the data, but we’re not sure what to do with it yet,” they’ve got the sequence backwards.
The better sequence is: what problems are causing the biggest headache? Who deals with them, and when? What data would change those outcomes? Only then: what infrastructure is actually required?
Without that chain, AI becomes an experiment rather than an operational capability.
ii. The pet project trap
If one common mistake is building infrastructure before intent, the opposite mistake is allowing brilliant local digital pilots to grow in isolation.
Often the most effective digital and AI solutions come from process engineers solving a chronic quality issue, maintenance teams building simple predictive tools, or shop-floor teams automating reporting or decision support.
These pilots solve real operational problems, deliver measurable benefits quickly, and are trusted by the people who use them – and yet, they rarely scale.
The issue is not that the pilots are too simple or not strategic enough. It’s that they are usually built around local knowledge, data extracts, or spreadsheets that don’t use tools and systems that can scale. They’re hard-wired to specific machines, lines, or products, and they’re owned by individuals rather than the organisation. They are detached from MES, governance, compliance and – all too often – cyber security standards.
From the pilot team’s point of view, this makes sense – they optimise for speed and impact. But from an enterprise point of view, it creates fragility. For example, when the engineer moves role, the solution remains static or dies, or when another site wants it, it can’t be replicated.
This is where many digital strategies fail. Too much control and innovation slows, engineers disengage and become cynical of digital solutions, and problems stay unsolved; but too little control and solutions fragment, value stays local and can’t scale.
The role of a good digitisation and data strategy is not to eliminate pilots – it’s to turn the good ones into products.
When infrastructure is built only top-down, it lacks relevance. When solutions are built only bottom-up, they lack scale, impact and longevity. AI in industrial operations succeeds when real operational problems drive innovation, and these are solved within existing infrastructure.
2. The two-part methodology
Avoiding both traps requires the same starting point: a specific operational problem worth solving.
Here’s the approach that works
i. Start with the problem you’re trying to solve
Technologies evolve, but problems often remain the same. AI technologies are tools and should be used as such. Rather than asking, “what can AI do for us?”, instead ask, “what novel solutions could AI bring to our core operational problems?”
Flipping the narrative avoids implementing AI because it fits a process, rather than because that process is costing you money. Without this discipline, you expend time and money with no return on investment.
The tools available now span from traditional machine learning for prediction and optimisation, to natural language processing for conversational interfaces, to computer vision for quality control and safety monitoring. Machine learning excels at pattern recognition, anomaly detection and prediction – the more powerful your datasets (MES, historian, quality, maintenance, schedule), the more potential value you can unlock.
In industrial environments, this could mean predictive maintenance combining condition monitoring, equipment telemetry, alarm data, cycle times and vibration data to predict failure probability and remaining useful life. Or quality prediction using process parameters, environmental data, operator information and batch data to flag quality risks before waste and scrap occur. Or computer vision systems monitoring production lines to identify defects or irregularities in real time.
The technology choice comes after the problem identification – never before.
ii. Build your cake slice by slice
Once you’ve identified your most important operational challenges, you need to move quickly. The tools available now – from traditional machine learning for prediction and optimisation to large language models (LLMs) for analysis – let us implement pilot projects much faster than before. Test in simulation, prove value, then expand to live operations.
Think of each challenge as a slice of cake – you need to go narrow and deep and build each slice to create the entire cake, rather than building the whole cake a layer at a time.
Don’t build all your network infrastructure, integrate all your systems, get all your data and then decide what to do with it. Focus on building a “slice of the cake” – a pilot or MVP that gives you the small piece of infrastructure, integration and data you actually need to solve your problem. Then solve the problem, prove the value and justify the investment for building more and more of the cake – one slice at a time.
But here’s the critical difference from the pet project trap: each slice is built with the governance and architecture required for production from the beginning. It’s not a local hack that can’t scale, but a solution designed to deploy, integrate with operational and information systems, and replicate across sites at enterprise scale.
Image caption: each ‘slice’ contains the infrastructure, integration, and data needed to solve one specific operational problem – then you build the next slice
Case studies
This is what the methodology looks like in proof-of-concept projects with industrial process businesses. The same principle holds: start with the real problem, build the specific solution, prove the value.
A global energy company needed to improve the accuracy of production planning job durations.
We trained a regression model based on historical OEE data to predict run times, factoring in performance losses, unplanned stoppages, team, shift and product variables. We used Python ML libraries in Azure ML Studio.
The model delivered a 20% improvement in the accuracy of planned job durations compared to current practice. Plans became more realistic, generating operator buy-in and resulting in a reduction in overtime.
Proven across sectors
The same methodology applies across sectors, operational challenges, and AI approaches
Each validated the core principle: start with the real problem, build the specific solution, prove the value.
A major operator had legacy PLC code available only as screenshots. We trained an image recognition model to interpret PLC function blocks and accurately convert code, resulting in automated conversion of PLC code, reduced errors in conversions, and removal of legacy hardware.
A pharmaceutical manufacturer needed to address batch quality. We used machine learning to compare historical batches with current batch data to spot anomalies and operator steps performed incorrectly. Alerting operators to deviations from norms avoided batches being scrapped or requiring rework.
A critical facility needed to improve upon a rule-based approach. We combined reinforcement learning with simulation to test and refine the existing approach. The reinforcement learning approach outperformed the existing rule-based method – if extended beyond proof of concept, it would lead to improvements in throughput and safety for critical emptying operations.
3. Scaling with governance
Building slice by slice only works if each slice is built to last. Using simulation, you can test “before and after” scenarios in a virtual environment while operations continue as normal. Governance ensures every slice of the cake has the security protocols and architecture required for production – so that you can keep building.
The key is introducing governance at the right point – not so early that it kills speed and experimentation, but not so late that pilots become impossible to scale. Build it into the design from day one, not as an afterthought. When you start with a real operational problem and design the slice to solve it, you can simultaneously design for production deployment – the right data sources, the right integration points, the right security standards.
This way the first slice takes longer to build than a quick hack, but the second slice is faster, the third faster still. And crucially, they can all talk to each other because they share the same foundations.
Conclusion
If you’re planning AI investment this year, the question isn’t whether the technology works. The question is whether you’re deploying it to deliver real value.
Work with partners who start with your most expensive, discrete problem; solve it with a single slice; then do it again.
Solve the problem, prove the value, scale what works. That’s how transformation actually happens – not as a declared programme, but as the cumulative effect of solving real problems one at a time.
Three quarters of UK manufacturers are planning AI investments this year, which means your competitors are making the same decision you are: transformation-first or problem-first.
If you choose problem-first, you will move faster. Your first slice will deliver value while others are still building platforms; your second slice will be live while others are still in workshops. Value compounds because each solved problem creates the foundation for the next.
By the time a transformation-first business has finished building its platform, a problem-first business has already solved multiple operational failures. The gap isn’t just technical, it’s competitive.
So, the choice isn’t whether to invest in AI; it’s whether to spend the next twelve months solving problems – or building programmes that promise to.