For most European companies, the question that stalls an AI project isn’t technical. It’s legal: are we even allowed to do this with our data?

It’s a fair question, and the uncertainty is expensive. Some companies freeze and do nothing. Others move fast and paste sensitive information into public chatbots. Both are avoidable. The GDPR does not prohibit AI — it sets conditions, and most business AI use cases can be designed to meet them from the start.

This guide covers the questions worth answering before you build, in plain language.

A note: this is practical guidance from an engineering perspective, not legal advice. For anything consequential, involve your legal counsel or DPO.

The four questions to answer before any AI project

Almost every GDPR concern in an AI project reduces to four questions:

1. What personal data will the AI actually see?
2. What is our legal basis for using it that way?
3. Where is it processed, and by whom?
4. Can we explain and control what the system does?

If you can answer these clearly, you are most of the way to a defensible project. If you can’t, that’s the work to do before writing code — not after.

What data does the AI actually see?

Start by mapping it honestly. Many AI use cases touch far less personal data than people assume — and some touch much more than intended.

Two GDPR principles do most of the work here:

• Data minimization — the AI should only receive the data it genuinely needs for the task. If a document-classification model only needs the document type, it doesn’t need the customer’s full record attached.
• Purpose limitation — data collected for one purpose can’t automatically be reused for another. Support tickets collected to resolve customer issues aren’t automatically available to train a model, unless that use is compatible and covered.

Be especially careful with special category data (health, biometrics, and similar). It carries stricter conditions, and it often hides inside free-text fields nobody thought of as sensitive.

A practical habit: strip or pseudonymize what the model doesn’t need before it ever reaches the model.

What’s your legal basis?

Under the GDPR, every processing activity needs a lawful basis. For business AI, the realistic candidates are usually:

• Contract — the processing is necessary to deliver a service the person signed up for.
• Legitimate interest — you have a genuine business interest that doesn’t override the individual’s rights. This requires an actual balancing assessment, documented.
• Consent — appropriate in some cases, but weaker than it looks: it must be freely given, specific and withdrawable, which is hard to sustain for internal operational tools.

The common mistake is assuming “we already have the data, so we can use it for anything.” Having data lawfully for one purpose doesn’t automatically extend to a new AI purpose.

Where is the data processed?

This is where AI projects most often go wrong, quietly.

When you send data to a third-party AI provider, that provider is typically acting as a processor on your behalf. That means you need a data processing agreement with them, clarity on what they do with your inputs, and — critically — confirmation of whether your data is used to train their models. Many enterprise offerings disable training on customer data; many consumer-facing ones do not.

If processing happens outside the EEA, you need a valid transfer mechanism: an adequacy decision or Standard Contractual Clauses with appropriate safeguards.

Practically, this shapes architecture:

• Prefer providers with EU processing regions where the data warrants it.
• For sensitive workloads, consider models that can run in your own environment.
• Keep a record of which system sends what, where. If you can’t draw that diagram, you can’t defend it.

Can you explain and control what it does?

Two further obligations matter once the system is live.

Transparency. People whose data is processed have a right to know it’s happening, in clear terms. If AI is involved in handling customer data, your privacy notice should reflect reality — not a generic paragraph written years ago.

Automated decisions. The GDPR gives people the right not to be subject to decisions based solely on automated processing where those decisions have legal or similarly significant effects — think credit, employment, or access to a service. The practical answer for most companies is straightforward: keep a human in the loop for consequential decisions. Use AI to prepare, rank and draft; let a person decide and own the outcome.

If a project involves large-scale processing of sensitive data or systematic evaluation of individuals, a Data Protection Impact Assessment (DPIA) may be required. It’s better treated as a design tool than a formality — it surfaces risks while they’re still cheap to fix.

What the EU AI Act adds

The GDPR governs personal data. The EU AI Act governs AI systems, and it applies on top — it doesn’t replace your GDPR obligations.

It works on a risk-based tiering: a small set of practices is prohibited outright; a defined set of high-risk uses (things like AI in recruitment, credit scoring, or critical infrastructure) carries substantial obligations around risk management, data governance, documentation and human oversight; and most other systems fall into lighter categories where the main requirements are transparency — for example, making clear when someone is interacting with an AI system or seeing AI-generated content.

Two things are worth knowing:

• Most ordinary business use cases are not high-risk. Document extraction, internal knowledge search, summarization and routing typically fall into the lighter tiers. If your use case touches hiring, credit, or access to essential services, treat it as high-risk until confirmed otherwise.
• Obligations are phasing in over time, and the timelines and guidance have continued to evolve. Check the current state with counsel rather than relying on a blog post’s snapshot — including this one.

Building AI that is useful and compliant

None of this requires a legal department to adopt AI. It requires designing with a few habits:

• Choose use cases that fit your data reality. The highest-value early projects are often the ones touching the least personal data — internal documentation search, document extraction, operational forecasting.
• Minimize before you send. Strip, mask or pseudonymize what the model doesn’t need.
• Know your processors. Get the DPA, confirm the training and retention terms, know the processing location.
• Keep humans on consequential decisions. It’s better practice and it resolves most Article 22 concerns.
• Document as you build. Legal basis, data flows, and decisions — written down while they’re fresh, not reconstructed a year later under pressure.
• Update your privacy notice to reflect what the system actually does.

Done this way, compliance stops being the thing that blocks AI and becomes part of what makes it trustworthy enough to deploy in a real business.

Frequently asked questions

Does the GDPR prohibit using AI? No. The GDPR doesn’t ban AI — it sets conditions on how personal data is used. You need a lawful basis, you must minimize the data the AI sees, be transparent about it, control where it’s processed, and keep humans in charge of consequential decisions. Most business AI use cases can be designed to meet these conditions.

Can we use our customer data to train an AI model? Not automatically. Data collected for one purpose can’t be reused for an incompatible new purpose without a valid basis. Also check your AI provider’s terms: many consumer tools may use your inputs to improve their models, while enterprise offerings typically allow you to disable this. Confirm it in the data processing agreement.

Does our data have to stay in the EU? Not necessarily, but transfers outside the EEA need a valid mechanism such as an adequacy decision or Standard Contractual Clauses with appropriate safeguards. For sensitive workloads, using EU processing regions or self-hosted models is often the simpler and safer choice.

Do we need a DPIA for an AI project? Sometimes. A Data Protection Impact Assessment is generally required for high-risk processing, such as large-scale handling of sensitive data or systematic evaluation of individuals. Even when it isn’t strictly required, running one early is a useful way to catch design problems while they’re still cheap to fix.

How does the EU AI Act relate to the GDPR? They’re complementary. The GDPR governs personal data; the AI Act governs AI systems by risk level, adding obligations for high-risk uses and transparency requirements for others. Complying with one doesn’t exempt you from the other.

---

Thinking about where AI could help your business — and want a partner who takes data protection seriously from the design stage? Explore our AI adoption program or get in touch for a first conversation.