Fourth-Party AI Risk: Who Sits Behind Your Vendor?

Your company signs a contract with an AI vendor. Procurement checks the vendor. Security reviews its controls. The business approves the use case. Then an outage starts at a company nobody on the approval team has heard of.

The vendor was only the first layer. Its product may depend on an external model, another company's hosting, a document-processing service, or a source of data that can change without your team noticing. Reviewing the company on the invoice does not tell you everything the service depends on.

Fourth-party AI risk management makes those dependencies visible enough to govern. The goal is not to investigate every supplier on earth. It is to find the downstream relationships that could interrupt an important service, change where data goes, or invalidate the decision you already made.

Key takeaways

• A direct vendor review is a starting point. Important AI dependencies can sit behind that vendor.

• Begin with the business service and follow the model, hosting, data and processing relationships that support it.

• A dependency map should distinguish confirmed facts from vendor statements and unanswered questions.

• Ask what happens when a downstream provider fails or changes. A list of names is not a continuity plan.

• Give each material evidence gap and change notice an owner, a decision and a due date.

Step 1: Start from the service, not the supplier list

Pick a business outcome that matters: answering customer questions, reviewing claims, drafting contracts, or routing orders. Name the executive accountable for that outcome. Then identify the AI product supporting it and the direct vendor responsible for the contract.

This keeps the work proportional. A writing aid for optional internal drafts deserves a different level of investigation from a system that influences customer eligibility. The service owner should explain what happens if the AI stops, becomes unreliable, or must be withdrawn.

Step 2: Follow the dependencies that can change the risk

Ask the direct vendor for the layers that matter to your use case:

• Model: whose model is used, how versions are selected, and whether requests can be routed to a different provider.
• Hosting: where the application and inference run, including the regions relevant to your data and availability needs.
• Data and processing: which other services receive prompts, files, outputs, logs or retrieved information, and for what purpose.
• Operational support: which downstream services are necessary for the product to work, be monitored, or be recovered.

Separate live service dependencies from historical inputs. A dataset used to train a model and an API called on every transaction create different risks. Both may matter, but they do not fail or change in the same way.

NIST's Generative AI Profile describes value-chain risks involving datasets, pre-trained models and software components. It recommends attention to supplier assessment, third-party inventories, incident plans and fallback arrangements. That is a useful foundation for the questions, not a guarantee that a vendor can answer every one.

Step 3: Record what you know and what you do not

Use one row per material relationship. Record the source of the information and when it was checked. A subprocessor list can support a data-processing question; it may not establish which model actually serves a particular workflow. A marketing architecture diagram may omit services used for logging or support.

When a vendor cannot disclose a provider, record the uncertainty rather than inventing the missing box. Ask whether an independent assurance report, a contractual commitment or a narrower use case can address the specific concern. If the gap is material to the business decision, it belongs with the authorized risk owner.

Step 4: Agree what happens when a dependency changes

Decide which changes need notice and review: a new model provider, a different processing location, a material subprocessor change, or loss of a fallback. Ask who receives the notice, who assesses it, and what contractual options exist if the change is unacceptable.

Do not assume that a notification email reaches the right person. Put the notice route into the vendor record and test it. The contract owner and the service owner may be different people; both need a clear role.

Step 5: Test one downstream failure

Choose a dependency whose loss would matter and ask the business to walk through it. Can the team continue without the AI? Does the alternate product depend on the same upstream service? Can staff handle the volume manually, and for how long?

A vendor's recovery promise is one input. Your business's ability to operate while that promise is being delivered is another. Keep both on the map.

A dependency map you can use

The following is a fictional example, not a description of any named product. Each row follows one business service through the direct vendor to a downstream dependency.

Service and direct vendor	Downstream dependency	Evidence and open question	Owner and next action
Customer support / Vendor A	External model provider	Vendor architecture note names the provider; automatic model switching is unclear.	Support owner: obtain routing and change-notice terms before expanding use.
Customer support / Vendor A	Document extraction service	Subprocessor list names the service; retention of uploaded files is not confirmed.	Privacy lead: confirm retention and permitted data before enabling uploads.
Customer support / Vendor A	Hosting region	Region is documented; recovery into another region has not been evidenced.	Service owner: request recovery evidence and test the manual fallback.

Add the date checked, notification route and decision reference to each row in your working copy. The point is to turn an unknown relationship into an owned question, then close it with evidence or an explicit decision.

Sources

NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (2024), section 2.12 and GOVERN 6: NIST AI 600-1. The worksheet and fictional example above are practical recommendations, not quoted requirements.

Frequently asked questions

What is a fourth-party AI dependency?

It is a provider or component behind your direct AI vendor that contributes to the service you use. Examples include an upstream model provider, hosting provider, data source or document-processing service. The relevant question is how that relationship affects your service, data or risk decision.

Is a subprocessor list enough?

No single document answers every dependency question. A subprocessor list can identify organizations processing personal data, but it may not describe model routing, recovery arrangements or every operational dependency. Use it alongside architecture information, contract terms and relevant assurance evidence.

What if the vendor will not name an upstream provider?

Record the gap and its business significance. Seek other evidence or commitments that address the concern. If the uncertainty remains material, the authorized owner must decide whether to limit the use, defer it or accept the exposure within policy. Do not treat nondisclosure as proof that the dependency is safe or unsafe.

Who should own the dependency map?

The business service owner should be accountable for the outcome, with procurement, technology, security and privacy supplying the relevant evidence. Assign a named owner to each open question and keep the map connected to the vendor's change-review process.

Closing

The vendor on the invoice is the beginning of the map, not the end. Ask for the next layer, label what you cannot verify, and decide who acts when it changes. That is how a supplier review becomes useful oversight of the service you actually depend on.