Synthetic data: when it replaces real data and when it misleads

Synthetic data is artificially generated data that mimics the structure and statistical behaviour of real data without being a record of any actual person or transaction. It gets sold as the elegant answer to a genuine problem: you need data to test, train or demo, and the data you have carries names, ID numbers, medical histories or figures that should not leave where they live. The promise sounds perfect. Which is exactly why it deserves a closer look.

This guide stays concrete: what synthetic data really is, where it replaces real data with no loss, where it hands you false confidence, how it is generated, what GDPR asks before you touch it, and how to measure whether the dataset you built is worth anything. No laboratory theory — this is what we see working in companies without a research team.

One warning up front: synthetic data is not anonymisation, even though both get used for the same purpose. They are different things with different risks, and conflating them is the first mistake.

What is synthetic data, and what is it not?

A synthetic dataset is produced by a model that learns the properties of a real dataset — distributions, correlations, time patterns — and then generates new rows that respect those properties. Row 1,482 of your synthetic customer table matches no customer: it is a plausible combination of values that could exist.

What it is not:

• Not anonymisation. Anonymising means taking real data and breaking the link to the person. Synthesising means generating new data. The practical difference, and when GDPR requires each, is covered in the data anonymisation guide.
• Not random fake data. Filling a table with names off a list and random amounts is dummy data. Useful to check a form does not break, useless for anything that depends on structure.
• Not automatically safe. A generator trained on few records can memorise and reproduce a specific individual almost verbatim. The risk drops a lot, but it is not zero by definition.
• Not a fix for bad data. If the source dataset is dirty, biased or incomplete, the synthetic one inherits those flaws and hides them on top. Worth reading the data quality guide first.

The honest framing: synthetic data lowers risk and unblocks work that was stalled. It does not turn a data problem into a non-problem.

When does synthetic data replace real data?

The pattern is fairly clear. It works when what you need is structure and volume, and it fails when you need truth about specific facts.

| Scenario | Does synthetic work? | Why | |---|---|---| | Development and test environments | Yes, very well | You need realistically shaped tables, not real customers | | Demos to clients or to the board | Yes | You avoid showing someone else's book on a screen | | Internal team training | Yes | They practise on realistic cases without production access | | Load and performance testing | Yes | You can generate 50× your current volume | | Sharing with an external vendor | Yes, with controls | Lowers the risk of the transfer; does not replace the contract | | Training a model headed for production | With caveats | Good to bootstrap or balance classes; rarely as the only source | | Business analytics and reporting | No | A dashboard built on invented data is an invented dashboard | | Audit, compliance, legal evidence | No | You need the real, traceable fact |

The most interesting and most misread case is model training. Synthetic data earns its place in two narrow situations: when a class is so under-represented that the model never learns it (fraud, breakdowns, defaults — rare events by definition), and when you want to prove an approach makes sense before requesting access to real data, which in many companies takes weeks of paperwork. What synthetic data does not do is invent signal that was not there. If your real data holds no relationship between a customer's behaviour and their churn, a model trained on synthetic data will not find one either — it will just reproduce the absence of a relationship across more rows.

When does synthetic data mislead?

Here is the part the brochures leave out. Three ways it leads you to false conclusions:

The model looks excellent and is not. If you evaluate a model trained on synthetic data using synthetic data as well, you are measuring how faithfully the model reproduces your generator, not reality. The metric goes up and means nothing. Non-negotiable rule: the evaluation set is always real data, however small.

The tails disappear. Generators learn the centre of the distribution well and the extremes badly. Rare cases — the €400,000 order, the patient with five conditions, the transaction at 4 a.m. — get smoothed away or lost. And in most useful projects, the value sits precisely there, in the extreme.

Bias gets laundered. If your hiring history favoured one profile, the synthetic version will reproduce it, now wrapped in apparent neutrality because "these are not real people's data any more". The bias has not gone; it has become harder to point at. Same problem we describe in AI CV screening.

A synthetic dataset is only as good as the question you plan to ask it. If you do not know what you will validate with it, do not generate it.

How is it generated? Three families and what each costs

You do not need research infrastructure. In practice the options rank by effort:

1. Rules and simulation. You define the schema, ranges, proportions and business rules by hand (an order has at least one line; the start date precedes the end date). Cheapest, most controllable, most used. Covers 80% of development and testing cases. 2. Statistical models. You fit the distributions and correlations of the real dataset and sample from them. Keeps the relationships between columns without learning anyone in particular. A good middle ground for customer, consumption or transaction tables. 3. Generative models. Networks trained on the original dataset to produce new rows, text or images. The most faithful and the most expensive: it demands starting volume, compute and, above all, privacy controls, because this is where the memorisation risk lives.

Our advice, repeated on nearly every project: start at level 1. Most teams that "need synthetic data" actually need a decent rule-based generator and two afternoons of work, not a generative model with its own lifecycle. And if you do end up at level 3, that generator is a production model with everything that implies — versions, monitoring and maintenance, like any other (MLOps).

What does GDPR say about synthetic data?

GDPR does not mention it by name. What matters is a single question: does the result allow anyone to be re-identified, on its own or combined with other reasonably available information? If the answer is no, that dataset falls outside the regulation. If it is yes — even for a minority of rows — you are still processing personal data and everything applies.

Four practical obligations follow, none of them skippable:

• Training the generator is processing. To build the synthetic set you used real personal data. That needs a legal basis and belongs in the record of processing activities.
• Document the re-identification risk. Claiming it is synthetic is not enough. Measure the distance between generated rows and original ones and discard anything that sits too close to a unique record.
• Be careful with special category data. Health, biometrics, beliefs: the bar rises, and synthesising alone does not lower it.
• Keep a trail. Who generated the dataset, with which generator version, from which source and on what date. This is exactly the data governance discipline applied to a new artefact.

If you are reaching for synthetic data specifically to dodge an uncomfortable privacy conversation, you are starting badly. The approach that works is the opposite: use it as one more control inside a framework you already keep in order, which is what we cover in the GDPR and AI guide.

How do you measure whether a synthetic dataset is any good?

Three checks. If it cannot pass them, do not use it yet.

Fidelity. Does it resemble the real thing? Compare distribution against distribution and the correlation matrices. A quick and brutally honest test: train a classifier to tell real rows from synthetic ones. If it is right 95% of the time, your synthetic data resembles nothing. If it hovers near 50%, good sign.

Utility. Does it serve the task? Train the model on synthetic data, evaluate it on real data, and compare against the same model trained on real data. The drop in performance is the price of not using real data, and you decide whether to pay it.

Privacy. Does it protect? Measure the distance from each generated row to its nearest neighbour in the original. Rows glued to a real record get discarded. And run the outlier test: if your largest customer is identifiable in the synthetic set by sheer volume, you have protected nothing.

How do you start without a six-month project?

A four-step path that fits into a month of part-time work:

1. Write the use case in one sentence, including the decision you will make with that data. If the sentence does not come out, data is not your problem. 2. Pick a single table — the one blocking development or training the most today — and generate it with rules. Two days. 3. Run the three checks on fidelity, utility and privacy. Document the result, even if it is one page. 4. Decide whether to level up. Only if the rule-based generator falls short for the real question do you move to models. Not before.

What makes this work is not the technique, it is the discipline of not fooling yourself: always evaluate on real data, document what gets lost, and never treat a synthetic dataset as if it were truth.

Frequently asked questions

Is synthetic data exempt from GDPR?

Only if it allows no one to be re-identified, alone or combined with other available information. That has to be demonstrated with a re-identification risk measure, not asserted. Training the generator, meanwhile, is processing personal data in full.

Can I train a production model on synthetic data alone?

Rarely a good idea. It works as a complement — to balance rare classes or to get started without real data access — but evaluation must always run against real data. A model validated only on synthetic data measures its resemblance to the generator, not to reality.

What is the difference between synthetic and anonymised data?

Anonymised data consists of real records whose link to the person has been broken; synthetic data consists of new records produced by a model. The first preserves facts, the second preserves statistical structure. For an audit you need the first; for testing software, the second usually suffices.

How much real data do you need to generate useful synthetic data?

It depends on the method. A rule-based generator needs no source dataset at all, only business knowledge. Generative models do: with only a few thousand records the risk of memorising specific individuals rises noticeably, and fidelity drops.

If you are weighing synthetic data to unblock a project that has been stalled for months over privacy, it usually pays to look at the whole picture first: what data exists, who is accountable for it, and what you can already do with what you have. That is exactly what we look at in the audit, and if you would rather talk it through on a short call before deciding anything, let's talk.