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 you need 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 are building models or already have them and want those models to keep working as the data changes. Data Science Lab sets up MLOps alongside your team.
A data scientist has built a model that predicts demand for maintenance, 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 rebuilds 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 no one knows which settings were used.
The problem is rarely the model itself. It is what is missing around it: a designated place for code, data and model versions, an automated route to production, and someone responsible once the model is running. MLOps helps you put that in place.
Code is stored in Git, and each training run records the 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, data quality and 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 generic monitoring approach scales better than managing each model by hand.
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 approach too. A new version only goes live if it performs at least as well as the current one.
For each model, it is clear who owns it, who receives alerts and who decides whether to release a new version. Because every step is logged, you can later show which data, code and settings were used to create a model.
Talk to one of our ML engineers about how to deploy it in a reproducible, monitored way.
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 and runs in Git and MLflow, using a fixed version of the training data.
We build a CI/CD pipeline with tests and separate environments for development, testing and production, for example in Azure DevOps.
We measure drift, data quality and, where outcomes are available, performance. We agree thresholds and alert recipients with the owner.
We capture what works in reusable templates, so subsequent models follow the same path rather than starting from scratch with each project.
Your team adopts 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 requires a place to run experiments, a model registry and a deployment process. Databricks provides these through MLflow and Unity Catalog; Microsoft Fabric supports MLflow experiments and has a built-in model registry. It can also run on-premises. At LUMC, we previously set up the infrastructure to implement models in clinical practice. We are now working there on MLOps on on-premises, sovereign 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 developed 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 move from standalone notebooks to working with Git and pipelines, while IT learns to manage models as software that depends on data. We help you make that transition and, if you wish, include the MLOps pipeline in our management and continuous improvement services.
Any organisation can launch 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 used to develop, deploy, monitor and improve machine learning models. The aim is not just to put a model into production once, but to keep it performing as conditions change.
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 the processes DevOps already covers, such as automated testing and deployment.
With data drift, the input changes: for example, the model receives different types of customers or measurements from those in its training data. With concept drift, the relationship between input and outcome changes, for example because customers behave differently after a price change. You can spot concept drift mainly 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 its predictions were correct; until then, you monitor drift in the input data. We therefore agree a retraining schedule for each model with its owner.
We choose tools that fit your existing environment. In our projects, we use tools including 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, the same approach is possible using its built-in MLflow experiments. We are a Databricks Partner and Microsoft Partner.
For high-risk AI, the AI Act sets requirements for 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 requirements apply from 2 December 2027, or from 2 August 2028 for AI in regulated products. MLOps provides evidence to support compliance with these requirements, but does not automatically make a system compliant. A lawyer or your compliance department can assess whether your application is high-risk; we help you take stock, prepare the risk classification and establish AI governance.
If you have a single model that is rarely retrained and where an error has little impact, a full MLOps setup is often more than you need. Code in Git, a documented training run and a simple check of the outcomes may be enough. If the model has not yet proved its value, start with data science. Further automation becomes worthwhile when you add more models or the consequences of errors become greater.
E-mail info@datasciencelab.nl
Phone +31 (0)20 3636 724
Tell us which models you have and where you’re running into difficulties. 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.
