Your AI agent has been handling quote requests for three months. One Monday morning it returns empty answers. You open the contract: it describes a scope, a price, a term. Nothing about how long it takes to get back online, nothing about who picks up the phone at 8:30. An SLA (service level agreement) exists precisely to fill that hole. It still has to be written for an AI agent, not copied from a web hosting contract.
Key Takeaways
- An AI agent runs on three layers (infrastructure, model, integration). An uptime figure published for one layer does not protect the whole.
- Demand quantified response times by severity level, with the covered hours and the start of the clock.
- Service credits cap the remedy: at a hyperscaler they are limited to a percentage of the monthly bill and stand as the only contractual recourse.
- The SLA must state who responds when the model provider goes down, and how fast the vendor alerts you to an incident.
- Two clauses matter as much as the response times: incident notification and exit (prompts, logs, data).
A hosting SLA does not protect an agent
A website is either up or down. An AI agent can answer every request and still say the wrong thing. That difference changes the nature of the commitments you need.
Three layers stack up inside an agent in production:
- The infrastructure running the service (server, container, database).
- The model the agent calls, usually through a third-party API.
- The integration connecting the model to your tools: messaging, CRM, knowledge base, and the prompt that frames the behaviour.
A contract promising 99.9% uptime nearly always refers to the first layer. The other two were already failing, and nobody promised anything. A deprecated model version, a hit rate limit, a connector returning a silent error: the agent is up, it just stopped working.
The practical consequence is simple. Before negotiating a number, get in writing what is measured, on which layer, and from whose point of view.
What the uptime percentage hides
Figures published by large providers give a useful order of magnitude. In its service level agreement for Compute Engine, Google Cloud (SLA accessed 13 November 2026) sets "a single instance of all other families" at 99.9% and "instances in multiple zones" at 99.99%.
The gap looks small. It is not. Over a 30-day month, that is 43,200 minutes:
- 99.99% allows roughly 4 minutes of downtime.
- 99.9% allows roughly 43 minutes.
- 99.5% allows roughly 3 hours 36.
Moving from 99.9 to 99.5 multiplies the tolerated downtime by five, without the contract changing name. An SLA without a calculation method is a slogan.
Four questions settle this:
- Which period? Calendar month, quarter, rolling year. An annual calculation wipes out three bad months.
- Which scope? The whole service, one API route, one business journey.
- Measured by whom? The vendor alone, with internal probes, or a third party with an external measurement point.
- Which exclusions? Planned maintenance, force majeure, model provider outage, errors on your side. The exclusion list is often longer than the commitment.
Response and resolution times by severity
An uptime percentage does not tell you what to do when the outage happens. You need a grid with two distinct clocks: response (a qualified person is looking) and resolution (the service works again). Confusing the two is the most common trap, because a vendor can respond in ten minutes and restore service in three days.
Here is the kind of grid to put in the contract. The values are negotiable depending on how critical the process is; these ones are an illustration, not a market standard.
| Level | Example for an agent | Response | Target resolution | Follow-up |
|---|---|---|---|---|
| P1 | Agent unreachable, process blocked | 1 business hour | 4 business hours | Update every 2 hours |
| P2 | One major intent no longer works | 4 business hours | 1 business day | Daily update |
| P3 | Limited impact, workaround available | 1 business day | 5 business days | Ticket |
| P4 | Change request, prompt adjustment | 5 business days | Per schedule | Ticket |
Three points to get in writing:
- Covered hours. 24/7, business days from 9am to 6pm, or paid on-call as an option. An agent answering customers on Saturday needs Saturday coverage.
- When the clock starts. On detection by the vendor, or on your report. The second is more favourable, and it forces the vendor to instrument monitoring.
- The reporting channel. A generic support address is not an incident channel. Ask for a phone number and a named contact for P1s.
What "restore" means for an agent
On a server, restoring means the service responds. On an agent, it can mean four different things: the service responds, it responds correctly, it responds correctly on critical cases, or the root cause is fixed.
Ask for the distinction between workaround and permanent fix, with a deadline for each. A workaround may consist in disabling one of the agent's skills, which restores service and degrades the result. You want to know that beforehand, not during the incident.
Add a change control clause. An agent evolves in small touches: an adjusted prompt, an updated model, a modified connector. Without a procedure, the very change that fixes one case can break twenty others, and responsibility becomes impossible to establish. A non-regression test suite, run before every change, turns that clause into a verifiable commitment.
When the model provider goes down
Your vendor almost never owns the model. It rents API access. An outage, a price increase or a version deprecation at that provider hits your agent without any fault from your vendor.
ANSSI's guide on security recommendations for a generative AI system (ANSSI, 29 April 2024) covers this by addressing the whole lifecycle, from training to production, including third-party AI tools. The contractual logic follows: you cannot promise what you do not control, but you can promise a reaction.
Three commitments to ask for:
- Failover. Is there a backup model, tested, with a stated switchover time? If not, put that in the contract rather than discovering it live.
- Notice. How long before a model version is deprecated does the vendor warn you, and who bears the cost of adaptation?
- Visibility on dependencies. The list of subcontractors and model providers, kept current. Your legal counsel and your DPO will ask for it too.
Service credits are not insurance
Most SLAs provide credits: if the level is missed, the customer receives a rebate on the invoice. The Google Cloud scale is explicit: credits range from 10% to 100% of the monthly bill for the covered service depending on the severity of the drop. The contract adds that these credits are the customer's only recourse for a failure to meet the objective, "Customer's sole and exclusive remedy".
In other words, a full month of downtime ends with a rebate, not with compensation for the revenue you lost. For an agent handling inbound requests, that ceiling is very low.
Three countermeasures, to be weighed with your legal counsel:
- A credit proportional to the service delivered. A rebate on the subscription is thin if the agent is the only order-taking channel.
- A continuity clause. Documented recovery plan, backup restoration time, annual tests.
- A separately negotiated penalty for P1 incidents, capped, with an agreed procedure for establishing the facts.
A serious vendor will discuss these points. A vendor refusing any quantified time commitment is mainly telling you it has no on-call rotation.
Incident notification, a link in your compliance chain
If the agent processes personal data, the incident also becomes a regulatory matter for you. The CNIL reminds organisations to set up procedures to detect a breach, contain it, assess the risks and decide whether to notify, under articles 33 and 34 of the GDPR (CNIL). The notification deadline starts when you become aware of the breach. Every hour the vendor takes to alert you is an hour spent from your own budget.
So ask for:
- an incident notification time in hours, not business days;
- a named, reachable contact, and a procedure if that person is away;
- a written post-incident report within a few days: cause, scope of affected data, measures taken;
- log retention long enough to reconstruct the incident.
Exit, the most neglected clause
An SLA is only worth something if you can leave. Ask what you get back, in which format and within what time: prompts and system instructions, test sets, execution logs, connector documentation, conversation history relevant to an audit. Also state who owns these items, and how long the vendor must keep your data after the contract ends. On that ground, reversibility for an AI agent deserves to be treated as a deliverable, with a date.
The maintenance contract answers a different question, the recurring effort: what is included, what is billed, how often the agent is re-evaluated. The two documents complement each other, and what a maintenance contract should cover details that side.
What no SLA will settle
Three topics stay outside, and you should know that before signing.
Answer quality. No uptime percentage tells you whether the agent answers correctly. That is handled by an evaluation protocol: sample of real cases, human review, acceptance threshold, frequency. Ask for it as an annex, not as a promise.
Security. The SLA talks about availability, rarely about security. The expected measures (isolation, access control, logging, secret management) belong in the contract and the security annex. The ANSSI guide cited above provides a useful framework for the review.
Scale. An agent handling 50 conversations a day can saturate at 500. Ask for model API quotas, what happens during a peak, and the marginal cost. An agent whose cost per request doubles in high season gets switched off quickly.
Questions to ask before signing
- Which layers does the uptime commitment cover, and with what calculation method?
- What are the response and resolution times for a P1, in business hours or 24/7?
- Who measures downtime, with which probes, and can you access the reports?
- What happens if the model provider changes its pricing or deprecates a version?
- What is the notification time for a security incident, and who calls whom?
- What do you get back on exit, in which format and within what time?
- Are service credits the only remedy, and do they cover the service delivered or only the subscription?
These answers fit in two pages of annex. A vendor that provides them before signature saves you weeks. To gauge the level of rigour to expect from a partner, the questions to ask an AI agency complete this list on the project side.
FAQ
Is an SLA mandatory for an AI agent?
No. In France, nothing imposes a service level agreement, and contractual freedom applies. The obligation shifts: if the agent feeds a critical process, the absence of written times becomes a risk you carry alone, with no identifiable recourse when it fails.
What uptime level should you ask for an internal agent?
It depends on the use. An assistant helping draft notes tolerates a few hours of downtime. An agent receiving inbound requests or triggering quotes needs broad coverage and a short restoration time. The number matters less than consistency between the promised level, the covered hours and the continuity plan.
Are service credits enough as compensation?
Rarely. A credit applies to the service invoice, while the damage often sits on the revenue side or in internal workload. For a critical use, add a tested continuity plan and, if you have the leverage, a negotiated penalty.
What if the vendor refuses any quantified time commitment?
Ask for at least three things: a named on-call for blocking incidents, an incident notification time, and a post-incident report. If nothing is possible, reduce the dependency: have the agent documented, keep control of the prompts, and plan a fallback. A technical audit before signing often clarifies that decision, and our audit page describes this kind of engagement.
Conclusion
A useful SLA does not promise the impossible. It describes who reacts, in how long, on which layer, and what you get back if the relationship ends. For an AI agent, that description must cover the model and the integration, not only the server hosting them.
The right sequence has three steps. First write the service level your processes need, not the one in the vendor's catalogue. Then get the times and exclusions quantified. Finally, test the contract for real: simulate an outage and see who calls.
NexeAI designs and maintains AI agents for small and mid-sized companies, with service commitments written into the project: our AI agents and our automation offering start from the process to be held, not from a package. If you need to frame these clauses on a live project, write to us through the contact page.
