MLOps: definition, lifecycle and tooling for keeping a model in production
MLOps is the set of practices that get a machine learning model into production and keep it reliable over time. It extends DevOps to two objects that conventional software ignores: the data and the model. Its reason for existing comes down to one observation — a model degrades on its own, because the world it learned from keeps changing.
In brief: MLOps defined in 30 seconds
MLOps is the set of practices that get a machine learning model into production and keep it reliable there. The term contracts machine learning and operations, on the model of DevOps.
The difference from DevOps lies in what is tracked. DevOps versions code. MLOps versions code, data and a trained model.
That difference produces another, more important one. Software nobody touches keeps working. A model nobody touches degrades anyway, because the world it learned from changes. That is the reason MLOps exists.
The problem is well documented: the hard part of an AI project is rarely training the model. It is the months that follow go-live.
What MLOps is
A machine learning model in production is not a deliverable, it is a service. It consumes data continuously, produces decisions, and its quality varies without a single line of code changing.
MLOps answers four questions conventional software development never has to ask.
Which version is running? A model is the product of code, a dataset, hyperparameters and often a random seed. Without all four, the training run is not reproducible. Knowing which artefact is serving today’s predictions is the foundation of everything else.
Is it still good? A model validated at 92% accuracy does not necessarily stay there. Monitoring performance in production is a standing function, not a testing phase.
Can it be replaced safely? Deploying a new version means comparing it against the one in service on real traffic, and being able to roll back quickly.
Can a past decision be explained? Replaying a prediction issued six months ago means recovering the model, the input data and the context. It is a trust requirement, and increasingly a regulatory one.
MLOps and DevOps: the three differences that matter
| DevOps | MLOps | |
|---|---|---|
| What is versioned | Code | Code, data, model |
| Deployment | Deterministic | Produces a model to validate before service |
| Degradation | Requires a change | Happens with no change, through drift |
| Testing | True or false assertions | Statistical metrics, thresholds |
| Rollback | Redeploy the previous commit | Redeploy the previous model, data included |
| Monitoring | Errors, latency, availability | Same, plus drift and prediction quality |
The least intuitive line for a team coming from software is “degradation”. In conventional development, a stable service stays stable as long as its environment holds still. In machine learning, the environment is the data, and data always moves.
The MLOps lifecycle
A mature MLOps chain has seven stages, arranged as a loop rather than a straight line.
┌──────────────────────────────────────────────┐
│ │
▼ │
[1. Data] ── collection, cleaning, versioning │
│ (DVC, LakeFS) │
▼ │
[2. Features] ── transformation, feature store │
│ │
▼ │
[3. Training] ── tracked experiments │
│ (MLflow, W&B) │
▼ │
[4. Evaluation] ── metrics, bias, thresholds │
│ go / no-go decision │
▼ │
[5. Registry] ── versioned artefact + metadata │
│ │
▼ │
[6. Deployment] ── shadow, canary, A/B │
│ (BentoML, KServe, vLLM) │
▼ │
[7. Monitoring] ── drift, performance, cost │
│ │
└──── retraining triggered ────────────────────┘1. Data. Versioning datasets is the foundation. Without it, a training run is not reproducible, and a performance regression becomes impossible to diagnose.
2. Features. Turning raw data into usable variables. The classic trap is a mismatch between the training transformation and the production one, which yields correct predictions in testing and wrong ones in service. A feature store resolves that mismatch by sharing the same code on both sides.
3. Training. Every experiment is tracked: parameters, dataset, metrics, artefact produced. A team comparing results by screenshot has already lost reproducibility.
4. Evaluation. Beyond the headline metric, evaluation measures performance per subgroup. A model that is good overall can be poor on one segment, which becomes a fairness problem as much as a quality one.
5. Model registry. The validated artefact is recorded with its metadata and its stage: development, staging, production, archived. The registry is the source of truth for answering “which version is running”.
6. Progressive deployment. Shadow deployment runs the new model on real traffic without serving its outputs. Canary deployment gives it a small percentage of traffic. Both let you measure before committing.
7. Monitoring. Three families of indicators: the technical health of the service, drift in the incoming data, and business performance once ground truth becomes available. Monitoring is what sends you back to stage 1.
The three MLOps maturity levels
Not every organisation needs the top level. Knowing where you sit avoids investing beside the point.
Level 0 — manual. Training happens in a notebook, deployment by hand. Acceptable for a single, low-criticality model retrained rarely. The hidden cost surfaces the day the person who built it leaves.
Level 1 — automated training pipeline. Training is orchestrated and reproducible, the model registry exists, basic monitoring is in place. This is the level that suits the large majority of organisations, and the one we target by default on our projects.
Level 2 — fully automated chain. Drift detection triggers retraining, evaluation approves or rejects automatically, progressive deployment follows on. This level earns its keep when models are numerous or drift is fast — fraud detection, for instance.
Moving from level 0 to level 1 delivers most of the benefit. The jump to level 2 is expensive and only pays back at a volume or criticality that justifies it.
Drift: the problem that does not exist in DevOps
This is the central concept of MLOps, and the one that surprises teams most.
Data drift is a shift in the distribution of incoming data relative to the training data. A model trained on a UK customer base sees its inputs change when the company opens in Germany.
Concept drift is more insidious. The relationship between inputs and target changes: the world has moved, and the learned rule is no longer the right one. A regulatory change, a new competitor or a downturn is enough to cause it. The data can look entirely normal while the predictions turn wrong.
Detection relies on statistical tests comparing distributions, and on tracking performance once ground truth arrives. The practical difficulty is the delay: in a credit risk model, the real outcome is only known months later. Indirect indicators have to be monitored in the meantime.
We met this problem on the ADEME case study, where automated analysis of grant applications has to stay accurate while the grant schemes themselves keep changing. A frozen model would have aged at the same rate as the schemes it analyses.
MLOps tooling in 2026
The landscape has settled. Here are the common components, with a preference for what can be self-hosted.
| Function | Tools | Self-hostable |
|---|---|---|
| Experiment tracking, registry | MLflow, Weights and Biases | MLflow |
| Data versioning | DVC, LakeFS | Both |
| Orchestration | Airflow, Dagster, Prefect | All three |
| Feature store | Feast, Hopsworks | Both |
| Model serving | BentoML, KServe, vLLM | All three |
| Monitoring and drift | Evidently, WhyLabs | Evidently |
| Integrated platform | Kubeflow, ZenML | Both |
For an organisation subject to UK or EU data protection law, most of this chain is open source and deployable on European infrastructure. A stack of MLflow, DVC, Airflow and BentoML on a sovereign cloud gives up nothing functionally against a managed platform hosted outside Europe.
The practical advice: start with experiment tracking and the model registry. Those are the two components that deliver value earliest, and neither requires an infrastructure overhaul.
LLMOps: what changes with large language models
The arrival of LLMs moved some of the problems without removing the old ones. Three structural differences.
What gets versioned changes in nature. On a RAG system, the model is often a third-party service you do not retrain. What you version is the prompts, the indexed corpus, the chunking strategy and the retrieval parameters. Changing a prompt alters behaviour as much as retraining would.
Evaluation becomes composite. There is no single metric equivalent to accuracy. Evaluation combines reference test sets, automated judges where one model scores another’s outputs, and human feedback. Building that test set is the highest-return work in an LLM project.
Cost becomes a production indicator. Per-token spend makes latency and cost per request metrics to monitor alongside quality. A prompt change that improves the answer and doubles the bill is a trade-off, not an improvement.
What does not change: traceability, the ability to roll back, and drift monitoring. An indexed corpus ages exactly like a training set.
MLOps, data protection and the AI Act
No text mandates MLOps. Several obligations presuppose it in practice.
For high-risk systems, the AI Act requires event logging, technical documentation of the system, governance of training data and effective human oversight. These requirements are now expected by 2 December 2027, after the deferral confirmed by the digital omnibus. They describe, in regulatory language, what an MLOps chain produces naturally.
On the data protection side, the UK rewrote its rules on solely automated decisions in February 2026: Articles 22A to 22D of the UK GDPR replaced the old Article 22 prohibition with a safeguards regime, requiring the controller to inform the data subject, take representations, provide meaningful human intervention and allow the decision to be contested. Every one of those safeguards assumes you can retrieve what the model saw and what it produced. Replaying a past prediction means having kept the model and the inputs. That is an MLOps function before it is a legal one. Our guide to AI and data protection covers where the two meet.
What we will not promise
“You need a full MLOps platform before you start.” False, and expensive. A team that stands up Kubeflow before having a model in service has built infrastructure with no use for it. Experiment tracking and a registry are enough to begin.
“Automatic retraining solves drift.” Dangerous as stated. Retraining triggered without validation propagates a data problem straight into the model. The automated loop must always pass through an evaluation that can refuse the new version.
“A model at 95% accuracy is production-ready.” Overall accuracy says nothing about performance per subgroup, nor about stability over time, nor about behaviour on rare cases. Those three dimensions decide whether a model holds up in service.
This is the heart of what we do as a data and AI agency: designing systems that stay accurate after go-live, not only on acceptance day. When an engagement involves machine learning, we deliver the full chain — data versioning included, model registry, progressive deployment and drift monitoring.
FAQ
What is MLOps, in plain terms?
MLOps covers the practices, tooling and organisation that get a machine learning model into production and keep it reliable there. The term contracts machine learning and operations, on the model of DevOps. The difference lies in what is versioned and monitored: in DevOps, code; in MLOps, code, data and a trained model, whose behaviours evolve independently of one another.
What is the difference between MLOps and DevOps?
DevOps automates the lifecycle of code. MLOps automates the lifecycle of code, data and the model. Three practical differences follow. A DevOps deployment is deterministic, whereas an MLOps deployment produces a model whose quality has to be measured before it goes into service. Software does not degrade without a code change, whereas a model degrades as its data drifts. And reproducing a DevOps build requires the commit, whereas reproducing a training run also requires the dataset and the random seed.
What is model drift?
Drift is the gradual degradation of a model whose code has not changed. There are two main forms. Data drift is a shift in the distribution of incoming data relative to the training data. Concept drift is a change in the relationship between inputs and target: the world has moved, and the learned rule is no longer the right one. A scoring model trained before a regulatory change is the textbook example.
Which MLOps tools matter in 2026?
The common stack combines MLflow or Weights and Biases for experiment tracking and the model registry, DVC or LakeFS for data versioning, Airflow, Dagster or Prefect for orchestration, BentoML, KServe or vLLM for serving, and Evidently or WhyLabs for drift detection. Kubeflow and ZenML offer integrated platforms. For a sovereign deployment, most of these components are open source and self-hostable.
What is LLMOps and how does it differ from MLOps?
LLMOps applies the MLOps approach to large language models. Three differences count. What gets versioned is no longer only a trained model but also prompts, an indexed corpus and a retrieval configuration. Evaluation does not reduce to a single metric; it combines test sets, automated judges and human feedback. And cost is steered per token, which shifts monitoring towards latency and spend per request.
When is it worth investing in MLOps?
As soon as a model leaves the notebook to serve a real decision, even at small scale. The threshold is not volume but consequence: if a wrong prediction affects a customer, a case file or a budget, you need at minimum to know which model produced which output, and on what data. That minimal traceability costs little at the outset and becomes very expensive to reconstruct after the fact.
Is MLOps required for GDPR or AI Act compliance?
No text mandates MLOps as such. That said, the logging, traceability and human oversight obligations the AI Act places on high-risk systems presuppose exactly this kind of setup in practice. Knowing which model produced which decision, on what data, and being able to replay it, is precisely what a properly tooled MLOps chain provides.