Three years ago, “which LLM does it use?” was the first question on every AI vendor call. The answer settled the deal. If the model was the right brand, the conversation continued; if not, it ended.
In 2026, the question has flipped. The first question is now “can you swap the LLM if we need to?”. The answer settles the deal in the opposite direction: if the platform is locked to one provider, the conversation slows down. If swapping the provider is a config change, the conversation moves.
Three things drove the flip.
1. Regulatory pressure made model provenance a board issue
The EU AI Act started its phased rollout. Provisions covering high-risk AI systems, model documentation requirements, and incident-reporting obligations now apply to a growing share of enterprise deployments. The specific requirement that affects vendor selection: regulated institutions need to be able to document which model produced a given output and, if a model is deprecated or withdrawn, demonstrate that they can substitute another model without breaking the audit chain.
A platform locked to one provider creates a regulatory single point of failure. If the provider deprecates a model the institution relies on, or the provider’s data-handling posture changes in a way that conflicts with FINMA / Swiss FADP / GDPR / HIPAA expectations, the institution needs a substitution path that does not require rebuilding the substrate. Bring-your-own LLM, as a substrate property, gives them that path. A roadmap item promising future model portability does not.
2. Vendor concentration risk hardened on the scorecard
Procurement teams have spent the last 18 months adding “dependency on single AI provider” as an explicit line item on the risk register. The framing is familiar: same conversation that ran in the cloud-provider single-vendor lock-in debate in the late 2010s, now with sharper teeth because the cost of being on the wrong side is higher (model swap is harder than database swap in most stacks).
The scorecard question on every AI vendor evaluation in 2026 reads roughly: “What is our exposure if this AI vendor or its underlying model provider changes terms, has a security incident, or is acquired?” The answer for a single-model platform is exposure. The answer for a BYO-LLM substrate is “documented substitution path, tested in development.”
3. The first single-model contracts came up for renewal
The 2024-2025 wave of AI platform purchases is now in its first renewal cycle. The CFO conversations are unfolding. The pattern that keeps showing up: the platform got locked to one model provider when the deal was signed, the model provider raised prices on the inference tier the customer was using, and the platform vendor cannot pass through to a cheaper provider because they were never built to.
The buyers who structured their original contracts around bring-your-own LLM are not having those conversations. They moved from a more expensive provider to a less expensive one in a quarter and kept moving.
What "bring-your-own LLM" really means at the substrate level
Most vendors will say they support multiple models. The procurement question is whether they support them as substrate properties or as configuration options on a primary path.
True BYO-LLM substrate properties
- Provider abstraction at the action layer. Every LLM call goes through a single caller helper that resolves the provider from configuration. Swapping the provider is a config change; no code on the action path references the model directly.
- Feature parity across providers. Tool use, structured output, citations, streaming, function-calling work identically regardless of which provider is wired. If one provider has a feature the others do not, the substrate either polyfills it or refuses to use it (the substrate does not become provider-specific because of one feature).
- Governance identical across providers. Source receipts, approval gate, audit log fire on every action regardless of model. The substrate enforces the same invariants on every provider.
- Model metadata in the audit log. Every LLM call records the provider, model, version, and parameters. The auditor can replay a specific action and see exactly which model produced which output.
- Self-hosted / private deployment supported. The substrate runs against Claude, OpenAI, Azure OpenAI, Anthropic via Bedrock, Anthropic via Vertex, plus open-source models hosted in the customer’s own environment. No model dependency forces a particular cloud provider.
What "we support multiple models" can mean instead
- The platform was built on one provider; secondary providers are exposed through a thin wrapper with reduced functionality.
- Switching providers requires a redeployment, a re-prompting pass, or a custom integration project.
- Governance behavior changes between providers (some skip the approval gate; some do not log; some lose source-receipt fidelity).
- The roadmap mentions provider portability but the current behavior is single-provider in production.
The difference is invisible on the demo call and decisive in the renewal conversation 18 months later.
How to test BYO-LLM before signing
Three questions to ask any vendor that claims BYO-LLM:
- Show me the production deployment where the LLM provider was swapped at least once. What changed in the config? How long did it take? Did any feature degrade?
- Walk me through an audit log entry for the same prompt run on two different providers. The schema should be identical except for the provider, model, version, and parameter fields.
- Show me a customer running this substrate with a self-hosted open-source model in their own environment, alongside another tenant running on a hosted provider. The substrate should not care.
A vendor that has done the work can answer all three. A vendor that has not will offer a roadmap on at least one.
Why Atlas treats this as a substrate property
Atlas was built with the assumption that the LLM market will reshape itself at least twice over the working life of a deployment. The provider abstraction is at the action layer, governance fires identically across providers, audit-log entries capture provider metadata, and the substrate supports hosted and self-hosted models in the same architecture.
The reason this is structural rather than feature-level: the substrate is the part that compounds in value over time (the knowledge base, the operator muscle, the audit-log history, the connector catalogue, the workflow inventory). The model is the part you swap when the market gives you a better option. If the substrate and the model are coupled, the substrate cannot compound because every model swap is a re-platform.
For the substrate definition, read What Is Atlas?. For the buying-side checklist that includes BYO-LLM as a substrate question, read The Agent-Deployment Buying Guide. For the model-portability comparison against Microsoft Copilot Studio, see Clarm Atlas vs Microsoft Copilot Studio.