GDPR-compliant AI: cloud, EU-hosted, or a local model?

“Local” is a data-flow decision, not a compliance certificate

The most common misconception we meet: that self-hosting an open-weight model makes you compliant. It does not. A local model that ingests your HR files without a legal basis, without a retention limit, and without a log of who queried what is still a GDPR problem; it just happens to run on your own hardware.

What self-hosting genuinely removes is one specific risk: the transfer question. No third-party processor, no international transfer analysis, no dependence on a vendor’s retention policy. That is real value, and it is one line item out of six.

What GDPR actually asks of an AI system

These apply to all three deployment options. If you cannot answer them, the hosting question is premature:

• Legal basis and purpose. Why this personal data, under which Article 6 basis? Data collected to fulfil an order cannot be quietly repurposed to tune a model.
• Data minimisation. Does the model need the full customer record, or the three fields the task actually uses? Most prompts we see ship far more than the job requires.
• Processor agreements and transfers. Any AI vendor touching personal data is a processor under Article 28. If it processes outside the EEA, you also need a valid Chapter V mechanism, and clarity on who can access the data for support.
• Retention and logging. How long are prompts, outputs, and traces kept, by the vendor and by you? Agent logs are useful, and are themselves personal data.
• Transparency and rights. People need to know, and you need to honour access and erasure requests, including in your vector store, which is the part teams forget.
• Automated decisions (Article 22). If the system decides about people without meaningful human involvement (hiring, credit, termination), you are in a stricter regime. A human in the loop largely removes this.

The EU AI Act sits on top of this. Most SME use cases fall under transparency obligations, but recruitment screening, creditworthiness scoring, and worker management are explicitly high-risk; if your idea is in that territory, check the classification before you build.

The three options

Public API. The strongest models, no infrastructure, fastest path to something working. Business tiers generally exclude your inputs from training and offer DPAs and EU residency options; the consumer tier of the same product usually does not. Best for non-sensitive content where you control what goes in.

EU-hosted inference. Open-weight or European models served from an EU provider under an EU contract. Someone else runs the GPUs and the transfer question gets simple. Below frontier capability, but more than enough for classification, extraction, and routing. Best for ordinary business data.

Local / self-hosted. An open-weight model on a GPU server you control. Nothing leaves your perimeter, and you own the whole stack, including patching, monitoring, and capacity. Best for confidential documents, health or HR data, and high-volume repetitive tasks where a fixed monthly cost beats per-token pricing.

When a local model earns its cost

Self-host when:

• The data is confidential by contract or by law, and the simplest defensible answer is “it never left”.
• Volume is high and predictable: thousands of small classifications a day.
• The task is narrow: classify, extract, redact, route, summarise.
• You need independence from vendor pricing and model deprecations.

We talk clients out of it more often than into it, though. For long multi-step reasoning and reliable tool use, hosted frontier models still lead, and a failing agent costs more than the tokens you saved. You inherit GPU capacity, uptime, and security patching, which rarely appears in the original business case. A GPU server bills whether you send it ten requests a day or ten thousand. And if the workflow touches no personal or confidential data, self-hosting buys you complexity, not compliance.

The pattern that usually wins: route by data class

It is not one model for the whole company. Classify the data first, then send each class where it belongs:

• Public / internal-general (marketing copy, documentation, code without secrets): a hosted frontier model under a business agreement.
• Personal data, ordinary risk (customers, orders, tickets): EU-hosted inference with a DPA, minimised inputs, short retention.
• Sensitive or contractually restricted (health, HR, legal, client-confidential): local model, no egress.

Four things around that routing matter more than the model choice itself: redaction at the boundary so identifiers never reach the model unless needed; retrieval (RAG) so the agent looks facts up in your systems instead of relying on what a model memorised; least-privilege tool access so an agent that reads invoices cannot delete them; and an audit log of every tool call. Add human approval on anything that writes, sends, or pays. It is the cheapest control available, and what makes an AI agent safe to put in front of a real process.

Three mistakes we see most

• Shadow AI. Staff pasting customer data into free consumer tools because the company never provided a sanctioned one. Banning it does not work; giving people a compliant option does.
• Fine-tuning on personal data because it sounds impressive. Retrieval is usually better, cheaper, and far easier to reconcile with an erasure request: you cannot un-train a model.
• No evaluation set. Without thirty real cases with known-correct answers, you cannot tell whether a cheaper local model is good enough; you just have opinions, and every regression is a surprise.

How NexClass approaches this

We start from the workflow and the data, not from a model vendor: hosted frontier models where they earn their place, EU-hosted inference for ordinary business data, local models where the data should not leave the building, often all three in one system. Retrieval, least-privilege access, audit logs, and human approval on write actions are standard, not extras. We also say when an agent is the wrong tool: a large share of what arrives as “an AI problem” is a straightforward automation problem , deterministic, cheaper, and easier to defend to your auditor.

One note on scope: this is engineering guidance, not legal advice. For a formal assessment, work with your DPO or a Luxembourg data protection lawyer: the CNPD also publishes practical guidance for companies here.