"Personal data must not go to US-hosted models" is a sentence every Dutch public-sector CISO has said in a meeting this year. It is easy to say and hard to make true, because model calls are made by developers, from features, on behalf of users, and a policy document does not sit between the code and the API. This article looks at the options that keep prompts inside the EU, describes a residency policy that is enforced in code and fails closed, and ends with the questions that belong in a procurement checklist.
Why the sentence is right
A prompt that contains a resident's name, case number and circumstances is personal data. Processing it on servers outside the European Economic Area is a transfer under Chapter V of the GDPR and needs a lawful mechanism: an adequacy decision, standard contractual clauses with a transfer assessment, or another Art. 46 safeguard. The adequacy framework for transfers to the United States has been challenged in court more than once, and its status should be checked rather than assumed. Independently of transfers, the provider is a processor and needs an Art. 28 agreement that covers sub-processors, retention and whether prompts are used for training.
For a public body there is a second layer. National cloud and information-security policy for government sets expectations about where data is processed and under whose jurisdiction, and a US provider may be subject to disclosure orders that reach data wherever it is stored. Those are questions for the organisation's own policy; the technical control described below is what makes the answer stick.
The options that keep prompts in the EU
There are three, in increasing order of dependence on someone else's promise.
A model in your own infrastructure. An open-weights model served by an inference server on your own hardware or in your own cloud tenancy. Nothing leaves the deployment. The cost is operational: someone runs it, patches it and sizes it. For screening, extraction and drafting tasks a mid-sized model is often enough.
An EU-hosted provider. A vendor that serves models from an EU region and says so in its documentation and contract. The residency claim is the vendor's, so confirm the region on your own account and that no model you select is routed elsewhere.
A region-selectable hyperscaler resource. A cloud model service where residency depends entirely on which region you created the resource in and which data-residency commitments your contract carries. Correctly configured it is EU; the point is that the tool cannot know that from the endpoint, so the configuration must declare it and someone must confirm it.
Two options do not belong on the list. A router that sends each request to whichever upstream provider serves the model has no single residency at all. And a US provider with a regional endpoint is only EU-hosted if your agreement actually says so.
A residency policy that fails closed
A policy is only as good as the moment it is enforced. The design that works has four properties.
The policy is per project. A children's-services project and an internal documentation project do not share a risk profile. Each project declares one of three positions: any provider; an EU-hosted or locally run provider; or a locally run provider only.
Residency is a declaration checked against the endpoint. Each configured provider carries a declared residency: local, EU, US or unspecified. A preset can pre-fill the declaration, but never makes it. And the declaration is sanity-checked: a known US vendor cannot be saved as local, and a public endpoint cannot be saved as local.
Undeclared satisfies only "any provider". If nobody knows where a provider runs, it cannot satisfy a policy whose purpose is to constrain where data goes.
The failure is a refusal, at the earliest moment. Saving a provider configuration that violates the project's own policy is rejected outright. If a violating configuration is reached anyway, the call returns an error naming the provider, where it runs and what the policy requires. It never falls back to another key, never returns a mock result, and the report simply omits the model-generated section with a line saying why.
Redaction sits alongside this, not instead of it. Pattern-based redaction strips e-mail addresses, phone numbers, card numbers, IBANs and the Dutch BSN before a prompt is sent. It cannot strip names, addresses or dates of birth. Redaction reduces exposure; residency decides where the remainder goes.
A worked example
The fictional municipality of Wijkerveen runs two projects. The first screens a benefits-eligibility model; its prompts could carry case details. The second summarises published council minutes. The CISO sets the first project to "EU-hosted or locally run only" and the second to "any provider".
A developer on the first project selects a US vendor preset and tries to save. The save is refused with the policy named. She switches to the inference server the municipality runs in its own tenancy, declared local; the connection test lists the deployed models and the save goes through. Weeks later a platform key for the US vendor is added at organisation level for the minutes project. The benefits project is unaffected: its policy still refuses that provider, and when a colleague asks for a narrative paragraph in the report the section is omitted with the reason printed. Nothing was sent, nothing was faked, and the audit log shows the refusal.
A procurement checklist
Put these in the tender or the contract, and expect a written answer to each:
- In which region is inference performed, and can it be fixed contractually?
- Which sub-processors touch prompt data, and where are they?
- Are prompts or outputs retained, for how long, and can retention be set to zero?
- Are prompts used to train or improve any model? The answer should be no, in writing.
- Which legal entity is the processor, under which jurisdiction, and what is the transfer mechanism if any data leaves the EEA?
- Is there an Art. 28 processor agreement, and does it cover audit rights and breach notification timelines?
- Can the service be run inside our own tenancy or on-premises, and at what cost?
- Does the provider declare its residency in a way our tooling can check, per endpoint rather than per brochure?
How Landfall helps
Landfall carries a per-project residency policy with the three positions above and enforces it in code: a provider configuration that violates the policy cannot be saved, and a blocked call fails closed with an error naming the provider and the policy, never a silent fallback. Provider presets cover two local inference servers, two EU-hosted endpoints, a region-dependent cloud resource left as unspecified, and a US vendor declared as such, each with a one-line note on what the operator still has to confirm. PII redaction runs before any prompt is sent and the trust page states plainly what it does not catch.