What should an AI service level agreement actually promise?

You are on a customer call. Your API endpoint is up. The dashboard loads. Yet the buyer is unhappy because their AI workflow is producing unreliable answers after a model update or retrieval issue. If your contract only promises "99.9% uptime," you have not answered the customer's real question: what happens when the service is technically available but commercially unusable?

That is the core problem with many AI service level negotiations. An undifferentiated uptime number can be useful for infrastructure performance, but it does not cover human support responsiveness, incident communication, or the quality and stability of model outputs. In AI products, those are different promises, measured in different ways, by different teams, with different evidence and often different remedies.

A practical AI service level agreement should therefore separate at least three lanes: service availability and latency; human support response and incident communication; and model-output quality and change management. For each lane, decide whether you will promise a metric at all, who owns the measurement, what records prove compliance, and what remedy applies if the commitment is missed. That is a contract-design choice, not a single rule imposed by US law across every deal.

This article is general information, not legal advice. It is written for a US AI SaaS founder or commercial lead negotiating customer promises, not for someone looking for a generic software template.

Where the SLA sits in the contract set

Before debating percentages and credits, decide where the service-level terms live. In many deals, the SLA is not a standalone contract. It is a schedule or section attached to the main customer agreement, which carries the broader commercial terms on fees, IP, confidentiality, data rights, limitations of liability, termination and dispute mechanics.

If you need the broader contract first, Sprintlaw's page on a Service Agreement explains the wider framework, while its page on a Master Services Agreement is relevant where you expect repeat orders, statements of work or enterprise procurement layering. For many AI companies, the cleanest structure is a main customer agreement plus an SLA schedule, with separate order forms or statements of work for implementation, fine-tuning, data-labeling support or other project work.

That document split matters because AI products often combine several services at once:

• a hosted application or API;
• human support and incident handling;
• configuration or prompt-design help;
• integrations into customer systems;
• model updates or retraining work; and
• third-party components such as cloud hosting, foundation models or vector databases.

If all of those activities are collapsed into one loose "service level" promise, disputes become more likely. A customer may think they bought response guarantees for prompt tuning or quality regression review, while your team only intended to promise infrastructure uptime.

Also review any proposed service-credit language in the context of the full contract and the governing state law. Some providers want SLA credits to be the customer's exclusive remedy for a missed metric. Sometimes that position is accepted; sometimes it is negotiated; sometimes it creates tension with termination rights, indemnities, or other remedies elsewhere in the contract. Whether "exclusive remedy" wording will work as intended is not something to assume automatically from a template label. It needs full-contract and state-law review.

Build the SLA in three separate lanes

The fastest way to improve an AI SLA is to stop treating every performance issue as an uptime issue. These three lanes should usually be handled separately.

Lane 1: Service availability and latency

This lane covers whether the platform can be reached and whether it performs within the agreed operational envelope. Typical topics include API availability, application availability, request success rates, latency, scheduled maintenance and degraded performance caused by capacity constraints.

• Possible metric: monthly availability, success-rate percentage, or response-time percentile for a defined endpoint or service component.
• Measurement owner: usually engineering, SRE or infrastructure operations.
• Evidence: system monitoring, ingress logs, synthetic monitoring, incident reports and maintenance notices.
• Typical remedy: service credits tied to the affected subscription component, or sometimes only incident escalation and reporting if the commitment is informational rather than credit-bearing.

The drafting work here is definitional. What exactly is "available"? Is a request counted as available if the gateway answers but downstream retrieval times out? Are admin features measured separately from inference endpoints? Is latency measured at the provider edge, inside the customer environment, or end to end? If you do not define the measured service carefully, a clean-looking number can hide a messy operational argument.

Lane 2: Human support response and incident communication

This lane covers what the customer can expect from people, not machines: ticket acknowledgment, escalation, status updates and communication during incidents. Many AI businesses under-draft this area and then discover that enterprise customers care as much about speed of human response as about raw platform uptime.

• Possible metric: initial response time by severity level and support window, plus an update cadence for major incidents.
• Measurement owner: support operations, incident management or customer success, with engineering involved after triage.
• Evidence: ticket timestamps, paging records, status-page messages, incident channels and escalation logs.
• Typical remedy: often an escalation path or premium-support credit rather than the same credit formula used for infrastructure outages.

This is where support-hours discipline matters. A business-hours support promise is very different from a true 24/7 response promise. Severity definitions matter too. A complete production outage affecting all users is not the same as a cosmetic dashboard bug, and it should not carry the same response target.

Customers also want clarity on communications. Who sends updates? How often? Does the clock stop if the provider is waiting on customer information? If a third-party dependency is failing, will you still provide updates even if you do not control the upstream fix? Those operational details often matter more than another decimal place on an availability percentage.

Lane 3: Model-output quality and change management

This is the lane that makes AI different. A model can be online, fast and fully reachable while still generating unreliable, stale or commercially unsafe outputs. Output quality may turn on prompt structure, retrieval quality, customer data hygiene, model version changes, threshold tuning, guardrails, human review, or domain-specific evaluation criteria.

• Possible metric: sometimes a defined benchmark score on an agreed test set, a regression threshold after changes, or a change-management commitment such as advance notice, rollback review or documented evaluation before release.
• Measurement owner: product, applied AI, ML engineering or a cross-functional model-governance team.
• Evidence: versioned evaluation sets, release notes, human-review records, benchmark reports, change-control logs and production monitoring.
• Typical remedy: often a rollback, patch, re-evaluation process, or change freeze rather than a classic uptime-style service credit.

In many products, the right answer is not to promise a broad numerical output-quality SLA at all. If customer prompts, customer-provided data, or third-party foundation models materially affect the result, a simple "accuracy" promise may be too unstable to administer. You may instead promise a disciplined process: documented model changes, notice of material updates, regression testing against an agreed sample set, and a route for quality incidents to be investigated and, where appropriate, rolled back.

That is not weaker drafting. It is often more honest drafting. A promise that cannot be measured consistently is harder to defend in negotiations and harder to operate when something goes wrong.

Choose metrics you can actually measure and defend

A compact example of a workable promise, using illustrative numbers only and not market-standard or recommended legal thresholds, might look like this:

• Illustrative measurable promise: "During each calendar month, the production inference API will be available 99.9% of the time, excluding scheduled maintenance announced in advance under the agreement. Availability will be measured by the provider's gateway logs. If availability falls below that threshold, the customer may claim a defined service credit for that month."

That example works because it identifies the service component, the measurement period, the measurement source, the exclusion concept and the consequence.

A tempting but unworkable promise often sounds like this:

• Illustrative unworkable promise: "The AI will always provide accurate, reliable and non-hallucinatory answers suitable for the customer's business needs."

That sounds reassuring in sales, but as contract language it is usually too broad. It does not define the task, the evaluation method, the allowed input conditions, the effect of customer data quality, the effect of third-party model changes, or what counts as a miss. "Always" is especially dangerous where the underlying technology is probabilistic and where outputs may depend on shifting real-world data or retrieval sources.

If you need a technical discipline for cloud-style operational metrics, NIST's publication on cloud computing service metrics is useful voluntary guidance. It emphasizes representative, accurate and reproducible metrics, and the connection between service-agreement language and runtime measurement. It is not a mandatory legal rule and it does not tell you what uptime percentage, remedy or claim procedure to choose.

For the AI-specific side, the NIST AI Risk Management Framework Core is also voluntary guidance, not a binding source of SLA terms. Its practical value is that it pushes teams to define the AI task, identify knowledge limits, document test sets and metrics, measure performance under deployment-like conditions and monitor functionality in production. That can improve the quality lane of your negotiation, even though it does not prescribe service credits, uptime figures or legal remedies.

Draft the operational edges: exclusions, dependencies, maintenance and credits

Once the lanes are separated, most negotiation time goes into the edges: what is excluded, who bears dependency risk, how incidents are classified, and how a customer actually claims relief.

Exclusions. If a metric applies, say what does not count. Common drafting choices include scheduled maintenance, emergency maintenance, customer misuse, unsupported configurations, customer-side network failures, customer delays in providing required information, beta or preview features, force majeure events and failures caused by third-party services outside your control. These are drafting choices, not automatic universal rules, and they should match the architecture you actually run.

Third-party dependencies. Many AI services rely on upstream cloud infrastructure, model providers, embedding services, search layers, transcription engines or data suppliers. If those dependencies matter, the SLA should say so plainly. You do not need to disclaim all responsibility to address dependency risk, but you should avoid promising a level of control that your stack does not give you.

Maintenance and changes. Customers will usually accept planned maintenance if the contract explains when it can happen, how notice is given and whether major release changes are handled differently from routine updates. AI systems also need change-management discipline. If you regularly change prompts, routing logic, model versions or retrieval pipelines, decide which changes require notice, which require internal approval, and whether certain customers get a rollback or freeze option after a significant regression.

Incident severity. Severity should track business impact, not simply technical symptoms. A Severity 1 event might be a full production outage, a widespread inability to generate outputs, or a security-related service disruption. Lower severities may cover partial degradation, single-customer issues, reporting defects or non-critical bugs. The severity definitions should connect to response targets and communication obligations in the support lane.

Credit claim workflow. If you offer credits, spell out the process. A workable clause usually answers these questions:

• Who measures the event and from what records?
• Does the customer need to submit a written claim, and within what contractually stated period?
• What information must the customer provide, such as the affected service, incident dates or ticket references?
• How is the credit calculated?
• Is the credit applied to future fees, and are there caps or aggregation rules?
• How are disputes about the calculation handled?

Do not leave the credit mechanics implied. If the commercial intention is that credits are not automatic, say so. If the intention is that credits are the sole remedy for a narrowly defined service-level miss, that should be expressed carefully and then reviewed against the rest of the contract and the governing state law rather than assumed to be effective in all circumstances.

Keep the evidence trail aligned with each promise. Availability metrics usually depend on monitoring and logs. Support metrics depend on ticket timestamps and escalation records. Quality or change-management commitments depend on evaluation records, release notes, model version history and incident reviews. If nobody can produce the evidence after a dispute starts, the contract language will not save the process.

A practical negotiation position for an AI company

A strong negotiation position is not "we refuse to promise anything" and it is not "we will sign the customer's generic enterprise SLA." It is: we will make measurable promises where measurement is reliable; we will separate infrastructure performance from support responsiveness and from model-output governance; and we will not pretend that one uptime number solves all three problems.

That usually leads to a better customer discussion. For the infrastructure lane, you may be able to commit to availability and latency. For the support lane, you may commit to response times and incident updates by severity. For the model-quality lane, you may either set a tightly defined measurable benchmark or choose a process promise instead, such as release testing, notice of material changes, and a rollback or review path for quality regressions.

If you need help turning that position into customer-ready paper, Sprintlaw Tech LLC can assist through its platform. Sprintlaw Tech LLC is not a US law firm. Licensed US attorneys provide legal services through the platform where required. For help with a main agreement, an SLA schedule, enterprise support commitments or AI-specific change-management language, call (888) 449-8437 or email team@sprintlaw.com.

Again, this article is general information only and not legal advice. The right SLA depends on your product, your support model, your upstream dependencies, the rest of your contract set and the governing law chosen for the deal.