You signed a contract with a vendor. You did your due diligence on that vendor. What you did not sign, and could not do diligence on, is the contract between your vendor and the company whose AI model actually runs inside the tool you bought. That company is your fourth party, and increasingly, it is where the real dependency sits.
For most of the history of supply-chain risk, the tier below your direct supplier was a distant abstraction. With AI it is not. The model doing the work is often two tiers down, run by a provider you have no relationship with, and if it fails, you feel it directly - through a vendor who is, in that moment, just a pass-through.
Where the dependency actually lives
Trace the chain of an AI feature and it rarely stops at the vendor you pay. Your vendor builds a product; the product's AI feature calls a model; that model is often run by a separate company - a foundation-model provider a layer removed. Sometimes there is another layer still: an infrastructure provider hosting the model, a data pipeline in between.
You contracted with the first link. But the capability you actually depend on, the model that reads your data and produces the output your workflow relies on - lives further down. Your tier-one vendor is, for that feature, an intermediary. The thing that would break your process if it went wrong is not always the company you can call.
This is the inversion that fourth-party risk describes: the deeper you go down the chain, the less contractual visibility you have, and the more concentrated the actual dependency often becomes. You have the most control over the link that matters least, and the least over the link that matters most.
Why tier-one assessment doesn't reach it
A conventional third-party programme assesses the companies you contract with. That is its scope by design - you assess who you pay, because that is who you have a relationship with and some power over. The problem is that the AI risk does not respect that boundary.
When you assess your tier-one vendor, you learn about the vendor. You do not automatically learn which model provider sits behind its AI feature, where that provider runs, what it does with data, or how it would fail.
That information exists one contract removed from you - in the agreement between your vendor and its model provider, which you are not party to and usually cannot see. The assessment stops exactly where the dependency starts to matter.
DORA and NIS2 both push against this boundary.
The regulatory direction is clear: for a service supporting a critical function, knowing your direct vendor is not enough, you are expected to understand the chain beneath it to the depth at which the risk actually lives. The assessment boundary and the regulatory boundary have come apart, and the gap between them is fourth-party risk.
The AI twist: the chain converges
There is a feature of AI supply chains that ordinary ones do not share, and it makes fourth-party risk sharper. Traditional supply chains branch outward - many suppliers, many sub-suppliers, diffuse. AI supply chains converge.
Ten different vendors in your estate, each with its own AI feature, can turn out to be running on the same two or three foundation-model providers underneath. The diversity is at the surface, in the vendors you contracted with; the concentration is below it, in the handful of model providers they all quietly depend on.
So fourth-party risk is not just "one more layer to check." It is the layer where your apparently-diverse vendor base can quietly narrow to a few shared dependencies you never chose.
What that convergence means when everyone depends on the same provider is a risk in its own right - concentration risk, and it is worth its own treatment. Here the point is simply that fourth-party mapping is what makes the convergence visible at all.
How to get visibility you have no contract for
The hard part of fourth-party risk is that the usual lever, the contract - does not reach. You cannot due-diligence a company you have no agreement with. So the approach has to be different from tier-one assessment.
It starts with mapping, not contracting. For the vendors that support your critical functions, the task is to establish what their AI features actually run on - which model providers, which sub-processors, where.
Some of this comes from the vendor's own sub-processor disclosures and DPAs; some has to be asked for directly; and some has to be observed, because it is not disclosed at all. The goal is a map of the chain beneath your critical vendors, drawn to the depth where the real dependency sits.
It is deliberately not a map of everything. Trying to trace every fourth party under every vendor is the trap that makes nth-party risk feel impossible. The discipline is the one from criticality classification: go deep only where the function is critical.
For a vendor supporting a function you could not operate without, you trace the chain down to the model provider and beyond; for a peripheral vendor, the direct relationship is enough. Depth follows criticality, or the exercise drowns.
I will be straight about the limit here. You will never have the same assurance about a fourth party that you have about a vendor you contracted with - there is no agreement to enforce, no direct line to pull.
What you can have is a map: knowing that your ten critical vendors run on three model providers, so that when one of those providers has an incident, you know within the hour which of your functions are exposed, rather than finding out from the news.
Fourth-party risk is not a problem you solve by extending your contracts downward. It is one you manage by seeing the chain, and watching the few points where it converges.
Frequently asked questions
What is fourth-party risk?
Montro's definition: fourth-party risk is the risk that comes from your vendors' vendors - the sub-processors, model providers and infrastructure companies your direct suppliers depend on, which you have no contract with but still rely on. For AI, the fourth party is often the foundation-model provider running the model inside your vendor's tool. It matters because the capability you actually depend on frequently sits below the tier you contracted with, where your visibility and your power to demand anything are weakest.
Why doesn't third-party risk assessment cover fourth parties?
Because third-party assessment is scoped to the companies you contract with, and a fourth party sits one contract removed - in the agreement between your vendor and its model provider, which you are not party to. Assessing your tier-one vendor tells you about that vendor, not about the model provider behind its AI feature.
The assessment stops where your contractual relationship stops, which is not where the dependency stops.
How is fourth-party risk different for AI supply chains?
AI supply chains converge where traditional ones diverge. Many different vendors, each with its own AI feature, often run on the same small number of foundation-model providers underneath. So a vendor base that looks diverse at the surface can narrow to a handful of shared dependencies one tier down. Making that convergence visible is the job of fourth-party mapping; what to do about the concentration it reveals is a related but separate question.
How do you manage a fourth party you have no contract with?
Not through contracting, which does not reach that far, but through mapping. For vendors supporting critical functions, establish what their AI features run on - model providers, sub-processors, locations - using sub-processor disclosures, direct questions, and observation where nothing is disclosed. The realistic goal is a dependency map that tells you which of your functions are exposed when a given fourth party fails, rather than the enforceable assurance you get from a direct contract. Depth should follow criticality: trace deep only where the function warrants it.
).jpeg)
