Three AI Vendors, One Dependency

An organization deliberately spreads its AI usage across three providers. Different companies, different contracts, different model families, a primary and a fallback. The vendor list looks diversified and the exposure register records three suppliers rather than one.

‍

All three run inference on the same hyperscaler. The models differ and the infrastructure does not, so a regional failure at the layer nobody contracted with takes down the primary and the fallback together.

‍

Which Layers Are Concentrated?

‍

Three, and treating them as one risk is the error, because they fail on completely different timescales and only one of them is something an enterprise can act on.

‍

Infrastructure is the operational layer. Frontier model providers do not run their own large-scale server estates, so they contract with a small number of cloud companies for the compute their models require, which binds the model layer to the infrastructure layer commercially. A regional outage there is measured in hours and affects everything hosted in it.

‍

Accelerator supply is the strategic layer. The cloud providers depend on a small number of chip designers and a smaller number of fabrication facilities. The concentration is real, measured in quarters and years, and no enterprise procurement decision affects it.

‍

The Third Is Not an Availability Risk at All

‍

Model family concentration is about behavior rather than uptime. Several providers building on similar architectures and overlapping training approaches means a systematic weakness can appear across all of them, which matters for output quality and for adversarial robustness. It has nothing to do with whether the service responds.

‍

Why Is the Vendor List the Wrong Unit?

‍

Because it counts contracts and the failure happens at a component. Three suppliers converging on one dependency appear in a register as three entries and behave as one.

‍

The useful question inverts it. Rather than listing suppliers and checking none holds too much, ask what single component failing would stop all AI capability at once. The question reframes the exercise from enumerating vendors to enumerating single points, and the answer is frequently a cloud region, an identity provider or a gateway rather than a model company.

‍

Which Changes What the Register Records

‍

A field for the infrastructure each AI vendor runs on, alongside the vendor name. Two entries sharing that field are one exposure wearing two contracts, and concentration below the first tier behaves identically whether the shared component is AI-specific or not.

‍

How Do You Establish Where the Dependency Sits?

‍

Three routes, none requiring the provider's cooperation, which matters because a model company has little incentive to detail its infrastructure arrangements.

‍

• Where the endpoint resolves: Public naming and certificate data indicate the hosting provider and frequently the region, without asking anyone.
• Correlated incident history: Two providers whose status pages show simultaneous degradation share something, whether or not either will say what.
• The provider's own documentation: Data residency and region pages are published for compliance reasons and name the underlying platform more often than people expect.

‍

The second is the most direct and the least used. A year of status page history across your AI providers is a free dataset, and simultaneous incidents are evidence of a shared component that no questionnaire would have surfaced. An AI data fabric records which providers each workload reached, which is what the comparison needs on your side.

‍

Does Multi-Provider Help With Anything?

‍

Yes, and being specific about what prevents the strategy from being dismissed. It addresses two real risks and not the one it is usually sold against.

‍

Deprecation is the first. A provider retiring a model on its own schedule leaves anyone depending on it to migrate, and having a second provider already integrated turns that from a project into a configuration change. Deprecation running on somebody else's calendar is a genuine reason to hold more than one.

‍

Commercial leverage is the second. Pricing, terms and rate limits are negotiable where an alternative is already working and not where migration would take a quarter. Neither of those is availability, and presenting multi-provider as an availability strategy is what makes it disappointing.

‍

Which AI Uses Need Infrastructure Diversity?

‍

Fewer than most organizations assume, and sorting them changes the cost calculation entirely.

‍

An agent inside a customer-facing workflow that stops when inference stops is availability-critical, and diversity across infrastructure is worth paying for. A research assistant, a drafting tool or an internal summarization service degrades to people doing the work manually, which is inconvenient rather than material. Most AI usage in most organizations sits in the second category.

‍

What Does That Mean in Practice?

‍

Pay for genuine infrastructure diversity on the small set where an outage has consequences, and accept single-provider dependency everywhere else with the acceptance recorded. Spreading a thin diversification across everything costs more and protects the wrong things, and prioritizing by what each measure removes is the same reasoning applied to controls.

‍

How Should the Exposure Be Priced?

‍

Model the shared component rather than the individual providers, since the aggregate is what the correlation changes.

‍

Three vendors modeled independently produce three modest figures that sum to something manageable. The same three modeled as one dependency produce a single larger event, and the difference lands almost entirely in the extreme case rather than in the average. An organization reporting expected annual loss will barely see it, which aggregating without dependency applied covers as a general property.

‍

What If You Cannot Confirm the Dependency?

‍

Bound it. Run the aggregate assuming the providers are independent and again assuming they share infrastructure, and the width of the resulting range says whether the question deserves further work. Where the extreme figure roughly doubles, establishing the dependency is worth the effort. Where it barely moves, the diversification you have is adequate.

‍

What Happens When the Shared Layer Fails?

‍

Everything at once, and the response plan usually assumes otherwise. Continuity arrangements for AI dependencies are typically written per vendor.

‍

A plan stating that if provider A is unavailable the workload moves to provider B is sound where A and B fail independently and worthless where they do not. The failover is documented, tested against a single-provider scenario, and untested against the scenario that will occur. Testing the correlated case means simulating both providers unavailable simultaneously, which is a different exercise and one most organizations have never run.

‍

What Does the Fallback Have to Be?

‍

Something outside the shared layer, which usually means degrading rather than switching. A workflow that continues with a human doing the task, a cached response, or a rules-based path that produces a worse answer is a real fallback. Another model on the same infrastructure is not, and calling it one is what leaves the plan looking complete.

‍

Which Argues for a Specific Test

‍

Disable AI access entirely for one workflow and observe what happens. The exercise establishes whether the fallback exists, how long the workflow survives without inference and who notices, and it tests the correlated scenario rather than the independent one, which modeling an outage rather than a breach then prices.

‍

What Should Be Done This Month?

‍

Three steps, and the first is an afternoon.

‍

List your AI providers alongside where each one's endpoint resolves, which gives you the infrastructure layer without asking anyone. Pull a year of status page history and look for simultaneous incidents. Then sort your AI uses into availability-critical and everything else, so the diversification budget goes where an outage has consequences. An AI Interaction Data Fabric records which providers each workload reaches, which is the input the first step needs.

‍

Diversify at the Layer That Fails

‍

Three AI providers on one hyperscaler are one dependency with three invoices, and a vendor register counting contracts will not show it. The concentration exists at three layers that fail on different clocks, and only the infrastructure layer is both operationally relevant and something a procurement decision touches. Multi-provider strategies genuinely address deprecation and commercial leverage while doing nothing for availability, so presenting them as resilience is what makes them disappointing. Establishing the shared layer needs no cooperation, since endpoint resolution and correlated status history both reveal it. Kovrr's AI Security and Governance Platform records what each AI workload depends on, which is the unit the exposure sits in.

‍

To see which AI workloads in your environment converge on a single dependency, book a demo mapped to your own estate.