GDPR and the EU AI Act: Where Compliance Overlaps

Most guides treat GDPR and the EU AI Act as two separate reading assignments: one about personal data, one about AI systems. If your company processes personal data with an AI system, which describes almost every AI use case involving customers, candidates, or employees, that separation is misleading. You are running both regimes at once, on the same system, and they do not always ask the same question in the same way. This post is about that overlap: where the two reinforce each other, where they genuinely collide, and how to handle both without doing the work twice.

Two different regulators looking at the same system

GDPR asks a narrow question: is personal data being processed lawfully, fairly, and for a defined purpose. The AI Act asks a broader one: does this AI system pose a risk to health, safety, or fundamental rights, regardless of whether personal data is involved. An AI system that scores loan applicants, screens CVs, or flags insurance fraud sits inside both questions at once. That is the source of most friction below: the two laws were drafted with different objects in mind and then landed on the same use cases.

Training AI on personal data: the legitimate interest question

If your company trains, fine-tunes, or customises a model using personal data, such as customer records, support tickets, or CVs, you need a GDPR legal basis for that processing, separate from anything the AI Act requires. In December 2024, the European Data Protection Board addressed this in Opinion 28/2024, issued at the request of Ireland's Data Protection Commission. It confirmed that legitimate interest can, in principle, serve as a lawful basis for developing or deploying an AI model on personal data, but only after a genuine three-step test: a clearly identified interest, a demonstrated necessity for the processing, and a documented balancing exercise against the individual's rights, not just an asserted one.

The same opinion set a demanding bar for calling a trained model "anonymous" and therefore outside GDPR's scope: a controller has to show that identifying an individual from the model, by any means reasonably likely to be used, is negligible. Few companies fine-tuning a model on their own customer or employee data will clear that bar, which means the model itself, not just the training dataset, can remain in scope of GDPR. France's CNIL has published parallel, more operational guidance through 2024 and 2025, including recommendations on legitimate interest for AI training and on informing individuals when their data has plausibly shaped a model's outputs.

One decision, two different legal tests

GDPR Article 22 gives individuals a right not to be subject to a decision based solely on automated processing, including profiling, that produces legal or similarly significant effects on them. The AI Act's Annex III separately lists categories of "high-risk" AI systems, including recruitment, employee evaluation, creditworthiness assessment, and access to essential services, based on the context of use, not on whether a decision was fully automated. A hiring system will often trigger both tests at once, but they are not the same test, and clearing one does not clear the other.

So "we have a human in the loop" is not a single fix that closes both files. It may address the Article 22 question. It rarely, by itself, addresses the AI Act's separate requirements around risk management, technical documentation, human oversight design, and logging for a high-risk system.

Impact assessments: overlapping, not identical

GDPR Article 35 requires a Data Protection Impact Assessment (DPIA) when processing is likely to result in high risk to individuals' rights, which most AI systems processing personal data will trigger. The AI Act's Article 27 separately requires certain deployers of high-risk AI systems, notably public bodies and private operators providing certain public-facing services, to run a Fundamental Rights Impact Assessment (FRIA) before putting the system into use. The two are meant to connect: Article 27(4) states that where a FRIA's requirements are already met by a DPIA, the FRIA "shall complement" that DPIA rather than duplicate it.

In practice, that connection is only partial. A DPIA is scoped to personal data risk; a FRIA is scoped to fundamental rights more broadly, including non-discrimination, dignity, and access to services, whether or not personal data is the mechanism of harm. The FRIA obligation also applies to a narrower set of deployers, so many companies will need a DPIA without ever needing a FRIA. The efficient move is one assessment process that produces both documents from a shared fact base, not two separate projects that each start by re-interviewing the same product team.

Data minimization meets a data-hungry model

This is the tension hardest to resolve on paper. GDPR's data minimization principle says you should collect and retain no more personal data than is necessary for a specified purpose. Training and fine-tuning works against that instinct almost by design: more varied, more representative data tends to produce a better-performing, less biased model, and "we might need it for a future version" is a common but weak justification under GDPR. CNIL's 2024 guidance allows a flexible reading of purpose limitation for general-purpose systems whose exact future use cannot be fully specified in advance, but it does not remove the obligation to define, document, and revisit why a dataset is being kept and used.

For an SME, the practical question is rarely "can we use this data for AI at all" but "have we written down, before training starts, what the model is for, why this dataset is necessary for that purpose, and when we will stop using it." Vendors selling AI tools with vague or absent documentation on this point are pushing that unresolved tension onto you as the deployer.

Different regulators, different clocks

GDPR is enforced by national Data Protection Authorities, a system running since 2018. The AI Act is enforced by a different, still-forming structure: national market surveillance authorities designated by each Member State (in some countries that role has gone to the existing DPA, in others to a new body), plus the EU AI Office, which took on enforcement of general-purpose AI model obligations from August 2026. A company operating across the EU can have one AI deployment reviewed, on different questions and timelines, by more than one type of regulator.

The Code of Practice for general-purpose AI models, published by the AI Office in mid-2025, adds a signal: the Commission prefers a structured, negotiated path to compliance for large model providers over case-by-case enforcement. Enforcement on AI systems handling personal data has also proven genuinely contested: a widely reported €15 million fine against OpenAI issued by Italy's Garante in December 2024 over ChatGPT's training practices was later annulled by a Rome court in 2026. Treat any single enforcement action as a directional signal, not a fixed precedent.

Non-EU AI providers add a third layer

Many SMEs reach AI capability through a non-EU provider, directly or through a SaaS tool built on one. That routes personal data outside the EEA, triggering GDPR's Chapter V transfer rules independently of the AI Act: a valid transfer mechanism (an adequacy decision, standard contractual clauses, or another safeguard), plus, per the Schrems II line of cases, an honest look at whether the destination country's laws could undermine those safeguards in practice. A vendor being AI Act-compliant as a provider says nothing about whether your use of their tool satisfies GDPR's transfer rules; those are two separate questions.

Running both processes together, not in sequence

The costliest mistake is treating GDPR and the AI Act as sequential projects, finishing a data protection review and then starting an AI Act review from scratch. A more efficient approach starts from a shared fact base:

• Map each AI use case once, capturing both the personal data involved and the context of use (hiring, credit, essential services, and so on) that AI Act risk tiering depends on.
• Record the GDPR legal basis for any training or fine-tuning on personal data before it happens, including the three-step legitimate interest test if that is the basis relied on.
• Check Article 22 and Annex III as two separate questions for any system that produces a decision or recommendation about a person, not as one combined checkbox.
• Where a DPIA is required, structure it so the same fact base can extend into a FRIA later, instead of starting a second assessment from a blank page.
• Get a straight answer from any AI vendor on data residency, transfer mechanism, and whether your data trains their models, before rollout rather than after.
• Track the two regimes' deadlines separately. A use case can be GDPR-live today with its AI Act obligations still phasing in; treating the later date as a reason to defer the GDPR work is a common, avoidable error.

Everything above is general information to help you get oriented, not legal advice for your specific situation. Both regimes have detail and ongoing regulatory guidance a single article cannot fully capture, and how they interact depends on your exact data, use case, and countries of operation. Where Komplya publishes guidance like this, we are clear about which layers are legally reviewed and which are draft material, so you can weigh it accordingly.

Reading about the overlap in the abstract only gets you so far. The fastest way to get clarity is to check your specific use case: what data it touches, what decisions it makes or feeds into, and which of these obligations actually apply to you today versus later.