Data you cannot move: GDPR, HIPAA and the alternatives to sharing

Every machine learning project starts with the same question: where is the data, and can we use it? For a lot of the data that matters most, such as patient records, process data from factories and what people type on their phones, the honest answer is “it exists, but it cannot be moved”.

This post is about that answer. It explains why so much data is stuck, what the main privacy laws actually ask for, and the alternatives people use to learn from data they cannot share: anonymisation, synthetic data, differential privacy, secure environments and cryptography. Each one works well for some jobs and breaks down for others. For one job in particular, training a model across several organisations, the best fit is usually federated learning, which is the subject of the rest of this series.

Part 2 explains how federated learning works, Part 3 compares the ways a server can combine updates, and Part 4 surveys the open-source frameworks.

New to AI? AI runs on data: machine learning explained, and why data is hard explains what machine learning is and why it depends on data, and is a good place to start.

This post explains the rules in plain language. It is not legal advice: for a real project, talk to your data protection officer or a lawyer early.

Why the data is stuck

Data stays where it is for four kinds of reason, and most real projects meet more than one.

• Law. Health records, genetic data and anything else that can be linked to a person are tightly regulated. Copying them to another organisation, or another country, needs a legal basis, a clear purpose and often an ethics approval.
• Business. A factory’s process data, a bank’s transactions or a retailer’s sales reveal how the business works. The EU even has a directive on trade secrets (2016/943). No company hands this to a competitor, even for a shared model that would help both.
• Trust. Patients agreed to have their data used to treat them, not necessarily to have it copied to a research server abroad. Even when a transfer is legal, it can still damage trust.
• Practice. A hospital’s imaging archive can run to hundreds of terabytes. Moving it, and keeping copies in sync, is slow and expensive.

What the law asks for

There are many privacy laws, but most follow the same pattern as Europe’s GDPR, so it is the best place to start.

GDPR in five ideas

The General Data Protection Regulation (Regulation (EU) 2016/679) has applied across the EU and EEA since May 2018. Five ideas from it matter most for machine learning.

1. Personal data is broader than names. It is any information about a person who can be identified directly or indirectly. A record with no name, but with a postcode, a birth date and a diagnosis, is usually still personal data.
2. Pseudonymised data is still personal data. Replacing names with codes reduces risk, and the GDPR encourages it, but as long as someone can reverse the coding, or link the record to other data, the GDPR still applies. Only truly anonymous data, where re-identification is no longer reasonably possible, falls outside it.
3. Every use needs a legal basis and a purpose. You must have a reason the regulation recognises, such as consent, a legal obligation or a task in the public interest, and use the data only for the purpose you stated. Use only as much data as you need (data minimisation).
4. Health data is a special category. Health, genetic and biometric data are by default forbidden to process, with listed exceptions such as explicit consent or scientific research with safeguards. Projects that use them at scale need a data protection impact assessment before they start.
5. Moving data is itself regulated. Sending personal data outside the EEA needs an adequacy decision for the destination country, or safeguards such as standard contractual clauses. In 2020, the EU Court of Justice struck down the main framework for transfers to the United States (the Schrems II ruling). It was replaced by the EU–US Data Privacy Framework in 2023, which the EU General Court upheld in 2025; an appeal is pending at the Court of Justice.

The GDPR also asks for data protection by design: choosing technical approaches that collect, copy and expose as little personal data as possible. Fines can reach 20 million euros or 4% of a company’s worldwide annual turnover, whichever is higher.

HIPAA in the United States

The Health Insurance Portability and Accountability Act (1996) works differently from the GDPR. It does not cover all health data, only data held by covered entities: health-care providers, health plans and clearinghouses, and the business associates who work for them. A fitness app outside that circle is not covered by HIPAA at all.

For research, the key idea is de-identification. HIPAA gives two routes:

• Safe Harbor: remove 18 listed identifiers, including names, most geographic detail below the state level, all dates except the year, and phone and record numbers.
• Expert Determination: a qualified expert analyses the data and concludes that the risk of re-identification is very small.

Data that is not de-identified needs patient authorisation, a waiver from an ethics board, or a limited data set under a data use agreement.

The rest of the world, in one table

Several other countries, including India, Canada, Japan and South Korea, have their own laws. The details differ, but the direction is the same everywhere: more protection for sensitive data, and more scrutiny when it crosses a border.

What is coming in Europe

Two newer EU regulations will shape how health and AI projects use data:

• The European Health Data Space (Regulation (EU) 2025/327) entered into force in March 2025. Its rules for the secondary use of health data, for research, innovation and policy, apply from March 2029. Researchers will apply for a data permit to a national health data access body, and work on the data only inside a secure processing environment, with results checked before they leave. The data stays put, and the researcher comes to it.
• The AI Act (Regulation (EU) 2024/1689) requires training data for high-risk AI systems to be relevant, representative and, as far as possible, free of errors. After the 2026 “Digital Omnibus” amendment (Regulation (EU) 2026/1744), these obligations apply from December 2027 for stand-alone high-risk systems and from August 2028 for AI inside regulated products such as medical devices. In practice, this pushes developers towards more varied data, which is often exactly the data they cannot pool.

And in Sweden

My own projects are in Sweden, where the GDPR is supervised by the Swedish Authority for Privacy Protection (IMY). Three national laws add to it. Research on sensitive personal data needs approval from the Swedish Ethical Review Authority under the Ethical Review Act (2003:460). The Patient Data Act (2008:355) controls who may access patient records. Data held by public bodies, including university hospitals, is also covered by the secrecy rules of the Public Access to Information and Secrecy Act (2009:400). A multi-hospital study can easily need all four.

The alternatives, and where each breaks down

If the data cannot move as it is, there are four broad ways forward. They differ in what travels: an altered copy of the data, the analyst, encrypted data, or the model. The sections below take the main options one at a time, including differential privacy, which can be combined with any of them, and contracts, which every route needs. The fourth path, federated learning, comes at the end.

1. Anonymise the data

The oldest answer is to remove whatever identifies people and share the rest. It sounds easy, and it is surprisingly hard to get right, because a few ordinary columns are enough to single people out.

In a well-known study, Latanya Sweeney estimated that 87% of the US population could be uniquely identified by just three values: five-digit ZIP code, sex and full date of birth (Sweeney, 2000). In 1997, she used those same three values to find the medical records of the Governor of Massachusetts in a “de-identified” hospital dataset, by matching it with the public voter list. Later cases repeated the lesson. Netflix’s “anonymous” movie ratings were linked back to named reviewers on IMDb (Narayanan and Shmatikov, 2008). A 2019 study estimated that 15 demographic attributes are enough to re-identify 99.98% of Americans in any dataset (Rocher et al., 2019).

You can see the effect in a few lines of Python. The code builds a synthetic region of 20,000 people and counts how many are the only one with their combination of postcode, birth date and sex.

import numpy as np

rng = np.random.default_rng(7)

# A synthetic region: 20,000 people, 40 postcodes, birth dates over 60 years
N = 20_000
postcode = rng.integers(0, 40, N)
birth_day = rng.integers(0, 60 * 365, N)        # day of birth, counted from 1 Jan 1950
sex = rng.integers(0, 2, N)
birth_year = 1950 + birth_day // 365

def share_unique(*columns):
    """Fraction of people who are the only one with their combination of values."""
    keys = np.stack(columns, axis=1)
    _, group, size = np.unique(keys, axis=0, return_inverse=True, return_counts=True)
    return np.mean(size[group.ravel()] == 1)

print(f"birth year + sex:                {share_unique(birth_year, sex):6.1%} unique")
print(f"postcode + birth year + sex:     {share_unique(postcode, birth_year, sex):6.1%} unique")
print(f"postcode + full birth date + sex:{share_unique(postcode, birth_day, sex):6.1%} unique")

birth year + sex:                  0.0% unique
postcode + birth year + sex:       1.6% unique
postcode + full birth date + sex: 98.9% unique

Now suppose a regional health register publishes a research file with names removed but those three columns kept, and an attacker also has a public register that lists names, postcodes, birth dates and sex for 60% of the same people.

# The health register publishes an "anonymised" file: no names, but these three
# columns kept for research. Five percent of patients have a sensitive diagnosis.
diagnosis = rng.random(N) < 0.05

# A public register (think electoral roll) lists name, postcode, birth date and
# sex for 60% of the same people.
in_register = rng.random(N) < 0.60

key = postcode * 10**7 + birth_day * 10 + sex        # one number per combination
_, group, size = np.unique(key, return_inverse=True, return_counts=True)
unique_in_release = size[group] == 1

reidentified = in_register & unique_in_release
print(f"people in the register:         {in_register.sum():,}")
print(f"re-identified by a simple join: {reidentified.sum():,} ({reidentified.sum() / in_register.sum():.0%})")
print(f"  of whom have the diagnosis:   {(reidentified & diagnosis).sum():,}")

people in the register:         12,057
re-identified by a simple join: 11,912 (99%)
  of whom have the diagnosis:   630

The fix is to coarsen the data: birth year instead of birth date, region instead of postcode, until every combination is shared by at least k people. This is called k-anonymity, and the code shows it works: with birth year and sex alone, nobody is unique. But the coarsened data has also lost the detail a study often needs, such as exact ages for children or local patterns of disease. Rare conditions are the hardest case of all, because a rare diagnosis is itself an identifier. And since the GDPR judges anonymity against “all the means reasonably likely to be used”, a file that is anonymous today can stop being anonymous when new public data appears.

2. Generate synthetic data

A newer idea is to train a generative model on the real data, then share fake records that have the same statistical patterns. Synthetic data is excellent for testing software, teaching and sharing examples of a data format.

As a privacy guarantee, it is weaker than it sounds. A generator that is faithful enough to be useful can also reproduce rare, real records, and outliers are exactly the people most at risk. A careful evaluation found that synthetic data did not give a better trade-off between privacy and usefulness than traditional anonymisation (Stadler et al., 2022). Under the GDPR, synthetic data is not automatically anonymous: it has to be assessed like any other release.

3. Add noise: differential privacy

Differential privacy turns the question around. Instead of asking “can anyone be re-identified?”, it promises that the result of an analysis would look almost the same whether or not any one person’s data was included (Dwork et al., 2006). It achieves this by adding carefully sized random noise. A single number, epsilon, controls the trade-off: smaller epsilon means more noise and more privacy.

It is the only approach in this list with a mathematical guarantee about what a result reveals about any one person, and it is used at scale. The US Census Bureau used it for the 2020 census, and Apple and Google use it to collect usage statistics from phones.

Here is the threat it defends against. An attacker asks two harmless-looking questions, one that includes Alice and one that does not, and subtracts the answers.

# A differencing attack. The attacker asks two harmless-looking questions:
#   A: how many patients in postcode 7 have the diagnosis?
#   B: the same, but leaving out everyone born on Alice's birthday.
# If Alice is the only one born that day, A - B reveals her diagnosis.
def laplace_count(true_count, epsilon):
    """A differentially private count: the true count plus Laplace noise."""
    return true_count + rng.laplace(0, 1 / epsilon, size=np.shape(true_count))

trials = 20_000
print("epsilon   typical error   attacker right")
for epsilon in [0.1, 0.5, 1, 2, 5, 10]:
    alice = rng.random(trials) < 0.5                  # does Alice have it? (50/50 prior)
    others = rng.binomial(25, 0.05, trials)           # the rest of postcode 7
    a = laplace_count(others + alice, epsilon)
    b = laplace_count(others, epsilon)
    guess = (a - b) > 0.5
    error = np.mean(np.abs(a - (others + alice)))
    print(f"{epsilon:>7}   {error:>13.2f}   {np.mean(guess == alice):>14.0%}")
print("no noise          0.00             100%")

epsilon   typical error   attacker right
    0.1            9.87              51%
    0.5            1.96              56%
      1            1.01              62%
      2            0.50              73%
      5            0.20              91%
     10            0.10              99%
no noise          0.00             100%

Without noise, the attacker is always right. At epsilon 1, they are right 62% of the time, against 50% for a blind guess, while an honest analyst’s count is off by about one patient. That is a good deal for a count over thousands of people, and a bad one for a count of five. This is differential privacy’s catch: the noise is fixed, so it hurts small groups and small datasets the most. Every extra question also spends more of the privacy budget, so a dataset can only answer so many questions before the guarantee wears thin.

4. Bring people to the data

Instead of releasing data, the owner can let approved researchers work on it inside a controlled computer environment, called a secure processing environment or trusted research environment. Researchers see the data but cannot copy it out; only checked results, such as tables and model coefficients, leave. This is the approach the European Health Data Space builds on, and it is widely used for national registers.

It works well when one organisation holds all the data. When the data is spread across several hospitals, companies or countries, someone still has to copy it into one environment, and that is often exactly the step that is not allowed.

5. Compute on encrypted data

Cryptography offers ways to compute on data that nobody can see:

• Homomorphic encryption lets a server calculate directly on encrypted numbers; only the data owner can decrypt the result.
• Secure multi-party computation splits each value into random-looking shares held by different parties, who compute together without any of them seeing the inputs. One of its first real uses, in 2008, set sugar beet prices in Denmark without farmers revealing their bids.
• Trusted execution environments are sealed areas of a processor where data is decrypted and processed out of reach of the computer’s operator. You do have to trust the chip maker, and researchers have found side-channel attacks against several designs.

The guarantees of the first two are very strong. The cost is too: depending on the task, encrypted computation can be hundreds to millions of times slower than computing on plain data. That makes it practical for statistics, auctions and secure sums between a few parties, but not, so far, for training large models across many sites.

6. Contracts and consent

Finally, there is the legal route: data processing agreements, consent forms and joint controller arrangements. Every approach above needs some of this paperwork anyway. On its own, it controls who may see the data but does not reduce the technical risk, and negotiating agreements between several hospitals or companies often takes many months.

All of them side by side

Here is my rough summary of how the options compare for one specific job: training a model on data held by several organisations.

Why federated learning is usually the answer

Federated learning takes the fourth path in the first figure: instead of moving the data, it sends the model to the data. Each organisation trains the model on its own data, behind its own firewall, and sends back only the changes to the model. A coordinating server combines those changes into a better model, and the cycle repeats.

That design fits the problems above unusually well:

• The raw data never moves, so there is no copy to anonymise, no transfer to justify and no single store to breach. It is a direct way to practise data protection by design and data minimisation.
• It keeps the detail. Unlike anonymisation or synthetic data, it trains on the full, real records, rare cases included, so the model is usually close to one trained on pooled data.
• It scales to many owners, from a handful of hospitals to millions of phones, which secure environments and cryptography struggle to do.
• It combines with the other tools. Differential privacy and secure aggregation, a cryptographic technique that lets the server see only the sum of the updates (Bonawitz et al., 2017), can be added on top where the updates themselves need protecting.

It is not magic, and it is important to be honest about that. Model updates are not raw data, but they are not nothing: under some conditions, an attacker who sees an individual update can reconstruct parts of the training data from it (Zhu et al., 2019). Federated learning does not make data anonymous, and it does not make a project GDPR-compliant on its own: you still need a legal basis, an impact assessment for sensitive data, and agreements between the partners. The European Data Protection Supervisor and Spain’s data protection authority (AEPD) reached a similar conclusion in their joint 2025 report on federated learning, which describes it as a promising privacy-friendly approach that still calls for data protection by design and a careful risk assessment.

So the claim is narrower, and stronger for it: when you need to train a model on data that is spread across several owners and cannot be pooled, federated learning is usually the best starting point, ideally with secure aggregation or differential privacy on top. For one-off statistics, a secure environment or differential privacy may be simpler. For a single dataset that can legally be pooled, central training is simpler still.

Next: how federated learning works

Part 2 explains federated learning from the ground up: how a training round works, how the server combines updates, where it is used and what makes it hard, with a 30-line example you can run.

Further reading

• Regulation (EU) 2016/679, the GDPR. Recital 26 and Articles 4, 5, 9 and 25 cover most of what this post discusses.
• US Department of Health and Human Services. Guidance on de-identification under HIPAA.
• Sweeney (2000). Simple Demographics Often Identify People Uniquely.
• Rocher, Hendrickx and de Montjoye (2019). Estimating the success of re-identifications in incomplete datasets using generative models.
• Stadler, Oprisanu and Troncoso (2022). Synthetic Data: Anonymisation Groundhog Day.
• McMahan et al. (2018). Learning Differentially Private Recurrent Language Models. How differential privacy is added to federated learning.

Want to go further? Browse my publications on federated learning, or look at the open thesis topics if you would like to work on these problems with us.