A team reaches for Google’s Site Reliability Engineering book the week an AI feature ships, hoping for a vocabulary it can adopt wholesale: SLOs, error budgets, on-call rotations, blameless postmortems. The instinct is sound. The literal transcription is where it goes wrong. The SRE book is the closest thing the industry has to a shared grammar for keeping production systems healthy, and most of that grammar transfers. But it was written against a model of failure that an AI feature quietly breaks: a service is assumed to fail loudly. It returns errors, it times out, it saturates, and a health check goes red. An AI feature can stay green on every one of those signals while its output quality degrades to the point of being wrong — and an SLO defined only on uptime will never notice. The discipline is the right backbone. The reliability surface it instruments needs AI-specific instrumentation bolted on. How Does the SRE Book Work, and Where Does It Stop Short for AI? The book’s core move is to turn reliability from a feeling into a contract. You define Service Level Objectives — measurable targets like “99.9% of requests succeed within 300ms” — and you measure against them continuously. The gap between your SLO and 100% is your error budget: the amount of unreliability you’re allowed to spend. When the budget is healthy, you ship fast. When it’s exhausted, you stop shipping features and spend the engineering effort on reliability instead. On-call rotations carry the human response, and blameless postmortems convert every incident into a systemic fix rather than a search for someone to blame. That framework is sound enough that we treat it as the default starting point in any reliability conversation. The problem is the implicit definition of “request succeeded.” For a payments API, success is unambiguous: the right HTTP status, the right latency, the correct balance. For an AI feature, a response can arrive on time, with a 200 status, and be confidently, silently wrong. The transaction succeeded by every signal the book teaches you to instrument. The user got a hallucinated citation, a misclassified image, or a recommendation that drifted off-distribution three weeks ago. This is the divergence point. SRE assumes failure is observable at the boundary of the service. AI failure frequently lives inside a response that looks healthy from the outside. Which SRE Concepts Translate Directly, and Which Need Rework? Most of the operational scaffolding transfers without change. What needs rework is anything whose definition of “correct” assumes a deterministic service. The table below is the translation we apply when adapting an SRE-literate team’s existing practice to an AI feature. SRE concept Transfers as-is? What AI changes On-call rotation Yes Page on quality-regression alerts, not only on latency/error pages. Blameless postmortem Yes Add drift/hallucination incident classes; root cause is often upstream data, not code. Error budget policy Backbone transfers The budget must be spent against quality SLOs too, not just uptime. SLO definition Needs rework Uptime/latency SLOs miss silent quality decay; add eval-coverage and drift SLOs. The four golden signals Partially Latency, traffic, errors, saturation still matter — but quality is a fifth axis they don’t capture. Unit-test coverage gate Replace Eval-coverage is the AI analogue; a passing unit test says nothing about model behaviour. Health-check kill-switch Needs rework A green health check can mask a degraded model; the kill-switch needs a quality trigger. The pattern is consistent: the process — rotations, postmortems, budget-gated releases — survives intact, because it’s about how a team behaves under pressure. The measurements that feed those processes are where AI demands new instruments. A team that adopts the book’s process discipline but keeps its deterministic-service measurements will run a beautifully disciplined operation against the wrong signals. Why Do Uptime-Only SLOs Miss AI Reliability Regressions? The four golden signals of SRE — latency, traffic, errors, saturation — are designed to tell you whether a service is available and responsive. They were never designed to tell you whether it’s right. For a conventional service that’s fine, because availability and correctness are tightly coupled: if the database returns the wrong balance, you get an error somewhere. For an AI feature they decouple completely. The model can be fast, well-resourced, error-free, and steadily getting worse. Consider a classifier whose upstream data distribution shifts — a common, gradual failure that we cover in more depth in our breakdown of how data drift and model drift change your reliability response. Latency holds. Traffic holds. The error rate is zero, because the model returns a confident label for every input. Saturation is nominal. Every golden signal is green while accuracy erodes by a few points a week. The first signal an uptime-only SLO gives you is a customer complaint — and by then the regression has been live for weeks. A quality-aware SLO closes that gap. It defines a measurable quality target — eval-set accuracy above a threshold, a drift metric below a bound, a human-rated sample passing at some rate — and measures it on a schedule against production traffic. The operationally relevant point is that this should be measured under real conditions, not only against a frozen test set, which is the same reasoning that governs steady-state capacity planning for AI inference: a metric that only holds at launch tells you nothing about week six. With a quality SLO in place, time-to-detect moves from “next customer complaint” to monitor-driven minutes — the single highest-leverage change an SRE-literate team can make when adapting the book to AI. How Does an Error Budget Help Decide Whether to Pause a Rollout? The error budget is the book’s most underused idea, and it’s the one that translates with the most force to AI. The mechanism is simple: you have a quantified allowance for unreliability, and when you’ve spent it, a policy — not a meeting, not a vibe — pauses the rollout. Extend the budget to quality and you get a defensible threshold for the hardest call in AI operations: do we keep rolling this model out, or pull it back? Instead of an ad-hoc judgement when someone notices the outputs look off, you set a quality error budget — say, the eval-coverage delta or the drift metric may degrade by no more than a defined amount over a rollout window — and the policy fires automatically when it’s breached. This is exactly the quantified input that feeds a structured release-readiness decision framework: the budget converts a subjective “is it good enough?” into a measured “have we spent the allowance?” The value is twofold. It removes the political weight from the rollback decision — no one is overruling anyone, the policy fired — and it gives the team a number to defend to a VP who wants the feature shipped yesterday. An error-budget-driven pause is far easier to hold than an engineer’s gut feeling that the model “seems worse.” What Does Blameless-Postmortem Discipline Change for Drift and Hallucination Incidents? Blameless postmortems are the book’s cultural contribution: every incident is a failure of the system, not the person, and the output is a fix that makes the same failure impossible or detectable next time. For AI, the discipline matters even more, because the root cause is so rarely in the code. When a hallucination or drift incident is dissected blamelessly, the chain almost always runs upstream into data, distribution shift, or a missing eval — not into a line someone wrote wrong. In our experience reviewing post-incident analyses, the most valuable artefact a drift postmortem produces is a new eval case: the specific failure becomes a permanent test that the monitoring harness now watches for (observed across our reliability engagements; not a benchmarked rate). That’s the AI analogue of “add a regression test.” Without the blameless frame, teams burn the incident searching for who approved the model, and the eval that would have caught it next time never gets written. Which Golden Signals Still Apply, and What AI-Specific Signals Sit Alongside Them? The four golden signals are not wrong for AI — they’re incomplete. Latency, traffic, errors, and saturation still tell you whether the serving layer is healthy, and a serving layer that’s saturated or throwing errors will absolutely degrade an AI feature. You keep all four. The reasoning behind the saturation and latency signals is also where the gap between peak and steady-state performance becomes the operationally relevant measure — a feature that’s fine at peak burst but degrades under sustained load fails in a way the raw golden signals describe but don’t fully diagnose. What you add is a quality axis the book never instruments: Eval-coverage — what fraction of production behaviour is exercised by an eval set, and is that coverage drifting as inputs change. Drift — distribution shift in inputs and in model outputs, measured continuously rather than at training time. Quality regression — a direct measure of output correctness, via held-out evals, human-rated samples, or proxy metrics, tracked as a first-class signal. These three sit beside the original four, and the kill-switch is wired to all seven — not just the deterministic ones a green health check covers. FAQ How does the Site Reliability Engineering book work, and what does it mean in practice for production AI? The SRE book turns reliability into a measurable contract: you define SLOs, measure against them, treat the gap to 100% as an error budget, and gate releases on that budget — backed by on-call rotations and blameless postmortems. For production AI, the process discipline transfers intact, but the book’s measurements assume a service fails loudly. AI features can stay green on every standard signal while their output quality silently degrades, so the framework needs AI-specific instrumentation added. Which SRE concepts — SLOs, error budgets, on-call, postmortems — translate directly to AI features, and which need rework? On-call rotations, blameless postmortems, and the error-budget process transfer almost unchanged, because they govern how a team behaves under pressure. SLO definitions and health-check kill-switches need rework, because their definition of “correct” assumes a deterministic service. Unit-test coverage gates should be replaced by eval-coverage, the AI analogue. Why do uptime-only SLOs miss AI reliability regressions, and what does a quality-aware SLO look like? Uptime and latency SLOs only measure availability and responsiveness, which decouple from correctness for an AI feature — a model can be fast, error-free, and steadily getting worse. A quality-aware SLO defines a measurable quality target (eval-set accuracy above a threshold, drift below a bound, sampled outputs passing at some rate) and tracks it against production traffic on a schedule, moving time-to-detect from a customer complaint to monitor-driven minutes. How does an error budget help decide whether to pause an AI feature rollout? Extend the error budget to quality — for example, allowing the eval-coverage delta or a drift metric to degrade by no more than a defined amount over a rollout window — and a policy fires automatically when the budget is spent. That converts the rollback call from an ad-hoc judgement into a quantified, defensible threshold the team can hold against pressure to keep shipping. What does blameless-postmortem discipline change about how teams respond to drift or hallucination incidents? It reframes the incident as a system failure rather than a search for who approved the model, which matters for AI because the root cause is usually upstream data or a missing eval, not a coding mistake. The most valuable output is typically a new eval case — the specific failure becomes a permanent test the monitoring harness watches for next time. Where does the SRE book’s service-failure model break down for silent AI quality degradation? The book assumes failure is observable at the service boundary: errors, timeouts, saturation, a red health check. AI failure frequently lives inside a response that looks healthy from the outside — a confident, on-time, 200-status answer that is simply wrong — so the model’s “service is up” assumption misses the regression entirely. How do these SRE principles show up concretely in a production AI reliability audit? The quality-aware SLOs, error-budget policy, and on-call ownership described here become a scored, AI-specific artefact in a production AI reliability audit, which instruments incident rate, time-to-detect, time-to-rollback, and eval-coverage delta. The principles are operationalised inside the audit’s release-readiness checklist and ownership matrix. The SRE book describes the four golden signals (latency, traffic, errors, saturation) — which still apply to an AI feature, and what AI-specific signals need to sit alongside them? All four golden signals still apply, because they tell you whether the serving layer is healthy. What they don’t capture is correctness, so an AI feature adds a quality axis: eval-coverage, drift, and quality regression. The kill-switch is wired to all seven signals, not just the deterministic ones a green health check covers. Where This Lands The SRE book is the right backbone — adopt its process discipline without apology. But treat its measurement model as written for a world where services fail loudly, and bolt on the quality instrumentation AI demands before you trust a green dashboard. The principles in this article become a scored, AI-specific deliverable in what a production AI monitoring harness actually contains, the artefact that operationalises the SLOs and ownership described here. If you’re translating an existing SRE practice to your first production AI feature, the production AI monitoring harness is where these concepts stop being a reading list and become a checklist — and our broader consulting services are where that translation gets done against your specific failure surface. The question worth holding onto is the one the golden signals can’t answer on their own: when your AI feature next degrades, will a monitor tell you first, or will a customer?
