What it is
MLOps (Machine Learning Operations) is the discipline of deploying and maintaining machine-learning models reliably in production. It applies software-engineering rigour to the full ML lifecycle so that models are reproducible, auditable and continuously governed rather than one-off experiments that work on a laptop and break in the real world. A model that scores well in a notebook is not a product; MLOps is what turns it into a service that other systems and citizens can depend on.
The practice borrows heavily from DevOps but adds the parts that are unique to machine learning. In classic software you version code; in MLOps you also version data, features, hyperparameters and the trained model artefact itself. The core building blocks you will encounter again and again are: CI/CD pipelines for models (automated testing and promotion), a model registry (a catalogue of model versions with metadata and an approval workflow), a feature store (a shared, consistent source of features for both training and serving), experiment-tracking and registry tools such as MLflow, pipeline orchestrators such as Kubeflow running on Kubernetes, containerised serving with Docker, data versioning with DVC, and continuous monitoring for data drift and concept drift. Together these turn an ad-hoc training script into a governed, repeatable pipeline.
How it works in practice
The ML lifecycle in production is a loop, not a straight line. It runs from data preparation, through training and validation, to deployment, then monitoring, and — when the model starts to slip — retraining, which feeds the whole cycle again. Each stage produces an artefact that must be tracked so the result can be reproduced months later.
| Stage | Purpose | Key activity / artefact |
|---|---|---|
| Data preparation | Assemble clean, versioned training data | Immutable, content-addressable (SHA-256) dataset snapshot; features published to a feature store |
| Training | Fit the model and search hyperparameters | Trained model artefact logged with its run, parameters and metrics (e.g. in MLflow) |
| Validation | Confirm the model is good enough and fair | Data-quality, model-performance and fairness tests passing minimum thresholds |
| Deployment | Serve predictions safely to users | Model packaged in a Docker container; canary or batch rollout via the registry |
| Monitoring | Detect degradation in live use | Performance, score-distribution and drift metrics (e.g. Population Stability Index) |
| Retraining | Restore performance when it drops | New model version trained on refreshed data, re-validated and re-promoted |
Reproducibility is the thread that runs through every stage. A trained model is only trustworthy if you can point to the exact ingredients that produced it: the dataset snapshot (a content hash), the code (a Git commit hash), the hyperparameters (a versioned config file) and the environment (a Docker image or pinned dependency hash). Datasets are treated as immutable, content-addressable snapshots so you always know what data the model actually saw. A feature store reinforces this by serving the same feature definitions to training (its offline store) and to live inference (its online store), which prevents training-serving skew — the silent class of bugs that appears when the two paths compute features through different code.
Promotion to production is deliberately cautious. A model registry such as MLflow moves a version through stages — Staging, Production, Archived — behind an approval workflow, and CI/CD pipelines run ML-specific tests (data quality, pipeline transforms, model performance, fairness, integration) before anything goes live. The rollout itself favours canary deployment: route a small slice of traffic — say 5% — to the new version, watch the error rates, then ramp to 100% or roll back instantly. A hard cutover risks exposing every user to an undetected regression at once. For many public-sector workloads, batch scoring on a schedule is even simpler and cheaper, and because every prediction is stored it creates a built-in audit trail.
The EU angle is unusually direct here. Training large models at scale can run on EuroHPC supercomputers, giving European institutions sovereign compute for demanding workloads. More importantly, the EU AI Act turns several MLOps practices into legal obligations for high-risk systems — think recruitment, credit scoring, critical infrastructure or border control. Article 12 mandates logging of system activity; the Act requires meaningful human oversight; and providers must run post-market monitoring to catch problems once a system is live. Those are precisely the capabilities a mature MLOps pipeline already delivers: comprehensive logging, human-in-the-loop review gates, and continuous drift monitoring. Good engineering and legal compliance point in the same direction.
Common points of confusion
- MLOps vs DevOps. DevOps automates the delivery of code; MLOps additionally manages data and models, which behave differently. Code is deterministic, but a model's quality depends on data that keeps changing, so MLOps adds data versioning, feature stores and live monitoring that classic DevOps never needed.
- Training accuracy vs production performance. A high score on the validation set does not guarantee the model works in the wild. Performance is measured against the data the model met during training; once the live data distribution shifts, real-world accuracy can fall even though the offline metrics looked excellent. This is why monitoring, not just evaluation, is part of the lifecycle.
- Concept drift vs data drift. Data drift (covariate shift) means the inputs change — P(X), such as new customer demographics — while the underlying rule still holds. Concept drift means the relationship between features and target changes — P(Y|X), where yesterday's "suspicious" pattern becomes today's "normal". A useful rule: if features drift but accuracy stays stable, keep monitoring rather than retraining; retrain only when performance on labelled data actually degrades.
Why it matters for EU data scientists
For a working data scientist, MLOps is the difference between a clever prototype and a system the institution can rely on, defend and audit. In an EU context the stakes are higher than raw accuracy: models that screen grants for fraud, classify multilingual documents or score risk in customs must be reproducible, explainable and continuously supervised, because their outputs affect citizens and public money. Mastering the lifecycle — versioning, CI/CD, a model registry, feature stores, containerised serving and drift detection — is what lets you meet both engineering and governance expectations at once.
It is also squarely on the exam. The EPSO AD7 Data Science competition (EPSO/AD/429/26) maps a whole Field-4 duty area to MLOps & automation, and questions probe exactly these distinctions: which rollout strategy limits blast radius, when to retrain versus keep monitoring, how the EU AI Act's logging, human-oversight and post-market-monitoring duties land on high-risk systems. Knowing how a model reaches and stays in production — and how that connects to the AI Act — is core to scoring well. Prepare for the AD7 Data Science exam with the Prep4EU study pack.