--- title: "EU and US Models Under One Policy Floor" description: "Running EU-hosted and US-hosted models under one inherited policy floor: residency enforced before the provider, denials on the record, limits stated." canonical: https://www.norcaster.com/article/eu-and-us-models-one-policy-floor --- # EU and US Models Under One Policy Floor 2026-09-10 ยท Jesper Jensen, Norcaster Not legal advice. Residency below means configured residency, not a legal determination about where data is processed. **Who this is for:** platform engineers and AI-risk reviewers at companies with EU and US business units that want to use more than one model provider without maintaining two governance stacks. ## The problem, concretely A bank has an EU business unit and a US business unit. Both want an internal assistant. The EU unit must not send customer data to a US-hosted model; the US unit is happy with either. Both units want the same redaction rules, the same approval flow for policy changes, and one place to answer "which configuration governed this request". The usual answer is two gateways, two policy files, and a spreadsheet that says which is which. That works until a fallback provider is added, a deployment is cloned into the wrong project, or an auditor asks for the EU unit's denials. ## What "one policy layer" has to mean It is not enough that both units \*share\* a policy file. The layer has to be a **floor**: a child scope can tighten what the parent allows and can never loosen it. If the organisation says "EU business unit: EU-tagged providers only", no deployment inside that unit can widen the list, replace it with an empty one, or swap the whole settings object to escape it. The second requirement is that the check runs **before any provider sees data**, on every supported request path, and that the fallback target is checked too. A residency rule that only applies to the primary provider is a residency rule with a hole in it. The third is that a denial is **on the record** as an enforcement event with the governing policy version, not a 4xx in a log file. ## How it works in Norcaster - Policies inherit **organisation โ†’ project โ†’ deployment**. The resolver merges them as a floor: children may only tighten. Residency is an \*intersection\* key โ€” a deployment's allowed regions are the intersection of its own list with its parents'. - Each provider carries a declared **residency region** tag. Each deployment can carry an **allowlist of regions**. When a request resolves to a provider whose tag is not in the allowlist, the request is blocked with a governance error before the adapter is called, and an enforcement event is written with the policy version and content hash. - The check runs on the primary inference API and on the OpenAI-compatible and Anthropic-compatible gateway routes, and it is applied to the **fallback target** as well, so a transient error cannot route EU traffic to a US provider. - An organisation can set the policy to **fail closed** for untagged providers, so a provider someone forgot to tag is denied rather than allowed. - Provider failover is itself an event: primary, fallback, model, runtime, and the classified reason. ## What the synthetic bank exercise shows We maintain a reproducible acceptance exercise with a **fictional** bank that has separate EU and US organisations. It is an engineering exercise, not a customer reference. It asserts that: - EU and US business units cannot relax inherited region restrictions, including by broadening a child list, supplying an empty or disjoint list, or replacing whole settings objects; - provider fallback stays within the configured region policy in streaming and non-streaming calls; - revocation of a data grant takes effect on the next request; - redaction behaves the same across English, Swedish, German, and French synthetic inputs. The test suite and the walkthrough are in the repository under the pilots directory. Ask us for the walkthrough rather than a slide. ## The limits, stated - **The region tag is declared, not verified.** A provider tagged EU that points at a US endpoint is still dispatched. We verify what we can derive from the endpoint next; until then, treat residency as configured residency and confirm it in your provider contracts. - **No EU-native model provider is in the registry yet.** EU today means Azure OpenAI EU endpoints or a self-hosted runtime such as NVIDIA NIM inside your own cluster. A direct integration with a European model provider is planned. - **Allowed calls do not yet carry the region on the record.** Denials are events; a successful EU-routed call records provider and model but not the region tag. That is on the plan. - **The control plane is hosted in the EU; the data plane can run in your network.** Prompts and evidence stay inside your boundary via the hybrid data plane, with an allowlist of metadata that may leave. Full self-hosting is available for teams that need the control plane inside too. ## Questions to ask any vendor 1. Is the policy a floor or a default? Show me a child scope failing to widen it. 2. Where does the residency check run, and does it cover the fallback provider? 3. Show me a denial as a record with the policy version, not a log line. 4. Is the region on a provider verified or declared? 5. Which of your model providers are actually hosted in the EU? We will answer all five for our own product in the same conversation, including the ones we do not like. --- This piece describes shipped behaviour as of 10 September 2026 and names its limits. It is not a compliance determination. The synthetic bank exercise represents a fictional customer.