---
title: "MLOps"
url: "https://mahouse.world/glossary/mlops"
type: "glossary term"
topic: "AI operations"
author: "Ihor Vlasov"
reviewed: "2026-09-20"
published: "2026-08-06"
---

# MLOps

MLOps — machine learning operations — is the engineering practice of taking models from development into production and keeping them working there: reproducible training pipelines, model registries and versioning, deployment and serving, monitoring of inputs, outputs and performance, drift detection, retraining, rollback, and the documentation that ties each version to its data, code and evaluation. In a regulated fintech it is the operational half of model-risk management; LLMOps is the same discipline for prompts, retrieval and rented models.

**Also known as:** Machine learning operations, ML operations, LLMOps, Model lifecycle management

## Key facts

- **Used at:** every organisation running models in production — fraud, credit, identity, pricing, marketing, and now language-model applications — from a single model on a schedule to hundreds of models with continuous retraining
- **Binding:** model-risk guidance (SR 11-7, SS1/23, the EBA's expectations) requires inventory, validation, monitoring, change control and documentation; the EU AI Act's high-risk obligations include logging, post-market monitoring, accuracy and robustness requirements, and record-keeping; DORA covers the ICT resilience of the pipelines
- **Typical components:** feature stores (consistent features for training and serving), experiment tracking, training pipelines (data → features → train → evaluate → register), a model registry with versions and metadata, deployment (batch, real-time API, on-device), serving infrastructure with latency and availability targets, monitoring (input distributions, prediction distributions, outcome performance when labels arrive, latency, errors), drift alerts, champion–challenger and shadow deployment, retraining triggers, rollback, and model cards generated from the pipeline
- **Typical failures without it:** models that cannot be reproduced, training–serving skew (features computed differently in production), silent drift (performance decays and nobody sees it), a model retrained by hand and deployed without validation, and a regulator's question about a decision two years ago that no one can answer
- **Parties:** ML engineers and platform teams, data scientists, model-risk validators, the business owners of each model, compliance, and the vendors of MLOps platforms (the clouds' offerings, MLflow, Weights & Biases, Databricks, and the LLM-observability tools that appeared in 2023–2024)

## How MLOps works in practice

A fintech's fraud model runs through a pipeline. Every month: the pipeline pulls the trailing 18 months of transactions and labels, computes features from the feature store (the same code that serves them in production), trains a candidate, evaluates it on an out-of-time period against the champion, runs fairness and stability checks, and registers the candidate with its metrics, data snapshot hash, code version and a generated model card. If it beats the champion on the acceptance criteria, it is deployed in shadow for a week — scoring live traffic without acting — and then promoted; rollback is one command. In production, dashboards show the score distribution, the top features' distributions, latency and error rate in real time, and detection and false-positive rates as labels arrive; drift alerts fire when a feature's distribution moves past a threshold. When a regulator asks why a transaction was declined in March, the log gives the model version, the features and the score, and the registry gives the model's card.

LLMOps applies the same discipline to a different stack. Prompts are versioned; retrieval indices are rebuilt on a schedule and tested; evaluation sets run on every prompt, model or index change; production conversations are logged and sampled for review; cost and latency per request are monitored; the rented model's version is pinned and its changes are tested before adoption; guardrail hit rates and human-escalation rates are tracked. The failure modes are the same as classical MLOps — a change deployed without evaluation, quality decaying unseen, a vendor's model update changing behaviour overnight — and the controls are the same in spirit. For a fintech, MLOps is the infrastructure that makes models governable at scale and the evidence base for every model-risk conversation; for a buyer, a target's MLOps maturity is read from its registry, its monitoring and its ability to answer "what model made this decision, trained on what, validated how" for any past decision.

For a fintech founder, MLOps is what turns a data-science team's models into a regulated production system; for an acquirer, it is the difference between models that can be inherited and models that leave with the person who trained them.

## Example

A lender with 14 models in production — credit, fraud, collections, marketing — has each maintained by its data scientist in notebooks, deployed by hand, monitored by nobody. A model-risk review finds three models unreproducible, two with training–serving skew, one that has not been retrained in three years, and no model that can answer a lineage question for a past decision. The MLOps build over nine months: a feature store, a pipeline template every model must use, a registry, standard monitoring dashboards, drift alerts, shadow deployment, and model cards generated from the pipeline. Results: all 14 models reproducible; the stale model retrained and improved by 6 Gini points; drift caught twice in the first year before performance fell; and the regulator's next review, which asks for the lineage of 20 past decisions, answered from the logs in a day. The cost was two engineers for a year; the review's finding was closed.

## Common mistakes

- Models deployed from notebooks with no registry, no versioning, no rollback.
- Features computed differently in training and serving.
- No monitoring of outcomes, so drift is discovered by the losses.
- Retraining by hand without the validation the first version had.
- LLM applications changed — prompt, model, index — without an evaluation run.

## Related terms

- [Machine Learning](https://mahouse.world/glossary/machine-learning.md)
- [Validation Data](https://mahouse.world/glossary/validation-data.md)
- [Hyperparameter Tuning](https://mahouse.world/glossary/hyperparameter-tuning.md)
- [Guardrails](https://mahouse.world/glossary/guardrails.md)
- [Training Data](https://mahouse.world/glossary/training-data.md)
- [Overfitting](https://mahouse.world/glossary/overfitting.md)

— Ihor Vlasov, M&A FinTech Expert. Last reviewed 2026-09-20. https://mahouse.world/authors/ihor-vlasov