What an AI Product SLA Should Actually Promise
An uptime SLA does not cover the risk an enterprise buyer actually fears. Here is what an AI product SLA should promise: behavior bounds, not just availability.
A standard SLA promises the wrong thing. It guarantees the service is up 99.9 percent of the time, which tells an enterprise buyer nothing about the risk they are actually losing sleep over. Their fear is not that your AI product goes down. Their fear is that it stays up and does something wrong: gives a confident wrong answer, takes an action it should not have, or exposes data it should not have touched. An uptime number does not address any of that.
An AI product SLA should promise behavior bounds, not just availability. It should commit, in the contract, to what the system will and will not do, and what happens when it fails. Here is what belongs in one.
Availability is table stakes, not the promise
Start with the standard availability commitment because the buyer expects it, but understand it is the floor, not the value. Uptime, latency, support response times: fill those in with real numbers you can hit. Then keep going, because for an AI product the interesting failures happen while the system is fully available.
The reason uptime feels hollow to a serious buyer is that a hallucinating model has 100 percent uptime. It is up. It is answering. It is just wrong. If your SLA stops at availability, you have promised to keep the risk running.
Promise behavior bounds the buyer can hold you to
The part that matters is a commitment to how the system behaves. This is the hard part to write, which is exactly why it is worth writing, because almost no vendor does.
Bound the actions. Commit that the system will not take defined high-stakes actions (moving money, deleting records, sending external communications) without a human approving. That is not a feature description, it is a contractual guarantee, and it is the sentence a risk owner underlines. Bound the data. Commit that customer data is not used for training and does not leave the defined boundary. Bound the accuracy where you honestly can, on a defined task, measured a defined way, with the remedy stated if you miss.
These are the promises that map to the buyer's real fear. A system whose dangerous actions are blocked by construction lets a compliance team approve it, which is why I build the guardrails into the product rather than promise them in a slide. The SLA just puts the guarantee in writing.
Define what happens when it is wrong
No serious buyer believes your system is never wrong, so an SLA that implies perfection reads as dishonest. The credible move is to assume failure and define the response.
State the detection: how you notice the system misbehaved. State the containment: what stops a bad output from becoming a bad outcome, usually the human in the loop on consequential actions. State the notification: how fast you tell the customer when something material happened, in hours. State the remediation: what you do to fix it and what the customer is owed. An SLA that handles failure honestly is more reassuring than one that pretends failure is impossible, the same way showing how agents recover from failure beats claiming they never fail.
Make every clause defensible
Do not write a clause you cannot honor. A missed SLA commitment is worse than a modest one, because it triggers the exact loss of trust the SLA was supposed to prevent, and now it is contractual. If you cannot guarantee an accuracy threshold honestly, do not put a number on it; bound the behavior instead, which you can control.
The discipline here is the same one that governs every claim I make about an AI product. Underpromise against what you can defend, then honor it exactly. A buyer who finds your SLA was conservative trusts the whole relationship. A buyer who catches you missing a clause you oversold stops trusting all of it. This is claims discipline written into the contract.
The SLA is an assurance document
Reframe what the SLA is for. It is not legal boilerplate to get past. It is the place where your assurance story becomes a binding commitment, and a well-written one closes deals that a demo cannot. When a risk owner reads bounded actions, bounded data, and honest failure handling in your contract, you have handed them the thing they need to say yes.
That is how I write enterprise commitments across the portfolio, from Agency Script to CaseSolo. Promise the behavior, not just the uptime. The behavior is what they are buying.