GDPR-Compliant AI Hosting on Dedicated GPUs: Architecture, Controls and What Auditors Want

GDPR (and the UK’s UK-GDPR + Data Protection Act 2018) does not prohibit using AI. It demands you can demonstrate lawful, proportionate processing. For organisations handling personal data — healthcare, finance, legal, public sector — that’s increasingly easier on dedicated infrastructure than on hosted APIs. This page is the architecture playbook.

Why GDPR pushes you to self-hosting

Three structural problems with hosted-API AI under GDPR:

1. International data transfers. Most hosted-AI APIs (OpenAI, Anthropic, Together, Fireworks) are US-hosted. GDPR requires a documented basis for transferring personal data to a third country. Standard Contractual Clauses (SCCs) are the usual answer, but they require risk assessment per provider and per workload.
2. Sub-processor opacity. Hosted AIs use cloud sub-processors (AWS, Azure, GCP) which themselves use further sub-processors. Mapping the chain for a DPIA is genuinely hard.
3. Prompt retention. Most hosted-AI providers buffer prompts for 7-30 days for "abuse review". That’s a US-resident copy of your data with a legitimate-interest justification you don’t control.

Self-hosting on a UK-resident dedicated GPU eliminates all three.

The reference architecture

• Datacenter: UK Tier-3 (GigaGPU’s London facility, or equivalent). EU acceptable; US not.
• Hardware: single-tenant bare-metal GPU server. No hypervisor sharing. No multi-tenant memory.
• Network: site-to-site VPN to your application VPC; optionally remove the public IP.
• OS: Ubuntu 22.04 LTS, LUKS full-disk encryption with BYOK.
• Inference engine: vLLM with metrics enabled, prompt logging disabled.
• Auth: mTLS or VPN-only access; no public API surface.
• Logging: structured request logs to your SIEM, with PII redaction. Retention per your data minimisation policy (typically 30 days max).
• Monitoring: Prometheus + Grafana on infrastructure metrics only — no payload sampling.

Concrete controls

DPA and documentation

What you need on file:

• Data Processing Agreement with the GPU provider, signed and version-controlled. Includes processing purpose, retention, sub-processors, breach notification.
• Data Processing Impact Assessment (DPIA) for each AI workload that processes personal data. Documents lawful basis, necessity, proportionality, mitigations.
• Records of Processing Activities (RoPA) updated to include the AI processing.
• Sub-processor list from the GPU provider (datacenter + transit) and from your application stack.
• Architecture diagram showing data flows. Auditors love these.
• Privacy notice updated to disclose AI processing where relevant.

Surviving an audit

Common questions auditors ask:

1. Where is the data physically? Address of the datacenter. We provide that.
2. Who has access? Named individuals, MFA-required, audit-logged.
3. What sub-processors are involved? Datacenter operator (named) + IP transit provider (named). Stop.
4. Is the data ever transferred outside the UK? Not by us; document any in your application stack.
5. How are deletion requests handled? No persistent inference logs by default; deletion of stored embeddings/RAG content is your application's responsibility.
6. What happens on a breach? Documented incident response, notification within 24h to controller, assistance with regulator notification.

Verdict

GDPR-compliant AI on dedicated GPU is not just feasible — it’s structurally simpler than the same workload on a hosted API. The hardware controls are out of the box; the work is documentation. Most teams complete the DPIA and DPA in a working week, then ship.