To assess an AI security vendor's data residency, trace each copy of source and source-derived content from repository access through deletion. Record where code is downloaded, examined, sent for inference, logged, backed up and made available to support staff. Ask for the exact service, endpoint, model route and region for each step, then test a bounded pilot. “Hosted in the EU” establishes little about where a model executes or who can remotely read a report. The answer changes with the selected model, endpoint, inference profile, logging configuration, backup design and support arrangement. For example, Amazon Bedrock distinguishes single-Region, geographic and global inference routes; they have different processing-location implications (AWS model availability guide).
This review is about an actual configuration for your account and workflow. A vendor architecture diagram is useful, but it is not evidence that the proposed route is deployed, enforced and used for every job. Conversely, absence of a source file in a database does not establish absence from a task disk, prompt, error trace or retained backup.
Define the promise before inspecting the diagram
Ask your security, privacy and engineering owners to write one sentence that can be tested. These are different requirements:
| Possible requirement | What must be checked |
|---|---|
| Source is stored in a chosen EU region | Durable source objects, databases, indexes, logs and backups; regional replicas and restores |
| Source is processed only in EU member states | Acquisition, scanner compute, model inference, temporary files, telemetry and any human access to source-bearing content; the country of every allowed destination |
| Source is processed in one named region | Every source-bearing step and model destination is confined to that region, including failure and capacity fallbacks |
| Source is not retained after an assessment | Source copies, prompts, model outputs, caches, logs, exports and backups each have a specified deletion or expiry event |
| Vendor staff cannot read source | The complete cryptographic and operational access design, including service identities, support paths and recovery roles |
The last row is a separate access claim. Server-side encryption can protect stored media while an authorized service still receives plaintext. Treat a region claim and an access claim as two questions with two evidence packets.
If the repository can contain personal data, counsel should also assess the applicable contractual and transfer obligations. The European Data Protection Board's guidelines on international transfers include remote access examples; an EU storage location by itself does not answer the legal question. This article provides a technical fact-finding method, not a legal classification of any particular flow.
Illustrative case: an EU repository and a regional dashboard
Illustrative case; CedarPay, its repository and all configurations below are invented. CedarPay is evaluating a source-review vendor for an EU billing service. The vendor proposal says “EU hosted.” The proposed dashboard and findings database are in AWS Europe (Ireland). A scanner task downloads a pinned revision of one private repository. It sends selected source excerpts to an AI model and publishes source-derived explanations. CedarPay requires processing in Ireland specifically, because its internal approval covers only that region.
The first diagram from the vendor shows the dashboard and database. It leaves out the Git provider, task-local disk, model call, invocation logs and a support export. CedarPay requests a flow record and one synthetic trial. The vendor names an AWS eu. inference profile but does not supply its destinations. CedarPay marks the inference location unresolved: AWS says a profile may route across regions and warns against relying on its geographic prefix alone (supported inference profiles). The separate inference-route decision record shows how to compare a destination list with an Ireland-only rule.
Reconcile four artifacts that initially appear to agree
CedarPay receives four fictional artifacts: a dashboard screenshot naming Ireland, a scanner task placement record naming Ireland, a disabled invocation-logging setting, and a successful synthetic job whose metadata reports Ireland. None shows what a timeout does. The reviewer adds a synthetic marker, CEDAR-TRACE-7, to a harmless source comment and asks the vendor to trace one normal job and one failed job through every recipient. This is a proposed diligence exercise; the observations below are invented, not an executed trial.
The second packet changes the decision:
| Artifact or observation | What it supports | What it contradicts or leaves open |
|---|---|---|
| Task placement T9 in Ireland | Acquisition/inspection compute for the sampled job is regional | Does not establish model destination or telemetry processing. |
Config C12 selects an eu. profile |
Identifies the allowed inference route | Its full destination set is wider than Ireland; sampled local success cannot narrow the set. |
| Bedrock invocation logging disabled | That optional customer logging feature is off in the named Region | Does not answer provider abuse-retention rules or vendor traces. |
Timeout trace includes CEDAR-TRACE-7 |
Vendor error handler copied prompt content into telemetry | The telemetry processor was absent from the first diagram; its processing location and retention are unknown. |
| Support export contains a cited code fragment | Source-derived reports can carry source into attachments | “We never retain repository files” does not cover this copy. |
| Cancellation receipt stops the task | The sampled acquisition task ended | It does not prove deletion of the timeout trace or support attachment. |
The missing arrows matter more than the number of green boxes. The revised flow is repository → Ireland task → model route → report, with branches from the task to telemetry and from the report to support. The vendor must identify the operator, location, content class and lifetime for each branch. A “source-derived” label describes origin; it does not make the content harmless or outside CedarPay's rule.
Make the decision turn on the evidence
CedarPay holds private billing source. The geographic model route already fails its Ireland-only requirement. The source-bearing timeout trace also has an unknown recipient boundary. These are independent blockers: replacing the model alone would not close the telemetry gap.
The fictional remediation packet removes prompt bodies from the timeout event and supplies the telemetry schema, but a synthetic failure record still contains the marker in a nested exception field. CedarPay keeps that row open. A normal-job demonstration would have missed it. The required follow-through is the shared serialization path, including nested errors, and a new failure-path record showing the permitted metadata without content.
For the support export, the vendor proposes disabling attachments for this pilot and retaining source-free ticket IDs. CedarPay can accept that narrower operating scope if the actual support workflow enforces it. A verbal promise to “be careful with exports” cannot replace an absent data path. The resulting decision record is:
Private-source decision: hold. Required: supported Ireland-only model route and failure behavior; content-free error serialization on normal and exceptional paths; enforceable support-export restriction; separate provider-retention evidence. Allowed now: approved synthetic input. Reopen when: configuration and trial evidence match all four conditions.
This is broader than a model-location check and more useful than a vendor questionnaire scored by yes/no answers. It reconciles configuration, sampled behavior and every content-bearing copy into one purchase decision. The model-route guide handles destination mechanics; the remaining passes below cover the complete workflow.
Follow the bytes in six passes
1. Establish the input boundary
Identify authorized repositories, pins, submodules and file classes, then compare them with the actual acquisition manifest. Distinguish a full archive, individual-file reads and a retained mirror. The installation screen shows potential access; the job record shows what was copied. An analysis exclusion may still permit acquisition of the excluded file.
2. Map task-local and durable copies separately
For each copy, record content class, operator, location, creation event, retention trigger and owner. Include task disks, indexes, prompts, nested error traces, citations, support exports and backups. Cancellation and failed cleanup need their own path through that map. “Ephemeral” should name the event that ends the copy's lifetime; deleting a path does not prove physical erasure. CedarPay's marker exercise is one way to challenge the declared map without supplying private source.
3. Resolve the model route, not just the model brand
Record provider, model version, endpoint, source region, allowed destinations and fallback for every model call. Classify the route as single-Region, geographic or global using the AWS model guide when Bedrock is involved. The checkpoint is whether the dated destination set and failure behavior satisfy the customer's written boundary. Ask the technical owner for the account-specific route evidence; use the filled counsel decision record to decide what it proves.
Do not infer another provider's location from AWS behavior. Google Cloud's Agent Platform data-residency documentation separately describes data at rest and the location of model computation. It says global endpoint requests can be processed worldwide, while jurisdictional endpoints constrain processing to their specified geography. The exact model and feature still need checking. The practical lesson is to obtain the product-specific route and processing commitment, not a generic “cloud region” screenshot.
4. Examine retention at the provider and application layers
For AWS Bedrock, first identify the endpoint and API. For bedrock-runtime, request the account retention policy in the actual source Region; Runtime calls have no project scope. A bedrock-mantle project setting cannot establish that Runtime policy. Then check the exact model's retention requirements and the chosen API path. AWS's current retention documentation describes modes including none, default and aws_review; an unconfigured Region can fall back to a model default. A store=false request alone is not the same as a configured zero-retention mode. This source describes AWS's service behavior, not the vendor application's own prompts, logs, cache or backups.
Ask whether model invocation logging is enabled and where it writes. AWS says Bedrock invocation logging can collect full request and response data and deliver it to same-account, same-Region CloudWatch Logs or S3; it is disabled by default, but a vendor can enable it (Bedrock invocation logging). The procurement answer must state the actual configuration, which operations it covers, who can read it and its retention period. Treat other telemetry and support systems as additional flows.
5. Test access and exceptional paths
Ask who can invoke a source read, view a report section, download a diagnostic bundle, administer a key, restore a backup and grant support access. Identify service identities and emergency roles as well as ordinary staff. Run one authorized read and one deliberately denied read in the pilot. Confirm that reports, exports, search, notifications and support tickets apply the same content boundary. A diagram showing two application checks does not prove that an administrator or backup role cannot read a copy.
Failures often change the path. Ask what happens if a scan times out after source acquisition, if a model call is rejected by the chosen regional route, if logging is temporarily unavailable, or if a support engineer investigates a crash. The desired output is a failure-mode table with data locations and owners, not an unqualified “fail secure” sentence.
6. Reconcile configuration with the contract
Have the technical owner supply dated configuration evidence for the pilot: region IDs, model and profile IDs, retention settings, logging destinations, backup inventory, support access process and deletion job status. Have procurement or counsel compare those facts with the actual agreement and subprocessors. Ask how a model, region, provider or subprocessor change is announced and what approval is required before it can affect source-bearing work. Save the exact version and date of the evidence; cloud offerings change.
Decide with explicit unknowns
A useful decision has three outcomes. Accept for the defined scope when evidence is proportionate to the data and material requirements are met. Use configuration, provider commitments, independent assessments and selected demonstrations together; a buyer cannot directly test every internal copy. Accept a narrower pilot when the location boundary is demonstrated only for synthetic or lower-sensitivity material. Hold when a material source-bearing path has no location, retention or access answer. A marketing claim, a configuration screenshot without the matching production account, or a clean scan result cannot close that gap.
For CedarPay, the immediate action is to close the four conditions in its revised decision record, including the nested timeout trace and support-export restriction. If any source path can leave Ireland, its owner must either choose a different route or obtain a changed internal requirement before connecting billing code.
Next action: draw your own six-row flow table for one repository and ask the vendor to fill every unknown with dated evidence. Continue with questions to ask before connecting a repository and how to distinguish EU hosting from single-region inference.