What Your SLA Must Promise When AI Does the Work

An SLA written for AI-delivered work has to commit to a measurable outcome and disclose that a machine, not a person, produced it, something a human-technician SLA never had to spell out. Most MSPs still only do the first. New transparency rules, thin vendor liability coverage, and client trust gaps make the second just as contractual.

Why Does an SLA Built for Humans Break When AI Does the Work?

A traditional SLA assumes a technician is behind every response and resolution clock. It measures how fast a person acknowledged a ticket and how long a person took to close it, and it assumes that person exercised judgment along the way, judgment a client is implicitly paying for and that a court would look to if something went wrong.

When an AI agent triages, responds to, or resolves a ticket, none of those assumptions hold automatically. The clock can move faster, because software does not wait for a technician to open a ticket. But "resolved" from a model can mean something different than "resolved" from a person, especially when the agent closes a ticket without being sure it actually fixed the underlying problem. An SLA that only measures speed, without saying anything about who or what produced the outcome, is quietly promising a standard of judgment nobody agreed was being delivered.

That gap matters more once you look at where the liability actually sits. A March 2025 Stanford Law School analysis of AI vendor contracts, using data from the contract-review platform TermScout, found that 88% of AI vendors impose liability caps on their own products, close to the 81% rate across broader SaaS agreements. The same analysis found that only 38% of those contracts cap customer liability, compared to 44% in general SaaS agreements. In plain terms, the software vendor your AI tooling runs on has already limited what it owes you when the model gets something wrong, while your own exposure to your client stays wide open unless you write it down yourself.

What Must an SLA Disclose About AI?

Yes, and soon it will not be optional in every market. Under Article 50 of the EU AI Act, providers must design AI systems that interact directly with people, including customer service chatbots and virtual agents, so that those people are informed they are interacting with AI, with this disclosure obligation applying from August 2, 2026. The notice has to come at the start of the first interaction, not buried deep inside a terms-of-service document nobody reads, and the "it was obvious" exception is meant to be read narrowly rather than as an easy way out.

Even where no regulation applies yet, disclosure is where client trust already sits. A Five9 study of 4,000 consumers in the US and UK, fielded in September 2024, found that 84% of consumers are aware that some companies use AI to handle customer service interactions, yet 48% say they do not trust information provided by AI-powered customer service bots. The same study found that 75% of consumers prefer talking to a real human, in person or over the phone, for customer support. Clients already assume a person is on the other end unless told otherwise, so an SLA silent on which tasks run through AI is making an implicit promise about who does the work that the client never actually agreed to.

A 2026 CIO.com analysis of vendor AI risk recommends that disclosure obligations be written as their own contract clause, requiring vendors, and by extension MSPs reselling AI-powered service, to formally disclose where and how AI is used in delivering a service, proactively rather than only when a client asks. That is the practical standard to build an SLA disclosure clause around: name the task categories where AI does the work, state it in the SLA or statement of work itself, and update the disclosure whenever the mix of AI versus human handling changes.

What Can You Actually Promise When an AI Agent Handles the Ticket?

Promise what the agent can actually guarantee, not what a technician used to guarantee by implication. A response-time commitment still works for AI-handled tickets, often better than it ever did for a person, because software does not take lunch breaks or get pulled into another client's emergency. Resolution commitments need more care. "Resolved" should mean the issue did not reopen within a defined window, not just that a ticket status changed, and that distinction belongs in the contract rather than left assumed.

Escalation terms carry more of the real commitment than resolution terms do. The SLA should name the conditions that force a handoff to a person: a confidence threshold the agent fails to clear, a repeated back-and-forth with the client that signals the agent is stuck, or a request type carved out as AI-ineligible from the start, such as anything touching billing disputes, legal exposure, or safety. None of that needs a number to be enforceable. It needs a named trigger and a named human owner who picks it up.

Capacity claims deserve particular skepticism before they go in a contract. ScalePad's 2026 MSP Trends Report found that 43% of MSPs say AI already has or will fully replace roles in their business. Intent to automate a role is not the same as having validated that an AI agent can hold an SLA commitment at the volume and complexity your real contracts carry. Pilot the agent against actual ticket volume before the SLA reflects what you hope it can do rather than what you have measured it doing.

Who Absorbs the Risk When the AI Gets It Wrong?

By default, you do, not your AI vendor. Because most AI tooling vendors already cap what they owe you, as the Stanford Law School data above shows, a generic indemnity clause copied from an old master services agreement will not transfer AI-specific risk anywhere. If the agent gives a client bad guidance, misclassifies a security event, or takes an action it should have escalated instead, the client's recourse runs through your contract with them first, and your contract with your own tooling vendor second, and the pair are rarely matched in scope.

The fix is treating AI-related incidents as their own liability category instead of folding them into a generic errors-and-omissions clause. Define what counts as an AI-caused incident, cap your own exposure at a level you can actually absorb, and require your AI vendors to carry liability terms that approach what you are promising clients, rather than assuming the terms line up on their own.

How Do You Build This Into Your Service Catalog Instead of Relitigating It Every Renewal?

None of this works as a one-off negotiation repeated client by client. Disclosure language, escalation triggers, and liability allocation all need to be standard parts of how you provision and document any AI-delivered service before the first client signs, not patched in after a renewal gets uncomfortable. That is a provisioning and documentation problem as much as a legal one, and it starts with knowing which AI tools a client already runs. ActiWright flags AI apps that have been granted access to a client's Microsoft 365 tenant, giving you an inventory to write those disclosures against instead of every account manager writing one from memory.

Pair that with a clear view of what your current stack can and cannot responsibly commit to before pricing a new AI-delivered tier. The stack-builder tool maps what you already run against what an SLA for AI-delivered work actually requires, so the commitments you write down match the tooling you have, not the tooling you wish you had.

These pieces, a disclosure clause, escalation routing, and liability allocation, are also the kind of thing worth standardizing once across Actiforge's full product catalog rather than rebuilding for every client type. Getting that template right once is worth more than winning any single negotiation on speed alone. See the full stack to see how these pieces fit together across a white-labeled AI service catalog.