What is MLOps?
Definition MLOps (machine learning operations) is the set of practices, tools and team habits used to build, deploy, monitor and continuously improve machine learning models in production. It applies DevOps principles such as automation, testing and continuous delivery to the whole ML lifecycle, and adds what ML needs on top: versioned data, automated [...]
Definition
MLOps (machine learning operations) is the set of practices, tools and team habits used to build, deploy, monitor and continuously improve machine learning models in production. It applies DevOps principles such as automation, testing and continuous delivery to the whole ML lifecycle, and adds what ML needs on top: versioned data, automated retraining and monitoring of model quality over time.
Related terms: ML engineering, CD4ML (continuous delivery for machine learning), ModelOps, LLMOps, GenAIOps
Why MLOps matters
Building a model that performs well on a test dataset is only the start. Google’s MLOps guidance puts it plainly: the real challenge is building an integrated ML system and operating it continuously in production. Many organizations never get that far.
48%
Average share of AI projects that make it into production (Gartner survey of 644 organizations, 2024)
8 months
Average time to go from AI prototype to production (Gartner, 2024)
9%
Organizations Gartner classed as AI mature; AI engineering is one of their four foundational capabilities
42%
Share of non-generative AI prototypes that reached production, against 41% for generative AI (Gartner, 2025)
Two features of machine learning explain the gap. First, the model is a small part of the system. In their 2015 paper Hidden Technical Debt in Machine Learning Systems, Google researchers showed that ML code is a small fraction of a real-world ML system. The rest is data collection, verification, configuration, serving and monitoring, and that surrounding infrastructure is where most failures happen.
Elements of a production ML system
Configuration Data collection Data verification Feature extraction Resource management ML code Testing and debugging Model analysis Process and metadata management Serving infrastructure Monitoring Automation
Adapted from Sculley et al. (2015) and Google Cloud’s MLOps architecture guide.
Second, models degrade even when nobody touches the code. Customer behavior, prices, sensors and language all change, so the data a model sees in production drifts away from the data it was trained on. Traditional software fails loudly with an error. A drifting model fails quietly with worse predictions. MLOps exists to catch that decline and fix it through monitoring and retraining.
MLOps vs DevOps
An ML system is a software system, so DevOps practices still apply. Google’s architecture guidance identifies where ML changes the meaning of each practice.
| Practice | In DevOps | In MLOps |
|---|---|---|
| Continuous integration | Tests and validates code and components | Also tests and validates data, data schemas and models |
| Continuous delivery | Ships a software package or service | Ships a training pipeline that in turn deploys a model prediction service |
| Continuous training | Not applicable | New practice: retrains and serves models automatically when data or performance changes |
| Testing | Unit and integration tests | Adds data validation, model quality evaluation and model validation against a baseline |
| Monitoring | Uptime, latency, errors | Adds prediction quality, data drift and training-serving skew |
| Development style | Planned features | Experimental; teams must track what worked and keep results reproducible |
The MLOps lifecycle
MLOps turns the one-way path from notebook to production into a loop. Monitoring results flow back into the pipeline, which retrains, validates and redeploys the model.
- Data. Extract, analyze and prepare data, with automated checks on schema and statistical values.
- Experiment. Try features, algorithms and hyperparameters, logging every run so results can be reproduced.
- Train and validate. Train on prepared data, evaluate on a holdout set and confirm the model beats the current baseline.
- Deploy. Serve the validated model through an API, a batch job or an edge device, often behind a canary or A/B test.
- Monitor. Track prediction quality, data drift, latency and cost in production.
- Retrain (feedback loop). A schedule, new data or a drop in performance triggers the pipeline to run again.
The MLOps lifecycle as a continuous loop. Based on the ML process steps in Google Cloud’s architecture guide and the feedback loops described by Kreuzberger et al. (2023).
The nine principles of MLOps
The most widely cited academic definition comes from Kreuzberger, Kühl and Hirschl, published in IEEE Access in 2023. Drawing on a literature review, a tool review and expert interviews, they identified nine principles that an MLOps practice should implement.
Core components and example tools
The same study maps the principles to nine technical components. MLOps is vendor neutral: each component can be built from open-source tools or bought as part of a cloud platform. The tools below are examples cited in the research, not recommendations.
| Component | What it does | Example tools |
|---|---|---|
| Source code repository | Stores and versions code so teams can commit and merge | GitHub, GitLab, Bitbucket |
| CI/CD component | Builds, tests, delivers and deploys pipelines and models | Jenkins, GitHub Actions |
| Workflow orchestration | Runs pipeline steps in order and tracks artifacts | Apache Airflow, Kubeflow Pipelines |
| Feature store | Serves the same features for training and live predictions, preventing training-serving skew | Feast, Tecton, Hopsworks |
| Training infrastructure | Provides CPUs, GPUs and memory, ideally scalable | Kubernetes, cloud compute |
| Model registry | Stores trained models with their metadata and status | MLflow, cloud model registries |
| Metadata store | Records parameters, metrics and lineage of each run | MLflow, Kubeflow, cloud ML platforms |
| Model serving | Delivers predictions online through an API or in batch | KServe, TensorFlow Serving, cloud endpoints |
| Monitoring | Watches model performance, drift and infrastructure health | Prometheus with Grafana, ELK stack |
Who does MLOps?
MLOps is a team practice. Kreuzberger et al. describe seven roles: business stakeholder, solution architect, data scientist, data engineer, software engineer, DevOps engineer and ML engineer. The ML engineer (often titled MLOps engineer) is the cross-functional role that builds and runs the ML infrastructure, manages automated pipelines and monitors models in production.
A common failure pattern is the “handover”: a data scientist trains a model in a notebook and passes a model file to an engineering team that rebuilds the features for production. Google identifies this disconnect as a defining trait of the lowest maturity level, and a direct cause of training-serving skew.
MLOps maturity levels
Two vendor models are widely used to assess where an organization stands. Google Cloud defines three levels, based on how much of the ML process is automated. Microsoft defines five, assessed across people, model creation, model release and application integration. The matrix below follows Microsoft’s five levels, shows what changes in each capability as you move up, and marks where Google’s levels broadly align. Select a level to read what it looks like in practice.
Level 0 No MLOps
Every step is manual, from gathering data to releasing the model. Data scientists, data engineers and software engineers work in isolation, and a model usually leaves the team as a single file. Once deployed, there is little feedback on how it performs.
Next step. Put code under version control and automate application builds and tests.
Level names from the Microsoft MLOps maturity model (updated June 2026). The alignment with Google Cloud’s levels 0 to 2 is DASCIN’s interpretation; the two models measure different things.
Google notes that level 0 is common in organizations starting out with ML, and can be enough when models rarely change. Both vendors recommend moving up gradually rather than trying to reach full automation in one step. Microsoft adds that most organizations show characteristics of more than one level at the same time.
MLOps, governance and regulation
MLOps started as an engineering discipline, but its outputs are now governance evidence. Versioned data, logged training runs, validation reports and production monitoring are exactly what regulators and auditors ask for when they examine an AI system.
EU AI Act. After the AI Omnibus adopted in 2026, obligations for stand-alone high-risk AI systems (Annex III, such as hiring, credit scoring and education) apply from 2 December 2027, and those for high-risk AI embedded in regulated products (Annex I) from 2 August 2028. Several of the Act’s requirements map directly to MLOps practices.
| AI Act requirement | Article | MLOps practice that supplies the evidence |
|---|---|---|
| Data and data governance | Art. 10 | Data validation, versioned datasets, documented feature pipelines |
| Technical documentation | Art. 11 | Model registry entries, metadata and lineage for each model version |
| Record keeping (logs) | Art. 12 | Prediction logging and metadata tracking |
| Accuracy, robustness and cybersecurity | Art. 15 | Model validation against baselines, segment testing, secure CI/CD |
| Quality management system | Art. 17 | Defined, repeatable pipelines with review and approval gates |
| Post-market monitoring | Art. 72 | Continuous monitoring of performance and drift in production |
Voluntary frameworks. The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) organizes AI risk work into four functions: Govern, Map, Measure and Manage. ISO/IEC 42001:2023 sets requirements for an AI management system. MLOps gives both frameworks the operational data they depend on, especially for measuring and managing models over time.
Personal data. When models are trained on personal data, the GDPR still applies in full. Data lineage from MLOps makes it far easier to answer questions about lawful basis, retention and data subject requests.
MLOps and generative AI
Large language models and other generative systems brought new operational terms: LLMOps and GenAIOps. They extend MLOps rather than replace it. Microsoft’s guidance describes GenAIOps as adding capabilities on top of MLOps maturity, including prompt lifecycle management, retrieval augmentation, output safety and governance of token costs.
The core ideas carry over unchanged. Version everything, evaluate before release, monitor in production and close the feedback loop. What changes is what you version (prompts and retrieval indexes alongside model weights) and how you evaluate (output quality and safety rather than a single accuracy score).
Sustainability
Training and serving models consume significant compute. MLOps metadata on run duration and resource use is also the starting point for measuring AI’s energy footprint. See our Knowledge Base entry What is a Green IT Audit?
How to get started with MLOps
You do not need a full platform on day one. Most teams make the biggest gains from a few foundational habits, then automate further as the number of models grows.
- 1
Assess your current level
Use the maturity levels above to locate each model in production. Note who owns it, how it was trained and whether anyone monitors it.
- 2
Version code, data and models
Put training code in source control, record which dataset version produced each model, and store models in a registry with their metrics.
- 3
Track every experiment
Log parameters, metrics and lineage automatically, so any result can be reproduced and explained.
- 4
Automate the training pipeline
Turn notebook steps into modular, tested pipeline components with automated data and model validation. This is Google’s level 1.
- 5
Monitor production models
Track prediction quality and data drift, set thresholds and decide what happens when one is crossed: an alert, a rollback or retraining.
- 6
Add CI/CD for pipelines
Test and deploy pipeline changes automatically, with manual approval before production where risk requires it.
- 7
Connect it to governance
Map your pipeline outputs to documentation duties under the AI Act, GDPR and internal AI policy, so evidence is produced as a side effect of normal work.
Common challenges
Kreuzberger et al. group the open challenges of MLOps into three categories. They show that tools alone do not solve the problem.
Sources
- Kreuzberger, D., Kühl, N. and Hirschl, S. (2023). Machine Learning Operations (MLOps): Overview, Definition, and Architecture. IEEE Access, 11, 31866 to 31879. Open version on arXiv.
- Google Cloud Architecture Center, MLOps: Continuous delivery and automation pipelines in machine learning (last reviewed August 2024)
- Sculley, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28.
- Microsoft Azure Architecture Center, MLOps maturity model (updated June 2026)
- Gartner, Gartner Survey Finds Generative AI Is Now the Most Frequently Deployed AI Solution in Organizations (May 7, 2024)
- Gartner, AI Maturity Matters: Proportion of AI and GenAI Prototypes Making It Into Production (June 2025)
- Microsoft Learn, GenAIOps for organizations that have MLOps investments
- Regulation (EU) 2024/1689 (Artificial Intelligence Act), Articles 10, 11, 12, 15, 17 and 72, as amended by the AI Omnibus (2026)
- NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0)
- ISO/IEC 42001:2023, Information technology: Artificial intelligence: Management system
This entry is for general information and is not legal advice. Regulatory details reflect published sources as of October 2026.
Knowledge - Certification - Community
