Managing AI Vendor Risk in Regulated Cloud Infrastructure

The gap nobody has closed yet

Most organisations have done the first piece of AI governance work: deciding which tools people can use, and on what data. That answers what happens when your own people use AI carelessly. It does not answer what happens when the AI vendor itself is the point of failure.

That second question is a vendor risk question, and for regulated infrastructure it is one most organisations have not worked through, largely because AI vendors have been treated as a different category of supplier to the ones we already scrutinise closely. They are not. A frontier model provider belongs in the same risk category as a payment processor or a critical SaaS dependency: what happens if it becomes unavailable, if your data does not stay where you were told, or if the vendor changes terms without much notice. None of these are hypothetical; all three have already happened to organisations running AI in production.

Concentration risk is not just a technical problem

If a single AI provider sits on the critical path of a customer-facing process, a compliance workflow, or a tool your team now depends on daily, you have a concentration risk, whether or not anyone has labelled it that way.

The obvious failure mode is technical: the vendor has an outage, and whatever depended on it stops working. That is manageable if the dependency is genuinely non-critical, and a different conversation if it has quietly become load-bearing.

The less obvious failure mode is commercial and regulatory. A vendor can change pricing, restrict a model, or lose access to a jurisdiction, and your organisation absorbs that whether or not it was consulted. Export control changes, licensing disputes, and abrupt model deprecations have already forced this on organisations with no warning and no fallback. If your only answer to “what do we do if this vendor stops being available” is “find out when it happens,” that is concentration risk.

The mitigation is not exotic. For anything on a genuinely critical path, know your fallback before you need it: a second vendor, a self-hosted model, or a manual process you can revert to. You do not need redundancy everywhere, but you do need a deliberate decision about where you have it, rather than discovering the answer during an incident.

Data residency claims need verifying, not assuming

“Hosted in the EU” or “processed in-region” sounds like a settled fact once it is in a vendor’s documentation. In practice, it is often a default that holds under normal conditions and can change under load, or one that only covers part of the pipeline.

Cloud AI platforms commonly offer tiered deployment options, strictly in-region, near-region, and global, each with different availability and different guarantees about where processing actually happens. Many organisations do not realise which tier they have selected, or that a vendor’s terms reserve the right to fail over to a different region under load, meaning the residency guarantee they believed they had was conditional all along.

The same applies to tools you did not think of as AI systems at all. Enabling an AI feature inside a chat, calendar, or productivity tool can route data through infrastructure well outside your existing residency posture, even when the base product’s hosting is exactly where you expect. The terms usually say so; almost nobody reads that far.

The practical answer is not to take the claim at face value at onboarding and move on. Check what the contract actually commits to, distinguish that from what the marketing implies, and revisit it periodically rather than assuming it still holds a year later.

An old discipline applied to a new supplier

None of this requires inventing a new risk framework. It requires applying the one your organisation already has for other critical suppliers to AI vendors specifically.

If you already run due diligence on a banking partner or a critical outsourced dependency, you already ask what the impact is if the supplier fails, what the fallback is, what has been verified rather than taken on trust, and who owns the decision to accept the risk. AI vendors should go through the same process, not a lighter one, simply because the technology is newer. Practically, that means AI vendor risk sits with whoever already owns supplier risk in your organisation, rather than living in a separate AI silo nobody quite owns.

A few concrete habits follow from that:

Decide where redundancy is worth the cost. Not every AI-dependent process needs a second provider. The ones on a genuinely critical path, customer-facing, compliance-related, or hard to unwind quickly, are worth the extra cost of a fallback.

Know your circuit breaker before you need it. If a model becomes unavailable or is withdrawn, you should already know what the process reverts to, whether that’s a different vendor or a manual step. Deciding this mid-incident is the expensive way to find out the answer was never agreed.

Keep a record of what you sent and what came back, particularly for anything feeding a regulated decision. If a vendor’s behaviour is ever disputed, that record is what lets you answer the question rather than reconstruct it after the fact.

Where we draw the lines

Applied to our own estate, this produces a few clear positions. We do not put anything on a genuinely critical path through a single AI vendor without a defined fallback, even if that fallback is a manual process rather than a second model. We treat a vendor’s stated data residency tier as a starting point for verification, not a settled fact, and we revisit it rather than assuming it still holds a year on. And we keep the same record-keeping discipline for AI vendor interactions that we already apply to any other critical third-party dependency, because the ability to reconstruct what happened is worth more during an incident than any assurance given in advance.

None of this argues against using AI vendors, including frontier models, for real work. It argues for treating them with the same seriousness you already apply to any other supplier your business would struggle to operate without.

Closing thought

AI vendors are not a special category that gets a lighter risk process because the technology is new. They are a supplier like any other, and the organisations that will handle the next vendor outage, licensing change, or residency surprise well are the ones that already decided, in advance, what their fallback was.

The organisations that get this right will be the ones who can say, for any AI-dependent process, what happens if the vendor fails, where the data actually goes, and what the fallback is.

Key takeaways

• AI vendor risk is a distinct question from AI usage governance: one is about how your people use the tools, the other is about what happens when the vendor itself is the point of failure
• Concentration risk has both a technical face (outages) and a commercial one (pricing, terms, access changes, deprecations), and the second is often the one nobody has a fallback for
• Data residency claims such as “EU-hosted” or “in-region” are often conditional defaults rather than guarantees, and can be overridden under load or by third-party integrations you did not think of as AI
• Applying existing supplier due diligence, the kind already used for banking partners and payment processors, to AI vendors is more useful than building a separate AI-specific framework
• Redundancy is not needed everywhere, but it should be a deliberate decision for anything on a genuinely critical path, made in advance rather than discovered during an incident
• Keeping a record of what was sent to and received from an AI vendor is what allows a dispute or audit to be answered rather than reconstructed after the fact

If you’re reviewing vendor risk across your AI estate and want to talk through where the infrastructure and compliance obligations sit, feel free to get in touch.