How to Write an AI Maintenance and Support Contract

Most support contracts get written once, copied for every client, and never revisited. That works fine for a static website. It doesn't work for an AI product, because the thing you're agreeing to support keeps changing underneath you. A model gets deprecated. An API provider changes its output format overnight. A “bug” turns out to be the model working exactly as designed, just not as the client expected. A maintenance and support contract for an AI product needs to cover three things a generic template never mentions: tiered response times, a real definition of bug versus feature, and a clause for what happens when the underlying model changes mid-contract. Here's how to write one.

What to Include in an AI Support Agreement

A solid maintenance and support contract for an AI product covers six areas. Skip any of them and you end up negotiating scope by email in the middle of an incident, which is the worst possible time to do it.

• Response time tiers: how fast you respond and resolve, broken out by severity, not one blanket “24 hours” promise.

• Bug versus feature definition: a written test for what counts as a covered fix versus billable new work.

• Model change and deprecation clause: who decides, who pays, and how much notice is owed when the provider retires or changes the model the product runs on.

• Scope boundaries: which layer of the system you're responsible for, and what you're explicitly not.

• Uptime and quality definition: what “working” means for a product whose failures are often silent output problems, not server crashes.

• Renewal and pricing terms: how the fee adjusts as usage, model costs, or scope shift.

Response Time Tiers That Match How AI Products Actually Fail

Generic support contracts sort tickets into “urgent” and “not urgent.” That's not granular enough here, because AI failure modes aren't binary. A traditional app either runs or throws an error. An AI feature can run fine, return a response, and still be wrong, so severity has to account for output quality as well as availability.

A structure that holds up in practice:

• Severity 1, critical: the feature is down, erroring out, or producing outputs that could cause real harm, wrong financial or legal-adjacent answers, data exposure, a safety filter bypass. Response within a few business hours, work continues until it's resolved or mitigated.

• Severity 2, degraded: the feature runs but accuracy or relevance has visibly dropped, or usage cost has spiked unexpectedly. Response within one business day, fix scoped within the week.

• Severity 3, minor: edge-case quality issues, cosmetic problems, non-blocking inconsistencies. Response within two to three business days, batched into the next update.

• Severity 4, enhancement request: anything the client wants that the system wasn't built to do. Logged and quoted separately, not covered by the retainer.

Put real numbers in the contract. “Prompt response” is not enforceable. “Four business hours” is.

Where Bug Stops and Feature Starts

This is where AI support contracts break down most often, because the client's idea of “wrong” doesn't match how the system actually works. A traditional bug is a fixed thing: the code should do X, it does Y, that's a defect. An AI feature can be “wrong” in several different ways, and only some of them are bugs.

Define a bug as the system failing to do something it was built and tested to do: a broken integration, a prompt template that regressed after a code change, a retrieval step pulling the wrong source documents, an output that fails to parse into the expected format. These are covered under the maintenance fee.

Define a feature request as the client wanting the system to handle something it was never scoped to handle: a new document type, a new language, a new decision the model wasn't asked to make, a request to make the model noticeably more creative or more conservative than the original scope called for. These get scoped and quoted separately.

The gray zone is inconsistent output on tasks that were in scope. Write a specific clause for it: agree on an acceptable error rate against a shared test set before signing, and treat outputs that fall below that bar on in-scope tasks as bugs. Note in the contract that models are probabilistic and some variance on genuinely ambiguous inputs is expected behavior, not a defect, unless it crosses the agreed threshold.

The Clause Generic Templates Skip: Model Changes and Deprecation

This is the risk that's specific to AI products, and the one almost no off-the-shelf support contract template accounts for. The model or API a product runs on isn't static. Providers deprecate models, change default behavior, or shift rate limits, sometimes with a few months' notice and sometimes with less. If the contract is silent on this, you absorb the cost while the client assumes it was already covered under “maintenance.”

Write a clause that answers three questions directly:

• Notice: what happens when the provider announces a deprecation or breaking change. Commit to notifying the client within a set window, five business days is reasonable, of becoming aware of it.

• Migration responsibility: is re-testing and re-tuning after a model swap covered under the retainer, billed as a separate project, or split by an agreed formula, for example one included migration per 12-month term with additional ones quoted?

• Performance parity: you're responsible for verifying the replacement model meets the quality bar defined in the bug clause, not for guaranteeing identical output, since a like-for-like swap can still shift behavior in ways outside your control.

A workable clause reads something like: if a third-party AI model or API used in the product is deprecated, materially changed, or discontinued by its provider, the contractor will notify the client within a set number of business days of becoming aware of it. Migration, including re-testing against the agreed quality benchmark, is included in or billed separately from the monthly fee, up to a stated number of migrations per term. The contractor isn't responsible for output differences caused by provider-side changes beyond its control, but will use reasonable efforts to restore equivalent performance.

Scope Boundaries: What's In, What's Out

AI products sit on top of a stack nobody fully controls end to end: the model provider, the hosting layer, sometimes the client's own data pipeline. Be explicit about where your responsibility starts and stops.

Typically in scope:

• The application code you built: prompts, orchestration logic, API integration, the interface.

• Monitoring for errors, cost spikes, and output quality regressions against the agreed benchmark.

• Bug fixes as defined above, within the response time tiers.

• Minor prompt and configuration tuning within existing scope.

Typically out of scope:

• The underlying model provider's own uptime and outages, point clients to the provider's own terms rather than guaranteeing them yourself.

• Data quality problems originating in the client's own systems.

• New features, integrations, or use cases that weren't in the original scope document.

• Client-side infrastructure the product depends on but you don't manage.

Attach the original scope document as an exhibit to the support contract. It gives both sides a fixed reference point for what the product was built to do, which is what the bug-versus-feature test above depends on. If that scope was never written down formally, that's what a project proposal is for.

Retainer Structure and Renewal Terms

Most AI support agreements run as a monthly retainer rather than a one-time fee, because the work, monitoring, minor fixes, responding to model changes, is ongoing by nature. How you price that retainer is a separate decision, but the contract should spell out three things regardless of price: the term length, month-to-month or a minimum of three to six months, what triggers a price change, and the notice period either side needs to cancel or not renew. Thirty days is standard.

If usage grows well beyond what was scoped, a support tool built for a few hundred requests a month suddenly handling several thousand, build in a review checkpoint instead of waiting for the renewal date. A clause like “either party may request a scope and pricing review if actual usage exceeds an agreed threshold for two consecutive months” keeps the contract honest without forcing a full renegotiation every time traffic moves. This is the same problem covered from the build side in handling scope creep on an AI project, the support contract is just where you pre-write the answer instead of improvising it.

A Short Checklist Before You Send It

• Response time tiers with real hours or days, not vague language like “promptly.”

• A written test for bug versus feature, tied to an agreed quality benchmark where possible.

• A model-change and deprecation clause naming the notice period and who covers migration cost.

• Scope boundaries that list what's explicitly out, not only what's in.

• Renewal terms with a defined notice period and a usage-based review trigger.

• The original scope document or proposal attached as an exhibit.

Recurring maintenance and support is one of the more overlooked lines in how AI builders actually get paid, most of the attention goes to the initial sale, but a contract that survives a model deprecation without a fight is what makes the recurring part worth having.

Frequently Asked Questions

What's the difference between an SLA and a maintenance contract?

An SLA, service level agreement, is usually the response-and-resolution-time section inside a larger maintenance contract, not a separate document. The maintenance contract covers scope, fees, and responsibilities; the SLA is the specific, numbered commitment on how fast you respond and fix things by severity. Some clients ask for it broken out as its own signed document, and in that case it helps to write a dedicated SLA rather than bury the terms inside the maintenance contract.

How much should you charge for AI product support?

There's no fixed number, it depends on scope and usage volume, but most builders price it as a monthly retainer sized to expected support hours and model costs rather than a flat percentage of the original build fee.

Who is responsible when the underlying AI model breaks something?

Whatever the contract says, which is exactly why the deprecation clause matters. Without one, responsibility defaults to an argument after the fact. With one, it's a described process: a notice period, a migration cost split, and a defined performance bar the replacement model has to hit.

Should AI support contracts be monthly retainers or billed by the hour?

Monthly retainers tend to work better for AI products than pay-as-you-go hours, because a chunk of the work, watching for silent quality drift and provider changes, is ongoing and hard to bill hour by hour. Hourly support tends to work only for low-touch products with rare, well-defined maintenance needs.

What happens if a client's usage grows far beyond what the contract assumed?

That's what the usage review clause is for. Instead of absorbing a five-times traffic increase inside a flat fee, or waiting for renewal to renegotiate, a review trigger tied to a usage threshold lets either side revisit scope and price as soon as the mismatch shows up.