Vendor lock-in: when corporate memory becomes dependent on a proprietary AI engine

Large language models (LLMs) and hosted inference services have introduced a new type of lock-in: an organisation’s ability to store, retrieve, and use its informational assets depends on a proprietary AI engine. Often obscured by promises of productivity, this dependence raises technical, economic, legal, and strategic concerns. Decision-makers need to assess the risks, ways to mitigate them, and options for retaining control of their data and models.

Introduction – A decision that "remembers"?

Imagine a bank that, in 2022, entrusts an external provider with the automated analysis of its client contracts via a proprietary LLM. Within a few months, the legal teams have integrated this service into their workflow: obligation extraction, clause classification, and summary generation. The added value is undeniable; speed increases from several days to a few minutes.

Six months later, the same provider announces a 45% price increase and modifies its API, rendering the current integration obsolete. The underlying model evolves, embedding formats change, and the bank finds itself locked in: every update requires code, testing, and an additional budget that had not been planned for.

This situation illustrates vendor lock-in applied to corporate memory – namely, the entirety of structured or unstructured data, embedding vectors, fine-tuned prompts, and inference pipelines that constitute the decision-making foundation. Lock-in is no longer just an infrastructure problem: it affects the organisation's very capacity to exploit its informational assets.

In the following sections, we will analyse:

• What this type of dependency actually entails;
• Why this phenomenon is accelerating today;
• The technical mechanisms that create lock-in;
• The impacts on IT architecture, security, and compliance;
• The economic challenge of the "exit cost";
• Mitigation strategies;
• A concrete use case;
• Limitations and key points of vigilance;
• Operational recommendations for decision-makers.

1. Definition of AI vendor lock-in and corporate 'memory'

AI lock-in occurs as soon as any one of the following three dimensions becomes exclusive:

• Model – The LLM is not available as open source or cannot be exported (encrypted weights, restrictive licences).
• Access Interface – Proprietary APIs impose request/response formats and usage-based billing that cannot be replicated internally.
• Derived Data – Embeddings, search vectors, or fine-tuned models remain stored in the provider's cloud, with no possibility of raw extraction.

When these three components combine, the company's memory becomes physically and legally tied to the chosen AI engine.

2. Why is this subject crucial today?

• LLM Explosion – Since 2020, models containing more than 100M parameters have become commonplace; “foundation models” exceed 1,000M (e.g. GPT-4). Their ability to process free text makes the creation of “low-code AI” applications accessible to business units.
• API-based Economic Model – Most providers charge per request or token, creating a direct financial dependency on every service call.
• Evolving Regulations – GDPR, the Digital Services Act (EU), and the AI Act impose requirements for traceability, auditability, and data sovereignty that are difficult to satisfy with an opaque service.
• Competitive Pressure – Cloud players are integrating AI at the core of their offerings (AWS Bedrock, Azure OpenAI Service), making the choice of platform strategic for digital transformation projects.

In short, the decision to adopt a proprietary AI engine is no longer limited to a technical question: it becomes a strategic choice that shapes the operational and legal independence of the company.

3. Technical Lock-in Mechanisms

3.1 Proprietary Models and Non-exportable Weights

Providers encrypt model weights (e.g., OpenAI uses a proprietary 'OpenAI-Model-Blob' format). The lack of access to the binary file prevents any migration to internal infrastructure or another cloud, even if the contract permits the replication of business logic.

3.2 Proprietary APIs and data formats

Inference endpoints enforce specific JSON schemas (e.g., messages with system and assistant roles). SDKs integrate rate-limiting, billing, and usage tracking libraries that are not compatible with open source stacks such as LangChain or Haystack without adaptation.

3.3 Cloud-stored embeddings and vectors

Vector indexing solutions (e.g., Pinecone, Azure Cognitive Search) offer a managed service where LLM-generated embeddings are injected directly into a proprietary database. Most providers do not allow the bulk extraction of these vectors, making the reconstruction of an internal index prohibitively expensive.

3.4 Fine-tuning and 'customised' models

Fine-tuning via API (e.g., OpenAI fine_tunes.create) creates a derived model that remains hosted by the provider. Licences often prohibit the redistribution of the trained model, even when the training data is entirely proprietary.

3.5 Prompt management and reasoning chains

Organisations develop complex prompt libraries (e.g., retrieval-summarisation chains). These libraries become an intangible asset dependent on the exact behaviour of the underlying engine, which is difficult to reproduce if the model evolves or is deprecated.

4. Impacts on information systems architecture

These impacts force CIOs to rethink the IT system's trust zone and to integrate the AI provider as a critical component requiring the same availability, resilience, and compliance requirements as a transactional database.

5. Cybersecurity and Compliance Risks

• Leakage of sensitive data via prompts – Queries containing confidential information (e.g., account numbers) are transmitted to a third party. Even with TLS encryption, the provider may retain logs for model improvement purposes, creating a potential GDPR violation ("personal data processed without a legal basis").
• Limited traceability and auditability – Logs provided by the vendor are often aggregated (e.g., token counters) and do not allow for the identification of which user generated a specific response, complicating compliance with NIS2 or CNIL requirements.
• Data sovereignty – Services hosted outside the EU (e.g., OpenAI in the United States) may be subject to the CLOUD Act, granting government access rights without European oversight.
• Bias and legal liability – A proprietary model may generate discriminatory or erroneous responses. Legal liability then falls upon the user company, which has no control over training data or correction mechanisms.

These risks must be integrated into the IT risk register and addressed through precise contractual clauses (SLA, DPA).

6. Economic analysis – The real cost of lock-in

The Total Cost of Ownership (TCO) of a proprietary AI solution often exceeds the simple API consumption cost when these externalities are integrated.

7. Vendor lock-in mitigation strategies

7.1 Choosing open standards from the outset

• Exchange formats: JSON-LD, OpenAPI, ONNX for exportable models.
• Vector indexing: using libraries compatible with multiple back-ends (FAISS, Annoy, Milvus) rather than proprietary managed services.

7.2 Hybrid 'cloud + on-premise' architecture

Deploying a gateway that orchestrates calls to external APIs while maintaining an internal fallback layer with open source models (e.g., Llama 2, Mistral). This allows for rapid switching in the event of an incident or price increase.

7.3 Contracts and exit clauses

• Portability clauses: the right to full extraction of embeddings and fine-tuned models.
• Availability SLAs: financial penalties if downtime exceeds agreed limits.
• Log retention limits: the obligation to provide raw logs for a specified duration (e.g., 12 months).

7.4 Prompt and data governance

Maintain an internal catalogue of prompts, training datasets, and fine-tuning parameters within a secure Git repository. This ensures that business logic remains reusable even if the underlying engine changes.

7.5 Investing in internal skills

Train DevSecOps teams in MLOps (CI/CD pipelines for models) and the use of open-source tools (MLflow, DVC). Internal expertise reduces migration costs and increases bargaining power with vendors.

8. Real-world use case: a French bank and automated contract processing

Context

In 2022, the legal department of a large regional bank decided to automate the extraction of contractual obligations (termination clauses, penalties) from over 250,000 PDF documents. The project, named LexiAI, opted for the GPT-4 service via OpenAI API, coupled with Pinecone for vector search.

Implemented architecture

Read the diagram notation

graph LR
    A["Data Lake (On‑Prem)"] --> B[Pipeline ETL]
    B --> C[Extraction PDF → texte brut]
    C --> D[Embedding via OpenAI API]
    D --> E["Pinecone Vector DB (Cloud)"]
    E --> F["Service interne de recherche (REST)"]
    F --> G["Interface métier (Web UI)"]

• Data remains stored on-premises, but embeddings are created and hosted at Pinecone.
• Classification prompts are versioned in GitLab.

Review after 12 months

The vendor lock-in shock

In Q4 2023, OpenAI announced the deprecation of the davinci endpoint and a 40% price increase for 'gpt‑4‑turbo' models. Additionally, Pinecone introduced a new embedding format incompatible with previous versions.

Consequences:

• Re-engineering of the embedding pipeline (2 months of work, €80k).
• Contractual renegotiation with OpenAI, resulting in an exit clause but without the right to extract existing embeddings.
• Risk of loss of continuity for legal teams who relied on the service in production.

Lessons learned

• Vector portability: the lack of a full export blocked the migration to an open source engine (FAISS).
• Fixed-price clause: the variable pricing model generated unanticipated budgetary volatility.
• Prompt governance: prompts were stored in the repo, which facilitated the reconstruction of an internal pipeline after migration.

9. Limitations and points of vigilance

9.1 Points of vigilance

Domain — Risk — Mitigation

| Model bias | Discriminatory or inaccurate responses, legal liability. | Regular audits on sets of