AI Data Residency, Explained Properly

What data residency actually means for AI inference

When choosing an inference API, establish where data is stored and processed, who receives it, and which entities control access. The answers help you assess legal and contractual requirements. They do not produce an automatic verdict for or against a provider.

Storage, processing and operator jurisdiction are useful assessment questions, not 3 standalone GDPR residency obligations. A provider’s answer to one does not settle the others.

• Storage: where prompts, outputs, logs and backups persist
• Processing: where the model and related services handle the data
• Legal control: which entities can access the data and which legal demands may apply to them

An inference request moves all three at once. Your prompt text and the model's output are personal data the moment they can be linked to a person, and they travel with metadata: request identifiers, timestamps, routing decisions, logs. Each of those can land in a different legal place. The prompt may be processed on a GPU in one region, logged in another, and backed up to object storage in a third, while the company operating all of it sits under a fourth jurisdiction.

Conflating the three produces a false all-clear. A provider who answers yes to is your data stored in the EU may be answering only the storage question while the processing runs elsewhere, or while the operating entity is subject to third-country legal process. For a GDPR-regulated buyer, each of the three needs its own answer, in writing, before the endpoint goes anywhere near production traffic.

Storage location, processing location and operator jurisdiction

Chapter V depends on a transfer, not on foreign ownership alone. The EDPB test requires a GDPR-subject exporter, disclosure to another controller or processor, and an importer in a third country or international organisation. EU storage can coexist with a transfer through remote access by a separate overseas entity.

Article 44 sets the general principle: any transfer of personal data which are undergoing processing, or are intended for processing after transfer, to a third country may take place only if the conditions laid down in Chapter V are complied with, including for onward transfers from that third country to another. The onward-transfer clause is the one most buyers skip, and it matters for inference: a sub-processor forwarding prompts to a support or logging tool in a second third country is a fresh transfer that needs its own safeguards.

An applicable adequacy decision is a Chapter V transfer mechanism. Check its scope and current status. The EU-US Data Privacy Framework covers eligible participating organisations, not every US provider or every kind of transfer.

Assess foreign legal exposure separately from whether a transfer has occurred. A parent company’s nationality does not by itself establish a transfer or make processing unlawful. Access, corporate arrangements and applicable legal process still need review.

Why a console region label is not a guarantee

A region label describes the service scope the provider assigns to that label. Read its definition. It may cover inference or storage without covering all support, telemetry or failover paths.

• Check peak-load and failover destinations
• Identify sub-processors for support, logging and other processing
• Check which entities can access personal data and from where
• Request the service’s written location commitments and any exceptions

The US CLOUD Act addresses disclosure under valid legal process of data within a covered provider’s possession, custody or control, including data held abroad. Its application depends on jurisdiction and the facts. Review that exposure without treating ownership as automatic disclosure.

Map routing and failover against the permitted locations in your contract. For any route involving another entity outside the EEA, apply the transfer test and identify the appropriate safeguards. Crossing a physical border alone is not the complete legal test.

What a GDPR-regulated buyer has to verify

Article 28 is where a residency claim gets tested, because it defines what your processor owes you before any data flows. The controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures so that processing meets the requirements of the Regulation. Sufficient guarantees is a documentation exercise, not a vibe: the contract has to carry specific content.

1. The processor processes personal data only on documented instructions from the controller, including with regard to transfers to a third country, unless Union or Member State law requires otherwise.
2. Persons authorised to process the data are committed to confidentiality, or under an appropriate statutory obligation of it.
3. The processor takes all measures required under Article 32, the security article, which is a separate obligation from residency.
4. Engaging another processor requires prior specific or general written authorisation, and the processor must inform the controller of any intended addition or replacement, giving the controller the opportunity to object.
5. The processor assists the controller with data subject rights and with the obligations under Articles 32 to 36.
6. At the controller's choice, the processor deletes or returns all personal data at the end of the service, and makes available all information necessary to demonstrate compliance, including audits and inspections.

The sub-processor chain is the part that matters most for residency. Where a processor engages another processor, the same data protection obligations must be imposed on that sub-processor by contract, and where the sub-processor fails, the initial processor remains fully liable to the controller. Read that against the change-notice rule: a provider whose sub-processor list can change without you seeing the new names is a provider whose residency claim can change without you noticing.

This is why the named sub-processor list is where a residency claim is actually tested, not the region field. If the DPA names a third-country entity with administrative or remote access to the inference infrastructure, the EU datacentre story has a hole in it that no console tag closes. Ask for the list by name, ask which of the named entities can access prompt data, and ask under what authorisation regime changes to that list reach you.

Where residency stops solving the problem

Residency can support security and contractual controls, but location alone does not show that access, encryption, availability or processor terms are adequate. A region label is not an audit report.

• Security: assess access, encryption, availability and incident handling in addition to location
• Certification: inspect the scheme, issuer, covered processing and validity rather than relying on a badge
• Contracts: review Article 28 terms, sub-processor authorisation, assistance and audit rights

GDPR Articles 42 and 43 provide voluntary certification mechanisms, issued by accredited bodies or supervisory authorities. Check what a specific certification covers. Lyceum’s GDPR statement is self-asserted; facility certificates do not automatically attest to our inference service.

Checking a provider's residency claim before you sign

The verification path is short, and every step produces an artefact your data protection officer can put in the file. Run it before signature, because after signature your leverage drops to the termination clause.

1. Ask for the hosting region of the specific model string you plan to call, with the date the answer was read. Not a platform-level statement, not a marketing page: the region record for that model, on a stated date.
2. Read the DPA and its named sub-processor list before signing, per Article 28, and confirm the change-notice regime gives you the opportunity to object to additions.
3. Where a transfer exists, check adequacy first. If relying on an Article 46 tool such as standard contractual clauses, assess its effectiveness and any required supplementary measures
4. Confirm in writing that the hosting region is pinned per request and that no routing tier in front of the model can move traffic outside the EEA.
5. Record the contracting entity's jurisdiction of incorporation, because that is the answer to the operator-jurisdiction question the region field cannot give you.

When relying on standard contractual clauses, assess whether the transfer protection works in the relevant circumstances and whether supplementary measures are needed. An adequacy-covered transfer follows a different route. Keep that distinction in the review record.

How providers structure the underlying architecture, dedicated capacity versus serverless endpoints, changes which of these checks bite hardest, and we compare EU sovereign inference platforms separately in the EU Sovereign Inference Platform Comparison. The same verification discipline applies if you are evaluating GPU marketplaces rather than inference APIs; we cover that case in RunPod Alternatives for EU Data Residency.

Keep dated evidence for each model and service. A platform promise can be meaningful if its contract and technical controls support it, but a catalogue change requires a fresh check. Confirm support, logs and failover as well as the model’s region.

The Lyceum dashboard listed moonshotai/kimi-k3 with an EU label on 1 October 2026. That is a catalogue observation, not proof of every processing path. Ask for the model’s current service terms and location commitments before handling restricted data.

For what we can and cannot claim about certification, data protection and service commitments, the Compliance & Certifications record is the honest list: GDPR compliance is a self-asserted legal position, we hold no ISO 27001 or SOC 2, and the DPA is available on request. Check the hosting region of the specific model you plan to call before you commit to it: the EU-hosted model roster, prices and changes are tracked in EU Hosted LLM API: Lyceum Model Roster, Prices and Changes.