Every AI strategy deck I have seen in the last year has a slide that says "model-agnostic" or "we can swap providers at any time." It is a comforting line, and in most cases it is not true. The gap between the claim and the reality is exactly what a board should be poking at, before it becomes a footnote in a post-mortem.
Strip away the logos and the wrappers, and the overwhelming majority of serious AI capability in production traces back to a very small number of frontier labs. Call it three, give or take, depending on how you count. The SaaS tool, the copilot, the agent platform you bought: each is very often a thin layer over one of those labs' APIs. So when you tell yourself you have a diversified AI supply chain, what you may actually have is a diversified set of invoices pointing at the same two or three underlying models. That's not diversification. That's correlation wearing a costume.
The real mechanic: concentration stacks vertically, not horizontally
The instinct in vendor risk is to count vendors. We ask how many suppliers we have for a critical function, and we feel good when the answer is more than one. But AI concentration does not live at the horizontal layer where you are shopping. It lives vertically, all the way down the stack, and it compounds at every floor.
Start at the top. Your application vendors mostly resell a handful of foundation models. Those labs run on a startlingly narrow base of compute — one dominant accelerator vendor whose chips are the currency the whole industry trades in. Those chips are fabricated by essentially one company at the leading node, in one geography that carries its own geopolitical tail risk. And the whole apparatus depends on physical inputs that do not care about your procurement timeline: power, water for cooling, advanced packaging capacity, and mundane things like the helium and specialty gases that fabrication and cooling quietly rely on. When people say "AI is just software," they are skipping the part where software runs on a global physical supply chain with single points of failure at almost every layer.
So the honest map of your AI dependency is a narrow column, not a wide row of vendors. And a narrow column means a disruption at any floor — a lab changing its terms, a chip allocation crunch, an export-control shift, a packaging shortage, a regional event — propagates upward through everything you have built, regardless of how many vendor contracts you signed.
Index funds are quietly force-feeding the concentration
There is a second-order effect that does not show up in a security review and absolutely belongs in a board conversation, because it shapes whether this concentration eases or intensifies. The capital flooding into this space is not, for the most part, discerning capital making bets on the best architecture. A lot of it is passive: index funds and the retirement accounts behind them, mechanically buying the largest companies because they are the largest companies.
That matters for resilience because it removes the market pressure that would otherwise fund alternatives. When capital flows to incumbents automatically rather than on merit, the second and third sources you would want for a healthy supply chain get starved of the oxygen they need to mature into real options. You cannot assume the market will sort out diversity when the dominant flow of money is a thermostat set to "buy whatever is already biggest."
I am not making a market-timing call. I have no idea what any of this is worth, and neither does anyone telling you they do. The point for an operator is narrower and more durable: the conditions that produced the concentration are self-reinforcing, so betting your roadmap on it dissolving on its own is not a plan.
Financial services already named this risk
I run security and DevOps for a company that serves more than 1,500 financial institutions, and the mental model I keep coming back to is one regulators have drilled into financial services for years: concentration risk, and concentration in critical third parties. We already know how to think about this. If every bank in a region clears through the same one processor, the system is fragile no matter how solid any single bank is. AI concentration has the same shape, just earlier in its regulatory life. The frameworks are not new. We simply have not pointed them at the model layer yet.
The trap I watch teams fall into is treating model access like electricity — assumed, fungible, always on, priced per unit. It is closer to a specialized commodity with a fragile supply chain and a counterparty who can reprice, deprecate, or restrict you with a changelog entry. Model deprecation alone is an operational risk most shops have never rehearsed. The exact model your prompts, evals, and fine-tunes were built around gets retired, and your "drop-in" replacement behaves differently enough to break things your tests do not catch. That is a Tuesday, not a hypothetical for the future.
The questions a board should be asking now
I try not to write bullet lists, but governance questions are the exception, because a board's power sits in the questions it forces management to answer in writing. So here is what I would want on the table:
- What is our true upstream count? Not how many AI vendors we pay, but how many distinct foundation labs we actually depend on once you trace through the wrappers. Make management draw the vertical column, not the horizontal row.
- What breaks, and how fast, if our primary model is repriced, rate-limited, or deprecated? If the answer is "we'd switch," demand the rehearsal rather than the assertion. A failover you have never executed is a hope, not a control.
- Where are we exposed to the physical layer? Compute allocation, regional dependency, supply constraints we do not control. We do not have to solve geopolitics, but we should know which roadmap commitments are silently leaning on it.
- What's our portability cost, in real terms? Prompts, evals, fine-tunes, and agent scaffolding are switching costs masquerading as productivity. Measure them before you need them.
- Are we designing for substitution, or for lock-in? Abstraction layers, an internal eval harness that is model-independent, and at least one credible second source kept warm. These are cheap insurance now and impossible to retrofit during a crisis.
None of this is an argument against using frontier AI. I use it, I ship it, and the capability is real. It is an argument against confusing access to a thing with control over it. The companies that come through the next few years intact will not be the ones who picked the "right" lab. They will be the ones who assumed every layer of the stack could fail and built so that no single failure took the roadmap with it.
So here is the challenge for the next board meeting. Stop accepting "model-agnostic" as a statement of fact and start treating it as a claim that has to be proven. Ask management to demonstrate the switch, not describe it. If they cannot, and most cannot yet, you have just found the most important item on the AI roadmap, and it is resilience rather than a model.