A decade ago, one of the recurring headaches for CIOs was ECM lock-in. Migrating from a document management system meant migrating decades of content, reconfiguring workflows, retraining users and, in most cases, accepting that the cost of leaving would exceed the benefits of switching.
Today, the same problem is reappearing, but no longer around the document management system—it is happening around Artificial Intelligence. Many organizations are building their document processes on a single AI provider and discovering too late that changing models means redoing a significant part of the work already completed.
An organization that has built its extraction processes, assistants, agents, and knowledge bases around a single family of models—whether Gemini, OpenAI, Anthropic, or another provider—may discover months later that switching providers costs almost as much as changing ECM platforms did in 2015.
But this is not the only problem or limitation faced by a company tied to a single AI provider for document management. Teams should also be asking questions such as:
The key question is: does your document management system allow you to choose or change the Artificial Intelligence model or technology for each use case?
Multi-LLM document management platforms are the architectural answer to this problem. A multi-LLM document management platform abstracts the Artificial Intelligence engine behind a common layer, allowing customers to choose between multiple providers through configuration. Above all, a multi-LLM document management platform ensures that switching providers does not require rewriting prompts, templates, or workflows.
This article explains why this matters, what it really means to be multi-LLM, which layers beyond the LLM should also be interchangeable, and what questions you should ask your document management provider to determine whether it truly offers a multi-LLM document management platform.
In document management—as in many other types of software—the functionality offered to end users relies on a model that may be deployed as a service (OpenAI API, Claude Console, etc.) or installed on-premise (Ollama, etc.) to address a specific need: data extraction, classification, document chat, RAG, and more.
In theory, working with one option or another should be interchangeable: disconnect one and connect another. Or use one for a particular use case and another for a different one.
If switching providers were simply a matter of replacing an API key, every platform would already be multi-LLM. The reality is considerably more complex.
Although providers such as OpenAI, Gemini, Anthropic, or locally deployed models pursue similar objectives, the capabilities they offer and the way those capabilities are consumed are not equivalent. A multi-LLM document management platform must hide these differences behind a common interface so that an extraction, document classification, or RAG workflow does not have to be rewritten when switching providers.
Examples of capabilities that vary from one provider to another include:
In practice, functionality developed around the specific capabilities of one provider often becomes coupled to that provider. Replacing the model may require adapting the integration, reviewing prompts, modifying output schemas, or even redesigning part of the application’s logic.
Emerging standards do not yet completely eliminate these differences between providers. A good example is Model Context Protocol (MCP), a protocol designed to allow different AI models to discover and use tools in a standardized way. In theory, an MCP server should be usable interchangeably by OpenAI, Claude, or any other compatible client. In practice, however, implementation differences still exist. For example, during the discovery process for authenticated tools, Claude is more strict and expects the authorization server to publish its metadata according to RFC 8414 (OAuth 2.0 Authorization Server Metadata), whereas OpenAI may work correctly using only standard OpenID Connect (OIDC) metadata. As a result, an MCP server that works with one provider may require minor adjustments to interoperate with another, even though both claim to support the same protocol.
OpenAI, Gemini, and Anthropic can all produce structured responses, but they do not implement exactly the same standards or accept the same JSON schemas. A Pydantic model that works without modification with OpenAI may require simplification, removal of references ($ref), or provider-specific adaptations to work with Gemini.
Even when two models support the same functionality, they do not necessarily respond in the same way to the same prompt. Prompt effectiveness depends on the model, and prompts are not 100% interchangeable precisely because the capabilities offered by different services are not identical:
A document management platform is not truly multi-LLM simply because it allows multiple Artificial Intelligence providers to be configured. It becomes multi-LLM when customers can use the AI technology that best suits each use case without being constrained by the specific characteristics of a particular provider. In other words, the goal is not simply to support OpenAI, Gemini, or Claude. The goal is to prevent any technological decision regarding AI from propagating throughout the rest of the system.
When we introduced our first AI capabilities for document management, they were all built on OpenAI because that was the technology we were using at the time. However, we quickly discovered that our enterprise customers did not all share the same technology strategy. Some were more Google-oriented, others were Azure-oriented, while others required their documents to remain entirely within their internal perimeter. This diversity, together with our risk analysis, made us realize that the only sustainable approach was to build a document management platform that is agnostic regarding AI technology.
A multi-LLM document management platform requires a common layer that receives requests from functional components—extraction, classification, assistants, agents—and translates them into the language of the services offered by the selected provider.
The functional component does not know which model it is communicating with. This is very different from a catalog of “supported engines,” where each engine requires its own configuration and workflows are written against a specific engine.
At Athento, this layer is called Athenea. It abstracts OpenAI, Google Gemini, Azure OpenAI, Ollama, Hugging Face—and any other technologies that may come in the future—behind a consistent interface. The components that invoke Athenea—extraction operations, classification, conversations, agents—do not change when the engine changes.
Switching engines should be a configuration operation. Ideally, this should be configurable by team or knowledge base so that different use cases can operate with different engines within the same installation. If switching engines requires deploying code, it is not multi-LLM in any meaningful sense.
In fact, this approach is not new. At Athento, we have been applying it to other technologies such as OCR for years. Athento is agnostic regarding the OCR engine selected by the customer: Google OCR, Azure Vision, PaddleOCR, Tesseract, and others. We learned that OCR does not behave in the same way with every document, nor are process requirements always the same—confidential versus public documents, for example—so we needed to be able to offer different capabilities.
A multi-LLM document management platform should also abstract embedding generation. Although embeddings often go unnoticed, they are one of the most difficult components to replace in a RAG architecture because each model family generates incompatible vectors. Switching providers therefore usually means recalculating the entire vector index. The platform should therefore make it possible to use OpenAI, Gemini, Azure OpenAI, or open-source models such as Sentence Transformers interchangeably, allowing each knowledge base to evolve without becoming tied to a single provider.
Multi-LLM without multi-embedding is only half the answer. One of the biggest lock-in risks lies in the vector index.
When people talk about multi-LLM platforms, almost all of the conversation revolves around the generative model. However, a document AI project depends on many more components: the search engine, OCR, embeddings, and computer vision models. If any of these components is tied to a single provider, the lock-in problem is simply transferred to another layer of the architecture.
The semantic search layer is where much of the recurring cost of a document AI project is concentrated. A complete multi-LLM document management platform allows you to choose the search backend:
The difference compared with a provider that supports only one search backend can be financially significant.
Glean, Coveo, Mindbreeze, and similar products are powerful solutions, but using them as the exclusive backend for the semantic layer of your document management system introduces a recurring licensing cost that a multi-backend architecture can help avoid.
OCR is another layer where lock-in can become expensive.
A multi-LLM document management platform supports multiple interchangeable OCR engines—commercial OCR engines, cloud services, and open-source solutions such as Tesseract, PaddleOCR, Google Cloud Vision, Azure AI Vision, or ABBYY—and allows organizations to choose by document, document type, or team. This neutralizes OCR engine lock-in and enables hybrid strategies: local OCR for sensitive data, cloud OCR for high volumes, and specialized engines for complex cases.
The real value of a multi-LLM document management platform for customers is not that they design their processes around OpenAI, Gemini, or Claude. It is that they can build their processes on the document management platform itself, while the platform takes responsibility for translating operations to the corresponding AI provider and absorbing the differences between technologies.
This allows business logic—extraction processes, assistants, agents, or knowledge bases—to remain stable even as AI technology evolves. Switching models, introducing a new provider, or deploying a local LLM is no longer a development project and becomes, in most cases, a configuration and architecture decision.
This is the philosophy we follow at Athento, and it can be summarized by the concept of BYO AI (Bring Your Own AI). We believe organizations should have the freedom to choose the AI technology that best meets their needs, whether based on cost, performance, regulatory requirements, technology strategy, or data sovereignty.
To achieve this, the platform must take responsibility for continuous technical evolution:
This approach requires continuous investment from the software vendor, but it shifts that complexity away from the customer and into the platform.
The result is an organization that can adopt new Artificial Intelligence technologies at the pace of market evolution without having to rebuild its document processes every time a new model appears or the selected provider changes.
The question a CIO should ask is not whether OpenAI, Gemini, or Claude offers the best model today.
The real question is whether, three or five years from now, the organization will still have the freedom to choose the AI technology that best meets its needs without having to rebuild its document processes.
From this perspective, the value of a multi-LLM document management platform is concentrated in four areas:
The AI market is evolving rapidly. Prices per million tokens, available models, and commercial policies are constantly changing. An organization tied to a single provider can only benefit from these improvements if that provider decides to offer them. By contrast, a multi-LLM platform allows organizations to select the engine that offers the best balance between cost and performance for each use case.
Leading models change continuously. One provider may excel at document extraction, another at reasoning, another at multimodal processing, and another at on-premise deployments. A decoupled architecture makes it possible to incorporate these improvements without redesigning the solution.
An organization’s requirements can also change. A customer may require all information to remain within a specific country, models to run on its own infrastructure, or the use of a provider approved by the corporate group. When the platform abstracts the underlying AI technology, these changes can be addressed through configuration instead of new development.
Every technological dependency introduces risk. If a provider experiences an outage, changes its terms of use, withdraws a model, or stops operating in a particular region, a multi-LLM document management platform provides alternatives to keep AI-dependent processes operational. Business continuity no longer depends on a single provider.
The absence of a multi-LLM architecture is rarely noticeable on the first day. Its effects become apparent over time: higher operating costs because the organization cannot take advantage of competition between providers, greater difficulty adopting new models, less flexibility in responding to regulatory or commercial requirements, and increasing dependence on the technological and commercial decisions of a single vendor.
AI provider lock-in is likely to be one of the most underestimated technology risks of the coming years. The architectural decisions organizations make today will determine not only which models they use in 2026, but also their ability to incorporate new technologies, respond to regulatory changes, and control costs over the next decade.
The difference between a multi-LLM document management platform and one tied to a single provider is not simply the functionality available today. It lies in the freedom to adopt tomorrow’s model, infrastructure, or technology strategy that best meets business requirements without having to rebuild processes, assistants, knowledge bases, or integrations.
At Athento, we have designed our architecture around precisely this principle. Athenea acts as an abstraction layer between the platform and AI providers, making it possible to combine generative models, embeddings, OCR, search engines, and computer vision capabilities from different vendors within a single document management platform. The goal is not to commit to one specific technology, but to ensure that our customers can do so whenever they need to.
Because in a market where new models appear, prices change, and regulatory requirements evolve almost every month, the ability to choose is no longer merely convenient—it becomes a competitive advantage.
If you are evaluating a multi-LLM document management platform or want to understand how dependent your current architecture is on a particular AI provider, Athento can help you analyze it.
We will review your use cases, identify existing lock-in points, and show you how to build a more flexible and independent architecture that is prepared to evolve alongside the market and advances in Artificial Intelligence.
Request a personalized demo or talk to one of our specialists to evaluate your document AI strategy.
🤖Learn how to automate document management with ChatGPT by integrating it with Athento. Save time, reduce errors and improve your processes 🚀#Automation #ArtificialIntelligence.
Discover how you can chat with a PDF and get instant responses with AI. With Athento, you can chat with your documents and generate new ones automatically – transform your document management! 🤖🚀
Déjanos tus datos y te enviaremos el acceso por email
De conformidad con el art. 13 del RGPD y el art. 11 de la LOPDGDD, tus datos personales van a ser tratados por ATHENTO EUROPA S.L. con la finalidad de atender las consultas realizadas por los usuarios, siendo el consentimiento nuestra base legal para el tratamiento de tus datos personales. Sólo trataremos los datos que nos proporciones y podrán ser cedidos a terceros para poder cumplir la finalidad, como a ActiveCampaig u Open AI. Existen automatizaciones a través de Open AI, no obstante, hay intervención por lo que no se trata de decisiones automatizadas. Puedes ejercer tus derechos de acceso, rectificación, oposición, supresión, portabilidad y limitación de sus datos de carácter personal a través del email: dpo@athento.com. Puedes consultar la información adicional y detallada sobre Protección de Datos en nuestra Política de Privacidad.
