How to run AI workloads while staying GDPR-compliant

The General Data Protection Regulation was written before large language models became a standard enterprise tool. But its principles — data minimisation, purpose limitation, lawful basis, and the right to erasure — apply to AI workloads with full force. Achieving GDPR AI compliance is not about finding a loophole. It is about architecture.

The problem is straightforward: when a user pastes customer data into a prompt and that prompt is sent to a cloud inference endpoint, personal data has just been transferred to a third-party processor. If that processor operates outside the EU, you may also have a cross-border transfer issue. If the data is used for training, you have a purpose limitation violation.

Where the risk actually sits

Most GDPR risk in AI workloads comes from three places:

1. Prompt content. Users routinely include names, email addresses, contract details, and support tickets in prompts. Every one of these is personal data under Article 4.
2. Retrieval-augmented generation. RAG pipelines pull documents from internal stores and inject them into context windows. If those documents contain personal data, the inference provider now processes it.
3. Fine-tuning datasets. Models fine-tuned on enterprise data may memorise and later emit personal data. If the training happened on a cloud provider’s infrastructure, you have transferred that data.

The common thread: GDPR AI compliance fails whenever personal data leaves your processing boundary without adequate controls.

Technical controls that work

There are four controls that, together, make AI workloads defensible under GDPR:

Local inference. If the model runs on hardware you control, inside your data centre, the prompt never leaves your processing boundary. No transfer, no additional processor, no new DPIA for a third-party sub-processor chain.

PII detection at the gateway. A request-level filter that identifies and either redacts or blocks prompts containing personal data before they reach the model. This is not foolproof, but it is a meaningful layer of defence.

Audit logging with retention controls. Every interaction must be logged for accountability (Article 5(2)), but logs themselves contain personal data and must be subject to retention policies and erasure requests. Your audit system needs both capabilities.

Purpose-bound model access. Different departments should access different models with different context policies. An HR chatbot should not have the same retrieval scope as an engineering assistant.

What a Data Protection Impact Assessment expects

If you deploy AI that processes personal data at scale, a DPIA is mandatory under Article 35. The assessment will ask: where does data flow, who processes it, what safeguards exist, and what is the residual risk?

If your answer is “prompts go to a US-based API and we trust their DPA,” your DPO will have questions. If your answer is “inference runs on-site, prompts are filtered at the gateway, audit logs are signed and retention-managed, and no data leaves our network,” the DPIA becomes dramatically simpler.

Making compliance the default

GDPR AI compliance should not depend on user behaviour. It should be an infrastructure guarantee. The architecture should make non-compliance difficult, not just discouraged.

Operayde runs inference on local appliances, filters requests at the gateway, and produces signed audit logs with configurable retention  — so the DPIA writes itself and personal data stays where your regulators expect it to be.