Anonymized isn't anonymous: why synthetic is the safer default

The most common alternative to synthetic data isn't other synthetic data — it's a copy of production with the names scrubbed out. Strip the customer names, hash the emails, maybe shift the dates, and call it "anonymized." It feels safe. It usually isn't, and the reasons why are worth understanding before you hand a "clean" extract to a vendor, a training class, or an offshore team.

Re-identification is not a theoretical attack

The famous results are old enough to vote. Latanya Sweeney showed in 2000 that 87% of Americans are uniquely identified by just ZIP code, birth date, and sex — three fields nobody thinks of as identifiers. AOL released "anonymized" search logs in 2006; journalists identified user 4417749 by name within days. Netflix published scrubbed movie ratings for a prize competition; researchers matched them to public IMDb reviews. The pattern is always the same: the direct identifiers are gone, but the combination of innocuous fields is a fingerprint, and an attacker with any outside dataset to join against can reverse the scrubbing.

Business data is worse, not better. A B2B order history has customer sizes, locations, order cadences, and product mixes. A distributor's largest account in a five-digit ZIP is identifiable from volume alone — no name required. Scrub harder and you start destroying the correlations that made the data useful; the privacy–utility trade-off tightens until there's nothing left on either side.

Anonymization tries to keep a 1:1 mapping to real people while making it hard to follow. Synthetic data never has the mapping in the first place — there is nothing to re-identify.

The regulatory line agrees

Under GDPR, pseudonymized data — identifiers replaced but re-linkable — is still personal data, with everything that implies: lawful basis, processing agreements, breach duties, retention limits. Truly anonymous data escapes the regulation, but the bar is that re-identification must be impossible by "means reasonably likely to be used," and the case history above shows how hard that bar is to clear. Synthetic data generated without reference to real individuals sits cleanly outside the definition: there is no data subject. That's not a loophole; it's the difference between disguising information about people and never collecting it.

The caveat that actually matters

"Synthetic" is not automatically safe either, and it's worth being precise about why. A generative model trained on real records can memorize and replay its training data — researchers have extracted verbatim rare records from models trained on medical and text data. If your synthetic data is a model's imitation of a real customer table, privacy now depends on how well the model generalized, which is a probabilistic claim, not a guarantee.

That is why our dataset takes the other road entirely: it is rules-first, not trained. The distributor behind our data never existed. Its customers, vendors, and order flows are generated from configured business rules — segment mixes, seasonality curves, credit behaviors, fill-rate physics — with named statistical distributions, not from any real company's records. There is no training corpus to leak, no rare real customer to memorize, and every value is traceable to a rule in the methodology rather than to a person. Realism comes from the rules being right, which you can audit, instead of from resemblance to real people, which you can't.

What this buys you in practice

The consequences are operational, not philosophical. A dataset with no data subjects can be handed to a contractor without a data-processing agreement, loaded into a cloud sandbox without a privacy review, shipped to a training class, posted in a demo environment, or given to an offshore QA team — the entire approval apparatus that exists to manage personal data simply has nothing to attach to. Teams we talk to consistently underestimate this until they've watched a six-week security review evaporate because the answer to "whose data is this?" is "no one's."

The test to apply

Whatever data you're about to share, ask one question: does a row correspond to a real person or a real company? If yes — however scrambled — you own a re-identification risk and a regulatory posture, and history says both are heavier than they look. If no, and the data was built rather than derived, the risk isn't reduced. It's absent. That's the property everything else on this site is built on: realistic enough to work with, synthetic enough that there is nothing to protect.