Models that run reproducibly, are monitored for drift and are retrained when the data changes.
Trusted by leading organisations
MLOps combines the practices and technology needed to deploy machine learning models reliably and keep them running in production: from version control and automated testing to monitoring and retraining. It is for organisations that build models, or already have them, and want those models to keep working as the data changes. Data Science Lab sets up MLOps together with your team.
A data scientist has built a model that predicts maintenance needs, and it looks good in the notebook. To put it into use, she sends the model file to IT, along with a document describing the columns it expects. IT reimplements the input calculations, but does so slightly differently from the notebook. The model runs, but no one notices that its predictions are gradually drifting.
Later, someone from compliance asks which data the current version was trained on. No one can answer: the training table has been overwritten, the code is on a laptop, and nobody knows which settings were used.
The problem is rarely the model itself. It is what is missing around it: a fixed place for code, data and model versions, an automated route to production, and someone responsible for the model once it is running. That is what you set up with MLOps.
Code is stored in Git, and every training run records its parameters, metrics and model file, for example in MLflow. Record which version of the training data was used, too: Delta tables have versions, but older versions disappear after clean-up.
A model registry, such as Models in Unity Catalog or the MLflow Model Registry, tracks which model versions exist and which run they came from. Aliases such as champion and challenger let you switch versions without changing the code.
Every change goes through the same tests and moves from development through testing to production. Databricks recommends promoting code rather than trained models, so the production model is trained in the production environment using tested code.
For each model, we monitor inputs and predictions for drift, check data quality, and assess accuracy once the actual outcomes are available. Thresholds for each signal determine who receives an alert and when. If you run multiple models, a single monitoring approach scales better than handling each model manually.
Start by retraining on a fixed schedule, then move to retraining in response to a signal, such as drift or declining quality. Databricks recommends this too. A new version only goes live if it performs at least as well as the current one.
For each model, it’s clear who owns it, who receives alerts and who decides whether to deploy a new version. Because every step is logged, you can show afterwards which data, code and settings were used to create a model.
Talk to one of our ML engineers about how to deploy it reproducibly and monitor it.
We look at which models you have, where they run, how they are currently trained and deployed, and where manual work or risks arise.
We choose a model that matters and record its code, runs and training data in Git, MLflow and a fixed data version.
We build a CI/CD pipeline with tests and separate development, test and production environments, for example in Azure DevOps.
We measure drift, data quality and, where outcomes are available, performance. We agree on thresholds and alert recipients with the owner.
We capture what works in reusable templates, so subsequent models follow the same path and each project does not have to start from scratch.
Your team takes over the approach, with technical training where useful, or we remain involved in management and continuous improvement.
DSL came up with an inventive solution that we can put to good use.
MLOps needs an environment for experiments, a model registry and a deployment path. Databricks provides these through MLflow and Unity Catalog; Microsoft Fabric has MLflow experiments and a built-in model registry. It can also run on-premise. At LUMC, we previously set up the infrastructure to deploy models in clinical practice. We are now working there on MLOps on sovereign, on-premise infrastructure, using MLflow and Docker, among other tools.
Existing notebooks and models are the starting point. At GVB, we set up an MLOps lifecycle with reusable templates in Databricks for a segmentation model based on travel behaviour. At Waternet, we set up a workflow with an MLflow model registry and CI/CD templates within the Datalab team, which we also maintain. If you mainly need extra capacity, you can also bring in one of our MLOps engineers on secondment.
The technology is usually not the hardest part. Data scientists start working with Git and pipelines instead of standalone notebooks, while IT learns to manage models as software that depends on data. We guide you through that transition and, if you wish, include the MLOps pipeline in our management and continuous improvement services.
Any organisation can start an AI pilot. The challenge is what comes next: making AI part of the organisation. That’s where Data Science Lab makes a difference.
Read more about us
10+
8.7
200+
MLOps, short for machine learning operations, combines the practices, roles and tools you use to develop, deploy, monitor and improve machine learning models. The aim is not just to launch a model once, but to keep it performing as circumstances change.
Developing the model itself falls outside MLOps. You can read about how we do that in machine learning model development.
DevOps deals with software whose behaviour is defined in code. A machine learning model learns its behaviour from data, and that data changes. As a result, a model can perform worse even when no code has changed. MLOps therefore adds version control for data and models, drift monitoring and retraining to what DevOps already covers, such as automated testing and deployment.
With data drift, the input changes: for example, different types of customers or measurements arrive compared with the training data. With concept drift, the relationship between input and outcome changes, for example because customers behave differently after a price change. You mainly detect concept drift by comparing predictions with actual outcomes. For Rijkswaterstaat, we developed a generic monitoring package for drift and outlier detection.
That depends on how quickly your data changes, the cost of an error and when the actual outcomes become available. With a model that predicts payment arrears, you only find out later whether it was right; until then, you monitor the input for drift. We therefore set a retraining schedule for each model together with its owner.
We choose tools that fit your existing environment. In our projects, we work with MLflow for experiments and the model registry, Databricks, Azure DevOps for CI/CD, Docker and Python packages such as Alibi Detect for drift detection. In Microsoft Fabric, you can follow the same approach using its built-in MLflow experiments. We are a Databricks Partner and a Microsoft Partner.
For high-risk AI, the AI Act sets requirements covering, among other things, data governance (Article 10), automatic logging (Article 12), accuracy and robustness throughout the lifecycle (Article 15), and post-deployment monitoring (Article 72). Following the Digital Omnibus, these apply from 2 December 2027, or from 2 August 2028 for AI in regulated products. MLOps provides evidence for these requirements, but does not automatically make a system compliant. A legal expert or your compliance department assesses whether your application is high-risk; we help you take stock, prepare the risk classification and address AI governance.
E-mail info@datasciencelab.nl
Phone +31 (0)20 3636 724
Tell us which models you have and where the challenges lie. Then we’ll look together at the path from notebook to production.
Message sent
Thanks for your message. We’ll be in touch as soon as possible.
