Most vendor relationships in enterprise AI are built backwards.

The company doing the evaluation has a gap. They need a model. They look at the available options, pick one, and then manage the dependency.

That’s backwards from how it should work. The question isn’t “which model should we buy.” It’s “if we depend on this vendor, what are the constraints that creates, and can we live with them?”

This matters because vendor dependency is actually a governance issue, not a procurement issue.

The hidden constraints of vendor dependency

Here’s a scenario that plays out regularly: A company licenses a foundation model from a vendor. They build applications on top of it. The model works well. Everything’s good for two years.

Then the vendor updates the model. It’s a better model. Stronger performance. But it has different behavior characteristics. It generates outputs that are slightly different. The applications that were built on top of the old model have to be updated.

Or the vendor changes their terms. They used to allow you to run the model internally. Now they want you to use their API. You have to redesign your applications.

Or the vendor stops supporting the version you’re using. They want you to upgrade. The upgrade comes with changes you’re not prepared for.

In each case, the company that built the dependency is now constrained. The vendor changed something. The company has to adapt.

This is fine if you have one model. This is a serious problem if you’ve built dozens of applications on top of the model and that model is embedded in your decision-making processes.

Why this becomes a governance problem

Most companies don’t think about vendor dependency until it’s a problem.

They’re focused on the model’s performance right now. Does it do what you need? Does it have good accuracy? Is it cost-effective?

They’re not focused on the second-order question: What happens if this vendor changes?

By the time that question becomes urgent, the dependency is already deep.

I watched a company build a suite of applications on top of an open-source model. They contributed improvements. They optimized for their use case. Six months in, they had 12 applications in production, all depending on that model.

Then the model’s maintainers made a change. Not a breaking change, exactly, but a change that affected how the model handled certain types of input.

The company had to choose: Spend weeks updating all 12 applications, or fork the model and maintain their own version.

They forked. Now they’re maintaining their own version of a model that’s being actively developed by a community. Their fork diverges. Updates from the community have to be manually merged. New bugs come out of the original model. Do they apply those fixes to the fork?

Within two years, maintaining the fork cost more than building their own model would have.

The company wasn’t paying attention to the governance implications of the vendor dependency. They were paying attention to whether the model worked.

What questions actually matter

The evaluation criteria for any AI platform partner aren’t the ones most companies focus on.

Most companies ask: What’s the model’s accuracy? How much does it cost? What’s the API latency?

These questions aren’t aimed at any specific category of provider. They apply to every AI platform relationship—cloud services, open-source deployments, and proprietary APIs alike. You should also ask:

1) How often does this model change?

And importantly: How do you define a change? Is it just updates to the weights? Does it include changes to architecture? Changes to inputs or outputs?

If you’ve built applications that depend on specific model outputs, and the model changes behavior, your applications might break.

You need to understand the cadence. Is the model updated quarterly? Whenever the vendor feels like it? When there’s a major improvement?

2) What’s your path if the vendor stops supporting this?

Not “if they go out of business,” but if they decide to deprecate this model or change their business model.

Can you download the model and run it yourself? Are there licensing restrictions? If you needed to migrate to a different model, how long would that take?

If the answer is “you’d have to rewrite everything,” you should factor that into your decision.

3) What changes are backwards compatible?

If the vendor updates the model, will your applications still work? Or will you have to retest and redeploy?

Some vendors are thoughtful about backwards compatibility. Others aren’t. If you depend on them, you need to know.

4) What’s the data retention policy?

If you’re using their API, are they storing your data? For how long? What are they using it for?

If they’re using your data to improve their models, that’s fine — but you should know it and be comfortable with it.

5) What happens to my applications if you change your terms?

If they say “we’re discontinuing the API and you have to use our cloud service,” what options do you have?

If they change pricing dramatically, what’s your recourse?

Most vendors won’t want to answer this question directly. But you should ask it anyway.

The vendor as governance decision

Here’s why this matters at the governance level: When you decide to use a vendor’s model, you’re not just deciding on that model’s performance. You’re deciding to accept a set of constraints on your system.

You’re deciding to accept that this vendor can change how your model behaves, and you’ll have to keep up.

You’re deciding to accept that if the vendor’s business changes, you might have to change yours.

You’re deciding to accept that you’re dependent on someone else’s roadmap.

All of these are fine — dependencies are inevitable. But they should be explicit decisions, not accidental ones.

Organizations that handle this well usually:

Map the dependencies

They know exactly which applications depend on which models, and what would happen if those dependencies changed.

Diversify where sensible

If they have applications that could work with multiple models, they build for flexibility. They’re not locked into one vendor.

Maintain fallback options

They have a plan if the vendor changes. Maybe it’s “we’ll migrate to this alternative,” or “we’ll build our own version,” or “we’ll redesign the application.” But they have a plan.

Make it a deliberate choice

When they decide to depend on a vendor, they’re making an explicit decision about the constraints that dependency creates.

What to do if you’re already dependent

If you’ve already built applications on vendor models and you’re realizing the dependency is deep, you can’t undo it quickly.

But you can start:

1. Map the dependencies. Which applications use which models? What would it cost to migrate?

2. Start reducing dependency where sensible. Can you build flexibility into your architecture so you’re not locked into one model?

3. Ask the hard questions. Especially the ones about what happens if the vendor changes.

4. Make explicit decisions about where to accept dependency and where to avoid it.

The companies that end up in bad situations usually didn’t plan for vendor risk. They just picked a model that worked and kept building on it.

The companies that manage vendor relationships well ask the governance questions upfront. They know what constraints they’re accepting. And when things change, they’re not surprised because they planned for the possibility.