Synthetic Data for ML: Genuinely Useful, and Quietly Dangerous

Synthetic data is having a moment, and for good reasons: training data without exposing real people, a way around privacy constraints, and a fix for thin data on rare events. Used well, it's real. Used as a drop-in replacement for messy production data, it fails in a way that's hard to catch until it's expensive. Here's the honest engineering picture.

Where it genuinely helps

• Privacy. Share a realistic-but-fake dataset with a vendor or across a boundary where real PII can't go.
• Class imbalance. Fraud is rare. Augmenting the minority class with plausible synthetic examples can help a model learn a boundary it otherwise sees too few times.
• Bootstrapping. Standing up a pipeline before you have volume, or testing systems without touching real records.

The trap nobody advertises

A generator can only produce patterns it learned from the real data. It cannot invent the edge cases you didn't already have.

That's the whole risk in one sentence. Synthetic data regularizes toward the center of the distribution it was trained on. The rare, weird, expensive tail — the exact region where insurance loses or makes money — is precisely what's under-represented in the source and therefore under-represented (or fabricated-smooth) in the synthetic copy.

real data:      ●●●●●●●●●●●●  ·   ·      ·          (fat, lumpy tail)
synthetic copy: ●●●●●●●●●●●●●●●                     (tail smoothed away)
                                    ^ the money lives here, and it's gone

Train a model on synthetic data and you can get something confident about the average and blind to the tail. In fraud, catastrophe, or large-loss modeling, that's not a rounding error — it's the business.

A checklist before you trust it

1. What problem are you actually solving? Privacy/sharing? Fine. Augmenting a rare class? Maybe, with validation. Replacing real data because it's messy? Stop — you're deleting signal.
2. Validate against held-out real data, never against more synthetic data. If your eval set is also synthetic, you've built a closed loop that confirms its own blind spots.
3. Check the tail explicitly. Compare tail statistics (extremes, rare-category frequencies) between synthetic and real. Smoothed tail = danger.
4. Watch for leakage the other way. A generator that memorized can reproduce real individuals — "synthetic" isn't automatically private. Test for it.

The rule of thumb

Synthetic data is a tool for privacy and augmentation, not a substitute for the messy real records that carry the rare, expensive patterns. Know which of those two problems you're solving, and validate on real data either way.

Full write-up with the insurance framing:

Synthetic Data for Insurance ML: When It Helps and When It Hurts →

From IntelliBooks' series on the data foundation under insurance AI.

Anyone using synthetic data for minority-class augmentation in prod? How are you validating the tail didn't get smoothed?