Training AI on Health Data: What the GDPR Actually Allows

The essentials in 30 seconds

Introduction

Every hospital sitting on years of clinical records eventually asks the same question: can we use this to train a model? The answer is not a simple yes or no, and the projects that stall are rarely blocked by technology. They stall because nobody wrote down, early enough, what the data would be used for and on what legal ground.

Galeon builds an AI-native EHR (DPI) with caregivers since 2016, used in 19 hospitals including 2 university hospitals (CHU), so we work inside this constraint every day rather than around it.

One thing to remember: the GDPR does not forbid training AI on health data, it forbids doing it without a documented purpose and a valid legal basis.

What does the GDPR actually say about health data?

Health data is a special category under Article 9. Its processing is prohibited by default, and becomes lawful only when one of the exceptions in Article 9(2) applies. In a hospital context, three routes come up most often: the provision of healthcare, scientific research in the public interest, and explicit consent.

These routes are not interchangeable. Delivering care to a patient and training a model on that patient's record are two different purposes, and the first does not authorise the second. This is the point where most projects get into trouble: data collected lawfully for care is treated as if it were freely available for anything else.

Which legal basis actually works for AI training?

In practice, most AI training on health data in France proceeds under a research framework rather than individual consent. Consent sounds reassuring but scales badly: it must be free, specific, informed and revocable, and a model already trained cannot easily unlearn one participant.

The research route comes with its own machinery. In France the CNIL publishes reference methodologies that projects can declare conformity with, which avoids a case by case authorisation. A project that fits one of them moves quickly. A project that does not needs a specific authorisation, and that changes the timeline considerably. Knowing which situation you are in should happen before the first line of code, not after the first results.

Anonymisation or pseudonymisation?

This distinction decides the entire regulatory weight of a project, and it is the one most often confused.

Pseudonymised data has had direct identifiers replaced, but re-identification remains possible. It is still personal data, and the GDPR applies in full. Anonymised data cannot reasonably be linked back to a person by anyone, and it falls outside the GDPR entirely.

The catch is that genuine anonymisation is hard on clinical data. A rare diagnosis, an unusual care pathway, a precise date combined with a postal area: richness is exactly what makes health data useful for AI, and exactly what makes it re-identifiable. Treating a pseudonymised dataset as anonymous is one of the most common and most costly mistakes in this field.

Where does the AI Act fit in?

The AI Act adds obligations, it does not replace the GDPR. Both apply, and they answer different questions: the GDPR asks whether you may process this data, the AI Act asks whether this system may be placed on the market and used. A model can be perfectly GDPR compliant and still fall short of AI Act requirements, and the reverse is equally possible.

One point deserves care rather than enthusiasm: the AI Act contains a narrow allowance for processing special category data specifically to detect and correct bias, under strict conditions. It is a targeted provision, not a general permission to reuse health data for training.

Does distributed learning change the equation?

Approaches that keep data inside each establishment and share only model updates genuinely reduce one risk: the mass transfer of records to a central repository. That is a meaningful gain on security and on sovereignty.

It does not, however, remove the need for a legal basis. The model still learns from personal data, even if that data never leaves the hospital, so the purpose still has to be defined and justified. Architecture reduces exposure. It does not substitute for compliance, and any claim that it does should be treated with suspicion.

Limits and challenges to be aware of

FAQ

Do we need patient consent to train a model?
Not necessarily. A research framework is often the more workable route, but it has its own requirements and cannot be assumed either.

If we anonymise, are we outside the GDPR?
Only if the data is genuinely anonymous, meaning re-identification is not reasonably possible by anyone. On clinical data that bar is high and must be demonstrated.

Can we reuse care data because we collected it lawfully?
No. Lawful collection for care does not authorise a different purpose. Reuse must be justified on its own terms.

Does a patient objection stop everything?
Objection rights must be handled, which is far easier when planned upstream than retrofitted after a model exists.

Who decides whether our project is compliant?
The controller documents and answers for it. Anticipating the audit is cheaper than reconstructing the file later.

In summary

Training AI on health data is allowed, and it is not a grey area. It is a documented area. What makes projects fail is almost never the model, it is the absence of a written purpose, a confusion between pseudonymised and anonymous, and the assumption that treating patients grants the right to train on them. Galeon, an HDS certified EHR (DPI) aligned with ISO 27001:2022 and built for interoperability, structures data at the point of entry precisely so that these questions can be answered rather than avoided.

Read next: GDPR and health data, what every hospital CIO needs to know.

Sources