Telling an enterprise buyer that your product abstracts the model is a maintenance promise. That work deserves its own staffing and price.
If a buyer approves observed behavior rather than the model underneath it, changing the model changes the thing it evaluated. Microsoft distinguishes model versions from API versions, warns that behavior can change after an Azure OpenAI upgrade, and tells customers to test their workflows. The API can remain compatible while the result the risk team approved becomes approximate. If the agreement defines change through API availability alone, no term may be triggered. Without a notice and validation process, the vendor may first learn about the difference through a support ticket on a workflow that used to be fine.
The routing swap is the cheap part. The cost lies in proving the new configuration does the same job on the customer’s data: reconstituting an eval set that no longer matches production, re-running the prompts customers wrote themselves, rechecking the edge cases behind the last few escalations, and getting a named person on the customer side to agree the output still meets what they approved. Across accounts with account-specific prompts and retrieval settings, that stops being a sprint. It becomes a standing claim on the platform team that surfaces in the roadmap review as slippage nobody can explain.
Two places to write it down.
With the provider: which versions are running in production, what notice comes before one is retired or updated in place, whether the prior version stays reachable during a transition, and what to do when that notice is shorter than a customer’s validation cycle.
With the customer: what counts as a material change in behavior, who gets told and when, how long the previous configuration stays available, and who pays for re-validation when the customer’s own controls require a fresh review. For a regulated buyer, define the deliverable as a controlled migration and a report its risk team can file. The contract can then price the report and the validation cycle. An unannounced change gives the customer grounds to treat the work as an incident and raise it at renewal.
In diligence I would ask for the migration history rather than the model strategy. How many forced version changes in the last four quarters, how many engineering weeks each one consumed, how many accounts needed re-approval, and whether a renewal slipped while one was in progress. Then, what shipped late because of it. If the answer is that upgrades happen quietly and customers never notice, there are two readings available. The work may be genuinely insensitive to which model runs it, which is worth knowing, because it says the model layer is not where the pricing power sits. Or nobody is checking, and the absence of verification will remain hidden until a customer does.
For vendors with account-specific configurations, protecting enterprise gross margin means treating re-qualification as something they ship: a versioned report, on a stated cadence, attached to a support tier the customer pays for. The alternative is engineering time spent on a provider’s release calendar for free, while finance keeps booking it as product development.