Skip to main content
Bureau of AI
Category: Model Lifecycle & MLOps

MLOps

Also known as: MLOps, Machine Learning Operations, ML Operations
Simply put

MLOps refers to a set of practices for managing the lifecycle of machine learning models, from development through deployment and ongoing operation. It aims to make building, releasing, and maintaining ML systems more efficient and reliable, often by automating and standardizing repetitive steps. The term draws on established software engineering ideas but applies them to the specific needs of machine learning projects.

Formal definition

MLOps is a set of engineering practices that applies DevOps principles from software engineering to the machine learning lifecycle, spanning data preparation, model development, deployment, monitoring, and maintenance. In many accounts it emphasizes automation and simplification of ML workflows and deployments to improve efficiency and repeatability across the model lifecycle. Definitions vary across vendors and practitioners, and the sources here describe MLOps at a general level rather than specifying a single authoritative standard; note that MLOps is an operational discipline and is distinct from, though it can support, AI governance and formal model risk management activities such as independent validation and risk monitoring.

Why it matters

MLOps matters because machine learning systems, unlike traditional software, depend on data and trained models that can change or degrade over time, making ad hoc deployment and maintenance practices fragile. By applying established software engineering and DevOps principles to the ML lifecycle, MLOps aims to make building, releasing, and maintaining ML systems more efficient, repeatable, and reliable. For organizations running models in production, this operational discipline reduces the friction and inconsistency that can arise when data scientists and engineers manage the lifecycle through manual, one-off steps.

For compliance and risk professionals, it is important to recognize what MLOps is and is not. MLOps is an operational discipline focused on the efficiency and reliability of ML workflows and deployments. It can support AI governance and model risk management—for example, by standardizing deployment and enabling monitoring—but it is distinct from those functions. MLOps does not by itself constitute independent model validation, formal risk monitoring, or the organizational accountability structures that governance and model risk management provide. Treating MLOps automation as a substitute for those controls is a common conceptual error.

Because definitions of MLOps vary across vendors and practitioners, professionals should be cautious about assuming a single authoritative standard exists. The sources describe MLOps at a general level, emphasizing lifecycle management, automation, and the borrowing of DevOps ideas, rather than prescribing a fixed set of required activities.

Who it's relevant to

Data scientists and ML engineers
MLOps is most directly relevant to the practitioners who build, deploy, and maintain ML models. It offers practices to manage the ML lifecycle more efficiently and reliably, and to automate and simplify workflows and deployments that would otherwise be handled through manual, repetitive steps.
Model risk managers and validators
For those responsible for model risk management, MLOps is an operational discipline that can support but does not replace their work. Standardized deployment and lifecycle monitoring enabled by MLOps may provide useful inputs, but independent validation and formal risk monitoring remain distinct activities that MLOps automation does not perform.
AI governance and compliance professionals
Governance and compliance specialists should understand MLOps as distinct from the organizational structures, policies, and accountability mechanisms that govern AI systems. Recognizing this distinction helps avoid treating operational automation as evidence of governance or oversight, while still appreciating how MLOps practices can support those functions.
Auditors
Auditors reviewing ML systems benefit from understanding that MLOps definitions vary across vendors and practitioners and that no single authoritative standard is described here. This matters when assessing whether an organization's stated MLOps practices actually correspond to the lifecycle management, monitoring, and control activities being claimed.

Inside MLOps

Data and feature pipelines
Automated processes for ingesting, transforming, and versioning data and features used to train and serve models. In many MLOps setups these pipelines are tracked so that inputs to a model can be reproduced and audited.
Model training and experiment tracking
Tooling and practices for running, recording, and comparing training experiments, including hyperparameters, code versions, and resulting artifacts, to support reproducibility and traceability.
Model deployment and serving
Mechanisms for moving a trained model into a production environment, such as packaging, containerization, and release patterns. This operational step is typically distinct from the validation activities emphasized in model risk management.
Monitoring and observability
Ongoing tracking of model behavior in production, which commonly includes performance metrics, data drift, and operational health. Note that monitoring for performance degradation is related to, but not the same as, the broader identification and control of model risk.
Versioning of data, code, and models
Practices for maintaining identifiable versions of datasets, source code, and model artifacts so that a specific production model can be linked to the exact inputs and logic that produced it.
CI/CD and automation
Continuous integration and continuous delivery practices adapted for machine learning, automating build, test, and release steps for model-related artifacts to improve consistency and repeatability.
Governance integration points
Interfaces where MLOps tooling can support governance and oversight, such as approval gates, documentation capture, and audit trails. MLOps supplies operational plumbing that can feed governance and model risk management processes but does not by itself constitute either.

Common questions

Answers to the questions practitioners most commonly ask about MLOps.

Is MLOps the same thing as model risk management?
No. MLOps refers to the engineering practices and tooling used to deploy, monitor, and maintain machine learning models in production, typically drawing on DevOps principles applied to the model lifecycle. Model risk management, by contrast, is the discipline of identifying, measuring, monitoring, and controlling risks arising from model use, historically framed by guidance such as SR 11-7 in the U.S. banking context. The two overlap—MLOps monitoring capabilities can support model risk controls—but they are not interchangeable. MLOps is largely an operational and technical function, while model risk management is a risk discipline with governance and validation dimensions that extend beyond deployment tooling.
Does having a mature MLOps pipeline mean a model has been validated?
Not necessarily. MLOps automates and operationalizes deployment, monitoring, and retraining, but automated pipeline checks are not the same as independent model validation. Validation, as commonly understood in model risk contexts, typically involves an independent assessment of a model's conceptual soundness, data, assumptions, and outcomes, often performed by a party separate from the development team. MLOps may include verification-style checks that confirm a model behaves as built, but this should not be confused with the broader validation activities many frameworks expect. Treating pipeline test coverage as a substitute for validation is a frequent point of error.
How does MLOps typically support ongoing model monitoring?
MLOps commonly provides the infrastructure for continuous monitoring of models in production, including tracking input data characteristics, output distributions, and performance metrics over time. This can help surface issues such as model performance degradation, where a model's predictive quality declines as conditions shift away from those seen during development. Note that performance degradation is distinct from model risk more broadly; monitoring tooling detects certain observable changes but does not by itself constitute a complete risk assessment. The specific metrics, thresholds, and alerting arrangements vary by organization and use case.
Where does MLOps fit within the lines-of-defense structure?
In many organizations that adopt a three-lines-of-defense model, MLOps activities are typically situated within the first line—those who own and operate the models and controls day to day—since the practice is oriented toward development, deployment, and operational maintenance. Independent validation and oversight functions generally sit in the second line, and internal audit in the third. This placement is a common pattern rather than a universal rule, and how a given firm maps MLOps responsibilities depends on its structure and sector. The distinction matters because operational tooling in the first line should not be relied upon to perform second-line independent challenge.
What documentation and reproducibility practices are associated with MLOps?
MLOps practices frequently emphasize versioning of data, code, model artifacts, and configurations, along with logging of training runs and deployment events, to support reproducibility and traceability. Such practices can assist governance and audit needs by making it easier to reconstruct how a model was built and changed over time. Whether these artifacts satisfy any particular regulatory or internal documentation expectation depends on the applicable framework and the organization's own standards, which vary; MLOps tooling can enable good documentation but does not by itself define what documentation is required.
How is model retraining commonly handled within an MLOps setup?
MLOps environments often support automated or scheduled retraining, in which models are updated as new data becomes available. Organizations typically apply controls around retraining—such as approval steps, testing before promotion, and change tracking—because a retrained model may behave differently from its predecessor. In many risk-oriented settings, material changes from retraining prompt reassessment or renewed validation rather than automatic promotion to production. The degree of automation appropriate for retraining generally depends on the model's risk profile and the governance expectations that apply, which differ across contexts and sectors.

Common misconceptions

MLOps is the same as, or a substitute for, model governance and model risk management.
MLOps is primarily an operational and engineering discipline for building, deploying, and monitoring models. AI governance concerns organizational structures, policies, accountability, and oversight, while model risk management concerns the identification, measurement, monitoring, and control of model risk. MLOps tooling can support both by providing traceability, automation, and monitoring, but it does not replace the independent oversight or risk-control functions those disciplines require.
Production monitoring in MLOps fully addresses model risk.
Monitoring commonly detects performance degradation and data drift, but performance degradation is only one dimension of model risk. Broader model risk includes risks arising from model design, misuse, and inappropriate application, which typically require validation and control activities beyond operational monitoring.
Automating pipelines through CI/CD ensures a model is validated and compliant.
Automation improves consistency and reproducibility of the operational process, but it does not by itself perform validation, which is a distinct activity typically involving independent assessment of model soundness. Automation can enforce that certain checks run, yet the substance of validation and any regulatory obligations remain separate concerns.

Best practices

Version data, code, and model artifacts together so any production model can be traced back to the exact inputs and logic that produced it.
Use experiment tracking to record hyperparameters, code versions, and results, supporting reproducibility and auditability.
Implement production monitoring for performance metrics and data drift, while treating it as one input to a broader model risk process rather than a complete risk control.
Design deployment pipelines with explicit approval gates and captured documentation so MLOps tooling can feed governance and model risk management processes.
Keep operational activities (deployment, automation) distinct from independent validation and oversight, ensuring MLOps supports but does not substitute for those functions.
Maintain audit trails across the pipeline so operational evidence is available to governance, risk, and audit stakeholders when needed.