AI Vendor Evidence Gap Notes #8
A country name sounds like a boundary.
“Customer data is stored in the United States.”
“EU data residency is available.”
“Enterprise customers can select a region.”
These statements feel specific.
They identify a place, and a place can make the data path appear settled.
But in an AI vendor review, location is only the beginning of the question.
A residency statement may describe where one category of data is stored while saying little about where the rest of the workflow is processed, cached, backed up, reviewed, or routed.
The review question is not only:
Where is customer data stored?
The better question is:
Which data is covered, what happens to it, which systems and providers receive it, and which parts of that path are actually restricted to the stated region?
A hosting location can be accurate while the geographic boundary remains incomplete.
That is the evidence gap.
Claim
The vendor says:
“Customer data is stored in the United States.”
Or:
“EU data residency is available.”
Or:
“Enterprise customers can select a hosting region.”
These statements may establish that defined customer data is stored within a stated location.
They do not establish the complete geographic path of the buyer’s data.
Why it sounds sufficient
Data residency is often reduced to a country, region, or dropdown selection.
That works well in a questionnaire.
The buyer asks where customer data is hosted. The vendor names a location. The answer appears complete.
But an AI workflow rarely involves one database and one data object.
A single interaction may create:
prompts and outputs;
uploaded files;
audio and transcripts;
embeddings and indexes;
metadata and usage records;
logs and moderation events;
support artifacts;
cached copies;
backups and recovery copies.
The application may store customer records in one region while a model provider, transcription service, analytics platform, support tool, or security service operates through a different path.
The storage location may be clear.
The processing location may not be.
The primary database may sit in one country.
Backups, logs, support systems, local caches, or downstream providers may follow different rules.
This is how a true statement can create the wrong impression.
“Stored in the United States” may accurately describe the primary application environment.
It may not describe the entire service.
What it actually proves
A current, product-specific residency statement may establish that:
a primary hosting region has been identified;
defined customer content is stored in a stated location;
a regional storage option exists;
the vendor has documented a geographic control;
a particular plan or deployment supports regional selection.
These are meaningful evidence points.
They establish something about location.
They do not automatically establish:
which data types are covered;
whether storage and processing occur in the same region;
where external providers operate;
where backups and logs remain;
where support personnel may access data;
whether exceptions alter the path;
whether the commitment is contractual;
whether the same boundary applies to every product, plan, and feature.
Storage is part of the data path.
It is not the whole data path.
A public evidence example
The CodeYourCompliance public evidence profile for Granola records a US data-residency reference among the public evidence surfaces observed for Granola’s AI meeting-notes product.
The profile was last checked on 27 June 2026. It also records that regional residency outside the United States was not observed during that review.
The profile is an evidence index.
It is not implementation verification, a security assessment, or a vendor recommendation.
Granola’s Security, Privacy & Data FAQs states that data is stored on AWS servers in the United States and that EU, UK, Canadian, Australian, and other regional residency options are not currently offered.
The same documentation also says that meeting notes are cached locally on the user’s device.
Granola’s separate security page states that notes are stored in a US-hosted AWS Virtual Private Cloud and backed up daily. It also explains that transcription providers and AI providers form part of the service workflow.
These statements are useful.
They identify the primary hosting environment.
They identify the absence of alternative regional residency options.
They also begin to show that the service involves more than one data location and more than one provider role.
They do not, by themselves, establish:
where each transcription or AI provider processes data;
which data types each provider receives;
where backups and recovery copies are located;
whether local caches follow the same deletion lifecycle;
where support or incident-response access may occur;
whether every plan and feature follows the same path;
which geographic commitments appear in the customer’s contract.
The public profile helps locate the evidence.
The vendor’s own documentation remains the primary source.
Neither should be stretched beyond what it says.
What it does not prove
A data-residency statement does not automatically establish:
Data-type coverage. The statement may apply to notes, prompts, or outputs without covering uploaded files, transcripts, embeddings, metadata, logs, moderation records, support copies, or backups.
Processing location. Data can be stored in one country while being processed elsewhere by model, transcription, security, analytics, or infrastructure providers.
Secondary storage. Caches, indexes, vector stores, observability platforms, disaster-recovery environments, and support tools may follow different location rules.
Provider routing. The buyer may not know which model or service provider receives a request, whether fallback routing occurs, or whether provider selection changes by feature or region.
Human access location. A regional storage claim does not show where support, engineering, safety, or incident-response personnel may access customer data.
Exception paths. Abuse review, legal requests, security investigations, support cases, customer-enabled integrations, and service failures may alter the normal path.
Deletion scope. Deletion from the main application does not automatically establish deletion from local caches, logs, support systems, backups, or downstream providers.
Product and plan scope. A location statement may apply to one application, feature, plan, region, or deployment model without covering the exact service under review.
Contract scope. A public documentation page does not necessarily provide the same commitment as a DPA, order form, service agreement, regional addendum, or negotiated term.
None of these gaps proves that the vendor is handling data improperly.
They show that the location claim is narrower than the decision the buyer is trying to make.
Weak-answer pattern
This is the country-without-path pattern.
The vendor names a hosting region.
The buyer records:
“Data hosted in the United States.”
Or:
“EU residency available.”
But the review file does not identify:
which data types are covered;
where processing occurs;
which providers receive the data;
where logs and backups remain;
where support access may occur;
which exceptions change the path;
which product and plan are covered;
which contract term supports the boundary.
The answer may be accurate.
The geographic scope is still incomplete.
Evidence request
Do not ask only:
“Where is customer data hosted?”
Ask for the data-location map.
A stronger request is:
Please provide a product- and plan-specific data-location map for the intended workflow. For each relevant data type, identify where it is stored, where it is processed, which providers receive it, where backups and recovery copies are held, where human or support access may occur, which exceptions may alter the path, and which contractual source supports the stated regional boundary.
Then ask:
Which data types are covered by the residency commitment?
Does the stated region apply to both storage and processing?
Which model, transcription, infrastructure, security, and analytics providers receive data?
Can routing or fallback move processing to another provider or region?
Where are logs, caches, indexes, backups, and recovery copies located?
From which locations may support, engineering, safety, or incident personnel access the data?
Do integrations or customer-enabled features change the path?
Does the boundary differ by product, plan, configuration, or feature?
Which DPA, order-form term, or regional addendum confirms the commitment?
The vendor does not need to disclose sensitive architecture.
It does need to establish a geographic boundary that the buyer can use.
Review note
A weak review note says:
“Customer data is hosted in the United States.”
A stronger review note says:
The vendor identifies a customer-data hosting region, but the available evidence does not establish the complete geographic scope of processing, provider routing, logs, caches, backups, support access, subprocessors, or exception paths. The response is not evidence-complete for a use case requiring verified in-region storage and processing.
That note does not say the residency statement is false.
It prevents a storage-location claim from being treated as proof of the complete data path.
Usage boundary
Until the geographic path is evidenced:
Limit use to data that does not require verified in-region storage and processing. Do not introduce regulated, highly confidential, customer-restricted, or contract-restricted data where uncertainty about processing locations, providers, backups, support access, or exception paths 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 residency claim can support that review.
It cannot replace the data path.
A country name is evidence.
It is not regional coverage.
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 if you want the sanitized sample evidence gap memo.
#AIVendorRiskAssessment #DataResidency #AIGovernance