AI Act and GDPR: What Your Existing Compliance Already Gives You
Invested in GDPR compliance? Part of it carries over to the AI Act. What your work already covers, what it does not, and how to run both tracks together.
When a founder tells me "we're on top of GDPR, are we safe on the AI Act?", my answer comes in two parts. Yes, a real portion of your GDPR work carries over and saves you time. And no, GDPR does not cover everything — the AI Act adds a logic that Regulation (EU) 2016/679 was never meant to carry.
Understanding where the two texts overlap, and where they diverge, avoids two mirror-image mistakes: starting from scratch when you already hold the essentials, or assuming that GDPR compliance amounts to AI compliance. Here is the map.
The GDPR protects a fundamental right: the protection of personal data. Its compass is the data subjects, their rights, the lawfulness of processing.
The AI Act, by contrast, is first and foremost product-safety regulation. Its logic is close to CE marking: an AI system deemed high-risk must be documented, tested, monitored and, where relevant, assessed for conformity before being placed on the market. The centre of gravity is not the person whose data is processed; it is the system itself and its safety.
That difference in nature explains everything that follows. The two texts intersect the moment an AI system processes personal data, but they ask different questions. Keep this grid in mind: for each obligation, it tells you whether you have already handled it on the GDPR side or whether it is a fresh piece of work.
If you did your GDPR work properly, you built blocks that transfer directly.
Your processing map. The record of processing activities under Article 30 GDPR already lists your data flows. It is the ideal basis for the AI system inventory the AI Act assumes: start from what exists, add an "AI use" column and the role-and-risk classification.
Your impact-assessment method. The Data Protection Impact Assessment (DPIA, Article 35 GDPR) taught you to evaluate a risky processing operation before launch. The AI Act provides, for certain deployers of high-risk systems, a fundamental rights impact assessment (Article 27). The two exercises are not identical, but the methodological culture is the same, and both assessments can largely be run together.
Your vendor management. The processor agreements required by Article 28 GDPR — the familiar DPAs — trained you to govern a chain of providers. The AI Act calls for the same rigour across the AI value chain: identifying model providers, technical subprocessors, and change-notification mechanisms. Your contractual reflexes apply here too. I set out the mechanics in the article on subprocessing in a SaaS agreement.
Your governance. A DPO or data lead, internal procedures, an incident register: this governance is the natural foundation on which to build AI governance, rather than standing up a parallel structure.
In practice. Startups that had already invested in GDPR start the AI Act with a head start. If that foundation is still missing, building it now serves both compliance tracks at once.
This is the most sensitive intersection between the two texts, and the one that comes up in every AI negotiation I handle.
Training or fine-tuning a model on personal data is processing within the meaning of the GDPR. It therefore needs a legal basis. In its Opinion 28/2024 of 17 December 2024, the European Data Protection Board (EDPB) confirmed that legitimate interest (Article 6(1)(f) GDPR) can, subject to conditions, serve as a basis for both training and deployment of a model — following a three-step test: a legitimate purpose, necessity, and a balancing exercise against the rights of individuals.
The same opinion dismantles a widespread assumption: a trained model does not automatically become anonymous. Personal data may remain "absorbed" in its parameters and, in some cases, be extracted again. Anonymity must be demonstrated case by case, not presumed.
Worth flagging. The EDPB also indicated that training carried out in breach of the GDPR can "taint" the deployment phase of the model. In other words, a shortcut taken upstream on data can undermine the entire downstream use. This is a risk you manage by contract, by tightly framing the origin of the data and the training use — a topic I develop on the contract side in the article on the AI Act and SaaS agreements.
This is where your GDPR compliance shows its limits. Several AI Act obligations have no GDPR equivalent, above all for high-risk systems: a risk management system (Article 9), technical documentation of the system (Article 11 and Annex IV), human oversight designed in from the start (Article 14), accuracy, robustness and cybersecurity requirements (Article 15), and, where applicable, a conformity assessment before the system reaches the market.
If your product is high-risk, these obligations are a separate, "product"-grade workstream that your DPO will not handle alone. If your product is limited or minimal risk — the most common case in B2B SaaS — the addition over GDPR narrows to two points: the transparency duty under Article 50 (tell the user they are interacting with AI, make generated content identifiable) and the AI literacy duty under Article 4 (internal training). Neither is covered by the GDPR.
One useful nuance on a point both texts touch: automated decision-making. Article 22 GDPR already frames decisions producing legal effects taken without human involvement. The AI Act adds, for high-risk systems, a human oversight requirement. The two are complementary but say different things: one protects the person targeted by the decision, the other mandates a control architecture inside the system.
The interplay between the two texts keeps evolving, and one point deserves your attention.
The Digital Omnibus, in the process of adoption as I write (political agreement of 7 May 2026), notably aims to clarify the processing of special-category data for the detection and correction of bias in AI systems — a subject sitting right on the edge of Article 9 GDPR, which in principle prohibits that kind of processing. In their joint opinion of February 2026, the EDPB and the European Data Protection Supervisor welcomed the objective while calling for precise safeguards on the scope of the derogation.
In concrete terms: if you work on the fairness of your models, the use of special-category data for that purpose is being clarified — but the framework is not settled. One to watch, and not to read too broadly while the text remains provisional. (Analysis as of 2 June 2026.)
The mistake would be to treat the AI Act and the GDPR as two silos. Here is how I align them with clients:
The right mindset is not "yet another regulation." It is to see the AI Act as an extension of the discipline you already acquired with GDPR — the same traceability culture, the same reflex to document, applied to a new object. The companies that will make this transition well are those that build on what they have rather than reinventing everything. If you want to audit what your current compliance already covers and pinpoint the real gaps, let's book a call.
The Digital Omnibus has shifted the AI Act timeline. What actually applies in 2026, what has been postponed, and how to tell if your SaaS is in scope.
SaaS, IT, hosting, integration: an overview of how to terminate an IT contract under French law, and the right reflexes to have
Let's build together to grow your business
I have been supporting software and SaaS companies for over 10 years, helping them structure their business, protect their intellectual property and strengthen their contracts.
