What is a service level agreement (SLA)?

An SLA has three parts, and all three are required. A metric that can be measured without dispute. A threshold that states the committed level of that metric. A remedy—credit, refund, escalation, or termination right—that applies when the threshold is missed. A stated target without a remedy is an aspiration; a remedy without an agreed measurement method is unenforceable.

Three terms are routinely mixed up. An SLI is an indicator—the raw measurement, such as uptime percentage or median response time. An SLO is an objective a team sets for itself internally, with no external consequence. An SLA is the contractual version: an objective promised to a customer with a remedy attached. A support policy describes how a vendor responds to requests and commits to nothing measurable, which is why it is not an SLA even when it names response times.

The distinguishing feature of an SLA is risk transfer. The vendor, not the customer, absorbs the cost of underperformance within the agreed bounds, which makes an SLA a commercial instrument rather than a technical document.

For AI systems the useful metrics differ from traditional software. Availability alone does not describe quality: an agent that is reachable but wrong satisfies an uptime commitment while producing the error the buyer wanted to avoid. Accuracy or error rate, time to correct a wrong output, and who is accountable for downstream effects are the metrics that make an AI SLA meaningful.

SLAs are also the mechanism outcome-based pricing relies on. When a vendor charges for a result rather than for seats, the metric, threshold, and remedy in the SLA are what define and enforce that result; without them the buyer is paying against a number the vendor both produces and reports.