What is MLOps: versioning, deployment and monitoring of production models?

Training a model is the visible part. The hard part comes later: getting that model right tomorrow, next week, and six months from now, when the world's data has changed and no one has warned you. Most machine learning tutorials end right where the real problem begins. MLOps is the discipline that covers that stretch.

What is MLOps? MLOps - MachineLearning Operations -is the set of practices for bringing machine learning models into production and keeping them running reliably over time. It integrates model development, deployment automation and continuous monitoring into the complete MLOps lifecycle.

What MLOps is and why it matters

A machine learning model is not a conventional program. Calculator code does the same thing every time. A recommendation model trained on data from six months ago may behave differently today because users have changed, products have changed, or both.

MLOps was born to respond to that reality. It takes proven software engineering principles - automation, version control, continuous integration, observability - and adapts them to the particularities of machine learning systems, where the behaviour of the system depends on both the code and the data it was trained on.

The complete MLOps lifecycle goes through four phases that are repeated in a loop:

• Development: experimentation, feature selection, training and evaluation of the model.
• Deployment: packaging of the model, test automation and integration into the consuming system.
• Monitoring: continuous monitoring of the actual performance of the model in production.
• Continuous improvement: detection of degradation, retraining and return to the beginning of the cycle.

Without this loop, a model is a static artefact. With it, it is a living system.

MLOps vs DevOps vs ML Engineering vs Data Engineering

One of the most common confusions when approaching this field is to mix roles that overlap but are not the same. This table sorts them by what each one manages, where they work and with which everyday example it can be illustrated:

MLOps does not replace any of these disciplines. It coordinates them. An MLOps team knows how to talk to data engineers, ML engineers and infrastructure teams because their role is to get the model into production and keep it there.

Versioning data, code and models

When someone coming from development hears "versioning", they think of Git and code branches. That's necessary, but in machine learning it's not enough. The behaviour of a model depends on three variables that can change independently: the training code, the data it was trained on, and the resulting parameters. If you only version the code, you cannot reproduce a past experiment or diagnose why two runs with the same code produce different models.

In MLOps you version everything that determines the behaviour of the model:

The practical consequence is clear: if there is a problem with the model in production, the team can identify exactly which version of data, code and parameters produced it. Without that record, debugging a bug in production is a search in the dark.

Deployment and CI/CD in machine learning systems

Deploying a model means making it available to a real system to make predictions. It can be an API that responds in real time, a batch process that runs predictions every night, or an embedded component in a mobile application. The mechanism changes depending on the use case, but the principle is the same: the model moves from being a file in a repository to being an active service.

In traditional software, continuous integration (CI) and continuous deployment (CD) automate the compilation, testing and release of new code. In machine learning, that pipeline is complicated for a fundamental reason: the model depends not only on the code, but also on the training data. A change in the input data can produce a model with excellent validation metrics that performs worse in production.

That's why MLOps adds a third C to the pipeline: continuous training (CT). When the data changes sufficiently - because the business has evolved, because there is more volume, or because the environment has changed - the system can automatically retrain the model, run the established quality tests, and deploy it if it passes defined thresholds. No manual intervention at each iteration.

It is this automated cycle that allows small teams to keep dozens of models in production without each update becoming a critical engineering operation.

Monitoring models, drift and degradation

A server can be running perfectly - with no errors, with nominal latency - while the model it runs has been responding poorly for weeks. This is the central difference between technical monitoring and model monitoring, and it is one of the most important concepts in understanding what MLOps is.

Technical monitoring checks that the system is working: CPU, memory, response latency, HTTP errors. It is necessary, but it does not detect whether the model is being useful.

Model monitoring checks that the predictions are still correct: distribution of inputs, quality of outputs, comparison between predictions and actual results when feedback is available.

This is where the concept of drift comes in, which occurs when the world the model learned during training no longer matches the world in which it operates. It is not a failure of the model; it is a natural consequence of change. Buying patterns evolve. User profiles change. Economic conditions move. The model, on the other hand, stands still until someone retrains it.

There are two main types of drift that should be distinguished:

• Data drift(covariate drift): the distribution of the input data changes. For example, the fraud detection model was trained with transactions from a specific period, but payment habits have changed.
• Concept drift: the relationship between the input and output variables changes. The behaviour that the model learned to predict is no longer the same as the actual behaviour.

Performance degradation is the visible consequence of undetected drift. A scoring model that used to be right 92% of the time can drop to 78% in six months without any infrastructure alarm detecting it. That's why model monitoring is not optional in production: it's the difference between an AI system that generates value and one that erodes it without anyone knowing.

How to know if this path interests you

MLOps lives at the intersection of several disciplines, and that means it can connect with different profiles. There is no single entry point.

• If you are most attracted to data, statistics and the logic of models - how they learn, what metrics evaluate them, how experiments are designed - your natural entry point is in data science and machine learning. UDIT's Bachelor's Degree in Data Science and Artificial Intelligence covers precisely that base, from applied statistics to model design and evaluation.
• If it's the systems, automation and deployment side that gets you hooked - how to build a pipeline, how to manage an API, how to test and deploy a service - your inclination is towards software engineering. The Full-Stack Software Development Degree develops that capability in depth, including the architectural patterns that underpin real systems.
• If you already have a technical background and you are looking to specialise in the complete intersection -models, systems, operations, governance-, the Official Master's Degree in Artificial Intelligence at UDIT works on this convergence with an advanced level and professional orientation.

You don't need to decide now which profile you connect with the most. But knowing that these routes exist helps to give direction to your interest.

Checklist for understanding MLOps

Before exploring further specific tools, platforms or architectures, it's a good idea to check that the fundamentals are clear. If you can check off these six points, you have a solid foundation:

• [ ] I know how to explain what the difference is between a trained model and a production model, and why that difference matters.
• [ ] I distinguish technical monitoring (the system works) from model monitoring (the model is still useful).
• [ ] I understand why in ML not only the code is versioned, but also the data, the parameters and the resulting model.
• [ ] I can identify what drift is, why it occurs and what its consequence is on model performance over time.
• [ ] I can explain how a CI/CD pipeline in machine learning differs from that of traditional software (hint: continuous training).
• [ ] I distinguish MLOps from DevOps, ML Engineering and Data Engineering, and I know how they overlap and how they differ.

Frequently asked questions

Is MLOps just DevOps applied to AI? Not exactly. DevOps manages the software lifecycle: code, infrastructure, deployment. MLOps inherits those principles, but adds dimensions that don't exist in traditional software: the behaviour of the model depends on training data, it can degrade without the system technically failing, and it needs specific monitoring of its predictions. The intersection is large, but the problem MLOps solves is different.

Do you need to know Kubernetes to understand MLOps? Not to understand the concepts. Kubernetes is a container orchestration tool that appears in advanced deployments, but the principles of MLOps - versioning, deployment, monitoring, continuous improvement - can be understood and practised without it. The basics first; the concrete tools come later.

What exactly is versioning in machine learning? Five assets: the training code, the datasets used, the hyperparameters configured, the resulting model and the experiment metadata (metrics, dates, settings). Versioning only the code does not allow you to reproduce an experiment or to audit why two runs produce different models.

What is the difference between monitoring a system and monitoring a model? Monitoring the system answers: is it up and running? Latency, errors, availability. Monitoring the model answers: is it still useful? Distribution of inputs, quality of predictions, drift detection. A system can pass all technical checks and still be serving incorrect predictions for weeks.

What is drift in machine learning? It is the progressive mismatch between the world the model learned during training and the world it operates in today. It does not indicate that the model was poorly built: it indicates that the environment has changed. Data drift occurs when the distribution of input data changes. Concept drift occurs when the relationship between variables and outcome is no longer the same as the model learned.

Does MLOps have real career opportunities? Yes, and there is a growing demand for it. The most sought-after profiles in this field include ML Engineer, MLOps Engineer and AI Infrastructure Engineer. Companies that already have models in production - banking, retail, healthcare, logistics, media - need teams to keep them running. The profile is in short supply because it requires expertise in several layers at once: data, models, systems and automation.

What to study if I am interested in this intersection? It depends on where you connect the most. If the core is data and modelling, a background in data science is the right starting point. If it's systems engineering and deployment, backend-oriented software development and architectures are the way to go. If you already have a technical background and are looking for advanced specialisation, a master's degree in artificial intelligence covers the full convergence.

Conclusion

A machine learning model that no one maintains is not an asset: it is a silent technical debt. MLOps is the discipline that turns models into operable systems, capable of surviving the passage of time, the change of data and the real scale of a business.

Understanding what MLOps is - the full cycle of model versioning, deployment and monitoring - is not a niche specialisation. It is the level of technical maturity that separates those who build models on notebooks from those who build AI systems that actually work. That leap doesn't require years of industry experience. It requires understanding the right fundamentals from the ground up.

UDIT works at exactly that intersection between technical rigour and real-world application, with training designed for those who don't want to stay on the surface of artificial intelligence.