Here's a fun exercise. Open the statement of work for your current AI engagement and search it for the word "deprecation". We'll wait.
If you found nothing, you're in good company, and you have a problem. Because the system you're building has a load bearing dependency on a model that a vendor can retire whenever it likes, and the paperwork is silent about whose problem that is when it happens.
It will happen. This isn't doom talk, it's a calendar. We track model shutdowns on our Platform Ledger, and the schedule reads like a departure board. At the time of writing, OpenAI has more than a dozen models leaving service inside ninety days, including entire product surfaces (the Assistants API retires in August, replaced by a different API with a different shape). Google's Gemini line is cycling generations with shutdown dates a few months out. Every provider does it, at different speeds, with different amounts of notice. The model your client's system calls today has a decent chance of not existing in its current form by the time your warranty period ends.
Why this wrecks projects specifically
A model retirement is not like a library going out of date, where the old version keeps working while you ignore the upgrade guilt. When a hosted model is shut down, the API calls fail. The system stops. And the replacement is not a drop in swap, whatever the migration guide says.
The new model behaves differently. Prompts that were tuned over weeks produce different outputs. Edge cases you fixed reappear wearing different clothes. Output formats drift just enough to break the parser downstream. Costs change, sometimes down, sometimes not. So the migration is real engineering work: re running evaluations, re tuning prompts, regression testing the pipeline, getting stakeholders to re approve outputs they'd already signed off once.
Now the only question that matters commercially: who pays for that work? If the contract doesn't say, the client will assume you do, because from where they sit the thing they bought stopped working. You'll assume they do, because a third party retired a product and that's hardly your doing. That disagreement, held in good faith on both sides, is how relationships end up in our archive.
The clause
What follows is a starting point to adapt with someone qualified, not legal advice, and definitely not something to paste in unread. But the shape of a decent model deprecation clause covers five things.
Name the dependency. The SOW states which model and version the system is built and tested against. Not "a leading large language model", the actual model identifier, pinned. Vagueness here feels flexible and costs you later, because you can't prove what changed if you never said what it was.
Define the trigger. A deprecation event is the provider announcing end of availability, materially changing pricing beyond an agreed threshold, or materially changing model behaviour. That third one matters. Providers update models in place, and a silent behaviour change can hurt you as much as a shutdown.
Assign the monitoring. Someone is named as responsible for watching provider announcements during the engagement and support period. This is a real task. Provider notice periods are finite and occasionally short, and the difference between three months of runway and three weeks of panic is somebody having read the announcement on the day it went out.
Price the migration in advance. Migration to a successor model is a defined, chargeable piece of work, either as a pre agreed change request with an estimate attached or as an explicit exclusion the client acknowledges. The number can be a range. The point is that the conversation happened at signing, when everyone was friendly, rather than at failure, when nobody is.
Bound the support obligation. Any warranty on system behaviour applies to the named model version. If the ground shifts underneath it, the warranty covers helping the client onto the new ground at the agreed rate, not free rebuilding in perpetuity.
Scoping the engagement to survive it
The clause protects the paperwork. Two engineering decisions protect the system, and they belong in your scope because they're much cheaper on day one than day three hundred.
Put an abstraction layer between the application and the provider, so that swapping models is a configuration change plus testing rather than surgery. And build the evaluation set from the start: a few hundred representative inputs and approved outputs. When the migration comes, that eval set is the difference between "we validated the successor in four days" and "we argued about vibes for a month." Sell both as what they are, insurance priced at a fraction of the incident.
If you're choosing between providers at scoping time, deprecation behaviour should be a weighted criterion alongside capability and price. Providers have observably different habits here. Some publish long runways and formal lifecycle policies. Some retire fifteen things on a Tuesday. The Vendor Evaluation Matrix has a column for exactly this, and the Platform Ledger will show you each provider's habits in public, updated daily, with receipts.
The uncomfortable summary
The AI platform economy currently ships faster than it stabilises, and everyone downstream is absorbing that instability somewhere: in contracts, in budgets, or in unpaid weekend migrations. Consultants don't get to opt out of that. What you get to choose is whether the absorption is priced, named and agreed in a paragraph of the SOW, or discovered later in an email thread with the word "urgent" in the subject line.
One paragraph. Write it in. The SOW Toolkit has the commercial protection framework it slots into, and your future self, reading a provider's sunset announcement over breakfast, will be uncharacteristically grateful.