End-to-end development of privacy-safe synthetic data

Synthetic Data: Where Anonymization Breaks

The classic failure looks like this: a team takes an export with personal data, runs it through masking and hashing, gets a formally anonymized dataset — and hands it off for training.

The resulting model shows acceptable metrics on the test set, but falls apart in production: rare segments disappear, correlations between features break down, and recommendations degenerate into averaged noise.

The cause is not the model, but the fact that data anonymization destroyed the statistical structure for which the dataset was collected in the first place.

The second failure is quieter and more costly.

Formal anonymization provides no privacy guarantees: with a sufficient number of quasi-identifiers, a record can be reconstructed from an external source, and a model trained on such data is capable of "leaking" fragments of the training set in its responses.

Personal data protection requirements are considered met on paper, but not in substance — and they surface at the very first audit or incident.

Synthetic data solves both problems at once: the dataset is generated in such a way as to preserve distributions, correlations, and rare classes, but to contain not a single real record.

This changes the very framing — data privacy becomes a property of the generator rather than a consequence of manual cleanup, and dataset quality is measured by how closely the model's behavior on synthetic data matches its behavior on the original data.

We break down how this is addressed: which checks separate workable synthetic data from a plausible imitation, where the boundary between privacy and utility lies, and how to structure the process so that the result is accepted by both analysts and the security team.

How synthetic data generation works and what it delivers

Synthetic data generation is built on three levels of control: the distribution profile, the relationships between features, and the acceptable level of proximity to the original records.

The profile defines the marginal distributions of each column, a copula or dependency graph reconstructs the joint relationships, and the noise and filtering mechanism discards records that are too similar to real ones.

It is at the intersection of these levels that the "privacy versus utility" conflict is resolved: the stronger the blurring, the higher the protection and the lower the accuracy of a model trained on synthetic data.

Preserving statistical relationships

Copulas and Bayesian networks maintain pairwise and conditional dependencies: correlations, category shares, rare feature combinations. We verify this directly — comparing correlation matrices, tests for distribution equality, and model behavior on a holdout sample.

If the synthetic data loses the relationship between income and region, the model will train on a fiction, and the metric on real data will degrade.

Assessing synthetic data quality

We measure quality along three axes: accuracy (matching of distributions and relationships), coverage (the share of rare classes that were preserved), and protection (resistance to reconstruction and re-identification attacks). The report for each axis includes numbers, not a qualitative assessment of "looks similar."

Generation modes

SDV is a library that makes it convenient to assemble such a pipeline: it provides ready-made models for tabular data and comparison metrics, and we build our own privacy checks and quality report on top of it.

Stages of privacy-safe synthetic data implementation

Implementing synthetic data starts not with a generator, but with an audit: until the profile of the real dataset is described — field types, relationships between tables, distributions, rare categories — the synthetic data will be either useless or unsafe.

That is why the first step is always engineering: we analyze the source, record which fields identify a person and which carry analytical value, and agree on target quality and privacy metrics before launch.

1. Data and privacy requirements audit. We profile tables, build a map of relationships and quasi-identifiers, and determine the acceptable level of re-identification risk. The output is a data model and formalized acceptance criteria.
2. Generation model selection. We choose the approach for the task: statistical distribution copiers for tabular data, diffusion or autoregressive models for complex dependencies, and separate logic for text and time series.
3. Generator configuration. We train the model on the prepared corpus, configure privacy parameters (noise, constraints on memorizing rare records), and ensure the generator does not reproduce real rows verbatim.
4. Synthetic data validation. We compare distributions, correlations, and aggregates against the original; we test resilience to re-identification and attribution attacks. The dataset is accepted only if both sets of metrics are met.
5. Solution handover. We deliver the generator, configurations, reproduction scripts, and a quality report so the client's team can retrain the model on new data slices without us.

The key point is that synthetic data validation runs along two axes simultaneously: utility (whether the patterns that models and reports are built on have been preserved) and privacy (whether real records leak).

Weaken one — and you get either useless noise or repackaged personal data. That is why acceptance is recorded in a report with numbers, not in words.

How do synthetic data differ from anonymized data?

Anonymization works with the original record: direct identifiers are removed or masked from it — name, document number, contact, address.

Data masking can be irreversible (the value is deleted) or reversible (the value is replaced with a token that can be matched back using a key).

The structure of the row remains the same: the same set of fields, the same values in unchanged columns, the same relationships between tables. That is precisely why an anonymized dataset remains derived from real people — it describes them, just without a label.

Synthetic data are structured differently: these are new records that did not exist in the source. A model is trained on the original dataset, learns the joint distributions of features and the correlations between fields, and then generates rows anew.

Preserving distributions is a key requirement: the proportions of categories, the ranges of numeric fields, the frequencies of rare values, and the relationships between columns must match the original within a specified accuracy.

If in the real data delinquency correlates with region and contract type, the synthetic data must reproduce that dependency, otherwise a model cannot be trained on it or hypotheses tested with it.

This gives rise to a different nature of re-identification risk. In an anonymized dataset it remains: a combination of quasi-identifiers — age, postal code, job title, date — often singles out a person uniquely, and re-matching with an external source restores the identity.

In synthetic data there is no risk of "matching a row back to a person" by construction, but another one appears — overfitting of the generator and leakage of training examples verbatim.

That is why privacy here is measured rather than declared: the distance to the nearest real record is checked, resistance to membership inference and attribute inference attacks is tested, and the distributions of the synthetic data and the original are compared using statistical tests.

The practical conclusion for choosing an approach is simple. Anonymization is suitable when an exact copy of the structure is needed and residual risk from quasi-identifiers is acceptable.

Synthetic data are needed when the data must be transferred outside, moved into a test environment, or used to expand rare scenarios — and when the absence of a link to a specific person matters more than verbatim matching of rows.

In practice, these approaches are often combined: first masking of direct identifiers, then generation with control of distribution preservation and measurement of privacy at the output.

Case: synthetic data for model training without leakage

The client — a medical service — hit a dead end: the training dataset contained patients' personal data, and regulatory restrictions prohibited moving it outside the perimeter.

The legal department blocked the transfer of real records into the training environment, and the model project stalled. The team could not make progress on either quality or deadlines — formally there was plenty of data, but it could not be used.

We built a synthetic data generator: we trained a model in a closed environment that reproduces the statistical dependencies and distributions of the real dataset but contains none of the original records.

The key is to preserve the correlations between features, otherwise the model learns from plausible but useless noise. We verified this with a separate pipeline: we compared distributions, rare feature combinations, and behavior on a held-out real dataset.

What changed in the metrics

Model quality remained within the margin of error relative to training on real data — this was confirmed on a closed test.

At the same time, personal records were completely removed from the training environment, which means the entire class of risks associated with their leakage or re-identification also disappeared.

Why this works

Synthetic data does not replace real data everywhere — it addresses a specific scenario: when access to real data is restricted but a model still needs to be trained.

We maintain two independent pipelines — generation and validation — so that the synthetic data is not "tuned" to the expected result. This approach relies on methods described in research on differential privacy — we apply them as a basis for leakage control, not as a formality.

For the client, this meant unblocking the project without legal risks: new versions of the dataset are prepared in hours rather than weeks of approvals.

Compatibility, migration, and rollback concerns

Synthetic data is rarely deployed "in a green field": almost always there is already an analytical warehouse, streaming exports, and models trained on historical data running nearby.

Therefore, the first question at a review is not "does synthetic data look like real data," but "what will happen to what is already running." We answer each point: compatibility of synthetic data with the current stack, data migration, rollback of changes, access and roles, documentation handover.

What if a rollback is required? Synthetic data is connected as a separate loop: production exports remain untouched, switching happens at the data source level. A rollback is returning the pointer to the previous source, without code changes and without restoring from backups.

What about access? We separate roles on the principle of least privilege: the generator sees only permitted fields, analysts — only the synthetic loop. We agree on the role scheme and access matrix before launch, so as not to open anything extra "temporarily."

The customer receives:

• generator configurations and field labeling rules;
• data flow diagram with connection and rollback points;
• access matrix and role descriptions;
• quality report for the synthetic dataset with convergence metrics;
• migration and switch-back regulations;
• operations and team handover documentation.

Describe your task and current stack — we will come back with an estimate and a work plan.

Timeline for synthetic data implementation by stages

The timeline depends not on the size of the generator, but on how long it takes to agree on profiles and verify data suitability. Below is a guideline by stages for a typical project: from source audit to handing the model over to production.

The stages partially overlap: schema design begins before the audit is completed, and preparation of privacy tests runs in parallel with generation.

Therefore, the sum of the table rows does not equal the calendar duration of the project: for a typical environment this is 6–10 weeks, for several sources with different structures — longer.

Acceleration comes not from hardware power, but from early fixation of suitability metrics: if the criteria are agreed upon before training, the "generated — rejected — redone" cycle does not repeat.

A separate reserve should be set aside for data access and coordination with legal teams — these are timelines external to the team, and they most often shift the plan.

Describe your sources and task — we will come back with an estimate by stages and a work plan.