How to distinguish EU hosting from single-region inference

An application can be hosted in Ireland while its AI model processes a source excerpt elsewhere. To decide whether a proposed route meets a location rule, write the rule in terms of allowed processing regions, obtain every destination for the exact model and source region, and check the deployed fallback. An AWS eu. profile name alone does not establish processing in one region or even, for every source region, only in EU member states. AWS tells customers with residency requirements to inspect the destination model ARNs returned by GetInferenceProfile from each source region (AWS inference-profile guidance).

This guide gives privacy counsel a filled inference-route decision record. It evaluates one model call and names the evidence the technical owner must supply. For the wider review of acquisition, logs, backups, support and deletion, use the source data-flow diligence guide. A route decision does not settle those other flows or the legal treatment of remote access.

A filled record for an Ireland-only rule

Illustrative case: Elmbridge Health, its policy and the proposed vendor deployment are invented. The AWS model route and destination list below come from public AWS documentation checked on 19 October 2026; no vendor account was inspected. Elmbridge's privacy counsel has written a technical acceptance boundary for this pilot: patient-related source excerpts, prompts and model outputs may be processed in AWS Europe (Ireland), eu-west-1, only. A capacity retry or fallback must fail closed rather than process them in another region. The boundary is deliberately narrower than “EU only.”

The vendor proposes Amazon Bedrock Runtime with source region eu-west-1 and geographic profile eu.anthropic.claude-opus-5-5. Its report database is also in Ireland, but that fact does not establish the model destination. AWS's Claude Opus 5.5 model card lists these possible destinations for that profile when invoked from Ireland:

All six are EU member states, so this documented Ireland-origin model route may fit an EU-member-state boundary. Five are outside Ireland, so it fails Elmbridge's written rule. The public model card is a reference for the route, not proof that the vendor actually invokes that model, starts every call in Ireland or enforces the proposed configuration. AWS notes that source regions can have different destination sets; the same card shows Zurich as a destination when the profile is called from Zurich and London when called from London. Neither Switzerland nor the UK is on the EU member-state list. A reviewer must map the actual source-specific list to countries instead of treating the eu. prefix as a legal geography (AWS model card, profile guidance).

Here is the decision as Elmbridge would file it:

This is a route decision, not a finding that the invented vendor mishandled data. If Elmbridge changed its policy to allow processing across named EU member states, counsel would still need the account-specific destination list and runtime controls before approving that revised route. The privacy and contract review would then use the full data-flow record.

Do not convert a geographic profile by blocking destinations

For geographic cross-region inference, AWS says permission is required for the profile, the source-region model and all destination-region models in the profile. The profile guidance says an SCP blocking any destination makes the request fail even when other destinations remain allowed; it does not turn the profile into a single-region route (AWS profile guidance). A vendor should not present “we denied the other regions” as evidence that this profile will consistently process only in Ireland.

Nor should Elmbridge assume the same model can simply be called without a profile in Ireland. The Opus 5.5 model card's Bedrock Runtime availability table does not list in-region inference for eu-west-1. A replacement proposal needs a supported model and route, or an explicit change to Elmbridge's boundary through its own decision process. Public regional availability also does not establish that the customer account can invoke the model: access eligibility, agreement and retention compatibility are separate checks using synthetic input. Until then, a failed request is preferable to an unapproved fallback for patient-related source.

A local sample does not clear the failover route

Suppose the invented vendor returns a synthetic job record showing one Ireland destination and concludes that the geographic profile is “effectively local.” Elmbridge rejects that inference. The observed destination is one member of the allowed set; it cannot eliminate the other five destinations from future routing.

The platform owner then supplies the retry configuration. After a capacity error, the application changes its source endpoint to London and uses the same eu. profile ID. The public model card lists London among the destinations for a London-origin call. Even a revised requirement allowing only the six EU member-state regions in the original table would not cover this fallback. The account record must bind source region plus profile plus destination set, not merely the profile string.

Elmbridge records three separate outcomes:

Retention adds another location question. AWS's geographic inference documentation says prompts and outputs can move outside the source Region and that data retained for abuse detection is stored in the destination Region for models requiring such storage. Disabling customer invocation logging does not remove that provider-retention question. The inference destination record and the retention record must describe the same model and route.

The final choice is operationally concrete: use an evidenced in-region alternative, change the written processing boundary through Elmbridge's own decision process, or keep private source on hold. Repeatedly sampling a geographic profile until a call lands in Ireland is not a fourth option.

Keep the route decision usable when service availability changes

Elmbridge's Ireland-only rule creates an availability tradeoff that procurement should understand before a private assessment begins. If the approved route is unavailable, the agreed behavior is an incomplete or delayed job. The vendor should show how that outcome is communicated and what happens to the source already acquired. A transparent failed job is compatible with the location rule; an undisclosed destination change is not the same service under the approved configuration.

Write a short operational branch for that situation. The technical owner identifies the failed approved route and records source-free diagnostic metadata. The account owner decides whether to wait, cancel the job or propose a different model that can meet the same boundary. If no acceptable alternative exists, any change to the boundary returns to the authorized decision owner. The support team should not improvise a broader retry route merely to finish the scan.

Keep model suitability separate from location suitability. An alternative may fit the geography yet lack the capability, context allowance or supported API needed for the agreed review. The technical team must evaluate those requirements before calling it an equivalent replacement. Counsel's route approval answers the location question; it does not establish the quality of the security analysis or authorize a different data-handling workflow.

When the proposed configuration changes, retain the previous route record and create a new dated decision. Include what changed, why it matters and which evidence was reused. A destination list, enforcement setting and sampled call should refer to the same configuration. Replacing only the model name in an older approval can leave its source-region and fallback assumptions wrong.

This approach gives Elmbridge a clear operational choice during an outage and a traceable approval after a change. It avoids turning repeated failure into pressure to reinterpret “Ireland only” while still allowing a practical, explicitly reviewed alternative.

Evidence the technical owner must attach

Counsel should ask for a short evidence packet, with the platform owner named beside every item:

1. Source-specific destinations. Run GetInferenceProfile from each region the deployed job can originate in, using the exact profile ID, and preserve the dated models[].modelArn list. AWS says these ARNs identify possible destination regions and warns that the prefix alone is insufficient (AWS profile guidance). The public model card can corroborate this list but cannot replace account-specific readback.
2. Deployed route and fallback. Show the selected endpoint, model ID, region, configuration revision, relevant permissions and any retry or capacity path. For an Ireland-only replacement, the owner should show an enforced allowlist that rejects the proposed eu. and global routes for this workload. Record what error a rejected or unavailable approved route produces. A source-code constant alone cannot establish the deployed setting.
3. Controlled check. Invoke the approved route using synthetic input, then attempt a disallowed route and a simulated unavailable-route path. Preserve configuration and safe invocation metadata, not private prompts. One successful call is a sample; the enforceable configuration and documented destination set support the future-route claim.
4. Sign-off and change notice. The infrastructure reviewer records what was checked and which uncertainty remains. Privacy counsel records whether the proven route meets the written location boundary. The vendor names who must notify Elmbridge before any route, model or fallback change and who can approve a new record.

If the profile lookup is missing, the source region can change, or fallback behavior is unknown, keep the route undecided and use only separately approved synthetic material. If the complete set includes a region outside the written boundary, hold private source even when a sampled call happened to run inside it. If an alternative route meets the boundary and its deployed controls are demonstrated, approve that named configuration, with its checked date and reapproval triggers. Apply the wider source data-flow review before treating the whole vendor workflow as approved.

Next action: give your technical reviewer the filled record above and ask them to replace every public-reference or “not supplied” entry with dated evidence from the proposed account. For the separate question of prompt retention, use how to explain model retention settings to procurement.