Keeping your AI options open

AI has become important to many businesses very quickly, faster than the controls around it. Most of it runs on a small number of outside model providers. That makes a provider a supplier you depend on but cannot control. The steps that protect you are good practice anyway. This is about building resilience and control into how you use AI, so a change at your provider stays a small problem and does not become a crisis.

Businesses have always depended on things that can suddenly stop working. A cloud region goes offline for an afternoon. A single supplier raises its price at a bad moment. These risks are well known, and so are the ways to manage them. The model layer is the newest risk of this kind, and often the least examined, because it arrived fast and sits very close to the work. A model you depend on can be removed, repriced, or changed by the provider at any time. Treat it the way you would treat any important supplier. Understand the dependency, and have a plan for the day it changes.

Keeping your options open is a form of insurance. You pay for it in the quiet months, and you are glad to have it on the difficult day. The cost is real, and that is the point. Decide the price on purpose, based on what losing a capability would cost your business. If you do not, you learn that price during an outage, when it is highest.

Your model provider is a supplier you don't control

One provider for a capability your business depends on is a single point of failure. Models are retired. Prices change. A new version behaves differently from the one you tested, and a prompt that worked last quarter starts to give slightly wrong answers. None of this is unusual or hostile. It is normal for a fast-moving product. The real question is simple. When the provider changes something, does it reach you as a one-line setting change, or as days of urgent repair work?

Banks and insurers already treat this as a named risk. The EU's DORA rules ask financial firms to manage how much they rely on a small number of technology suppliers, and to make this a board-level concern. You do not need to be a bank to use the same idea. If a model sits under something important, name the risk and give it an owner before it surprises you.

What leadership owns

This is not a task for the technical team to take on by default because no one above them does. The build teams carry out the decisions. They should not be the ones quietly making them. Six decisions belong to leadership.

1. Name it as concentration risk.

   One provider for an important capability is a critical-supplier dependency. If you do not name it as one, it stays invisible. Match your controls to a published framework instead of inventing your own. ISO/IEC 42001 is the first certifiable AI management standard. The NIST AI Risk Management Framework is a widely used reference. Either one gives your teams a shared language and a checklist.

2. Map where AI is important.

   Make a list of the products, processes, and decisions that depend on a model. Mark which ones rely on a single provider, and which rely on one specific version. Keep this list up to date, with a named owner. It should be a living record, not a one-time audit.

3. Set a data policy.

   Decide what data may go to which providers, and where it may be processed. This is good GDPR practice. Put data location and processing terms in the decision from the start, not in a contract clause that someone reads later.

4. Write down your risk appetite.

   Decide which capabilities must have a tested backup, and how much of any single capability you are willing to run through one provider. If you do not write this down, every team argues it again, and the default choice wins. The default is usually the first provider you signed with.

5. Buy options at contract time.

   They are cheapest before you sign: the right to move your data and leave, clear data terms, advance notice before a model is retired, and no lock-in to closed formats. Check which EU AI Act duties apply to how you use AI, and take legal advice, because the timeline is still changing.

6. Give it an owner, and practise the loss.

   Name a senior owner. Put the risk on the register and the board agenda. Then run the exercise: your main provider is gone for a week, then for three months. One honest rehearsal teaches you more than a year of supplier promises.

All of this costs money, and that cost is useful information. Set the price for each capability, based on what losing it would do. Spend too little, and an outage sets the price for you. Spend too much, and you run backup systems that no one needs.

What engineering builds

Rules on paper mean nothing if the systems cannot follow them. The goal is not to stop using the best models. The goal is to make switching cheap, so you keep the best models for the few tasks that need them, and stay free to move for everything else. Here are the main steps, from simplest to hardest.

1. Do not hard-code the model.

   Choose models through configuration, by capability, never by a name written directly into the code. When a model is retired, this is the difference between changing one setting and releasing an emergency fix.

2. Send every request through a gateway.

   One place handles routing, backup, budgets, and logging. Run a gateway you host yourself, or one run inside the EU, if data location matters. A popular hosted router makes switching easier, but it adds an extra party you may not have planned for.

3. Keep a real backup, and test it.

   Have a second provider, or an open-weight model, ready and tested, with a test setup that works across providers. A switch you have practised is boring. A switch you have not practised is an emergency.

4. Separate planning from doing.

   Let your strongest model handle the difficult thinking, and pass the routine steps to a cheaper model you can replace. Your dependence on any single top model then shrinks to where it is truly worth the cost.

5. Keep European and open options available.

   Above modest volumes, or for more sensitive data, EU-hosted or self-hosted models become cheaper to run and easier to reason about. You do not have to start here. You do want the option to be there.

The two halves only work together

Leadership sets the risk appetite, the data policy, and the exit terms. Engineering builds the ability to switch and the backups that make those decisions real. On their own, each side fails in a familiar way. Leadership writes policies the systems cannot follow, or engineering builds resilience that no one will pay to keep. Together, with a record that names the risks and systems that can absorb them, a provider going offline becomes a small, contained event instead of a serious disruption.

None of this removes your dependence on these tools while they improve so quickly. It changes who controls the dependence, and how much warning a change must give before it becomes your problem. What you are buying is a buffer of days or weeks, in which a provider change is only an inconvenience. That buffer is cheap to build on purpose, and expensive to wish for during an outage.