Synthetic Data
Synthetic Data
What is synthetic data?
- Artificially generated data instead of real data
- Sidestepping scarce and sensitive data
- Needs quality validation
Once you start using synthetic data, the data-access bottleneck moves elsewhere. Instead of spending months on legal review and release approval to get the original data, you train a model on the original just once inside a secure zone, then send the artificial records it generates outside for development, testing, and vendor collaboration. The data owner's job shifts from finding data to building and validating it.
There are three main ways to create it. For areas governed by clear physical laws, such as equipment faults or autonomous driving, simulators generate the scenarios. For tabular data such as customer and transaction records, teams use statistical models or GAN- and diffusion-based generative models. For support logs and contracts, LLMs write the text. The line between this and pseudonymization is clear: pseudonymization keeps real people's records and only masks identifiers, whereas synthesis creates new records that match no real individual.
Quality is judged on three axes: whether the distribution resembles the original (fidelity), whether a model trained on synthetic data performs well when evaluated on real data (utility), and whether any original row has been copied verbatim (privacy). If any one is missing, you will run into trouble: match only the distribution and real individuals can surface; tighten only privacy and the data goes flat and is useless for training. That is why, in practice, synthetic data is rarely used alone, and mixed training with 10–30% real data is the default.
The most common misconception is 'It's synthetic, so it isn't personal data.' If a generative model memorizes a rare outlier and reproduces it, a real individual is exposed as is, and the whole regulatory argument collapses at once. It is also easy to miss that synthesis does not create information that was not there. Synthesizing 10,000 records from data with only 12 fraud cases yields nothing but variations on those 12, so the model performs well in internal validation but is easily fooled by genuinely new fraud methods. Repeatedly feeding synthetic output back into training also narrows the distribution, causing model collapse, so always keep a separate evaluation set built from real data.
John KimInstructor John Kim, author of "B2B Marketing Design" and CEO of Nanum Consulting
Sungil KimGlobal pitching expert from KAIST and Samsung Electronics who coached the winning teams at the UN Tourism and Select USA IR pitch competitionsIt grew out of the need to handle data scarcity and privacy regulation, and its use has surged with the rise of generative AI.
Consider a hypothetical case. Company A, a mid-sized card issuer with 900 employees, had run its fraud detection system (FDS) model for three years. Only 0.02% of all transactions were confirmed as fraud, and new fraud methods appeared in just over 20 cases per quarter, so the model rarely picked up new patterns. On top of that, raw transaction data could not leave the company, so collaboration with an outside development firm had been stalled for four months.
- Kim, head of the data platform team, pulled the past year's data-release review records: 8 of 12 requests were rejected, and the average wait alone was 47 days. In a meeting someone said, 'The project will be over before the data arrives.'
- Inside the secure network, they set up an isolated server and trained a generative model on 18 million transactions from the past two years. They then amplified only the fraud-labeled segment 30x to produce 600,000 synthetic transactions.
- Mr. Park, a deputy manager on the information security team, compared every synthetic record against its nearest original and filtered out 1,204 records virtually identical to the originals. He set the condition up front: 'if even one record comes out unchanged, nothing leaves.'
- Mr. Lee, the senior manager in charge of modeling, evaluated a model trained only on synthetic data against real August transactions. True positives rose, but false positives increased 2.3x, so he switched to mixed training with 20% real data.
- Six months later, detection of new fraud methods rose from 61% to 78%, customer verification calls triggered by false positives fell from 340 to 190 a day, and the stalled outside collaboration resumed in three weeks once synthetic data could be shared.