Hanad KubatVisit Website →
← Back to blog

GDPR for AI: Close High Risk Gaps in Weeks for Legal and Privacy Teams

September 21, 2026
GDPR for AI: Close High Risk Gaps in Weeks for Legal and Privacy Teams

GDPR applies to AI the moment personal data enters training, testing, or inference; there's no carve-out for machine learning. If your system touches personal data, three things need to happen now: confirm whether you're a controller or processor, run or refresh a Data Protection Impact Assessment for anything high-risk, and document your lawful basis with clear transparency notices. The EDPB, the EU AI Act, and the ICO all converge on this point.

TL;DR:

  • GDPR applies to any AI process involving personal data at any stage, including training, testing, inference, and output interpretation.
  • Processing activities such as data collection, model fine-tuning, inference, and sharing outputs automatically trigger GDPR compliance obligations.
  • High-risk AI systems often require a DPIA to evaluate potential harm, especially for profiling, sensitive data, significant effects, or innovative technologies.
  • The EU AI Act adds layered risk-based obligations on top of GDPR for high-risk AI, including technical documentation and risk management, but GDPR remains primary.
  • Ensuring model anonymity demands proactive controls like differential privacy, query monitoring, provenance logging, and synthetic data substitution.
Hanad Kubat
Build AI Workflows You Can Maintain
Turn a validated AI workflow into working software with clear ownership, fixed scope, and maintainable code from the first commit.
See how software gets built

Table of Contents

Where GDPR for AI Actually Applies

GDPR doesn't care whether personal data is sitting in a spreadsheet or embedded in the weights of a language model. It applies at every stage where personal data gets touched: collecting training data, running validation tests, fine-tuning on customer records, and generating live predictions for a user.

Outputs count too. If a model infers someone's likely income bracket, health status, or political leaning from behavioral signals, that inference is personal data under GDPR, even if no name is attached. Profiling scores, recommendation rankings, and risk classifications all fall into this category.

Territorial scope follows the same extraterritorial logic as the rest of GDPR. A company based outside the EU that offers an AI-powered service to EU residents, or monitors their behavior, is in scope. This catches a lot of US and UK-based SaaS companies that assumed GDPR was someone else's problem.

Processing activities that trigger GDPR obligations for AI systems include the following:

  • Collecting or scraping personal data to build a training set
  • Fine-tuning a foundation model on customer or user records
  • Running inference that produces a score, prediction, or classification about a person
  • Storing prompts, logs, or embeddings that contain identifiable information
  • Sharing model outputs with third parties who can act on them

Key GDPR Requirements for AI Systems

Article 5's core principles don't change for AI. They just get harder to operationalize once data moves through a model instead of a database.

  1. Purpose limitation. Write down exactly why you're training or deploying the model, and treat that document as a boundary. Using a support chatbot's conversation logs to build a marketing model later is a new purpose and needs its own lawful basis.
  2. Data minimization. Strip fields you don't need before they reach a training pipeline. Synthetic data and aggressive anonymization reduce exposure, though the anonymization has to actually hold up, not just look clean.
  3. Accuracy and storage limitation. Set retention limits for training sets and for the model artifacts themselves, and build a correction path for when someone disputes what the system inferred about them.
  4. Accountability. Keep a record of processing activities that covers the model, not just the raw data: who trained it, what it was trained on, which processor agreements are in place, and what technical documentation exists.
  5. Limits on legitimate interest. If legitimate interest is your lawful basis, EDPB Opinion 28/2024 requires a three-step test: identify the interest, show the processing is strictly necessary, and balance it against the individual's rights. Skipping the balancing step is the most common failure point in audits.

Pro Tip: Treat your record of processing activities as a living index that points to your DPIA, your data flow diagrams, and your processor contracts, not as a standalone form you fill out once and file away.

How the EU AI Act Changes the Compliance Picture

The EU AI Act entered into force on August 1, 2024, and becomes fully applicable on August 2, 2026. It layers risk-based obligations on top of GDPR. It doesn't replace it.

If your system counts as high-risk under the AI Act, you now owe technical documentation, risk management processes, and conformity assessments in addition to your existing GDPR duties. GDPR still governs anything involving personal data, regardless of the AI Act's risk tier. A low-risk AI Act classification does not excuse you from a DPIA if the processing itself is high-risk under Article 35.

Practical sequencing matters here:

  • Run your DPIA and lawful-basis work as if the AI Act didn't exist, because GDPR requires it regardless
  • Layer AI Act technical documentation on top once the DPIA identifies the risk profile
  • Reuse the same risk register for both regimes rather than building two parallel compliance tracks

When Do You Need a DPIA for AI?

Article 35 GDPR makes a DPIA mandatory for processing likely to result in high risk to individuals. For AI systems, that threshold gets crossed more often than teams expect.

  1. Systematic profiling at scale. Credit scoring, hiring algorithms, and fraud detection models that evaluate people systematically almost always qualify.
  2. Sensitive data processing. Health, biometric, or similarly sensitive categories flowing through a model trigger the requirement on their own.
  3. Legal or similarly significant effects. If the output changes someone's access to a loan, a job, or a service, you're in DPIA territory.
  4. Innovative technology. The ICO lists novel AI techniques as a trigger when combined with other risk factors, even if the underlying data category seems mundane.

A DPIA for AI isn't a document you write once. Regulators expect it to evolve every time the model gets retrained, a new data source gets added, or the deployment context shifts.

Pro Tip: Version your DPIA the way you version code. Date every revision, note what changed in the model or data pipeline, and keep the history. Auditors ask for it more often than you'd think.

Explaining AI Decisions Under Article 22

Articles 13 through 15, alongside Article 22, require that people receive meaningful information about automated decisions and have a real path to contest them. "Meaningful" doesn't mean a technical readout of model weights.

The ICO's guidance breaks a useful explanation into five components: rationale (why this outcome), responsibility (who to contact), data (what was used), fairness (how bias was checked), and impact (what happens next). Good explanations focus on which input features actually swayed the outcome for that specific person, in plain language, sometimes with a counterfactual example.

Build these into your process before a decision ships:

  • A human review channel for anyone who wants to contest an outcome
  • A template explanation covering all five components, ready before the model goes live
  • A defined turnaround time for responding to a contested decision

Pro Tip: Draft your explanation template during model design, not after a regulator asks for one. Retrofitting explainability onto a black-box model already in production is where most of the pain lives.

Is Your AI Model Actually Anonymous?

Plenty of teams assume that once personal data goes into a model, it comes out anonymized by default. The EDPB rejects that assumption outright. Anonymity has to be assessed case by case, and a model only counts as anonymous if the likelihood of identifying someone through the training data or through crafted queries is genuinely negligible.

Illustration of AI anonymization risk assessment

The real risks are model inversion attacks that reconstruct training examples, extraction attacks that pull memorized data back out through prompts, and linkage attacks that combine model outputs with other datasets to re-identify someone.

Controls worth implementing:

  • Differential privacy during training, with a documented privacy budget
  • Query rate limits and monitoring for extraction-style probing
  • Provenance logs showing where training data came from and how it was processed
  • Synthetic data substitution wherever it doesn't degrade model performance

A Runnable GDPR Compliance Checklist for AI Teams

Most teams don't need a six-month compliance program. They need a prioritized list they can work through in weeks.

  1. Inventory first. Map every dataset and model component, then identify who's the controller and who's the processor, including any third-party foundation model vendors.
  2. Immediate must-dos. Update the DPIA, record the lawful basis, publish transparency notices, and turn on logging and monitoring for anything touching personal data.
  3. Technical fixes. Strip unnecessary personal identifiers, apply synthetic data or differential privacy where it's realistic, add access controls and audit logs, and build a human-review flow for contested decisions.
  4. Evidence for audits. Keep dated DPIA versions, processor agreements, and a short technical summary of your anonymization or minimization approach, since "we did it" without paper trail rarely survives scrutiny.

A DPIA template built for AI systems speeds up step two considerably, and an AI audit checklist covers most of step three in a format an engineering team can actually execute against.

Pro Tip: If you only have budget for one external review this quarter, spend it on the three highest-risk findings, not a full-scope audit. Fixing the worst gaps first is usually what regulators and due-diligence buyers actually check.

What I See Go Wrong in Practice

The two failures I run into most: data flows nobody wrote down, and a DPIA that was accurate a year ago and hasn't been touched since. Neither is a legal problem at first. Both become one fast once a system scales or a new data source gets added.

My fix is usually the same: freeze scope, run a focused audit, isolate or remove the personal data that shouldn't be there, and add a human-review gate before anything ships. Ten years of engineering work, including systems built for organizations like Deutsche Bahn and BMW, taught me that compliance holds up when it's built into the architecture, not bolted on after a legal review flags it.

— Hanad Kubat

Get a Fixed-Price Audit Instead of an Open-Ended Retainer

I offer a fixed-price alternative to a compliance consultancy that bills by the hour with no end in sight: one person writing every line, and you own the code from the first commit. If your AI feature has a GDPR gap, The plan starts at a fixed price and gets credited against a build if you move forward, covering a documented DPIA update, remediation of highest-risk findings, and logging or monitoring wired in before handoff. For teams building the feature itself rather than just auditing it, Your app starts at a fixed price for a full build, delivered in weeks, not months, with no surprise invoices along the way. There's one name on the contract who answers when something breaks. Book a Prototype Audit through Hanadkubat and get a scoped, dated plan for closing the gap before your next due-diligence review.

Sources

FAQ

Does AI Have to Comply With GDPR?

Yes. Any AI system that processes personal data during training, testing, or deployment falls under GDPR, regardless of whether the output looks anonymous. The EDPB and ICO both confirm there's no AI-specific exemption.

What Is GDPR in AI?

GDPR for AI refers to how the regulation's existing principles, purpose limitation, data minimization, accountability, and the rest, apply to systems that use personal data to train or run machine learning models. It's the same law, applied to a newer kind of processing.

Is ChatGPT GDPR Compliant?

Compliance depends on how a specific deployment uses ChatGPT, not the tool itself in isolation. Any organization feeding personal data into it, or using its outputs to make decisions about individuals, still needs its own lawful basis, transparency notice, and DPIA where the processing is high-risk.

What Is the 30% Rule in AI? (This term does not appear in GDPR, the EU AI Act, or ICO guidance.)

There is no established rule recognized in GDPR, EU AI Act, or ICO guidance stating a "30% rule" for AI. If you've seen this term elsewhere, it isn't part of the regulatory framework covered here, so treat it with caution rather than as an official threshold.