What Production AI Teams Can Learn From Site Reliability Engineering

Treat Model Behaviour as a Reliability Problem

Production AI fails differently from conventional software, but not so differently that engineering discipline becomes irrelevant. A payments API is expected to return the correct response within a known latency envelope; a language model may return a plausible but wrong answer, comply inconsistently with policy, or degrade when user behaviour shifts. In both cases, the system sits inside a chain of dependencies and serves users with measurable expectations. Site reliability engineering offers a useful operating model because it begins with outcomes, accepts that failure is inevitable, and forces teams to decide how much failure is tolerable.

The key shift is from asking whether a model is “good” to asking whether an AI-enabled service is reliable enough for a defined purpose. A support assistant might need to cite an approved source in 99.5% of eligible answers, keep harmful-policy violations below 0.05%, and respond within four seconds at the 95th percentile. Those thresholds will vary by workflow: a drafting tool can tolerate more factual errors than an autonomous refund agent. Reliability belongs to the whole product, including retrieval, prompts, policy filters, model providers, human escalation and downstream actions—not to a benchmark score in isolation.

Define Service-Level Objectives for AI Outcomes

SRE distinguishes service-level indicators, objectives and agreements. AI teams should do the same. An indicator is a measurement, such as citation validity, task completion, groundedness, escalation rate or end-to-end latency. An objective is the target over a period: for example, 99% of customer-service conversations should complete without a severe policy breach during a rolling 28-day window. An agreement is the external promise, usually with consequences. Teams often jump directly to vague promises about accuracy, although accuracy may be impossible to define consistently across open-ended tasks.

Useful AI objectives combine conventional availability with behavioural quality. Consider an invoice-processing service. It might target 99.9% request availability, 98.5% exact extraction accuracy on critical fields, less than 0.2% silent corruption, and 99% of cases completed within 30 seconds. Silent corruption deserves a stricter threshold than a visible failure because an explicit rejection can enter a manual queue, whereas a wrong bank account number may trigger a costly payment. Segmenting objectives by risk prevents a high average from concealing serious failures in a small but important class.

Measurement must also reflect production traffic. A static evaluation set provides comparability, but it cannot capture new products, accents, adversarial prompts or seasonal demand. Strong teams blend labelled test suites, sampled human review, automated checks and operational telemetry. They define eligibility rules and confidence intervals before incidents occur. If only 200 conversations are reviewed each week, a reported 99.5% success rate is too fragile to support fine-grained claims; the sampling programme must match the decision being made.

Use Error Budgets to Balance Shipping and Safety

An error budget converts an objective into an allowance for failure. If an AI service has a 99.5% quality objective across one million eligible outputs per month, it has a budget of 5,000 failed outputs. That number is not permission to be careless. It is a mechanism for deciding when to prioritise features, experiments or reliability work. When the service is comfortably within budget, teams can move faster. When consumption accelerates, risky releases pause and engineering effort shifts towards diagnosis, containment and prevention.

AI systems need more than one budget because failures have unequal consequences. A hallucinated restaurant opening time and fabricated medical dosage cannot share a single pool. Teams can establish separate budgets for severe safety events, material factual errors, latency and ordinary task failures. A healthcare assistant might allow zero uncontained critical medication errors, while tolerating a 1% rate of harmless formatting defects. Weighted budgets are possible, but they can obscure accountability; a simple hierarchy of severity classes is often easier to operate.

Burn rate matters more than the monthly total. Consuming 20% of a 28-day budget in six hours indicates an acute incident even if the cumulative objective still appears healthy. Multi-window alerts reduce noise: a fast alert might trigger when the two-hour burn rate exceeds 14 times the sustainable rate, while a slower alert catches a three-day degradation at twice the rate. This approach is more useful than arbitrary alarms on individual metrics because it connects paging directly to user impact.

Build Runbooks for Probabilistic Failures

Traditional runbooks document symptoms, checks, mitigations and escalation paths. AI runbooks should add model-specific failure modes: retrieval contamination, prompt regressions, provider drift, context truncation, unsafe tool calls, evaluation blind spots and sudden changes in refusal behaviour. A responder facing a spike in unsupported answers should not have to invent a diagnostic sequence under pressure. The runbook can specify how to inspect recent deployments, compare model versions, validate retrieved documents, isolate affected cohorts and switch to a safer configuration.

Mitigations should be designed before they are needed. Options include disabling autonomous actions, narrowing tool permissions, lowering traffic to a new model, increasing human review, reverting a prompt, freezing a corrupted index or falling back to deterministic workflows. A fallback does not have to preserve every feature. During an incident, returning a sourced list of documents may be preferable to generating a polished but unreliable synthesis. Graceful degradation is an explicit product capability, not merely an infrastructure pattern.

Runbooks must name owners and decision thresholds. If the severe-error rate exceeds 0.1% for 15 minutes, who can disable the feature? If the primary model provider becomes unavailable, does traffic move automatically to a model with different safety characteristics? Legal, security and operations teams may need notification, but a 12-person approval chain makes containment ineffective. Practising these scenarios through game days reveals missing telemetry and ambiguous authority before real users pay the price.

Roll Out Models Like Risky Infrastructure Changes

A model upgrade can alter thousands of behaviours without changing an application interface. Treating it as a routine dependency bump is therefore reckless. SRE-inspired release engineering starts with offline evaluation, then shadow traffic, internal use, a small canary and staged expansion. At each gate, teams compare the candidate against the current system using predefined measures. A release might begin with 1% of low-risk traffic, advance to 10% after 24 hours, and reach 50% only after enough samples establish that critical error rates have not worsened.

Shadowing is particularly valuable because it exposes a candidate to real inputs without allowing its outputs or actions to affect users. The technique has limits: it cannot fully test multi-turn interactions, user reactions or tool side effects. Canary releases fill that gap, but require cohort design. Sending the new model only to employees or expert users may hide problems that affect novices, non-native speakers or customers with long conversation histories. Randomisation, regional segmentation and risk-based exclusions should be documented rather than improvised.

Every rollout needs automated stop conditions and a tested rollback path. If citation validity drops by two percentage points, cost per resolved case rises by 25%, or p95 latency exceeds six seconds, expansion should halt. Rollback may be complicated by changed prompts, embeddings, caches or conversation state, so teams must test compatibility. The tradeoff is slower deployment, but staged exposure usually reduces total delivery time by preventing broad incidents and chaotic reversions.

Design Observability Around Decisions, Not Tokens

Infrastructure telemetry remains necessary: request rates, failures, latency, saturation and provider availability still matter. Yet AI observability must also capture whether the system made acceptable decisions. Teams need traces that connect user input, retrieved context, prompt and policy versions, model output, tool calls, validation results and final user-visible behaviour. Without that lineage, an apparently simple defect can become impossible to reproduce, especially when providers update models or sampling introduces variation.

Logging everything is neither affordable nor responsible. Full prompts may contain personal, commercially sensitive or regulated data, while token-level traces can generate enormous storage costs. A mature design uses redaction, access controls, retention limits and risk-based sampling. It may retain 100% of severe policy events, 10% of low-confidence transactions and 0.5% of routine successful interactions. Where raw content cannot be stored, structured features and privacy-preserving review workflows can still support diagnosis.

Dashboards should map to operational choices. An overall thumbs-up rate is rarely actionable because it blends product fit, model quality and user mood. Breakdowns by task, language, model version, retrieval source and customer segment are more revealing. Leading indicators also matter: rising retrieval misses or increased human overrides may predict a quality incident before complaints arrive. Observability earns its cost when it tells responders whether to roll back, degrade, escalate or continue.

Run Blameless Reviews That Produce Engineering Change

Blameless post-incident reviews are especially important in AI, where uncertainty encourages hindsight bias. If a model produced a harmful answer, the useful question is not who approved it, but why the system allowed that answer to reach the user. Perhaps the evaluation set lacked the relevant dialect, the safety classifier failed on long contexts, the alert measured only refusals, or commercial pressure overrode a depleted error budget. Individual decisions should be examined, but in the context of the information, incentives and controls available at the time.

A rigorous review reconstructs the timeline, quantifies impact, identifies contributing conditions and distinguishes detection from mitigation. It should state, for example, that 18,400 users were exposed over 47 minutes, 620 outputs were sampled, 31 contained unsupported claims and four led to incorrect account changes. Uncertainty must be explicit; false precision is another form of unreliability. Reviews should include near misses, because a blocked unsafe tool call can reveal a weakness before it causes harm.

Corrective actions need owners, deadlines and verification. “Improve monitoring” is not an action; “add a per-language groundedness alert with a two-times budget burn threshold by 15 September” is. The strongest actions change the system: permission boundaries, release gates, validation layers, dataset coverage and rollback automation. Training and documentation can help, but they are weaker than controls that make recurrence difficult.

Make Reliability a Product and Governance Discipline

SRE works when reliability is a shared constraint rather than an operations department’s clean-up duty. AI requires the same alignment. Product managers should define acceptable degradation; model engineers should expose uncertainty and limitations; platform teams should provide deployment and tracing controls; domain experts should set severity criteria; and executives should respect release pauses when budgets are exhausted. Otherwise, governance becomes a committee reviewing incidents after decisions have already been embedded in code.

Not every AI feature warrants identical machinery. A low-traffic copy assistant may use lightweight objectives, weekly sampling and manual rollback. An agent authorised to issue refunds or modify patient records needs stronger evaluation, separation of duties, real-time controls and rehearsed incident response. The governing principle is proportionality: operational investment should rise with scale, autonomy, irreversibility and harm. Reliability practices should enable justified experimentation, not eliminate it.

The most valuable lesson from SRE is cultural as much as technical: reliability is a measurable product feature purchased through explicit tradeoffs. Models will remain probabilistic, users will discover unanticipated behaviours, and suppliers will change beneath production systems. Service objectives, error budgets, runbooks, staged rollouts and blameless reviews do not remove that uncertainty. They make it governable—and turn AI operations from reactive firefighting into disciplined engineering.