Fourth-Party AI Risk: The Unmapped Supply Chain Layer

Here's the data flow for a typical SaaS vendor that added AI features last quarter:

Your Organization
  │  Customer PII, financial data, health records
  ▼
SaaS Vendor (your Tier 1, assessed annually)
  │  Sends prompts containing your data to inference API
  ▼
AI Model Provider (OpenAI / Anthropic / Google / Meta)
  │  Processes inference on shared infrastructure
  ▼
Cloud Infrastructure (Azure / AWS / GCP)
     Compute, storage, networking

Your risk assessment covers the first link. Probably. If your questionnaire is current and the vendor answered honestly. As we explore in Your Vendors Are Deploying AI. Your Risk Program Hasn't Noticed., most organizations don't even have visibility into the first layer of vendor AI deployment, let alone the layers beneath it.

The model provider? Not assessed. The infrastructure provider underneath that? Not even on your radar. Your regulated data flows through all four layers. Your risk program maps one.

This is the fourth-party AI risk problem. And almost nobody has a handle on it.

Why Fourth-Party Risk Is Different With AI

Fourth-party risk isn't new. Your vendors have always had sub-processors and hosting providers. Traditional fourth-party management meant requiring sub-processor disclosure and change notification. Workable, because data flows were straightforward: vendor stores data on AWS, data stays in the contracted region.

AI breaks this model in three ways.

Data flows to inference APIs are dynamic and opaque. When your vendor sends a prompt to a model provider's API, your data enters a shared inference pipeline. Where inference happens, how long data is retained, and whether it's used for model improvement depends on terms your vendor may not have negotiated beyond the default.

Model providers aggregate data across customers. A traditional sub-processor keeps your vendor's data isolated. AI model providers operate differently. Inference requests from thousands of customers flow through shared infrastructure. Default API terms for many providers allow using interaction data for model improvement. Your vendor may have opted out. Or not.

The risk surface is novel. Model providers face risks traditional sub-processors don't: training data poisoning, prompt injection, model theft, output reliability failures. Your vendor's SOC 2 doesn't cover the model provider. The model provider's SOC 2 (if they have one) doesn't cover the specific way your vendor integrates their API.

The Regulatory Push for Supply Chain Visibility

Two regulatory frameworks now explicitly require visibility into AI supply chains.

EU AI Act value chain obligations. The Act creates obligations across the entire AI value chain, not just for developers. If your organization deploys an AI system (even through a vendor), you have deployer obligations under Article 28. You need to understand what AI systems operate in your environment, including those run by third parties. The August 2026 deadline is three months away. "We assessed the vendor but not their model provider" won't satisfy an auditor.

NIST AI RMF supply chain requirements. The MAP function of NIST AI RMF calls for identifying AI risks across the supply chain, including risks introduced by third-party components. If a vendor integrates a third-party model and that model has reliability or bias issues, the risk flows upstream to your organization. NIST expects you to have mapped that chain.

Anatomy of a Fourth-Party AI Incident

Your vendor uses an AI model provider for a feature that processes customer support tickets. The model provider suffers a security incident: an employee exfiltrates training data that included prompt-response pairs from API customers, including prompts containing your customer PII.

The notification chain: Model provider discovers the incident (Day 0). Notifies your vendor (Day 3, maybe). Vendor assesses impact (Day 5-10). Vendor notifies you (Day 10-14, if contractually required). You assess impact on your data subjects (Day 15-20). You notify regulators (Day 20+, potentially past GDPR's 72-hour window). This is exactly why the annual vendor questionnaire is dead as a risk management tool -- point-in-time assessment cannot catch incidents that unfold between cycles.

At every link, information degrades and time is lost. If you don't know the model provider exists, step 4 might not happen until the next assessment cycle.

Compare that to a mapped chain where you're monitoring the model provider's SecurityScorecard. You see the score drop before the vendor notifies you. You initiate contact proactively. That's the difference between mapped and unmapped fourth-party risk.

What You Don't Know About Your Vendors' AI Providers

Most organizations that have asked vendors about AI got answers like "yes, we use AI." Surface-level disclosure that tells you nothing actionable. Here's what you actually need to know:

Model provider identity. Which specific provider? The risk profile of an open-source model self-hosted by the vendor is completely different from an API call to a cloud-hosted proprietary model.

Data transmission specifics. What data is included in prompts? Full customer records, summaries, anonymized fields? What's the retention period on the model provider's side?

Training data usage. Does the model provider use API interaction data to train or fine-tune models? Has the vendor opted out? Can you verify?

Contractual terms. Standard API ToS or negotiated enterprise agreement? Default terms for most model providers include broad data usage rights that may conflict with your data processing agreements.

Incident notification path. If the model provider has a security incident, how and how fast does the vendor learn about it? Contractual obligation or reliance on public disclosure?

Geographic processing. Where does inference happen? Model providers don't always guarantee processing in a specific region unless explicitly contracted. For regulated data, geography matters.

How Kyudo Maps the Fourth-Party Chain

The core challenge with fourth-party AI risk is structural. You need a data model that can represent multi-layer relationships and query across them. Spreadsheets and traditional GRC tools track vendors as flat lists. AI supply chains are graphs.

Knowledge Graph modeling. Kyudo's Vendor Risk Management module uses the Compliance Graph to represent the full chain as connected nodes: Vendor → Sub-vendor → Model Provider → Data Sharing Agreement → Certification → Incident. Each relationship has attributes: what data flows between nodes, under what contractual terms, with what access patterns.

When you ask "Which of my vendors use OpenAI?", Kyudo doesn't search a text field. It traverses the graph and returns every vendor with a documented relationship to OpenAI as a sub-processor, along with the data flows, contractual terms, and assessment status for each.

Structured fourth-party questions in assessments. Kyudo's VRM questionnaire templates (SIG Lite, SIG Core, CAIQ, and custom) include fourth-party AI sections. Not a generic "do you use AI?" checkbox, but specific questions:

List all AI model providers used in products that process customer data
For each provider, describe the data included in API calls
Provide the model provider's data processing terms or enterprise agreement
Confirm whether API interaction data is excluded from model training
Describe the incident notification path from model provider to your organization
Specify the geographic regions where inference processing occurs

These responses become structured data in the Knowledge Graph, not free text in a PDF.

Continuous monitoring of disclosed sub-processors. Once a vendor discloses their model provider, Kyudo monitors that provider through the same signal categories used for direct vendors: SecurityScorecard ratings, breach intelligence, financial health, and compliance status. If the model provider's security posture degrades, you see the signal correlated to every vendor that depends on them.

Intelligent pre-fill and validation. When a vendor reports using a specific model provider, Kyudo cross-references that claim against known data: the model provider's public certifications, their documented data processing practices, and any incidents in the breach database. If the vendor claims their model provider is SOC 2 compliant but the certification expired four months ago, the discrepancy is flagged during assessment review.

"We Can't Assess Our Vendors' Vendors"

This is the objection that stops most fourth-party risk conversations cold. And it contains a truth: you can't send a SIG Core questionnaire to OpenAI and expect a response. You don't have a contractual relationship with your vendor's model provider. You can't audit them directly.

But "we can't directly assess fourth parties" is different from "we can't manage fourth-party risk." Three mechanisms give you meaningful visibility without direct access.

Contractual requirements on your vendor. Your vendor agreement can (and should) require disclosure of AI sub-processors, notification of sub-processor changes, specific data processing terms with model providers, incident notification obligations that flow through to fourth-party incidents, and the right to review vendor's assessments of their own sub-processors.

You're not assessing the fourth party directly. You're requiring your vendor to assess them and share the results.

Public intelligence on model providers. Major model providers (OpenAI, Anthropic, Google, etc.) publish security documentation, obtain SOC 2 and ISO 27001 certifications, and are covered by security rating platforms. You can monitor their posture without a contractual relationship. It's not as thorough as a direct assessment, but it's far better than zero visibility.

Signal correlation across your vendor portfolio. If you have 15 vendors that all use OpenAI, a single signal about OpenAI (breach, score drop, certification expiry) affects all 15 vendor risk profiles simultaneously. The Knowledge Graph makes this correlation automatic. Without it, you'd need to manually cross-reference your vendor list against news about every model provider.

Your Monday Morning Checklist

1. Ask the basic question. For your top 10 vendors by data sensitivity, ask: "Does your product use any third-party AI models or AI service providers to process our data?" If you haven't asked this yet, start here. The answers (and the non-answers) will tell you the scope of your blind spot.

2. Update your vendor agreements. For new contracts and renewals, add clauses requiring disclosure of AI sub-processors, notification of sub-processor changes (with a specific timeframe, not "reasonable notice"), and flowing of incident notification obligations through to AI providers. If you're subject to the EU AI Act, our guide on the EU AI Act deadline and AI inventory covers the specific contractual language you'll need.

3. Map what you already know. Some vendors have already disclosed AI usage in marketing materials, changelogs, or support docs, even if they haven't told your GRC team directly. A quick scan of vendor product pages for "AI" and "machine learning" gives you a starting inventory.

4. Identify concentration risk. If seven of your Tier 1 vendors all use the same model provider, you have concentration risk at the fourth-party layer. A single incident at that model provider affects seven critical vendor relationships simultaneously. You can't manage concentration risk you haven't mapped.

5. Start monitoring model providers. Add the major AI model providers (OpenAI, Anthropic, Google DeepMind, Meta AI) to your SecurityScorecard or BitSight watchlist. You may not have a contractual relationship with them, but you have a data relationship with them through your vendors. Monitor accordingly.

The supply chain for AI isn't a chain. It's a web of dependencies, model providers, infrastructure layers, training data pipelines, and inference endpoints that your traditional VRM program was never designed to see.

You don't need to map every node on day one. But you need to start mapping now, because your data is already flowing through layers your risk program pretends don't exist.

<a href="/product/vendor-risk" className="cta-button">Try the AI risk assessment</a>