MLOps: a side skill or a career path of its own?

The wrong question: "which tools should I know?"

MLOps is often reduced to a list: containers, orchestration, continuous integration, an experiment tracker, a model registry. Those building blocks exist, they can be learned, and mastering them alone neither lands a role nor keeps a system running. A profile reciting tools without being able to explain what they monitor, why, and what they do when an indicator degrades is indistinguishable from a generalist DevOps profile.

The professional question is rather: what are you accountable for between the moment a model works on a laptop and the moment a service depends on it every day? That interval defines the job, and it does not hold the same content in every organisation.

The real responsibilities across the lifecycle

Reproducibility and data

A result you cannot reproduce is not a usable result. Reproducing means knowing which data was used, in what state, with which transformations, which code and which parameters. The data side is the most underestimated: without versioning of datasets and transformations, a gap between two training runs stays unexplained and a production incident stays undiagnosable.

Artifacts, versions and deployment

A model in production is a dated artifact tied to a code version, a dataset, a runtime environment and an interface contract. Deployment then raises familiar questions in adapted form: how to move to a new version without interrupting the service, how to compare old and new on real traffic, and how to roll back quickly. The ability to roll back is often what allows a team to move fast.

Testing, monitoring and drift

Testing an ML system goes beyond unit tests on the code. You also check input data quality, consistency of transformations between training and serving, stability of outputs on a reference sample, and behaviour on missing or aberrant values.

• Technical monitoring: availability, latency, error rate, saturation. Necessary, not sufficient.
• Input monitoring: how the distribution of incoming data moves relative to training data.
• Output monitoring: prediction distribution, abstention rate, edge cases, gaps between user segments.
• Actual quality: when ground truth arrives later — sometimes weeks later — you need a mechanism to tie it back to past predictions.
• Alerting and decision: a degrading indicator must trigger something defined, otherwise monitoring only records what already happened.

Security, cost and governance

Access to training data and logs, personal data, environment separation, secrets, traceability of automated decisions, retention of what is needed to explain a past decision: these are not administrative formalities, they often determine what can go to production at all. Cost is steered too: training, inference, storage and trace retention are trade-offs that come back regularly.

These responsibilities are not always carried by the same person. In a small structure one person covers them partially; in a large one they are split across teams with boundaries specific to the organisation. Describing what you actually carried is more useful than claiming a theoretical scope.

What GenAI systems change

When the model is called through an external API, part of the classic work disappears — no training, no GPU fleet — and other work appears. Accountability shifts to what surrounds the model.

• Provider dependency: model versions that evolve or are retired, behaviour that changes without any change on your side, rate limits, outages. Planning a fallback is an architecture decision, not a detail.
• Prompts and configurations: versioned artifacts, tested and deployed like code, not strings edited directly in production.
• Evaluation: instead of one metric, case sets replayed on every change, including known failure cases.
• Traces: query, context provided, output, cost, latency. Without them no incident analysis is possible, and retaining them raises confidentiality questions of its own.
• Guardrails: input and output filtering, restriction of permitted actions, fallback behaviour when a control blocks a response.
• Cost and latency: full production indicators, monitored per use case rather than only in aggregate.

What carries over from classic ML is the discipline: measure, version, monitor, be able to roll back. What changes is the objects being monitored and the fact that part of the system sits outside your control.

DevOps, ML Engineering, MLOps, GenAI operations

These terms overlap, and the boundaries vary by company. The distinctions below are useful conversational markers, not official definitions.

1. 1

   DevOps

   marker

   Delivery pipeline, infrastructure, reliability, application observability. Code and its execution are the determining objects. Data is not a first-class concern.

2. 2

   ML Engineering

   marker

   Designing and industrialising the model side: data preparation, training, optimisation, serving. The emphasis is on building the system, with a strong software component.

3. 3

   MLOps

   marker

   Making and keeping those systems operable: reproducibility, data and model versioning, deployment, monitoring, drift, rollback, cost, compliance. The emphasis is on the system's lifetime, not only on its launch.

4. 4

   LLMOps / GenAI operations

   marker

   The same discipline applied to systems built on often external models: prompt and configuration versioning, evaluation by case sets, traces, guardrails, provider dependency management, cost per request.

In practice many job ads use one title for a different reality. All the more reason to ask precise questions in interviews: who deploys, who is paged on an incident, who decides on a rollback, who watches quality and how often.

A side skill or a career path?

Both genuinely exist, and the question cannot be settled in the abstract. In a small team MLOps is a side skill carried by people with another title: the ability to reach production is then what separates a project that ships from one that stays a demo. In an organisation running several systems in parallel, the function becomes a role of its own, with platform responsibility and multiple stakeholders.

Two signals tell you whether it is becoming a path: does the work target one system or the shared means serving several systems? And does the role consist of delivering, or of deciding how delivery happens? Moving from the first to the second is what turns a skill into a path.

What an MLOps profile should be able to explain in interviews

Rather than a technology list, here are the questions you should be able to answer from real experience. A good answer describes a context, a decision and a consequence.

• How do you reproduce a result obtained six months ago? What do you need for that?
• What do you monitor once the system is live, and what triggers an action?
• How do you know a model is degrading when ground truth arrives late, or never?
• How do you deploy a new version, and how long does a rollback take?
• What has broken in production, and what did you change afterwards?
• How do you prevent a transformation from differing between training and serving?
• What does your system cost, and which line item dominates?
• On a GenAI system: how do you test a prompt or model version change before deploying it?
• What data is kept in your traces, and for how long?

None of these require a specific tool. They check that you have carried responsibility over time, which is precisely what the job is about.

• MLOps
• Production
• Evaluation