Integrating GDPR Compliance into AI Projects

The GDPR and the AI Act serve different purposes. But inside your AI systems, they govern the same data and a violation of one can trigger enforcement under both.

Most organisations building or deploying AI treat data protection and AI compliance as separate tracks. One team handles the DPIA. Another handles the AI Act risk classification. They use different frameworks, report to different people, and rarely sit in the same meeting.

That separation is becoming expensive. Since the GDPR and the AI Act serve different protective purposes, two separate fines can be imposed for the same AI system. Authorities must coordinate penalties proportionately, but adding them together is legally permissible. The AI Act's penalty structure is tiered: up to €35 million or 7% of turnover for prohibited practices, up to €15 million or 3% for high-risk system violations, and lower thresholds for misleading information. Stack that on top of GDPR's €20 million or 4% ceiling, and a single non-compliant AI system can create financial exposure under two separate enforcement regimes.

The enforcement picture in Belgium is still taking shape — the GBA/APD covers GDPR, while AI Act market surveillance authority designations are being finalised across Member States. But the legal exposure exists regardless of whether both authorities are fully operational today. The framework is in force.

And the overlap between the two is deeper than most compliance teams realise. The AI Act's core quality criteria for training data in Article 10 draw heavily from GDPR's Article 5 - accuracy, transparency, and fairness function as the foundation of both. Compliance by design in the AI Act is directly inspired by GDPR's data protection by design principle. The EDPB is actively developing joint guidelines on how the two frameworks interact, with the expectation that meeting AI Act transparency requirements can help satisfy GDPR accountability obligations.

In practice, this means the work overlaps more than the org charts suggest. The data inventory you need for GDPR - knowing what personal data you process, on what basis, for what purpose - is the same inventory you need to assess whether your AI training data is compliant under Article 10. The DPIA you already run for high-risk processing shares DNA with the Fundamental Rights Impact Assessment the AI Act introduces under Article 27, though the FRIA has a narrower trigger: it applies specifically to public bodies and private entities providing public services, not all deployers. Similar discipline, different legal scope.

There is also the question of roles. AI model providers and deployers can act as both data controllers and processors depending on the use case. That determination matters - it dictates who carries which obligations under GDPR and what the liability chain looks like when something goes wrong. Many organisations deploying third-party AI models have not made this assessment explicitly, which leaves a gap that either regulator could walk through.

Then there is the hardest question: lawful basis. The post-deployment reality is that personal data collected for one purpose often ends up training or fine-tuning AI models — a secondary use that may not be covered by the original consent or legitimate interest assessment. This is actively contested territory. Multiple DPAs have taken different positions on whether original lawful bases extend to AI training. Any organisation feeding personal data into AI systems needs to confront this question head-on with legal counsel, not assume the original basis stretches.

None of this is reason to slow down AI adoption. But it is reason to stop treating data protection and AI governance as parallel workstreams that occasionally wave at each other. The smarter approach starts at the data layer: map what personal data enters your AI systems, resolve the controller/processor question for each use case, verify lawful basis coverage for AI-specific processing, and monitor data quality as a regulatory requirement - not a technical nice-to-have. Build documentation that serves both your DPO and your AI compliance lead from the same source.

The interplay between GDPR and the AI Act is now a daily enforcement reality. The organisations that build integrated governance early will spend less, move faster, and face fewer surprises when either regulator comes knocking.

So the question: when your AI team kicks off a new project next quarter, will your data protection officer be in the room from day one - or brought in after the architecture is already set?

‍