Part 3 of our series on Privacy-Enhancing Technologies.

Of everything covered in this series so far, synthetic data is the topic that generates the most genuine excitement. Fake patient files that behave like real ones. Fake transaction histories. Fake everything - statistically real enough to build on, legally fake enough to use freely. With enterprise large language models (LLMs) now accessible to most organizations, generating synthetic data at scale has moved from a research project to a routine engineering task.

Which is precisely why we need to address the part that rarely makes it into a vendor's pitch deck: synthetic does not automatically mean private.

Some of the most enthusiastic engineering teams we speak with have also become the most skeptical, and for reasons that are worth taking seriously before you build a compliance strategy on this technology.

What is Synthetic Data? The Core Promise

The appeal of synthetic data is best illustrated with a concrete example. Consider a hospital that builds a synthetic patient population derived from real records. The synthetic dataset preserves the same statistical relationships between age, diagnosis, treatment outcome, and length of stay - but no synthetic record maps back to an actual patient.

Once that dataset exists, it can be used indefinitely: for software testing, machine learning model training, external research partnerships, and product demonstrations, all without ever touching a real patient's file again.

The core value proposition is straightforward: build the effort once, reuse it indefinitely, and eliminate the usual data-handling compliance overhead.

The Problem Nobody's Pitch Deck Mentions

The critical limitation of synthetic data is one that is rarely disclosed upfront. Generative models do not always generate novel data- sometimes they memorize and reproduce actual training records nearly verbatim. This is not an edge case. Researchers have extracted real training data from a model marketed as "privacy-safe" in under 30 minutes. A widely cited 2022 Royal Society report identified the same phenomenon across multiple synthetic data systems.

Beyond direct memorization, two additional failure modes are worth understanding:

Structural Leakage. Even without a single direct identifier present, synthetic records can preserve enough statistical correlation and pattern that an adversary with access to external data can re-identify an individual by matching structure rather than values. The person's name is absent; their unique combination of attributes is not.
Membership Inference. An attacker does not need to recover your exact record. In many cases, simply confirming that someone matching a given profile was present in the original training dataset constitutes a privacy violation in its own right. The question "was anyone with this rare combination of conditions in the training set?" can be enough.

Underlying both of these risks is a fundamental tension: fidelity and privacy pull in opposite directions. Synthetic data that is too close to the original leaks. Synthetic data that is too far from the original loses the statistical utility that made it valuable in the first place. There is no configuration that delivers maximum realism and maximum privacy simultaneously.

This is likely why your engineering team is less enthusiastic about synthetic data than your business stakeholders. The concern is not that "synthetic data is bad." It is that "synthetic data marketed as inherently private is bad." Those are materially different claims, and the distinction matters for compliance purposes.

Is Synthetic Data Worth the Investment?

The answer is yes, but only with a critical caveat that transforms it from a marketing claim into a rigorous engineering practice.

Stage	What It Involves	Why It Cannot Be Skipped
Step 1: Generation	Create a synthetic dataset from real records using a generative model.	Produces statistically representative data that can be reused, analyzed, and shared more safely.
Step 2: Testing	Assess the synthetic dataset for memorization, structural leakage, and membership-inference vulnerabilities before any external use.	Without testing, synthetic data may still expose information from the original records, undermining its claimed privacy protections.

Where does synthetic data earn the investment?

Recurring reuse cases where the same dataset will be used for years - such as a hospital patient population used for ongoing model training - rather than a one-off internal report.

Where is it probably not worth it?

High-stakes accuracy contexts, such as diagnostic models or risk-scoring systems, where fidelity must be near-perfect. This is precisely where leakage risk is also at its highest.

One additional point worth noting: synthetic data generation does not eliminate the need for data cleaning. Garbage in still means garbage out. Synthetic generation does not skip that step - it simply moves it earlier in the pipeline.

Coming Up

Next in our series: Federated Learning.

It is a narrower use case, but it represents a fundamentally different architectural approach to privacy: training machine learning models without ever moving the underlying data at all.

---

This post is for general informational purposes and does not constitute legal advice. Whether a specific synthetic dataset satisfies a given anonymization or de-identification standard depends on how it was generated and tested. If you want a second opinion before relying on "synthetic" as a compliance answer, our attorneys specializing in data privacy are happy to review it with you.

---

P.S. The gap between what vendors promise and what technology actually delivers is one of the most important things a skilled professional can learn to navigate. Synthetic data is a useful case study in exactly that. As you evaluate new technologies for your organization, the ability to ask the right skeptical questions, and to distinguish a marketing claim from an engineering reality, is a skill that compounds in value over time. It is worth cultivating deliberately.