Third-party AI risk management

Almost no regulated firm builds its own AI estate. The third-party risk is already inside your perimeter; the question is whether you have governed it.

Most of the AI risk conversation inside regulated firms focuses on what the model does. Will it hallucinate? Will it leak data? Will an agent go further than we intended? Those are real questions. But they are downstream of a more basic one most security and audit teams have not yet answered formally: who are we buying this from, on what terms, and what happens if they change their mind?

Your AI estate is, in all likelihood, a handful of foundation-model providers, a collection of third-party connectors, and one or two embedded copilot products whose internal behaviour you cannot observe. Every one of those relationships is a dependency you are accountable for but do not control. The regulator treating AI third parties as ICT third parties is not a metaphor. Under DORA, for example, the register of information and the oversight framework for critical ICT third-party providers applies to AI providers as much as it applies to a cloud data centre. Third-party AI risk is not a new category of risk. It is your existing third-party risk discipline applied to a new and genuinely harder asset class.

The stake

The FS AI supply chain concentrates on a small number of foundation-model vendors and the cloud providers that host them. Several of your “independent” AI services may share a single point of failure: the same model family, the same hosting region, the same provider’s policy decisions on data retention. That concentration is not automatically unacceptable. Substitutability at the frontier is genuinely poor. But it must be a named, owned, board-visible risk, not an accident you discover during an outage.

Three features of AI providers make the standard third-party risk template insufficient without adjustment.

First, the provider can retain and learn from the data you send it. A cloud storage provider does not train models on your files. Many AI providers do, on the default tier, unless you explicitly configure otherwise and get that in writing. The default tier and the enterprise tier of the same product can behave in opposite ways. Contract for the tier you actually run on.

Second, a connector or copilot is executable code running inside your trust boundary, holding credentials and scopes. That is closer to software-vendor diligence than data-processor diligence. The questions are: who maintains this code, how are changes versioned and signed, and what does the tool actually require versus what does it request in its description?

Third, a single provider outage or policy change is a portfolio-level event, not an application-level one. That is a different scale of dependency than most third-party risk frameworks were written to handle.

Three provider types, three sets of questions

Your due diligence starts with a common baseline across all AI providers: security posture and independent assurance (SOC 2 Type II, ISO/IEC 27001, and ideally ISO/IEC 42001 certification of the provider’s AI management system); sub-processor disclosure and the right to notification on changes; incident-notification commitments and history; and financial viability.

Then add the type-specific questions.

Foundation-model vendors. The load-bearing questions are about where inference runs and who can retain the data. A vendor-hosted API, a cloud-managed model on infrastructure you control, and a self-hosted open-weight model put the retention boundary in three different places. Establish which one you are buying. Add model provenance: what was the model trained on, what safety evaluations exist, and how are model versions deprecated.

Connector providers. Treat a connector as third-party code, not a data processor. Who maintains it? How are changes versioned and signed? What is the disclosure process if the connector’s tool description changes? What scopes does it actually need versus what it requests? The tool description is the connector’s attack surface for prompt injection and capability expansion; change control on it is as material as change control on any other executable you run inside your perimeter.

Copilot vendors. The distinctive question is tenancy and data boundary. In a shared multi-tenant copilot, what prevents cross-tenant leakage? What is logged? And can you get the data-handling terms for your tenant specifically, rather than the marketing default?

The data-handling contract checklist

This is the most commonly skipped step. Firms assume the provider’s privacy policy covers them. It does not. The data-handling terms that matter are negotiated, not assumed, and they are frequently available only on enterprise tiers or by explicit configuration. Get the following in writing for every material AI provider.

• Zero or limited data retention. Whether prompts and outputs are retained at all, and if so for how long. Zero data retention is the strongest position. Where it is unavailable, pin an explicit, short retention window.
• No training on firm data. An express commitment that your prompts, outputs, and uploaded content are not used to train or fine-tune the provider’s models. This must cover the default tier and any “improvement” or “feedback” programmes.
• Abuse-monitoring carve-outs. Many providers route a sample of traffic to human reviewers for safety monitoring and cannot fully opt out. Understand the scope of that carve-out and exclude your most sensitive data classes from prompts in the first place. A contractually bounded, auditable regime is the realistic position.
• Deletion SLAs. Defined maximum retention and a deletion service-level on termination and on request, with evidence of deletion.
• Sub-processor disclosure. A current list of sub-processors, prior notice of additions, and flow-down of these terms to them.
• Data-residency commitments. Where data is processed and stored, contractually fixed. This is the contractual input to your GDPR cross-border transfer analysis; the obligation itself sits in the transfer provisions of UK and EU GDPR.

Verify the runtime configuration matches the paper. Provider terms change unilaterally and often. The default consumer tier of the same product may do the opposite of what the enterprise contract says. Ongoing oversight catches a quietly altered retention clause before it creates an exposure.

Managing concentration risk

Four moves get you from “we know we depend on one vendor” to “this is a named, governed risk.”

First, map it. For each AI-supported important business service, record the upstream model, connector, and hosting dependencies. Then look across the portfolio for shared roots. Two services you thought were independent may share a model family, a hosting region, or a provider’s policy framework.

Second, accept it explicitly. Where substitution is genuinely unavailable, make the residual risk explicit: a board-level acceptance with a named risk owner, not a footnote in a risk register nobody reads.

Third, plan the fallback. Document a degradation or fallback plan for each workflow that provider supports, including a manual or reduced-function mode you have actually tested. An untested fallback is a plan you will discover is broken during the incident.

Fourth, contract for continuity. Negotiate notice periods, model-weight or source escrow where feasible, transition assistance, and data portability. Write the contract to serve the exit plan, not the other way round.

Ongoing oversight after the contract is signed

Diligence and contracting are point-in-time. The risk is continuous. Sustainable oversight means keeping the provider in your AI inventory and third-party register, periodic re-assessment tied to the provider’s risk tier, and monitoring for material changes: new sub-processors, changed retention or training terms, model deprecations, security incidents.

The practical discipline is: fold AI providers into the third-party risk process you already run. A firm running DORA-aligned ICT third-party risk management already has supplier management, data classification, change control, risk treatment, and concentration analysis. The AI-specific work is identifiable and narrow: the data-handling checklist, connector-as-code diligence, and provider concentration mapping. Add those to your existing process rather than standing up a second one.

What to do this week

1. List every AI provider your firm currently consumes, including connectors and embedded copilots. Note the tier each runs on.
2. For each provider, confirm whether your current contract includes the six data-handling terms above. Flag the gaps as procurement actions.
3. Map provider concentration: for each AI-supported important business service, identify the upstream model and hosting dependencies, then look for shared roots across the portfolio.
4. Name concentration risk explicitly in your third-party risk register with a named owner and a fallback plan.
5. Set a re-assessment cadence for each provider, keyed to its risk tier, and put it in your third-party oversight calendar.