Book an intro

GDPR, AI and the end of siloed compliance

This is the second in a three-part series on GDPR now. It is based on a webinar that we aired on May 27, 2026. A recording of the webinar can be found here

In the first blog in this three-part series, we looked at why GDPR can no longer be treated as a static compliance project. Eight years on, organisations need real accountability, meaningful transparency and ongoing risk assessment.

That shift becomes even more important when AI enters the picture.

AI is not separate from GDPR. If an AI system uses personal data, produces outputs about people or supports decisions affecting people, data protection law is likely to apply. Even where an organisation believes data is anonymised, that assumption needs to be tested rather than taken at face value.

The rise of AI has made GDPR even more relevant.

Why this is relevant now

AI tools are no longer limited to specialist teams or experimental projects. They are being built into CRMs, HR platforms, customer service tools, marketing systems, productivity software and everyday workplace applications.

That creates a real compliance challenge. Organisations may not always know where AI is being used, what data it is accessing, whether suppliers are using data to improve models, or whether individuals are being affected by automated outputs.

At the same time, regulators are increasingly applying GDPR principles to AI systems. The EU AI Act adds another layer of regulation, but it does not replace GDPR. The two regimes overlap, particularly around fairness, transparency, accountability, human oversight and risk management.

GDPR and AI governance are now connected

The EU’s wider digital reform agenda, including the Digital Omnibus proposals and changes linked to the AI Act, reflects a broader move towards integrated digital governance.

For organisations, this means GDPR cannot sit in one compliance silo while AI, cybersecurity, procurement and product governance sit somewhere else.

AI systems depend on data. Cybersecurity failures can become data protection breaches. Supplier decisions can affect international transfers. Product design can determine whether individuals understand how their data is used.

These risks are connected, so the governance needs to be connected too.

Fairness is not only about intention

Fairness is one of the clearest areas where GDPR and AI intersect.

AI systems often learn from historical data. If that data reflects bias, exclusion or past unfairness, the system may reproduce or amplify those issues. The organisation may not intend to discriminate, but the outcome can still disadvantage certain people or groups.

That is why fairness cannot be treated as an abstract principle. It needs to be tested.

Before deploying an AI system, organisations should consider whether the system has been checked for bias, whether the data is appropriate, whether outputs are monitored and whether there is a way to identify unexpected or unfair results.

The compliance question is not: did we mean to be fair? It’s: have we taken reasonable steps to test whether the system works fairly in practice?

Transparency needs to be understandable

AI can make transparency more difficult. Some systems are technically complex, and it may not be possible or useful to explain every detail of how a model works.

But GDPR does not require organisations to confuse people with technical explanations. It requires real information. People need to understand how their data is being used, what type of decision or recommendation is being made, what the likely impact may be and what rights they have.

This requires collaboration. Legal and compliance teams may understand the regulatory requirements, but product, data and customer-facing teams often understand how to explain the system in a way people can actually follow.

A privacy notice alone will rarely be enough. Transparency should be built into the user experience.

Purpose limitation is under pressure

AI also creates tension with purpose limitation.

GDPR requires personal data to be collected for specific, explicit and legitimate purposes. AI systems, however, often encourage broader reuse of data. A dataset collected for customer service might later look useful for training a model. Employee data gathered for HR administration might be tempting to use for workforce analytics.

But the fact that data is available does not mean it can be reused.

Organisations need to ask whether the new use is compatible with the original purpose, whether there is a lawful basis, whether individuals were told about it and whether the new use changes the risk.

This is where innovation can move faster than governance. Without clear controls, teams may start using data in ways that were never properly assessed.

Data minimisation still applies

AI can create a temptation to collect as much data as possible and work out its value later. That approach is difficult to reconcile with GDPR.

Data minimisation requires organisations to collect and use only what is necessary. For AI projects, that means being able to explain why each category of personal data is needed, whether less data could be used, whether data can be anonymised or pseudonymised, and whether retention limits are clear.

“More data means better results” is not a compliance strategy.

Accuracy and human review matter

AI systems can produce predictions, classifications or recommendations that appear authoritative but may be wrong. Where those outputs affect people, the consequences can be serious.

A person might be wrongly flagged as a fraud risk. A job applicant might be rejected because of an inaccurate assessment. A customer might be denied access to a service based on an automated recommendation.

GDPR requires personal data to be accurate, and people must be able to challenge decisions in appropriate circumstances. That means organisations need meaningful human review, not a rubber-stamp process where staff automatically accept the AI output.

Human oversight needs to be real, documented and understood by the people responsible for using the system.

DPIAs are becoming essential AI governance tools

Data protection impact assessments are one of the most practical tools organisations have for managing AI risk.

A strong AI DPIA should consider the purpose of the system, the personal data involved, the lawful basis, fairness risks, transparency, security, rights impacts, supplier arrangements and human oversight. It should also be revisited when the system changes.

This matters because AI systems often evolve. A tool may be updated, connected to new datasets or used for a new purpose. Each of those changes can alter the risk profile.

A DPIA completed before launch may be insufficient if the system later becomes more intrusive or more influential.

What organisations should do now

Organisations using AI should start by understanding where AI is already in use. This includes approved tools, supplier-provided features and informal use by staff.

They should then assess whether personal data is involved, whether existing privacy notices and DPIAs are still accurate, whether suppliers are transparent about data use, and whether staff know what they can and cannot do.

Clear rules are essential. Staff need to know, for example, that personal data should not be uploaded into unapproved AI tools, that sensitive information should be removed where possible and that AI outputs should be reviewed before being used in decisions.

AI governance is not only a technical issue. It is a people, process and accountability issue.

The GDPR challenge of the next decade will be shaped by AI, digital regulation, supplier complexity and faster enforcement.

Organisations that keep GDPR separate from AI governance will struggle. Those that bring privacy, AI, cybersecurity, procurement and operational risk together will be better placed to demonstrate control.

GDPR was already about accountability. AI raises the stakes by making that accountability harder to evidence, but even more important to get right.

Don't miss the first blog in this series: Why compliance can no longer sit in a policy folder

Read it here →