Supplier management for AI: governing the vendors behind your models

Almost no organisation builds its own AI from scratch. That means almost every AI risk is, in part, a supplier risk.

Michael McCarroll 16 min read Updated June 2026

The supply chain you didn't know you had

The phrase AI supplier sounds like a single vendor — the one whose logo is on the contract. The reality is a stack. Underneath the application you bought sits a hosted model provider; underneath that, an infrastructure provider; alongside, a retrieval system fed by your own data; and, increasingly, an agentic layer that calls out to further third-party services. Each layer has its own incentives, its own data handling and its own incidents.

The Cloud Security Alliance has noted that this layered structure makes the AI supply chain materially harder to govern than traditional SaaS, because a single end-user action can result in data crossing three or four organisational boundaries within a second (CSA 2024).

The four layers worth tracking explicitly

1. Model providers. The organisation that trains and serves the underlying model — typically a foundation-model lab. Their terms govern what they may do with prompts, outputs and any fine-tuning data you provide.

2. Hosting and orchestration platforms. The platform that exposes the model to your applications — often a hyperscaler, sometimes a specialist. Their terms govern data residency, logging and isolation.

3. Application vendors. The SaaS you actually bought. Their terms govern your end-to-end relationship, but typically pass through the upstream providers' constraints.

4. Embedded AI features. The features that quietly appeared inside the tools your organisation already uses — note-takers, summarisers, copilots, smart-reply suggestions. These are the suppliers nobody assessed because nobody bought them. They deserve the most rigorous handling, not the least.

An AI-specific due diligence addendum

Most supplier security questionnaires were written for static SaaS. For AI you need additional questions, each of which has at least one wrong answer that should stop adoption.

  • What categories of customer data are used to train, fine-tune or evaluate any model? Is opt-out the default or must we request it in writing?
  • What is retained — prompts, outputs, embeddings — and for how long? Where, and under whose jurisdiction?
  • What is the change-management posture for model versions? Are we notified before a swap, or only afterwards in a release note?
  • What evaluation evidence is available for the use cases we intend to put into production? How was bias tested?
  • Which sub-processors and upstream model providers are involved? Are we contractually informed when they change?
  • What is the documented behaviour when the model fails, hallucinates or returns a refusal? Who is responsible for the consequences?
  • How are security incidents — including prompt-injection and data-leak incidents — defined, reported and remediated?

The questions matter, but the contractual right to ask them and the operational rhythm of asking them matter more.

Contracts: what to update, what to insist on

Contracts signed before 2023 generally predate the generative-AI era. They are silent on training data, on model change, on output liability and on regulator co-operation under the EU AI Act (European Parliament 2024). Three additions matter most.

Data use clauses that bind the supplier and any subcontractor not to train on customer data without explicit, contract-grade consent. The default needs to be off.

Change notification clauses that require advance notice of material changes to the model, hosting location, or fine-tuning posture. The minimum useful notice is enough time to test against your own evaluation set.

Audit and evidence clauses that grant the right to receive evaluation evidence, security attestations and incident records, not just SOC 2 letters. For high-risk uses, the right to participate in a regulator's investigation under the AI Act is increasingly relevant.

The long tail: embedded AI features

The most common 2024–2025 incident pattern is not the procured platform, it is the embedded feature. A meeting tool adds a transcription summariser. A CRM ships a generative email drafter. A code editor adds an autocomplete that ingests the whole codebase. None of these went through procurement; each of them now processes confidential material.

The remedy is procedural rather than technical: every existing supplier review cycle asks the additional question what AI features have you added since we last reviewed you? and treats the answer as a re-classification trigger. ISO/IEC 42001 Annex A includes explicit controls for this, but the discipline matters more than the standard reference (ISO/IEC 2023).

References

  • Cloud Security Alliance (2024) AI Resilience: A Framework for Trustworthy Adoption. Seattle, WA: CSA.
  • European Parliament (2024) Regulation (EU) 2024/1689 (Artificial Intelligence Act). Official Journal of the European Union.
  • ISO/IEC (2023) ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. Geneva: ISO/IEC.
  • National Institute of Standards and Technology (2024) Generative AI Profile (NIST AI 600-1). Gaithersburg, MD: NIST.

Govern every supplier in your AI stack, not just the one with the logo

ISO-STANDARD.app keeps a live register of every AI supplier, the upstream model providers behind them and the embedded features you didn't buy — with the controls and contract terms each requires.

ISO-STANDARD.app ships a ready-to-adopt ISO 42001 workspace with the risk register, controls catalogue, policies and audit-ready exports already wired together — no spreadsheet sprawl, no consultant lock-in.

Prefer a conversation? Email hello@iso-standard.app — a real human responds within one business day.

Trust & security
ISO 27001 aligned
Controls mapped to Annex A
Encryption in transit & at rest
TLS 1.3 · AES-256
MFA enforced
TOTP required for all admins
GDPR & UK GDPR
DPA on request · EU/UK data
SOC 2 ready posture
Audit-grade logging
RLS-isolated tenants
Row-level data separation
← All guidesHome →