When you integrate a third-party AI API, you don't just adopt its capabilities — you inherit its training-data risk, its security posture, and a share of its legal liability under frameworks like the EU AI Act. Due diligence before signing, and monitoring after, is what keeps an inherited risk from becoming an unmanaged one.
Quick answer: Treat every embedded model as inherited risk, not delegated risk. Run a six-domain check before signing — training data, security, data handling, indemnification, model updates, exit — and negotiate contract terms that keep you informed and covered when the vendor changes the model underneath you.
Why Embedding a Vendor's Model Makes You a Co-Owner of Its Risk
Under the EU AI Act's value-chain provisions, a company that integrates a third-party AI model into its own product can be treated as a deployer — and in some configurations, reclassified as a provider — with its own compliance obligations, regardless of who actually trained the underlying model. Liability doesn't stay upstream just because the code did.
Article 25 of the EU AI Act (Regulation (EU) 2024/1689) sets out "responsibilities along the AI value chain." It specifies that a distributor, importer, or downstream integrator can be treated as the provider of a high-risk system — inheriting the provider's full compliance burden — if it puts its own branding on the system, substantially modifies it, or changes its intended purpose. Bolting a vendor's model into your product and shipping it under your name is exactly the kind of act the provision anticipates.
Practically, that means you inherit more than a feature. You inherit:
- Whatever bias sits in the base model's training data, whether or not the vendor tested for it.
- The vendor's actual security posture, not the one described in their sales deck.
- Their data-retention and reuse practices, including whether your customers' inputs quietly become someone else's training data.
- Behavior changes the vendor pushes on their own schedule, which your product team may not learn about until users notice.
The NIST AI Risk Management Framework treats third-party and supply-chain risk as part of its Govern function, not a separate compliance track. The expectation is that an organization's AI governance program explicitly covers models it consumes, not just models it builds. If your responsible-AI practice only has a process for internally trained models, it has a blind spot exactly where most production AI features actually live today.
The OECD AI Principles, which the EU AI Act's risk-based approach draws on, make the same point from a policy angle: accountability is expected to travel with whoever deploys a system into the world, not stay fixed to whoever trained it.
Gartner has repeatedly noted that most enterprise generative-AI initiatives now run on a licensed or embedded foundation model rather than one trained in-house — vendor risk is quickly becoming the default shape of AI risk, not a special category next to it.
For the fuller regulatory picture — including which risk tier your product likely falls into — see our EU AI Act map for product managers. This vendor-diligence discipline is one piece of a larger practice; the complete guide to advanced responsible AI for product teams covers the rest.
The Six-Domain Vendor Due-Diligence Checklist
A rigorous AI vendor review interrogates six domains before a contract is signed: training data provenance, security and infrastructure, data handling and retention, indemnification and liability, model update and versioning policy, and exit and portability. Treat each as a pass/fail gate, not a checkbox — a vague answer in any one domain is itself the finding.
| Domain | What to ask | Red flag |
|---|---|---|
| Training data provenance | Can they name data sources and licensing basis? Do they document bias testing? | "Proprietary and confidential" with no further detail, on any question |
| Security & infrastructure | Current SOC 2 Type II or ISO/IEC 27001 report? Pen-test cadence? Where is data processed? | No third-party audit report available on request |
| Data handling & retention | Is your data used to train or fine-tune their model? Retention period after contract ends? | Training-on-your-data is opt-out, not opt-in |
| Indemnification & liability | Do they indemnify you for IP infringement or discriminatory outputs? What's the liability cap? | Cap set at fees paid in the last month |
| Model update & versioning | Do they notify you before changing the underlying model? Can you pin a version? | "We may update the model at any time," no notice clause |
| Exit & portability | Can you export logs and fine-tuning data? What's the transition window if they shut down? | No defined export format or timeline |
Training Data Provenance: The Question Vendors Answer Vaguely
Most vendors will describe their model's capabilities in detail and its training data in a single evasive sentence. That asymmetry is itself informative. Stanford HAI's Foundation Model Transparency Index (Bommasani et al.) scored major foundation-model developers against a public transparency rubric and found scores clustered low across the board — many developers disclosed little to nothing about training data composition, licensing, or labor even when they disclosed plenty about benchmarks.
Push past "trained on a diverse, web-scale corpus." Ask whether they've run any bias or fairness evaluation, on what protected classes, and whether you can see the results. If the answer is silence, assume the model carries whatever bias its training data carries, because someone has to, and it defaults to you.
Indemnification: Read the Liability Cap, Not Just the Clause
An indemnification clause that exists on paper but caps damages at a month of subscription fees isn't protection — it's a rounding error next to a discrimination lawsuit or an IP infringement claim. Read the cap, not just whether the clause is present. Vendors routinely offer indemnification language in the first draft and quietly cap it near-zero in the fee schedule.
Security diligence deserves the same skepticism. The OWASP Top 10 for LLM Applications catalogs risks that a glossy security page rarely addresses directly:
- Prompt injection — can untrusted input override the system prompt or leak other tenants' data?
- Training-data poisoning — how do they vet data before it shapes the model?
- Supply-chain vulnerabilities — which third-party components and plugins sit inside their stack?
- Insecure output handling — is model output ever passed downstream without sanitization?
Ask the vendor how they mitigate each one, by name. The Cloud Security Alliance publishes AI-specific vendor assessment questionnaires for exactly this conversation, giving your security team a recognized reference point instead of a bespoke document only your product team understands.
Exit and Portability: The Question Everyone Skips
Exit planning gets skipped because signing a contract feels like the opposite moment to plan a departure in. That's precisely why it belongs in diligence, not after a problem forces it. Ask, before you sign, exactly what you'd be able to export if the relationship ended tomorrow — logs, fine-tuned weights, prompt histories, evaluation data — and in what format.
A vendor that goes quiet on this question, or answers with "we'll work with you on that," is telling you the export path has never actually been tested. Treat that the same way you'd treat an untested backup: assume it fails until you've verified otherwise, ideally by requesting a sample export early in the relationship rather than waiting for a crisis to try it for the first time.
Contract Terms Worth Fighting For
The checklist tells you what to ask; the contract is where the answers become enforceable. Prioritize terms that protect you against the two failure modes that actually happen: a silent model change breaking your product, and a liability event where the vendor's cap leaves you exposed.
| Contract term | Why it matters | If you can't get it |
|---|---|---|
| Advance notice of model changes | Lets you re-test before a breaking change ships to your users | Demand a changelog subscription and monitor it weekly yourself |
| Version pinning / LTS window | Keeps your prompts and evals valid for a defined period | Build your own regression suite as an early-warning system |
| Indemnification with a realistic cap | Protects you against IP and discrimination claims, not just breach of contract | Carry it as a named, quantified risk in your own governance log |
| Data Processing Addendum with sub-processor list | Shows exactly who else touches your data downstream | Ask for the sub-processor list even without a formal DPA |
| Audit rights | Lets you request current SOC 2/ISO reports annually, not just at signing | Set a calendar reminder to re-request them yourself |
| Deprecation & sunset notice (6–12 months) | Gives you runway to migrate before an API is killed | Treat any vendor without this clause as higher migration risk |
| Data export & transition assistance on exit | Prevents lock-in from becoming a business continuity risk | Test the export path once, early, before you need it |
Asking whether a vendor holds ISO/IEC 42001 certification — the first international standard for AI management systems — is a fast proxy for whether they run an actual AI governance program versus marketing copy dressed as one. It won't tell you everything, but a vendor that can't answer the question at all has told you something too.
The Silent Model-Swap Scenario: What Breaks When They Change the Model Under You
When a vendor updates the model behind an API, everything downstream that depended on its exact behavior — prompt formatting, confidence calibration, safety filters, latency and cost assumptions — can shift at once, with no corresponding change on your side to point to. The fix is treating every model version as a pinned dependency you test, not a black box you trust.
Say a product routes support tickets through a vendor's classification endpoint, tuned against outputs from one model version. The vendor upgrades the model for everyone, with a release note buried in a changelog nobody on the product team subscribes to. Nothing in your codebase changed, yet accuracy, tone, and even the JSON shape of responses can all drift simultaneously.
| Signal that breaks | Why it breaks | What to pin |
|---|---|---|
| Output format / structure | Newer model versions format responses differently even with the same prompt | Contract-test the response schema, not just a spot-check |
| Confidence or probability scores | Recalibrated models shift score distributions, so old thresholds miscue | Version-lock uncertainty thresholds to a specific model ID |
| Fairness / bias profile | A retrained base model can shift disparate-impact metrics without any UI change | Re-run fairness checks after every vendor version bump |
| Cost and latency | New model versions can be priced or sized differently, changing unit economics | Track cost-per-call by model version, not just by feature |
What to Watch Beyond the Table
Two of these signals deserve their own line of defense. Confidence and probability scores that recalibrate silently are a UX problem before they're a technical one — if your interface presents the model's certainty to users at all, review how you're framing it against the guidance in designing honest confidence and uncertainty into AI UX, because a threshold tuned for one model version can quietly start over- or under-claiming certainty on the next.
A fairness profile that shifts is exactly the kind of drift a one-time launch audit misses, since nothing about your product changed — only the vendor's model did. The practice in running an AI fairness audit as a product team is designed to be repeatable for this reason: run it again after every material vendor model update, not just before ship.
Zoom out and the real question is whether the feature still does the job it was hired to do. Revisit it through a jobs-to-be-done lens: a model swap that keeps accuracy numbers flat can still change the texture of the output enough that it no longer satisfies the underlying job, and metrics dashboards rarely surface that on their own.
Turning Due Diligence Into an Ongoing Governance Cadence
Due diligence isn't a one-time gate at contract signature — it's a recurring review cycle triggered by vendor model updates, contract renewals, and incident reports, with a named owner on the product or platform team. A checklist that only runs once is a snapshot of a risk that keeps moving.
Assign the cadence to a person, not a team alias. In practice this is usually a product manager or platform lead who already owns the vendor relationship commercially, working alongside whoever owns security review — splitting "do we still want this vendor" from "is this vendor still safe" across two owners who never compare notes is how a renewal gets rubber-stamped without either question actually being asked.
Build the cadence around three triggers, not a fixed calendar alone:
- Contract renewal — re-run the full six-domain checklist, not just the pricing conversation.
- A vendor-announced model version change — re-test your regression suite and, where applicable, your fairness audit, before the new version reaches production traffic.
- Any security or compliance incident at the vendor, disclosed or discovered — trigger an off-cycle review regardless of where you are in the renewal calendar.
Mapping where a vendor swap would actually surface for a user is easier with a customer journey view in hand — it tells you which moments in the experience are load-bearing on the vendor's model behavior, so monitoring effort goes where a silent regression would actually be felt, not just where it's easiest to instrument.
None of this monitoring works if nobody can say precisely what data crosses the vendor boundary in the first place. That's a scoping problem as much as a governance one: teams often integrate a vendor API against a vague mental model of "we send it the ticket text," when the real payload includes metadata, prior conversation history, or customer identifiers nobody flagged.
Key Takeaways
- Third-party AI is inherited risk, not delegated risk — under the EU AI Act's value-chain provisions, integrating a model can make you a co-owner of its compliance obligations.
- Run the six-domain checklist before signing: training data provenance, security, data handling, indemnification, model updates, and exit — a vague answer in any domain is a finding, not a formality.
- Read the indemnification cap, not just the clause — protection capped at a month of fees is not protection.
- Negotiate for advance notice of model changes and a defined deprecation window, since these are the terms most likely to prevent a silent production break.
- A vendor model update can shift output format, confidence calibration, and fairness profile simultaneously — pin versions and re-test after every material change, don't assume stability.
- Due diligence is a recurring cadence, triggered by renewals, vendor model updates, and incidents — not a one-time gate you clear at signature.
- Know precisely what data crosses the vendor boundary before you scope monitoring or negotiate terms; a concrete endpoint spec beats a vague mental model of "we send it the ticket text."
Frequently Asked Questions
What is AI vendor due diligence?
AI vendor due diligence is the structured review of a third-party AI provider — its training data, security posture, data handling, liability terms, model-update policy, and exit options — conducted before signing a contract and repeated on a recurring cadence afterward, not just once at procurement.
Who is liable if a third-party AI model discriminates or hallucinates — us or the vendor?
Often both, and the split depends on your role under frameworks like the EU AI Act. If you've branded, substantially modified, or repurposed the vendor's model, Article 25's value-chain provisions can treat you as a provider with your own compliance obligations, alongside whatever contractual indemnification you negotiated.
How often should we re-review an AI vendor after signing the contract?
At minimum, at every contract renewal — but the higher-value trigger is any vendor-announced model version change or disclosed security incident, since those are the events most likely to introduce new risk mid-contract, well before a renewal date arrives.
What should be in an AI vendor's data processing addendum?
A usable DPA names every sub-processor who touches your data, states whether your inputs are used for model training or fine-tuning (and whether that's opt-in or opt-out), defines a retention period after contract termination, and specifies where data is processed geographically.
Can we require an AI vendor to give notice before changing their model?
Yes — advance-notice-of-model-change is a standard, negotiable clause, though vendors resist committing to it by default. Ask for a defined notice period (commonly 30–90 days) plus the ability to stay pinned to a prior version through that window while you re-test.