Never build a critical workflow on a model you don't control

The AI you build on is not yours. You rent it. For a small business, avoiding AI vendor lock-in is the difference between a calm month and a scramble, because the company you rent from can change the terms, change the behavior, or shut the whole thing off, usually with little warning and never on your schedule. Most teams have not priced that in. They wire a model into something that matters, watch it work for a few months, and quietly start treating it like permanent infrastructure. It is not.

Models get restricted. They get deprecated. They get re-aligned so that the same prompt that worked in March returns something different in September. Sometimes a provider pulls a capability because a regulator pushed, or because the safety team decided it was too easy to misuse, or because a licensing fight went sideways. From where you sit as the operator, the cause does not matter. The effect is identical: a dependency you did not own just walked out the door, and your workflow broke at the worst possible moment, which is when a customer is waiting.

Renting is fine, pretending you own it is not

There is nothing wrong with renting capability. Almost no small business should be training its own model. The mistake is forgetting that you are renting, and building as if the lease will never end.

When you connect a model to a support flow or a draft generator or an internal research tool, you are making a quiet bet that the exact thing you call today will still be there next quarter, behaving the same way, at the same price, under the same rules. That bet has been mostly safe for a couple of years, so people stopped noticing they were making it. The day it stops being safe, you find out fast, and you find out in production.

Separate the job from the tool

The single most useful habit here is to write down what each AI step is actually for, in plain language, before you write the integration.

"Summarize this ticket into three bullets a human can act on" is a job. "Call this specific model's API" is an implementation detail. When you know the job, you can find another tool to do it. When all you have recorded is the API call, you are stuck the day that call stops working. This sounds obvious and almost nobody does it, because in the moment the API call feels like the real thing and the job feels like a comment you can skip.

Keep your prompts and your business logic separate from any one provider. If swapping models means editing a config file and re-running your tests, you are in good shape. If it means a two-week migration through code that has the provider's name baked into a hundred places, you have a fragility problem hiding in your codebase that you will discover at exactly the wrong time.

Build an eval set before you need it

Here is the move that pays for itself the first time you use it: keep a small folder of real inputs paired with the outputs you consider good. Fifty examples is plenty to start. These are your actual tickets, your actual emails, your actual documents, with the answers a competent person on your team would sign off on.

The day a model gets pulled or re-aligned and you need to test a replacement, you want to run all fifty through the new option in an hour and read the results, not eyeball three and hope. An eval set turns "which model should we switch to" from a panicked guess into a quick measurement. It also catches the quieter danger, which is a provider silently changing a model's behavior under you. If last month's good outputs start failing this month, your eval set tells you before your customers do.

Keep a fallback and keep a human

Two cheap insurance policies. First, have a second provider that can do the same job, even if it is a little worse, wired in behind the same internal interface so you can flip to it. You do not need it running daily. You need it ready.

Second, keep a person reviewing anything that reaches a customer. If a model vanishes overnight and a human was already checking the output, the event is an inconvenience: that person falls back to a weaker tool or does it by hand, and the business keeps moving. If you removed the human because the model seemed good enough, you built a single point of failure and handed the off switch to a company whose priorities are not yours.

Pull up every place you depend on AI and ask one question per integration. If this exact model disappeared tomorrow, what breaks, and how fast could I swap it? Wherever the honest answer is "I don't know," that is the integration to harden first. Plan for the model you love to leave, because eventually it will, and the teams that planned for it will barely notice.

Related reading

- [Don't marry one AI coding tool. Run several and route the work.](04-route-work-across-ai-tools.md)

- [Leaderboard rankings won't tell you which AI fits your work](07-benchmarks-vs-workflow.md)

- [The narrow base every AI tool quietly sits on](19-ai-infrastructure-concentration.md)