“The platform will be available 99.9% of the time.”

That looks like a service commitment. It may even survive procurement and appear on a dashboard. But it leaves most of the operating decision unanswered. Available to whom? For which workflow? Measured where? Does a technically successful response count when it contains stale data? What happens after the target is missed? Who handles the queue when an automated workflow sends work to people faster than they can review it?

A useful technology SLA is not a decorative uptime number. It is a compact operating model for a service that other people depend on. The document should connect the user’s outcome to measurable behavior, state what each side must do, and define the decisions triggered by normal variation, overload, change, and failure.

That standard applies whether the service is a customer API, an internal data platform, a managed cloud product, an AI assistant, or a review team sitting inside an automated workflow.

Begin with the service-promise canvas

Before debating percentages, write one page that answers the following decisions. This is the center of the agreement; legal language and detailed runbooks can follow where they are needed.

The canvas prevents one team from promising an outcome while another quietly absorbs its cost or risk. It also exposes a common problem early: sometimes the organization does not yet have enough instrumentation, capacity knowledge, or ownership clarity to offer a credible agreement. That discovery is useful. A promise should follow evidence, not substitute for it.

Put the user journey before the component

Infrastructure metrics are necessary, but users experience workflows. A database can be healthy while a dashboard shows yesterday’s numbers. A model endpoint can return HTTP 200 while an agent selects the wrong tool. A document platform can be online while access rules prevent the right employees from finding what they need.

Define the covered journey first:

During regional support hours, an authorized specialist can retrieve the current policy for an eligible case and receive a reviewable draft before the response deadline.

This statement gives the team something concrete to decompose. Identity, retrieval, policy freshness, model inference, application code, and human review all contribute to the journey. It also makes the exclusions discussable. Perhaps unusual legal cases are outside the automated path. Perhaps bulk imports have a different service window from interactive requests. Perhaps the assistant may draft but never send.

Google’s SRE guidance recommends starting with what users care about and then choosing a small set of representative indicators. Its service-level terminology also separates an indicator, an internal objective, and an agreement with consequences. That distinction keeps every dashboard target from being mislabeled as a contract.

For internal services, the consequence does not need to be a financial credit. It might be a freeze on feature releases, a capacity review, a temporary move to a manual workflow, a funding decision, or an executive risk acceptance. If missing the target changes nothing, the number is reporting—not an operating commitment.

Keep the measurement, target, and consequence separate

Technology teams often compress three different ideas into one sentence:

• SLI: the observed measure, such as the share of valid requests completed within eight seconds.
• SLO: the target, such as 95% of those requests over a rolling 28-day window.
• SLA: the commitment between parties, including scope, responsibilities, and what follows a miss.

The separation matters because each element can fail independently. A sensible target measured from the wrong location gives false confidence. A precise measure with an arbitrary target can push the team toward waste. A contractual target without an operational response creates arguments after an incident instead of decisions during it.

Measurement details belong in plain view. State the event that starts and stops the timer, which requests enter the denominator, how planned maintenance is treated, which time zone defines the service window, how partial results count, and whose telemetry settles a dispute. Percentiles are usually more revealing than averages for latency because an acceptable mean can hide a painful tail.

Targets should come from consequence and tested capability. Ask how long the user can tolerate delay, how much incorrect or incomplete work can be caught safely, what recovery point the business can accept, and what the architecture can sustain. Then price the gap between current evidence and the desired level. Choosing “four nines” because it sounds professional is not reliability engineering.

The companion note on turning vague AI requirements into testable rules goes deeper into translating words such as “fast,” “accurate,” and “safe.” An SLA uses those testable rules to define a continuing relationship, not only a release gate.

Treat the service as a chain of promises

Most modern services cross organizational and technical boundaries. A product team may own the interface, a platform team the runtime, a data team the source pipeline, an external provider the model, security the access policy, and an operations team the response process. No single component SLA guarantees the user journey.

Create a dependency register beside the canvas. For each dependency, record:

1. What the service needs from it.
2. What level it actually promises.
3. How failure is detected from the consuming service.
4. Which fallback exists and what quality it provides.
5. Who can change, replace, or escalate the dependency.

Vendor agreements deserve special care. A service credit can partially compensate an invoice, but it does not answer customers, restore corrupted data, clear a review backlog, or protect a missed business deadline. The consuming team still needs its own detection, degradation, and recovery plan. It should also know whether the vendor’s measurement window, exclusions, support tier, and incident clock match the business journey.

Composition creates arithmetic as well as accountability. If a workflow requires several independent services to succeed, its achievable availability is lower than the best component’s headline figure. Parallel fallbacks can improve resilience, but they add implementation work, testing, security review, and cost. A dependency diagram becomes operational only when each edge has an assumption and an owner.

Add data and AI quality without pretending it is uptime

Conventional availability remains important for AI and data products, but it is incomplete. A data service can answer quickly with missing records. A retrieval system can be online while returning irrelevant context. A model can respond fluently while violating a policy. An agent can complete a tool call that should never have been attempted.

Modern service promises may therefore need several indicator families:

• Technical delivery: availability, end-to-end latency, throughput, timeout rate, and recovery.
• Data condition: freshness, completeness, schema validity, lineage coverage, and reconciliation failures.
• Task quality: success on a versioned evaluation set, groundedness, valid structured output, abstention behavior, and production review findings.
• Action safety: permission violations, prohibited tool attempts, irreversible actions, and approvals bypassed.
• Human experience: review queue age, override rate, unresolved exceptions, and user-reported failure categories.

Do not collapse them into one composite score that nobody can interpret. Give each measure a decision. A latency breach might route traffic to a faster model. A freshness breach might display the last verified update and block sensitive recommendations. A quality regression might stop a rollout even though uptime remains perfect.

NIST’s AI Risk Management Framework Core calls for production monitoring of system behavior, documented evaluation under conditions similar to deployment, and defined responsibilities for human-AI configurations. Those are useful requirements for an AI service agreement because they connect assurance to the live workflow.

Observability is becoming easier to standardize across providers. OpenTelemetry now maintains generative AI attributes for signals such as operations, models, token use, and tool calls. Common telemetry does not decide which service level is appropriate, but it can reduce ambiguity about what happened across a multi-model or agent workflow. Sensitive prompts, tool arguments, and user data still require deliberate collection and access policies.

Budget capacity, cost, and human review together

A promise is credible only within a supported demand envelope. State normal volume, burst tolerance, maximum payload or context size, concurrency, regional coverage, and expected growth. If consumers can exceed those assumptions without notice, the service provider cannot plan capacity. If providers can throttle without a declared rule, consumers cannot plan their workflow.

AI services add token throughput, provider rate limits, long-running tool calls, and variable inference cost to the capacity discussion. Data platforms add batch windows, warehouse concurrency, and backfill load. Human approval adds shifts, queue limits, skill requirements, and fatigue.

Human review is frequently described as a safeguard but funded as if it were free and infinitely elastic. The agreement should name:

• which cases require a person;
• the evidence the reviewer receives;
• expected arrival rate and peak queue;
• response time by severity;
• who provides backup coverage;
• what happens when the queue exceeds its safe limit.

Without those details, automation can simply move the bottleneck from compute to people. The interface may remain available while the actual service silently stops.

Higher reliability also has a price. Microsoft’s current reliability tradeoff guidance makes the operating costs explicit: redundancy, observability, drills, documentation, and on-call coverage all consume money or attention. The target should reflect the value of the protected journey. Overengineering a low-impact internal report can be as irresponsible as underengineering a customer payment flow.

This is why protecting reliability while shipping AI is partly a capacity decision. Teams need room for evaluation, maintenance, incident response, and recovery—not only feature delivery.

Make escalation a decision path, not a contact list

An escalation section that contains only names and phone numbers is incomplete. It tells people whom to disturb, but not what that person can decide.

For each breach condition, define:

• trigger: the observable threshold or event;
• severity: the user or business consequence;
• first action: continue, degrade, queue, fail over, roll back, or stop;
• authority: who may take that action without waiting for another meeting;
• communication: who needs which update and by when;
• recovery evidence: what must be true before normal service resumes.

Consider three clocks. Detection time measures how long it takes to notice the condition. Decision time measures how long the organization takes to authorize a response. Recovery time measures how long it takes to restore an acceptable journey. Teams often optimize the third while leaving the first two vague.

AI incidents also need triggers beyond outage. A sudden rise in unsupported answers, repeated prohibited tool attempts, policy-source staleness, abnormal cost per completed task, or a growing override rate can justify intervention. The AI incident-response guide explains how to connect those signals to safe fallback and return-to-service decisions.

Work through one layered example

Suppose an internal assistant helps support specialists prepare policy-based customer responses. A workable agreement might be summarized as follows:

These numbers are examples, not universal recommendations. The right thresholds depend on case severity, user tolerance, tested system behavior, staffing, regulation, and the cost of failure. The value of the table is that every layer names a decision. It does not permit “the API was up” to end the conversation.

It also reveals hidden work before launch: evaluation data, freshness telemetry, permission testing, queue monitoring, alternate workflows, and reviewer coverage. The note on the hidden work behind reliable AI projects explains why those items belong in the estimate rather than in an emergency backlog after release.

Review the promise when reality changes

An agreement can become inaccurate while every team continues to comply with its wording. Traffic grows. Users treat a recommendation as a decision. A batch report becomes operationally critical. A model provider changes. A data source moves. A human-review step receives twice the expected volume. A low-risk assistant gains write access.

Add review triggers instead of relying only on an annual calendar:

• a material change in volume, user group, geography, or service hours;
• a new vendor, model, tool, data source, or permission;
• a repeated breach or near miss;
• a sustained change in cost per successful outcome;
• a new regulatory, security, or business-impact classification;
• evidence that users depend on performance beyond the stated promise.

The review should compare the written service with observed use. Retire indicators that no longer drive decisions. Tighten targets only when the user benefit justifies the operating cost. Loosen or narrow a promise when evidence shows that the current scope cannot be supported honestly.

Version the agreement, dashboard, runbook, and dependency map together. A target referring to an old measurement query is worse than no target because it creates confidence without control.

Use a pre-signing test

Before an SLA is approved, ask both provider and consumer to answer ten questions without consulting the author:

1. Which user journey is protected?
2. What traffic and time window are included?
3. Where is success measured?
4. Which target applies, and over what period?
5. What does each party provide?
6. What demand can the service sustain?
7. Which dependency can break the journey first?
8. What happens immediately after a breach?
9. Who has authority to degrade or stop the service?
10. Which change forces a new review?

If the answers differ, the document has not created agreement yet. Revise it, test the telemetry, and rehearse one breach scenario. The rehearsal will usually find ambiguities that reading alone misses.

The most useful technology SLA is not the strictest document or the one with the most metrics. It is the one that helps people make a hard decision before an incident, during overload, after a vendor failure, and when the service evolves.

Write the promise around the outcome. Measure it from the user’s path. Assign both sides of every dependency. Fund the capacity—including human capacity—needed to keep it. Define what a miss changes. Then keep the agreement synchronized with the service people actually use.