How to Write an SLA for an AI Product

An AI product SLA needs three things a normal SaaS SLA does not: an honest carve-out for your upstream model provider's uptime, a separate latency commitment for the model's own response time versus your support response time, and a clause covering what happens when the underlying model changes or degrades. Below is a clause-by-clause structure with illustrative example numbers you can adapt, reasoned from how most AI-wrapper products are actually built, not a generic legal template with no logic behind it.

This is not legal advice. Treat every number here as a starting point to adjust for your own infrastructure and risk tolerance, and have a lawyer review whatever you send a paying customer.

Why a normal SaaS SLA template doesn't fit an AI product

Most SLA templates floating around online were written for products where the vendor controls the whole stack: you own the servers, you own the code, and 99.9% uptime is a promise you can keep because nothing between you and the database belongs to someone else.

An AI product usually isn't like that. If you're calling OpenAI, Anthropic, or any other model provider's API, your uptime is capped by theirs, and their status page updates on their schedule, not yours. Copy-pasting a generic SaaS SLA either sets you up to owe credits you can't afford, or it quietly overpromises something you don't control. The fix isn't to skip the SLA, it's to write one that tells the truth about where your control ends.

What belongs in an AI product SLA that a normal SaaS SLA skips

Four things, specifically:

• Upstream dependency disclosure: a clear statement that your uptime commitment excludes outages caused by your model provider, and what counts as evidence of one.

• Two separate response-time clauses: one for how fast a human replies to a support ticket, one for how fast the AI itself responds to a request, because customers conflate these and you shouldn't let them.

• Model-change risk: what you owe the customer if the provider deprecates, updates, or silently changes the behavior of the model you're built on, since output quality can shift without any code change on your end.

• Data handling during degraded service: what happens to in-flight requests and stored data if you have to fail over to a backup model or provider.

Clause 1: uptime commitment, with the upstream carve-out

Start with the number, then immediately scope what it covers. A workable structure for a small AI product:

Illustrative example: commit to 99.5% monthly uptime for your own application layer (the parts you control: your API gateway, your auth, your dashboard, your queueing). Explicitly exclude downtime caused by your upstream model provider, your cloud host, or any third-party dependency you don't operate, and define how you'll evidence an upstream outage, typically by linking the provider's own public status page incident.

99.5% is a starting point, not a standard. A two-person team on a single region with no failover will break that promise the first time the model provider has a bad day. A team with retry logic and a fallback model can reasonably push toward 99.9% for its own layer. Reason backward from what your infrastructure can survive, not from what sounds impressive in a sales deck. The number is also only as good as the provider underneath it, so if you haven't checked your upstream provider's own reliability track record before picking a figure, that's worth doing first, covered in how to vet an AI vendor before you hand over data.

Write the exclusion in plain terms, something close to:

"Uptime" means the percentage of time the Service is available for use during a calendar month, excluding: (a) scheduled maintenance announced at least 24 hours in advance, (b) outages caused by the underlying AI model provider(s) we integrate with, as evidenced by their published status page, (c) force majeure events, and (d) issues caused by Customer's own systems or misuse of the API.

Clause 2: response time, split into two separate commitments

This is the clause most first-time SLA writers merge into one number, and it's the wrong move. A support reply and a model's answer are two different systems with two different failure modes, and bundling them means one bad actor drags down a metric the other side of your team doesn't control.

Support response time

How fast a human acknowledges a ticket. Illustrative example: first response within 4 business hours for standard requests, 1 hour for outage-severity issues, defined against your stated business hours and time zone. Tie the tiers to severity, not to the customer's plan size, so the clause reads as fair rather than as a upsell lever.

AI response latency

How fast the model itself returns an answer under normal load. Illustrative example: median response under 3 seconds and 95th percentile under 8 seconds for a standard request, measured server-side from request receipt to first token or full response, whichever matches how your product streams.

Set this number from your own logs, not a guess. Pull your last 30 days of response times, take the p50 and p95, and commit to something a little looser than what you're already hitting, so a slow week from your model provider doesn't put you in breach on day one.

Clause 3: model-change risk, the clause a generic SaaS SLA has no reason to include

This one is genuinely specific to AI products. A normal software vendor doesn't wake up to find their database engine silently changed its behavior. You might. Model providers deprecate versions, roll out updates that change tone or accuracy, and sometimes adjust behavior without a version bump at all. Cover three scenarios explicitly:

1. Planned deprecation: commit to notifying customers within a stated window, illustrative example 30 days, of any known upstream deprecation that will force a model change on your end, and to testing the replacement before the cutover where your provider's timeline allows it.

2. Unannounced behavior drift: state that you monitor output quality on a routine basis and will investigate customer-reported regressions within a stated window, illustrative example 5 business days, since you can't promise to prevent drift you don't control, only to respond to it.

3. Provider-side outage or shutdown: state your fallback plan if a provider is unavailable for an extended period, whether that's a secondary model provider, a degraded-mode fallback, or a defined communication plan if no fallback exists yet.

Customers who ask for an SLA are usually testing whether you've thought about failure modes, not just whether you'll sign a number. A clause that names the real risk reads as more credible than one that pretends it doesn't exist.

Clause 4: remedies, kept proportional to what you can absorb

Service credits, not cash refunds, are the standard remedy and for good reason: they keep the customer's incentive aligned with staying rather than leaving, and they cap your downside to revenue you haven't collected yet rather than cash you have to pay out.

Illustrative example structure: 10% of the monthly fee credited for uptime between 99.0% and 99.5%, 25% for uptime below 99.0%, capped at 100% of that month's fee. Require the customer to request the credit in writing within a stated window, illustrative example 30 days of the incident, so you're not fielding claims for outages from two quarters ago.

Clause 5: what's explicitly out of scope

State plainly what the SLA does not cover: accuracy or correctness of AI-generated output, third-party integrations you don't operate, customer-side misconfiguration, and beta or preview features. This is the same discipline as the uptime carve-out: say clearly where your responsibility ends so the parts you did commit to carry weight.

Putting it together: where this fits in the rest of your paperwork

An SLA rarely stands alone. If you're still figuring out how a deal like this gets scoped and signed in the first place, how to write an AI project proposal that gets signed covers the document that usually comes before it, and negotiating a contract with an AI vendor is useful if you're on the buying side of a similar conversation.

Ongoing support expectations belong in a separate maintenance and support contract, and how you charge for variable model costs affects what uptime and credit numbers you can safely commit to, covered in how to price an AI product with variable costs. Zooming out, how much structure a deal needs in the first place traces back to how you're charging for the product, the wider decision covered in AI monetization strategies.

FAQ

Do I need an SLA if I'm a solo founder or small team?

Only if a customer asks for one, or if you're selling to a business that will require it before signing a contract, which is common once a deal moves past self-serve pricing. A written SLA is a commitment with teeth, and a small team should commit only to numbers it can actually hold under a bad week.

What uptime guarantee is realistic for an AI SaaS running on a single model provider?

There's no universal answer, it depends on your own infrastructure's reliability, not just the model provider's. A reasonable starting point is to promise a slightly lower number for your application layer than the provider publishes for their own API, since your stack adds its own points of failure on top of theirs, and to exclude their downtime from your count entirely.

What happens if the AI model I'm built on gets deprecated?

Your SLA should state a notice window for planned deprecations and a testing commitment before you cut over to a replacement model. This is exactly the model-change clause covered above, and it's worth writing even if you think it will never happen, because model providers deprecate versions on a regular cycle.

Should support response time and AI response latency be the same clause?

No. They measure different systems and fail for different reasons. Keeping them separate means a slow model provider doesn't put your support team in breach, and a busy support week doesn't get blamed on your infrastructure.

Can I offer refunds instead of service credits?

You can, but most SaaS and AI-product SLAs use credits because they cap your downside to unearned revenue rather than cash already collected, and they keep the customer's incentive pointed at staying rather than leaving. Whichever you choose, cap it and require a written claim within a defined window.