Generated records that look like real ones have become a normal part of software testing. The share of test data made this way rose from 14% to 25% in a year, because AI now produces in seconds what used to take a data scientist and a subject expert weeks. For a company that cannot put real patient or customer records in front of every developer, that is a real gain. The question for anyone who relies on it is what the generated data leaves out.
A generator draws what is typical
A generator learns what real records look like and then draws new ones. Drawing favors the common. If a certain fraud pattern shows up in 1 of every 1,000 real transactions, it will show up less often in a generated set, and less again in a copy made from that set. Rare things are rare because they are unlikely, and an unlikely thing is what a generator is least likely to produce.
There is a second problem, which is that the loss is hard to see. In experiments where models learn from each other's output, the rare cases go first and overall scores can still look better. Ordinary cases dominate any average, so the average hides what was dropped. A team that checks only its overall pass rate will not notice.
The generator also has a more basic limit. Someone has to decide what to generate, so it can multiply the scenarios a company already understands. It cannot reliably produce the edge cases nobody thought of.
What it looks like in a hospital group
Imagine the finance team of a hospital group replacing its billing system. Instead of copying patient records, which would take weeks of approvals, they ask an AI tool for 100,000 realistic claims. It takes an afternoon, no patient data is exposed, and every test passes.
Then the system goes live. Say 1 claim in 500 involves a patient moved between hospitals in the middle of a stay, or covered by two insurers. At 20,000 claims a month, that is 40 claims the system cannot handle. If each takes a person 20 minutes to fix by hand, that is about 13 hours of work every month, plus delayed payments. Nothing in the tests warned them, because the generated claims had almost none of these cases.
Keep a small real exam
Generated data is a good tool for the bulk of the work. It suits checking that a screen loads, testing a single feature with a handful of fake customers, and putting a system under heavy load. It becomes risky when a rare case costs real money.
For those systems, a team can keep a small collection of real, masked cases that were never produced by the generator. Every time something odd breaks in production, a version of that case goes into the collection. The team then runs the collection against every new system and every new batch of generated data. Two habits protect it. The tool that makes the practice data never writes the exam. Every generated record is also labeled as generated, so a fake record cannot quietly end up in a live system and be treated as real.
Generated data multiplies what a company already understands. The surprises still come from the real world, so the company's record of what has actually gone wrong is worth more as generated data gets cheaper.