MLOps Explained: 5 Stages Worth Getting Right

MLOps is the discipline of getting machine learning models into production and keeping them useful there. Most models that fail do not fail in training. They fail months later, quietly, when the data changes and nobody notices. MLOps exists because a trained model is a small part of a working system, and the rest of that system has to be built, tested, deployed and watched like any other software.

Updated September 2026. Pay and hiring figures are from the sources named and change quickly.

What MLOps actually means

Google Cloud’s reference architecture defines the practice as “an ML engineering culture and practice that aims at unifying ML system development (Dev) and ML system operation (Ops)”. The point of that phrasing is that MLOps is not a product you buy. It is DevOps adapted to a component that degrades on its own, because the world the model learned about keeps moving.

The best-known evidence for why this matters is a decade old. In Hidden Technical Debt in Machine Learning Systems, presented at NIPS in 2015, Sculley and colleagues at Google argued that real-world machine learning systems carry massive ongoing maintenance costs, and catalogued the causes: entanglement, hidden feedback loops, undeclared consumers, unstable data dependencies and configuration sprawl. Google Cloud’s MLOps guide adapts their central illustration, in which the ML code is only a small fraction of a real system, surrounded by configuration, data collection, testing, resource management, serving infrastructure and monitoring.

The 5 stages every model must survive

This is the loop that MLOps automates. Each stage is a place where a model that looked fine in a notebook stops being fine.

1. Data and features. Collecting, validating and transforming the inputs. If the features computed at serving time differ from the ones used in training, the model is wrong before it starts.
2. Training. Running the experiment reproducibly, with tracked parameters, code versions and datasets, so a result can be rebuilt rather than remembered.
3. Validation. Testing the model against held-out data and against the current production model, including checks for convergence and for behaviour on the slices you care about.
4. Deployment and serving. Packaging the model behind an interface, releasing it in a way that can be rolled back, and confirming the serving system matches what was tested.
5. Monitoring and retraining. Watching live inputs and predictions, detecting drift and degradation, and triggering the loop again on a schedule, on new data, or when performance falls.

The fifth stage is the one teams skip, and it is the one that makes the other four worth automating.

The 3 MLOps maturity levels

Google Cloud’s architecture guide sets out three levels, and they are a fair way to locate your own team honestly.

• Level 0, manual process. Script-driven and interactive work in notebooks, a handoff from data scientists to engineers, infrequent releases, no continuous integration or delivery, and no active performance monitoring. Google notes this is common and often adequate for models that change rarely.
• Level 1, ML pipeline automation. Automated data and model validation, continuous training triggered by schedules, new data or degradation, modular containerised components, feature stores and metadata management. The unit being deployed becomes the pipeline rather than a single model.
• Level 2, CI/CD pipeline automation. Automated build, test and deployment of the pipelines themselves, with integration tests covering unit behaviour, model convergence and component interaction, plus staged delivery and rapid experimentation.

Moving up a level costs real engineering time, so the honest question is how often your model needs to change. A model retrained twice a year does not need level 2 MLOps. A fraud model retrained nightly does.

Where MLOps work most often goes wrong

• Training and serving skew. The classic failure, and the reason feature stores exist at all.
• No monitoring after launch. Level 0 teams typically have none, so degradation is discovered by a customer complaint.
• Handoffs instead of shared ownership. Google’s level 0 description names disconnected teams explicitly.
• Unreproducible experiments. If the dataset version and code commit are not recorded, a good result cannot be rebuilt or defended.
• Governance left to the end. Model documentation, approval records and audit trails are far cheaper to build into the pipeline than to reconstruct. See our guide to AI governance.

MLOps as a job, and how it is certified

The role now has its own credentials. Microsoft’s Machine Learning Operations Engineer Associate certification, taken through exam AI-300, assesses designing and implementing MLOps infrastructure, the model lifecycle, generative AI operations infrastructure, quality assurance and observability, and system optimisation. The exam runs 120 minutes and is offered in English. Microsoft expects candidates to have a data science background with Python and entry-level DevOps practice, including GitHub Actions and infrastructure as code.

Databricks offers a Certified Machine Learning Associate exam, 48 scored questions in 90 minutes for $200, valid for two years, covering AutoML, MLflow, feature engineering and deployment. Google Cloud’s Professional Machine Learning Engineer exam costs $200, runs two hours, and recommends three or more years of industry experience. Our guide to AI certification compares the main options and their fees. For the neighbouring job that builds on top of models rather than operating them, see the AI engineer role.

Hiring demand is easier to describe than to quantify. Indeed Hiring Lab found that in December 2025, 45 percent of US data and analytics postings mentioned AI, the highest share of any occupational sector, with software development and IT systems above 20 percent. Most MLOps work sits inside those categories rather than under its own label, which is why a single MLOps job count is hard to trust.

Common questions

What is MLOps in simple terms? It is the practice of running machine learning models as production software: automating the data, training, testing, deployment and monitoring loop so a model keeps working after launch rather than decaying unnoticed.

What is the difference between MLOps and DevOps? DevOps automates building and releasing code. MLOps adds data and models, which change independently of the code, so it also has to version datasets, validate models and monitor for drift in live inputs.

What are the MLOps maturity levels? Google Cloud defines three: level 0 manual process, level 1 ML pipeline automation with continuous training, and level 2 CI/CD pipeline automation where the pipelines themselves are built, tested and deployed automatically.

Is MLOps still relevant with generative AI? Yes, and vendors have extended it. Microsoft groups MLOps and generative AI operations together as AI operations in its AI-300 certification, which covers evaluation, observability and optimisation of generative systems.

What skills does an MLOps engineer need? Microsoft lists Python, entry-level DevOps including GitHub Actions, and infrastructure as code, on top of experience training, deploying and monitoring machine learning models.

Sources and further reading

Where the figures and rules above come from, so you can check them:

• MLOps: continuous delivery and automation pipelines in machine learning: Google Cloud
• Hidden Technical Debt in Machine Learning Systems (NIPS 2015): Sculley et al., Google
• Machine Learning Operations Engineer Associate, exam AI-300: Microsoft Learn
• Certified Machine Learning Associate, format and fee: Databricks
• Professional Machine Learning Engineer, format and fee: Google Cloud
• AI mentions by occupational sector, December 2025: Indeed Hiring Lab

Photo credits: Data Center của CMC Telecom (2) by Daoducquan, CC BY-SA 4.0, via Wikimedia Commons. Opsview Monitor 6.0 Dashboard by Opsview, Ltd, CC BY-SA 3.0, via Wikimedia Commons.