Getting a predictive model into the control room: what deployment actually looks like

Deployment is not uploading a model. It is connecting that model to data pipelines, operational systems, control room workflows, and decision ownership in a way that holds in production.

Across the eight articles that preceded this one, we have worked through the foundations of industrial AI productionisation, data readiness, signal creation, model building, experimentation discipline, pre-production validation. Each of those stages exists for a reason, but each of them produces something that is still, technically speaking, a research output. The thing that changes everything is deployment. That is the moment when the model stops being a data science asset and becomes part of how the operation runs.

And it is the moment that most industrial AI programmes underestimate. In our experience working with mining and industrial organisations, there is a persistent assumption that deployment is a technical step: take the trained model, package it, push it to a serving endpoint, and the work is done. That assumption is the source of a remarkable number of post-deployment problems. A model that is technically deployed but not operationally integrated is a model that produces outputs nobody acts on, alerts that go to inboxes nobody monitors, and predictions that have no path back into the decisions they were built to inform.

Stage 05 of the CoffeeBeans AI Productionization Value Chain is Model Deployment and Serving. It is the bridge between a validated model and an operational system. For a predictive maintenance model on a SAG mill, a process optimisation model on a flotation circuit, or a fleet decision support model in a haul truck operation, this is where the value either materialises or quietly evaporates.

A packaged model is not a deployed model

Four distinct states sit between training and operational integration

In industrial AI, the language around deployment often obscures more than it clarifies. Four distinct states matter, and they are not interchangeable:

• A trained model has learned a pattern from historical data. It can produce predictions on examples that resemble its training distribution. That is all it can do.

• A packaged model has been serialised into a form that can be moved between environments and executed elsewhere. It is portable. It is not yet running.

• A served model is hosted on infrastructure that can accept inputs and return predictions through a defined interface. It is running. It is not yet connected to anything operational.

• A deployed model is integrated into a workflow, a system, a user, a decision, and a monitoring process. Its predictions flow somewhere they will be acted on. Its failures are detected and responded to. Its outputs are owned.

All four states are necessary. Only the fourth produces business value. The most common deployment failure pattern we see in industrial AI is a model that has reached state three and stalled there — technically live, operationally invisible. The data science team considers the work complete. Operations never engages. Six months later, the programme is reviewed and judged to have underdelivered, when what actually happened is that the deployment was never finished.

A packaged model is not a production AI system. A served model that nobody acts on is not either.

What deployment actually looks like in a mining control room

The output of the model has to land somewhere a decision will change

A predictive maintenance model on a SAG mill bearing produces, every few minutes, a risk score and a recommended review window. That output is technically a model artefact. Operationally, it has to become an alert that reaches the right maintenance planner at the right time, with enough context for the planner to assess whether the recommendation is credible, and with clear ownership of the response.

Across mining operations, deployment looks different depending on the use case. Some examples we have seen repeatedly:

• A SAG mill failure risk model feeds into the maintenance planning system, where the planner reviews the recommendation alongside existing scheduled work and decides whether to bring forward an intervention.

• A conveyor downtime model pushes alerts into a reliability dashboard that the reliability engineer reviews on a defined cadence, with the option to escalate to the operations team.

• A crusher performance model informs shift-level decisions about feed rate adjustments, with the recommendation surfaced to the control room operator who decides whether to apply it.

• A pump failure model triggers a structured review by the maintenance team, with a defined response window and a documented protocol for action.

• A fleet optimization model sends dispatch recommendations to the dispatcher, who decides whether to act on the recommendation or override it.

In each of these cases, the model output is timely, understandable, actionable, and owned by a specific role. None of those properties is automatic. All of them are deployment work.

Batch and real-time inference solve different operational problems

Faster is not always better. The decision timeline determines the inference pattern.

One of the most common early questions in industrial AI deployment is whether the model should serve in batch or in real time. The technical instinct is often toward real time, on the assumption that faster predictions are always better. The operational answer is more nuanced. Faster inference is only valuable if the decision the model supports requires that speed.

Most predictive maintenance use cases in mining benefit from batch inference at shift or daily cadence. The maintenance team does not need second-by-second updates on bearing risk; they need a credible recommendation in time to plan the next maintenance window. Some process optimisation and safety-critical use cases require real-time inference industrial patterns, where decisions are made in minutes and the cost of latency is operationally significant. The right design follows from the decision cycle, not from technical preference.

Integration with operational systems is where deployment becomes real

Model serving must reach where operational decisions are already made

A served model in isolation is operationally inert. For deployment to deliver value, the model has to integrate with the operational systems that already define how the plant works. In mining environments, this typically means connecting to one or more of the following:

• SCADA and DCS systems. The systems where the plant is monitored and controlled. Model outputs that surface in the control operator's existing view are far more likely to be acted on than those that arrive in a separate dashboard.

• Process historians. Both as input sources for live feature pipelines and as logging destinations for model predictions over time.

• Maintenance and asset management systems. Where work orders are generated, scheduled, and tracked. A predictive model that creates planning recommendations should integrate with the work order workflow, not run in parallel to it.

• ERP systems. For asset hierarchy, spare parts inventory, and the business processes that maintenance decisions ultimately depend on.

• Operator interfaces and dashboards. Where alerts and recommendations are reviewed by the operations team.

• Alerting channels. Email, mobile notification, or control room display, depending on urgency and ownership.

Each integration is a deployment task in its own right. None of them is optional if the goal is operational value rather than technical milestone.

Why CI/CD matters for industrial ML

Deployment is not a one-time event. It is an ongoing operating discipline.

MLOps deployment serving is the broader discipline that turns deployment from a project milestone into an operational capability. Models change. Feature logic changes. Data pipelines change. Operating conditions change. New versions of models are trained and need to be released without disrupting the live service. Older versions must be archived or rolled back when problems are detected. None of this can depend on manual handoffs or undocumented procedures. It requires CI/CD discipline.

CI/CD for ML is the controlled process for testing, releasing, updating, and rolling back models and pipelines. In practical terms, it means new model versions move through automated tests against a defined dataset, are promoted through staging environments under documented criteria, and are released into production with full versioning and rollback paths. When a deployed model degrades, the rollback to the previous known-good version is a routine operational action, not a fire drill.

Operations teams notice the difference. A model deployment that comes with confident release and rollback procedures earns trust quickly. A deployment that depends on the data science team manually rebuilding the model each time something needs to change earns the opposite.

The leadership mistake we see repeatedly

Asking 'can it be deployed?' instead of 'can it be served reliably into the workflow?'

The most common leadership question at this stage is, can the model be deployed? The technical answer is almost always yes. Any validated model can be packaged and hosted. The question that determines operational success is different.

Can the model be served reliably into the workflow where a decision will actually change? That question requires evidence from system integration, latency testing, alert design, human review workflow, ownership clarity, and rollback procedures. It cannot be answered by confirming that the model has been packaged. It can only be answered by confirming that the operational handoff is in place.

What a production deployment actually requires

A practical checklist for the Stage 05 conversation

Across the engagements we have led, a production deployment in an industrial AI context typically requires the following to be in place before go-live:

• A validated model artefact from the model registry, with documented version and approval status.

• A connected feature pipeline generating production features that are verifiably consistent with the training pipeline.

• A serving architecture appropriate to the inference pattern — batch or real time — and the latency requirements of the decision being supported.

• Integration with operational systems — SCADA, DCS, historian, maintenance systems, ERP, dashboards — as required by the use case.

• Alert and dashboard design that surfaces predictions where the relevant role will see and act on them.

• A human review process with clear ownership of the decision the model is informing.

• Logging and audit trail capturing every prediction, every input feature, and every action taken in response.

• Error handling and latency monitoring with defined thresholds and escalation paths.

• CI/CD pipelines supporting controlled model updates, version promotion, and clean rollback.

• A documented ownership model answering who is responsible when the model is right, when it is wrong, and when the pipeline fails.

• A monitoring plan that connects directly to Stage 06 of the productionisation chain.

How Stage 05 connects to Stage 06

Deployment without monitoring is a deployment that will not last

Stage 05 cannot be considered complete without Stage 06. A deployed model that is not monitored will degrade silently. Input data quality will change. Operating conditions will shift. Feature distributions will drift. None of this will be visible until performance has already declined far enough for operations teams to notice through which point trust is harder to recover than it would have been to maintain.

Stage 06, Model Health and Performance, is the topic of the next two articles in this series. For Stage 05 purposes, the relevant point is that the deployment should be designed from the outset to support the monitoring discipline that will follow it. Logging, audit trails, performance baselines, and drift detection thresholds are deployment work, not afterthoughts.

How CoffeeBeans helps

From packaged model to operationally integrated AI

CoffeeBeans works with mining and industrial organisations to build AI model deployment mining infrastructure that closes the gap between a validated model and an operationally embedded AI system. Our Stage 05 engagements typically begin with the deployment architecture itself: whether the use case requires batch or real-time inference industrial patterns, what systems the model must integrate with, what latency and reliability the decision requires, and what the alert and human review workflow should look like.

From there, we operationalise the deployment. The serving architecture is built. Integration with SCADA, DCS, historian, maintenance, and ERP systems is engineered to fit the operational rhythm of the plant. MLOps deployment serving discipline is established — CI/CD pipelines, model registry promotion, rollback procedures, logging and audit infrastructure. Alerts are designed to be actionable. Ownership of the decision the model supports is made explicit. And the monitoring plan that Stage 06 will execute against is built into the deployment from day one.

The objective is not to put a model into production. The objective is to put a working AI system into operations, with the discipline that allows it to remain there. That distinction is what makes the difference between a deployed pilot and a productionised capability.

Is your AI model deployed, or is it operationally integrated?

If your industrial AI programme has produced validated models that have reached production technically but have not changed any operational decision, the gap is in Stage 05. CoffeeBeans can help your team design the deployment architecture, engineer AI model deployment mining integration with SCADA, DCS, and operational systems, and embed the MLOps deployment serving discipline that production AI requires to sustain itself. Talk to our Enterprise AI practice about deployment and serving in your operation.