Use synthetic data first, masked data second, and real data only after the prototype has been reviewed and approved for it. Synthetic data keeps its shape and edge cases without containing anyone's actual information, so a leak from a prototype costs you nothing.
Why data choice matters more with AI tools
When you work with an AI coding assistant, data travels. Sample rows get pasted into prompts, stack traces carry values into chat history, and logs end up in screenshots. Even if your tools are configured well, the number of places a real record can land is larger than during ordinary development.
Starting from synthetic data removes most of that risk before any control is needed.
Three levels of test data
| Level | What it is | Use it when |
|---|---|---|
| Synthetic | Generated records with no link to real people | Default for every prototype |
| Masked | Real structure with identifying values replaced | You need realistic distributions or odd formats |
| Real | Actual records | Only after review, access controls and an agreed purpose |
How to build useful synthetic data
Match the shape, not the people. Copy field names, types, lengths and nullability from the real schema. Generate values that look plausible, such as invented names and addresses.
Include the awkward cases. Add empty strings, very long names, unusual characters, duplicate emails, dates at boundaries and records with missing fields. Real data is messy, and prototypes that only see tidy rows fail at launch.
Keep volume realistic. A prototype tested with ten rows will behave differently with ten million. Generate enough to exercise paging and search.
Make fakes obviously fake. Use clearly invented domains and numbers so nobody mistakes a test record for a customer, and so a stray email never reaches a real inbox.
If you must mask real data
Masking is harder than it looks. Replace direct identifiers such as names and emails, but also think about fields that identify indirectly, like unusual job titles or rare postcodes. Mask before the data leaves its source, not after it has landed in the prototype. Keep the masking script in version control so it is repeatable.
When a prototype may touch real data
Treat it as a promotion event. The code has been reviewed, secrets are out of the repo, access is limited, logging does not capture personal fields, and someone has approved the purpose. If you cannot tick those, stay synthetic.
Prompt hygiene
- Paste schemas and invented examples into prompts, not production rows.
- Strip values from error messages before sharing them.
- Check that your assistant's data-sharing settings match your policy.
Your own legal or privacy team decides what counts as personal data in your situation; this article is not legal advice.
Quick check
Is synthetic data always safe?
Generated data that has no link to real people carries almost no privacy risk. Data produced by copying real rows with small edits can still reveal individuals, so generate from rules, not from samples.
Do I need synthetic data if the prototype stays on my laptop?
Yes. Laptops are lost, backed up to the cloud and shared in screen calls, and the assistant may send context to a hosted service.
Sources
Last reviewed: 19 October 2026.
