The Hidden Bill of AI: Vendor Lock-in

You know the energy of an AI project in its demo phase. A small team, a quick experiment, an impressive result. The monthly cost looks tiny, too: three hundred dollars, five hundred, maybe a little more.

Everyone in the meeting is smiling. “If it’s this cheap, let’s try it right away.” And at that stage it’s hard to object: the technical result is good, and the cost still feels more like coffee money than a budget line.

Six months later, as the same project nears production, the picture starts to change. The user base grows, the context gets longer, the number of calls multiplies, you hit rate limits, data location becomes a topic, and logging and monitoring requirements appear. Then, on top of everything, the provider announces that the model will be retired in a few months.

The technical team says, “The system works.” Finance says, “This isn’t sustainable.” The business says, “But we’ve built our process around it now.”

This is where the hidden bill of AI begins.

The model may be yours, but the decision isn’t always

When you connect to an API, it’s easy to think you’re buying a simple technical service. With AI, what you’re actually buying is more complicated: model behavior, a pricing regime, data processing terms, capacity limits, and the provider’s product roadmap.

Here’s the crucial difference: you use the model, but you don’t always decide how long it lives.

OpenAI’s deprecations page and Anthropic’s model deprecation documentation make this plain. Models change; some are shut down, others are replaced by newer versions. That’s normal in tech, but “normal” doesn’t mean “without consequences” for a business process running in production.

When the model changes, it isn’t only the endpoint that changes. Prompts need retesting, output quality needs re-measuring, security controls need another review, and integrations need watching. Sometimes even user habits shift.

That’s why vendor lock-in can’t be waved away with “we’ll just switch to another API.” The real dependency starts when the organization begins shaping its decisions and processes around someone else’s model calendar.

Why the bill doesn’t grow linearly

AI costs don’t behave like a traditional software license. Assuming that costs double when users double is usually misleading.

First, token consumption grows as usage patterns change. A system that summarized short texts in the demo starts handling long customer histories, documents, product catalogs, and conversation threads in production, and the cost of each call changes with it.

Second, model choices shift as quality expectations rise. A cheaper model may be enough for the demo, but production may require a more capable model, a longer context window, or lower latency. OpenAI’s pricing page and AWS Bedrock pricing show how widely these costs can vary, and data residency premiums come on top.

Third, in production you pay for far more than model calls. Monitoring, logging, security, data retention, evaluation sets, red-team testing, human review, and incident response all become part of the cost.

The real mistake is assuming the pilot cost is a small-scale version of the production cost. A pilot is usually just technical proof that something can work; it is not a cost model.

The real price: not being able to leave

The cost of working with a provider isn’t only incurred on the day you sign up. For me, the more important question is: what will it cost you when you want to leave?

If your prompts are written for one provider, your evaluation sets are tuned to one model’s behavior, your application layer is wired into one API contract, and your users have grown used to one model’s style of answering, then leaving may look technically possible, but it becomes operationally very expensive.

Much of that cost never shows up on an invoice. A release slips, the team spends three sprints on the migration, the business has to live with a temporary drop in quality, and legal and security ask for a fresh review. In the end, switching providers stops being a technical refactor and turns into a small internal transformation project.

That’s why, in AI, the cheapest way in can be the start of the most expensive dependency.

The biggest hidden line item: the project that never delivers

So far I’ve talked about the cost of systems that work. But the biggest line item on the hidden bill is the projects that are shelved without ever producing value.

The GenAI Divide, a 2025 study attributed to MIT’s NANDA initiative, found that most enterprise generative AI pilots either stalled at the pilot stage or never translated into measurable profit-and-loss impact. A caveat is in order: the study covers a short six-month window, and its authors present the figures as directional rather than precise. The finding should be read not as “AI doesn’t work,” but as a warning that poor data, unclear process ownership, and weak value measurement keep projects from reaching production.

Still, the direction becomes clearer when you set it beside other sources. Gartner predicts that through 2026, organizations will abandon 60% of AI projects that aren’t supported by “AI-ready data.” In the same research, 63% of organizations say they either lack the right data management practices or aren’t sure whether they have them. Gartner’s January 2026 analysis looked back and found that at least half of generative AI projects were abandoned after the proof-of-concept stage. The main reasons are familiar: poor data quality, inadequate risk controls, rising costs, and unclear business value.

What these numbers have in common is one of software’s oldest principles: garbage in, garbage out. However powerful the model, if it’s fed from repositories holding ten versions of the same document, from data sources nobody owns, and from unclassified archives, its output won’t be reliable. Nobody builds real work on unreliable output, and the project quietly gets shelved.

Translated into procurement terms: the provider’s invoice is only the visible part of the total cost. A business plan that ignores the cost of making data AI-ready (cleaning, classification, metadata, governance) has effectively volunteered for that 60% forecast.

Regulation has a price, too

Regulation also affects the cost of AI procurement directly. NIST’s Generative AI Profile recommends managing risk across the entire model lifecycle. And although the AI Omnibus, part of the broader Digital Omnibus simplification package, pushed back some high-risk deadlines, it didn’t remove the need for governance.

In Türkiye, the guidance from KVKK, the Turkish data protection authority, points in the same direction: it must be clear which data is processed for what purpose, where it is stored, who it is shared with, and what employees are allowed to do.

All of this is part of the procurement decision. Data residency, contract terms, audit rights, deletion guarantees, log access, notice of model changes, and exit support aren’t just legal clauses; they are decisions that shape your production architecture.

So “which model gives better answers?” is an important question, but not a sufficient one. You also need to ask, at the same time: “What costs and what dependencies are we accepting by using this model?”

So what should you do?

I don’t believe there’s a magic formula. Every organization’s risk profile, volume, regulatory burden, and technical maturity is different. But a few basic principles work almost everywhere.

First, abstract model usage away from application code as much as you can. A model router, a provider abstraction layer, or a shared evaluation layer may look like over-engineering on day one, but it will save you on the day you need to leave.

Second, make model retirement and version tracking an operational process. You should know in advance when a model will be shut down, which business processes it affects, and which tests it must pass before you move to its replacement.

Third, calculate costs for the production scenario, not the pilot. How many users will there be? What’s the average prompt length? What happens at peak load? What’s the retry rate? How much will logging and monitoring cost? What extra controls will regulation require? Until you can answer these, “the monthly cost is low” is wishful thinking, and that kind of optimism is exactly how many projects end up on the wrong side of Gartner’s 60% forecast.

Fourth, write technical reality into the contract: portability, change notification, data deletion, caps on price increases, audit rights, post-termination support, and, where possible, a transition period.

One last reminder: procurement isn’t just about choosing a single provider. According to Cyberhaven’s 2026 report, the median organization uses 54 generative AI tools, and the most advanced adopters use more than 300. Every unsanctioned tool brings its own contract terms and its own dependency risk. A central decision isn’t enough; managing the inventory is part of the job.

Wrapping up

In AI procurement, the first price is rarely the real price. The real price shows up when usage grows, when the model changes, when regulation kicks in, and when you want to leave. That’s why it’s no surprise that at least half of projects are abandoned after the proof-of-concept stage.

So the buying decision shouldn’t rest only on “which model is better?” The better question is: how much control do we keep while working with this model?

In the first article in this series, I treated ethics as a control architecture. Here we see the procurement side of the same issue. If you can’t leave your provider, can’t monitor the model’s behavior, can’t measure costs under production conditions, and your contract doesn’t protect you, a project that looks like a technical success can still leave the organization fragile.

In the next article, I turn to the most everyday form of that fragility: how company data quietly flows out through employees’ copy-and-paste habits.