AI Supply Chain Risk: The Compliance Gap Most Teams Miss in 2026
Most AI teams secure their own models carefully. Far fewer audit the third-party components their systems depend on. This is the gap enterprise procurement teams are now specifically checking for.
Most AI teams have a reasonable handle on their own models. The gap is everything else.
The third-party components, foundational models, data providers, and inference APIs that most modern AI systems depend on entirely - this is the AI supply chain. And in 2026, it is the compliance gap enterprise procurement teams are specifically looking for.
What the AI supply chain actually is
When most founders say "our AI model," they mean the fine-tuned layer or orchestration logic they built. Underneath that is a stack of third-party components: a foundational model from OpenAI or Anthropic, a vector database from Pinecone or Weaviate, embeddings from a cloud provider, potentially a data labelling service, and inference infrastructure from AWS or Google Cloud.
Every one of these components carries compliance implications. The accuracy and safety properties of your AI system depend not just on what you built but on the quality, governance, and reliability of every component you consume.
If a component fails silently, produces biased outputs because of its training data, or changes behaviour after an unannounced model update, the liability sits with you as the deployer. Not with the vendor.
What EU AI Act Article 28 says about third-party components
EU AI Act Article 28 addresses deployer obligations specifically. If you deploy a third-party AI system, you are responsible for:
- •Ensuring the system is used according to its intended purpose and the provider's instructions.
- •Implementing appropriate human oversight measures for the system.
- •Monitoring the system's performance and reporting serious incidents.
Article 28 does not exempt you from liability simply because you did not build the underlying model. If your product makes consequential decisions using a third-party foundational model, you carry the deployer obligations for that system's outputs.
What NIST AI RMF GOVERN 6 requires
NIST AI RMF GOVERN 6 addresses AI supply chain risk specifically. It requires organisations to:
- •Maintain an inventory of AI components and the third parties that supply them.
- •Assess the governance practices of AI component suppliers - including how they handle model updates, incident disclosure, and data governance.
- •Establish contractual mechanisms for receiving notification of material changes to AI components.
For most teams, the honest answer is no. Foundational model providers push updates continuously. Most SaaS teams have no monitoring in place to detect when upstream model behaviour shifts.
What enterprise procurement teams are asking in 2026
Enterprise security and procurement teams reviewing AI vendors in 2026 are routinely asking for:
- •An AI system inventory listing every third-party component, the vendor, and the version deployed.
- •Evidence of vendor assessment: documentation showing you have evaluated your AI suppliers' governance practices.
- •Incident notification procedures: a written process describing how you would detect and respond to a failure in a third-party AI component.
- •Contractual provisions: do your vendor agreements include obligations on the supplier to notify you of material model changes?
If you cannot answer these questions, you are likely to fail the procurement questionnaire at a large enterprise account.
The vendor update problem
Foundational model providers - OpenAI, Anthropic, Google, Meta - update their models regularly. Some updates are announced. Many are not. Behaviour changes between model versions can be material: different tone, different refusal patterns, different accuracy profiles on specific tasks.
If your product's compliance properties are evaluated at launch and the underlying model changes six months later, your compliance documentation is stale. You are still representing that your system behaves a certain way. The documentation says so. But the system no longer behaves that way.
The EU AI Act and ISO 42001 both require ongoing monitoring of AI system performance. For systems that depend on third-party foundational models, this means monitoring at the API layer: periodic evaluation of model outputs, automated detection of performance drift, and a process for updating documentation when material changes are detected.
The monitoring gap
Beyond vendor model updates, AI supply chain risk includes:
Data provider changes - if your system ingests third-party data feeds, changes to those feeds affect your system's outputs.
Infrastructure provider changes - cloud inference APIs change their behaviour, pricing models, and availability. Are these changes tracked in your governance documentation?
Embedded AI in SaaS - many enterprise SaaS platforms now have AI features enabled by default. If your company uses these platforms and the AI features are active, you are a deployer of those AI systems under the EU AI Act, even if you never explicitly activated the feature.
What you can do this week
The AI supply chain compliance gap is one of the easier ones to start closing because it begins with an inventory exercise:
- •List every AI component in your stack. Foundational models, embeddings, vector databases, inference APIs, data providers. Include the SaaS platforms with AI features enabled.
- •For each component, note: the vendor, the version or model version deployed, when you last evaluated it, and who in your organisation owns the relationship.
- •Check your contracts. Do your AI vendor agreements include notification obligations for material model changes?
- •Establish a monitoring cadence. How often do you evaluate whether your third-party AI components are still performing as expected?
This inventory is the foundation of NIST AI RMF GOVERN 6 compliance and the starting point for EU AI Act Article 28 documentation. It is also the first thing an enterprise procurement team will ask for.