Synthetic Data Is Not Anonymized: Designing Privacy and Utility

Stadler et al. evaluated multiple generation models, assessing attacks such as attribute inference and utility within the same framework, and reported that synthetic data does not consistently show a better privacy-utility trade-off than traditional anonymization.[1] Even if the rows appear fictional, statistical ties with the training data may remain.

At the start of review, determine what to protect and who the attacker is. Threats vary, such as external third parties guessing affiliations, inferring secret attributes from known ones, or insiders re-identifying rare records; thus, evaluations change accordingly. The explanation that it is "not the original data" does not constitute a safety claim unless the attacker's knowledge, number of queries, and auxiliary information are specified.

Empirical safety judgments must record not only the attacker's success rate but also the auxiliary information provided, query permissions, and results for rare groups, along with the version history. Passing known attacks only bounds the result to having not been detected under these specific conditions.[1] The publishing authority must invalidate previous judgments and re-review the use case when access stronger than assumed becomes necessary.

Carlini et al. proposed exposure to measure how uniquely a secret column inserted into the training data is memorized in the model, and showed conditions under which unique sequences can be extracted from the generation model.[2] Even if average similarity is low, if rare strings or records of minorities are strongly memorized, the risk may be overlooked in overall statistics.

Before publication, separately inspect duplicate records, rare categories, long free-text descriptions, and columns resembling identifiers. Perform membership inference, attribute inference, and canary-based memorization tests according to the assumed access. However, failing an attack is not a proof of safety, but a limited result indicating that leakage was not detected under these specific attack conditions.

McKenna et al. presented a three-stage MST mechanism that selects low-dimensional marginal distributions, adds differential privacy noise for measurement, and generates consistent synthetic data.[3] Differential privacy is a formal framework that limits the impact of an individual's presence or absence on the output, allowing guarantees to be stated separately from the appearance of the generated product.

On the other hand, tightening the privacy budget makes it easier to lose rare groups and high-dimensional interactions. Even if averages and simple aggregations are preserved, the data may be useless for fraud detection, rare diseases, or causal analysis. Record the budget, iterative publications, and selected queries, and evaluate performance differences and group-specific errors for each assumed task.

The passing condition for utility is not the closeness of the overall distribution, but whether the conclusions obtained from the original data are preserved for each planned analysis. Methods suitable for low-dimensional aggregation do not necessarily transfer to tasks using rare groups or complex interactions.[3] Use cases where group-specific errors or decision inversions exceed the tolerance line should be excluded from the provision targets even if they pass the privacy side, and should not be substituted with evaluation results for other use cases.

Existing comparisons do not show consistent anonymization superiority of synthesis under the evaluated generators and attack conditions, and MST is also a method dependent on the selected low-dimensional marginal distribution and budget.[1][3] Neither directly verifies safety and utility when actually combining multiple versions issued over time. The synthetic risk of iterative publication is also unevaluated.

The following are recommendations before publication. Instead of testing new versions in isolation, provide past versions given to the same recipient, versions for different uses created from the same population, and published aggregations to the attacker side simultaneously as a bundle. This posits a virtual path where differences invisible in isolated versions narrow candidate records through version comparison. Reproduce the acquisition history for each recipient.

Even if inference strengthens in joint testing, do not immediately treat it as confirmed personal leakage. Separate explanations such as matrix correspondence, rare categories, generation random number differences, and published aggregations, and carefully verify if they can be reproduced with the assumed auxiliary information. Return the reproduction conditions to the version ledger; if they include irrevocable old versions, narrow the scope of new publication.

If utility test items are selected after viewing the generation results, only preserved analyses can be reported as uses. The operational proposal is to clearly fix in the use contract before generation the intended judgments, necessary columns, group-specific confirmations, unacceptable conclusion inversions, and prohibited secondary uses. Do not add successes outside the contract as grounds for passing. Fix the evaluation procedure and adjudicator in advance.

As a hypothetical example, if the overall aggregation is preserved but the selection of targets in a rare category is inverted, divide the use case: this version can be used for overall reporting but not for individual selection. Conversely, since accuracy might be preserved because it is too close to individual records, do not use high utility as a substitute for privacy safety. Create separate judgment sheets for each permitted use.

In regeneration, reproduce the same use contract and show improvements or deteriorations compared to the previous version by analysis unit. If you want to add a use, create a new contract and joint attack test, and do not horizontally transfer existing passes. If use in a prohibited area is discovered after publication, send it to distribution suspension and re-review as a contract violation, not a precision issue, and record recipient notification.

• RELEASE BUNDLE: A set consisting of past versions, different-use versions, and published aggregations that recipients can combine
• LINKAGE HYPOTHESIS: Specify candidates narrowed by version differences and auxiliary information given to the attacker
• USE CONTRACT: Freeze permitted judgments, necessary columns, group-specific conditions, inversion prohibitions, and secondary use prohibitions
• RECALL TRIGGER: Record conditions for narrowing publication when joint reproduction, contract violation, or irrevocable old versions occur

The synthetic data approval table lists the threat model, type of guarantee, scope of training data, duplicate handling, access to the generator, privacy budget, attack tests, use-case-specific performance, and prohibited uses. Do not collapse privacy and utility metrics into a single composite score; set minimum conditions for both. If either is lacking, narrow the use or stop publication.

Publication is not a fixed object. Risks change with additional data, generator updates, combinations of multiple releases, and new attacks. Keep a ledger for each version, inform users of the guarantee scope and known weaknesses, and have a recall path. The value of synthetic data is not being a "safe-looking substitute," but providing utility sufficient for the purpose within explainable risks.

Recallability is also a publication condition. Link the generator version, scope of original data, distribution destination, and possibility of redistribution, and pre-exercise whether distribution can be stopped, users notified, and regeneration performed if significant reproduction is found via new memorization attacks or canary tests.[2] Distribution forms that cannot be recalled are not treated as the same risk level, but limited to narrower uses or management environments.

• Threat: Specify the protected individuals, secrets, and the attacker's knowledge and access
• Guarantee: Record empirical attack resistance and formal guarantees separately
• Utility: Compare not only aggregations but also downstream tasks and group-specific errors
• Operation: Aggregate iterative publications, maintain version management, prohibited uses, and recall paths
• Privacy Officer: Approve changes to the threat model and attack conditions
• Business Owner: Judge conclusion consistency by use case and group-specific errors
• Distribution Administrator: Track distribution destinations and recall completion for each version