If you operate an AI system in the EU that processes personal data, you now live under two regulatory regimes that were drafted eight years apart, by different institutional coalitions, with partly incompatible assumptions about what “risk” means and how to manage it. Most scale-ups I advise treat this as two separate compliance exercises — run the DPIA, separately run the AI Act conformity assessment, hope the documents do not contradict each other. That approach is expensive, duplicative, and frequently produces evidence that will not stand up in either audit.
The better approach is to understand where the regimes genuinely stack — where you can satisfy both with one artefact — and where they conflict, because the conflict points are where most programmes quietly fall apart.
Where the regimes stack
The overlap is larger than the AI Act’s drafters probably intended, and it is the right place to start any unified programme.
Risk assessment is the clearest overlap. GDPR Article 35 mandates a Data Protection Impact Assessment for high-risk processing. AI Act Article 9 mandates a risk management system for high-risk AI systems, and Article 27 mandates a Fundamental Rights Impact Assessment where the deployer is a public body or private entity providing public services. These are three different documents in the regulation, but they are asking overlapping questions: what is the processing / system doing, what rights are at stake, what can go wrong, what controls mitigate the risk, what residual risk remains, who owns it.
A properly designed assessment template can produce all three outputs from one exercise — with different cover pages, different signatories, and different triggering conditions, but the same evidentiary core. Running them as separate exercises produces inconsistent findings, and an auditor who reads both will notice.
Data governance is the second overlap. AI Act Article 10 imposes data governance requirements on high-risk systems — data relevance, representativeness, bias mitigation, documentation of provenance. GDPR imposes data minimisation, purpose limitation, accuracy, and storage limitation. These are not the same principles, but they push in similar architectural directions: know where your data came from, know why you have it, know whether it is fit for purpose, know when it should be deleted. A unified data inventory — one register, mapped to both regimes — eliminates most of the duplicate work.
Transparency and documentation. GDPR Articles 13 and 14 require information to data subjects about the processing. AI Act Article 13 requires transparency information to deployers and, in some cases, end-users. AI Act Article 50 requires disclosure when users are interacting with an AI system, when content is synthetically generated, or when emotion-recognition or biometric-categorisation systems are in use. The regimes overlap on the obligation to inform, but the specifics — who must be informed, about what, in what form — differ. A documented transparency matrix mapping every obligation to every audience is the artefact that passes both audits.
Human oversight. AI Act Article 14 requires high-risk systems to be designed for effective human oversight. GDPR Article 22 restricts decisions based solely on automated processing, including profiling, with some narrow exceptions. These are doctrinally different — one is a design obligation, the other is a prohibition with exceptions — but operationally they point to the same architectural question: where does the human sit in the decision loop, with what authority, on what evidence? Design the system properly for Article 22 and you have most of what Article 14 needs.
Where the regimes fight
The conflict points are fewer, but they are where programmes tend to break. Each requires an explicit design decision, documented.
Training data and purpose limitation. GDPR purpose limitation (Article 5(1)(b)) restricts further processing to compatible purposes. Using personal data collected for one purpose to train an AI model for a different purpose is a compatibility analysis that is rarely as simple as programmes assume. The AI Act’s data governance requirements — particularly around representativeness and bias mitigation — can actively push in the opposite direction: you may need more data, from broader sources, to build a well-governed training set. Reconciling this requires a lawful basis analysis up front, not after the model is trained.
Accuracy versus bias mitigation. GDPR Article 5(1)(d) requires personal data to be accurate. AI Act Article 10(3) requires training, validation, and test data to be relevant, representative, and free of errors to the best extent possible. In practice, these cut in different directions when individual-level accuracy sits in tension with statistical representativeness. A dataset may be statistically well-calibrated and individually wrong about particular data subjects. The AI Act will accept this with appropriate governance. GDPR has a harder time with it. The design choice — and its documentation — has to be deliberate.
Right to explanation. GDPR Article 22 carries with it, via Article 15 and the Article 29 Working Party / EDPB guidance, something that functions as a right to meaningful information about the logic of automated decisions. The AI Act’s transparency obligations are less demanding in the individual case but more demanding in the systemic case — conformity documentation, technical files, deployer information. A system designed only for Article 22 explanations will under-deliver on AI Act conformity. A system designed only for AI Act conformity may fail Article 22’s individual-explanation threshold. Both have to be designed for.
Incident reporting. GDPR Article 33 requires personal data breach notification to the supervisory authority within 72 hours. AI Act Article 73 requires serious incident reporting to the market surveillance authority without undue delay. The authorities are different. The thresholds are different. The content of the notification is different. The timing can be different. An incident response playbook that assumes one will cover the other will fail the regime it did not plan for.
How to actually run both
The programmes that work treat GDPR and the AI Act as one governance regime with two reporting perimeters, not two programmes with shared themes. One risk register. One data inventory. One assessment template with three output profiles. One human-oversight architecture. One incident response runbook with two notification paths.
The work that cannot be unified is the legal analysis — lawful basis, special category conditions, Article 22 exceptions, transparency obligations, cross-border transfer mechanisms. Those remain distinct. But the operational spine supporting them should be shared, and the evidence they produce should be drawn from one place.
The failure mode I see most often is the opposite: a privacy team that built GDPR compliance in 2019 and now bolts AI-specific controls onto the side, and an AI governance team that reads ISO 42001 and designs its own risk assessment template that conflicts with the privacy team’s. The controls duplicate. The documents contradict. The next regulator or auditor to read both will have questions the organisation cannot answer.
Designing the unified control set is the highest-leverage work in any AI-and-privacy programme. It is also, in my experience, the work most consistently deferred. If you are budgeting for AI Act compliance as if it were a separate exercise from your existing privacy programme, the budget is probably forty to sixty per cent higher than it needs to be, and the resulting posture will still be weaker.
Run both regimes as one governance programme. The regulators are not coordinating on your behalf. You will have to.