AI Vendor Evidence Gap Notes #5
A subprocessor list is useful evidence.
It is not the actual AI data path.
An AI vendor may publish a list of third-party service providers. That list may show which subprocessors the vendor is permitted to use.
But for a buyer, the review question is narrower:
Which provider touches which data, for which product feature, in which region, under which contract boundary, for which use case, and for how long?
If that is not answered, the subprocessor list remains source material.
It is not evidence-complete for AI vendor review.
Claim
The vendor says:
“We maintain a subprocessor list.”
Or:
“Our current subprocessors are listed here.”
Or:
“We only share customer data with approved subprocessors.”
Or:
“Customers will be notified of subprocessor changes.”
These statements may support a baseline third-party disclosure process.
They do not automatically show how data moves through the actual AI workflow.
Why it sounds sufficient
A subprocessor list feels concrete.
It usually includes company names, service descriptions, locations, and sometimes update dates or notification terms.
For a standard SaaS review, this may support a basic third-party processing check. The buyer can see that cloud infrastructure, analytics, support, security tooling, logging, email delivery, or AI infrastructure providers may be involved.
That matters.
But AI vendor review usually needs more than a list.
A buyer may be sending prompts, files, meeting audio, transcripts, source code, customer records, support tickets, embeddings, metadata, logs, or generated outputs into a specific product workflow.
A static subprocessor list may not show which of those data types each third party touches.
It may not show whether a model provider processes prompts and outputs. It may not show whether transcription, embedding, retrieval, safety filtering, support access, logging, analytics, or abuse monitoring follow different paths.
The list names possible processors.
It does not explain the operating path.
What it actually proves
A subprocessor list may show that the vendor discloses third parties, identifies their general functions, maintains an update process, and may notify customers of changes.
These are useful evidence points.
They establish disclosure practices.
They do not establish the buyer’s actual AI workflow.
A public evidence example
The CodeYourCompliance public evidence profile for Vercel records several public evidence surfaces observed as of 27 June 2026, including the Trust Center, DPA, subprocessor disclosures, AI data-use terms, and the separate v0 Enterprise Addendum.
The profile is an evidence index. It is not verification of an operating data path.
For v0, Vercel’s public Trust Center materials identify certain providers and describe functions such as model inference, AI services, monitoring, and analytics.
Separately, Vercel’s AI Gateway documentation describes provider ordering and fallback behaviour for AI Gateway.
These are different product surfaces.
They should not be combined into one product-level conclusion.
Together, they illustrate the evidence problem: a subprocessor disclosure may identify possible participants, while product documentation may describe possible routing behaviour.
Neither source alone shows which provider handled a particular request, what data was sent, whether fallback occurred, what the provider retained, or whether the same path applied to the buyer’s product, plan, configuration, and region.
The list identifies possible participants.
The product documentation describes possible routing.
The buyer still needs the workflow-level map.
What it does not prove
A subprocessor list does not automatically establish:
Product and feature use. A provider listed at company level may not participate in the exact product, feature, plan, or configuration under review.
Data-type coverage. The list may not show whether a provider receives prompts, outputs, files, transcripts, embeddings, metadata, logs, support records, or safety events.
Routing and fallback. It may not show which provider handles a request, whether routing changes by region, or whether another provider is used after failure, timeout, or capacity constraints.
Retention and access. It may not explain what each provider stores, how long it is retained, who can access it, or how deletion is propagated.
Contract scope. It may not show whether the relevant processing path is covered by the customer’s DPA, order form, product addendum, objection rights, or regional commitments.
The buyer may therefore record:
“Subprocessor list reviewed.”
But the review file still does not establish the actual AI data path.
Weak-answer pattern
This is the list-without-routing pattern.
The vendor provides a subprocessor list, and the buyer records it as if the data path were understood.
But the list does not show which provider handles prompts, embeddings, logs, support records, or fallback traffic for the specific workflow.
Without that mapping, the list is a directory.
It is not the data path.
Evidence request
Do not ask only:
“Can you provide your subprocessor list?”
Ask for feature-level routing.
A stronger request is:
Please map the subprocessors and model providers involved in the specific product, plan, region, and AI workflow under review, including which data types each provider receives, processes, stores, logs, or can access.
Then ask:
Which providers are used for the exact product, plan, feature, configuration, and region?
Which data types does each provider receive, process, store, log, or access?
Can model routing, fallback, support, monitoring, or safety workflows change the provider path?
What retention, deletion, and human-access terms apply at each provider?
Which DPA, addendum, order-form term, or customer control confirms the boundary?
That is how a subprocessor list becomes reviewable.
Review note
A weak review note says:
Subprocessor list available.
A stronger review note says:
The vendor provides a subprocessor list, but the list does not by itself establish the actual AI data path for the intended workflow. The buyer should confirm which subprocessors and model providers process each relevant data type, which product features use them, whether routing differs by plan, region, or configuration, whether support and monitoring systems receive customer content, and which contract terms confirm the processing boundary.
That note does not say the vendor is unsafe.
It says the subprocessor evidence has not yet been mapped to the workflow.
Usage boundary
Until provider routing is mapped, usage should remain bounded.
Limit use to low-sensitivity internal data. Do not introduce customer-confidential data, regulated data, source code, employee records, or privileged business material where uncertainty about provider routing, retention, support access, or regional handling would materially change the appropriate usage boundary.
That is not approval.
That is review preparation.
The review unit is:
vendor + product + plan + use case + data type + region + contract terms + evidence date.
A subprocessor list can support the review.
It cannot replace the actual AI data path.
Boundary
This material is for evidence structuring and review preparation. It does not provide legal, regulatory, audit, procurement, certification, or implementation advice.
The goal is not to approve or reject a vendor.
The goal is to make the evidence gap visible before real data use.
Reply to request the sanitized sample evidence gap memo.