The AI boom and hidden concentration: many names, one shared risk

A current story, a general risk mechanism

The IMF's January 2026 economic commentary discusses the technology-driven boom and related risks. Its July 2026 discussion of AI and financial stability also examines vulnerabilities as adoption changes financial systems. These are dated institutional analyses, not a prediction that a particular asset or supplier will fail.

You do not have to take a view on whether AI is overvalued to inspect concentration. A technology can be useful and still create correlated exposures. Likewise, a good business can be a poor fit for a particular risk constraint. The exercise here is a dependency map, not a recommendation to buy, sell, or choose a particular allocation.

Count drivers, not just names

In the diversification simulation, change the relationship between outcomes while keeping the number of components in view. When outcomes move together, adding components provides less reduction in variability than independent outcomes would. The model's correlation settings are assumptions you choose, not measured forecasts for real securities.

Write down the drivers behind each exposure: demand, financing, regulation, geography, infrastructure, and the customers paying the bill. Look for repeated entries. A fund, a direct holding, and your employer's revenue can all create exposure to the same industry even though they live in different parts of your personal spreadsheet.

Use the same lens on operational resilience

A backup vendor is only partly useful if it shares the dependency that caused the primary vendor to fail. Two services may use the same hosting provider, authentication system, or upstream dataset. If the shared layer breaks, switching between brands may not restore the workflow.

Explore series and parallel reliability to see why the arrangement matters. The simplified reliability model assumes the stated relationships; it does not verify a vendor's architecture. Use it to ask which component is truly redundant and which remains a common point of failure.

A worked example: two AI writing tools

Imagine a team using two fictional AI writing services so it can switch if one becomes unavailable. Both rely on the same upstream model provider, and the team's login depends on one identity service. The second subscription protects against some app-specific failures, but not every failure. This is a teaching scenario, not a claim about any real product.

1. Map the path from the user to the final output: login, application, upstream service, stored data, and review process.
2. Mark the shared dependencies. Name one failure that the backup covers and one it cannot cover.
3. Test a small fallback, such as an approved manual workflow with accessible templates. Measure what can still be delivered and how long recovery takes.

An average can hide the scenario that matters

The antifragility experiment helps you inspect how different response shapes behave as variability increases. It does not establish the response of a particular market or business. The useful question is whether your plan has considered outcomes outside the range that feels familiar, and whether larger disruptions cause disproportionately larger harm.

Also inspect Gambler’s Ruin: some strategies become unacceptable because one path prevents you from continuing, even if the average outcome looks attractive. In an operational setting, that could mean being unable to serve a critical customer long enough to recover. Define the unacceptable state in concrete terms rather than using 'risky' as a vague label.

Make a one-page dependency map

Put exposures in rows and shared drivers in columns. Mark connections you know, and label uncertain ones as questions to investigate. Use an outage, a demand slowdown, or a financing interruption as a scenario. Ask which rows would be affected together and which fallback remains available.

Do not turn the map into an artificial precision score. A guessed correlation of 0.73 is not more honest than a clearly stated qualitative uncertainty. For a financial decision, personal circumstances and professional advice may matter. For a team, bring the map to the people who know the technical and contractual details before changing critical services.

• Look through funds and vendors to their underlying drivers.
• Mark shared infrastructure and customer dependencies.
• Define the disruption you cannot comfortably absorb.
• Test whether the fallback works under that specific scenario.

Resilience has a cost; perfect independence is rare

Duplicating everything can be expensive and create complexity of its own. Common infrastructure can also be efficient and reliable. The aim is to understand the tradeoff, not to eliminate every shared dependency. Start with the few disruptions whose consequences would be hardest to handle.

A practical review ends with one useful action: verify an unknown dependency, test a recovery process, or clarify which risk has been knowingly accepted. Adding another name to a list may feel like progress. Demonstrating that you can still operate when the shared driver fails is stronger evidence.