TL;DR #
MLOps (machine learning operations) is the set of practices that takes a machine learning model from an experiment to a reliable production system, and keeps it reliable afterwards. It combines DevOps automation with the parts DevOps never had to handle: data versioning, model training, a model registry and monitoring for drift. MLOps makes models repeatable to ship. MLOps security makes sure what ships, and everything it depends on, can be trusted.
What is MLOps? #
A model that works in a notebook is not a product. It becomes one when it can be retrained on new data, deployed without a manual handover, rolled back when it misbehaves, and explained when an auditor asks where it came from.
That gap is where most machine learning projects stall. Google’s widely cited paper Hidden Technical Debt in Machine Learning Systems showed that the model code is a small fraction of a real ML system. The rest is data collection, feature extraction, configuration, serving infrastructure and monitoring, and that is where the debt accumulates.
MLOps is the discipline that manages that rest. It applies the principles of DevOps (automation, version control, continuous delivery, shared ownership) to a system where the behaviour depends on data as much as on code. So a team asking what is MLOps is really asking how to make models something the organisation can operate, not just build. → What is AI security?
The distinction that matters: in software, the same code produces the same behaviour. In machine learning, the same code trained on different data produces a different model. MLOps exists because data is a second source of change.
MLOps meaning: what the term actually covers #
The MLOps meaning varies between vendors, so it helps to state the boundary. The term covers five areas:
- Data management. Versioning datasets, validating their quality and tracking which data trained which model.
- Experimentation and training. Tracking experiments, parameters and results so a model can be reproduced, not just remembered.
- Model registry. A single record of every model version, its lineage, its evaluation and its approval status.
- Delivery and serving. Automated pipelines that package, test and deploy models to inference endpoints, including continuous training when new data arrives.
- Monitoring. Watching production models for data drift, concept drift and performance decay, and triggering retraining when they degrade.
What it does not cover on its own: the security of the components a model pipeline pulls in. That is where MLOps security, and its neighbouring terms below, take over.
Why MLOps became its own discipline #
Because models decay in a way code does not. A function written correctly stays correct. A fraud model trained on last year’s transactions slowly stops matching this year’s behaviour, with no change to a single line of code. Without monitoring and retraining, accuracy erodes silently.
Scale made it unavoidable. One model can be managed by hand. Dozens of models, each retrained on its own schedule, each depending on its own datasets, frameworks and pretrained weights, cannot. MLOps turned that work into pipelines.
Then the supply chain arrived. Modern ML rarely starts from zero. Teams download pretrained models from public hubs, depend on large open-source frameworks and fine-tune on third-party data. Each one is a component somebody else produced. Some model serialization formats can execute code when a file is loaded, which means downloading a model can carry the same risk as installing an untrusted package. → What is data poisoning?
How MLOps works: the lifecycle #
Understanding what is MLOps in practice means knowing what each stage produces, because every artifact one stage creates is something a later stage depends on.
| Stage | Question it answers | Typical artifacts |
|---|---|---|
| Data | Which data trains the model, and is it trustworthy? | Dataset versions, validation reports, feature stores |
| Train | Can we reproduce this model? | Experiment logs, parameters, pretrained weights, frameworks |
| Register | Which model version is approved, and where did it come from? | Model registry entries, model cards, lineage |
| Deploy | How does the model reach production safely? | CI/CD pipelines, containers, inference endpoints |
| Monitor | Is the model still behaving as expected? | Drift metrics, performance dashboards, retraining triggers |
Google Cloud’s reference architecture, MLOps: Continuous delivery and automation pipelines in machine learning, describes maturity in three levels: manual processes (level 0), automated training pipelines (level 1) and automated CI/CD of the pipelines themselves (level 2). Most organisations sit between the first two.
A mature MLOps practice answers every question in the table automatically. A security-aware one adds a sixth question at every stage: what did this step depend on, and would we know if it changed? Answering it needs an AI inventory that sits outside any single pipeline.
What is MLOps not? Neighbouring terms #
The OWASP GenAI Security Project published the Top 10 for LLM Applications 2026 in August 2026, and it is the cThese get used interchangeably, which muddies both tooling and ownership conversations.
- AI governance sets the policy, accountability and compliance rules that MLOps pipelines then enforce. → What is AI governance?
- DevOps automates the delivery of software. MLOps extends it with data, training and model monitoring rather than replacing it.
- DataOps focuses on the data pipelines themselves: quality, freshness and delivery of data to analytics and ML consumers.
- ModelOps is the broader governance of all analytical and AI models in production, including rules-based and optimisation models, not only machine learning.
- LLMOps adapts MLOps to large language models: prompt management, retrieval pipelines, evaluation of generated output and cost control.
- MLSecOps brings security into the ML lifecycle: model provenance, pipeline integrity, dependency risk and adversarial threats. It is the security layer of MLOps, not a competing process.
They are layers, not competitors. An organisation that runs MLOps without MLOps security has automated its delivery pipeline without checking what flows through it.
Frameworks That Shape the MLOps Meaning of Risk #
Judge a framework by publication status, not by how current it sounds.
On documentation the honest framing is narrow. The EU AI Act’s technical documentation duties for high-risk systems and the Cyber Resilience Act’s SBOM obligations create real evidence requirements. An AI inventory and an AI-BOM help meet them. Neither regulation names an AI-BOM, and neither requires a particular MLOps tool.
From definition to programme #
Knowing the MLOps meaning of model lineage is not the same as knowing which models, datasets and frameworks are actually wired into your own repositories.
That gap closes in a predictable order. Discover every AI asset your pipelines depend on, including the ones nobody registered. Map how they connect, so you know which dataset feeds which model and which endpoint serves it. Then export that record as an AI-BOM that auditors, customers and your own incident response can use.
Xygeni AI Security builds that record from your code. It maintains a continuous AI inventory of models, AI frameworks, datasets, inference endpoints, agents and the rest of your AI footprint, with a risk score, provider, type and exact location in code for each asset. The AI graph shows which dataset feeds which model and where risk concentrates, and a machine-readable AI-BOM exports from the same discovery. Your MLOps pipeline keeps delivering models; Xygeni tells you what they are made of. For the underlying concepts, see What is an AI BOM? and What is an AI inventory?
Schedule a demo to see your own AI inventory and AI-BOM.
FAQ #
The practices and automation that let a team train, ship, monitor and retrain machine learning models reliably, the way DevOps does for software.
DevOps manages code changes. MLOps manages code changes and data changes, because a model’s behaviour depends on the data it was trained on. That adds data versioning, training pipelines, a model registry and drift monitoring.
Applying security to the ML lifecycle: verifying where models and datasets come from, protecting training and deployment pipelines, and tracking the dependencies a model relies on. It is often called MLSecOps.
A system that can take more actions, with more permissions, more autonomously than the task requires. Not by default. A model registry records model versions and lineage for the ML team. An AI inventory, and the AI-BOM exported from it, is a standardised, machine-readable record of AI components meant for auditors, customers and security teams. They complement each other.
Usually ML engineering or a platform team. Security of the pipeline is shared: the ML team owns delivery, and application security owns the dependencies and components that delivery relies on.
