The vendor changed the model. Your company did not notice. Pin the version your process was tested on.
One day last spring, a major vendor quietly swapped the default model behind its flagship product. No release notes, no customer notification. Prompts that worked cleanly on Monday returned drifted answers on Thursday, output schemas renamed fields and broke downstream parsers, and in some shops the brand voice shifted in customer-facing copy until a customer flagged it. The companies that noticed fastest were not the ones with the best vendors. They were the ones not running on defaults.
Here is the reframe this playbook earns its place with: when your team says "we are standardized on Vendor X," what the board should hear is undiversified concentration risk on a vendor we do not control. Most enterprises name a single primary model vendor, and most have no documented fallback. The fix has four steps, and the first one is entirely within your power no matter what your contract says.
Every serious AI platform lets you call a specific model version instead of a floating default. An endpoint like "latest" is a convenience the vendor built for their release process, not for your production stability: the version behind it can change without any code change on your side. Pinning means your workflows name the exact version they were tested against, and nothing changes underneath you until you decide it does. It costs a deployment setting. Which flows to pin is a judgment call with a simple rule: anything high-stakes runs version-locked (legal documents, financial summaries, regulated workflows, board materials), anything high-volume runs monitored, and only prototypes run unlocked.
Test second, because pinning without testing is a snapshot of past trust. A nightly regression suite runs your top ten production prompts against a frozen set of known-good outputs and diffs the results. Regression here has a plain meaning: a prompt that worked cleanly on Monday returns a wrong or drifted answer on Thursday, because the model changed, not your code. The suite is a one-week engineering project, and it converts "we found out from a customer" into "we found out at 6am from a diff." When you do choose to upgrade versions, the same suite tells you in one night whether the new model passes.
Get notification rights into the contract when you can, and know that you cannot always get them: some vendors will not sign it, and some of your AI arrives embedded inside other SaaS where you never see the model at all. That is exactly why pinning comes first. When you can get the language in, here is a starting point your contracts lawyer can adapt in half an hour:
Notice. "Vendor shall provide Customer with no fewer than 30 calendar days' written notice prior to any change in the model version underlying any endpoint referenced in Exhibit A." A 14-day notice period is an acceptable negotiated floor.
Rollback. "Customer shall have the right to maintain access to the prior model version for no fewer than 30 days following any model version change."
Testing. "Vendor shall cooperate with Customer's reasonable regression testing during any transition period."
One timing fact worth knowing when the upgrade press release drops: the vendor's gain timeline and your cost timeline are offset by two to six weeks. The release ships Tuesday, your prompts start drifting Wednesday, and the CFO asks about the anomaly in three weeks. The regression suite closes that gap to one night.
Pinning is a configuration change per workflow. The regression suite is one engineering week. The notification clause is a paragraph at your next renewal. The tested fallback is the real investment, roughly six weeks to validate an alternate vendor on your critical workloads, and it pays for itself the first time it fires, or the first time you use it as leverage in a renewal conversation.
The first edition taught the contract clause as the control, and a year of real procurement changed my mind. You will not always have the option to sign swap rights into an agreement, and a growing share of the AI in your company arrives embedded in someone else's product where no clause reaches. The control you always have is engineering: wire the selected model into the process instead of letting your work ride on the vendor's default. Get the clause when you can. Pin the model always.
The workflow and vendor map in a Phase Zero assessment surfaces exactly that. Already have the map? A Pilot Build starts from it and pins as it builds.
Start with a Phase Zero assessment Explore all engagements