October 22, 2026

Three Types of Enterprise AI Lock-in and How to Avoid Them

Roger Wallman

Roger Wallman

Director, Product Marketing, Avaya

Steve Brock

Steve Brock

Senior Marketing Director, Avaya

Key Takeaways:

Real AI choice goes beyond selecting a model from a dropdown. It means being able to adapt or replace that model, reuse the workflows and integrations around it, and decide where it runs and under whose control. Open-weight models and open standards can expand those freedoms, but they do not automatically remove vendor dependencies.

Before committing to an AI platform, ask what it would take to change direction as your needs evolve. 

The freedom that matters is the freedom you still have after deployment.

Steve:  I was at an AI meet-up recently, following along as a presenter walked us through fine-tuning a model. Step by step, we worked through the exercise together. In less than 30 minutes, we had done it. 

Sitting there, I thought about what this means for the enterprises we work with. Adapting an existing model to a particular task is now something you can experience firsthand in a room full of curious people. This raises a bigger question for me: 

If a business can shape the intelligence itself, how much freedom does it have to choose where it runs, what it connects to, and when to replace it?

Suddenly, a dropdown of approved models feels like a very small part of the conversation.

The AI Decision You Need to Be Able to Change

Imagine choosing the chef for a new restaurant. You have an impressive shortlist, and every candidate can cook.

Then you read the lease. The kitchen only accepts one supplier's equipment. Your recipes cannot easily move to another location. You must prepare every meal in a facility someone else controls.

How much freedom did choosing the chef really give you?

Enterprise AI deserves the same scrutiny. A model dropdown tells you which intelligence is available today. It tells you much less about what happens when prices change, a better model appears, or your business needs a different operating arrangement.

There is a business reason to care. Stanford's 2025 AI Index found that the cost of querying a model with GPT-3.5-level performance on the MMLU benchmark fell more than 280-fold between November 2022 and October 2024. That is a specific benchmark comparison, but it illustrates how quickly the economics can change. 

Our takeaway is straightforward: the ability to adopt a better option has value. If the cost of switching outweighs the benefit, the option exists only on paper.

We believe enterprise leaders should test AI choice in three places: the model, the connections and workflows around it, and the environment in which it runs. A weakness in any one can limit the other two.

Lock-in #1: Model Lock-In Limits Your Ability to Change and Adapt AI

Model lock-in begins when replacing the intelligence requires rebuilding too much of the business around it. Prompts, evaluation criteria, integrations, and application logic can all become tied to one model's behavior.

A menu of supported models is useful. But choosing from that menu, connecting your own model, and operating a model yourself are different capabilities.

With model selection, you use the platform's supported options. With bring your own model, you connect an additional model or service through supported interfaces. With customer-operated AI, your organization, or an operator you authorize, runs the model under the controls you have chosen.

Open-weight models expand that last possibility. Their learned numerical parameters are available, allowing organizations to run and, where the license permits, modify a trained model. The company that created the model does not have to be the company operating it.

With Google's Gemma, organizations can adapt model behavior for a specific task, domain, or role such as customer service. OpenAI's gpt-oss models similarly support customization and deployment in an organization's own environment. These are concrete examples of model choice extending beyond access to a hosted API.

Think of fine-tuning as teaching an experienced chef your menu. You start with existing capabilities and use additional training to develop a specialist. You do not have to build a foundation model from scratch.

Training also differs from giving a model information. Retrieval-augmented generation, or RAG, supplies relevant material when the model answers. Fine-tuning changes learned parameters. In restaurant terms, one provides the recipe for today's order; the other changes the chef's training.

For an enterprise, the decision is practical. Does a general model handle the task well enough? Would better access to current information solve the problem? Do measurable improvements justify additional training?

We would test those questions against real work before adding complexity. A smaller, adapted model might be a good fit for a bounded task, but the answer belongs in your evaluation results. Switching will still require testing and sometimes prompt or integration changes. The goal is to make that work manageable.

Lock-in #2: Orchestration Lock-In Ties Your Workflows to One Platform

A chef cannot run a restaurant alone. Orders must reach the kitchen, ingredients must be available, and the right meal must reach the right table.

Enterprise AI needs similar coordination. A customer asking about a missing delivery may need an order lookup, a shipment check, a policy decision, a refund approval, and help from a person. A fluent answer is only one part of getting that customer a result.

Orchestration coordinates those steps. Lock-in develops when connections, business rules, or customer context become so dependent on one platform that they are hard to reuse or move.

Model Context Protocol, or MCP, helps by standardizing connections between AI applications and tools or information. Its architecture focuses on context exchange; it does not determine how applications use models or manage that context.

We therefore treat MCP as a useful connection standard, not proof that an entire application is portable. A common plug helps you connect kitchen equipment. It doesn't transfer the restaurant's operating procedures.

Ask to see which integrations another application could reuse and whether workflows, policies, and conversation records can be exported in usable formats. Identify the proprietary components that would need to be rebuilt. Then make the exit terms explicit: Which export formats are available? What fees apply to extracting your data? What transition assistance will the provider supply? How long will you retain access during migration? Put those commitments in the contract so you understand the effort, cost, and continuity involved in making a change.

This protects an often-overlooked investment: the knowledge your teams put into making AI useful. How you resolve an exception or hand a customer to an expert should remain valuable even as the underlying technology changes.

Lock-in #3: Deployment Lock-In Restricts Where and How Your AI Runs

Deployment lock-in occurs when your AI strategy becomes tied to an operating environment that no longer fits your requirements, with no practical route to change it.

Public cloud, private environments, and hybrid arrangements can each be appropriate. The key question is which arrangement meets the workload's needs and who controls it.

Start by separating who developed the model, who operates it, and where you process your data. These are different decisions. For example, a provider may use an open-weight model but host and manage it entirely on its own infrastructure. That gives the provider flexibility, but your organization’s control still depends on the deployment arrangement: who can access your data, who approves model updates, and whether you can move the workload elsewhere.

Then follow a conversation through the whole system. Where is the audio transcribed? Where do prompts and retrieved records go? Who can access outputs and logs? What happens if the primary service fails?

A model running inside your cloud account may still depend on external transcription, monitoring, or fallback services. That is why we would ask for a complete data-flow diagram before accepting a claim about private or sovereign AI.

The NIST (the National Institute of Standards and Technology) Generative AI Profile reinforces this operational discipline. Its suggested actions include identifying dependencies and fallbacks, continuously monitoring third-party AI systems, and testing fallback arrangements, including manual processing. 

Consider a bank designing a customer journey. It could keep a sensitive analysis task in a controlled environment, use an approved hosted service for public-information questions, and route consequential exceptions to a person. The connections and fallback arrangements would need careful testing: a failure must not silently send protected information to an unapproved service.

A model you can download for free isn't free to operate. Someone still has to provide the computing capacity, secure the environment, monitor performance, manage updates, and keep the service running when something fails. Those responsibilities carry real costs, whether your own team handles them or you pay a provider to do so. An enterprise can reduce its spending on model access and still spend more overall.

That is why the business case should compare the total cost of delivering a reliable service. Include infrastructure, specialist skills, ongoing testing, support, and recovery when things go wrong. Operating your own model may offer valuable control and attractive economics, but those benefits need to be demonstrated against your workload. The download price is the starting point for that calculation.

We Built Avaya Infinity to Keep Your Options Open  

Your next AI investment should expand what your business can do. Avaya Infinity helps enterprises modernize customer experience while building on the contact centers, systems, and processes they already depend on.

It brings together support for bringing your own AI, MCP-based integration, and cloud, hybrid, and on-premises deployment options. That combination gives enterprises choices across all three areas discussed here: the intelligence they connect, the integrations supporting it, and the environment in which it operates.

Those choices have practical business value. Bring-your-own AI lets you connect approved intelligence suited to your needs. MCP-based integration provides a standard way to connect AI applications with enterprise tools and information. Flexible deployment helps you align modernization with your operational priorities and data requirements. Together, these capabilities help protect existing investments while creating room for new ones.

Consider the customer calling about a missing delivery. Improving that experience requires intelligence connected to order information, shipment tools, business policies, and human expertise. Avaya Infinity brings those elements together through orchestration, helping your organization improve the journey while retaining valuable systems and relationships.

Supported models and features vary by configuration. The business goal remains consistent: introduce the capabilities you need today while preserving your ability to adapt as technology, economics, and customer expectations change.

Roger:  Picture an AI demonstration in which a customer calls about a delayed order. The AI checks the shipment, explains the options, and brings in a person with all the context they need. Everything works.

I’m already thinking about six months from now. A better model arrives, costs change, or the business needs a different deployment approach. How much of what we just saw could carry forward?

The team choosing that platform will also be responsible for improving it. They should be able to build on the work they have already done.

So when the presenter asks, “Any questions?” I’d start with: “That looked great. Now let’s change something.”

Three Things to Ask For in Your Next AI Demo

Change the model. Run a representative task with a supported alternative. Compare quality, response time, and total cost. Show the work required to switch and, where needed, demonstrate an approved customer-operated model.

Reuse a connection. Show how an external tool can serve another approved application. Export a workflow or its usable definition, identify what must be rebuilt, and explain the permissions and commercial terms involved.

Trace the data and test a failure. Follow an interaction through transcription, retrieval, model processing, storage, and handoff. Then demonstrate what happens when a service becomes unavailable. Confirm that fallback behavior respects the same data boundaries.

Those demonstrations expose what a feature list cannot: where choice is practical, where it requires engineering, and where dependencies remain.

We are not suggesting that enterprises change suppliers whenever a new model arrives. The point is to preserve the ability to act when the business case warrants it.

Before committing to an AI platform, ask: What would it take to change our minds? The quality of that answer will tell you far more than the length of the dropdown.

 

Your next AI investment should keep your options open. Explore Avaya Infinity to see how AI choice, open integration, and flexible deployment can help you modernize customer experience while building on the systems and investments you already have. Bring us the customer journey you want to improve, and let’s discuss what greater choice could make possible.

 

Frequently asked questions

What are the three types of enterprise AI lock-in?

Model lock-in makes it hard to change the intelligence. Orchestration lock-in ties your connections and workflows to one platform. Deployment lock-in restricts where and under whose control AI operates. Evaluate all three because flexibility in one layer does not guarantee flexibility in the others.

Is bringing your own model the same as running your own AI?

No. It can mean connecting to an external hosted service. Running your own AI means your organization, or an authorized operator, manages the model's execution in an agreed environment. Ask who controls updates, access, logs, infrastructure, and incident response.

If we fine-tune an open-weight model, have we trained our own model?

You have performed additional training on an existing model or its adaptation parameters. You have not created the underlying foundation model from scratch. The base model's license still matters. Adding documents through RAG or improving a prompt does not, by itself, constitute model training.

Does MCP eliminate vendor lock-in?

No. MCP standardizes connections for exchanging context with tools and information. It does not automatically make workflows, permissions, or stored context portable. We recommend checking what you can reuse or export and what remains specific to the platform.

Does self-hosting guarantee lower costs or better data control?

No. The result depends on workload, utilization, operating skills, and the full set of services involved. Compare total operating costs and trace every data path. Hosting the main model yourself doesn't determine where every other component processes information.

How is Avaya Infinity's approach broader than a model dropdown?

It brings AI choice together with MCP-based integration and flexible deployment. The value is in connecting those capabilities to a real customer journey. Validate the required models, features, data paths, and support responsibilities for your configuration.

What should we ask a provider to prove before we commit?

Ask it to change a model, reuse a tool connection, export a usable workflow definition, and demonstrate approved fallback behavior. Record the effort, costs, and limits. Apply that standard to every provider, including Avaya.