Synthetic data has moved from research labs into enterprise roadmaps on the strength of a simple promise: if real data is scarce, sensitive or slow to obtain, generate data that behaves like it. Banks want transaction records they can share with vendors without exposing customers. Hospitals want patient records for model development without consent bottlenecks. Manufacturers want images of defects that occur once in a hundred thousand parts.
The promise is partly true. Synthetic data for enterprise use can shorten development cycles, fill gaps in rare classes and let teams test systems without touching production records. But it can also lie, quietly. A synthetic dataset can look statistically faithful while losing exactly the rare cases a model most needs to learn, and it can feel anonymous while still leaking information about the people it was derived from.
This piece explains the main kinds of synthetic data, sets out what peer-reviewed research and analysts say about its limits, considers how India's Digital Personal Data Protection Act applies, and offers a fit test: four conditions under which synthetic data is safe to use in an enterprise AI programme.
Three kinds of synthetic data, and why the distinction matters
"Synthetic data" covers techniques with very different risk profiles. Treating them as one category is the first source of error.
Simulated or rule-based data is generated from a model of how the world works rather than from real records. A physics simulator renders images of a conveyor belt with defects placed at random; a test- data tool generates fake customer records that satisfy a database schema. No real person's data is involved, so privacy risk is low. The risk is realism: the simulator only knows what its designers put in.
Learned synthetic data is produced by a generative model trained on real data, for example a model that learns the joint distribution of a bank's transaction table and then samples new rows. This is what most vendors mean by synthetic data. It can capture correlations a rule-based approach would miss, but because it is learned from real records, it can also memorise and reproduce them.
Model-generated text and labels are outputs from large language models used as training or evaluation data: synthetic customer queries, generated question and answer pairs, or model-written labels. This is now the most common form in generative AI projects, and it carries a distinct risk: models trained on the outputs of other models can lose information over successive rounds.
The fit test later in this piece applies to all three, but the weight of each condition differs by kind.
Why the governance problem is growing
Analysts have begun to flag management of synthetic data as a governance issue rather than a technical curiosity. In its data and analytics predictions published on 17 June 2025, Gartner predicted that by 2027, 60% of data and analytics leaders will face critical failures in managing synthetic data, putting AI governance, model accuracy and compliance at risk.
That prediction is a forecast, not a measurement, but its framing is useful. The failures Gartner points to are not about whether a generator can produce plausible data. They are about whether organisations know where synthetic data sits in their pipelines, whether it is labelled as such, and whether anyone has checked that it is fit for the decision it informs.
The underlying driver is simple. Generating synthetic data has become cheap and fast, especially with large language models. Governance processes built for real data, with its lineage, consent and access controls, often do not register synthetic data at all. The result is datasets that flow into training, testing and even reporting without the scrutiny real data would receive.
Where synthetic data lies: three failure mechanisms
It can look anonymous without being anonymous
The most common enterprise justification for synthetic data is privacy: share or use the synthetic version and the personal data problem goes away. Research does not support that as a general rule.
Theresa Stadler, Bristena Oprisanu and Carmela Troncoso tested a range of state-of-the-art generative models in a paper presented at the USENIX Security Symposium in 2022, titled "Synthetic Data: Anonymisation Groundhog Day". They found that synthetic data "either does not prevent inference attacks or does not retain data utility", and that it "does not provide a better tradeoff between privacy and utility than traditional anonymisation techniques." Most importantly for practitioners, they found the trade-off "hard to predict": privacy gain was highly variable and utility loss unpredictable, because it is not known in advance which signals a synthetic dataset will keep. Their conclusion was that synthetic data "is far from the holy grail of privacy-preserving data publishing."
The practical implication is that privacy must be measured for each dataset, not assumed for the technique. Outliers, the customers with unusual profiles or the patients with rare conditions, are the most exposed, because a generator that reproduces them faithfully is close to reproducing the individual.
It can lose the tails
The second failure is fidelity. A synthetic dataset can match the averages and common correlations of real data while thinning out the rare events. For many enterprise uses, the rare events are the point: fraud, equipment failure, adverse drug reactions, unusual legal fact patterns.
Research on model-generated data makes this concrete. In "The Curse of Recursion: Training on Generated Data Makes Models Forget" (arXiv, first submitted May 2023, revised April 2024), Ilia Shumailov and colleagues showed that training on model-generated content causes "irreversible defects in the resulting models", which they called model collapse. Over successive generations, the tails of the original distribution disappear. They demonstrated the effect in variational autoencoders, Gaussian mixture models and large language models, and argued that data from genuine human interactions becomes more valuable as generated content spreads.
Enterprises rarely train models recursively on purpose. But it happens by accident when model- generated text is used to fine-tune a model, that model's outputs are logged, and the logs later become training data. Without provenance labels, nobody notices.
It can make evaluation look better than reality
The third failure is the least discussed. Teams increasingly use language models to generate test questions and expected answers for evaluating other models. If the generator and the system under test share training data or design assumptions, the test set reflects what models find easy rather than what users actually ask. Scores rise; production performance does not. A separate PanScience Research piece covers evaluation before deployment and why test sets must reflect real usage.
Synthetic data for enterprise use under the DPDP Act
India's Digital Personal Data Protection Act, 2023 defines personal data as data about an individual who is identifiable by or in relation to such data. DLA Piper's guide to Indian data protection law reads the Act as not covering anonymised or non-personal data. That reading makes synthetic data attractive: if the output is genuinely non-personal, the Act's consent and purpose obligations would not attach to it.
Three points follow for enterprises.
First, training the generator is processing of personal data. Where learned synthetic data is produced from customer, patient or employee records, the act of training the generator uses personal data and needs a lawful basis under the Act. Synthetic generation is a downstream use of the original data, not a way around the rules that govern it.
Second, whether the output is non-personal is a factual question. Given the research above, an enterprise cannot assume that synthetic records fall outside the definition of personal data. The defensible position is to test re-identification and membership risk and document the result, treating the output as personal data until shown otherwise.
Third, the research exemption is narrow. DLA Piper describes an exemption for processing necessary for research, archiving or statistical purposes, subject to standards set in the Rules, where the data is not used to take any decision specific to a data principal. A synthetic dataset used to build a credit or claims model that then makes individual decisions does not obviously sit within that exemption.
The stakes are significant. DLA Piper notes civil penalties on data fiduciaries of up to ₹250 crore per instance. The DPDP Rules were notified in November 2025 with a phased timeline; DLA Piper reports that the main substantive obligations apply from May 2027. Enterprises building synthetic data pipelines now are building them for that regime.
A fit test: four conditions for safe use
The test below is PanScience Research's proposal. It does not ask whether synthetic data is good or bad. It asks whether a specific synthetic dataset is fit for a specific decision. All four conditions should hold; if one fails, the dataset should either be fixed or used for a lower-stakes purpose.
Condition 1: The decision tolerates the fidelity gap. Every synthetic dataset differs from reality in some way. The question is whether the decision it informs is sensitive to that difference. Testing whether a software pipeline handles malformed records is tolerant; estimating the default rate of a loan portfolio is not.
Condition 2: Real data anchors both ends. The generator is built from or calibrated against real data, and the model trained with synthetic data is evaluated on held-out real data. Synthetic data can supplement training; it should not be the final arbiter of whether a model works.
Condition 3: Privacy is measured, not assumed. For learned synthetic data derived from personal data, re-identification, linkage and membership inference risk are tested and documented, with particular attention to outliers. The dataset is handled as personal data until those tests show otherwise.
Condition 4: Provenance is recorded and contained. Synthetic records are labelled as synthetic throughout their life, their generator and source data are recorded, and they are prevented from flowing back into training data for generators or models without a deliberate decision. This is the control against accidental model collapse and against synthetic data leaking into reporting.
Applied to common enterprise uses, the test gives a clear pattern.
Making it operational
The test only works if someone owns it. In practice, synthetic data governance belongs with the same function that owns training data quality, annotation guidelines and model evaluation: a data operations or model operations team, rather than individual project teams generating data as they go. A separate PanScience Research piece on data annotation in India describes how that function is evolving.
PanScience's portfolio includes Indika AI, which describes itself as a data-centric AI and model operations business (company-reported). The point of the example is structural rather than promotional: synthetic data decisions are best made where data quality, labelling and evaluation are already managed together, because each of the four conditions depends on information that function holds.
Existing frameworks help. The NIST AI Risk Management Framework's Map and Measure functions ask organisations to document the context of an AI system and measure its risks; synthetic data provenance and privacy testing fit naturally there. ISO/IEC 42001, the AI management system standard, gives a structure for assigning ownership and reviewing controls. Neither framework requires a separate synthetic data policy, but both are easier to satisfy when synthetic data is visible in the data inventory.
A short operating checklist for a chief data officer:
Register synthetic datasets in the data catalogue alongside real ones, with generator, source data and purpose.
Require a written fit test, against the four conditions, before synthetic data enters a production training or evaluation pipeline. Keep a real-data holdout for every model that uses synthetic training data. Ask vendors that supply synthetic data for their privacy test results, not their technique. Block synthetic data from management and regulatory reporting by default.
Conclusion
Synthetic data is a useful tool with a misleading name. It helps most when it is used to explore, test and supplement, with real data deciding whether the result is right. It lies when it is treated as a privacy guarantee, as a substitute for rare real events, or as the final word on whether a model works.
The research is consistent on the central point: the privacy and fidelity of a synthetic dataset are properties of that dataset, not of the technique that produced it. Enterprises that measure those properties, label synthetic data through its life and keep real data at both ends of the pipeline will get the benefits. Those that do not will find, as Gartner's prediction suggests, that the failures appear in governance, accuracy and compliance at once.
Methodology and sources
The privacy findings are from Stadler, Oprisanu and Troncoso, "Synthetic Data: Anonymisation Groundhog Day", USENIX Security Symposium 2022 (usenix.org/conference/usenixsecurity22/presentation/stadler). The model collapse findings are from Shumailov and colleagues, "The Curse of Recursion: Training on Generated Data Makes Models Forget" (arxiv.org/abs/2305.17493). The Gartner prediction is from its press release of 17 June 2025 (gartner.com/en/newsroom/press-releases/2025-06-17-gartner-announces-top-data-and-analytics- predictions). The reading of the DPDP Act, its research exemption, penalties and phased commencement is taken from DLA Piper's Data Protection Laws of the World guide for India (dlapiperdataprotection.com/index.html?c=IN); it is a law firm's interpretation, not legal advice, and enterprises should take their own advice. References to the NIST AI Risk Management Framework and ISO/IEC 42001 are at the level of their published structure. The three-kind classification, the four- condition fit test and the use-case results are PanScience Research's analytical proposals; the use-case results are illustrative judgements, not observed outcomes. The Indika AI description is company- reported from panscience.xyz.