Synthetic data: when fake data is the ethical choice

The vendor wants a “realistic” demo tenant by Friday. Someone proposes restoring last month’s production backup into a shared sandbox and scrubbing emails with a regex. Another person suggests generating customers from a script so training screenshots never show real people. A third person shrugs: “Just use prod read-only; nobody will export it.”

That shrug is how privacy incidents and awkward audits begin. Synthetic data is not a magic anonymizer, and it is not always better than careful sampling. But there are many days when fake data is the ethical choice: teaching, CI tests, demos, vendor evaluations, and early model experiments where real rows create risk without creating proportional value.

This post is a decision guide for analysts, analytics engineers, and team leads. For quality habits that still apply to fake tables, see the Data quality series. For pipelines that should never silently point at prod, browse Data pipelines. Stewardship and access questions connect to Data stewardship. Learn paths sit at Analytics Made Simple Learn. When synthetic rows feed AI experiments, pair with Practical AI and the LLM overview at What are LLMs, ChatGPT, generative AI, and more.

What you will learn

What people mean by synthetic, masked, anonymized, and sample data (they are not synonyms)
When fake data is the ethical default vs when you still need real (governed) data
A decision sketch you can use in design reviews
How to generate useful synthetic tables without fooling yourself
A worked card: demo tenant for a metrics workshop
Mistakes that turn “synthetic” into re-identifiable or useless mush

Words that get blurred

Term	Plain meaning	Watch out
Sample / subset	Real rows, fewer of them	Still real people and secrets
Masked / redacted	Real rows with fields hidden or replaced	Join keys and rare values can re-identify
Anonymized	Legal/technical claim that individuals are not identifiable	Hard to achieve; often over-claimed
Synthetic	Rows generated by rules or models, not copied from a person	Can still leak patterns or be too fake to test bugs
Mock / fixture	Hand-built tiny data for tests	May miss edge cases

Ethics starts with honesty about which one you are using. Calling a masked prod dump “synthetic” is a documentation failure waiting to become a compliance failure.

When synthetic (or mock) data is the ethical choice

Prefer generated or carefully mocked data when:

Teaching and workshops where screenshots and laptops leave the room.
Public talks, blog posts, and vendor demos that will be recorded or shared.
CI and unit tests that run on shared runners you do not fully control.
Early UI and dashboard layout work where volume and shape matter more than true correlations.
Vendor bake-offs before a data processing agreement is in place.
Prompt and agent experiments that might send table samples to external model APIs.
Onboarding before a new hire has completed access training.

In these cases, the moral cost of using real people as props is high, and the analytical cost of using fake data is often low if you design the fakeness on purpose.

When to choose synthetic data versus governed real samples

When you still need real data (under governance)

Synthetic data is a poor substitute when the question depends on true rare events, true joint distributions, or true production mess:

Validating a fraud model on real attack patterns
Debugging a production-only data quality failure
Measuring bias across real demographic slices (with legal and ethical review)
Final UAT for a migration where only prod-scale quirks matter
Regulatory reporting that must reflect actual activity

Then the ethical path is not “use whatever is convenient.” It is minimum necessary access, purpose limitation, audit logs, retention limits, and sometimes formal review. Synthetic data can still help you build the scaffolding before you touch the real extract.

Ethics is purpose, proportionality, and honesty

Three questions that clear more heat than a slogan:

Purpose: What decision or artifact requires data at all?
Proportionality: What is the least risky data that still serves that purpose?
Honesty: Will anyone mistake this dataset for production truth?

If the purpose is “make the dashboard not look empty on stage,” synthetic is proportional. If the purpose is “estimate churn lift for a board number,” synthetic is not a shortcut around measurement. Label outputs so nobody pastes fake KPIs into a real forecast.

How to make synthetic data useful

Start from grain and constraints

Write the grain first: one row per customer day, order line, ticket, session. List hard constraints: unique keys, foreign keys, non-negative amounts, valid status enums, time ordering (ship date on or after order date). Generators that ignore constraints create test data that never fails the way prod fails, or fails in impossible ways that waste time.

Match distributions lightly, not perfectly

For demos, you often need plausible skew (a few big customers, many small ones), seasonality-ish wiggles, and a handful of nulls. You do not need a perfect clone of prod correlations. Perfect clones can re-identify and also create false confidence. Document what you intentionally did not preserve.

Include edge cases on purpose

Add: empty strings vs nulls, unicode names, refunds, same-day cancels, leap days if relevant, duplicate natural keys if prod has them, delayed events. Fixtures that are only happy-path teach brittle pipelines.

Keep generators in version control

A checked-in script with a seed beats a mysterious CSV on someone’s laptop. Seeds make CI reproducible. Review generators like any other code that defines “what normal looks like.”

Tiny sketch (illustrative):

import random
from datetime import date, timedelta

random.seed(42)
statuses = ["paid", "paid", "paid", "refunded", "pending"]

def fake_orders(n=1000, start=date(2025, 1, 1)):
    rows = []
    for i in range(1, n + 1):
        order_day = start + timedelta(days=random.randint(0, 180))
        amount = round(max(1.0, random.gauss(48.0, 20.0)), 2)
        rows.append({
            "order_id": i,
            "customer_id": random.randint(1, 200),
            "order_date": order_day.isoformat(),
            "amount_usd": amount,
            "status": random.choice(statuses),
        })
    return rows

That is enough for a workshop on group-bys and refund filters. It is not enough to claim “this matches our market.” Put that sentence in the README.

Worked example: demo tenant for a metrics class

Goal: teach weekly revenue, refund rate, and a simple cohort chart without exposing real customers. Audience: internal analysts plus a few vendor observers. Output: screenshots may leave the company.

Decision:

Use fully synthetic customers and orders with a fixed seed.
Brand as “Northwind-like AMS Demo Tenant,” not a real region name.
Include intentional quality bugs: 2% null customer_id on a staging-only table to practice checks.
Ban connecting workshop laptops to prod “just for the live demo.”

Card fields worth writing down:

Field	Example entry
Purpose	Workshop screenshots and SQL practice
Data class	Synthetic only; no prod subset
Generator	repo path + seed 42
Refresh	Rebuild nightly from script
Allowed tools	Classroom warehouse schema `demo_*`
Forbidden	Joining demo to real customer dims
Labeling	Watermark “SYNTHETIC” on dashboards
Owner	Analytics enablement
Review	Each quarter or before external demos

Field	Synthetic rule
IDs	Fake sequential or hashed, never copied from prod
Emails	example.com only
Amounts	Plausible ranges, not cloned totals
Label in prompt	Say synthetic explicitly so nobody pastes it as truth

The result card is what you show security when they ask “what is in that demo environment?” Paper trails beat vibes.

Risks of synthetic data (yes, it has some)

False confidence: models and dashboards look healthy on toy patterns.
Leakage via training: generative models trained on sensitive data can memorize; “synthetic” outputs may not be safe without care.
Re-identification via realism: if you inject too many real rare combinations, you recreated the hazard you tried to avoid.
Policy theater: calling masked prod synthetic to skip review.
Broken referential integrity: useless for testing joins that matter.

Standards and privacy engineering literature treat anonymization and synthetic data as techniques with residual risk, not moral free passes. Document assumptions. When in doubt, ask privacy counsel for high-stakes domains (health, finance, children, precise location).

Common mistakes

Restoring prod backups into shared sandboxes “temporarily.”
Regex-masking emails but leaving names, phones, and free text intact.
Using synthetic KPIs in real decision meetings without labels.
Generators without seeds, owners, or docs.
Happy-path-only fixtures that hide null and late-arriving event bugs.
Joining synthetic facts to real dimension tables “for convenience.”
Assuming vendor “synthetic” exports were never trained on your data.
Skipping the purpose test: generating data when no data was needed.

Practice

Pick one recurring use of prod-like data that is not a final business decision (onboarding, dashboard theming, external demo, CI). Write a one-page synthetic data card: purpose, grain, generator plan, edge cases, watermark plan, owner. Implement a minimal generator or mock set. Replace the risky path. Tell the team where the seed lives.

Second drill: audit one “anonymized” extract. List fields that could re-identify with a public join. Decide whether to truly synthesize, further reduce, or keep under stricter access. Honesty is the skill.

Hand-off language that prevents confusion

When you ship a synthetic dataset to another team, say three things out loud: what purpose it serves, what it deliberately does not resemble about production, and who to ask before using it for a decision. A one-paragraph README in the schema beats tribal knowledge. Example: “This tenant is seed 42 synthetic orders for SQL workshops. Distributions are plausible, not calibrated to 2025 revenue. Do not use for board metrics or model validation.” That sentence has stopped more bad slides than a long policy wiki nobody opens.

If legal or security asks for a data map, include synthetic environments as first-class entries with owners and refresh jobs. Invisible demo databases are how “we only use fake data” becomes “wait, who restored that backup.” Treat demo warehouses with the same inventory discipline you use for production, even when the rows are imaginary people.

Quick recap

Synthetic, masked, sampled, and anonymized are different claims.
Fake data is often the ethical default for teaching, CI, demos, and early AI experiments.
Real data still belongs in governed analysis where truth and rarity matter.
Purpose, proportionality, and honesty beat slogans.
Useful synthetic data respects grain, constraints, edge cases, and versioned generators.
Label outputs, own the card, and never join demo facts to real people “just this once.”

Sources

NIST, Privacy Framework resources: https://www.nist.gov/privacy-framework
NIST AI RMF (data and privacy risk context for AI systems): https://www.nist.gov/itl/ai-risk-management-framework
UK Information Commissioner’s Office (ICO), anonymisation and synthetic data guidance hub: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/
European Data Protection Supervisor / public materials on anonymisation concepts (see current EDPS resources): https://www.edps.europa.eu/data-protection/data-protection/reference-library/anonymisation-pseudonymisation_en
Synthetic Data Vault (open-source ecosystem docs for generators; engineering reference, not a legal shield): https://docs.sdv.dev/sdv
Analytics Made Simple, Data quality series: https://analyticsmadesimple.com/series/data-quality/
Analytics Made Simple, Data stewardship series: https://analyticsmadesimple.com/series/data-stewardship/