Your Website Now Depends on Five AI Vendors You Never Evaluated

Why this became a real question in 2026

In September 2026, four frontier models launched inside 72 hours. Prices moved again, capability tiers multiplied, and older versions continued to be retired on published schedules. If AI sits anywhere in your website or marketing stack, that pace is no longer someone else's news cycle — it is a dependency you are exposed to.

This is not an argument against using these tools. It is an argument for knowing what you are standing on, which most businesses currently do not.

Start with the inventory, because it will surprise you

Ask a business owner how many AI vendors their website depends on and the usual answer is one or none. The real number is typically three to six, because most of these dependencies arrive inside other products rather than as deliberate integrations.

The common ones: a support chat widget calling a model you never chose, site search with semantic ranking, a content or SEO tool, a personalisation or recommendation layer, form spam filtering, image processing, and an analytics product with AI summaries. Each of those vendors is itself calling a frontier provider, usually without telling you which one or which version.

That second layer is the part worth taking seriously. Your exposure is not only to the vendors you pay; it is to the providers they depend on, and a change upstream reaches you through a product that never mentions it. The exercise is to list every tool touching your site, and for each, find out which model provider sits behind it. Support documentation usually says, and where it does not, that opacity is itself a finding.

The four failure modes, ranked by how often they happen

Deprecation is the most common. Model versions get retired on published timelines. If something you built is tuned to a specific version, you inherit a migration on the vendor's schedule rather than your own. This is usually announced well in advance and ignored until it is urgent.

Price changes are next. They move in both directions — frontier inference has generally got cheaper per token while capability tiers have multiplied — but a change either way can invalidate the unit economics of a feature that was justified on a specific cost per interaction. Anything whose business case depends on a per-call price needs that assumption written down and revisited.

Output drift is the most insidious. A newer version behaves differently: different formatting, different tone, different edge-case handling. Nothing errors. The feature keeps working and slowly gets worse, and because there is no alert for it, the discovery route is usually a customer complaint weeks later.

Outages are the risk everyone plans for and the least frequent. They are also the easiest to handle, because failure is loud and a fallback either exists or does not.

Notice that three of the four are silent or scheduled rather than sudden. Business continuity planning built entirely around downtime addresses the least likely of them.

Containment that is worth the effort

The goal is not provider independence. Full portability across every model costs far more than it returns, and businesses that chase it end up with an abstraction layer more complex than the thing it protects. The goal is to keep switching costs bounded.

Put a thin layer between your application and the provider. One place in the codebase where the model is named and called, so changing provider or version is a configuration change rather than an excavation. This is a day or two at build time and it is the single highest-return item here.

Own your prompts and your evaluation cases. Prompts represent real accumulated work. Kept inside a vendor's interface, they leave with the vendor. Kept in your own repository alongside a set of test inputs and expected outputs, they become portable assets — and the test cases are what let you detect drift after an upgrade instead of hearing about it from a customer.

Keep the outputs. If a model generates content, descriptions, or summaries that your site depends on, store the results in your own database rather than calling live on every page load. This removes the runtime dependency entirely for anything that does not need to be fresh, which is most of it, and it is faster besides.

Write down the version. Whatever version you validated against, record it and the date. Six months later, when output quality is disputed, that note is the difference between a diagnosis and a guess.

Where the dependency should not be

The clearest rule we apply: nothing on the critical revenue path should have an AI dependency without a working fallback.

Checkout, enquiry forms, and the route to reach a human must work when a model is unavailable. If your contact page offers only an AI chat widget, a provider outage means you cannot be contacted at all — and you will not know, because the failure is invisible from your side. Support agents belong here too; the escalation design that matters for customer satisfaction, covered in whether an AI support agent is worth it, doubles as the fallback when the model is down.

The right home for AI is paths that degrade gracefully: search that falls back to keyword matching, recommendations that fall back to popularity, personalisation that falls back to the default view. In each case, failure produces a slightly worse experience rather than a broken one, which is the property you are actually designing for.

The self-hosting question

Running open-weight models on your own infrastructure genuinely removes vendor risk, and it introduces operational burden most businesses should not take on. Open-weight models have narrowed the gap considerably but still trail frontier models on the hardest tasks, and someone now owns the infrastructure, the updates, and the failures.

Two cases make it worth the trade. The first is regulatory: where data residency requirements or sector rules make sending customer data to a third-party provider difficult. For Indian businesses navigating the obligations in the DPDP consent framework, keeping processing inside infrastructure you control can be decisive rather than merely tidy. The second is volume: at high enough throughput, inference costs dominate and self-hosting becomes straightforwardly cheaper.

Outside those two, managed services remain the right default, and the containment measures above are a better use of the same effort.

What to do this month

Three things, none of them large. List every tool touching your site and identify which model provider sits behind each, including the ones you did not choose directly. Identify anything on the revenue path with no fallback and fix that first. And for anything you built yourself, get the provider call behind a single abstraction and move the prompts into your own repository.

That is a week of work that turns an unbounded, invisible dependency into a known and bounded one. Given how fast this market is moving, and how much of it arrives through vendors who never tell you what changed, it is cheap insurance. Send us your stack and we will tell you where the unmapped dependencies are.