Industrial MLOps as a Distributed Operating Model

Industrial MLOps is the discipline of managing ML systems across distributed environments with different trust boundaries, operational constraints, and availability requirements. When people talk about MLOps, they often imagine a fairly straightforward lifecycle.A team trains a model, validates it, packages it, and deploys it to production. Even if the infrastructure is split into development, staging, and production environments, those environments usually belong to the same IT landscape, have stable connectivity, and are managed according to relatively consistent principles. In an industrial company, that assumption often stops being true. A single ML system may span multiple geographic sites, cross corporate and technological networks, interact with industrial equipment, operate inside partially isolated segments, and still be expected to remain functional when connectivity to the central environment is temporarily unavailable. That is why industrial MLOps is not simply “more complex CI/CD for models.” It is about managing ML systems across distributed infrastructure with different trust boundaries, operational constraints, and availability requirements. To make this less abstract, I will use a fictional company throughout the article: Northstar Mining Group. Northstar is a hypothetical mining company with a central office and several mineral processing plants: Aurora Plant, Red Valley Concentrator, and Silver Ridge Processing Site. All names are fictional and do not represent the architecture of any real company. One of Northstar’s ML use cases is a flotation optimization model. It analyzes ore characteristics, slurry parameters, reagent consumption, aeration indicators, and other process variables to recommend operating conditions that can improve recovery or reduce unnecessary reagent consumption. This example makes it easier to see why industrial MLOps quickly becomes more complex than a conventional centralized ML environment, regardless of whether the underlying infrastructure is cloud-based, bare metal, or hybrid. Northstar Mining Group, a fictional mining company used in this article to illustrate distributed industrial MLOps across multiple production sites. One ML Lifecycle, Multiple Operational Environments In a large industrial company, MLOps rarely lives inside a single platform. Some systems are used for model development and training. Others support centralized governance or enterprise ML services. Others are directly connected to local production operations. A typical landscape may include a corporate IT environment, a corporate data network, a DMZ or transfer zone, a technological network at the site, and local production segments. It is useful to define three terms first and explain why industrial architectures separate these environments in the first place. Corporate Network A corporate network is the environment where conventional enterprise IT systems operate: employee-facing services, business applications, analytics solutions, development environments, data stores, and centralized infrastructure services. Its role is to support the company’s business and IT operations: connect offices and data centers, provide access to enterprise systems, and support analytics, software development, ERP, BI, storage, and other shared services. For ML, this is often the most convenient environment for development, training, experimentation, model registry operations, and centralized lifecycle management. But a corporate network is usually much more open by nature than a technological network. It contains more users, integrations, external services, and frequent changes. Giving it unrestricted access to systems that directly affect production would therefore create unnecessary risk. Technological Network A technological network, often referred to as an OT network, supports the production process itself. It may contain automation systems, SCADA, industrial servers, sources of process signals, equipment, and systems interacting with industrial control systems. Its primary purpose is to keep production stable and predictable. The priorities here are different from those of corporate IT. In a normal business system, an update may be scheduled, a service may be restarted, or some functionality may be temporarily unavailable. In an industrial environment, any change is evaluated first in terms of its potential effect on the production process. As a result, technological networks are usually more isolated, changes are controlled more strictly, and interactions with external systems are limited. For ML, this means that inference used directly in production may run here, closer to the equipment and the process data. DMZ Between corporate and technological environments, there is often a DMZ — Demilitarized Zone. A DMZ is an intermediate network segment between environments with different levels of trust. Its purpose is to prevent unrestricted direct communication between them and instead provide a controlled area through which only approved interactions are allowed. This matters especially in industrial environments for a simple reason: compromising an employee workstation or an ordinary IT service should not automatically provide a path into production systems. An employee could, for example, open a malicious email attachment. If the corporate and technological networks were directly connected with broad trust between them, that incident could potentially spread much further. Segmentation and a DMZ help reduce that risk. A DMZ may contain intermediary exchange services, proxies, controlled gateways, registry mirrors, malware and security scanning services, telemetry transfer services, or other components that allow systems in different zones to communicate without establishing direct network trust. This becomes particularly interesting from an MLOps perspective. Suppose Northstar Mining Group prepares a new version of its flotation model in the central ML environment. That model should not necessarily be able to travel directly from the central model registry into a runtime inside the technological network at Aurora Plant. Instead, the artifact may first enter a controlled intermediate zone, where its origin, integrity, and authorization for further promotion are verified. Only then does it become available inside the technological environment. In industrial MLOps, the DMZ solves more than a networking problem. It can become a controlled transition point for model artifacts moving between trust zones. It is important to note that a DMZ is not the only possible mechanism and should not be treated as a mandatory universal architecture.Different companies may use different segmented environments, transfer zones, gateways, or dedicated exchange services. The important part is this: between corporate IT and the production environment, there is typically a controlled boundary rather than unrestricted network connectivity. This separation serves several purposes. It reduces the blast radius of an incident: a compromise in a corporate system should not automatically result in a compromise of the technological environment. It also allows different security policies to be applied. The security requirements for an analyst’s laptop are obviously not the same as those for a system involved in a production process. The technological environment can also be protected from overly frequent change. Corporate IT may receive updates daily, while stability in a production OT environment is often more important than speed. And finally, segmentation makes it possible to control exactly what data, software artifacts are allowed to cross the boundary. For example, aggregated ML metrics may be allowed to leave the site while raw process signals remain inside. In the other direction, only signed and approved model artifacts may be allowed in, rather than arbitrary containers. So network segmentation in industrial environments is not just architectural bureaucracy. It is a way to separate systems with different costs of failure and different trust requirements. The names and exact design of these environments vary from company to company, but the architectural problem remains the same: Models, containers, datasets, and other ML artifacts cannot move freely across all environments in the same way they often can in a more conventional centralized environment. Let us return to Northstar Mining Group.Historical data from several processing plants may be collected in a central analytical environment. There, the Data Science team trains a new version of the flotation model. Suppose the new model identifies a more effective relationship between particle-size distribution, collector dosage, froth level, and metal recovery. But training the model is only half the job. The model must eventually run at Aurora Plant, where process data originates in the local production environment and where its recommendations may be used by operators or other systems during the actual flotation process. This means the model is developed in one environment but has to deliver value in another — often a more restricted, operationally critical production environment. The challenge therefore goes beyond deployment: the model has to cross operational and trust boundaries before it can create value in production. The company must decide which artifact is allowed to cross the boundary, who may initiate the transfer, where the checks take place, which data is allowed to return to the central environment, and what happens to the ML service if the site temporarily loses connectivity. In other words, industrial MLOps is also about managing transitions between trust zones. The DMZ Stops Being “Just a Network Component” In traditional architecture, the DMZ is primarily discussed as a network security mechanism. In an industrial ML landscape, it effectively becomes part of the model supply chain. Imagine that Northstar Mining Group has prepared Flotation Optimizer 4.2. In the central environment, the model has passed technical validation and been compared with its previous version. The team confirms that, on a validation dataset, it improves the prediction of optimal reagent dosage without degrading the target recovery metrics. The model is then approved for production use. But between that approval and the actual launch at Aurora Plant lies another important part of the lifecycle: crossing into the technological environment. The artifact may enter an intermediate DMZ, pass additional checks, and only then become available inside the site environment. Simply copying the file is not enough. The company needs to know whether the version entering the technological environment is really the approved 4.2. Has the artifact changed during transfer? Does its digest match? Who initiated the promotion? Is this specific version authorized to run at Aurora Plant? Consider a simple error. An engineer needs to transfer flotation-model-4.2, but an experimental version with a similar name is stored in the same intermediate location. In a fully manual process, a human mistake could result in a technically valid but unapproved artifact reaching the technological environment. The container would start. The endpoint would respond. Infrastructure monitoring might show nothing unusual. Yet production would already be running a different model from the one the company believes it approved. This is where MLSecOps enters the picture. The goal is no longer simply to deliver the model. The goal is to preserve a chain of trust from the training run all the way to the specific production runtime. Corporate and Technological Networks Have Different Priorities The distinction between corporate and technological environments is fundamental to industrial MLOps. The corporate network is optimized primarily for IT. This is where development, analytics, enterprise applications, centralized services, and storage systems live. The technological network exists primarily to support production. At a mineral processing plant, it may contain systems receiving data from flow meters, level sensors, and analyzers, as well as information about flotation cells, air flow, reagent dosage, slurry parameters, and other process characteristics. And the priorities are different. A few minutes of downtime in a corporate analytics system may mean nothing more than a delayed report. In a production process, the cost can be very different — and much more tangible. A temporary loss of an ML service may lead to suboptimal operating conditions, higher reagent consumption, lower recovery, reduced throughput, or additional operator intervention. For example, if a flotation optimization model helps reduce reagent overuse by even a small percentage, several hours of downtime may translate directly into unnecessary operating costs. If the model also supports decisions that affect recovery, the financial impact may be larger still because even a small degradation in process efficiency can accumulate across high-volume production. Suppose Northstar’s model evaluates the flotation process every few minutes and recommends adjustments to the operating regime. If Aurora Plant loses connectivity to the central office, it would make little sense for local inference to stop simply because a central service is unavailable. The architecture may therefore need to support autonomous local ML runtime operation. The model continues to receive approved process features, generate predictions, and store local metrics. Once connectivity is restored, accumulated telemetry can be synchronized with the central system. That leads to an important assumption in industrial MLOps: The central environment may become unavailable, but local production must continue to operate. That assumption changes the architecture significantly.You need to think in advance about local artifacts, model state, telemetry buffering, fallback scenarios, and rollback without relying on access to a central registry. Central Governance Is Not the Same as Remote Control Centralization in industrial MLOps does not mean that a central team should directly control every production runtime. Northstar Mining Group does not need an architecture where an engineer at headquarters receives direct administrative access to Aurora Plant’s technological systems every time a new model is released. A more mature model separates governance from execution. The center defines that Flotation Optimizer 4.2 is an approved version, which types of plants it is authorized for, which configuration is considered the target state, and which checks must be completed. The local environment is responsible for execution within those rules. After deployment, the center needs confirmation of the actual state. For example, the corporate team may see that Aurora Plant is already running 4.2, Red Valley is still on 4.1, and Silver Ridge has temporarily returned to the previous version after a local rollback. This is the model: Central governance + local execution It is fundamentally different from the idea that “the center should be able to do anything on every plant.” The value of centralization lies not in total remote control, but in having a single source of truth and a governed lifecycle. Data Flow and Model Flow Do Not Have to Follow the Same Route The flotation example highlights another important feature of industrial ML. Data and models may move through the infrastructure in completely different ways. The model may depend on process parameters such as slurry characteristics, analyzer readings, air flow, tank levels, reagent dosage, and the current state of the equipment. But that does not mean the entire stream of raw industrial signals needs to be continuously sent to the central infrastructure. Some data may not be allowed to leave the technological environment at all. Some may be aggregated locally. The central environment may receive only prepared historical datasets or a specific set of approved features. The model itself travels in the opposite direction: a new approved version is created centrally and delivered to the site. Telemetry forms a third logical flow. The center may receive the active model version, inference latency, error counts, distributions of selected approved features, drift indicators, and aggregated model-quality metrics. Meanwhile, the raw technological data remains at the plant. As a result, a single ML use case can involve several architecturally independent flows: production data, model artifacts, and operational telemetry. Each may be governed by its own security rules. One ML use case does not imply one infrastructure flow. Data flow, model flow, and telemetry flow may follow different routes, cross different boundaries, and be governed by different security policies. This is another reason why industrial MLOps cannot be reduced to “CI/CD, but for models.” Monitoring Is Distributed by Design In a more conventional centralized IT or ML environment, production workloads often have stable connectivity to a shared observability stack. In industrial environments, that assumption may no longer hold. Imagine Aurora Plant located far from the company’s central infrastructure. The local ML service continues to run, but connectivity to the corporate environment disappears for four hours. If monitoring is designed under the assumption that connectivity always exists, the center simply sees the metrics disappear. That creates ambiguity. Did the model fail? Did the site lose connectivity? Is the problem only in the network link? Or did telemetry stop being exported because the local collector failed? Industrial monitoring therefore often needs to be hierarchical. Metrics are collected close to the runtime, stored or aggregated locally, and then an approved subset is transferred to the central observability system. Once connectivity returns, buffered telemetry may be sent later. That creates another architectural question: what exactly is allowed to leave the site? For example, the central team may only need to know that Aurora Plant is experiencing increased drift in the metal-content distribution of incoming ore. It does not necessarily need the full stream of process data. This means that even the seemingly simple requirement to “show the status of all production models on one dashboard” becomes significantly more difficult when those models operate behind different network boundaries. Geography Turns One Model Into Many Production Systems Now imagine that Flotation Optimizer is no longer deployed only at Aurora Plant. It is running at seven Northstar Mining Group processing sites. The Data Science team may still talk about “the flotation model.” Operationally, however, there are now seven different production installations. Aurora Plant runs version 4.2. Red Valley remains on 4.1 because local validation of the new version has not yet been completed. Silver Ridge has deployed 4.2 but uses a different threshold for one of its alerts. West Creek runs a site-specific variant because the characteristics of its ore are significantly different. Another plant has temporarily rolled back after a change in its upstream data pipeline. The managed object is therefore no longer simply Flotation Optimizer 4.2. It is something more complex: model version + configuration + runtime + site context That is why industrial MLOps increasingly starts to resemble fleet management. The company is no longer managing one model. It is managing a fleet of production installations of that model. Why You Cannot Simply Copy a Flotation Model to Another Plant This is particularly important in industrial ML. Suppose the model performs well at Aurora Plant, and the business wants to deploy it at Red Valley. From a software perspective, this looks simple: take the same container image and run it at the second site. But the two plants may operate under different physical conditions. Aurora Plant may process ore with one mineral composition, while Red Valley processes another. The plants may also differ in grinding settings, water chemistry, equipment, analyzer types, reagent schemes, and normal operating ranges. As a result, the same input feature can behave differently at each site. For example, at Aurora Plant the metal content in the feed may usually stay within a relatively narrow range. The model has seen many examples from that range during training. At Red Valley, the same feature may vary much more widely. The container can start successfully. The API can return predictions. Infrastructure monitoring can show that everything is healthy. But the model may now receive values that were rare or almost absent in its training data. That means a successful deployment does not automatically mean a successful ML rollout. Before using the model at a new site, the team may need to validate it on local historical data, compare feature distributions, check whether preprocessing is compatible, define a local baseline, and adjust thresholds or other configuration if necessary. The first weeks of operation may also require closer monitoring to confirm that the model behaves as expected under local production conditions. Importantly, this adaptation process should not rely on engineers repeating the same checks manually for every new site. A mature MLOps process can automate much of this work: validating local data schemas, comparing feature distributions with the reference site, checking preprocessing compatibility, running predefined acceptance tests, applying approved site-specific configuration, and enabling enhanced monitoring during the first stage of operation. The goal is not to eliminate local validation, but to turn it into a repeatable and auditable workflow rather than a collection of manual actions performed differently at every plant. That is why an industrial rollout is not just about deploying the same software somewhere else. You are transferring a model into a different physical and statistical environment — and the process of validating that transition should itself be standardized and automated. Same model artifact, different site context: local operating conditions can change how the model behaves in production. Rollback Often Needs to Be Available Locally Consider another scenario. Version 4.2 has been deployed at Aurora Plant. A few hours later, local monitoring detects unusual model behavior under a rare flotation regime. The central team decides to return to 4.1. In a more conventional centralized environment, the previous image might simply be pulled from a shared registry. But if the site has lost connectivity to the central environment at that moment, such a recovery strategy becomes unreliable. The previous approved version may therefore need to be stored inside the local environment in advance. A compatible runtime configuration and the information required for recovery should be available locally as well. The site can then return autonomously to the last known good state. Once connectivity is restored, the rollback event can be synchronized with the center. This is a good example of how industrial network constraints translate directly into MLOps lifecycle requirements. External Contractors Add Another Layer of Distribution Let us make the example slightly more complex. Suppose the local ML infrastructure at every Northstar Mining Group processing plant is operated by engineers from an external contractor. Outsourcing itself is not the problem. The company may quite reasonably choose not to maintain its own infrastructure team at every remote site. The problem begins when the operating model looks like this: The contractor receives the required access and manually does whatever is necessary. At Aurora Plant, one set of local scripts appears.At Red Valley, another engineer organizes deployment slightly differently. At Silver Ridge, model configuration is manually changed after approval over a phone call. After a few years, what is formally one corporate ML system has turned into a collection of slightly different local implementations. There is also a security issue. If a contractor’s engineer needs to “be able to deploy the model,” they are often given relatively broad access. But being able to perform a deployment is not the same as being able to modify the production environment arbitrarily. A more mature MLSecOps approach defines not only which systems a person can access, but also which lifecycle actions they are authorized to perform. For example, a contractor may be allowed to initiate deployment of version 4.2 if that version has already received production approval and is explicitly authorized for Aurora Plant. At the same time, that engineer should not necessarily be able to replace the model artifact, promote an experimental version to production, or bypass required controls. This is least privilege applied to the ML lifecycle. In Industrial MLOps, Model Lineage Is About More Than Model Origin In conventional MLOps, model lineage usually means being able to reconstruct where a model came from: which data it was trained on, which code produced it, which training run generated it, and which model artifact eventually reached production. In other words, you need to be able to answer: How did we get this particular model? In a distributed industrial environment, that is not enough.After training, the model may pass through several validation stages, cross network boundaries, reach a remote site, and receive a local configuration there. So a second question becomes just as important: How exactly did this model reach this particular production runtime, and what is actually running there now? Let us return to Northstar Mining Group.Suppose that six months after an update, the flotation model at Silver Ridge begins generating unusual recommendations for reagent dosage. The team wants to understand why. Checking the training run alone is not enough. Even if the centrally produced model was trained correctly, the problem may have appeared later. The site may have received an older artifact. The artifact itself may differ from the one that passed approval. A different configuration may have been used during deployment. A threshold or preprocessing step may have been changed locally. Or the central catalog may report 4.2 as the production version while the actual runtime at Silver Ridge is still using 4.1. The investigation therefore needs to reconstruct two related histories. The first is the model’s origin: data, code, training run, validation results, and the approved model artifact. The second is its production history: which artifact was authorized for transfer, which version and checksum crossed the environment boundary, when it arrived at the site, who initiated the deployment, which configuration was used, and what is actually loaded in the runtime now. In industrial MLOps, lineage therefore expands: from model provenance to provenance of the production state And that has very practical value. If this traceability exists, an incident team can quickly compare the approved state with the actual state and identify where the divergence occurred. Without it, incident investigation becomes an exercise in reconstruction: correlating model registry data, CI/CD logs, artifact transfer records, site-level configurations, contractor tickets, and employee messages. For one model, that is inconvenient. For dozens of models across dozens of geographically distributed sites, it becomes a significant operational risk. Industrial model lineage: tracing both how a model was created and what is actually running in production. Why MLOps and MLSecOps Are Hard to Separate Here Industrial ML makes it particularly obvious how artificial the separation between MLOps and security can become. Before a new flotation model can reach production, you already need to answer security questions. Who is allowed to approve it? Who can transfer the artifact across a boundary? How is its integrity verified? Which identity performs the deployment? What can an external contractor do? Which telemetry may leave the technological environment? Security is therefore not something added after the MLOps lifecycle has already been designed. It is embedded in the lifecycle itself. A useful way to describe the difference is: MLOps: How do we manage the lifecycle of the model? MLSecOps: How do we prove that every stage of that lifecycle was executed in a trusted and authorized way? In industrial environments, the second question is often almost as important as the first. From an ML Pipeline to a Distributed Operating Model Ultimately, industrial MLOps is more useful to think of not as a single pipeline, but as a distributed operating model for ML. It connects centralized development, model governance, security controls, network boundaries, local production environments, external contractors, telemetry, and geographically distributed sites. Let us return to Northstar Mining Group one final time. The flotation optimization model may be developed by a central Data Science team. At Aurora Plant, it operates autonomously inside the technological environment. At Red Valley, the new version is still undergoing local validation. Silver Ridge runs the same approved model artifact as Aurora Plant, but with a different site-specific runtime configuration around it — for example, local alert thresholds, monitoring baselines, or integration settings adapted to the plant’s operating conditions. The center does not need to manage every inference request or directly administer every site. But it does need to know which version is running where, which artifact was approved, where the actual state diverges from the target state, and how healthy the overall fleet of ML systems is. What should be centralized is primarily governance, the source of truth, approval logic, visibility, auditability, fleet-wide monitoring, and security policy. Execution can remain local. That leads to one of the most useful operating principles for industrial MLOps: Central governance + local execution A digital company often focuses on optimizing the path from commit to production. An industrial company has to manage a much longer journey: from experiment to the safe operation of a model inside a specific technological zone at a specific remote industrial site — and back into central visibility. That is what makes industrial MLOps fundamentally different — it evolves from a deployment pipeline into a distributed operating model.