Service Level Agreements: What to Put in One

Most service level agreements are thorough about availability and silent about everything that actually goes wrong. The service stayed up and started answering differently. The feature you built a process around was retired with two weeks of notice. Nobody breached the uptime clause in either case, and both cost you more than an outage would have.

The three standard parts

Availability, stated as a percentage over a measurement period. Response and resolution times, usually tiered by how severe the problem is. And a remedy when a target is missed, which in practice is almost always a service credit.

Read the measurement period rather than the percentage. The same 99.9% means something different measured monthly than measured annually, because a single bad day can be absorbed by a yearly figure and will breach a monthly one. Vendors know this and it is rarely the number on the marketing page.

Read the definition of downtime too. Scheduled maintenance is usually excluded, sometimes with generous limits on how much of it there can be, and a service that is technically responding while returning errors may not count as down at all.

What a service credit is worth

A credit refunds part of what you paid for the period in which the target was missed. It is not compensation for your losses and it is not intended to be.

On a subscription of a few hundred dollars a month, a breach might return a double-digit sum against a day of disruption that cost you considerably more. Most credits also have to be claimed within a short window and are not applied automatically, which means a large share are never collected.

Which is the honest way to read uptime clauses: as a signal of how seriously a vendor takes reliability, and as something to check is being measured, rather than as financial protection you can plan around.

The clauses AI services need

Clause	What it protects against	What to ask for
Model change notice	Same prompt, different behaviour, no warning	Advance notice, and a pinned version
Deprecation window	A version you depend on disappearing	A stated minimum period in writing
Rate limits and throttling	Working fine until your busy week	The actual numbers, not fair use
Output quality measure	Available but no longer useful	An agreed metric where one exists
Data handling on exit	Leaving costs more than staying	Export format and a window

Model change notice is the one with no equivalent in traditional software contracts. Conventional applications behave the same way until someone ships an update you can see in a release note; a model can be swapped underneath an unchanged API and your prompt starts producing different output, which looks to you like your own system breaking.

Output quality is the hardest to write and worth attempting where the task is measurable. A classification accuracy threshold on your own test set is enforceable in a way that better results is not, and even an informal agreement to re-test against an agreed sample after a model change is more than most businesses have.

What you can realistically negotiate

On a self-serve plan with a checkbox, nothing. The moment there is an order form and a salesperson, something becomes possible, and that threshold is often lower than businesses assume.

Notice periods and support response times move most readily, because they cost the vendor process rather than money. Uptime percentages and liability caps rarely move, since those are set centrally and apply across the customer base.

Where the relationship runs through a cloud marketplace rather than direct, your leverage usually sits with the cloud agreement rather than with the model provider, which is a useful thing to establish before you start asking. The wider vendor questions are in how to vet AI vendor claims and usage limits.

The SLA you give your own customers

If you promise customers a turnaround and deliver it using a service that promises you nothing, you have taken on a risk you have not priced. That is survivable and it should be deliberate.

Two practical guards. Promise a figure most of your work comfortably beats rather than your average, which is the argument in why faster work did not shorten your lead time. And know what you do during a day-long outage of your main provider, even if the answer is that work pauses and customers get told early.

When there is no SLA at all

Plenty of useful AI tools make no commitments whatsoever. The right response is to treat the absence as information rather than to avoid the tool.

Know how to get your data out and how long that takes. Avoid making a customer-facing commitment that depends on it. And read the terms for what the provider has reserved the right to do, which is a different document from the SLA and frequently the more consequential one, as covered in what to check in AI terms of service. Where an incident does happen, the questions to put to the vendor are in what to ask your AI vendor after an incident.

Frequently Asked Questions

What should a service level agreement actually cover?

Availability, response and resolution times by severity, and what happens when the target is missed. Those three are standard. What most SLAs omit, and what tends to cause the real disputes, is how the service is allowed to change underneath you: notice before a feature is removed, notice before behaviour changes, and what you are entitled to if a change breaks your workflow.

Is an uptime guarantee worth much?

Less than its prominence suggests. Three nines of availability permits roughly nine hours of downtime a year, and a provider that misses it typically owes you a service credit worth a fraction of one month’s fee. The credit is not compensation for your loss, it is a refund of a portion of what you paid. Treat uptime clauses as a signal of how seriously a vendor takes reliability rather than as financial protection.

What belongs in an SLA for an AI-powered service?

Three clauses beyond the usual. Notice before the underlying model changes, since the same prompt can behave differently afterwards. A deprecation window with a stated minimum, so a model version you depend on cannot vanish at short notice. And where output quality is measurable for your use, an agreed way of measuring it, because availability tells you the service responded and nothing about whether the answer was usable.

Can a small business negotiate an SLA?

On a standard self-serve plan, usually not, and that is worth knowing rather than fighting. Negotiation becomes realistic at the point you sign an order form rather than click a checkbox, which is often a lower threshold than people assume. The clauses most likely to move are notice periods and support response times; uptime percentages and liability caps rarely move at all.

What should we do if there is no SLA on offer?

Treat the absence as information and plan around it rather than assuming good behaviour. Decide in advance what you would do during a day-long outage, know whether your data can be exported and how quickly, and avoid building a customer-facing commitment on top of a service that makes you none. An unpromised service can still be a good choice; it should not be a load-bearing one without a fallback.