Why infrastructure, not models, is driving industrial AI adoption

Industrial AI's productivity gains aren't coming from frontier language models — they're coming from established techniques. What's finally making those techniques usable is better infrastructure underneath them.

The "other" industrial AI

For all the excitement around LLMs, the most significant industrial AI applications are iterative learning loops built around optimisation and statistical modelling. Teams run candidate experiments, update a model with the results, then use the updated model to decide what to test next.

Surrogates — fast statistical approximations of an underlying system — drive this approach. They don't remove the need for expensive evaluations; they reduce how many you need to reach a useful conclusion. The same pattern shows up across Design of Experiments, simulation optimisation and system calibration.

Classical DoE defines the experimental subset up front; adaptive methods like Bayesian optimisation refine the design as data arrives. By the 2000s, products like NUMECA FINE/Design3D, ESTECO modeFRONTIER and Siemens HEEDS had already made surrogate-based optimisation a market category. System calibration posed the same kind of problem — huge search spaces, expensive evaluations, the need to choose candidates intelligently — but adoption lagged well behind simulation optimisation. Not because of the methods, but because the supporting infrastructure was fragmented and expensive to integrate.

Why industrial AI was slow to take off

Simulation workflows generate inputs, outputs and metadata inside one coherent digital environment. Physical testing doesn't. Calibration data arrives in incompatible formats — LabVIEW TDMS files, proprietary DAQ systems, Excel spreadsheets, tools like ETAS INCA.

Before any model could recommend an experiment, teams faced months of data-engineering work just to unify those sources. That integration burden routinely exceeded the modelling itself.

The second barrier was expertise. The engineers who understood calibration constraints weren't the ones who understood the statistical methods — different vocabularies, tools and assumptions. Bridging the gap took rare hybrid specialists or embedded data scientists, so early wins clustered in flagship programmes with the budget for both.

What changed

Over the last decade the surrounding ecosystem matured. GPU-backed cloud computing cut the up-front infrastructure bill. Python became the common language across ML tooling. MATLAB and Simulink gained programmatic interfaces. Apache Kafka matured into a reliable way to route multi-source streams. Time-series databases got much better at high-rate sensor data.

At the same time, testing got harder — tighter emissions limits, more complex control systems, electrification, battery behaviour, motor control, hybrid powertrains — expanding the optimisation burden faster than teams could grow. Validated methods, rising automation pressure and mature infrastructure together created the commercial opening to productise what used to be bespoke.

How industrial AI was productised

Packaging these methods meant burying the technical choices inside software instead of asking engineers to specify kernel functions or compare acquisition strategies. Tools like Monolith AI's Next Test Recommender run several models at once, surface where they disagree, and present a ranked list of candidate tests.

Closed-loop optimisation also needs connected systems — test benches producing candidates, results ingested, surrogates updated, the next point selected and executed. Productising that means reusable connectors and orchestration rather than a custom integration per customer; Secondmind's work with Mazda is a good example of surrogates wired directly into a live calibration workflow.

And it needs interfaces engineers actually understand. Many projects stalled because the software expected data-scientist thinking. Productised tools expose sensitivity analysis, comparisons, traceability and explainability in engineering language instead. Underneath all of it sits the data backbone. Decades of historical campaign data are a competitive asset, so new systems have to integrate legacy results rather than discard them. This is the layer Quix provides — message brokers, data lakes and Python-based orchestration connecting simulations, optimisation components and physical systems, operationalising historical data alongside live streams.

What this means for R&D organisations

These shifts change the economics of adoption. Techniques that have existed for years become viable because the surrounding costs have fallen. Industrial data is still fragmented compared with mainstream software, but the reusable groundwork now exists — teams no longer have to assemble a proprietary platform before they can even start learning.

That moves the build-versus-buy line. Previously, applying these methods meant funding a strategic internal infrastructure effort — ingestion, time alignment, storage, orchestration, model execution, engineering interfaces — before you could even tell whether the optimisation logic paid off. Now many of those layers come off the shelf, and teams spend their effort on the problem-specific work: defining parameter spaces, choosing targets, validating recommendations, encoding domain knowledge.

Infrastructure doesn't remove the need for judgement. Someone still has to decide whether a target is meaningful, whether the data can be trusted, whether a recommendation is credible and when to stop. Productisation lowers the engineering prerequisite; it doesn't eliminate the need for engineers who understand both the system and the optimisation logic.

Conclusion

The recent attention on LLMs created a sense of urgency across engineering. But the near-term industrial gains are still coming from established methods — surrogates, adaptive experiment design, simulation optimisation, iterative calibration. Those methods were never really limited by model sophistication; they were limited by integration cost. The real shift isn't that new models unlocked engineering value — it's that the infrastructure and productisation needed to deploy the established methods has finally caught up to the methods themselves.