What happens if the AI provider I use in my business raises its price or shuts down?

A logistics client wrote to us a couple of months ago, pretty on edge: he’d read that a major AI provider had hiked prices for certain enterprise customers with no warning, and wanted to know if the same thing could happen to the assistant we’d built him for sorting delivery incidents. I told him the truth: yes, it could. We hadn’t talked about that risk when we signed the project. Neither had he. Neither had we.

Bringing an AI model into a business means taking on a new dependency, and a serious one. It’s not like depending on hosting, which you can swap out in an afternoon by copying files from one place to another. Once an assistant has been running for months on a specific model, the instructions you give it (the “prompt”) are tuned to that particular model’s quirks: how it reads dates, how much it rambles if you don’t set a limit, what examples it needs to stay on script. Switching providers isn’t swapping an API key. It’s re-testing half the assistant’s logic from scratch. In short: if your business depends on a specific AI provider and that provider raises its price, switches models, or drops support, migrating isn’t just swapping an API key — it’s reworking the prompt and re-testing a good chunk of the assistant’s logic.

It happened to us for real with an insurance client. The model we were using got deprecated in its old version, and we had three weeks to migrate the assistant to the new one, on a deadline set by the provider, not by us. The general logic still worked, but the tone changed: the new model was drier, gave shorter answers, and we had to rework the whole prompt to get it sounding like it used to. Three days of work nobody had budgeted for.

Since then I try to explain this on every new project that leans on AI in a serious way, not as a shop-window feature. Two things help a lot. One: don’t put business logic inside the prompt if you can avoid it. Hard rules (what price applies, what deadline has to be met) belong in ordinary code, and the model only handles the language part. That way, if the model changes tomorrow, what breaks is the tone, not the calculation. Two: write the code so that switching providers means swapping out one function, not rewriting the whole application. Nothing fancy, but few clients ask for it, because nobody’s told them they need to.

What I’m still not sure about is how much of this is worth building in from day one on a small project. That abstraction layer costs hours the client sees on the invoice, and for a simple assistant at a small business it might be paying for insurance you’ll never need to use. For the insurance client, looking back, it was worth it. For the delivery-incidents one, honestly, I still don’t know.