# MLOps Still Can't Solve Its Hardest Problems > Source: > Published: 2026-07-15 21:04:20+00:00 [AI](https://sourcefeed.dev/c/ai)Article # MLOps Still Can't Solve Its Hardest Problems Tooling keeps improving, yet emission control, safe filtering and org friction remain open failures at production scale. [Priya Nair](https://sourcefeed.dev/u/priya_nair) MLOps sold a clean story: take the reliability practices from software delivery and apply them to models. Pipelines, versioning, monitoring, automated promotion. In practice the field still runs into problems no platform fully closes. Teams that treat these as temporary tooling gaps keep rediscovering the same breakage points once systems leave the notebook. The core claim from recent analysis is blunt. The unsolved problems include inventing a way to stop unwanted material being emitted at the source rather than filtered after the fact (while still keeping the data in training), and generalizing safe filtering of inbound requests so it becomes universally usable rather than a one-off safety layer. Those sit next to the broader, repeatedly documented obstacles that show up whenever organizations try to industrialize machine learning: technical debt in data and infrastructure, operational fragility, business misalignment, and organisational silos. Together they explain why “production ML” still feels provisional even at companies with mature stacks. ## Emission Control Is Not Filtering Post-hoc filters are the default answer for generative systems. You train on broad data, then try to scrub outputs for toxicity, privacy leaks or policy violations. That approach is fundamentally reactive. Once the model has internalized the material, every new sampling path is another chance for it to surface. The harder, still-open requirement is prevention at emission time or earlier, without simply discarding the training signal that made the model useful. Current techniques (dataset curation, preference tuning, output classifiers) remain partial and brittle under distribution shift. They also do not transfer cleanly across model families or deployment contexts. The same logic applies inbound. Request filtering that works for one product’s threat model rarely ports to another without re-engineering. Until those two capabilities become general and reliable, every production LLM service carries residual risk that cannot be patched by adding another monitoring dashboard. ## Standardization and Maturity Are Still Fuzzy Literature reviews of MLOps adoption keep surfacing the same three structural gaps: absence of widely agreed practices, difficulty keeping models consistent and scalable as data and traffic grow, and ambiguity around how to measure maturity. Different teams invent their own promotion criteria, feature stores and rollback rules. What counts as “ready for production” varies by group, so hand-offs break and reproducibility suffers. Scalability then collides with consistency: a model that performs well on a single region or cohort starts to diverge once it faces real traffic and continuous retraining. Without shared maturity language, organisations also cannot tell whether they are stuck on tooling, process or culture. The result is repeated re-platforming rather than incremental hardening. ## Organisational Friction Amplifies Every Technical Gap Technical and operational issues rarely exist in isolation. Interviews and surveys identify four recurring obstacle classes: technical, operational, business and organisational. Data scientists, ML engineers and platform teams still speak different languages about latency, cost, risk and iteration speed. Misalignment produces duplicated pipelines, shadow deployments and late-stage security surprises. Cross-functional collaboration is repeatedly listed as both necessary and chronically under-supported. Security and data management compound the problem. Complex multi-stage deployments create large attack surfaces; without clear ownership, sensitive training data and model artifacts leak into places they should never reach. Collaboration gaps turn these into chronic rather than acute failures. ## What Practitioners Should Actually Do Assume the hard problems stay open for years. Design around them rather than waiting for a universal fix. - Prefer source-side controls wherever possible. Invest in training-data lineage and exclusion lists early; treat output filters as defense-in-depth, not the primary control. - Make request filtering an explicit, versioned component of the serving path, not an afterthought bolted onto the API gateway. Keep the rules auditable and testable against adversarial inputs. - Treat experiment tracking and training visibility as first-class. The recent move by OpenAI to acquire [Neptune](https://neptune.ai)underscores that even well-resourced research groups still need better instrumentation for model behaviour and run history. Wire that visibility into your promotion gates. - Automate the parts that are already understood (CI for data validation, canary model deploys, drift alerts) while leaving human review for the unsolved residual risk. Over-automating safety decisions simply moves the failure into production. - Measure organisational health with the same seriousness as model metrics. Shared runbooks, joint ownership of SLOs, and explicit decision rights between research and platform teams reduce the most common sources of late-stage thrash. Trade-offs are real. Heavy source-side filtering can degrade model capability. Strict request guards add latency and false positives. Stronger cross-team process slows iteration. The alternative is brittle systems that look healthy in staging and then emit or accept the wrong things under load. These unsolved problems are not a reason to abandon MLOps discipline. They are a reason to stop pretending the discipline is finished. Build pipelines that expect incomplete control over emission and inbound safety, instrument everything that can be measured, and treat organisational alignment as part of the reliability budget. The teams that do so will still hit friction, but they will hit it earlier and with clearer ownership. The next generation of tools will chip away at the edges. They will not eliminate the need for engineering judgment around what the model is allowed to see, say and accept. ## Sources & further reading - [Unsolved Problems in MLOps](https://spawn-queue.acm.org/doi/pdf/10.1145/3762989)— spawn-queue.acm.org [Priya Nair](https://sourcefeed.dev/u/priya_nair)· AI & Developer Experience Writer Priya covers AI frameworks, developer productivity tooling, and the startup ecosystem across South and Southeast Asia, bringing a researcher's rigour and a practitioner's empathy to every story. She is deeply sceptical of benchmarks and asks hard questions so her readers don't have to. ## Discussion 0 No comments yet Be the first to weigh in.