An open-weight model can often be operated on EU/EEA infrastructure regardless of the publisher’s country, because the deployer can obtain the weights and choose where inference runs. That can help control data flows, but it does not make the deployment automatically GDPR-compliant or exempt it from the EU AI Act. GDPR depends on the concrete processing of personal data, legal basis, security, retention, processors and transfers. AI Act obligations depend on the actor’s role and the model/system context. Provider flag ≠ data residency.
Provider origin is not data residency
A model can be developed by a US, Chinese, Canadian or European organization and still be self-hosted on infrastructure in Germany, France, the Netherlands or another EEA location if the weights and runtime support independent deployment.
Conversely, a model published by an EU company can be deployed through non-EU cloud services, telemetry providers or external APIs. The country flag therefore describes provider origin, not where your prompts, documents or outputs are processed.
This is why the OpenWeightModels registry labels flags as provider-country metadata rather than a compliance or residency badge.
What GDPR asks you to evaluate
GDPR applies when the system processes personal data in scope. A model itself is not simply “GDPR-compliant” or “non-compliant.” The processing operation has to be evaluated.
Relevant questions include the purpose and legal basis, data minimization, access controls, retention, deletion, security measures, processor relationships and whether individuals can exercise applicable rights. The European Data Protection Board’s Opinion 28/2024 addresses issues around AI models including anonymity, legitimate interests and unlawfully processed training data.
Self-hosting can reduce exposure to third-party model APIs, but it also places more security and governance responsibility on the operator.
International transfers depend on the full data path
The European Commission explains that special safeguards apply when personal data is transferred outside the EEA. For an AI application, the relevant path can include more than the inference server.
| Component | Data that may flow | Residency question |
|---|---|---|
| Inference | Prompts, context, outputs | Where does the model server run? |
| RAG / vector DB | Documents, chunks, metadata | Where is the index stored and queried? |
| Embeddings / reranking | Queries and document text | Is an external API used? |
| Logging / monitoring | Prompts, traces, identifiers | Where are observability systems hosted? |
| Backups / support | Stored datasets and diagnostics | Which subprocessors can access them? |
AI Act: open weight is not a blanket exemption
The EU AI Act contains obligations for providers of general-purpose AI models (GPAI), with additional obligations for models with systemic risk. The European Commission states that GPAI provider obligations include technical documentation, information for downstream providers, a copyright policy and a public summary of training content.
Whether an organization using an open-weight model becomes a provider, deployer or another regulated actor depends on what it does with the model and system. Fine-tuning, rebranding, integration and placement on the market can change the analysis. The Commission’s GPAI guidelines are the appropriate reference for scope questions.
A European procurement checklist
- Record the provider country — for supply-chain context only.
- Record the exact model license and commercial-use terms.
- Decide where weights, inference and supporting services will run.
- Map personal-data flows through RAG, logs, embeddings and support.
- List processors/subprocessors and transfer mechanisms.
- Determine the organization’s AI Act role for the concrete use.
- Document security, retention, access and incident procedures.
What a sovereignty-oriented architecture looks like
A strong sovereignty architecture does not require the model publisher itself to be European. It requires the deployer to control the critical dependencies it cares about: weight access, runtime portability, infrastructure location, encryption keys, data stores, logging and the ability to migrate.
European model publishers can still be strategically attractive for support, procurement and ecosystem reasons, but sovereignty is an architecture property, not a flag alone.
Better label than “GDPR compliant model”
Use precise statements such as “self-hosting possible,” “EU/EEA deployment possible,” “external model-API transfer avoidable,” and “data residency depends on the complete stack.”
Frequently asked questions
Can a US or Chinese open-weight model be hosted entirely in the EU?
Technically yes when the weights, inference runtime and connected services are operated on EU/EEA infrastructure. The full data path must still be reviewed.
Does a French or other EU model provider automatically make a deployment GDPR compliant?
No. Provider origin and GDPR compliance are different questions. Compliance depends on the concrete processing and system architecture.
Are open-weight models exempt from the AI Act?
No blanket rule applies merely because weights are available. Obligations depend on the model/system and the actor’s role; consult the Commission’s current guidance.
Can self-hosting eliminate international transfers?
It can eliminate some transfers, such as sending prompts to an external model API, but other services such as embeddings, monitoring or backups can still create transfers.
Apply this knowledge
Move from the concept to a concrete deployment shortlist.
Primary sources and technical references
OpenWeightModels prefers publisher documentation, standards bodies, official repositories and original research papers. The source material remains authoritative where it changes.