MLOps should help every machine learning effort become a maintained, continuously improved machine learning product.
2
A successful MLOps setup depends on people, processes, organizations, and technology, rather than on a fixed set of tools.
3
Teams should prove business value with small projects before adding the distinct roles and resources needed for a larger MLOps operation.
Summary
Niklas Kühl explains MLOps through the practical problem of turning machine learning work into products that create business value. He argues that the end goal should always be a fully operationalized product that is maintained, run, and improved over time. MLOps therefore includes technical architecture, workflows, organizational design, and collaboration between distinct roles. Kühl is honest about the gap between the ideal model and practice. In small companies, one data scientist may cover data science, engineering, software, and operations. He recommends starting with a small project, showing value, and using that evidence to secure the budget for a larger team. The conversation also covers how success can include business insight and better understanding of data, rather than only model performance. Kühl closes by discussing data-centric AI and human-AI teams, where systems should complement human strengths instead of simply maximizing standalone model performance.
MLOps grew from the difficulty of moving machine learning into real products
Kühl describes MLOps as a response to the gap between building a model and operating a product. He saw this gap in consulting work and in his research, where machine learning projects needed more than algorithms. A product must run continuously, be maintained, and improve over time. The goal is therefore broader than getting a model to work in a notebook or proving that a prediction is accurate once. MLOps provides a way to think about the full path from an initial idea to a machine learning product that creates value.
The business case has to come before the full team design
Kühl says production machine learning can become expensive because it needs several kinds of work and can require significant computing resources. Before starting, teams need to convince a customer that the project is worth exploring and should think about its return on investment. His practical approach is to build even a small proof of concept in a way that can become productive and scalable from the start. Showing an early, tangible result helps a customer understand where the project is going and can make it easier to secure the budget for a proper MLOps team.
MLOps is a socio-technical practice rather than a tool bundle
Kühl deliberately avoids defining MLOps as a collection of products or pipelines. His research looked for principles that would remain useful even as technologies changed. He describes the field through the interaction of technology, people, and organizations. This matters because tools operate inside companies and are used by people with different responsibilities. A company with one data scientist may expect that person to act as a data scientist, machine learning engineer, software engineer, data engineer, and DevOps engineer. That arrangement can work briefly, but it is difficult to scale.
Teams usually grow through stages after they prove an initial product
Kühl describes a common pattern in which a data science center or center of competence works with business units. Early work focuses on showing that a machine learning product can create value, often with a small group of people covering many roles. Once the first products succeed, the organization receives more headcount and must decide which role to add next. Over time, standards and workflows develop, the roles begin to work together, and products become more scalable. Kühl does not claim there is a precise headcount or a universal point where the mature stage begins.
Success depends on the business purpose and cannot be reduced to one model score
Kühl says some companies judge a product through a performance metric, such as the quality of anomaly detection or price prediction. Other products create value by revealing useful information about operations or exposing weaknesses in a company's data. The development process itself can teach a company about its data quality and its readiness for data-driven products, even when the final model does not meet its original target. Business stakeholders differ in how they judge this value. Some want a specific performance threshold, while others find a few useful insights valuable.
Data-centric AI can improve a product by changing the data collection process
Kühl contrasts a model-centric approach, which focuses on finding a slightly better model, with a data-centric approach. In an industrial setting, the best improvement may come from changing how data is collected. He gives the example of adding a sensor or camera at a point in a factory where it would provide useful information. That requires machine learning practitioners to think beyond model training and sometimes work directly in the field. The broader point is that product quality depends on the whole system that produces the data, not only on model architecture or hyperparameter choices.
Human-AI systems should be designed for complementarity
Kühl argues that machine learning products and people have different strengths. Combining them without considering those differences may leave the team no better than the strongest individual component. He wants systems designed around complementarity, where the machine supports human abilities and the human contributes abilities the machine lacks. This affects how predictions are presented, how people interact with them, and how explanations are provided. His research suggests that a team designed for complementary contributions can perform better than a system that only tries to maximize the model's standalone performance.
General-purpose models are promising, but their industrial value remains uncertain
Kühl sees foundational models as especially interesting for industry because a more general model can support many tasks. He is careful about predicting how well current models will work across different domains, since specific models will still matter in both research and industry. His own work with IBM Research is exploring foundational models for climate disasters, but he does not yet know whether that effort will succeed. He also describes the difficulty of keeping up with the growing research literature. The volume of papers has become too large for one person or even one institute to read, understand, and reproduce fully.
"Sometimes it only does require one additional sensor here or one additional camera here and it would give you all the things that you need."Niklas Kühl46:31
Who should watch
You are building machine learning products and need to explain why production work requires more than model training.
Your company has one data scientist covering several engineering and operations responsibilities and you need a way to plan team growth.
You want a business-focused definition of MLOps that includes return on investment, organizational roles, and product maintenance.
