Synthetic Data Generation: A Guide for Malaysian Enterprises
Synthetic data generation is the creation of artificial records that behave like your real data, so that AI models can be trained, tested and stress-tested without exposing the original records. It works well when real data is scarce, sensitive or unbalanced. It does not work as a shortcut around governance: synthetic data must be validated like any other data, and in Malaysia it sits inside a PDPA and sector-regulator context that boards cannot ignore.
This guide explains how generation works, which method suits which problem, how to judge quality and privacy, and how to move from a pilot to a controlled production workflow.
TL;DR
Synthetic data is artificial data that mimics the statistical patterns of real data. It can be tabular, text, image, video, audio or time series.
It complements real data and does not replace it. It must be tested and validated against real-world conditions, because it can carry bias, omissions and unrealistic patterns.
Calling data “synthetic” is not a formal privacy guarantee. Privacy needs to be tested, including attack-based testing, before sensitive synthetic data is shared.
Choose a generation method and tool by your data, purpose, budget, skills and infrastructure, not by feature lists.
In Malaysia, align with the PDPA, the MOSTI AI governance guidelines and, in financial services, Bank Negara Malaysia’s technology risk expectations.
Table of Contents
What synthetic data generation is
Synthetic data generation is the computational creation of artificial records, examples or observations, using statistical models, simulations or machine-learning models, so that the output resembles the distributions and relationships of real data without being a direct record of a real event. Singapore’s GovTech practice guide describes it in these terms and notes that the output can be tabular data, numbers, text, images, video, audio or time series.
The distinction that matters for enterprise teams is between three families. Rule-based mock data is hand-built or scripted: useful for software testing, but it rarely preserves real correlations. Simulation-based data comes from a model of a physical or business process, such as a production line or a payment flow. Learning-based synthesis trains a model on real samples, learns their patterns and correlations, and then produces new records. The GovTech guide draws exactly this line between learning-based synthesis, simple mock data and simulation-based data, and it matters because each family has different strengths, risks and costs.
How synthetic data is generated
There is no single technique. AWS describes three broad approaches: sampling from statistical distributions fitted to real data, training model-based machine-learning generators, and using deep-learning methods such as generative adversarial networks (GANs) and variational autoencoders (VAEs). The UK Government’s AI Insights note on synthetic data adds that data can also be produced with Monte Carlo simulations or quantitative methods based on Gaussian distributions, and used to support machine-learning development and tuning.
In practice the choice follows the data. A bank that needs realistic transaction tables for testing a new fraud model has a different problem from a manufacturer that needs images of rare defects, or an insurer that needs claim narratives to train a document classifier. Statistical sampling is transparent and cheap, but it can miss complex relationships between columns. Deep generative models capture more structure, but they cost more to run, are harder to explain to an auditor and need more careful testing for leakage of the original records.
Generative language models have added a further option for text. Large language models can draft synthetic emails, claim descriptions, customer queries and dialogue, which is how many teams bootstrap conversational agents before real conversation logs exist. The same caution applies: the output reflects the model that wrote it, and its errors and biases can be copied into whatever is trained on it.
Where it helps enterprise AI
The UK Government’s guidance lists the uses that matter most to enterprise teams: filling data gaps, rebalancing datasets, modelling rare events and addressing privacy concerns. AWS adds that synthetic data is used in research, testing and new development, and that it can help build or test models when real-world training data is insufficient.
Translated into the sectors we work with, that gives four recurring patterns.
Banking and insurance. Production data is tightly controlled, and test environments rarely get to touch it. Synthetic tables let engineering teams build and test pipelines, validate model code and rehearse integrations without waiting for access approvals. Fraud and claims leakage are rare events, so rebalancing a training set with synthetic minority cases can improve what a model learns about them.
Manufacturing. Defects, equipment failures and unusual sensor patterns are, by design, uncommon. Simulation-based and generated examples help a model see more of them before they happen on the line.
Logistics. Documents such as bills of lading, customs forms and delivery notes arrive in many layouts and quality levels. Synthetic variants of those documents help teams test extraction models across layouts they have seen only a handful of times.
Conversational agents. Synthetic dialogues let teams test how an agent handles unusual requests, escalations and edge cases before customers find them.
In each case the aim is the same: make a model more robust and a delivery team faster, while keeping real records out of places they should not be.
Tabular synthetic data: the enterprise workhorse
Most enterprise value sits in tables: customer records, transactions, policies, shipments, maintenance logs. Tabular synthetic data is generated from real tabular data through a synthesis pipeline, and GovTech’s quality guidelines say that evaluation should align its metrics with the agreed purpose and should assess privacy, legal and compliance risks alongside statistical quality.
That first point is easy to skip. A dataset can match the average and spread of every column and still be useless if it breaks the relationship between, say, policy type and claim amount, or produces a shipment that arrives before it departs. Good tabular evaluation therefore looks at three layers:
Fidelity: do column distributions and correlations resemble the real data?
Utility: does a model trained on the synthetic data perform acceptably when tested on real, held-out data?
Privacy: can anyone infer something about a real individual from the synthetic output?
Utility is the test that decides whether the exercise was worthwhile. If a model trained on synthetic data falls well short of one trained on real data when both are scored on the same real hold-out set, the generator has not captured what matters for your task, whatever the fidelity charts say.
What synthetic data cannot do
Synthetic data is not free of the problems of real data, and in some cases it adds new ones. A widely cited academic review, Best Practices and Lessons Learned on Synthetic Data, credits it with helping to address data scarcity and privacy concerns and to support more robust, reliable and fair AI, while warning about factuality, fidelity and bias, which call for rigorous testing. It also recommends combining synthetic data with real-world data and validating against real-world settings.
The UK Government’s guidance makes the same point in practical terms: synthetic data is a complement, not a replacement, and it needs the same testing, evaluation and validation as any dataset because it can contain bias, omissions and unrealistic patterns. If your real data under-represents a customer group, a generator trained on it will usually reproduce that gap. Generating more of a biased dataset gives you a bigger biased dataset.
Two practical consequences follow. First, always hold back a slice of real data that no generator has seen, and use it as the final judge. Second, treat the generator as part of the model’s lineage. Record which source data, which generator version and which settings produced each synthetic set, because an auditor or a model risk team will ask.
Is synthetic data private?
Not automatically. The GovTech guide warns that labelling data as synthetic does not by itself provide a formal privacy guarantee. A generator that memorises rare records can reproduce them, and a unique combination of attributes in a small dataset can point back to a real person.
GovTech’s privacy guidance recommends evaluating privacy before sensitive synthetic data is shared. It suggests memorisation smoke tests and attack-based testing for singling-out, linkability, inference and membership inference, and it recommends keeping three things separate: the training data, an unseen control set and the synthetic output. It also takes the view that privacy risk depends on context and that no single metric captures every leakage pathway, so empirical checks should be combined with adversarial testing against a defined threat model.
For a Malaysian enterprise, the working rule is simple. If the source data is personal data, treat the generation step as processing of that data, with a defined purpose and a lawful basis, and treat the output as something that must earn its “low risk” status through testing. Our guide to running LLMs on private data with three compliance controls covers the controls that apply when models touch sensitive records, and they apply equally to generators.
The Malaysian governance picture
Malaysia’s rules for AI and data are a mix of binding law, regulator expectations and voluntary guidance, and they are still moving.
The voluntary layer is the National Guidelines on AI Governance and Ethics from MOSTI. They promote responsible AI guided by principles including fairness, reliability and safety, privacy and security, inclusiveness, transparency, accountability and human benefit. Each of those has a direct synthetic data reading: fairness means testing generated data for skew, reliability means validating against real conditions, transparency means documenting how the data was made.
The legal layer is the Personal Data Protection Act. According to a March 2026 regulatory summary, the Personal Data Protection Commissioner issued supplementary AI guidance in January 2026 on consent, purpose limitation, legitimate interest and transparency, and amendments introducing mandatory data breach notification were under discussion. The same publisher’s PDPA compliance guide reports higher maximum penalties and portability requirements for personal data held in AI user profiles. Because these details change, confirm the current text with the Commissioner’s office or your counsel before you rely on them. For a plain-language comparison with European rules, see our note on PDPA versus GDPR actions in Malaysia, and for the wider policy landscape, Malaysia’s AI rules for policymakers and businesses.
For banks and insurers, the same regulatory summary reports that Bank Negara Malaysia updated its Risk Management in Technology policy in December 2025 with provisions on AI model validation, ongoing monitoring and consumer protection, and it points organisations to the draft MDEC AI governance framework. If a synthetic dataset helps train or test a model that touches customers, expect your model risk function to ask how the data was produced and validated. That is a question to answer in advance, with documentation, rather than during an audit. Our data governance guide mapping ISO/IEC 42001 and Malaysia’s PDP rules shows how to build that evidence trail.
Choosing a generation method and tool
GovTech’s advice is to choose a synthesiser that fits your data and constraints, technical expertise, budget, privacy needs, infrastructure and compute capacity. For tabular work, it adds that selection should rest on functional requirements, such as handling different column types, correlations and integrity constraints, and non-functional ones, such as computational cost and hardware suitability. An academic survey of tabular data synthesis reaches the same conclusion: pick by use-case-specific requirements.
We would put that into five questions to ask before any procurement or build decision.
What is the purpose? Software testing, model training, data sharing with a partner and analytics each tolerate different levels of fidelity and risk.
What must be preserved? Referential integrity across tables, business rules, time ordering and rare categories are common deal-breakers in finance and logistics.
Where will it run? Many Malaysian enterprises need generation inside their own environment or an approved cloud region. That rules out some hosted services before quality is even compared.
What does governance need to see? Enterprise-grade platforms increasingly build privacy risk assessment into the generation process, which lets governance teams enforce policy during development rather than after it. Whatever you choose, make sure privacy results and lineage are exportable as evidence.
Who will operate it? A generator that nobody can retrain, monitor or explain becomes shelfware within a year. Open-source libraries, commercial platforms and bespoke builds all fit different teams, and the honest answer is often a mix.
A workable path from pilot to production
The teams that get value from synthetic data treat it as an engineering workflow with controls, not as a one-off export. A sequence that holds up in regulated settings looks like this.
Start by defining the purpose and the success measure in business terms, for example “a document extraction model that reaches the accuracy we need on real invoices”. Then check the source data: its quality, its coverage of the cases you care about and its legal basis for this use. This readiness work is where most surprises appear, and it is why we begin engagements with readiness and data diligence.
Next, split the real data into a training portion for the generator and an untouched control set. Generate, then evaluate on all three layers: fidelity, utility on the real control set, and privacy with attack-based tests. Only then approve the dataset for its stated purpose, and record the approval, the generator version and the test results.
After release, monitor. Source data drifts, and a generator trained on last year’s customers will slowly describe a population that no longer exists. Re-run the evaluation on a schedule, and retire datasets whose purpose has ended. The broader sequence of stages, owners and checkpoints is laid out in our AI project lifecycle guide for project managers in Malaysia.
Our perspective
We see synthetic data fail for organisational reasons more often than technical ones. One team generates a dataset, a second team trains on it, a third team runs the model, and nobody owns the question “is this still representative of the business?” The generator is usually fine. The handoffs are the problem.
Our view is that synthetic data belongs inside the same accountable chain as the model it feeds. The people who decide which data to synthesise should be the people who will see how the resulting model behaves in production, and who will be answerable to compliance when it is audited. That is why we engineer for production from day one: lineage, governance, auditability and measured business results are designed in at the start, not added after a pilot impresses someone.
We also advise caution about the pitch that synthetic data removes the need for real data or for privacy review. It reduces exposure and unlocks work that would otherwise stall, and it is worth using for that. But it earns trust the same way every other dataset does: through validation against reality, documented method and continuous monitoring. For enterprises in banking, insurance, manufacturing and logistics, where a model’s error has a cost, that discipline is what separates a useful dataset from a convincing-looking one.
— Thomas Samuel
Where we can help
If you are weighing synthetic data for a document processing, conversational agent or predictive analytics project, we can help you decide whether it is the right tool and, if so, run it with governance attached. Our AI strategy and roadmap work prioritises use cases by value and feasibility, our data and platform engineering team builds the pipelines, and managed AI operations keeps the result monitored once it is live. One senior team owns the whole chain, so there is no handoff to lose context. To discuss your situation, start from our services overview and get in touch.
FAQ
What is an example of synthetic data?
A bank might generate a table of artificial customer transactions that keeps realistic spending patterns and relationships between fields, but contains no real customer’s record. It can then be used to test a fraud model or a data pipeline. Other common examples are generated images of defective parts and written customer queries for training a chatbot.
Is synthetic data better than real data?
No. It is a complement. It can fill gaps, rebalance skewed datasets and cover rare events, but it can also carry bias, omissions and unrealistic patterns from the data it was built from. Models trained with it should be validated against real-world data, as UK Government guidance stresses.
Does synthetic data remove PDPA obligations?
Not automatically. The source data is still processed to create it, and synthetic output can leak information about real individuals if the generator memorises records. Test for that risk and confirm your position with legal counsel or the Personal Data Protection Commissioner’s current guidance.
How do I choose between synthetic data tools?
Start with your purpose, data types, integrity constraints, infrastructure and team skills, then compare options against those requirements. Check the privacy testing and lineage evidence each option can produce, because your governance and audit teams will need it.
Sources
Recommended