An AI tool you have relied on for months can behave differently overnight because the vendor swapped the underlying model — and unlike a software bug, this is often a deliberate change nobody told you was coming.
Key takeaways
When an AI vendor updates or swaps the model behind its product, the interface often looks identical while the outputs shift — a summary that used to catch a specific detail stops catching it, or a drafting tool’s tone changes. There is rarely a warning, because most vendor agreements do not promise one. Whether that is a problem you can do anything about depends entirely on what your contract with the vendor actually says, not on how reasonable the change feels.
If the model change breaks a workflow you had promised a client, the instinct is to treat the vendor’s decision as an outside event beyond your control — a force majeure. That argument is weaker than it feels. Ontario courts “generally interpret force majeure clauses narrowly and in light of their specific wording, not as a general ‘unfair circumstances’ excuse,” and the event has to actually prevent performance, not just make it less convenient or change the tool you were using. A vendor deciding to update its own product is arguably a foreseeable business risk of relying on someone else’s software, which cuts against treating it as the kind of unforeseeable, uncontrollable event a force majeure clause is written for. Where a contract has no force majeure clause at all, the fallback is narrower still — the common-law doctrine of frustration, which “is a high bar and courts apply it sparingly… a doctrine for genuinely transformed circumstances, not for a bad bargain or an inconvenient turn of events.” The practical takeaway: build slack into how you promise deliverables to clients, rather than counting on a legal excuse if the underlying tool changes.
The clauses that decide how much a model change costs you were written before you needed them — at the point you signed up for the tool, not after it started behaving differently. A practical checklist built for exactly this situation names what matters: termination rights (for convenience, for cause, or only at a fixed term’s end), a data export clause that specifies a usable format and a defined window rather than a vague promise, any transition-assistance period where the vendor keeps helping after you leave, and whether your own configuration work — prompts, templates, workflows built inside the tool — can be taken with you or is treated as the vendor’s proprietary structure. A contract that is silent on all of this does not leave you with no rights, but it leaves you negotiating from a weaker position exactly when a vendor has the least incentive to accommodate you — after the relationship has already gone wrong.
A constructed illustration: a drafting tool your practice relies on switches its underlying model, and the output quality visibly drops for a specific task you had built a workflow around. Your contract has no committed data-export format and no notice requirement for the change itself. Practically, that means you can still ask for your historical data and templates back, but you have no specific format or timeline to point to if the vendor is slow — which is exactly the gap a negotiated exit clause exists to close before you are in this position.
If a vendor refuses a reasonable data-return request or otherwise breaches the agreement, that may be an ordinary contract claim — but it is not one you can sit on. “Ontario’s general limitation period for most contract claims is 2 years from when you discovered the problem, with an outside limit of 15 years… the clock can start running sooner than people expect,” so treating a vendor dispute as something to deal with “eventually” risks losing the ability to act on it at all.
The two-year/fifteen-year framing traces to three specific sections of Ontario’s own Limitations Act, 2002: s. 4 sets the basic two-year period running from discovery, s. 5 defines when a claim is discovered, and s. 15(2) caps any claim at fifteen years, stating “no proceeding shall be commenced in respect of any claim after the 15th anniversary of the day on which the act or omission on which the claim is based took place” — regardless of when it was actually discovered. Treadstonelaw’s summary above is a fair reading of those three sections, not a paraphrase to take on faith.
A model change at the vendor does not change your own obligations for the client data that has been running through the tool. The PIPEDA vendor-accountability rule still applies exactly as it did before the change: “an organization is responsible for personal information… including information that has been transferred to a third party for processing,” regardless of what the vendor did to its own product underneath that processing relationship. If a model change also changes how or where the vendor processes data — a new sub-processor, a new hosting region — that is worth re-checking against your own accountability, not just against how the output reads.
Related: the questions to ask a vendor before this problem exists, not after, what a paid tier’s contract terms actually buy you.
That depends entirely on the specific contract’s terms around service levels and termination, which vary widely between vendors. There is no general Canadian rule entitling you to a refund for a model change — check your specific agreement, and raise the issue with the vendor directly if it is not addressed.
No — the risk is manageable, not a reason to avoid the category. The practical response is checking exit terms before you build a heavy workflow around any one tool, and keeping your own records and templates in a format you control rather than only inside the vendor’s platform.
Generally yes, for tax purposes switching vendors is an ordinary business expense like any other software change, though the specifics depend on your own accounting treatment — that is a question for your accountant, not a legal one this hub answers.
Related but distinct — a vendor shutting down raises the same data-return urgency plus insolvency complications that can restrict access to your data during proceedings. Some businesses negotiate data-escrow arrangements for mission-critical tools specifically to cover that scenario.
Document exactly what changed and when, with examples of the old and new output side by side — that record is what supports either a vendor conversation or a later contract claim. Then check your own contract’s notice and termination terms before assuming you have to live with the new behaviour indefinitely.
We can help you check what you would actually be entitled to if the tool changed under you tomorrow.
