How to Generate Privacy-Safe Synthetic Data with MOSTLY AI, Tonic.ai, and Differential Privacy

Your team ran an open-source generator over the customer table, scrolled a few rows, saw no familiar names, and shipped the “anonymous” dataset to an analytics vendor. The model that produced it had memorized its outliers. A week later, someone matched the rarest synthetic records back to real people. The data looked fake. It was never safe.

Before You Start

You’ll need:

• A synthetic data generator — the MOSTLY AI Synthetic Data SDK (open-source, runs locally) or Tonic.ai’s Fabricate for database seed data
• A working understanding of Differential Privacy and Re-Identification
• A source dataset you can profile, and a clear utility target — what the synthetic copy actually has to be good at

This guide teaches you: how to treat privacy as a specification — a budget you set, a contract the pipeline enforces, and a test the data has to pass — instead of a property you hope the generator gave you.

The “It Looks Fake, So It’s Safe” Trap

Synthetic data fools the eye by design. That is exactly why eyeballing it proves nothing about privacy. Open-source CTGAN has no differential privacy built in — it learns the real joint distribution, and for a rare record, the closest thing it can sample is that person, nearly verbatim. The output looks invented. The leak is real.

The trap is the assumption that synthetic is the same as anonymous. It isn’t. A generator with no privacy budget optimizes for fidelity, and fidelity pushed far enough is memorization with extra steps.

It produced clean-looking rows on Friday. On Monday, an attacker confirmed which real customers sat in the training set — because the spec never required a privacy budget, and nobody tested for the leak before export.

Step 1: Map the Data Before You Generate Anything

Before you touch a generator, decompose the pipeline. Privacy is not a switch you flip at the end — it is a component with a specific home in the system, and privacy needs a place to live in the pipeline or it lives nowhere.

Your pipeline has four parts:

• Source profiler — identifies which columns are identifying, which are sensitive, and which carry the utility you genuinely need
• Generator — the model that learns the joint distribution and samples new rows ( Synthetic Data Generation)
• Privacy mechanism — the differential privacy layer that bounds how much any single real record can influence the output
• Validator — the re-identification tests that decide whether the dataset ships or goes back

Each part has a boundary. The profiler hands the generator a schema and a list of sensitive fields. The privacy mechanism wraps the generator’s training, not its output. The validator sees only synthetic rows and a privacy report. Get those boundaries wrong and privacy quietly falls through the gap between two components.

The Architect’s Rule: If you can’t point to where privacy is enforced in the pipeline, it isn’t enforced anywhere.

Step 2: Set the Privacy Budget and the Utility Floor

This is the contract — what the generator must know before it produces a single row. The two numbers that matter pull against each other: the privacy budget and the utility floor. Set the floor first, then spend the smallest epsilon that clears it.

Context checklist:

• Generator chosen and its differential privacy support confirmed — MOSTLY AI’s SDK ships a DP option; open-source CTGAN does not
• Epsilon (ε) budget set — smaller epsilon means more privacy and less utility; for synthetic data it usually sits between 1 and 10, per an open-source DP tools evaluation (MDPI)
• Utility floor defined — the columns and correlations the synthetic copy must preserve to be worth generating
• Sensitive attributes flagged — the fields a re-identification attack would target
• Re-identification test chosen up front, not bolted on after

On tooling: MOSTLY AI’s open-source Synthetic Data SDK (v6.1.1, Apache-2.0, as of mid-2026) installs with pip and runs locally, and it ships a differential privacy option — confirmed in MOSTLY AI’s GitHub repository. The free path is the SDK itself; the hosted platform runs on a paid credit model above a limited free tier. Tonic.ai aims at a different job — Fabricate seeds databases with synthetic test data, starting free and running $29/month for the Plus tier (Tonic.ai’s pricing page). Open-source CTGAN, part of the Synthetic Data Vault, ships no differential privacy at all; DP there is a paid SDV Enterprise add-on (SDV Docs).

The Spec Test: If your context doesn’t name an epsilon, the generator optimizes for fidelity alone — and fidelity, pushed far enough, is memorization with extra steps.

Security & compatibility notes:

• SmartNoise-Core is deprecated: migrate to the OpenDP library for differential privacy tooling (OpenDP’s GitHub repository). OpenDP and Opacus are the current open-source go-to libraries for tabular DP and deep-learning DP-SGD.
• Open-source CTGAN has no built-in differential privacy: do not treat vanilla CTGAN output as privacy-safe. For DP, use MOSTLY AI’s SDK option or wrap training with OpenDP or Opacus; the SDV DP bundle is Enterprise-only (SDV Docs).

Step 3: Generate in Dependency Order

Order is not a style preference here. Each step depends on the one before it, and the privacy mechanism has a hard constraint: differential privacy has to constrain training, not post-process finished rows.

Build order:

1. Profile the source first — because every later choice (epsilon, generator, utility floor) depends on knowing what is identifying and what is correlated
2. Fit the generator with the privacy mechanism attached — because you cannot add DP after sampling; the budget has to bound what the model learns
3. Sample the synthetic set — because only now do you have rows to test
4. Validate before anyone downstream touches the data — because a dataset in a vendor’s hands cannot be recalled

For each component, your context must specify:

• What it receives — the real schema and the flagged sensitive columns
• What it returns — synthetic rows at the same schema, plus a privacy report
• What it must NOT do — pass through any raw record, or memorize a single individual
• How to handle failure — what happens when utility drops below the floor or a test fails

Step 4: Prove the Data Can’t Be Traced Back

You do not ship on a hunch. You ship when the data clears three gates, in order of how much they prove. The screen is cheap and noisy; a membership inference attack is the real test.

Validation checklist:

• Distance-to-Closest-Record screen — failure looks like: an rDCR below 1, which signals overfitting and a real record sitting too close to a synthetic one (arXiv Privacy Metrics paper)
• Membership Inference Attack — failure looks like: an attacker can tell, better than chance, whether a specific real person was in the training data
• GDPR three-test — failure looks like: a record that can still be singled out, linked across datasets, or used to infer a real attribute

Treat DCR as a smoke alarm, not a certificate. Peer-reviewed work shows the metric can pass while the data still leaks (“DCR Delusion”, ESORICS 2025), which is why the membership inference attack is the gold-standard empirical test. Then run the regulatory gate: the EDPB’s singling-out, linkability, and inference tests (EDPB Guidelines 01/2025). Under GDPR, a synthetic dataset counts as anonymous only when re-identification risk is negligible — and a dataset that fails these tests is still personal data, no matter how it was generated.

Common Pitfalls

Pro Tip

Synthetic data does not reset the terms of the original collection. If the real records were gathered without a basis to use them this way, generating a statistical copy does not launder that gap — the practice even has a name, Consent Laundering. So build the privacy budget and the attack test into the spec from the first line. That turns Synthetic Data Ethics into an engineering checklist instead of a closing-day debate, and the privacy report ships attached to the dataset, every time.

Frequently Asked Questions

Q: How to generate synthetic data with MOSTLY AI or Tonic.ai step by step? A: Profile your source, pick the engine — MOSTLY AI’s SDK runs locally with a differential privacy option, Tonic Fabricate seeds databases — set an epsilon budget, fit the generator, then sample. Validate before export. Order matters: DP has to constrain training, never just the finished rows.

Q: How to use synthetic data to train machine learning models without exposing personal data? A: Train on a differentially private synthetic copy, never the raw table, with an epsilon budget tight enough to pass a membership inference attack. Check utility against Benchmark Datasets first, so privacy doesn’t quietly tank your model’s accuracy on the task that matters.

Q: How to measure re-identification risk in a synthetic dataset? A: Start with a Distance-to-Closest-Record screen — an rDCR below 1 flags overfitting. Then run the real test, a membership inference attack. Finish with the GDPR singling-out, linkability, and inference checks. DCR can pass while data still leaks, so never stop at the screen.

Your Spec Artifact

By the end of this guide, you should have:

• A data-flow map that names where privacy is enforced: profiler → generator → DP mechanism → validator
• A privacy contract: chosen generator, epsilon budget, utility floor, and flagged sensitive columns
• A validation gate: a DCR screen, a membership inference attack, and the GDPR three-test, each with an explicit pass/fail line

Your Implementation Prompt

Drop this into your AI coding tool (Claude Code, Cursor, Codex) to scaffold the pipeline from Steps 1–4. Fill every bracket with your own values — each one maps to a checklist item from Step 2. The prompt encodes the build order so the assistant cannot attach differential privacy in the wrong place.

You are helping me build a privacy-safe synthetic data pipeline.
Never pass a raw record through to the output. Build in this order:

1. Source profiler — read the schema of [source dataset/table]. Flag
   identifying columns [list], sensitive columns [list], and the columns
   and correlations I must preserve: [utility floor].

2. Generator + privacy mechanism — use [MOSTLY AI SDK | CTGAN wrapped
   with OpenDP/Opacus] with differential privacy enabled. Set
   epsilon = [your ε, typically 1–10]. DP must constrain training,
   not post-process the sampled rows.

3. Sampler — generate [N] synthetic rows at the same schema and emit
   a privacy report alongside them.

4. Validator — compute Distance-to-Closest-Record (fail if rDCR < 1),
   run a membership inference attack (fail if attacker accuracy beats
   chance), and check GDPR singling-out, linkability, and inference.

Stop and warn me if utility drops below [utility floor] or any
validation gate fails. Return the privacy report, not just the data.

Ship It

You now treat privacy as something you specify, not something you hope the generator handed you — a budget you set, a contract the pipeline enforces, a test the data passes before it leaves the building. Decompose any new dataset that way, and “is this actually anonymous?” stops being a guess and becomes a line you can check off.