AI Vendor Risk

The Technical Definition

AI vendor risk is the set of operational, financial, and compliance exposures that come from running production AI on infrastructure and models you do not control. The four primary categories: concentration (one vendor as a single point of failure), model deprecation (the underlying model is retired or materially changed), data residency and compliance pass-through (where your data lives, who can subpoena it, and which regulations follow it), and pricing power (the vendor can re-tier the contract once you are dependent).

What This Actually Means for Your Business

The pitch is “build on our platform and let us handle the model.” The fine print is that the model is the product, the model is theirs, and when they change the model, your workflow changes whether you wanted it to or not.

Concentration is the first risk most operators underestimate. If your customer-service assistant, your sales-research agent, and your internal-search tool all run on the same vendor’s model, that vendor’s outage is your outage across three systems simultaneously. That vendor’s price increase is a re-quote on three contracts. That vendor’s policy change on data use applies to every system you built on top of them. The convenience of a single integration is also the brittleness of a single dependency.

Model deprecation is the risk operators do not feel until the email arrives. The model you spent six months prompt-engineering against is being retired in ninety days. The replacement is “better” on the vendor’s benchmarks and worse on yours, because your prompts were tuned to the old model’s quirks. You now have a forced migration on the vendor’s timeline, not yours, with a system in production that customers depend on. This has already happened to GPT-3.5 customers, to specific Claude versions, to image-model deployments. It will happen again.

Data residency and compliance pass-through is the risk your auditor finds. Your data goes to the vendor’s API. The vendor’s API runs in regions you may or may not have approved. The vendor’s subprocessors include hyperscalers under different jurisdictions. Your GDPR, HIPAA, or SOC 2 obligations do not stop at your perimeter — they follow the data. If the vendor cannot tell you where every byte lives and who can access it, your compliance posture is as good as their disclosure.

Pricing power is the risk that shows up in the renewal. The first contract is priced to win the deal. The second is priced to monetize the integration. By then your prompt library, your eval set, your retrieval index, and your team’s mental models are all built on this vendor. The switching cost is no longer a contract — it is six months of rebuild.

Reality Check

What the vendor says: “We are committed to long-term partnership and stable pricing.”

What that means in practice: Pricing is stable until the model gets cheaper to run, in which case they keep the margin, or until you are deeply integrated, in which case they reprice. Commitment ends at the next contract negotiation, and the negotiation favors the side that controls the model.

What Operators Actually Do

Operators who manage AI vendor risk treat it like any other concentration: they measure it and they cap it. They keep a register of which models run which workflows, with revenue or cost exposure attached. When a single vendor exceeds a threshold of total AI spend or covers more than two critical workflows, that triggers a diversification review.

They also build for portability from day one. Prompts are stored in a model-agnostic format. Eval sets run against multiple models, not just the production one, so they always have a reference for what “good” looks like elsewhere. Retrieval and orchestration logic sit outside the vendor’s platform, so the model can be swapped without rebuilding the surrounding system. The cost is real — it is slower than going all-in on one vendor — and it is the cost of not being held hostage at renewal.

For data residency and compliance, the discipline is to read the subprocessor list and the data flow diagram before signing, not after the audit. If the vendor cannot produce both, the answer is no.

The Questions to Ask

1. What is our concentration on this vendor, in dollars and in workflows? If they go down for forty-eight hours, what stops working. If they raise prices forty percent at renewal, what is the alternative and how long does it take to switch.

2. What is the deprecation policy on the underlying model? Notice period, sandbox access to the replacement, ability to stay on the prior version, and at what cost. Get it in writing before the deal closes, because no one writes it in after.

3. Where does our data physically live, and who are the subprocessors? The vendor, the cloud provider, the inference layer, the logging stack. If your auditor asked tomorrow, can you produce the diagram. If not, the compliance posture is hope, not architecture.