GDPR and the EU AI Act on dedicated hardware

This isn't legal advice. It's the compliance picture we'd want as a buyer choosing between a shared multi-tenant AI API and a dedicated machine: what actually changes with each choice, and what doesn't. We keep this to one page on purpose, because the honest answer to most of these questions is short, and a longer answer would be padding, not information.

Two separate frameworks, two separate questions

GDPR and the EU AI Act get lumped together in conversation because both matter to a company deploying AI in Europe, but they answer different questions. GDPR is about personal data: what you may process, on what lawful basis, and who else touches it along the way. The AI Act is about the AI system itself: which risk tier your use case falls into, and whether you're acting as a provider (roughly, the entity that develops or places the system on the market) or a deployer (an entity using it under its own authority). Neither framework is decided by where your compute physically sits. Hosting location is a GDPR and data-residency question; risk tier and role are an AI Act question. Keeping them separate is the first thing worth getting right, because conflating them is where a lot of vendor marketing (including some of ours, if we're not careful) goes wrong.

What choosing dedicated hardware actually changes

Running your model on a dedicated DGX Spark instead of calling a shared multi-tenant API does not change your AI Act risk tier or your provider/deployer status; those turn on what the system does and who's responsible for putting it into service, not on the hardware underneath it. What it does change is the GDPR-relevant question of who else can access your data while the model runs. On a shared API, that answer is a description of the vendor's multi-tenant architecture and contractual isolation controls. On a whole dedicated machine, root SSH, your own container, that answer is nobody: no other customer's workload ever runs on that GPU. That's a simpler fact to hand a data protection officer or an auditor, not a bigger legal shield by itself, and it's worth being precise about the difference.

The GDPR evidence we provide

• Location. Hardware and operations run from EU-Central, Prague, Czech Republic, under PRINT IT! SE.
• A published Article 28 DPA. A standard GDPR data processing agreement is available at no charge at gpuwerk.com/legal/dpa.
• A short sub-processor list. Published at gpuwerk.com/legal/sub-processors; there are none for instance workloads.
• No training on your content. GPUwerk does not access, read, copy, index or analyse the content of your instance. Infrastructure administrator access exists, as on any hosted service, and is not used on your content except at your request for support or where a legal obligation requires it.
• A stated deletion path. Terminating an instance deletes its container and workspace from the node; nodes are sanitised before reallocation to another customer. GPUwerk keeps a periodic recovery copy of a running or stopped workspace on its own backup server in the Czech Republic, on the same network as the GPU nodes and accessed by no third party; terminating deletes that copy too, so nothing is kept elsewhere afterward.

You remain the controller of your own processing, so the compliance of what you do with the model is yours to assert; this is the infrastructure evidence that supports that assertion. For the full detail behind each of these points, see private LLM hosting and our GDPR checklist for AI tools.

The AI Act question, briefly

Most companies self-hosting an existing open-weight model for internal use, without substantially modifying it or offering it as a product to others, are positioned as deployers rather than providers, and deployer obligations are narrower than provider obligations. That classification depends on what you do with the model and who it affects, not on whether it runs on a dedicated Spark or a shared API. Where dedicated hardware helps is downstream of that classification: a deployer's obligations tend to include things like human oversight and, for higher-risk uses, monitoring and record-keeping, and a clean answer to "who has access to the data going into the system" is a reasonable starting point for that oversight, even though it doesn't substitute for the classification analysis itself. The full reasoning, including where this can shift toward provider-like obligations, is in our EU AI Act and self-hosted LLMs explainer.

What we're not claiming

We're not claiming dedicated hardware makes you AI Act compliant, that a DPA alone satisfies GDPR for your specific processing, or that any of this substitutes for review by counsel who knows your actual model, data, and use case. We're also not publishing a page per regulation; GDPR and the EU AI Act are the two frameworks buyers ask us about, so this is one page answering both, not four pages implying more legal depth than a hosting provider can responsibly offer.

Where infrastructure fits into this: a dedicated DGX Spark in EU-Central gives you a short, concrete answer on data access while counsel handles the classification and processing analysis. See private LLM hosting for how that's set up, or talk to us directly.