A compliance architect's reference for building AI systems that satisfy GDPR from the data model up, not as an afterthought.
Covers GDPR obligations for AI processors, EU AI Act interaction, and the architectural patterns that make compliance tractable rather than painful.
GDPR and AI are a collision in slow motion for most engineering teams. The regulation was written before large language models were production-ready, so it doesn't mention embeddings or inference endpoints. But it absolutely applies to them — because AI systems process personal data, and the principles of storage limitation, data minimisation, and processor accountability don't have exemptions for models.
The good news is that the architecture for GDPR-compliant AI inference is not complicated. It requires discipline more than cleverness: pick the right processor, get the DPA signed, implement stateless request handling, and document your data flows. What follows is the reference I wish I had when our team first mapped AI processing onto our GDPR RoPA.
Personal data must not be retained longer than necessary. For inference workloads this means prompt and completion data must not be logged after delivery. Zero-retention inference satisfies this by design; standard provider logging does not.
Every AI provider is a data processor under GDPR. A signed DPA must exist before processing begins. The DPA must enumerate all sub-processors (compute, CDN, storage). Verbal assurances and privacy policies are not substitutes for a signed DPA.
Transferring personal data to a non-EEA country requires either an adequacy decision (the US does not have one at infrastructure level for all entities), Standard Contractual Clauses, or Binding Corporate Rules. The safest architectural choice is to avoid the transfer entirely by using EU-incorporated processors.
Systems handling personal data must embed privacy controls into the architecture, not bolt them on afterwards. Stateless inference — where the LLM receives only the minimum necessary context and retains nothing — is the canonical implementation of this principle for AI workloads.
This is a starting-point checklist, not a legal opinion. Engage your DPO for jurisdiction-specific obligations.
The EU AI Act entered into force in August 2024 with a phased application schedule. GDPR governs data; the AI Act governs the system. For most enterprise AI use cases, both apply simultaneously.
Partially. Data may reside in the EU region, but the data processor is still a US-incorporated entity subject to CLOUD Act requests. Your legal basis for processing remains questionable unless Standard Contractual Clauses (SCCs) are in place and a Transfer Impact Assessment has been completed. Many EU DPAs (including the Swedish IMY) have issued guidance that SCCs alone are insufficient without additional safeguards. Using an EU-incorporated processor removes this risk entirely.
A DPA is a contract mandated by GDPR Article 28 whenever a controller (you) engages a processor (AI provider) to handle personal data. It must specify the subject matter, duration, nature and purpose of processing, the type of personal data, and the controller's obligations. If your prompts can contain personal data — user messages, names, emails, document contents — you need a signed DPA before the first API call.
Stateless inference means each API request is processed in memory and the prompt plus completion are discarded after the response is delivered. No logs, no training data, no telemetry that persists the personal data. This directly satisfies GDPR storage limitation (Art. 5(1)(e)) and data minimisation (Art. 5(1)(c)) for the inference component of your system. JuiceFactory's API is stateless by architecture — codified in the DPA.
They are complementary, not alternatives. GDPR governs personal data processing in AI systems. The EU AI Act governs the risk level of the AI system itself and imposes additional obligations for high-risk uses: conformity assessments, technical documentation, human oversight interfaces, and audit logging. Both sets of rules apply simultaneously. Systems handling medical records, creditworthiness, or employment decisions are likely high-risk under the AI Act and also process sensitive personal data under GDPR.
Yes, but the document store becomes a data processing component in its own right. You need: (1) a legal basis for storing the documents, (2) access control so retrieval only surfaces data the user is permitted to see, (3) an audit trail of what was retrieved and used in each inference call, and (4) a deletion mechanism that removes data from the vector store when the retention period expires. Our guide on GDPR-safe AI inference covers the full architecture.
JuiceFactory is incorporated in Sweden, processes data in Swedish datacenters, and provides a GDPR-compliant DPA as standard. No legal overhead, no US parent company in your processor chain.