3.2Third-Party AI Risk Management and Supply Chain Security
Much AI risk arrives through vendors, models and datasets the organization did not build. Third-party AI governance vets suppliers before purchase, traces where data and models came from, writes duties into contracts and keeps verifying after go-live.
Buying AI does not buy away the risk. The less of the stack an organization runs itself, the fewer controls it operates directly, but it still answers for how the AI is used. ADG's shared responsibility model shows which governance surfaces stay with the buyer as it moves from self-hosted models to SaaS features.
diagram
Moving from self-hosted to SaaS AI shrinks the number of ADG governance surfaces the organization operates, from nine to four. Accountability for how the AI is used stays with the organization at every step.
Key points
EC-Council's ADG (Adopt, Defend, Govern) framework defines three deployment classes: Homegrown or self-hosted, Foundation Model API, and software as a service (SaaS) or embedded AI.
Homegrown means the organization owns all nine governance surfaces; with a Foundation Model API it still owns seven: Prompt, Context, Tools, Orchestration, Identity, Safety Layer and Telemetry.
With SaaS or embedded AI the organization keeps Context, Identity, Telemetry and its GOVERN policy, and shares the Safety Layer and prompt customization with the vendor.
ADG states that ownership shifts toward the vendor but accountability for use never fully transfers; control MC-12 requires the boundary to be documented.
NIST AI Risk Management Framework (AI RMF) GOVERN 6 requires policies for third-party software, data and supply chain risk, and GOVERN 6.2 contingency plans for high-risk third-party AI.
NIST AI 600-1 names Value Chain and Component Integration as a generative AI risk: untraceable third-party components and improper supplier vetting.
ISO/IEC 42001 Annex A control objective A.10 covers third-party and customer relationships, including allocating responsibilities and managing suppliers.
Exam tip
When an option says the vendor is responsible because it built the model, look instead for the answer that keeps accountability with the deploying organization and documents the split in a responsibility matrix.
Due diligence is the background check before a supplier's AI gets into the environment. The buyer asks for evidence of where the model came from, how its data will be used and how incidents are handled, and then tests the claims instead of trusting the brochure.
diagram
Due diligence is a hand-off loop: the vendor supplies evidence, security tests it independently, and governance decides with the findings in hand. The contract then locks in what was promised.
Key points
EC-Council's ADG (Adopt, Defend, Govern) framework asks vendors to disclose model provenance, training data policies, alignment methods and known limitations before onboarding.
ADG says to evaluate vendor safety controls independently rather than relying solely on vendor claims, and to keep consumer-side monitoring whatever the vendor monitors.
Joint guidance from eight national cyber agencies (March 2026) tells AI buyers to vet vendors' security posture, data handling practices and extended supply chain risk.
The same guidance asks buyers to require and maintain an AI Bill of Materials (AIBOM) and Software Bill of Materials (SBOM), or equivalent documentation.
Suppliers should commit to report and respond to vulnerabilities and incidents on discovery, including those arising in their own third-party suppliers.
Findings go into the ADG Vendor AI Due Diligence Record, the evidence for control MC-12, together with contract clauses and responsibility boundaries.
ADG's nine-step process backbone makes vendor due diligence and ongoing assurance step 8, owned by the ADOPT pillar.
Exam tip
Best answer pattern: request evidence, verify it independently, record it, and repeat on a schedule. A common distractor relies on a vendor's marketing claim or a one-time questionnaire with no testing.
One AI vendor questionnaire item with evidence and mappings · json
{
"id": "AIDD-07",
"domain": "Training data use",
"question": "Will Contoso prompts, files or outputs be used to train or fine-tune any model?",
"acceptableAnswer": "No, unless Contoso opts in by written agreement",
"evidence": ["Data processing agreement clause", "Tenant setting export"],
"mapsTo": ["ADG MC-12", "NIST AI RMF GOVERN 6.1", "ISO/IEC 42001 A.10"],
"riskIfNotMet": "High",
"owner": "Procurement governance lead"
}
Provenance answers three questions for every dataset and model: where did it come from, who changed it, and is this the exact file that was approved? Lineage is the chain of custody, like the evidence log for a forensic exhibit. Without it, a poisoned dataset or swapped model file looks identical to the real one.
diagram
Provenance is a chain: sign at the source, record every change in an append-only ledger, and verify hashes and signatures before anything reaches the approved registry. A mismatch goes to quarantine, not production.
Key points
The May 2025 joint AI Data Security guidance names three data risk areas: the data supply chain, maliciously modified (poisoned) data, and data drift.
It recommends a cryptographically signed, append-only provenance database that records every data change and helps trace poisoned data back to its source.
Checksums and cryptographic hashes detect unauthorized changes in storage or transit; digital signatures authenticate the original data and each later revision.
A hash only proves a file matches its published source; lineage and chain-of-custody tracking are needed to see changes made before publication.
MITRE ATLAS (Adversarial Threat Landscape for AI Systems) mitigation AML.M0014, Verify AI Artifacts, warns against trusting a checksum sent through the same channel as the artifact.
Keep a model registry of versions that were verified, tested and approved, and prefer non-executable, weight-only model formats to block serialization attacks.
Open Source Security Foundation (OpenSSF) Model Signing (OMS) signs models during training and verifies them at upload, at deployment selection and when used as input to another model.
Exam tip
If the question asks how to prove the model in production is the one that was approved, pick hash or signature verification against a trusted registry, not a vendor statement or a newer model version.
Pin model and dataset digests, then record the approval in a signed tag · bash
# Pin the approved model and dataset by digest
sha256sum contoso-model.safetensors claims-2026-q1.parquet > approved.sha256
# Re-verify at deploy time against the digests from the trusted registry
sha256sum --check approved.sha256
# Record the approval in a signed, annotated tag and verify it
git tag -s model-v2.1.0 -m "Approved model and dataset digests"
git tag -v model-v2.1.0
A software bill of materials lists the ingredients of an application. An AI bill of materials extends that list to models, datasets and the configuration that makes an AI system behave the way it does. When a dataset or base model turns out to be compromised, it shows in minutes which systems use it.
diagram
What an AI bill of materials tracks, following MITRE ATLAS mitigation AML.M0023. Each entry carries a version, a source and a cryptographic digest.
Key points
MITRE ATLAS (Adversarial Threat Landscape for AI Systems) mitigation AML.M0023, Maintain an AI Bill of Materials, covers models, datasets, packages, runtimes, container images and agent configs.
An AI Bill of Materials (AI-BOM) records versions, sources, suppliers and cryptographic digests, plus derivations such as which base model and dataset produced a fine-tune.
For agents, ATLAS adds system instructions, connected tools and data sources, and the provider and version of any external AI service.
CycloneDX added Machine Learning Bill of Materials (ML-BOM) support in version 1.5 with the component types machine-learning-model and data and a modelCard object.
CycloneDX, developed by OWASP and Ecma International TC54 and published as standard ECMA-424, is at version 1.7, released on 21 October 2025.
The CycloneDX modelCard holds model parameters such as task and datasets, quantitative analysis, and considerations including limitations and fairness assessments.
ATLAS Code Signing (AML.M0013) advises cryptographically signing software bill of materials (SBOM) and AI-BOM components that track model or data provenance.
Exam tip
A plain software bill of materials (SBOM) misses models and datasets. When a question asks which artifact traces a compromised training dataset to every affected deployment, choose the AI-BOM or ML-BOM.
CycloneDX ML-BOM fragment: a vendor model linked to its training dataset · json
The EU AI Act assigns duties by role: providers build and place AI on the market, deployers use it. Roles can change. Rebrand or substantially modify a high-risk system and the provider's obligations come with it, and suppliers of components must put their support in writing.
diagram
Article 25(1) has three triggers. Any yes turns a deployer, importer or distributor into the provider with Article 16 duties, and the original provider must then cooperate.
Key points
Under Article 25(1), a distributor, importer, deployer or other third party becomes the provider of a high-risk AI system if it rebrands, substantially modifies or repurposes it into high-risk.
The new provider takes on the Article 16 provider obligations, and the original provider must cooperate with information, technical access and other assistance.
The Digital Omnibus spelled that cooperation out: technical documentation, known limitations and failure modes, and targeted technical access for testing and validation.
Article 25(4) requires a written agreement between a high-risk provider and suppliers of AI systems, AI models, tools, services, components or processes integrated into it.
That duty excludes free and open-source tools and components, but not general-purpose AI models, and the AI Office may publish voluntary model contract terms.
Deployers (Article 26) must follow the instructions for use, assign competent human oversight, monitor operation and keep automatically generated logs for at least six months.
Regulation (EU) 2026/1744 set these duties to apply from 2 December 2027 (Annex III) and 2 August 2028 (Annex I); legacy systems used by public authorities must comply by 2 August 2030.
Exam tip
Role-switch questions are common: a company that puts its own brand on a vendor's high-risk system is now the provider. Pick the answer that assigns Article 16 obligations to the rebrander.
General-purpose AI models, such as large foundation models, sit at the top of many AI supply chains. The EU AI Act makes their providers give downstream builders enough information to use the model safely and lawfully. For a buyer, those documents are ready-made due diligence evidence.
diagram
Article 53 sends different documents to different audiences: Annex XII information to downstream providers, Annex XI documentation to the AI Office on request, and a training content summary to the public.
Key points
EU AI Act obligations for providers of general-purpose AI (GPAI) models have applied since 2 August 2025 and were not postponed by the Digital Omnibus.
Article 53(1)(a) requires technical documentation per Annex XI, including training, testing and evaluation results, for the AI Office and national authorities on request.
Article 53(1)(b) requires information per Annex XII for downstream AI system providers, so they understand capabilities and limitations and can meet their own obligations.
Article 53(1)(c) requires a copyright policy that honors text-and-data-mining opt-outs, and 53(1)(d) a public training content summary using the AI Office template.
Open-source GPAI models with public weights are exempt from 53(1)(a) and (b), but the exemption does not apply to models with systemic risk.
The GPAI Code of Practice has three chapters: Transparency and Copyright for all GPAI providers, and Safety and Security only for providers of systemic-risk models.
The Transparency chapter's Model Documentation Form gives providers one template for the information downstream providers and the AI Office need.
Exam tip
If a downstream company cannot get documentation about a foundation model's limitations, the duty sits with the GPAI provider under Article 53(1)(b), not with the downstream builder or its customers.
The contract is where vendor promises become enforceable. AI contracts need clauses that ordinary software contracts skip: whether the buyer's data can train the vendor's model, what happens when the model changes, who explains a decision to an affected person, and who pays if a dataset infringes someone's rights.
diagram
Four clause families that AI contracts add on top of ordinary software terms. They combine ADG, the EU model clauses, GDPR Article 28 and the 2026 joint supply chain guidance.
Key points
EC-Council's ADG (Adopt, Defend, Govern) framework calls for AI contract clauses on incident notification, data handling, model change management and liability allocation, plus rollback and exit plans.
The EU model contractual clauses for AI procurement (MCC-AI), updated in 2025, come as a High-Risk version, a Light version for non-high-risk AI, and a commentary.
MCC-AI mirror EU AI Act Chapter III: risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness and cybersecurity.
MCC-AI add a supplier duty to help explain individual decisions, rights to and handover of datasets to limit lock-in, indemnities, and audit rights in the High-Risk version.
MCC-AI deliberately leave out intellectual property, payment, applicable law and liability terms; they are annexed to a main contract that covers those.
General Data Protection Regulation (GDPR) Article 28 binds a processor to documented instructions, authorized sub-processors, audits, and deletion or return of data at the end.
The 2026 joint AI supply chain guidance suggests clauses restricting training on the buyer's data, defining cloud residency, granting audit rights and setting continuity requirements.
Exam tip
When asked how to stop a vendor training on the organization's prompts, the governance answer is a contractual data-use restriction backed by audit rights, not a verbal or sales-deck promise.
A procurement checklist makes AI buying repeatable: the same questions, gates and sign-offs every time, scaled to the risk of the use case. It catches problems that are cheap to fix before signature and expensive after, such as vendor lock-in or unclear data-use rights.
diagram
A risk-tiered procurement runs from planning to operation, and a material vendor change loops back to due diligence. Exit and portability terms are settled at contract, not at renewal.
Key points
Start by classifying the use case (control MC-2 in EC-Council's ADG framework) so that the depth of due diligence, testing and contract terms matches its risk tier.
EC-Council's ADG (Adopt, Defend, Govern) framework puts AI governance questions into procurement and vendor risk assessments and lists a procurement governance lead among GOVERN roles.
US Office of Management and Budget (OMB) memo M-25-22 (April 2025) replaced M-24-18 and has federal agencies run AI acquisitions with a cross-functional team.
M-25-22 asks for lock-in protections in solicitations: knowledge transfer, clear data and model portability, clear licensing terms and pricing transparency.
M-25-22 says agency processes should ensure contracts permanently prohibit using non-public agency data and outputs to further train commercial AI absent explicit consent.
Test and evaluate proposals before award, and write monitoring, reassessment triggers and an exit plan into the contract rather than adding them after go-live.
Keep the evidence trail: the ADG Vendor AI Due Diligence Record documents assessments, contractual AI clauses and shared responsibility boundaries.
Exam tip
Scenarios reward checklists that are risk-tiered and cover the whole life cycle. Prefer the option that settles exit and portability terms at selection over one that negotiates them at renewal.
Signing the contract starts vendor assurance; it does not finish it. Vendors change models, sub-processors and features, so buyers keep collecting evidence: certifications, attestations, their own test results and incident history. A certificate is a snapshot, while monitoring is the full film.
Self-attested
Independently verified
AI-specific
STAR for AI Level 1
AI-CAIQ self-assessment
Optional automated validation
AI certification
ISO/IEC 42001 certificate
STAR for AI Level 2
General security
Vendor questionnaire
Policies and answers
Needs testing to trust
Security certification
ISO/IEC 27001 certificate
SOC 2 report
Vendor evidence ranges from self-attested to independently verified, and from general security to AI-specific. Strong assurance combines the right-hand column with the buyer's own monitoring.
Key points
NIST AI Risk Management Framework (AI RMF) MANAGE 3.1 requires regular monitoring of third-party AI risks, and MANAGE 3.2 monitoring of pre-trained models during maintenance.
ISO/IEC 42001 certification shows a vendor runs an AI management system using Plan-Do-Check-Act; it assesses the management system, not each AI application in detail.
The Cloud Security Alliance (CSA) AI Controls Matrix v1.1 (June 2026) has 247 control objectives in 18 domains and maps to ISO/IEC 42001 and ISO/IEC 27001.
CSA STAR for AI Level 1 is an AI Consensus Assessments Initiative Questionnaire (AI-CAIQ) self-assessment; Level 2 is third-party certification via ISO/IEC 27001 or 42001.
EC-Council's ADG (Adopt, Defend, Govern) framework lists vendor AI risk exposure, meaning dependence on third-party models, among its board-level indicators.
Reassess when the vendor changes models, sub-processors or terms; General Data Protection Regulation (GDPR) Article 28 requires notice of new sub-processors so the controller can object.
NIST AI RMF GOVERN 6.2 expects contingency processes for failures or incidents in high-risk third-party data or AI systems.
Exam tip
A current certificate is evidence, not assurance on its own. The best answer pairs attestations with the buyer's own monitoring and contractual change notification.