MLOps: industrialising the machine learning model lifecycle

SECTION 1

MLOps in 2026: why industrialise the model lifecycle

MLOps refers to the set of practices that make it possible to deploy and maintain machine learning models in production reliably, reproducibly and efficiently. The concept applies DevOps principles to machine learning, continuous integration, continuous delivery, infrastructure as code, while adding what makes ML specific: data and models are versioned artefacts just like code, and their behaviour degrades over time even when nothing changes in the software. In practice, this means treating the entire path from raw data to served prediction as a single, continuously tested system.

The starting observation has not changed: a notebook that produces a good score on a test set is not a production system. Between the two, you need governed data pipelines, reproducible training, controlled deployment and continuous monitoring. Industry studies have converged for years: the majority of ML projects fail not on modelling, but on industrialisation. The gap between a promising prototype and a dependable service is where most of the real engineering effort lies.

In 2026, the stakes have widened further. Organisations no longer operate only classic predictive models, scoring, forecasting, recommendation, but also generative and agentic systems built on LLMs. MLOps remains the common foundation: without reliable pipelines and monitoring, none of these systems delivers on its promises over time.

@cite:mlops-de-l-experimentation-a-la-production-a-grande-echelle

SECTION 2

Data pipelines and feature stores: the foundation of the lifecycle

Everything starts with data. Pipelines identify sources, convert formats, document metadata, remove outliers and consolidate duplicates, while complying with privacy regulations. Poor-quality data mechanically produces a poor model, whatever the algorithm: it is the area where every euro invested pays back the most. Schema checks, deduplication and freshness controls belong in the pipeline itself, not in a quarterly clean-up campaign.

### The feature store, shared repository of variables

The feature store centralises the models' input variables: each feature is computed once, documented, versioned and served consistently at training and at inference time. It eliminates training-serving skew, the mismatch between the data seen at training and the data received in production that silently ruins performance, and it saves each team from recomputing the same aggregates in its own corner.

Data itself gets versioned: tools such as DVC or lakeFS apply Git-like logic to datasets, and open table formats such as Apache Iceberg, whose v3 specification became mainstream across the major vendors in 2026,provide the time travel and lineage needed to replay a training run identically months later.

### Data contracts and automated quality tests

Mature teams treat their data flows like APIs: a data contract fixes the schema, the expected distributions and the freshness thresholds, and automated tests validate every batch before it reaches training or inference. A contract breach blocks the pipeline upstream, rather than letting a renamed column or a changed unit quietly corrupt predictions for weeks.

SECTION 3

Reproducible training: experiment tracking and model registry

Training must be reproducible: same code, same data, same hyperparameters, same result. That means versioning together the code (Git), the datasets and the produced artefacts. Tools such as MLflow, whose version 3 now also covers tracing for GenAI applications, record every experiment: parameters, metrics, execution environment and resulting model, comparable at a glance. Without this discipline, nobody can explain six months later why a model behaves the way it does, nor rebuild it if the original environment has disappeared.

### The model registry as the source of truth

The model registry centralises candidate versions and their status, staging, production, archived, together with their full lineage: which data, which code, which evaluation. It is what makes automated deployment and instant rollback possible, and it is what compliance audits rely on. A model that is not in the registry does not exist: this simple rule prevents ghost models trained on a workstation and pushed to production by hand.

CI/CD extends to ML: every change to code or data triggers unit tests on the transformations, retraining if necessary, an evaluation against the incumbent model and non-regression tests on frozen validation sets. The pipeline promotes the candidate only if it does better, or at least as well, as the reigning champion. Human approval can remain a gate for sensitive use cases, but it approves evidence produced by the pipeline rather than replacing it.

SECTION 4

Continuous deployment and serving: putting models into production without risk

Deploying a model is a software deployment with its own requirements: inference latency, compute cost, scaling. Serving platforms, from KServe on Kubernetes to the clouds' managed endpoints, standardise exposing the model behind an API, autoscaling, including on GPUs, and version management. The same GitOps workflows used for applications apply to models, with the registry acting as the deployment source of truth.

### Canary, shadow and A/B: deploying progressively

Progressive deployment strategies limit the risk. A canary release first sends a few percent of the traffic to the new model and compares its metrics with the old one's. A shadow deployment runs the candidate in parallel without exposing its predictions, to evaluate it on real traffic with no user impact. A/B tests, finally, measure the real business effect, conversion, retention, beyond the model's statistical metrics alone.

Rollback must be instant and ceremony-free: if the new model drifts, you switch back to the previous registry version in seconds. This reversibility is what allows a sustained deployment pace, exactly as in classic DevOps.

Inference cost also enters the deployment equation: model quantisation, request batching, choosing between CPU and GPU depending on the required latency, automatic shutdown of unused endpoints. A slightly less accurate model that is ten times cheaper to serve is often the better business choice, provided the decision is explicit and measured, not suffered.

SECTION 5

Monitoring and drift: watching models that degrade in silence

A model in production degrades without a sound. Data drift, the input distribution moves away from the training distribution, and concept drift, the relationship between inputs and outputs changes, because the world changes, erode prediction quality without triggering a single technical error. A scoring model trained before a shift in customer behaviour keeps responding fast and without exceptions: it just responds less and less well. This is why monitoring accuracy proxies matters just as much as monitoring uptime.

### Detect, alert, retrain

Model monitoring layers three levels: system metrics (latency, throughput, errors), data metrics (distributions, missing values, statistical drift) and business performance metrics once the real label eventually arrives. Thresholds trigger alerts, then automated retraining on fresh data, with validation before promotion, because retraining on corrupted data worsens the problem instead of fixing it.

This surveillance plugs into the organisation's existing observability stack: same dashboards, same alerting channels, same on-call rotations. SRE teams treat a degraded model as an incident, with a post-mortem and a runbook.

@cite:les-3-piliers-de-l-observabilite

SECTION 6

From MLOps to LLMOps: operating generative and agentic systems

Systems built on LLMs, RAG, assistants, agents, have given rise to LLMOps, the extension of MLOps to the specifics of generative AI. You generally do not train the model: you version prompts, retrieval configurations and tool orchestrations, and evaluation can no longer be reduced to a scalar metric on a labelled test set. Latency, cost and answer quality form a three-way trade-off that has to be managed release after release.

### Prompts, traces and continuous evaluation

The structuring practices are now well established: a registry of versioned prompts, detailed tracing of every call (inputs, outputs, tools invoked, latency, token cost), evaluation sets maintained like test suites, and a combination of automated judges, often an evaluator LLM, and sampled human reviews. Production guardrails filter adversarial inputs and non-compliant outputs, and inference cost tracking becomes a first-class metric on a par with latency.

The MLOps foundation remains intact: data pipelines to feed retrieval, a registry for artefacts, progressive deployment for new prompt versions as for models, monitoring of behaviour in production. Organisations that had invested in classic MLOps ship their generative systems faster and with far more confidence than the others.

@cite:comment-evaluer-un-systeme-llm

SECTION 7

Model governance, the AI Act and the Adservio approach

Model governance is no longer optional. The European AI Act, whose obligations for high-risk systems apply from August 2026, requires technical documentation, traceability of training data, human oversight and risk management across the entire lifecycle. The building blocks of MLOps, lineage, registry, monitoring, inference logging, are precisely what makes this compliance demonstrable without a last-minute documentation scramble. Teams that already operate a registry and lineage meet most of these requirements at near-zero marginal cost.

At Adservio, MLOps is not a layer of tooling bolted on afterwards but an engineering discipline: governed data pipelines, reproducible training, traceable production deployment and continuous monitoring of model behaviour once exposed to the real world. We tie every step to observability and governance, from the first pipeline to automated retraining.

Our conviction: a model is only valuable if it stays reliable over time. That is why we close our missions with a transfer of skills, so your teams operate their models, predictive and generative alike, in full autonomy.

FAQ

Frequently asked questions