GDPR Compliance for AI Systems: Technical Controls Guide (2026)

GDPR compliance for AI systems is now a top-three enforcement priority for European data protection authorities. Every LLM query sent with personal data in the prompt, every automated hiring or credit decision, every model trained on customer records creates obligations under six binding GDPR articles. And from August 2, 2026, those obligations compound with EU AI Act requirements, creating parallel penalty exposure from two independent regulatory frameworks.

Cumulative GDPR fines exceeded €7.1 billion by early 2026. TikTok received a €530 million penalty in 2025 for unlawful EU-to-China data transfers. Clearview AI was fined €30.5 million with a processing ban. Italian DPA issued €5 million in AI-specific enforcement. The enforcement landscape is not a future concern.

This guide maps the six GDPR articles that directly bind AI systems, gives CISOs and DPOs the specific technical controls for each, and shows where GDPR and the EU AI Act create simultaneous obligations requiring unified infrastructure.

---

The Six GDPR Articles That Directly Bind AI Systems

General GDPR guidance treats the regulation as primarily a data governance concern. For AI systems, six articles create specific technical obligations that no amount of policy documentation can satisfy without corresponding implementation.

Article 5: Lawfulness, Fairness, and Transparency The five core principles (lawfulness, fairness, transparency, purpose limitation, data minimisation, storage limitation, and accuracy) apply in full to AI systems. Purpose limitation is particularly acute: a model trained for fraud detection cannot be repurposed for employee monitoring without a new lawful basis assessment and likely a new DPIA. Storage limitation requires defined retention policies for training datasets, inference logs, and model outputs containing personal data.

Articles 13 and 14: Transparency Individuals whose data is processed by AI systems must be informed of the logic involved, the significance, and the envisaged consequences. A generic privacy policy statement is insufficient. Article 13(2)(f) requires specific disclosure when a decision is based solely on automated processing, including profiling. This applies to every AI feature making decisions that affect individuals, from credit scoring models to AI-driven HR tools.

Article 17: Right to Erasure This is where GDPR creates a fundamental architectural challenge for AI. Deleting a record from a database does not satisfy erasure when that record was part of a model's training set. The model's weights retain statistical influence from that data. EDPB guidance and academic analysis confirm that Article 17 obligations extend to trained model parameters.

Article 22: Automated Decision-Making Individuals have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects or similarly significant effects. The exceptions are narrow: contract necessity, explicit legal authority, or explicit consent. Where one exception applies, the data subject still has the right to human intervention, to express their point of view, and to contest the decision.

Article 25: Data Protection by Design and Default Controllers must implement appropriate technical measures from the design phase, not retrofit them. For AI systems, this means data minimisation architecture (only processing the minimum personal data needed), pseudonymisation where possible, and the ability to satisfy data subject rights by design. Retrospective compliance is consistently penalised more heavily by supervisory authorities.

Article 35: Data Protection Impact Assessments DPIAs are mandatory before processing likely to result in high risk. For AI systems, three EDPB criteria apply: systematic profiling used in significant decisions, large-scale special category data processing, and systematic monitoring. Most production AI systems processing personal data meet at least one criterion.

---

Technical Controls for Article 17: Machine Unlearning Architecture

The right to erasure creates three implementation options for AI teams, each with different cost and compliance profiles.

Option 1: Full Retraining The most legally defensible approach. When a subject requests erasure, the model is retrained from scratch on the training dataset with the subject's records removed. Guaranteed to remove influence. Cost is proportional to training time and compute. Practical for smaller models or infrequent erasure requests.

Option 2: Machine Unlearning Techniques A set of approaches that approximate erasure without full retraining:

• SISA Training (Sharded, Isolated, Sliced, and Aggregated): Partition training data into shards. Erasure requests only require retraining the affected shard, reducing compute by the shard fraction. Developed by Bourtoule et al. (2021) and now referenced in EDPB technical guidance.
• Gradient Reversal / Unlearning by Gradient Ascent: Apply gradient ascent on the target data points to drive the model away from those examples. Followed by a fine-tuning pass on retained data to restore generalisation. Computationally efficient but requires validation that unlearning was effective.
• Influence Function Estimation: Quantify each training example's influence on model outputs. Below a statistical significance threshold, influence may be documented as negligible, supporting a compliance argument that no meaningful unlearning is required.

Pre-deployment decision: The choice of unlearning approach must be made before training begins, not after receiving an erasure request. SISA training requires a specific data partitioning architecture; retrofitting it to an existing model is not feasible.

What to document: A formal machine unlearning policy specifying the approach chosen, the justification, the process for receiving and logging erasure requests, the verification method for confirming unlearning, and the timeline for completion. Regulators have accepted documented commitments with reasonable timelines; they have not accepted "we cannot comply because the model was already trained."

---

Securing Automated Decision Pipelines Under Article 22

Article 22 compliance requires more than a policy statement that humans review decisions. Supervisory authorities have consistently found that rubber-stamp reviews do not satisfy the human intervention requirement.

Mapping your automated decisions Start with a complete inventory of AI-driven decisions that produce legal or similarly significant effects on individuals: credit decisions, loan applications, insurance underwriting, hiring screening, benefits eligibility, access control, content moderation with account consequences. Each decision pipeline must be individually assessed for Article 22 applicability.

Human-in-the-loop architecture patterns

• Decision queuing: Automated decisions are staged, not immediately applied. A qualified human reviewer sees the model's output, the input features, and the model's confidence score before the decision takes effect. The queue must be staffed to meet reasonable response times.
• Mandatory contestation path: Every automated decision affecting an individual must include a documented, functioning process for the individual to request human review, provide context, and receive a response from a person with authority to override the system.
• Escalation threshold triggers: Define confidence thresholds below which the system automatically escalates to human review rather than issuing a decision.

Audit logging requirements Article 5(2) accountability principle requires documenting how Article 22 compliance is maintained. Log the model version used, the input features (with pseudonymisation of personal identifiers), the model output and confidence score, the identity of the human reviewer, the review outcome, and the timestamp. Retention of these logs must match the potential contestation window.

What AI Act Article 14 adds For high-risk AI systems under Annex III of the EU AI Act, the human oversight obligation goes further. The system must be designed to allow natural persons to fully understand the system's capabilities and limitations, detect automation bias, override or interrupt the system, and receive appropriate training. This requires technical instrumentation: explainability outputs per decision, anomaly alerts when model behaviour deviates from expected ranges, and documented override procedures.

---

Data Minimisation Technical Controls for AI Training

Article 5(1)(c) requires that personal data be limited to what is necessary. For AI training pipelines, the practical controls are:

Pre-training data audit: Before training, document every personal data field in the training dataset, the purpose for which it is processed, and whether it is strictly necessary for the model's function. Fields that improve model accuracy marginally but are not necessary for the stated purpose must be removed.

Differential privacy: Adding calibrated noise to gradients during training (DP-SGD) provides mathematical privacy guarantees: an attacker who obtains the model weights cannot infer whether any specific individual's data was in the training set, up to the defined epsilon parameter. Google, Apple, and OpenAI have published implementations. The tradeoff is reduced model accuracy at small epsilon values.

Pseudonymisation at data ingestion: Replace direct identifiers (names, email addresses, national IDs) with pseudonyms at the point of data ingestion into training pipelines. Maintain the mapping table under strict access controls, separate from the training data.

Synthetic data substitution: For model development and testing, synthetic data generated from real distributions avoids GDPR applicability entirely. Tools such as Gretel, Mostly AI, and Syntheticus generate statistically representative synthetic datasets. Production training may still require real data, but development and testing typically do not.

---

DPIA Checklist for AI System Deployments

A standard DPIA template will miss the AI-specific risk categories that regulators are now examining. Use this checklist as a supplement to your organisation's standard Article 35 process.

Standard DPIA elements (verify these are completed):

• Processing description and purposes
• Necessity and proportionality assessment
• Data subject rights mechanisms
• Data transfers and adequacy basis
• Data retention schedule
• Processor and sub-processor register

AI-specific additions:

Training data provenance: Document the lawful basis for each source of training data. Was consent obtained for the specific purpose of AI training, or was data collected for a different purpose and repurposed?

Model bias and discrimination assessment: Does the model perform differently across protected characteristics (age, gender, ethnicity, disability)? Document fairness metrics and the methodology for measuring them before deployment.

Inference attack risk: Can membership inference attacks reveal whether a specific individual's data was in the training set? What differential privacy or other controls mitigate this risk?

Erasure feasibility assessment: Before training, confirm and document the machine unlearning approach that will be used to respond to Article 17 requests. This decision cannot be made after training begins.

Model drift and accuracy degradation: What monitoring is in place to detect when model performance degrades and decisions become inaccurate? How does drift affect the fairness assessment?

Automated decision mapping: Is the AI system making solely automated decisions under Article 22? If so, document the exception relied upon and the human intervention architecture.

Third-party model and API risk: If using a foundation model API (OpenAI, Anthropic, Google, etc.), document the DPA, data residency, data retention policies, and transfer mechanism. Assess whether the provider can satisfy an Article 17 request affecting training data they may hold.

For guidance on AI governance controls that support DPIA documentation, see our Enterprise AI Governance Compliance Framework and NIST AI RMF Practical Guide.

---

Third-Party LLM DPA Requirements

Every time personal data appears in a prompt sent to an external LLM API, the provider is a data processor under Article 4(8) GDPR. Article 28 requires a signed Data Processing Agreement before any processing occurs. Terms of service clauses are not a substitute.

What a valid DPA must contain (Article 28(3)):

• Processing only on documented instructions
• Confidentiality obligations
• Technical and organisational security measures
• Sub-processor agreements and notification obligations
• Data subject rights assistance
• Deletion or return of data at contract end
• Audit cooperation

Provider status as of May 2026:

| Provider | DPA Available | EU Data Residency | SCCs Required | |---|---|---|---| | OpenAI API | Yes (standard DPA) | No (US processing) | Yes | | Azure OpenAI | Yes (via Microsoft) | Yes (EU regions) | Not required for EU processing | | Anthropic API | Yes (DPA Addendum) | No (US processing) | Yes | | Google Gemini API | Yes (via Google Cloud) | Yes (EU regions) | Not required for EU processing | | AWS Bedrock | Yes (via AWS) | Yes (EU regions) | Not required for EU processing |

Standard Contractual Clauses and Transfer Impact Assessments Where providers process data in the US, SCCs alone are not sufficient after the Schrems II ruling. A Transfer Impact Assessment (TIA) is required to document that the US legal regime does not undermine the SCC protections. Given US government access authorities (FISA 702, EO 12333), TIAs for US-based LLM providers require specific technical controls: encryption with keys held in the EU, prompt anonymisation before transmission, or contractual restrictions on data access by US-based staff.

Practical prompt architecture controls:

• Strip or pseudonymise personal identifiers from prompts before sending to external APIs
• Log all external API calls with data classification of the payload
• Configure zero-data-retention API tiers where available (OpenAI's ZDR option, Claude's enterprise tiers)
• Include external LLM providers in your Records of Processing Activities (RoPA) under Article 30

---

GDPR and EU AI Act: A Dual-Compliance Map

The two frameworks are not aligned and do not satisfy each other. GDPR compliance does not satisfy AI Act conformity assessment, logging, or synthetic content marking. Meeting the AI Act does not replace GDPR lawful basis documentation or DPIAs. Both apply simultaneously to AI systems processing personal data.

Where controls can satisfy both simultaneously:

| Obligation | GDPR Basis | EU AI Act Basis | Shared Control | |---|---|---|---| | Risk documentation | Art. 35 DPIA | Art. 9 Risk Management System | Unified risk register with dual references | | Training data governance | Art. 5 principles + Art. 35 | Art. 10 Data Governance | Data lineage and provenance documentation | | Human oversight | Art. 22 human intervention | Art. 14 Human Oversight | Decision review architecture | | Logging and audit | Art. 5(2) accountability | Art. 12 Logging Obligations | Centralised inference and decision logs | | Transparency | Art. 13/14 transparency | Art. 13 Provider transparency + Art. 50 | User-facing disclosure documentation | | Conformity / DPIA update | Art. 35(11) periodic review | Art. 43 Conformity Assessment | Annual compliance review cycle |

August 2, 2026 deadline status: AI Act transparency obligations under Article 50 (disclosing AI-generated content, chatbot identification) and GPAI model obligations are already fully in force. The August 2 date marks full application of obligations for General-Purpose AI models and providers. High-risk AI system obligations under Annex III arrive December 2027, but the classification exercise, risk management system, and DPIA must begin now to meet that deadline.

For technical controls on high-risk AI classification, see our EU AI Act Compliance Guide for SMBs.

---

The Enforcement Landscape: What DPAs Are Targeting

Supervisory authorities are shifting enforcement focus from cookie consent to AI processing. The signal is clear in recent actions:

• Italy's Garante imposed €5 million in AI-specific enforcement and issued temporary bans on AI processing where GDPR safeguards were absent
• Clearview AI: €30.5 million fine with a processing ban covering the Netherlands, for processing biometric data without a lawful basis
• TikTok: €530 million in 2025 for transferring EU user data to China without adequate safeguards, directly relevant to any AI system using non-EU infrastructure
• Meta: €1.2 billion (Ireland, 2023) for US data transfers, the framework that applies to any enterprise relying on US-based LLM APIs without SCCs and TIAs

The EDPB has coordinated task forces specifically targeting foundation model providers and AI system deployers. The three most frequent compliance gaps identified in audits are: absence of explicit informed consent or alternative lawful basis documentation before AI processing (47% of cases), absence of erasure mechanisms for AI-trained data (39%), and absence of functioning human intervention mechanisms for Article 22 decisions (31%).

---

Conclusion

GDPR compliance for AI systems is not a legal interpretation exercise. It is an architecture and engineering problem that must be addressed before training begins, before deployment, and with ongoing operational controls.

The six articles covered in this guide (5, 13/14, 17, 22, 25, 35) each require specific technical implementation. Policies and documentation cannot substitute for machine unlearning architecture, functioning human review queues, privacy-by-design training pipelines, or valid data processing agreements with LLM providers.

With the EU AI Act's August 2, 2026 transparency deadline now under 10 weeks away, and high-risk AI system classification starting now for the December 2027 deadline, the window to establish compliant infrastructure is closing.

BeyondScale's AI security assessment maps your AI system inventory against GDPR and EU AI Act obligations, identifies technical control gaps, and provides a prioritised remediation roadmap. Run a Securetom scan to assess your current posture, or contact us to discuss a full GDPR and EU AI Act readiness assessment.

---

External References

• EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and Default
• NIST AI RMF 1.0 - Risk management framework with GDPR-aligned controls
• OWASP LLM Top 10 2025 - LLM-specific security risks including training data poisoning and membership inference
• EU AI Act Official Text - Regulation (EU) 2024/1689