This page is practitioner guidance on deployment mechanics, not legal advice — involve your counsel or DPO for decisions about your specific obligations.
GDPR-compliant AI is a question of who processes personal data, where, and on what legal footing — not of which model you pick. Self-hosting an open-weight model collapses three of the hardest problems at once: there is no processor to bind under Article 28, no third-country transfer to justify under Chapter V, and no vendor retention term to reconcile with your own. What remains is ordinary controller work you already do: lawful basis, transparency, records, and a DPIA where the processing warrants one.
Why this is hard
Every hosted model adds a processor, and usually a sub-processor chain you cannot fully enumerate on request.
Article 17 erasure is trivial for a database row and genuinely hard for a model that has already trained on the row.
Post-Schrems II transfer assessments age badly, and a supervisory authority will ask what you did about it.
What the deployment gives you
No Chapter V transfer, because nothing transfers
Inference on hardware in your own facility or an EU datacentre means personal data never crosses a border. There is no adequacy decision to rely on, no standard contractual clauses to paper, and no transfer impact assessment to refresh every time the case law moves.
Article 30 records that survive an audit
A self-hosted deployment has one processing location, one retention policy, and one set of recipients — yours. Describing it in your record of processing activities takes a paragraph instead of a diagram with a dotted line leaving the page.
Erasure you can actually perform
Retrieval over an index you control makes Article 17 a delete operation with a verifiable result. This is the architectural reason to prefer RAG over fine-tuning on personal data: you can delete from an index, and you cannot meaningfully delete from frozen weights.
Data minimisation enforced before the prompt
A gateway that strips direct identifiers and scopes retrieval to the purpose turns Article 5(1)(c) into a pipeline stage. Minimisation asserted in a policy document is an intention; minimisation in code is a control.
Where the personal data goes — and where it stops
The open-weight model itself is the one component that comes from outside. It arrives once, as a file, and it contains no personal data of your data subjects; from then on every byte of personal data stays on your side of the boundary. That asymmetry is what makes the compliance story short.
A DPIA where Article 35 is triggered — large-scale processing of special-category data or systematic evaluation still needs one, self-hosted or not.
Retention on prompt and completion logs set explicitly. They routinely contain personal data and they are the control most often forgotten.
Transparency that names AI processing in your privacy notice; self-hosting changes the recipients, not your Article 13 duty to describe the processing.
Human review for anything with legal or similarly significant effects, so Article 22 does not apply to an automated decision nobody checked.
Purpose limitation on the index: documents gathered for one purpose should not silently become the retrieval corpus for another.
What you have to satisfy
Art. 28 GDPR — Processor obligations: Every hosted model is a processor requiring a compliant contract and documented sub-processors. Self-hosting removes the processor from the inference step entirely.
Art. 17 GDPR — Right to erasure: Deletable from an index; effectively not deletable from trained weights. This single asymmetry should drive your RAG-versus-fine-tuning decision.
Chapter V — Third-country transfers: Adequacy, SCCs, and transfer impact assessments apply the moment data leaves the EEA. Processing locally means the chapter never engages.
Art. 35 GDPR — Data protection impact assessment: Required for high-risk processing regardless of deployment model. Self-hosting shortens the DPIA; it does not remove the obligation to do one.
Models that fit this deployment
Model
VRAM (Q4)
Runs on
Context
License
Mistral Small 3.1 24B EU-published, Apache 2.0 — 16 GB card — A capable European open-weight model where provenance itself is part of the procurement argument. ollama pull mistral-small3.1
Qwen 3 32B Department tier — one 24 GB card — Permissive licence, strong multilingual behaviour across EU languages, single-card deployment. ollama pull qwen3:32b
20 GB
24 GB GPU (RTX 3090/4090) Mac: 32 GB unified
128,000
Apache 2.0
Llama 3.3 70B Instruct Organisation tier — 48 GB class — The reference open 70B for knowledge work; note the community licence when your legal team reviews terms. ollama pull llama3.3:70b
43.1 GB
2×24 GB GPUs or 48 GB card Mac: 64 GB unified
128K
Llama Community
Need AI your DPO will actually sign off on?
We help European organisations deploy AI that keeps personal data inside their own jurisdiction and their own control — architecture review, model selection, retrieval design, and the documentation your data protection officer needs to see. Vendor-neutral, practitioner-level, no platform to sell you.
Not inherently — it depends on lawful basis, transparency, the contract, and where the data ends up. Using a hosted model with personal data makes the provider a processor, so you need an Article 28 agreement, a documented sub-processor chain, a Chapter V transfer mechanism if processing happens outside the EEA, and a retention position that matches your own. Enterprise tiers can satisfy much of this contractually; consumer tiers generally cannot, and pasting personal data into one without a basis is where organisations get into difficulty.
How does the right to erasure work when a model has been trained on personal data?
Honestly, badly — which is the point. Once data is in the training set it is diffused across billions of weights, and there is no reliable operation that removes one person from a trained model. Machine-unlearning research exists but is not something to promise a supervisory authority. The practical answer is architectural: keep personal data in a retrieval index rather than the training corpus. Then erasure is a delete from a store you control, with a result you can demonstrate, and the model itself never held the data.
Does self-hosting mean we do not need a DPIA?
No. Article 35 turns on the risk of the processing, not on who owns the servers. If you are processing special-category data at scale, systematically evaluating people, or deploying a new technology in a way likely to result in high risk, you need a DPIA. Self-hosting usually makes that DPIA much shorter — the transfer section becomes "none", the recipients section becomes "no third party" — but skipping the assessment because the hardware is yours is not a defensible reading.
Do open-weight models count as personal data?
The weights of a general-purpose model published by a third party are not a record of your data subjects, and treating the model file as personal data is not a useful framing. The regulated question is what you feed the model and what you keep: prompts, retrieved documents, completions, and logs are all likely to contain personal data and all fall inside your record of processing. Where it gets genuinely unsettled is a model you fine-tuned on personal data yourself, since it may have memorised examples — another reason to prefer retrieval.
Does the EU AI Act change any of this?
It adds a separate obligation layer rather than replacing GDPR. The AI Act regulates you by role — provider versus deployer — and by risk classification of the use case, while GDPR continues to regulate personal data in the same system. Most organisations deploying an internal assistant are deployers of a limited-risk system with transparency duties, but the classification is use-case specific and worth doing deliberately. Our EU AI Act guide covers the roles and the timeline in detail.