Job postings tell you what companies actually need, not what they think they need. The job title that has grown fastest in the past two quarters is not ML engineer, not data scientist, and not AI researcher. It is AI reliability engineer. The title is new enough that most job boards do not have a category for it yet, but the role is real, and it reflects a shift in where companies are spending their AI budgets.
The shift is from building models to operating them. The past three years of AI investment have produced a large inventory of models that companies have built, bought, or adapted. Many of those models work in the lab. Fewer work reliably in production. The gap between lab performance and production performance is where the AI reliability engineer lives, and it is a gap that ML engineers are not typically trained to address.
What the role actually involves
AI reliability engineering is closer to site reliability engineering than to machine learning research. The core responsibilities are monitoring model behaviour in production, detecting when model outputs degrade, diagnosing the cause of degradation, and implementing corrective actions. The corrective actions might involve retraining, prompt adjustment, data pipeline repair, or infrastructure scaling. The distinguishing skill is not model development. It is operational judgment about what to do when a production AI system starts behaving unexpectedly.
Model monitoring is the foundation. AI systems degrade in ways that traditional software does not. A traditional system either works or fails. An AI system produces outputs that are technically valid but gradually become less accurate, less relevant, or less consistent. Detecting this degradation requires statistical monitoring of output distributions, not just uptime monitoring. If your customer service chatbot’s average response quality drops by 10 percent over two weeks, your uptime monitoring will report that the system is healthy. Your reliability engineer will notice that customer satisfaction scores are declining and trace the cause to a data pipeline issue that is feeding stale information to the model.
Incident response for AI systems is different from incident response for traditional systems. When a web server crashes, the response is straightforward: restart it, identify the root cause, fix the root cause. When an AI system produces harmful or incorrect outputs, the response is more nuanced. You need to understand whether the failure is in the model, the prompt, the data, or the infrastructure. Each failure mode has a different response. Misdiagnosing the failure leads to a fix that does not address the root cause, and the failure recurs.
Capacity planning for AI workloads requires understanding how inference load scales with user behaviour. AI workloads have different load characteristics than web workloads. A web request has a predictable resource cost. An AI inference request has a resource cost that varies with input length, output length, and model complexity. Capacity planning that assumes uniform resource costs per request will either over-provision (wasting money) or under-provision (degrading performance during peak load).
Why ML engineers do not fill this gap
ML engineers are trained to build models, not operate them. The skills overlap but are not identical. Building a model requires understanding of model architectures, training procedures, evaluation methodologies, and optimisation techniques. Operating a model requires understanding of monitoring systems, incident response, data pipeline operations, and production infrastructure. Some engineers have both sets of skills, but most specialise in one or the other.
The gap shows up in how ML engineers respond to production incidents. An ML engineer’s instinct when a model degrades is to retrain it. Retraining is sometimes the right response, but it is expensive, slow, and does not address all failure modes. If the degradation is caused by a data pipeline issue, retraining on the same bad data produces a model that is differently wrong. If the degradation is caused by a prompt that interacts badly with a model update, retraining does not fix the prompt. The reliability engineer’s instinct is to diagnose first, then choose the appropriate corrective action, which may or may not involve retraining.
The career incentives also differ. ML engineers are evaluated on model performance improvements. Reliability engineers are evaluated on system uptime and incident reduction. These different incentives produce different behaviours. An ML engineer may push for a model update that improves benchmark scores but introduces production risk. A reliability engineer will push for a cautious rollout that validates the update against production traffic before full deployment. Both behaviours are valuable, but they need to be balanced, and that balance requires someone whose job is specifically to protect production reliability.
Building the capability
Companies that are hiring AI reliability engineers face a supply problem. The role is new enough that there is no established career path or training pipeline. Most candidates come from one of two backgrounds: site reliability engineers who have developed AI domain expertise, or ML engineers who have moved into production operations. Neither background is sufficient on its own. SREs need to learn how AI systems fail in ways that traditional systems do not. ML engineers need to learn operational practices that they were not exposed to during model development.
The most effective approach to building this capability is to create a rotation program where SREs and ML engineers spend time in each other’s roles. An SRE who spends three months supporting ML production systems learns the failure modes. An ML engineer who spends three months on-call for production incidents learns the operational realities. After the rotation, both are better equipped for the reliability engineer role.
Tooling matters too. AI reliability engineers need monitoring tools that are designed for AI workloads, not adapted from traditional infrastructure monitoring. The monitoring needs to track output distributions, not just system metrics. It needs to detect drift in model behaviour, not just changes in resource utilisation. It needs to correlate model performance with data pipeline health, prompt versions, and model versions. Building or buying these tools is a prerequisite for effective AI reliability engineering.
The bounded recommendation
If you are running AI systems in production, assess whether your team has reliability engineering capability specifically for AI workloads. If your reliability is handled by general SREs who also manage web infrastructure, they are likely missing AI-specific failure modes. Create a dedicated reliability function for AI, even if it starts as a single person with a clear mandate. The cost of one reliability engineer is less than the cost of a production incident that goes undiagnosed for weeks.
