Why GDPR and the AI Act Apply Simultaneously
A common misconception is that the EU AI Act replaces GDPR for AI systems. It does not. The AI Act does not replace GDPR. It stacks on top.
This creates overlapping requirements. Both regulations cover transparency (GDPR Articles 13-14 and AI Act Article 50), risk assessment (GDPR Article 35 for DPIAs and AI Act Article 9 for risk management systems), human oversight (GDPR Article 22 and AI Act Article 14), and data quality (GDPR Article 5(1)(d) on accuracy and AI Act Article 10 on training data governance).
For engineering teams, this means a single compliance architecture must satisfy both frameworks. Treating them as separate workstreams leads to duplication, gaps, and audit failures.
The Data Flow Problem in AI Agents
An AI agent that processes personal data creates a chain of data movements. User input enters the system. The agent may retrieve context from a vector database. It sends a prompt to a language model. The model returns a response. The system may log the interaction for future reference.
At every step, personal data can be present. A customer name in a support ticket. An employee ID in a HR query. A medical history in a health-tech application
As soon as personal data is transferred to an AI provider, a data processing agreement pursuant to GDPR Article 28 is mandatory. This applies to every third-party model provider, every cloud hosting service, and every vector database provider in your AI stack.
Where to Host AI Systems for German Enterprises
The hosting decision directly affects GDPR compliance. The key principle is that personal data transferred outside the EU requires additional legal safeguards under GDPR Chapter V.
For AI workloads, three hosting approaches comply with current requirements:
EU-region cloud deployments.
Major LLM providers now offer EU-hosted inference endpoints. Anthropic offers EU residency via AWS Frankfurt. OpenAI offers it via Azure EU regions. Google offers it via Vertex AI EU regions. Using these EU-pinned endpoints keeps personal data within the EU during inference, which simplifies the transfer analysis.
On-premises deployment.
For enterprises with strict data residency requirements, open-source models can be deployed on-premises or in private cloud infrastructure within Germany. This eliminates third-party data transfers entirely but requires significant compute investment and in-house ML operations expertise.
Hybrid architecture.
Some enterprises route sensitive queries through locally hosted models while using cloud-hosted models for non-sensitive workloads. This requires a classification layer that identifies whether incoming data contains personal information and routes it accordingly.
Data Processing Agreements for AI Providers
A data processing agreement (DPA) pursuant to Article 28 GDPR is mandatory whenever personal data is transferred to an AI provider. In Germany, this is called an Auftragsverarbeitungsvertrag (AVV)
The DPA for an AI provider must address several areas that standard DPAs often miss. It should specify whether the provider uses input data for model training. It must document where inference happens geographically. It should list all sub-processors in the model serving chain.
The sub-processor list must be reviewed and on file. For a typical AI agent stack, this means documenting not just the LLM provider but also the cloud infrastructure provider, the vector database host, and any middleware services that handle data in transit.
If you are building AI agents for enterprise clients, ensuring these agreements are in place before the first byte of personal data enters the system is not optional. It is a legal prerequisite.
DPIA Requirements for AI Systems
The DSK (German Data Protection Conference) explicitly emphasizes that most corporate AI projects now fall under the mandatory criteria for a Data Protection Impact Assessment pursuant to GDPR Article 35.
A DPIA is required when processing is likely to result in a high risk to individuals. For AI systems, this threshold is met in nearly every enterprise use case because AI processing typically involves profiling, automated decision-making, or large-scale processing of personal data.
From August 2026, operators of high-risk AI systems face an additional obligation: the Fundamental Rights Impact Assessment under Article 27 of the AI Act. This is separate from the GDPR DPIA and addresses broader civil rights implications.
In practice, conducting both assessments together reduces duplication. Both require documenting the purpose of processing, the risks to individuals, and the safeguards in place. An integrated assessment template saves weeks of legal and engineering review time.
Building Privacy Into the RAG Pipeline
A retrieval-augmented generation system has four components where personal data exposure must be controlled: the document ingestion layer, the embedding and vector storage layer, the retrieval and prompt construction layer, and the response generation layer.
Document ingestion.
Before documents enter the RAG pipeline, personal data should be identified and handled. Data protection by design is not optional but mandatory under Article 25 GDPR. For AI systems, this means pseudonymization of personal data before inputting it into AI systems, logging all AI interactions traceably, and clear rules for when and how data is removed.
Embedding and vector storage.
Embeddings derived from personal data may themselves constitute personal data under GDPR if they can be linked back to an individual. Store vectors in EU-hosted infrastructure and apply the same access controls you would apply to the source documents.
Prompt construction.
When the retrieval layer pulls relevant chunks and constructs a prompt, personal data from the retrieved documents enters the prompt. If inference runs on a third-party model, this is a data transfer to a processor. Your DPA with the model provider must cover this.
Response generation.
The model's response may contain personal data extracted from the retrieved context. Log the response, apply retention policies, and ensure users are informed about what data the system processes about them under GDPR Articles 13 and 14.
The EDPB Opinion on AI Models and Personal Data
On 17 December 2024, the EDPB adopted Opinion 28/2024 on the use of personal data for the development and deployment of AI models. This opinion provides critical guidance for any team building or deploying AI systems in the EU.
Three findings are directly relevant:
The EDPB establishes a high threshold for proving the anonymity of AI models. An AI model trained on personal data cannot simply be declared anonymous. If personal data can be extracted from the model through queries, the model processes personal data and GDPR applies.
A controller may rely on legitimate interests as a ground for processing personal data in the development or deployment of AI models. However, this requires a documented balancing test that weighs the controller's interests against the data subject's rights.
Controllers deploying AI models may not be able to comply with their GDPR obligations if the model itself was not developed lawfully, even where the provider is a third-party supplier. This means enterprises cannot simply point to their vendor and claim they bear no responsibility.
For enterprises building RAG systems that process personal data, this opinion reinforces the need for thorough vendor due diligence on every LLM provider in the stack.
German-Specific Requirements Beyond GDPR
In Germany, the KoKIVO (within the BNetzA) serves as the technical competence hub supporting the enforcement of EU AI Act requirements.
On 17 June 2025, the German data protection authorities issued substantially revised guidance on technical and organizational measures for the development and operation of AI systems. This guidance incorporates both GDPR and EU AI Act requirements.
Key measures from the German DPA guidance include providing a time buffer between data collection, data subject notification, and model training to allow individuals to exercise their GDPR rights. AI systems involving automated decision-making must include user-accessible options to question or override results. And encryption and other security measures are required when distributing AI models containing personal data.
Where AI systems process or infer special category data, GDPR Article 9 requires an explicit legal basis and elevated technical safeguards. For children's data, the age of digital consent in Germany is 16 under GDPR Article 8.
A Practical Architecture Checklist
When building GDPR-compliant generative AI systems, these architecture decisions should be made before writing the first line of code:
Map every component in your AI stack that touches personal data. Document the data flow from user input through retrieval, inference, and response. Identify every third-party provider and confirm a DPA is in place for each one.
Choose EU-hosted inference endpoints for any workload involving personal data. Pin the hosting region contractually, not just by configuration. Ensure vector database hosting also falls within the EU.
Build pseudonymization into the ingestion pipeline. Apply it before data reaches embeddings or model prompts, not after. Document the pseudonymization method in your DPIA.
Implement retention policies for prompts, retrieved context, and responses. Define how long interaction logs are stored and when they are deleted. Ensure data subjects can exercise their right to erasure under GDPR Article 17.
Conduct a DPIA before deployment, not after. If your AI system qualifies as high-risk under the AI Act, also plan for the Fundamental Rights Impact Assessment under Article 27.
Cypherox builds AI and ML systems with these privacy controls integrated from the architecture phase. Our consulting services team works with enterprise legal and compliance stakeholders to ensure the technical architecture satisfies both GDPR and AI Act requirements before development begins.