Most developers know they shouldn't use production data in non-production environments. But knowing and doing are two different things — and the gap between them is getting more expensive.
According to Nick Mathison, Senior Product Manager for Delphix at Perforce Software, around 80% of organizations are still sharing production data downstream into non-production environments. That's not a new problem. What's new is that AI makes it significantly more dangerous.
AI Finds What You Missed
Mathison pointed to a recent example that frames the risk well. When the Mythos vulnerabilities were disclosed, researchers found that multiple low-severity issues could be chained together into a critical exploit. The same logic applies to data exposure.
"Before, you might have been okay with some risk," Mathison said. "You knew data was downstream. But now AI can find potentially divergent data points that — when put together — allow you to cross-reference and start to find these giant chains."
In other words, data that seemed harmless in isolation isn't harmless anymore. An AI agent combing through a non-production environment can connect dots that no human analyst would.
The People and Process Problem
When asked what most engineering teams get wrong about test data, Mathison didn't point to tooling. "Time and time again, it's a people and process problem," he said. "There are many tools out there that can do the job. At the end of the day, it's organizing your team in a way that shows the value of working this way."
Developers aren't oblivious to the problem either. Mathison said he asked this question at a user group recently and got a lot of knowing chuckles. "They know they're hiding their heads under the covers," he said. "They know it's there. It's just hard to track and monitor."
That's a pattern worth paying attention to. It's not ignorance — it's friction. Teams know the right approach, but the path to getting there feels expensive and disruptive.
Masking First, Synthetic Where It Fits
The most reliable fix, according to Mathison, is straightforward: mask production data before it ever leaves the production environment and pass only desensitized data downstream.
"Profile it, mask it in production, and then only share desensitized data into non-prod environments," he said. "Once it's masked, those teams are free to use it however they need — build the next feature, solve the next bug, iterate quickly."
Synthetic data is increasingly popular, especially with AI-generated datasets becoming easier to produce. But Mathison is direct about where it works and where it doesn't. Synthetic data is a good fit for greenfield projects and supplementing masked datasets. It breaks down when you're trying to replicate a full production database — complex relationships, correlated values, and real-world edge cases are hard to synthesize accurately. And when it comes to LLM training specifically, there's an added wrinkle: a model trained on AI-generated data can introduce a feedback loop that may not yield reliable results.
The practical takeaway: use masking as your primary strategy and treat synthetic data as a supplement rather than a replacement.
Shift Left on Data, Not Just Code
Developers have internalized shift-left thinking for testing and security. The same logic applies to data governance — it's just less common in practice.
Mathison described the target state as a self-service model. A platform team or data administration team manages the masking policies and makes compliant datasets available. Developers and testers pull what they need, when they need it, without opening a ticket or waiting on another team. "The upsides of getting access to that data when I need it, how I need it, just trumps the gotchas of making sure it's masked," Mathison said.
On the compliance side — GDPR, HIPAA, CCPA — Mathison is realistic about what developers can be expected to know. "You can't be an expert in everything," he said. The CISO and data administration teams own the policy. Developers need clear guardrails and tooling that make following those policies the path of least resistance.
One more watch-out: cloud costs. Teams moving to cloud-based data environments can see resource consumption scale quickly if access controls aren't balanced with spend management. It's the same pattern that bit organizations during the early lift-and-shift era.
What Good Looks Like
The bottom line is clear boundaries between production and non-production, a reliable masking process, and a self-service data delivery workflow that doesn't slow developers down.
Toil is the enemy. If the process for getting a compliant dataset is painful, developers will work around it. If it's fast and self-serve, they won't have to.
