On 14 September 2026, ECB President Christine Lagarde stood in Vienna and made a point that every enterprise risk leader should read as a third-party risk statement. In her speech, A new age of capital: growth, sovereignty and AI, she noted that the United States hosts three-quarters of the world’s AI computing capacity while Europe hosts 5%, and warned that “a withdrawal of access, or a change in its terms, would then reach every sector at once.”
Her argument was about European sovereignty and the case for more regional compute and “good enough” domestic models. Strip away the geopolitics and what remains is a concentration statement. AI capability is being delivered by a handful of model providers, running on a handful of hyperscalers, in a handful of locations. Every enterprise that adopts AI at scale inherits that concentration whether or not anyone has written it down.
That is the gap this article addresses. Most AI risk registers assess the application: the chatbot, the copilot, the underwriting model. Far fewer assess what the application stands on. In Crest.Digital’s view, AI infrastructure is becoming a new category of critical third party, and the discipline that already manages critical suppliers, portfolio-level concentration analysis, needs to be extended to cover it.
Crest.Digital’s AI-powered TPRM platform tracks each vendor’s AI posture, monitors changes after onboarding and keeps an auditable evidence trail, so concentration is visible before it becomes an incident.
Explore the TPRM PlatformWhy a Central Banker’s Speech Belongs in Your Risk Register
Central banks do not normally comment on enterprise architecture, which is exactly why this matters. When the head of the euro area’s monetary authority describes access to AI as a source of leverage “no trade partner has ever held over Europe,” she is saying the dependency is systemic. For a bank, insurer or any regulated firm, systemic dependencies tend to become supervisory expectations a few years later.
Cloud concentration followed the same path. Regulators first observed it, then described it, then built regimes around it. The same sequence now looks plausible for AI. The Cloud Security Alliance’s June 2026 research on AI provider concentration cites an IBM survey in which 71% of respondents said switching their primary AI vendor would be difficult, 91% said they do not fully understand their AI dependencies and 81% said a seven-day vendor outage would cause severe or critical disruption. Treat those as one survey’s indicators rather than a benchmark, but the direction is hard to dispute.
The Dependency Chain Beneath Every AI Application
A useful way to expose hidden concentration is to trace one AI use case from the business process down to the physical layer. The chain below is deliberately simple. Run it for each material AI application and the overlaps between use cases become visible quickly.
AI Application to Model Provider
Which foundation model or API does the application call? Many apps in different business units quietly share the same provider, and embedded AI features inside SaaS tools add providers nobody contracted with. Our piece on the fourth-party AI model you never contracted with covers this layer.
Model Provider to Cloud and Data Centre
On which hyperscaler and in which region is the model served? Two providers that look independent on paper may run on the same cloud, so diversification at the model layer can still leave a shared infrastructure dependency.
Cloud to Geography and Jurisdiction
Where is compute located, and which legal regimes, export controls or access restrictions apply? This is the layer Lagarde’s speech brings into focus, and the one most often missing from vendor files.
Geography to Critical Process
Which important business services depend on the chain? Concentration only matters relative to impact tolerance: an AI summarizer is not a payments-screening engine.
Critical Process to Concentration View
Aggregate across the portfolio by provider, cloud and region. The result is a heat map showing how many critical processes would fail together.
Concentration to Exit and Continuity Plan
For each concentrated dependency, document the realistic exit path, the validated fallback, the data portability position and the time it would take. Then rehearse it.
Notice what this exercise does not require: a better model evaluation. It requires disciplined third-party and fourth-party mapping, the same capability described in our guide to fourth-party risk management. The difference is that AI adds new layers, such as model versions, inference regions and fine-tuned assets, that standard vendor questionnaires were never designed to ask about.
Crest.Digital’s TPRM Agents handle vendor outreach, questionnaire intelligence and continuous monitoring, while Agentic GRC extends the same approach to control testing, with human-in-the-loop review on every conclusion.
Regulators Are Already Designating Critical Technology Providers
The regulatory direction is clear even where AI is not yet named. Under the EU Digital Operational Resilience Act, the European Supervisory Authorities designated the first critical ICT third-party providers on 18 November 2025 and now oversee them directly for ICT risk management and governance. In the UK, the critical third parties regime became operational in July 2026 when four global cloud and technology providers were designated, subjecting them to FCA and PRA rules on governance, supply chain risk, cyber resilience and incident reporting.
Two points follow for enterprises. First, these regimes supervise the provider, not your use of the provider. Your own obligations, including identifying critical dependencies, testing exit plans and understanding concentration, remain with you. Second, designation lists are a signal of where supervisors see systemic exposure, and AI model and compute providers sit directly on top of those same cloud platforms. If you are already working through DORA third-party obligations or building operational resilience into TPRM, AI dependencies are the next scope extension, not a separate project.
What Belongs in an AI Dependency Register
A dependency register is the simplest artefact that turns this analysis into something auditable. It does not need new tooling to start, but it does need to be maintained as AI adoption moves. At minimum, each row should capture the application, its owner, the model provider and version, the cloud and region, the business process supported, the impact tolerance, the data classes involved, the validated fallback and the date the exit plan was last tested.
Three tests make the register worth keeping. Can it show, in minutes, how many critical processes depend on any single provider? Can it show which dependencies are unsanctioned, since shadow AI is also a shadow vendor problem? And is every autonomous agent in it, with an identity, scoped access and an audit trail? Internal audit teams applying the IIA Global Internal Audit Standards will recognise this as an ordinary assurance question applied to a new asset class.
A Six-Step Playbook for AI Concentration Risk
The playbook below extends an existing TPRM programme rather than replacing it. Start with the AI uses that touch critical processes, prove the method, then widen coverage as the register matures.
The Discover → Classify → Test → Diversify → Monitor → Report Model
- Discover: Inventory every AI application, agent and embedded AI feature, and record the model provider, cloud platform and hosting region behind each.
- Classify: Link each dependency to the business process it supports and the impact tolerance for that process, so criticality comes from consequence rather than spend.
- Test: Rehearse realistic scenarios such as a seven-day provider outage, a regional access restriction or a sharp change in terms, and record the result.
- Diversify: Where a process is critical, validate a secondary model or provider, an abstraction layer and provider-neutral data formats for the workload.
- Monitor: Track provider incidents, ownership changes, regulatory designations and contract events continuously, not at annual review.
- Report: Give the board and risk committee a concentration view by provider, cloud and geography, with owners and open exceptions.
Two cautions keep this proportionate. Diversification has a cost, and not every workload justifies a second provider; the point is to decide deliberately, by criticality, rather than discover the dependency during an outage. And exit plans for AI are harder than for conventional software, because prompts, evaluation sets and fine-tuned behaviour do not port cleanly. Provider-neutral data formats and an abstraction layer for critical workloads are inexpensive insurance, and the vendor exit and offboarding discipline you already apply to other suppliers is the right starting template.
For boards, the questions are short. Which AI providers and clouds do our critical processes depend on, and do any of them share an upstream dependency? How long would a switch take, and when did we last rehearse one? Who is told when a provider’s terms, ownership or regulatory status change? If the answers live in people’s heads rather than in a maintained register with evidence, concentration is still an unmanaged risk. Continuous vendor monitoring and AI-assisted due diligence, as described in our note on AI vendor due diligence, are what keep the answers current between annual reviews.
Crest Perspective
AI governance programmes that treat AI risk as a technology problem will be underprepared for the regulatory environment taking shape in 2025–26. The EU AI Act, NIST AI RMF, and emerging FCA guidance all frame AI risk as a governance and accountability question first — the technology controls follow from having clear answers to who is responsible, what decisions the AI influences, and what the escalation path is when the system behaves unexpectedly.
Frequently Asked Questions
AI concentration risk is the exposure an organization carries when many of its AI-enabled processes depend on the same small set of model providers, cloud platforms, data centres or geographies. It sits one or more layers below the AI application itself, which is why an AI risk register that only assesses the application can miss it. If one foundation-model provider has an outage, changes its terms or loses access to a region, every workload built on it can be affected at once. Treating the model provider, the hosting cloud and the compute location as separate dependencies, and mapping them to critical business processes, is the first step to measuring it.
On 14 September 2026, ECB President Christine Lagarde said in Vienna that a withdrawal of access to AI, or a change in its terms, would reach every sector at once, and noted that the United States hosts three-quarters of the world’s AI computing capacity while Europe hosts 5%. Her remarks were about European sovereignty, but the underlying point applies to any enterprise: AI capability is concentrated in a few providers and a few geographies. For risk teams the practical takeaway is to treat AI infrastructure as a potential critical third party with its own exit, resilience and geopolitical scenarios.
Financial regulators have started to put the largest technology providers inside the supervisory perimeter. Under the EU Digital Operational Resilience Act, the European Supervisory Authorities designated an initial list of critical ICT third-party providers in November 2025 and oversee them directly. In the UK, the critical third parties regime moved from legal framework to live designation in July 2026, with the FCA and PRA able to impose conditions or restrictions on designated providers. Neither regime replaces a firm’s own obligations: regulated entities are still expected to manage their dependencies, test exit plans and understand concentration.
A credible AI exit plan names the critical process, the provider and model it depends on, the maximum tolerable downtime and the fallback. It documents how data, prompts, embeddings and fine-tuned assets can be exported in provider-neutral formats, which secondary model or provider has been validated for the use case, and how long a switch would realistically take. Most importantly it is tested. A plan that has never been rehearsed against a realistic scenario, such as a seven-day outage or a regional access restriction, is an assumption rather than a control.
Crest.Digital’s AI-powered TPRM platform records each vendor’s AI dependencies, monitors changes after onboarding, and keeps an auditable evidence trail against every third party. Its agentic AI workflows chase evidence, track remediation and flag concentration patterns across the vendor portfolio, with human-in-the-loop review on every conclusion. For continuous testing of the controls around those dependencies, Crest.Digital’s Agentic Risk and Continuous Assurance practice builds customized agents around your systems and control environment.