Why most models never leave the pilot, what MLOps adds to DevOps, the three maturity levels and a realistic starting point for a small data team.
In short
MLOps is the set of practices that takes machine learning models from experiment to reliable production use: automated data and training pipelines, versioning of data, code and models, testing, deployment and monitoring for drift. It applies DevOps ideas to systems whose behaviour depends on data, so a model can be retrained, checked and rolled back as routinely as software.
A model that performs well in a notebook is a promising experiment, not a business capability. The gap between the two is mostly engineering: data has to arrive every day, the model has to be retrained when conditions change, and someone has to notice when predictions get worse. This explainer from Devies, a Gothenburg-based product and engineering consultancy, is for CTOs, data leads and product owners who want to understand the practice well enough to plan for it and staff it.
What is MLOps?
MLOps (machine learning operations) is an engineering practice that unifies the development and operation of machine learning systems by automating and monitoring each step, from data preparation to training, deployment and monitoring. Google's architecture guide describes it as an ML engineering culture and practice aimed at exactly that unification (Google Cloud).
The reason it exists is that the model is a small part of the system. The same Google guide notes that "only a small fraction of a real-world ML system is composed of the ML code". Around it sit data collection, validation, feature preparation, serving infrastructure and monitoring. A widely cited NeurIPS paper by Google engineers, Hidden Technical Debt in Machine Learning Systems (Sculley et al., 2015), argues that real-world ML systems commonly incur massive ongoing maintenance costs, through issues such as data dependencies, entanglement and hidden feedback loops.
How is MLOps different from DevOps and DataOps?
MLOps extends DevOps because an ML system can break without any code change: the data shifts and the model silently gets worse. It therefore adds versioning and testing of data and models, and continuous retraining, to the usual software practices.
Practice
What it manages
What triggers a change
Typical failure it prevents
DevOps
What it manages
Application code and infrastructure
What triggers a change
A code commit
Typical failure it prevents
A broken release
DataOps
What it manages
Data pipelines and data quality
What triggers a change
New or changed source data
Typical failure it prevents
Late or wrong data in reports
MLOps
What it manages
Data, code and trained models together
What triggers a change
New data, drift or a code change
Typical failure it prevents
A model that quietly degrades
Model governance
What it manages
Approval, documentation and accountability for models
What triggers a change
A new model or a new use
Typical failure it prevents
A model used for a purpose nobody approved
The practices overlap. It relies on reliable pipelines, covered in our guide to data pipelines that do not break, and on the release habits described in DevOps for product teams.
What are the MLOps maturity levels?
Google's guide describes three maturity levels: level 0 is a manual process, level 1 automates the training pipeline so models retrain continuously, and level 2 adds a full CI/CD system for the pipelines themselves.
- Level 0, manual. Data scientists prepare data, train and evaluate in notebooks, then hand a model file to engineers. Releases are rare, there is no automated testing and little monitoring. Google points out that this hand-over can cause training-serving skew, where the model sees different data in production than in training.
- Level 1, ML pipeline automation. The training pipeline itself is deployed and runs automatically, on a schedule, when new data arrives or when performance drops. Data and model validation steps stop bad data or weaker models from reaching production. Google calls this continuous training.
- Level 2, CI/CD pipeline automation. Changes to the pipeline code are built, tested and deployed automatically, so a team can try new ideas and ship them quickly and safely.
Most mid-sized companies do not need level 2. One or two models in production are well served by a solid level 1: an automated pipeline, validation gates and monitoring.
What are the building blocks of a production ML system?
The building blocks are versioned data and code, an automated training pipeline, a model registry, a deployment mechanism, monitoring and a record of what ran when. Each solves a specific failure that otherwise appears months after launch.
- Version control for code, data and configuration. You must be able to recreate the exact model that made a past decision.
- Automated training pipeline. The same steps run in development and production, with no manual notebook in between.
- Data validation. Check schema and value distributions before training. A changed column type should stop the pipeline; a gradual shift in values may call for retraining.
- Model validation. Compare a new model with the current one on held-out data and on important segments before promotion.
- Model registry and metadata. Store each model with its training data version, parameters and evaluation results. Google lists a metadata store as the basis for lineage, reproducibility and rollback.
- Deployment with a safe rollout. Release to a small share of traffic first, or run the new model in shadow mode, and keep a one-step rollback.
- Monitoring. Track input data drift, prediction distributions and, when outcomes arrive, real accuracy. Alert a named owner.
- Feature store, if needed. A shared store of feature definitions helps avoid training-serving skew when several models reuse the same inputs. Small teams can usually wait.
Where should a small data team start?
A small team should start by automating the path for one model that already matters, rather than buying a platform for models that do not yet exist. The goal is that the model can be retrained and redeployed by someone other than its original author.
A practical first quarter looks like this:
- Move the training code out of notebooks into a versioned repository with a single command to retrain.
- Schedule that pipeline and add basic data checks.
- Log every prediction with model version and input summary.
- Build a simple dashboard of input drift and, where possible, accuracy against actual outcomes.
- Write a one-page runbook: who owns the model, when to retrain, how to roll back.
Managed services such as the ML platforms from the major cloud providers cover much of this, but tooling is the easy part. The harder part is ownership after launch, a point our explainer on machine learning for business leaders makes from the business side.
Regulation adds a reason to keep records. As of October 2026, the European Commission states that obligations for high-risk AI systems listed in Annex III of the AI Act apply from 2 December 2027 (European Commission). Those obligations include logging and documentation that a level 1 setup largely provides.
Keep reading
From our work
Client Case: Stena LineStena Line modernised its Azure data platform - improving Power BI reliability, reducing pipeline runtimes and scaling with medallion architecture.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
What is the difference between MLOps and DevOps?
DevOps automates the building, testing and release of software, triggered by code changes. MLOps adds what machine learning needs on top: versioning and validation of data and trained models, automated retraining when new data arrives or performance drops, and monitoring for data drift. A machine learning system can degrade without a single code change, which is why those extra practices are needed.
Do we need MLOps for one or two models?
Yes, but in a light form. Even a single model in production needs a repeatable training pipeline, version control, basic data checks, monitoring and a named owner. You do not need a full platform or a feature store. A small, well-automated pipeline is usually enough until you run several models that share data and infrastructure.
What is model drift?
Model drift is the gradual decline in a model's accuracy because the world it predicts has changed since training. Customer behaviour, prices, suppliers or sensor hardware shift, so the patterns the model learned no longer hold. MLOps detects drift by monitoring input data distributions and, when actual outcomes become available, real accuracy, then retrains or rolls back the model.
Which tools are used for MLOps?
Common choices include the managed machine learning platforms from Microsoft, Google and AWS, open-source tools such as MLflow for experiment tracking and model registry, workflow orchestrators for pipelines, and standard CI/CD and monitoring tools. The right mix depends on your existing data platform. Start with the platform you already run rather than introducing a separate stack for one model.
