Synthetic data — generating training examples rather than collecting them from real usage — is genuinely valuable where real data is scarce, sensitive, or expensive to label: rare edge cases that barely occur naturally, or scenarios where using real customer data for training raises privacy concerns the synthetic version sidesteps entirely. Used deliberately for these gaps, it's a real technique with real value.
The failure mode that catches teams out is generating synthetic data at scale as a substitute for real data collection, rather than as a supplement to it. A model trained heavily on data generated by another model learns the generating model's patterns, biases and blind spots as much as it learns the underlying task — and those patterns are frequently narrower and more artificial than what real usage actually produces, so the model performs well on synthetic evaluation and disappoints on real inputs.
The tell that this has happened is a model that performs excellently on your own held-out test set and poorly once deployed against genuine user input, particularly if that test set was itself partly synthetic or generated by the same process as the training data. A held-out evaluation set built entirely from real, independently collected examples is the only honest check against this — synthetic data evaluated against synthetic data measures whether the model learned the generator, not the task.
Where it works best is as an augmentation layered onto a genuine real-data foundation, deliberately targeting known gaps — generating more examples of a specific rare case that real data barely covers, rather than generating the bulk of the dataset. The proportion matters more than the technique itself: a small, targeted synthetic supplement on top of a solid real dataset is a reasonable and common practice; a dataset that's mostly synthetic because real data was inconvenient to collect is a different and considerably riskier decision that deserves to be made deliberately rather than by default.
