In mid-October 2026, US markets did something they had not done much of for two years: investors rotated out of AI stocks, on worries that the largest companies were overspending on infrastructure that would take longer to pay back than promised. Commentary about an "AI bubble" moved from the fringes to the front pages.
You do not need a view on valuations to take the lesson. Most businesses now run some part of their operation on AI products bought from vendors who are, between them, at every stage of financial health. Some are profitable. Many are subsidised by venture capital and priced to win share. Some will be acquired, some will change their pricing model, and some will close. Whichever way the market goes, a period of correction makes all of those more likely.
The question for an operator is simple: if your most important AI vendor changed its price, its model or its existence next quarter, what would happen to your business?
The short version
- The risk is not that AI stops working. It is that a specific product you depend on gets repriced, changes behaviour, or disappears.
- Subsidised pricing ends. Products priced below cost to win share will be repriced when funding tightens. Budget for it.
- Model changes are silent breaking changes. A vendor swapping the underlying model can change your outputs overnight, with no code change on your side.
- Own your data, your prompts and your test cases. If those live only inside a vendor's product, you cannot leave.
- Negotiate four clauses: data export, price change notice, model change notice, and termination assistance.
Which AI vendor risks actually matter?
| Risk | Early warning signs | Protection |
|---|---|---|
| Repricing | Seat pricing moving to usage pricing; "fair use" limits appearing; free tiers shrinking | Price change notice and caps in the contract; usage monitoring with alerts |
| Model change | Release notes mention new default models; output quality shifts without explanation | Contractual notice of model changes; your own test set run on every change |
| Acquisition | Hiring freezes, leadership changes, strategic partnership announcements | Change of control clause; data export rights that survive it |
| Shutdown | Product updates slow down; support response times stretch; funding news stops | Termination assistance clause; a tested exit plan |
| Data use | Terms updated to allow training on customer data | Explicit no-training clause; data residency and deletion commitments |
Not every vendor warrants all of this. Rank your AI tools by how much it would hurt to lose each one for a month, and apply the protection to the top of the list.
What should be in the contract?
Most small businesses click through AI vendor terms. For anything that has become part of how you operate, negotiate, or at least move to a plan where these are available.
- Data export. All of your data, including conversation history, configurations and any fine-tuning data, in a usable format, on request and on termination.
- Price change notice. A minimum notice period before price changes, ideally with a cap on increases at renewal.
- Model change notice. Advance notice before the underlying model for your account changes, and where possible the ability to pin a version for a period.
- No training on your data, stated explicitly, with deletion on request.
- Termination assistance. A period after termination during which your data stays accessible and exportable.
- Security and incident notification, the same as for any vendor handling your data. The NIST AI Risk Management Framework is a useful free checklist for what to ask.
Large vendors may not negotiate with a small customer. In that case, read their standard terms for these points and choose the plan tier that includes them.
How do you architect for portability?
If you are building on AI rather than just using a finished product, a few design choices keep you mobile.
Keep prompts, instructions and configurations in your own repository. Not only inside a vendor's dashboard. Version them like code.
Build a test set. A few dozen real examples, with expected outputs, that represent the work the AI does for you. Run it whenever a model or prompt changes, and whenever you evaluate a replacement vendor. Without it, you cannot tell whether a change broke something until a customer does.
Put a thin layer between your systems and the model provider. One place in your code where model calls happen means switching provider is a change in one place, not a project. This is ordinary engineering discipline, the same reason you would not scatter direct database calls through an application.
Prefer standard formats. Where a vendor offers a proprietary workflow builder, ask how you would recreate that workflow elsewhere. If the answer is "you could not", treat it as lock-in and decide whether the convenience is worth it.
We set out the broader version of this judgement in build versus buy: buy where the process is standard, build where it is the thing that makes you competitive, and in both cases keep the parts that encode your business in your own hands.
What does an exit plan look like?
For each critical AI tool, a single page that answers:
- What does this tool do for us, and what breaks if it stops?
- Where is our data, and how do we get it out?
- Which alternative have we checked, and when?
- How long would migration take, and who would do it?
- What would we do manually in the meantime?
Writing it takes an hour. Testing the export once takes another. Most businesses discover something important in that second hour.
Should you slow down AI adoption?
No. The tools that work keep working, and the businesses that use them well keep the advantage. The point is to adopt the way you would adopt any important supplier: with clear terms, a measured result, and a way out. Our piece on taking AI agents from pilot to production covers the measurement side, which is what lets you tell a vendor that is worth defending from one that is not.
Frequently asked questions
Are the big providers safer than startups?
Safer from shutdown, not from repricing or model changes. Large providers change models and prices too, and they are less likely to negotiate. Diversification and portability matter with both.
Should we use more than one model provider?
For critical workflows, being able to switch is more important than actually running two. Keep a tested alternative and a test set; you rarely need to run both in parallel.
How often should we review AI vendors?
Quarterly for anything critical, as part of normal vendor management. Check pricing, terms changes, model change notices and how often you hit limits.
What is the single most common mistake?
Letting the prompts, configurations and history that encode how your business works live only inside a vendor's product.
Where to go next
If something you depend on needs rebuilding with ownership and portability designed in, that is our custom software development work. For the operational side see AI agents and middle management, our notes on SaaS and technology, or talk to us.
