Most organizations do not build their own foundation models. They rent them. The capability at the center of the AI estate is therefore owned, trained, updated, and occasionally deprecated by somebody else, and the traditional vendor risk process was not built for that.
Conventional third-party risk management rests on an assumption so basic it is rarely stated: the thing you assessed stays the thing you are using. You evaluate a supplier, sign a contract, and the software behaves tomorrow as it behaved during diligence. Foundation models break that assumption. The artifact changes underneath you, sometimes without notice, and every piece of evaluation evidence you hold silently acquires an unknown expiry date.
This article works through the third-party AI lifecycle from sourcing to exit and identifies where the second line must insert itself.
Stage One: Sourcing and Selection
The decisions that determine your exposure are made before any contract is signed, and two of them are routinely deferred until it is too late to make them cheaply.
Define requirements before evaluating providers: capability, latency, cost, data residency, and the specific risk constraints that are genuinely non-negotiable. A requirements list assembled after a favored vendor has been identified will describe that vendor.
Assess switching cost at selection time, not at exit time. The architectural decisions made in week one determine whether a later exit is a quarter of work or a year of it.
Decide on a second provider for critical paths at the outset. Concentration risk is cheapest to solve before you have built on a single provider, and nearly impossible to solve gracefully afterwards.
Stage Two: Due Diligence: The Evidence to Demand
Diligence should test claims rather than collect assurances. The following evidence set covers the ground, and what each item tests matter more than whether it was supplied.
Model or system card: intended use, known limitations, evaluation results, and at least a general description of training data.
Safety and red-team summary: whether adversarial testing occurred, by whom, and against what threat model.
Independent evaluation or benchmark results: the question being whether performance claims are self-reported or externally verified.
Security certification such as SOC 2 Type II or ISO/IEC 27001. Type II matters specifically because it covers operation over a period rather than design at a point in time: the same design-versus-operating distinction that governs your own controls.
ISO/IEC 42001 certification where available: whether the provider runs a certified AI management system. This is becoming the differentiating question to ask.
Data handling and retention commitments: whether your inputs and outputs are retained, used for training, or subject to human review.
Sub-processor list and change notification process: who else touches the data, and whether you find out when that changes.
Incident history and notification commitments: how the provider behaves when something goes wrong.
Regulatory role allocation: whether the provider is acting as provider, deployer, or general-purpose model provider under the applicable regime, since this determines who carries which obligation. Get it in writing; the allocation is contractual as well as legal.
Model change and deprecation policy, notice period for version changes and end-of-life for versions you depend on. This is simultaneously the most important item on the list and the most frequently omitted.
Stage Three: Contracting: The Clauses That Actually Matter
Contract negotiation is where second-line requirements become enforceable or evaporate. Eight clauses carry most of the weight.
No training on our data: stated explicitly, covering inputs, outputs, derived data, and sub-processors.
Model change notification with a defined lead time, and the right to pin a version for a defined period. Without this, evaluation evidence expires silently and you learn about it from a production incident. If only one clause survives negotiation, make it this one.
Right to audit, or at least the right to specified evidence on a defined cycle. Large providers rarely grant full audit rights; they frequently grant structured evidence delivery. Negotiate for what is actually obtainable.
Data residency, retention and deletion, including deletion attestation on exit.
Sub-processor consent or, at minimum, notification with a right to object.
Service levels covering availability and latency, and, harder to obtain but worth requesting, commitments against performance regression.
Intellectual property indemnity for outputs. Now offered by most major providers, though the scope and the conditions attached vary considerably and deserve reading closely.
Exit assistance and portability: data export, deletion certification, and a defined transition period.
Stage Four: Integration, Where Architecture Becomes the Control
Contractual protection is necessary and slow. Architectural protection operates continuously. The single highest-leverage decision available is to route all model calls through an internal gateway or proxy rather than allowing applications to call providers directly.
That one decision delivers logging, sensitive-data redaction, rate limiting, cost control, provider substitution, and policy enforcement in a single place. It is also nearly impossible to retrofit once dozens of applications hold their own credentials and call providers directly, which is why it belongs in the second line's standard rather than in an engineering backlog.
Alongside the gateway, five integration controls do the practical work:
Log prompts and outputs, with redaction applied before storage and a defined retention period.
Per-use-case credentials rather than shared keys, so that consumption is attributable and revocable at the level of a single use case.
Rate and cost limits per use case, as a control against both runaway spend and abuse.
An abstraction layer that makes provider substitution a configuration change rather than a rewrite.
For agentic systems: least-privilege tool permissions, an allowlist of callable tools, human approval gates for consequential actions, and full action logging with replay capability. Every tool integration and every external protocol server is itself a third party and should be governed as one.
Stage Five: Ongoing Monitoring
The defining feature of third-party AI risk is that assessment decays. Four monitoring practices address that decay directly.
Regression-test your evaluation suiteagainst every model version change, including provider-initiated ones. This is the control that closes the silent-update gap, and it only works if you have an evaluation suite worth running.
Monitor output quality continuously rather than only at launch. For retrieval systems, groundedness and citation fidelity are the practical measures.
Track concentration:how many critical use cases depend on a single provider, and what measured substitution time would be.
Reassess annually and on trigger: a security incident, an ownership change, a material policy change, or a significant model release.
Stage Six: Exit
Exit planning is where the cost of early architectural decisions comes due. The assets that matter are the ones you built, and their portability varies sharply.
Prompts, evaluation suites, fine-tuning datasets, and retrieval corpora should be portable by design, held in your systems rather than the provider's.
Embeddings are the trap. They are model-specific, so changing providers means re-embedding the entire corpus, which converts a configuration change into a project with a schedule and a budget.
Fine-tuned model weights are usually not portable at all, a fact that belongs in the original selection decision rather than the exit conversation.
Deletion attestation, including confirmation that sub-processors have deleted.
For top-tier systems, the exit plan should be rehearsedrather than merely documented: the standard long applied to disaster recovery, applied here.
Five Special Cases
Certain arrangements carry distinct risks that a standard vendor assessment will not surface.
Open-weight models. There is no vendor to hold accountable, no support obligation, and no notification duty. License terms vary considerably and deserve individual reading rather than assumption.
Model chains and sub-models. A provider may route your request across several underlying models. Your diligence covers the provider; it does not necessarily cover what sits behind them.
Agentic tool integrations and protocol servers.Each connected tool is an access path and a potential injection surface. An agent with a badly scoped tool permission is a third-party risk wearing an internal badge.
AI features added to existing SaaS products. This is the largest blind spot in most third-party AI inventories:in-scope AI capability arriving under a contract written before AI was contemplated, invisible to both the AI register and the vendor risk register. Any organization building an AI inventory should sweep its existing SaaS estate specifically for this.
Cloud-hosted model services. The cloud relationship and the model relationship carry different risk profiles even when they arrive on the same invoice.
Where Ownership Sits
Third-party AI risk is shared, and the sharing needs explicit decision rights or it becomes nobody's.
Procurement owns the process.
Security owns the security assessment.
Privacy owns the data protection assessment.
The second-line AI function owns the AI-specific risk assessment, the tiering of the use case that consumes the vendor, and the standard the other assessments must satisfy.
The practical failure mode is a vendor cleared by procurement and security, with no one having asked whether the model is fit for the use case it will serve.Security clearance and fitness for purpose are different questions, and only one of them is anybody's job by default.
The Framing Worth Carrying
Traditional third-party risk assumes the thing you assessed stays the thing you are using. Foundation models violate that assumption continuously and quietly.
Everything in this article follows from taking that seriously:
Contract for notice of change
Architect so that substitution is cheap
Monitor so that decay is visible
Evaluate on a cycle rather than once.
The next article turns inward, to what happens when a control fails: issue management, remediation, risk acceptance, and the appetite statements that define the boundary in the first place.
Explore more: Start Here · Topics · Archive · About