Short answer. If your company built AI tools in the past year, they probably all call the same model supplier. That is fine for chat. For processes the business depends on, it is a supplier risk. You fix it with a second route to the same model, two extra columns in your AI register and one test before anything becomes critical. Do it before a buyer or an auditor asks.
How it happens
No board approves a single-supplier strategy for AI. It arrives one tool at a time. The first application calls the supplier whose kit was open that day. The second copies the first, because copying is quick. By the fourth, it has become the house style. And the house style has become a dependency.
You can't see it on an organisation chart or in a contract. It is one line in a configuration file.
The cheapest thing you built carries the deepest dependency.
Two kinds of use, two levels of urgency
These two get mixed up, and that leads to the wrong budget.
| People using chat and assistants | Automated processes and agents | |
|---|---|---|
| What happens when the supplier fails | Someone waits, or uses another tool for an hour | A process stops or fails quietly. Nobody notices until a delivery is late |
| What is at stake | One person's productivity | A business process, and the promises made to clients on top of it |
| When you notice | Straight away. The person tells you | Whenever someone happens to look |
| What to do | Nothing. Keep the tool | Stop calling the supplier directly from anything critical |
The fix is not to leave the supplier. It is narrower and cheaper than that.
The six-month test you already use
Most companies already ask one question of their important suppliers: could we change supplier within six months without losing the capability? If the answer is no, it is not a partnership, it is a dependency.
You probably ask it of your integrator, your software vendor and your agency. Almost nobody asks it of the AI model underneath their processes, because that never looked like a supplier. It looked like a feature.
What a gateway does
A gateway sits between your applications and the model suppliers. It sends each request to a suitable model. It switches to a backup when a supplier fails. And it keeps one log of what was sent, to which model, at what cost.
There are a few kinds: a hosted service, an open-source component you run yourself, a managed product with audit built in, or the routing inside a cloud you already use. Each has its own cost and its own dependency. The choice turns on one question that isn't technical: where may your data go, and who must be able to check it? Answer that first and the choice is easy. Answer it after the pilot and you will run the pilot twice.
The cheapest first step
There is a step you can take this quarter with almost no effort. Most leading models are also available through at least one large cloud provider, on separate infrastructure. Same model, different failure point, different contract. Often inside a cloud agreement you already signed.
Setting that up as a second route is a configuration change. It doesn't change your prompts or the quality of the output. It doesn't solve everything either: it buys time. Use that time to choose a gateway properly.
Two columns in the register
This does not need a new committee. If you run AI tools properly, you already keep a register: per application an owner, the data it touches and a risk class. Under the AI Act that register is your inventory.
Add two columns:
| Owner | Data touched | Risk class | Model supplier(s) | Backup tested on |
|---|---|---|---|---|
| Operations lead | Order data (read only) | Limited | Supplier A, supplier B | date of last test |
Then one rule: nothing becomes business-critical without a tested backup route. A documented one isn't enough. And one number for management, each quarter: the share of critical processes with a tested backup.
Why this belongs on the P&L
Supplier concentration has always been a due diligence question. What if the biggest supplier raises its prices, changes its terms or stops for a day? The model supplier is now one of those suppliers, inside the product rather than next to it. In most companies it isn't on the list yet.
A reviewer also looks for one pattern in particular: a product that is a thin layer over one public model, with no backup and no data of its own. Your company may be nothing like that. But the newest and least documented part of your systems can still read that way.
You price this dependency yourself, or a buyer prices it for you.
The limits
- A gateway adds a small delay and one more component to maintain.
- Spreading requests over several suppliers doesn't make the models equally good. One may simply be better at your task.
- It doesn't fix ownership. If the knowledge sits in one person's head, that needs a hiring plan or a contract, not software.
- It doesn't make a weak application worth keeping.
That includes us
NUVAI doesn't tie itself to one model supplier, for the reasons above. What you keep when we finish is the system in your own environment, its line in the register with the two new columns, and a team that can run it without us.