The Question
The model is in production. It is serving real users, generating real outputs, influencing real decisions. The data science team is proud of the accuracy metrics it achieved in evaluation. The engineering team is proud of the serving infrastructure they built to host it.
Six months later, a business stakeholder notices the AI outputs are "not as good as they used to be." The data science team investigates. They pull the model, run it against the evaluation dataset from six months ago, and confirm the model has not changed — the weights are identical. They then investigate the input data distribution and discover that the production input data has shifted significantly from the training distribution over the past six months. The model was never designed to handle the new distribution.
Nobody had been watching for this. There was no drift monitoring. There was no automated alerting on prediction distribution shifts. There was no defined retraining trigger. There was no automated retraining pipeline. The model in production was, operationally speaking, an artifact that had been deployed and abandoned — expected to perform indefinitely without maintenance or monitoring, in a production environment that was continuously evolving around it.
This is the MLOps gap. It is not a technology problem. The tools to solve it exist and are mature. It is an organizational and process problem — and it is extraordinarily common.
A model in production without MLOps is an operational liability — it degrades silently, cannot be updated safely, and requires a data scientist's manual intervention to diagnose every incident.
Why This Matters Now
In 2025, Gartner published a statistic that had been circulating in the MLOps community for several years but had not previously been formally quantified: fewer than 15% of ML models that are trained ever reach production. Of those that do reach production, a significant fraction lack the operational infrastructure — monitoring, retraining pipelines, versioning, rollback capability — that would make them maintainable over time.
The 85% figure represents an enormous waste of data science investment. Models trained, evaluated, and never deployed. Proof-of-concepts that demonstrated business value but were never operationalized. Pilots that ran well in controlled environments and were never scaled.
The reasons are structural and well-documented. Data science teams are optimized for research velocity — rapid experimentation, fast iteration on model architectures, maximizing evaluation metrics. They operate in notebook environments with minimal reproducibility requirements. They prototype with hardcoded file paths, undocumented preprocessing steps, and dependencies on specific environment configurations that are never formalized.
When a model needs to move to production, the gap between the research prototype and a production-grade system becomes visible: no reproducible training pipeline, no versioned artifacts, no automated evaluation gate, no monitoring instrumentation. Building those components is a separate engineering project, often larger than the original model development effort, and one that neither the data science team nor the platform engineering team fully owns.
The result is a persistent pattern: models deployed to production in a state that is operationally insufficient, maintained manually by data scientists who are simultaneously doing new model development, and degrading silently until a business stakeholder escalates a quality concern.
The emergence of managed MLOps platforms — Weights & Biases, Databricks, Vertex AI Pipelines, Amazon SageMaker Pipelines — reflects the industry's attempt to reduce the engineering effort required to bridge this gap. The platforms exist and are mature. The adoption and process discipline required to use them effectively is still catching up.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Infrastructure CURVE™ Report evaluated MLOps platform vendors across six capability dimensions: experiment tracking, model registry and versioning, feature store integration, pipeline orchestration, model monitoring and drift detection, and deployment and serving management. Vendors assessed include Weights & Biases, Databricks (MLflow + Feature Store), Amazon SageMaker (MLflow integration, Pipelines, Model Monitor), Google Vertex AI (Experiments, Pipelines, Model Monitoring), Microsoft Azure ML, Comet ML, and open-source stacks (MLflow + Prefect + Feast + Evidently AI).
The CURVE™ analysis found the greatest capability gaps in model monitoring and drift detection — the category that most directly determines whether a deployed model is being actively managed or passively decaying. Commercial platforms have invested heavily in this area, but adoption of monitoring capabilities significantly lags adoption of training and experiment tracking capabilities, even within organizations that have licensed the full platform.
The report also assessed the total cost of ownership difference between commercial MLOps platforms and open-source stacks at three organizational scales, finding that the engineering labor cost to operate open-source stacks at enterprise scale frequently exceeds the licensing cost of commercial platforms.
The full vendor rankings are in the 2026 Stackcurve AI Infrastructure CURVE™ Report — free to download.
The Gap Most Buyers Miss
MLOps is frequently described as a single thing — a platform, a tool, a team. In practice, it is a stack of six distinct capabilities, each addressing a different operational failure mode. Organizations that implement some but not all of these capabilities have partial operational coverage, and the gaps consistently correspond to the failure modes they experience.
Experiment Tracking
Before a model can be reproduced, the experiment that produced it must be reproducible. Experiment tracking captures the hyperparameters, dataset versions, environment configuration, and evaluation metrics for every training run. Without it, the data science team cannot reproduce a specific model version, cannot compare experiments rigorously, and cannot answer "what changed between this model version and the previous one?" when a production quality issue is investigated.
Weights & Biases and MLflow both provide experiment tracking as a core capability. The organizational requirement is that using the tracking system is mandatory for every training run — not optional, not "when you remember."
Model Registry and Versioning
A model registry is the source of truth for production model artifacts. It maintains versioned records of every model that has been promoted to staging or production, with metadata linking each version to the experiment that produced it. Without a model registry, production deployments are unversioned — the team knows a model is in production, but not which exact artifact it is or how to reproduce it.
The model registry also provides the workflow for promoting models from development to staging to production, with the associated approval gates and rollback capability. MLflow Model Registry and Weights & Biases Model Registry both support this workflow. The organizational requirement is that all production model deployments flow through the registry, with no direct deployment from a data scientist's local environment.
Feature Store
The feature store solves one of the most persistent sources of model quality degradation: training/serving skew. When the feature engineering logic applied to training data differs from the feature engineering logic applied at serving time — even subtly — the model receives different input distributions than it was trained on. A feature store enforces a single feature computation definition that is shared between training and serving, eliminating this class of skew by design.
Feast (open source), Tecton, and Databricks Feature Store are the leading options. The organizational requirement is that feature engineering logic lives in the feature store, not in separate training scripts and serving handlers maintained by different teams.
Pipeline Orchestration
Automated pipelines for training, evaluation, and deployment replace manual, data-scientist-driven processes. A training pipeline that runs automatically — on a schedule, on a data freshness trigger, or on a performance threshold breach — decouples model operational health from data scientist availability and attention. Without automated pipelines, every model update requires manual execution, the process is not reproducible across team members, and steps are skipped under time pressure.
Apache Airflow, Prefect, and Kubeflow Pipelines are the primary orchestration options. Kubeflow Pipelines integrates natively with the Kubernetes infrastructure common in enterprise ML platforms. The organizational requirement is that training, evaluation, and deployment are defined as code in the pipeline system, with human approval gates at promotion steps but no manual execution requirements.
Model Monitoring and Drift Detection
Deployed models operate in a changing world. Data distributions shift, user behavior changes, upstream data sources evolve. A model that was well-calibrated at deployment drifts from its optimal performance as the production distribution diverges from the training distribution. Without monitoring, this drift is invisible until a business stakeholder notices degraded outputs.
Model monitoring covers three distinct dimensions: data drift (are the input distributions changing?), prediction drift (is the model's output distribution changing?), and performance drift (for systems with ground truth feedback, is the model's accuracy changing?). Evidently AI, Arize AI, and WhyLabs are the leading purpose-built monitoring platforms. SageMaker Model Monitor and Vertex AI Model Monitoring provide monitoring capabilities integrated with their respective cloud platforms.
Deployment, A/B Testing, and Rollback
Safe model deployment requires the ability to route a fraction of production traffic to a new model version while maintaining the previous version in service — and to roll back instantly if the new version degrades. Without canary deployment and rollback capability, every model update is a full production swap with no safety net. Seldon Core, BentoML, and Ray Serve all support canary deployments and traffic splitting. The organizational requirement is that no model is promoted to full production traffic without a canary period with defined rollback criteria.
Questions Your Buying Team Should Be Asking
1. For each production AI model, can the team reproduce the exact artifact from the exact experiment that produced it?
Ask your data science or ML engineering team to demonstrate reproducibility for your highest-criticality production model. Can they identify the exact training dataset version, hyperparameter configuration, and environment that produced the deployed model? If not, the experiment tracking and model registry infrastructure is not in place — or is not being used consistently.
2. Is there an automated retraining pipeline for each production model, and what triggers a retraining run?
A production model without an automated retraining pipeline will degrade over time and require manual data scientist intervention to update. Ask for the specific retraining trigger for each production model: is it scheduled, performance-threshold-based, or data-drift-triggered? If the answer is "we retrain it when someone notices a quality issue," the retraining process is reactive rather than proactive.
3. Is model monitoring active on all production models, and what alerts are configured?
Ask for a demonstration of the monitoring system for a production model: what metrics are being tracked, what thresholds are configured, who receives alerts, and what was the most recent alert? If monitoring is in place but never fires alerts, either the system is perfectly healthy or the monitoring thresholds are misconfigured. Both are worth investigating.
4. Can the team roll back a deployed model to the previous version in under 30 minutes?
This question tests the operational readiness of the deployment infrastructure. Rollback capability requires a versioned model registry, a deployment system that supports traffic routing to a prior version, and a documented procedure. If the team cannot demonstrate sub-30-minute rollback, a degraded model deployment becomes a potentially hours-long incident.
5. Who owns the operational health of production AI models — data science, ML engineering, or platform engineering — and is that ownership documented and SLA-backed?
Unclear ownership is one of the most common root causes of MLOps gaps. Data scientists feel they are responsible for model quality, not model operations. Platform engineering feels AI models are someone else's problem. The result is that monitoring alerts go to nobody and incidents are escalated informally. Ask for the documented ownership of production AI model operational health and the associated SLA for incident response.
The Stackcurve Take
The MLOps gap is not a capability gap. The tools to close it are mature, well-documented, and available as managed services that do not require significant platform engineering investment. Weights & Biases covers experiment tracking, model registry, and monitoring in a single platform. Databricks provides a unified stack from feature engineering through model serving with integrated MLflow capabilities. SageMaker and Vertex AI provide end-to-end MLOps capabilities within their respective cloud ecosystems.
The gap is organizational: MLOps requires process discipline that runs against the grain of data science teams optimized for research velocity. Mandatory experiment logging, model registry promotion workflows, automated pipelines, and monitoring are all friction — small amounts of friction that pay enormous dividends in production reliability, but friction nonetheless.
Closing the MLOps gap requires leadership commitment to operationalizing AI models as production software, not research artifacts. It requires clear ownership of production model health, defined SLAs for model operational performance, and investment in the tooling and process to make MLOps the default path rather than the exceptional path.
The organizations that have made this investment are building a compounding advantage: each iteration of model development is faster because experiments are reproducible, each deployment is safer because rollback is instant, and each production incident is shorter because monitoring surfaces the root cause before the business notices.
The organizations that have not made this investment are accumulating technical debt in the form of unmonitorable, unupdatable production models — and the cost of that debt compounds every month those models remain in production without operational infrastructure.
The 2026 Stackcurve AI Infrastructure CURVE™ Report covers MLOps platform assessments, open-source versus commercial stack comparisons, and organizational maturity models for enterprise AI operations. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.