AI Model Concentration Risk: Different Vendors, One Dependency

Three teams buy three AI products. Each has a different vendor, a separate contract and its own business owner. The supplier list looks diversified.

Then a model provider has an outage and all three products slow down or stop. What appeared to be three independent choices was one operational dependency wearing three logos.

AI model provider concentration risk is a portfolio question. You cannot answer it by reviewing each vendor in isolation. You need to see where the products converge, what would fail together, and whether an alternative can actually carry the work.

Key takeaways

• Separate contracts do not establish independent model or hosting dependencies.

• Map important AI applications across underlying providers, then group the business services exposed to each shared dependency.

• Concentration matters most where the service is important and substitution is difficult.

• A named backup is not a proven fallback. Check capacity, data handling, permissions and output quality before relying on it.

• The board should see the combined service impact of a shared failure, not only a count of vendors.

Step 1: Turn the application inventory sideways

An AI inventory usually starts with applications: who owns each one, what it does and which vendor supplies it. Keep that inventory, but add a second view grouped by upstream provider.

For each important application, identify the model provider, hosting dependencies and any other shared service that could interrupt its use. Label what is confirmed, what is vendor-reported and what is still unknown. Model routing may change, so record when the information was checked and who receives change notices.

Do not confuse a model family with a hosted service. Two products using the same model design might run on separate infrastructure. Two products using different models might still depend on the same cloud region. The failure scenario determines which relationship matters.

Step 2: Weight concentration by the business impact

A count of applications is a weak measure on its own. Ten optional writing tools may matter less than one application supporting a time-sensitive customer service.

For each shared dependency, ask which business services would be affected, how much work could be delayed, and how long the organization could operate without it. Include the teams that would absorb the fallback. If several applications all depend on the same small operations team during an outage, their manual plans may compete for the same people.

The Financial Stability Board has identified third-party dependencies and provider concentration as AI-related vulnerabilities in finance. Its analysis emphasizes the layered supply chain and the importance of criticality and substitutability. The same questions provide a useful management lens outside finance, without making financial-sector guidance a universal requirement.

Step 3: Test two different common failures

Start with a service outage at the provider supporting the most important workflows. Ask each business owner what stops, what continues and what competes for scarce staff. Add the impacts together before concluding that the fallback is adequate.

Then test a different kind of change: a model is retired, routing changes, a price increase makes the workflow uneconomic, or new terms require a fresh data review. These are not all availability incidents. They can still force several teams to change at once.

The exercise should produce decisions: an evidence request, a tested fallback, a spending choice or an explicit acceptance of the combined exposure. A map that produces no decisions is only a supplier chart.

Step 4: Prove the alternative before you depend on it

Ask what "we can switch" means in practice. Can the alternative handle the volume? Are the data use and retention terms acceptable? Does it support the permissions and integrations the workflow needs? Have representative outputs been checked against the service's quality requirements?

Moving a request to a different model can change its behavior. A technically successful switch is not enough if the new output fails the business task. Define who can authorize the change and what validation is required.

Nor does owning two contracts guarantee independence. Trace the alternative far enough to establish that it avoids the failure you are planning for.

Step 5: Make concentration a recurring decision

Assign an owner to the portfolio view and revisit it when an important application is added, a vendor changes providers, or a fallback test fails. Report the biggest shared exposures with their service impact, evidence gaps and next action.

The board does not need to choose models. It should know where several important services depend on one provider or failure domain, whether that exposure is deliberate, and what management has done about it.

A portfolio concentration matrix

This fictional matrix shows why the alternative column needs more than a vendor name. Provider and application labels are invented.

Application and service	Underlying dependency	Common failure exposure	Alternative and switching constraint
Support copilot / customer responses	Hosted Model A; Cloud Region X	Model service outage stops draft generation.	Human response queue tested for one shift; longer outages require extra staffing.
Claims summary tool / case preparation	Hosted Model A; hosting not confirmed	Same model outage interrupts summaries; regional exposure remains unknown.	Vendor offers Model B, but quality and data-processing terms are not yet reviewed.
Contract drafting tool / legal operations	Hosted Model B; Cloud Region X	A regional cloud disruption may affect this product and the support copilot together.	Approved template process available; throughput is lower and deadlines must be triaged.

A model-provider outage and a regional cloud outage produce different groups of affected services. That is why a single "diversified" label cannot describe the portfolio.

Sources

Financial Stability Board, Monitoring Adoption of Artificial Intelligence and Related Vulnerabilities in the Financial Sector (2025), section 4: FSB report. NIST, Generative Artificial Intelligence Profile (2024), value-chain and third-party fallback guidance: NIST AI 600-1. The matrix is fictional; recommendations outside finance are the author's application of the underlying risk questions.

Frequently asked questions

What is AI model provider concentration risk?

It is the exposure created when several applications or business services rely on the same model provider. One outage, retirement or material change can affect them together. Related concentration can also exist in hosting, regions, data and other supporting services.

Do different AI vendors mean we are diversified?

Not necessarily. Different vendors may use the same underlying model service or hosting environment. Establish the dependencies relevant to your failure scenario before counting those vendors as independent alternatives.

Does using open-source models remove concentration risk?

No. It changes the dependency picture. An organization may gain more control over the model while still depending on hosting, hardware, distribution, support or a small internal team. Map those relationships and test the operating model rather than treating the license type as a resilience guarantee.

What should the board ask management?

Which important services share a model or hosting dependency? What would fail together? Which alternatives have been tested, under what conditions? What combined exposure remains, and who has authority to accept it? Those answers matter more than the number of supplier logos.

Closing

Vendor diversity is visible in a contract list. Dependency diversity takes more work. Map the common providers, add up the business impact and test the alternative. That is how management finds out whether it has several ways to operate or several ways to fail together.