Short answer. AI vendor lock-in happens when a bank’s prompts, fine-tuned models, data pipelines, and compliance evidence are built so tightly around one provider’s APIs that switching costs more than staying, even after that vendor’s pricing, model quality, or regulatory posture changes. Banks avoid it with three controls: contractual exit and data portability clauses, a model-agnostic architecture that treats large language models as swappable components, and a documented DORA Article 29 concentration risk assessment before signing. In Ableneo’s 2025 portfolio, 94% of production AI projects used large language models across 4 countries, and none were built around a single, unreplaceable model provider.
Lock-in rarely arrives as a single bad decision. It accumulates. A bank fine-tunes a model on a proprietary provider’s platform and the weights never leave that platform. A team writes prompts tuned to one model’s specific quirks, so swapping the model breaks output quality overnight. A vector database ties embeddings to a proprietary format that a competing provider cannot ingest without a full re-embed. An evaluation harness is wired only to one vendor’s API, so nobody can benchmark a challenger model without weeks of rework.
Each choice is reasonable in isolation. Together, they raise the cost of leaving a vendor past the point where switching is realistic, which is precisely the condition Article 29 of the EU Digital Operational Resilience Act (DORA) requires banks to assess and document before signing, not after.
DORA, in force for EU financial entities since January 2025, treats ICT concentration as a supervised risk category, not a procurement footnote. Article 29 requires a financial entity to assess, before entering a contractual arrangement for a critical or important function, whether the provider is easily substitutable and whether multiple arrangements already concentrate exposure in the same or closely connected providers. A bank that cannot answer “who else could run this in 90 days” for its core AI vendor has an open finding waiting for the next DORA examination.
The European Central Bank made the same point directly for cloud and AI infrastructure in its July 2025 guide on outsourcing cloud services: supervisors now expect an ex-ante assessment of lock-in and concentration risk before signing, a tested exit strategy, and independent monitoring of the arrangement, not a policy document that gets written once and never revisited. For a bank running AI models on the same cloud and inference layer as its core banking system, concentration risk and vendor lock-in are the same conversation from two different regulatory angles.
AI vendor lock-in comes from three sources: model-specific engineering, data gravity, and operational dependency on the vendor’s team.
Three patterns account for most of it. First, model-specific engineering: prompts, fine-tunes, and retrieval logic hand-built for one model’s behavior rather than for a task, so a better or cheaper model cannot be dropped in without a rebuild. Second, data gravity: training data, embeddings, and evaluation sets live only inside the vendor’s platform, with no portable copy. Third, operational dependency: the vendor’s team, not the bank’s, holds the institutional knowledge of how the system actually runs, so even a technically portable system cannot move without the vendor’s cooperation. Any one of these is manageable. A bank that has all three has, in effect, outsourced its ability to change vendors.
DORA does not name AI models specifically, but it applies in full to any ICT third-party provider supporting a critical or important function, and a production AI system that touches credit decisions, fraud detection, or customer service qualifies. Article 29 requires a documented preliminary assessment of substitutability and concentration before signing. Articles 28 and 30 add mandatory contractual content: audit and access rights, data location and portability, service level commitments, and termination rights. The Register of Information, an annual DORA obligation, must list every ICT third-party arrangement supporting a critical function, including the AI vendor, in a form supervisors can inspect on request. A bank that has never documented which of its AI vendors are substitutable is not DORA-ready, regardless of how well the model performs.
Four clauses do most of the work. Data portability: the bank owns and can export all training data, fine-tunes, embeddings, and logs in a documented, non-proprietary format, on request, within a defined timeframe. Termination and transition assistance: the vendor must support a defined exit window, typically 90 to 180 days for a critical function, during which it continues service while the bank migrates. Audit and access rights: the bank, and its regulator, can inspect how the model is trained, monitored, and updated. No unilateral model substitution: the vendor cannot silently swap the underlying model version without notice and a re-validation window, since a swapped model changes behavior and resets the bank’s own testing evidence. A bank negotiating an AI contract without these four terms is negotiating price, not risk.
A model-agnostic architecture puts an abstraction layer between the bank’s applications and any specific model API, so the application calls a standard internal interface and the interface routes to whichever model, provider, or self-hosted deployment currently performs best on cost, latency, and accuracy for that task. Swapping a model becomes a configuration change and a re-validation cycle, not a rebuild. This is also why the EU AI Act’s emphasis on documentation and traceability works in a bank’s favor here: the same evaluation harness and logging built for AI Act conformity doubles as the benchmark suite a bank needs to compare a challenger model against the incumbent before switching. Architecture built once for compliance pays for itself twice.
Ableneo builds AI systems for banks and insurers with the assumption that the underlying model will change at least once during the system’s life, because it usually does. Across the 34 production AI projects Ableneo shipped in 2025, spanning 4 countries and 7 industries, 94% used large language models, and none were architected around a single provider with no exit path. That production discipline, not a vendor relationship, is what a bank is buying when it evaluates a partner rather than a tool. See Ableneo’s AI vendor evaluation guide for the fuller checklist used in client engagements.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.