A product manager comes to you wanting to feed customer support transcripts into an AI model to draft replies. It will save hours. It also touches personal data and an automated decision, two things the law now has firm opinions about. The question isn't "is this allowed?" It's "what do we have to be able to show we thought about?" That shift, from permission to accountability, is the whole game.

The quick version

  • Data protection (in Europe, the GDPR) governs how you collect, use and store people's personal data. Its core demand is accountability: you must not only comply, you must be able to prove you complied.
  • The EU AI Act is the first broad law specifically for AI. It sorts AI systems into risk tiers, a few are banned, some are "high-risk" and heavily regulated, most carry only light transparency duties.
  • The two laws overlap but don't replace each other. GDPR covers the personal data inside your AI; the AI Act covers the system itself. Meeting one does not mean you've met the other.
  • The practical move for a leader is the same under both: know what data and which AI systems you have, decide who owns the risk, and write down your reasoning before you ship.

The idea in depth: data protection is an accountability law

Most people picture data-protection law as a list of things you can't do. That's half of it. The General Data Protection Regulation (GDPR), in force across the EU since 2018, rests on seven principles set out in Article 5: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality (security); and, the one leaders underrate, accountability, which says you must not only follow the other six but be able to demonstrate that you do.

So the move is to stop thinking of compliance as a state and start thinking of it as evidence. When that product manager asks to use support transcripts, the right response isn't yes or no, it's "what's our lawful basis, did we take only the data we need, and where is that written down?" A defensible decision you can show beats a cautious decision nobody recorded. Build the habit of a short written rationale for any new use of personal data, and you have met the spirit of Article 5 before a regulator asks.

The reason this earns a leader's attention: the penalties are sized to be felt. Article 83 sets two tiers, up to €10 million or 2% of global turnover for lesser breaches, and up to €20 million or 4% of global turnover (whichever is higher) for breaching the core principles or people's rights. These are ceilings, not typical fines, but the ceiling is real. In May 2023 the Irish Data Protection Commission fined Meta €1.2 billion over unlawful EU-to-US data transfers, then the largest GDPR penalty on record (European Data Protection Board, 2023).

An honest limitation. The GDPR is European law, and this guide leans on it because it is the most copied data-protection regime in the world, the UK GDPR, Brazil's LGPD and others echo it closely. But it is not universal: the United States has no single federal equivalent, only a patchwork of state laws (California's CPRA among them) and sector rules. Treat the GDPR's principles as a sturdy default, and check the specific regime in every market you operate in.

The idea in depth: the EU AI Act sorts systems by risk

Data-protection law cares about data. The newer wave of regulation cares about the system, and the flagship is the EU AI Act, which entered into force on 1 August 2024 as the first broad, horizontal AI law of its kind (European Commission). Its central idea is a risk pyramid. Rather than regulate "AI" as one thing, it asks what a given system is used for and scales the obligations to match.

flowchart TD
  A(["What is the AI system used for?"]) --> B(["Unacceptable risk
e.g. social scoring,
manipulative systems → BANNED"])
  A --> C(["High risk
e.g. hiring, credit, medical
→ strict obligations"])
  A --> D(["Limited risk
e.g. chatbots → must tell
users they're using AI"])
  A --> E(["Minimal risk
most software → few or
no extra duties"])
The EU AI Act's risk pyramid, obligations scale with what the system does, not what it's called. Leaders Loop

At the top, a small set of uses are simply prohibited, government-style social scoring, manipulative systems, certain biometric categorisation. Below that, high-risk systems, AI used in hiring, credit scoring, essential services or medical devices, are allowed but carry heavy duties: risk management, data governance, human oversight, documentation. Limited-risk systems, like a customer-facing chatbot, mostly owe transparency: tell people they're dealing with AI. And the majority of everyday software falls into minimal risk, with little or no extra burden. Penalties for the worst breaches reach up to €35 million or 7% of global turnover (AI Act, Article 99).

So the move, before you panic about "AI compliance," is to classify. For each AI use, ask one question: which tier? A support-reply tool drafting messages a human approves is almost certainly minimal-to-limited risk, you may owe nothing more than a clear note that AI helped. An AI that screens job applicants is high-risk, and a different conversation entirely. Most of your fear lives in the wrong tier. The obligations also arrive on a staggered clock: bans and AI-literacy duties applied from 2 February 2025, rules for general-purpose AI models from August 2025, and the bulk of the high-risk obligations become fully applicable on 2 August 2026 (artificialintelligenceact.eu). A high-risk system gives you a runway, but a finite one.

An honest limitation. The AI Act is young, and much of how it works in practice, the technical standards, the conformity assessments, how regulators actually enforce it, is still being written. Anyone selling you total certainty about AI compliance in 2026 is selling. Build for the principles (oversight, documentation, honesty about what your system does) rather than chasing every interpretive detail, because the principles are what will endure.

The idea in depth: where the two laws meet

Here is the trap that catches careful organisations: assuming that because they "do GDPR," they're covered for AI. The two laws overlap heavily, both demand documentation, impact assessments, transparency and clear ownership, but they protect different things. GDPR protects the personal data flowing through a system; the AI Act regulates the system itself. The International Association of Privacy Professionals, mapping the two, is blunt that GDPR compliance gives you a foundation but does not satisfy the AI Act's added duties around robustness, bias monitoring and conformity assessment (IAPP, "Mapping the Interplays").

GDPR covers the data inside your AI. The AI Act covers the AI itself. Doing one does not mean you've done the other.

The encouraging part is that the design instinct is shared. The AI Act's idea of building compliance in from the start is drawn straight from GDPR's Article 25 principle of data protection by design and by default, think about rights and risks at the drawing board, not after launch. So the move is to make one habit serve both laws: when a project touches personal data or a meaningful AI decision, run a single up-front review that asks the data questions (lawful basis, minimisation, security) and the system questions (risk tier, human oversight, transparency) together. The European Data Protection Supervisor's guidance on the AI Act helps keep the two aligned, and mapping your regulatory landscape & compliance obligations across markets stops a single review from missing a jurisdiction.

A worked example

Take a mid-sized HR-software firm, call it Tessera. (Illustrative scenario; not a real company.) Its team wants to ship a feature that ranks job applicants by predicted "fit," trained on a decade of the company's own hiring outcomes. It sounds like a productivity win. Run it through the two-law lens and it looks different.

The data questions (GDPR). The training data is full of personal data about past applicants, what's the lawful basis for reusing it, and does purpose limitation allow it? Minimisation asks whether they really need every field. And because this is automated decision-making affecting people's livelihoods, GDPR gives those applicants rights to meaningful information and human review.

The system questions (AI Act). AI used in recruitment is explicitly named as high-risk, triggering the heavy tier: documented risk management, data-governance checks for bias, genuine human oversight (a person who can actually overrule the model, not rubber-stamp it), and technical documentation a regulator could inspect.

flowchart TD
  A(["Tessera wants to rank
job applicants with AI"]) --> B{"Does it use
personal data?"}
  B -->|"Yes"| C(["GDPR: lawful basis,
minimisation, right to
human review"])
  A --> D{"What's the
AI Act risk tier?"}
  D -->|"Hiring = HIGH risk"| E(["AI Act: risk mgmt,
bias checks, real human
oversight, documentation"])
  C --> F(["One up-front review
before shipping"])
  E --> F
  F --> G(["Decision recorded,
owner named, ship
or redesign"])
One review, two laws, the high-risk path forces the design questions before code ships, not after a complaint. Leaders Loop

The leader's job here is not to memorise statutes. It's to insist the feature passes one combined review before launch, name a single owner for the risk, and make sure a human can override the ranking. Tessera may still ship, but it ships a defensible, documented, overridable system, which is exactly what both laws were built to require. The version that quietly went live without that review is the one that becomes a headline.

Frequently asked questions

We're not in Europe, does any of this apply to us?

Possibly. The GDPR and the EU AI Act both reach beyond the EU's borders: if you offer goods or services to people in the EU, or process their data, the rules can apply wherever you're based. Beyond that, many countries have modelled their own laws on the GDPR, so its principles are a sensible global baseline. The safe assumption is that "we're not in Europe" is a reason to check, not a reason to relax, confirm the specific regime in each market you serve.

What's the difference between GDPR and the EU AI Act in one line?

GDPR is about personal data, how you collect and use information about people. The AI Act is about AI systems, how they're built, what they're used for, and how risky that use is. They overlap, but one protects the data and the other regulates the machine.

Is using ChatGPT or a similar tool at work a compliance problem?

It can be, depending on what you put in. Pasting customers' personal data into a third-party AI tool is a data-protection question (where does that data go, and on what basis?); using AI to draft internal text is usually low-risk. The practical guardrail is a short, clear policy on what staff may and may not put into external AI tools, and which approved tools to use. That single document prevents most of the real exposure.

Do we need a Data Protection Impact Assessment (DPIA)?

Under GDPR, a DPIA is required when processing is likely to be high-risk to people's rights, large-scale profiling, sensitive data, or systematic monitoring are common triggers. It's a structured "what could go wrong and how will we mitigate it?" written before you start. Even where it isn't strictly mandatory, a lightweight version is cheap insurance, and it doubles as evidence under the accountability principle.

Related in the Toolkit

Data and AI rules don't live alone, they sit inside the wider machinery of how an organisation governs itself. The duty to map your obligations across markets (regulatory landscape & compliance obligations) is the parent discipline, and ultimately the people who answer for getting it wrong are the directors (board roles & committees).

Where to go next