Synthetic data

What is synthetic data?

Synthetic data is artificially generated records that copy the statistical shape of a real dataset without being real records. The columns, the value ranges, the way one field moves with another: those are reproduced, but no single row belongs to a real person or a real event.

Generation methods sit on a range. At the simple end you write the rules by hand, for example a customer id in a fixed format and one order in ten cancelled. At the other end a generative model learns the structure of the real data and produces new rows that fit it, the same kind of technique behind other generative AI. The closer the generator copies the real data, the more useful the output, and the more care it demands.

Picture a stunt double: a close enough match to shoot the scene, but not the star. Synthetic data makes the same trade, fake at the level of one row and useful across the whole table.

Where synthetic data earns its place

Three jobs come up again and again.

1. Test and development environments. A bank or a hospital can give developers a database that looks and behaves like production without putting real customer records in a test system. The application gets exercised against realistic volumes and edge cases while the real people stay out of the copy.

2. Sharing across parties. A supplier, a research group or another team can work on a synthetic version of your dataset while the real records never leave your control. When several parties instead need to combine sensitive data they each hold, a data clean room is the usual alternative.

3. Balancing rare classes. Fraud, machine failures and rare diseases turn up in a handful of rows, so a model barely learns them. Generating extra synthetic examples of the rare case gives the model more to train on, a common answer to class imbalance.

Take a fraud model where genuine fraud is one transaction in a thousand. Train on the raw data and the model can label everything legitimate and still be right 99.9 percent of the time, which helps no one. Extra synthetic fraud records rebalance what the model sees.

Synthetic data is not automatically anonymous

The pitch you hear most is that synthetic data sidesteps privacy law because none of the rows are real. That is half true at best.

Generating the data is itself processing of personal data: you start from real records, and under the GDPR that needs a lawful basis. Recital 26 sets the bar for when the output escapes the GDPR: data counts as anonymous only when a person is "not or no longer identifiable," judged against all the means reasonably likely to be used, including singling someone out. A label that says "synthetic" does not clear that bar on its own.

The risk is documented, not hypothetical. A generative model trained on personal data can memorise unusual records and reproduce something close to them, which is what membership inference attacks exploit: an attacker checks whether a specific person's record shows through in the output. Researchers at EPFL and UCL, in a 2022 study at USENIX Security, tested a range of generative models and found that synthetic data either fails to stop these inference attacks or loses so much detail that it stops being useful, and that the privacy you actually get is hard to predict.

This is why careful releases pair generation with differential privacy, which adds calibrated noise so no single record changes the result much. NIST's work on differentially private synthetic data makes the same case: a mathematical privacy guarantee is what lets you trust that the output cannot be traced back to individuals. Treat a synthetic dataset as anonymous only after a documented re-identification risk assessment says you can.

What synthetic data does not fix

Two limits get lost in the sales copy.

First, bias travels. Synthetic data reproduces the distribution of the source, and that includes the source's skew. If a group is under-represented or scored unfairly in the real data, the synthetic copy carries the same blind spot, because copying the statistics is the whole point. This is the same kind of bias that turns up in hiring and credit models, so check the source before you generate, not after.

Second, the rare cases thin out. A generator leans toward the common patterns and smooths over the outliers, so the one-in-ten-thousand events, often the ones you care about most, can end up under-represented or missing in the synthetic version. The same USENIX Security study made the point directly: you cannot tell in advance which signals a synthetic dataset keeps and which it loses. A model trained only on synthetic data inherits both, the source's bias and its thin tails.

How it differs from masking and anonymisation

Synthetic data is easy to mix up with two neighbours, and the difference comes down to one question: does a real person still sit behind each row?

With data masking and with anonymisation and pseudonymisation, the answer is yes. You keep the real records and obscure them, swapping a name for a code or blurring a birth date, so every row still describes one real individual, only less legibly. Pseudonymised data even stays personal data under the GDPR, because the link back can be restored.

Synthetic data answers no: the real rows are thrown away and new ones generated to match the table as a whole. That changes where the exposure sits. Masked and anonymised data leaks through linkage, when another source re-attaches a name; synthetic data leaks through the generator, which can echo the unusual records it trained on. Reach for masking or anonymisation when each row has to stay true, say for an audit, and for synthetic data when you need the patterns and not the individuals.