devops

SLA, SLO, and SLI: Reliability Terms Explained for AI Product Teams

SLIs measure service performance, SLOs set internal targets for those metrics, and SLAs are external contractual commitments based on SLO performance.

SLAs, SLOs, and SLIs are the vocabulary of service reliability engineering. They provide a structured framework for defining, measuring, and committing to the quality of service that a product delivers to its users and customers. For AI SaaS products, these terms matter at two points: internally, when your engineering team needs a shared definition of what acceptable service looks like, and externally, when enterprise customers ask what your uptime and reliability guarantees are. Getting clarity on all three concepts is also a prerequisite for meaningful observability, because you need to know what you are trying to achieve before you can measure whether you are achieving it. UK enterprise procurement teams in financial services, NHS supply chains, and central government increasingly require formal SLA documentation as a supplier onboarding condition. At SpeedMVPs, a UK AI MVP agency in Hemel Hempstead building products in 2-3 weeks at GBP 8,000 with full client code ownership, reliability architecture is addressed in the initial build so clients are ready when enterprise conversations surface SLA requirements. The EU AI Act adds a further dimension: high-risk AI systems must be subject to post-market monitoring, which requires measuring system performance in terms that map directly onto SLI and SLO concepts. UK GDPR incident reporting benefits from a clear SLA framework, because a defined incident threshold makes it unambiguous when a reliability event requires ICO notification within 72 hours. This guide explains SLIs, SLOs, and SLAs with specific examples for AI product teams under UK and EU regulatory expectations.

SLI: What You Measure

A Service Level Indicator is a quantitative measurement of the quality of service provided by a system, expressed as a ratio or rate. The definition is specific: it is a real number between 0 and 1 (or expressed as a percentage) that represents the fraction of valid events that were good. Common SLIs include availability, the fraction of time the service was responding successfully; latency, the fraction of requests completing in under a defined threshold; error rate, the fraction of requests returning an error response; and correctness, the fraction of outputs meeting a defined quality standard. For AI products, additional SLIs are worth defining. LLM success rate, the fraction of LLM API calls returning a valid, non-error response, is an SLI that captures AI-specific reliability beyond infrastructure uptime. AI feature engagement rate, the fraction of users who successfully use an AI-powered feature within a session, captures whether the AI feature is actually working for users as a combined measure of reliability and quality. The key to defining good SLIs is user-centricity: an SLI should measure something the user directly experiences as service quality, not internal system metrics that may or may not correlate with user experience.

SLO: What You Target

A Service Level Objective is the target value for an SLI over a defined time window. An SLO is an internal commitment, not a customer-facing promise: it is the level of service reliability your engineering team is aiming for. Examples include 99.5% of requests should return a successful response over a 28-day rolling window, or 95% of requests should complete in under 2 seconds over a 7-day rolling window. SLOs are directional: they establish an explicit minimum acceptable quality level rather than aspirational perfection. The concept of an error budget follows directly from the SLO: if your availability SLO is 99.5%, your error budget is 0.5% of requests, which over 28 days represents approximately 3.5 hours of downtime equivalent. The error budget is the engineering team's spending limit for planned risk: deployments, experiments, and infrastructure changes that could cause failures spend error budget. When the error budget is depleted, the team focuses on reliability rather than new features until the budget recovers. For AI products, setting SLOs for LLM-specific SLIs alongside infrastructure SLIs gives the team clear targets for both availability and AI quality.

SLA: What You Promise

A Service Level Agreement is a contractual commitment to a customer specifying the level of service they will receive and the remedies available if that level is not met. SLAs are typically expressed as uptime guarantees: 99.9% uptime, or 99.5% uptime measured monthly. They include definitions of how uptime is measured, what constitutes a service incident, how incidents are reported and communicated, and the financial remedies such as service credits available if the SLA is breached. SLAs are typically set more conservatively than SLOs: if your SLO targets 99.5% availability, your SLA might commit to 99% to provide a buffer between your internal target and your contractual commitment. For AI SaaS products targeting enterprise customers in the UK, SLAs are often a procurement requirement. Enterprise buyers need to understand the reliability commitment before signing contracts, particularly for products integrated into business-critical workflows. Common enterprise SLA requirements include 99.5% or 99.9% monthly uptime, a maximum incident response time, and a defined root cause analysis delivery time for significant incidents.

AI-Specific SLIs and SLOs

Standard infrastructure SLIs and SLOs do not capture the full reliability picture for AI products. A product whose infrastructure is 99.9% available but whose LLM outputs are 20% hallucinated is failing its users in a way that availability SLOs do not detect. Define AI-specific SLIs that capture the user-relevant quality dimensions of your AI features. LLM API success rate captures technical reliability of the AI layer. Average user acceptance rate captures whether outputs are actually useful to users. Task completion rate for AI-assisted workflows captures whether the AI feature enables users to accomplish their goals. Output safety rate, the fraction of outputs that do not trigger your safety filters or user reports, captures responsible AI performance. Set SLOs for these AI-specific SLIs alongside your infrastructure SLOs. Internal team conversations about whether the product is meeting its reliability targets should include AI quality SLIs, not just server uptime. For customer-facing SLAs, keep AI quality commitments out of formal SLAs until you have enough production data to set credible, measurable targets that you can reliably maintain.

Error Budgets in Practice

Error budgets convert SLO targets into a practical engineering resource for managing reliability risk. If your availability SLO is 99.5% over 30 days, your error budget is 0.5% of total requests, representing approximately 3.6 hours of complete downtime or a proportional amount of partial degradation. Engineering teams can spend error budget on planned maintenance, risky deployments, infrastructure experiments, and capacity testing. When the error budget is consumed early in the period, the team shifts focus from feature development to reliability improvement until the budget resets. This mechanism creates a feedback loop between engineering decisions and reliability outcomes that makes the abstract concept of reliability targets concrete and actionable. For AI products, consider defining separate error budgets for infrastructure reliability and AI quality reliability. The infrastructure error budget governs deployment and maintenance risk. The AI quality error budget governs model changes, prompt template updates, and AI feature experiments, allowing the team to take measured quality risks while maintaining a minimum quality floor.

Setting SLOs for a New AI Product

Setting SLOs for a new product requires balancing ambition with achievability and prioritising user impact over impressive-sounding numbers. A common mistake is setting a 99.99% availability SLO (52 minutes of downtime per year) before understanding what your actual infrastructure can reliably deliver or whether users even need that level of availability. Start with data: once you have been in production for 30-60 days, look at your actual availability and latency percentiles. Your SLO should be achievable given your current infrastructure and team capacity. For the initial SLO, choose a target that represents genuinely good service rather than perfect service, with enough error budget to allow normal engineering operations including deployments and occasional incidents. For AI SaaS products, a starting point of 99.5% monthly availability, 95% of requests completing in under 3 seconds, and 99% of LLM API calls returning a valid response is defensible and achievable. Tighten the targets as your reliability practice matures and as enterprise customer requirements make specific targets commercially necessary.

Frequently Asked Questions

Do we need to define SLAs for early-stage AI products?+

Not for consumer products or early pilots, but yes for enterprise B2B products once you are signing contracts with procurement teams. Enterprise buyers expect SLAs as part of the supplier agreement. If you do not have defined SLAs, you will be asked for them. Start with a modest availability SLA, such as 99.5% monthly uptime, that you are confident you can meet. Include clear definitions of how uptime is measured, exclusions for scheduled maintenance, and service credit terms. Avoid aspirational SLAs that your infrastructure cannot reliably support.

What is a reasonable uptime SLA for an AI SaaS product?+

99.5% monthly uptime (3.6 hours downtime per month) is a reasonable starting commitment for most AI SaaS products. 99.9% (43 minutes per month) is achievable with redundant infrastructure but requires multi-availability-zone deployment and automated failover. 99.99% (4 minutes per month) requires significant engineering investment in redundancy, automated recovery, and change management process and is not appropriate for early-stage products. Choose a target you can reliably meet with your current infrastructure rather than a number that requires infrastructure investment you have not yet made.

How do we measure availability for an AI product with LLM latency?+

Availability for an AI product should be measured at the user request level: what fraction of requests received a successful response within an acceptable timeout? This should exclude requests that succeeded at the infrastructure level but failed at the LLM level, such as LLM API errors passed through to users as error responses. Define your availability metric clearly in your SLA, including what response codes and latency thresholds count as a successful response, to avoid disputes about whether a period of LLM provider degradation constitutes a service availability incident.

What remedies should an AI SaaS SLA include?+

Standard SaaS SLA remedies are service credits proportional to the breach severity. Common tiers are 10% monthly fee credit for availability between 99.0% and 99.5%, 25% credit for availability between 95% and 99.0%, and 50% credit for availability below 95%. Credits are typically applied to the next invoice rather than paid in cash. Caps on total credits per month (often 50% of monthly fees) are standard. The SLA should also specify that credits are the sole remedy for availability breaches, excluding consequential damages, which is important for protecting against disproportionate liability claims.

How does the EU AI Act affect SLAs for AI products?+

The EU AI Act introduces obligations for high-risk AI systems that effectively create new reliability and transparency requirements beyond standard SLA terms. For high-risk AI systems, providers must implement logging sufficient to enable post-market monitoring and incident investigation, notify the relevant national authority of serious incidents within defined timeframes, and maintain a quality management system. These obligations effectively extend SLA-like requirements into regulatory compliance. For enterprise customers in the EU buying high-risk AI systems, expect procurement to ask about your incident notification procedures and post-market monitoring practices alongside traditional uptime SLA terms.

Building an AI product that needs to meet enterprise SLA requirements? We help you architect for the reliability targets your customers need. Get a free consultation at speedmvps.co.uk

Get a Free Quote