Your AI Vendor's SLA Covers Uptime. It Never Covers Wrong Answers.

Most enterprise AI contracts read like they were written for a database. They promise uptime percentages, response time targets, and credits when the lights go out. They almost never say what happens when the system stays up and still gives the wrong answer with complete confidence.

That gap matters more every quarter. A chatbot that is unavailable for twenty minutes is annoying. A chatbot that is available all day and quietly invents policy clauses, misstates coverage limits, or steers a claims handler toward the wrong workflow can create customer harm, regulatory exposure, and a remediation bill that no SLA credit will cover.

Australian banks, insurers, government agencies, and retailers are buying model APIs and managed AI platforms the same way they once bought cloud infrastructure. The commercial language has not caught up with the risk profile.

Uptime is necessary. It is not the product.

Availability and latency still matter. If your credit decisioning assistant times out during a peak lending window, the business feels it. Ops teams are right to insist on 99.9% style commitments, regional failover, and clear incident communications.

The problem is treating those metrics as a proxy for quality. A model endpoint can return HTTP 200, meet its p95 latency target, and still:

• Hallucinate a product feature that does not exist
• Misquote an internal policy or a PDS excerpt
• Fail a safety filter that looked fine in offline evals
• Drift in tone or refusal behaviour after a silent provider update

From the vendor dashboard, everything is green. From the frontline, something is wrong and nobody has a contractual hook to escalate it as anything other than a 'feature conversation'.

Wrong answers that look confident are worse than downtime

Downtime is visible. Queues back up. Status pages flip. People stop trusting the channel until it recovers.

Confident mistakes are quieter. A retail assistant invents a returns exception and a store team honours it. An insurance summariser compresses a claim note and drops a material exclusion. A public sector knowledge bot cites the wrong circular and a case officer treats it as guidance. Each incident looks small until the pattern shows up in complaints, QA sampling, or an audit.

Traditional SLAs were never designed for this. They measure whether the pipe is open. They do not measure whether what came through the pipe was fit for purpose.

What behaviour SLOs actually look like

You do not need a fantasy contract that guarantees zero hallucinations. You do need first-class quality obligations that sit beside uptime.

Useful behaviour SLOs are concrete, measurable, and tied to your use case:

• Grounded answer rate on a fixed evaluation set drawn from your own documents and edge cases
• Critical hallucination rate for high-consequence intents (eligibility, pricing, legal or clinical adjacent claims)
• Safety incident rate for refused, blocked, or escalated prompts that should never reach a customer
• Behaviour drift budget after model or prompt version changes, measured against a frozen regression pack
• Human escalation success when the system is uncertain, including time to a named owner

For a bank running an internal policy assistant, that might mean: on a monthly gold set of 500 queries, grounded answers stay above an agreed threshold, and any critical fabrication triggers the same severity path as a Sev-2 outage. For a retailer, it might mean invented promotions are treated as a production defect, not a content tidy-up.

Define model mistakes as incidents

If your runbooks only cover timeouts and 5xx errors, you will keep discovering quality failures in Slack threads and customer complaints.

Write incident definitions for model behaviour the same way you write them for infrastructure:

• What counts as a critical wrong answer in this product
• Who gets paged when sampling or monitoring crosses a threshold
• What evidence must be preserved (prompt, retrieval context, model version, output, user impact)
• When the feature must be rate-limited, rolled back, or taken offline

An insurer that treats a surge of fabricated coverage statements as a Sev-1 will respond differently from one that files it under 'model quirks'. The contract should reinforce that posture, not leave it optional.

Contract language that treats quality as an obligation

Procurement and legal teams still reach for cloud-era templates. Push for clauses that vendors can actually instrument, and that you can audit:

• Named evaluation datasets or evaluation protocols, refreshed on an agreed cadence
• Notification and change control when the provider swaps models, system prompts, or safety layers that affect your tenant
• Remedies for sustained breach of behaviour SLOs (credits alone are weak; suspension rights, dedicated remediation, or exit assistance are stronger)
• Audit rights for logs and evaluation artefacts relevant to your workloads, within privacy constraints
• Clear allocation of responsibility for third-party content and tool outputs when the vendor hosts an agent stack

Government buyers in particular should treat this as part of responsible AI assurance, not as a nice-to-have appendix. If the Commonwealth or a state agency is putting a citizen-facing assistant live, 'we had 99.95% uptime' will not answer a Senate estimates question about wrong advice.

What executives and platform owners should do next

Start with one production AI surface that already has customer or employee impact. Map the current vendor SLA. List every failure mode that would hurt you while the endpoint stays healthy. Turn the top three into measurable behaviour SLOs and incident classes. Then take that language into the next renewal, RFP, or statement of work.

Inside your own platform team, stop celebrating green latency graphs as proof the AI is safe. Pair them with groundedness dashboards, drift alerts, and an escalation queue that someone actually owns.

The takeaway is blunt. Your AI vendor's SLA covering uptime is table stakes. If it never covers wrong answers, you are buying availability of a risk you have not contractually defined. Treat answer quality, safety incidents, and behaviour drift as first-class obligations, or accept that the next expensive failure will look, on paper, like a perfectly healthy system.