Model Dependency: What It Is and How to Protect Your Business

What if the next AI upgrade is a downgrade for your business?

Every few months the AI labs ship a new model. Bigger context windows, stronger reasoning, higher benchmark scores. For researchers and developers, that progress is real. For a small business, the work AI does every day looks different: customer emails, proposals, quotes, summaries of messy notes, replies in the company’s voice. That work rewards a model that behaves the same way tomorrow as it did today.

Those two definitions of “better” don’t always point in the same direction. A model can score higher on every benchmark and still write emails that sound wrong for your customers, summaries that miss what your manager needs, and drafts that break a workflow your team spent months tuning.

Model dependency is a business’s reliance on a specific version of an AI model behaving in a specific way, inside work the business counts on. The model can change, degrade at your particular tasks, or be retired at any time, and the business has no vote.

How Model Dependency Builds Without Anyone Deciding to Build It

No owner sits down and decides to bet the company’s communications on one AI model. It happens in small steps. Someone finds that the model drafts a good follow-up email. A template gets built around that draft. The template becomes the sales process. Six months later, the tone of those emails, the structure of the proposals, and the shape of the weekly summaries all assume one thing: that the model keeps behaving the way it behaved when the workflow was built.

That assumption fails in three documented ways.

1Models Get Retired

Every major provider publishes deprecation schedules. A model your workflow depends on can be given a sunset date, and when the date arrives, the workflow migrates whether you’re ready or not.

2Models Get Replaced Abruptly

When OpenAI launched GPT-5 in August 2025, it initially removed the older models from ChatGPT in the same stroke. Users who had built habits and workflows around GPT-4o’s specific behavior protested loudly enough that the company restored it for paid users within days. The reprieve proved the point rather than refuting it: the model your work depends on can disappear overnight, and its return depends on someone else’s decision.

3Models Drift

Even without a version change, behavior shifts. Researchers at Stanford and Berkeley documented GPT-4’s performance on identical tasks changing measurably between March and June of 2023. The product name stayed the same. The behavior underneath it didn’t.

In each case the business experiences the same event: work that used to come out right starts coming out different, and nobody inside the company changed anything.

There’s an internet-era word people reach for when a product they rely on gets worse while the price holds: enshittification. Whether AI models are on that path is a running argument — labs cut inference costs, tune behavior, retire what’s expensive to serve. Model dependency needs no verdict on motive. It names the exposure: whether the model changes out of ambition, economics, or neglect, the business downstream absorbs the difference either way.

Same vendor. Same subscription. Same product name. And the ground still moves under your workflows.

Model Dependency vs. Vendor Lock-In

Model dependency is easy to confuse with vendor lock-in, and the difference matters. Vendor lock-in describes the cost of leaving a provider. Model dependency can hurt you while you stay.

How to Assess Your Model Dependency Risk

You can measure your exposure in an afternoon. Walk through the work your business produces in a week and ask, for each AI-assisted task:

• Behavior or ability? Does this task depend on the model’s exact tone, format, or judgment, or only on its raw ability? A calculation survives a model change. A voice often doesn’t.
• Revenue work or convenience work? Sales emails, proposals, and customer replies raise the stakes of a behavior shift far more than internal notes do.
• Who would notice drift? If the output changed subtly next Monday, who catches it, and how fast? A task nobody reviews is a task where drift compounds quietly.
• Could a new employee reproduce it? Can this output be recreated from written instructions and examples, or does the recipe live entirely inside one chat history and one model’s habits?

The last question is the sharpest one. If the answer is “it lives in the chat history,” the business doesn’t own that process. It rents it, month to month, from whatever model version happens to be running.

How to Protect Your Business

The protection is neither avoiding AI nor freezing on an old tool. It is moving the definition of good work out of the model and into assets the business owns:

• Written standards. What a good proposal, a good reply, and a good summary contain, stated in plain language a new hire could follow.
• An examples library. Your ten best real emails, proposals, and summaries, kept as files. Examples turn any model into your model, and they survive every migration.
• Review steps. A named person and a two-minute check for anything customer-facing. Reviews catch drift the week it starts instead of the quarter it costs you.
• A house style guide. The words your company uses and avoids, how it opens and closes messages, what it never promises.

A business equipped this way treats a model change as a Tuesday. Re-feed the standards, re-attach the examples, spot-check the output, and carry on. The workflow was never built on the model. It was built on documents the model gets pointed at. This is the same discipline a good AI Manual captures for a whole team.

The model will keep changing on someone else’s schedule. Your standards, your examples, and your house style change only when you decide they should.

Frequently Asked Questions

What is model dependency?

Model dependency is a business’s reliance on a specific version of an AI model behaving in a specific way, inside work the business counts on. When the model changes, degrades at those tasks, or is retired, the work breaks even though nobody inside the business changed anything.

Is model dependency the same as vendor lock-in?

No. Vendor lock-in is about the cost of switching providers. Model dependency can hurt you without any switch: the same provider updates or retires the model your workflows assume, and the outputs change under you.

Is model dependency the same as AI enshittification?

No. Enshittification describes a motive: a product degrading on purpose while its owner extracts more value. Model dependency describes your exposure, whatever the motive. A model that changes because of genuine progress can break your workflows just as thoroughly as one degraded to cut costs, and the protection is the same in both cases.

Does self-hosting or using open models solve it?

It reduces one form of the risk, since you can freeze a version you control. It doesn’t remove the deeper issue: if your standards and examples live only inside prompts and chat histories, your process still depends on remembered model behavior instead of owned documents. Most small businesses get more protection, faster, from writing their standards down than from changing infrastructure.

What should a small business do first?

Assess one week of AI-assisted work with the four questions above, then build the examples library. It is the fastest asset to create and the one that pays off on day one.