What can we actually ask a vendor?

Who processes material on their behalf, what happens to the service if one of those becomes unavailable, and how much notice they give before an upstream change reaches you. The first is now commonly answered, and the second is the one that separates a considered vendor from an optimistic one.

Is this different from ordinary vendor risk?

It is the same idea with a narrower base. Most software categories rest on many interchangeable suppliers, while a large share of this one rests on a few model providers and hosts, so a single event reaches further and the usual advice about diversifying suppliers works less well.

Does self-hosting remove it?

It shortens the chain and does not remove it. The model still came from somewhere, the software still has dependencies, and the operational responsibility that was somebody else's is now yours, which is a different exposure rather than an absent one.

Glossary

Supply chain risk

The exposure carried by everything a supplier itself depends on, which reaches you without your having chosen any of it.

In plain terms

You chose your supplier. You did not choose theirs, and you may not know who they are. Everything those companies do about security, availability and change is inherited by you through a relationship you were never party to.

Why it matters

Because the AI category has an unusually short chain resting on unusually few foundations. A tool bought from one company frequently runs on a model made by a second and hosted by a third, so a decision at any of them arrives at your desk as a change in the product you actually bought. That is true of most software and it is more concentrated here, because the number of organisations at the bottom of the chain is small.

How it works

The chain is shorter than in most software and the bottom of it is narrow. A great many products in this category rest on a handful of model providers and a handful of hosts, so an event at one of those is felt across products that look like competitors to a buyer comparing them.

Concentration turns independent choices into a single one. Two vendors chosen deliberately for redundancy can sit on the same foundation without either of them presenting that as a fact about their product, and the buyer has bought one dependency twice while believing they bought two.

Change arrives as much as failure does. A model retired, a price altered, a behaviour adjusted upstream: none of those is a breach and each of them changes what your tool does, on a timetable set by somebody with no relationship to you.

Visibility is the practical problem rather than the risk itself. Vendors are increasingly willing to name who processes material on their behalf, and rather less willing to characterise what happens if one of them stops, which is the half a buyer actually needs.

The realistic response is knowing rather than avoiding. An organisation cannot audit its vendor's vendors and can ask who they are, what happens if one becomes unavailable, and how much notice a change carries, which converts an unknown into something with a shape.

What a buyer chose, and what came with it

The useful thing about drawing the chain out is where the contract stops relative to where the dependency continues. A buyer's assessment, negotiation and remedies all apply to the second box, and every box after it arrived as part of the package without being chosen, assessed or negotiated. That is not unusual in software and it matters more here for one reason: the boxes on the right are fewer than a buyer imagines. A market that presents as many competing products frequently narrows to a handful of organisations two steps down, which is why an upstream event produces the odd experience of several unrelated tools behaving strangely on the same afternoon. The practical consequence is about what redundancy means. Buying two products is only redundancy if they diverge somewhere along this line, and nothing on a pricing page tells you whether they do. It is a question worth asking directly, and one most vendors will answer, because the answer is rarely secret and is simply not something anybody volunteers.

Seen in the wild

An assistant whose behaviour changes because a model it depends on was updated upstream.
ChatGPT
Two tools chosen for redundancy that turn out to rest on the same underlying provider.
Claude
An automation platform whose usefulness depends on connectors maintained by other companies entirely.
Make

Common misconceptions

People assume

Choosing a reputable vendor handles it.

In fact

It handles the part you can assess. Their own dependencies are chosen on their commercial reasoning rather than yours, and a well-run company can still rest on a foundation that has a bad week, which arrives at you unchanged.

People assume

Using two vendors gives redundancy.

In fact

Only if they do not share a foundation, which in this category they often do. Two products that compete for your business can depend on the same model provider or the same host, in which case the second purchase bought a second interface rather than a second dependency.

Questions

What can we actually ask a vendor?: Who processes material on their behalf, what happens to the service if one of those becomes unavailable, and how much notice they give before an upstream change reaches you. The first is now commonly answered, and the second is the one that separates a considered vendor from an optimistic one.
Is this different from ordinary vendor risk?: It is the same idea with a narrower base. Most software categories rest on many interchangeable suppliers, while a large share of this one rests on a few model providers and hosts, so a single event reaches further and the usual advice about diversifying suppliers works less well.
Does self-hosting remove it?: It shortens the chain and does not remove it. The model still came from somewhere, the software still has dependencies, and the operational responsibility that was somebody else's is now yours, which is a different exposure rather than an absent one.