A European hospital research consortium recently faced a dilemma. They had detailed orthopaedic patient records, covering surgical procedures, implant types, BMI values, comorbidity scores, and revision outcomes, that could accelerate joint replacement research across institutions. But privacy regulations prevented them from sharing this data with external partners.

Their first instinct was to anonymise: strip patient names, generalise ages into brackets, mask postcodes, and suppress hospital identifiers. But the approach failed on two fronts. Their data protection officer rejected the pseudo-anonymised dataset for external sharing because the high number of quasi-identifiers in orthopaedic records made re-identification risk unacceptably high. And even internally, the research team could see that the anonymisation had gutted the data. The relationship between a BMI of 32.4, age 67, and a specific surgical technique was replaced by coarse groupings like “BMI 30-35” and “age 60-70.” The fine-grained correlations that their predictive models for revision surgery depended on were flattened beyond recognition.

When they turned to synthetic data generation instead, both problems were resolved simultaneously. The synthetic dataset preserved individual-level detail, including specific procedure types, exact BMI values, and comorbidity scores, while achieving re-identification risk scores well below regulatory thresholds. The same data protection officer who had rejected the pseudo-anonymised version approved the synthetic dataset for external sharing after reviewing the quantitative privacy evaluation.

Anonymisation modifies real data to hide identities. Synthetic data generates entirely new data that was never tied to a real person. Both aim to protect privacy, but they differ fundamentally in what they sacrifice along the way. 

In this article:

• What is Anonymisation?
• How Synthetic Data Generation Structurally Differs from Anonymisation
• What Anonymisation Cannot Do: The Quality Problem
• The Regulatory Divide: Why the Difference Matters Under GDPR
• Privacy: How Do Synthetic Data and Anonymisation Actually Compare?
• Head-to-Head: What Each Method Can and Cannot Do
• Case Study: Enabling Cross-Institutional Medical Research Without Compromising Privacy
• When Should You Use Which Approach?
• Ready to See the Difference for Your Data?

What is Anonymisation (and Pseudo-Anonymisation)?

Anonymisation refers to a set of techniques applied to real datasets to reduce the likelihood that individuals can be identified. In practice, most organisations apply what regulators more accurately call pseudo-anonymisation: the removal or transformation of personally identifiable information (PII) such as names, addresses, and national ID numbers. Common techniques include data masking, generalisation (for example, converting exact ages into age brackets), k-anonymity grouping, and suppression of rare values.

The critical distinction here is that pseudo-anonymised data is still derived from and based on real individuals. Every row in the dataset still corresponds to someone. The unmodified fields, however innocuous they may seem in isolation, remain the actual attributes of that person. The European Data Protection Board (formerly the Article 29 Working Party) identified three fundamental risks that any anonymisation technique must protect against: singling out (isolating a specific individual in the dataset), linkability (connecting records across datasets to the same person), and inference (deducing sensitive attributes from other known values). Most pseudo-anonymisation techniques offer incomplete protection against all three.

How Synthetic Data Generation Structurally Differs from Anonymisation

The difference between anonymisation and synthetic data is not just technical; it is structural. Anonymisation transforms existing records. Every output row traces back to a real person. Synthetic data generation, as bluegen.live implements it, creates entirely new records by learning the statistical distribution of the source data and generating individuals that never existed.

bluegen.live’s generative model is trained on complete individual records, learning all variables simultaneously. This means the model does not just learn that “age” has a certain distribution or that “income” follows a certain pattern in isolation. It learns how these variables relate to each other across the full dataset: how age correlates with income, how both interact with household size, how all three connect to energy consumption patterns, and so on. This context-aware learning is what allows the synthetic output to preserve higher-order relationships between variables, the exact relationships that pseudo-anonymisation destroys through generalisation and suppression.

After training, the model generates new individuals one by one from this learned distribution. Each synthetic record is internally consistent (a generated person’s age, income, and household composition make sense together) without being a copy or transformation of any real person. This is the structural break from anonymisation: there is no one-to-one mapping between a synthetic row and a real individual that an attacker could exploit.

bluegen.live then evaluates every generated dataset across three dimensions. Resemblance measures how closely the synthetic distributions and correlations match the original. Utility tests whether downstream machine learning models trained on synthetic data perform comparably to those trained on the real data. Privacy quantifies residual re-identification risk through simulated attack scenarios aligned with the European Data Protection Board framework, specifically testing the three re-identification risks defined by the EDPB.

What Anonymisation Cannot Do: The Quality Problem

The largest drawback of anonymisation, is its impact on data quality. Every anonymisation technique involves a trade-off: stronger privacy requires more aggressive data transformation, which in turn degrades analytical value.

The introduction already illustrated what this looks like in practice: the orthopaedic consortium’s anonymised dataset lost the variable-level detail that their predictive models depended on. That example is not uncommon.

This loss of granularity has measurable consequences for downstream tasks. Models trained on heavily anonymised data consistently underperform compared to those trained on data that retains individual-level detail. The problem compounds with the number of variables: each generalised or suppressed field removes a dimension of analytical signal, and the interaction effects between those dimensions are lost entirely.

Synthetic data does not suffer from this trade-off in the same way. Because the generative model learns from complete, ungeneralised records, it can reproduce granular values and their interdependencies. The synthetic dataset retains the analytical signal that anonymisation strips away.

The Regulatory Divide: Why the Difference Matters Under GDPR

The distinction between anonymisation and synthetic data carries direct regulatory consequences. Under the GDPR, the classification of your output data determines which legal obligations apply, and the two approaches land in fundamentally different places.

Pseudo-anonymised data remains personal data under the GDPR. This is explicit in the regulation. Because each record still traces back to a real individual, even if direct identifiers have been removed, the full weight of data protection law continues to apply. You still need a legal basis for processing, data subject rights still apply, and cross-border data transfers remain subject to safeguard requirements. In practice, this means that a pseudo-anonymised dataset shared with an external research partner still triggers the same compliance obligations as sharing the original data, just with a slightly reduced risk profile.

This is the point many organisations miss. They invest in anonymisation expecting it to remove regulatory friction, only to discover that their data protection officer or legal team still classifies the output as personal data. The Dutch Data Protection Authority (Autoriteit Persoonsgegevens), for example, is widely regarded as conservative in its interpretation of when transformed data ceases to qualify as personal data. For organisations operating in the Netherlands or subject to Dutch regulatory oversight, this conservative stance makes pseudo-anonymisation a particularly weak strategy for enabling data sharing.

Synthetic data, when properly generated and evaluated, can fall outside the scope of personal data entirely. Because synthetic records are linked to real individuals, they do not represent identifiable natural persons. If the generation process is robust and the privacy evaluation confirms that re-identification risks (singling out, linkability, inference) fall below accepted thresholds, the resulting dataset may no longer qualify as personal data. This fundamentally changes the compliance picture: data sharing agreements become simpler, cross-border restrictions may not apply in the same way, and data subject rights do not attach to records that represent no real person.

The regulatory status of synthetic data depends entirely on the quality of the generation and the rigour of the privacy evaluation. A poorly trained model that memorises training data could produce output that is still traceable to individuals, which would keep it within the personal data scope.

This is precisely why bluegen.live evaluates every generated dataset against the three re-identification risks defined by the European Data Protection Board. The privacy evaluation report serves as documented evidence that the synthetic data meets the criteria for falling outside the personal data definition.

Privacy: How Do Synthetic Data and Anonymisation Actually Compare?

The previous sections established that anonymised data retains a direct lineage to real individuals and that this lineage creates an expanding risk surface as auxiliary information grows. The practical question is: how do we actually measure whether either approach protects privacy well enough? 

Synthetic data breaks this one-to-one relationship. Because the output is generated from a learned distribution rather than transformed from individual records, there is no direct mapping between a synthetic row and a real person. bluegen.live’s privacy evaluation framework measures residual risk across the three canonical dimensions defined by the European Data Protection Board: the three EDPB re-identification risks. Well-generated synthetic data consistently scores below conservative thresholds on all three metrics, using quantitative risk scores from 0 to 100 where a threshold of 9 out of 100 is considered the acceptable upper bound for data release. This threshold is recommended by the European Medicines Agency and mirrored by the Personal Data Protection Commission of Singapore specifically for synthetic data.

Beyond these three canonical risks, robust privacy evaluation also includes exact duplicate detection and nearest-neighbour distance analysis to flag overfitting, where a model memorises individuals from the training data rather than learning the underlying distribution The case study below provides a concrete example of how these evaluations translate to real-world results.

It is important to note that synthetic data does not guarantee zero privacy risk. Any form of data sharing carries some residual risk. The key question is whether that residual risk is low enough to be acceptable. The privacy of synthetic data depends on the quality of the generation process: a poorly trained model could overfit to training data and effectively memorise individuals. This is why bluegen.live evaluates privacy through simulated attack scenarios for every generated dataset, rather than relying on the generation process alone.

Head-to-Head: What Each Method Can and Cannot Do

Case Study: Enabling Cross-Institutional Medical Research Without Compromising Privacy

An orthopaedic research registry containing data from multiple hospitals needed to share patient-level information with external academic researchers. The dataset included surgical details, patient demographics, comorbidity scores, implant types, and revision outcomes. As described in the introduction, pseudo-anonymisation was rejected by the data protection officer, and the registry turned to synthetic data generation. 

The registry adopted a synthetic data approach. The generative model was trained on the complete dataset, learning the multivariate relationships across all variables simultaneously. The resulting synthetic dataset was then evaluated against bluegen.live’s privacy framework aligned with European Data Protection Board guidelines. The evaluation measured singling-out risk at 3/100, linkability at 0/100, and inference at 2/100, all well below the 9/100 threshold introduced in the privacy comparison section above. Nearest-neighbour analysis confirmed that synthetic records were not systematically closer to any specific real patient than real patients were to each other, indicating no evidence of model overfitting or memorisation.

The researchers were able to conduct their analyses on the synthetic data with statistical outcomes closely matching those that would have been obtained from the real data. Critically, the granularity was preserved: individual procedure types, specific BMI values, and exact comorbidity scores were all present in the synthetic version, which would have been impossible under standard anonymisation approaches that group or suppress such detail.

When Should You Use Which Approach?

Anonymisation still has valid use cases. For simple reporting where individual-level detail is not required, for datasets with very few quasi-identifiers, or for internal use cases where the data never leaves the organisation, basic pseudo-anonymisation techniques can be sufficient and operationally simpler to implement.

Synthetic data becomes the stronger choice when you need to share data externally with third parties or research partners, when the dataset contains many variables with complex interdependencies, when regulatory scrutiny demands quantitative evidence of privacy protection rather than procedural compliance alone, or when your data protection officer requires documented proof that re-identification risks fall below accepted thresholds before approving a data release.

The decision should be driven by the use case, not by assumption. For many organisations, a combined approach, using anonymisation for low-sensitivity internal workflows and synthetic data for external sharing and high-stakes analytical work, provides the most practical path forward.

Ready to See the Difference for Your Data?

If you are evaluating whether your current anonymisation approach is costing you analytical value or creating hidden privacy gaps, a side-by-side comparison with synthetic data can provide a concrete answer. 

bluegen.live generates synthetic data that is evaluated across resemblance, utility, and privacy metrics, so you do not have to guess whether the output is fit for purpose. Request a demo to see how your data performs under both approaches.