What MLOps Skills Do Teams Need to Support AI?

Many financial services firms have successfully built AI proof-of-concepts but struggle to operate them reliably once they go live.

A model that performed well in testing can quietly become inaccurate as market conditions shift, data feeds change or new counterparties and instruments enter the business.

Without dedicated operational skills to catch this, the model keeps producing outputs, but those outputs are no longer trustworthy.

This is the gap that MLOps closes: the practical skills and practices needed to keep AI systems reliable, monitored and governed once they are in production.

For technology and data leaders, understanding what MLOps actually requires, and how it differs from both data science and traditional IT operations, is now essential to planning where to invest in team capability.

Why MLOps skills matter in financial services

Firms are increasingly moving AI models out of pilot environments and into live business processes such as trade surveillance, settlement checks, underwriting support and customer service triage.

Once a model is live, the work does not stop. Data feeding the model can change shape or quality. Market behaviour can shift in ways the model was never trained on. New products, counterparties or customer segments can appear that fall outside the model's original scope.

In most software contexts, a system that keeps running without errors is considered stable. AI models are different: they can continue running without any technical error while quietly becoming less accurate. This is known as model drift, and it is one of the central problems MLOps skills exist to manage.

In a regulated financial environment, this matters even more than in a typical software context. Regulators and internal risk functions expect firms to demonstrate ongoing oversight of models that influence decisions, not just evidence that a model was validated once before launch. A skills gap in MLOps is therefore not only an operational efficiency issue. It is increasingly a compliance exposure.

How teams traditionally supported production systems

Technology and data teams already have a strong foundation to build from. Traditional IT operations and DevOps practices have long supported production software through automated deployment pipelines, system monitoring, incident response and version control of code.

These skills matter for AI systems too. A model still needs to be deployed reliably, integrated with other systems, and supported when something breaks.

However, conventional DevOps monitoring is generally built to detect technical failures: a service going down, an API returning errors, latency spiking. It is not designed to detect the more subtle problem of a model whose predictions are becoming less accurate while the system itself keeps running normally.

Similarly, traditional version control tracks changes to code, but AI models depend just as heavily on the data used to train and retrain them. Traditional DevOps practices do not typically extend to tracking which version of a dataset produced which version of a model, or when that model was last retrained.

DevOps skills are a genuinely useful starting point for MLOps, but they need to be extended, not simply relabelled.

The core MLOps skill areas

Teams supporting AI in production need capability across several distinct areas.

Deployment and integration. Getting a model into the live environment safely, connecting it to the systems and data feeds it depends on, and ensuring it can be rolled back or updated without disrupting the wider business process.

Monitoring and maintenance. Tracking not just system uptime but model-specific signals: changes in the distribution of incoming data, degradation in prediction accuracy, and unusual patterns that suggest the model is being applied to situations it was not designed for.

Version and data management. Keeping a clear record of which model version is in use, which dataset and parameters produced it, and being able to reproduce or roll back to a previous version if a problem emerges.

Retraining processes. Knowing when a model's declining performance warrants retraining, having a repeatable process to retrain and revalidate it, and redeploying it with appropriate testing rather than ad hoc changes.

Governance handoff. Ensuring risk and compliance functions receive the information they need, such as model performance reports and change logs, in a form that supports their oversight responsibilities rather than requiring them to chase technology teams for evidence.

Most teams will not need every skill area deeply covered by a specialist. In smaller firms, a handful of engineers with broad exposure across these areas may be sufficient. In larger firms running many models, dedicated MLOps roles may be justified.

Where AI tools can support MLOps itself

AI-assisted tooling can genuinely help with parts of the MLOps workload. Anomaly detection tools can flag unusual patterns in incoming data or model outputs faster than manual review would catch them. Automated documentation tools can help generate consistent records of model versions, training data and performance metrics, reducing the administrative burden on engineering teams.

This support is useful, but it does not remove the need for human judgement. Deciding whether a flagged anomaly represents genuine model drift, a temporary market event, or a data pipeline error still requires an experienced person to interpret the signal. Deciding when degraded performance is serious enough to escalate to risk and compliance is a judgement call, not something that should be left to an automated threshold alone.

The realistic role of AI here is to reduce the repetitive monitoring workload so that skilled staff can spend their time on the judgement calls that actually require it.

Example

A London-based commodities trading firm deploys a machine learning model to flag anomalous settlement instructions before they are processed.

Six months after go-live, the model's flagging accuracy quietly declines as new counterparties and instrument types enter the trading book. No one notices until a compliance review raises questions about missed anomalies.

The data engineering lead responsible for the model's data pipeline and the operations manager overseeing the settlement process work together to understand what went wrong. Following the review, the firm establishes a small MLOps function within technology and data, with clear ownership for monitoring model performance, triggering retraining when drift is detected, and reporting model health to the risk committee on a regular cycle.

FAQs

• Is MLOps the same as DevOps?

  MLOps builds on DevOps principles such as automation, continuous integration and monitoring, but it adds concerns that are specific to models rather than code. These include tracking data drift, defining when retraining is needed and managing model versioning alongside data versioning. Traditional DevOps tooling and skills do not typically cover these areas without extension.

• Do we need to hire new staff to build MLOps capability?

  Not necessarily. Many firms build MLOps capability by upskilling existing data engineering and IT operations staff, since much of the underlying foundation, such as deployment pipelines and monitoring disciplines, already exists in those teams. Some firms running a large number of models at scale may still choose to bring in specialist expertise.

• How is MLOps different from the work data scientists do?

  Data scientists focus on building, training and validating models before they go live. MLOps focuses on what happens after that: keeping the model running reliably, monitoring its performance, managing retraining, and ensuring risk and compliance functions have the oversight information they need. Both skill sets are needed together, but they are distinct disciplines.