We talk to ML engineers who are stuck. Not stuck on model architecture, not stuck on compute budget, but stuck on something much more fundamental: they cannot touch the data. The training set they need sits behind an access control wall, a legal review queue, or a compliance officer's inbox, and the sprint keeps slipping.
This post is a frank account of the four patterns we see most often, why each one is harder to work around than it first looks, and what the realistic options are. We are not going to pretend there is a single clean solution. There are tradeoffs, and you should know them before picking a path.
Blockage 1: Production Data Is Behind Role-Based Access Controls
The most common scenario: the data exists, it is rich, and it would be perfect for training. But it lives in a production database where access is restricted to a handful of roles, and getting an ML engineer added to those roles requires a security review that takes weeks or never completes.
The instinct is to route around this by asking someone who does have access to export a CSV. This works exactly once before security teams close the gap. Informal exports create audit trail problems and, under GDPR Article 32, can constitute a security incident if the exported data contains personal data and lands in an unsecured environment.
The real issue is that RBAC systems were designed to govern operational access, not analytical access. They are poorly suited to the ML use case, where you want to read a lot of data in bulk but never write to it. Some organizations address this with dedicated read replicas for analytics, but those replicas still contain the same personal data, which means the legal analysis does not change.
Blockage 2: GDPR Data Minimization Means the Best Features Are Off-Limits
GDPR Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." This is called the data minimization principle, and it has a specific bite for ML teams.
When you originally collected a piece of data, say a user's precise location history, you collected it for a specific purpose: showing relevant local search results. Using that same location history to train a churn prediction model is a different purpose. Under GDPR, you need to assess whether this secondary use is compatible with the original collection purpose (Article 6(4)) or collect new consent.
In practice, most ML feature engineering proposals end up using data that was collected for a different purpose. Compatibility assessments take time, legal is conservative, and the result is that the richest signal columns in your database are often legally off-limits for training. You end up training on a feature set that is impoverished by design.
We are not saying GDPR is wrong to require this. The principle protects individuals from uses of their data they did not anticipate. But the consequence for ML teams is real: you may have 150 columns in your production table, and you are allowed to train on 40 of them.
Blockage 3: HIPAA Minimum Necessary Caps Training Set Size and Richness
In healthcare settings, the HIPAA minimum necessary standard (45 CFR 164.502(b)) requires that access to protected health information (PHI) be limited to the minimum amount required to accomplish the intended purpose. This is structurally similar to GDPR data minimization but with sharper teeth: the 18 HIPAA Safe Harbor identifiers must be removed from any dataset used outside its original treatment/payment/operations context, and several of those identifiers are high-signal features for clinical ML.
Consider a team at a mid-size health technology company building a readmission risk model. The best predictors of readmission include diagnosis codes, discharge notes, previous visit frequency, and precise age. Diagnosis codes and visit frequency survive Safe Harbor de-identification if handled carefully. Discharge notes contain free text that almost certainly includes indirect identifiers. Precise age (over 89) is a direct HIPAA identifier. The result: the team is allowed to train on a shrunken version of the clinical record that has had its most predictive columns removed or coarsened.
Expert determination (the alternative to Safe Harbor) can permit richer data, but it requires a qualified statistician to certify that re-identification risk is "very small." This takes months and costs money that most growing engineering teams do not have in their sprint budget.
Blockage 4: Third-Party Data Sharing Agreements Prohibit ML Use
A less-discussed but surprisingly common blockage: you acquired data from a partner, a vendor, or a data aggregator, and the data sharing agreement (DSA) has a clause that restricts use to specific purposes. Training ML models is often not one of them.
DSAs were written when the primary use of shared data was analytics dashboards and batch reports. Model training was either not contemplated or explicitly prohibited to prevent the recipient from "commoditizing" the partner's proprietary data into a model that could substitute for it. Legal teams reviewing these agreements are finding that a significant fraction of commercially acquired datasets carry restrictions that block ML training use outright.
Renegotiating a DSA takes months. The alternative is to work only with data you generated yourself, which may be small or imbalanced.
The Workaround Landscape
Given these four blockages, teams typically try one of four responses: wait for legal clearance, anonymize the data, work with a smaller approved dataset, or generate synthetic training data. Each option has real costs.
Waiting for legal clearance is the default and the most expensive. ML projects stall for months. Engineers get context-switched to other work. When clearance eventually arrives, the model requirements have often shifted.
Anonymization sounds like the right answer but is technically fragile. Removing direct identifiers does not prevent re-identification when the remaining fields are combined. A dataset with zip code, birth year, and diagnosis is re-identifiable for a high fraction of the population. Achieving genuine k-anonymity at k=5 or higher typically requires coarsening or suppressing so much data that model performance degrades meaningfully.
Working with a smaller approved dataset limits what you can train. Class imbalance problems get worse. Rare events become undetectable. You build a model that would have been better with more data and you know it.
Generating synthetic data from a statistical model fitted on the real data decouples the legal exposure from the training data. The synthetic records contain no real individuals. There is no re-identification risk because there are no real records to re-identify. The tradeoff is fidelity: synthetic data is only as useful as its statistical model of the real data is accurate. If that model is shallow, the synthetic data is shallow.
What we have built at Synthpylon is focused on that last tradeoff. The question is not "does synthetic data have limitations" (it does), but "are those limitations smaller than the cost of being blocked entirely." For most of the teams we work with, the answer is yes. A synthetic training set with 85-90% of the statistical signal of the original data, available immediately, beats a perfect dataset that is stuck in legal review for six months.
Picking Your Path
The right approach depends on what kind of blockage you are hitting. If the problem is RBAC and you just need to move data to a safer environment for ML work, a synthetic copy of the schema and distributions can give your team a development dataset today while the access review plays out. If the problem is HIPAA feature restrictions, synthetic generation can produce training data that never contained PHI in the first place, side-stepping the minimum necessary analysis entirely.
If the problem is a DSA restriction on model training, synthetic data generated from your own systems, not from the restricted partner data, is often the cleanest path. You train on what you own.
What does not work is treating these blockages as temporary bureaucratic friction that will clear up on its own. GDPR and HIPAA compliance requirements are structural. They are not going to be waived because your sprint is on fire. The ML teams that ship consistently are the ones that have designed their data pipelines to work within these constraints from the start, not the ones waiting for an exception that may never come.