AI Providers as a New Concentration Risk: What DORA Means for Model Dependencies

Part 6 of 7 in our DORA series: Dependence on AI providers is not a remote risk for a later procurement cycle. It arises today as models, cloud access, data connectivity, guardrails, and operational knowledge merge without any prospect of switching. Following the articles on the DORA Exit Plan, cloud dependence of European banks, and the Register of Information, we therefore ask the question: How does a useful model integration turn into a concentration risk – and how does it remain manageable?

The model alone does not create the dependency

A bank does not just buy a model when it comes to AI. In a typical chain of use, model API, cloud infrastructure, vector search or other data components, security mechanisms, prompt and evaluation logic, and integration into business processes all come together. The more these levels are tailored to one provider and its proprietary interfaces, the higher the switching costs become. The dependency is thus technical, contractual, and organizational at the same time.

DORA provides a broad conceptual framework for this, but no sweeping labeling of every AI solution. Art. 3 No. 21 defines ICT services as digital and data services provided on an ongoing basis through ICT systems to internal or external users, with the sole exception of analog voice telephone services. Whether a specific AI service and its use fall under this definition must therefore be assessed based on the specific setup and the supported function. An explicit statement by the ESAs classifying AI or ML services generally as such is not required for this and is not available from the sources cited (DORA, Art. 3).

The decisive factor is the effect of the dependency. DORA defines an ICT concentration risk as an exposure to individual or multiple connected critical ICT third-party service providers, which creates a dependency and where an outage or disruption could jeopardize critical or important functions. The classification of a function – not the "AI" label – is thus the regulatory trigger. Part 7 of the series contextualizes this question for critical and important functions (DORA, Art. 3).

Concentration is quantifiably increasing

The warning is not abstract. The Financial Stability Board lists third-party dependencies and service provider concentration, market correlation, cyber risks, as well as model risk, data quality, and governance as AI-related vulnerabilities with the potential for systemic risks. The risk map thus includes not only model errors, but also the common technical foundation of many institutions (Financial Stability Board, 14 November 2024).

The finding on provider concentration is particularly clear. Based on a BoE/FCA survey, the share of the three largest model providers rose from 18% in 2022 to 44% in 2024. At the same time, the share of AI use cases implemented by third-party providers in the UK financial sector increased from 17% to 33%; foundation model use cases stood at 17% in 2024. These figures do not describe the overall European market, but they are a robust early indicator of how quickly external model dependencies can intensify (FSB Monitoring Report).

Concentration does not end with the model. The FSB views hardware, cloud, training data, and foundation models as relevant layers and describes hardware as the most concentrated part of the AI supply chain. Vertical integration can further increase switching costs. For risk management, it follows that: A mere list of model names underestimates dependency if the model, hosting, identity service, data access, and operations lie within the same supply chain (FSB Monitoring Report).

The ECB also separates two dimensions: technological penetration and vendor concentration. If new AI tools are widely deployed and vendors are concentrated, operational risks, including cyber risks, market concentration, and too-big-to-fail externalities, could increase, according to the ECB. It also warns that over-reliance on a few providers can make the operational backbone of the financial system more fragile – potentially leading to single-point-of-failure risks (ECB Financial Stability Review, May 2024).

Four levels that every institution should assess separately

Effective management begins with a simple decomposition. Not every level has the same owner, the same exit path, or the same risk impact.

This decomposition protects against a common fallacy: Multi-model usage is not automatically resilience. Two models with the same cloud or integration provider can still share the same outage or contractual dependency. Conversely, a single model in a clearly segregated architecture can be more easily replaceable than multiple models in an inextricable workflow.

The audit trail should therefore begin with the supported function. Which customer experience, decision, or internal activity depends on the AI component? What happens in the event of an outage, drop in quality, price, or contract change? Which data and configurations must be exported? And which alternatives have been tested under realistic quality, security, and latency requirements? This approach connects model risk with the exit logic from Part 2 and the supply chain perspective from Part 5, instead of dealing with both in separate committees.

Model-agnostic is an architectural principle, not a free pass

A model-agnostic architecture can reduce dependencies because it keeps models interchangeable and does not bind knowledge, contexts, and configurations to a single model provider. However, it does not replace risk analysis or testing. The switching option must be verifiable using representative tasks, protective measures, and operational processes; a simple connector to multiple models is not enough.

As a provider example, Acceleraid explicitly describes its GenAI approach as "model-agnostic" and "No vendor lock-in." The platform mentions the connection of existing Azure or Google Cloud contracts, any LLMs, and open-source models such as Llama and Mistral on its own infrastructure. For banks, this is a relevant design option: The interface to the business logic, the data preparation, and the governance can be separated from the specific model choice. It is not a promise that a switch will succeed in every use case without effort; rather, the architecture creates the prerequisite to test a switch in a planned manner in the first place (Acceleraid GenAI Enablement).

The article on AI personalization, EU AI Act, GDPR, and MaRisk deepens the governance perspective for customer-facing AI. In addition, Part 3 on cloud dependency shows that a model change is not sufficient if the surrounding infrastructure remains concentrated. Architectural decisions must therefore document both the model and cloud layers together.

Contracts, tests, and the AI Act belong on the same roadmap

If an outsourcing arrangement supports a critical or important function and is classified as an ICT service, Art. 30 para. 3 of DORA requires, among other things, full service level descriptions with quantitative and qualitative performance targets, contingency plans, ongoing monitoring, and exit strategies with a binding, appropriate transition period. These requirements can only be effectively met for AI if the institution knows and documents the technical dependencies before concluding the contract (DORA, Art. 30).

A useful test is not a theoretical contract review. For prioritized use cases, it should verify whether data and configurations are exportable, whether an alternative model can be reached through the same protection layers, and whether the business quality and security criteria continue to be met. The results belong in the outsourcing and register model: provider, supported function, subcontractors, data location, substitutability, test date, and identified limitations.

In parallel, the EU AI Act is creating a second governance timeline. The Regulation generally applies from August 2, 2026; Chapter V on General-Purpose AI has already been in force since August 2, 2025. Art. 53 requires, among other things, technical documentation, information for downstream providers, a copyright policy, and a summary of the training data. In the case of systemic risk, Art. 55 adds model evaluation, red-teaming, reporting of serious incidents, and cybersecurity measures (EU AI Act, Art. 113, 53, and 55).

For bank executives, this means: DORA and the AI Act are not competing checklists. DORA focuses on operational resilience and third-party dependency; the AI Act structures transparency, documentation, and obligations around general-purpose AI. A common inventory of models, providers, data flows, functions, and controls avoids double work – and makes real concentration visible.

The DORA Series at a Glance

• Part 1: DORA for Banks: What the EU Regulation rules and how it works

• Part 2: The Exit Plan under DORA: What it must contain and why it must be tested

• Part 3: Cloud dependence of European banks: How to get away from AWS, Microsoft, and Google in an emergency

• Part 4: Exit option for customer engagement workloads: Securing CDP, personalization, and campaigns in a DORA-compliant manner

• Part 5: The DORA Register of Information: Why it is actually a data quality problem

• Part 6: AI providers as a new concentration risk: What DORA means for model dependencies (this post)

• Part 7: Critical or important? Risk levels from Core Banking to CRM, Data Lake, and CDP

Illustration: AI-generated. AI-supported content: In creating our posts, we use AI technologies and automated agents, including those from Microsoft, Google, OpenAI, Anthropic, and other providers. Topics, professional orientation, and final approval remain with our team.