What Your AI Contract Should Say About Model Changes

Most AI service contracts are silent on the one thing guaranteed to happen: the model underneath changes. Not the vendor, not the price, not the API. The model. Your integration keeps working, your invoices keep arriving, and the quality of what you deliver moves in a direction nobody agreed to.

The clause you want is short. Notice before a change, the right to re-run your evaluation, and a defined remedy if results degrade. Three sentences, and they are far easier to add before signature than to argue about afterwards.

This is not hypothetical

DeepSeek announced on 10 September 2026 that from 04:00 UTC on 14 September, every deepseek-v4-pro API request would be served by V4.1-Flash instead, at Flash rates, until a V4.1-Pro launches on an unannounced date.

Four days of notice, a different architecture answering the same model string, and no error anywhere in the chain to tell a downstream customer. That is a well-behaved example, because DeepSeek announced it publicly. The version that should concern you is the one where a vendor changes a pool or a routing rule and tells nobody, because nothing in the contract required them to.

Who needs this clause

Two audiences, and they sit on opposite sides of the same table.

• If you buy AI services. You are paying for outputs of a certain quality. A model swap is a change to the thing you bought, and the contract should treat it as one.

• If you sell AI services. You depend on providers who can change under you with days of notice. Your client contract should not promise stability you have no way to deliver, and your provider contract should give you as much warning as you can negotiate.

Agencies and freelancers are exposed in both directions at once. Signing a fixed-quality commitment downstream while running on a provider with a four day notice period upstream is how you end up personally absorbing a vendor's roadmap. How to write an SLA for an AI product covers the wider service commitment.

The clause, in plain terms

Adapt the wording to your jurisdiction and have a lawyer read it, but these are the four moving parts.

Model changes.

(a) Notice. The Provider shall give the Customer at least thirty (30)
    days' written notice before changing the model, model version, or
    set of models used to deliver the Services, including any change
    to routing or model selection.

(b) Evaluation. On notice, the Customer may re-run its acceptance
    tests against the new configuration during the notice period,
    with access to both configurations for that purpose.

(c) Material degradation. If those tests show a material reduction in
    output quality as measured by the metrics in Schedule [X], the
    Provider shall remedy or maintain the prior configuration for
    [60] days, failing which the Customer may terminate without
    penalty and receive a pro-rata refund.

(d) Emergency changes. Changes required for security, legal
    compliance, or provider withdrawal may be made immediately, with
    notice as soon as practicable and clause (c) applying thereafter.

Clause (d) is what makes the rest acceptable to a vendor. Without it you are asking them to keep serving a model that has been withdrawn or found unsafe, and no reasonable counterparty will sign that.

The part everyone skips

Schedule X. A degradation clause that does not define degradation is decoration, and it is the reason most of these provisions never get invoked.

You do not need anything elaborate. Twenty to fifty representative tasks from your actual workload, a scoring rubric, and a threshold you agreed in advance. Written down, attached to the contract, and re-runnable in an afternoon.

Building that test set is work you should do regardless, because it is the same asset that tells you whether to accept any model change, contract or no contract. building a fixed test set before you switch models covers the method.

What you will actually get

Be realistic about leverage. A large provider on standard terms will not negotiate this with a small customer, and pushing hard on a clause nobody will sign wastes goodwill you need elsewhere.

Where it does land: resellers and agencies, smaller vendors selling into your business, anything with an order form rather than a click-through, and your own downstream contracts, where you are the one setting terms. Thirty days often becomes seven. Seven days of warning is still infinitely better than none, and asking establishes that you are the kind of customer who notices.

If you cannot get notice, get transparency instead: a commitment to publish model changes to a changelog you can subscribe to. It is a much easier ask and it solves most of the practical problem. Pricing and packaging the resulting service is covered in AI monetization strategies.

FAQ

Is thirty days' notice realistic?

With enterprise vendors and resellers, often yes. With frontier labs on public pricing, no. Ask for thirty, expect to settle nearer seven to fourteen, and treat anything with a defined number as a win over silence.

Does this apply if I use an orchestration service?

More so. A router changes which models it selects as a routine cost optimisation, so the change you care about may not even be a version bump. Ask for notice on pool composition specifically, not just model versions. The same opacity drives the data questions a routing service raises.

What if the vendor deprecates the model entirely?

Different clause, and you want both. Deprecation is usually covered by a sunset or end-of-life provision with a longer runway. What to do when an AI model gets deprecated covers the operational side.

Should I put this in my contracts with my own clients?

Yes, mirrored. Reserve the right to change the underlying model, commit to telling them, and avoid promising an output quality you cannot control. Silence in your own contract does not protect you, it just leaves the argument until the day it matters. How to negotiate a contract with an AI vendor covers the buying side in full.