Synthetic data: trust holds back SMEs

Synthetic data has long been part of the technology conversation as an almost perfect promise: it allows teams to work with information that resembles production data without exposing personal data or compromising compliance. However, real adoption lags far behind the enthusiasm. According to recent research from Perforce Delphix, the main obstacle is not a lack of awareness, nor governance policies, nor regulation: it is data quality.

The numbers are telling. Only 38% of business leaders believe that synthetic data offers sufficient realism, and barely 34% trust that it will preserve referential integrity. In other words, two-thirds of organizations are not confident that the relationships between entities —customers, orders, payments— will remain consistent when artificial data is generated. And without that trust, the development team prefers not to use it.

The problem is not generating data, it is making it useful

Generating synthetic data is relatively simple. The hard part is making that data useful for testing real applications. The original article sums it up with an idea we share: developers and testers do not first ask whether the data is protected, but whether it is useful to them. Does it represent customer behavior? Does it support complex scenarios? Does it maintain relationships between interconnected systems? Does it give me confidence that what I test today will work in production tomorrow?

When the answer is no, the team ends up validating the application against scenarios that do not exist in production. The result is defects, failed releases, and tests that do not reflect reality. And in an SME, where the margin for redoing work is scarce, that translates directly into cost and delays.

The figure of 66% of software leaders who acknowledge not using synthetic data in development and testing should make us reflect. It is not that they do not know about it; it is that they have tried it and have not seen improvements. Many tools generate random values that, while technically valid, do not respect ranges, distributions, or business rules. A made-up customer identifier can be syntactically correct and, at the same time, impossible in the real system.

Referential integrity: the detail that changes everything

Referential integrity is the ability to maintain relationships between data across different systems. In a typical business application, customer information lives in one system, orders in another, and payments in a third. If synthetic data breaks those dependencies, the team is not testing business processes: it is testing isolated components.

The original article gives a very clear example: two entities such as investor and investment account must always be linked. If they are generated separately, the test loses meaning. The same happens with an order and its line item, or with an invoice and its customer. Generation must respect the order of dependencies so that parent-child relationships remain intact throughout the environment.

For an SME with an ERP, a CRM, and an online store, this is not an academic detail. It is the difference between a reliable test environment and a dataset that is only good for demos.

What an IT team should demand before adopting synthetic data

The Perforce Delphix research identifies several capabilities that should be considered non-negotiable when evaluating synthetic data tools. We adapt them to the context of an SME or an IT team with limited resources:

• Preserve relationships between databases and systems, not only within a schema. If the tool does not understand dependencies between systems, the synthetic data will be decorative.
• Generate in dependency order, so that parent-child relationships are maintained throughout the process.
• Validate realism and business logic: expected formats, ranges, distributions, and rules. A test dataset should never produce impossible scenarios.
• Evaluate quality continuously as schemas evolve. If every change in the source system requires manually reconfiguring generation, trust erodes.

To this we add our own recommendation: start with a limited domain. There is no need to synthesize the entire corporate database. Choosing a critical flow —for example, onboarding a customer and their first order— allows you to validate the tool with a realistic case and, if it works, expand the scope. It is the same philosophy we apply when we talk about integrating AI into the development cycle: small steps, measurable results.

The context: agentic AI raises the stakes

The original article notes that more than half of companies (51%) already use synthetic data to protect sensitive information, along with static and dynamic masking techniques. The pressure is increasing because AI agents need available, high-quality data continuously. In that scenario, referential integrity stops being a luxury and becomes an operational requirement.

For an SME, the reading is twofold. On the one hand, synthetic data can resolve the eternal conflict between giving teams access and protecting information. On the other, adopting it without quality criteria can create a false sense of security: tests that pass in an environment that does not resemble production. As we discussed when analyzing engineering lessons for traffic spikes, reliability is built on assumptions that are validated, not on data that only looks real.

The conclusion is simple: the adoption of synthetic data is not unlocked by more marketing or more compliance, but by demonstrable trust. And trust is earned when synthetic data behaves like the system it represents. Before signing with a vendor, ask them to show you how they maintain relationships between tables, how they validate business rules, and what happens when the source schema changes. If they cannot answer clearly, 34% will remain the norm.

Source: The New Stack. Analysis and adaptation: ForgeNEX.