Here is the scenario that comes up more than any other when we talk to ML teams: they have a production database full of rich, well-labeled records. The records exist, are accessible to the right internal roles, and are exactly the kind of ground truth needed to train a useful model. But legal has reviewed the use case and said no. The data was collected for one purpose, and model training is a different purpose. Or the data contains fields that HIPAA requires be stripped out before any secondary use, and stripping them out makes the dataset too impoverished to train on.
This is what we call the training data gap, and it is not a bug in how these regulations were written. It is a feature. The point of GDPR data minimization and HIPAA's minimum necessary standard is exactly to prevent data collected for one purpose from being freely repurposed for others. The friction is intentional. What it creates for ML teams is a structural mismatch between the data that is legally available and the data that would produce a good model.
The GDPR Side: Purpose Limitation and Data Minimization
Two GDPR principles are particularly relevant here. Article 5(1)(b) establishes purpose limitation: personal data must be collected for specified, explicit, and legitimate purposes and not processed in a manner incompatible with those purposes. Article 5(1)(c) establishes data minimization: data must be "adequate, relevant and limited to what is necessary" for those purposes.
Together, these create a two-part problem. First, when you want to use existing data for ML training, you need to assess whether training is compatible with the purpose for which the data was originally collected (Article 6(4) compatibility test). The compatibility test considers factors like the link between the original and new purpose, the context of collection, the nature of the data, possible consequences, and safeguards. For many ML use cases, this assessment comes out negative: using transaction histories collected for fraud detection to train a lifetime value prediction model is a stretch, and legal teams default to caution.
Second, even if compatibility is established, data minimization limits what you can use. If your LTV model would benefit from 30 features but only 12 of them are necessary for the purpose as scoped, you are expected to train on 12. "Necessary" is not defined with mathematical precision in the regulation, which means it gets interpreted conservatively in practice.
The practical result: feature selection for GDPR-subject ML projects is partly a legal exercise, not purely a data science one. You cannot train on everything that would help. You train on what is approved.
The HIPAA Side: Minimum Necessary and the 18 Safe Harbor Identifiers
HIPAA's minimum necessary standard (45 CFR 164.502(b)) requires that when using or disclosing PHI, a covered entity or business associate must make reasonable efforts to limit the PHI used to the minimum necessary to accomplish the intended purpose. For ML training specifically, this is interpreted to mean that accessing a broad patient-level dataset to train a model requires justification that all accessed fields are actually required for the model's stated clinical purpose.
The Safe Harbor de-identification method (45 CFR 164.514(b)(2)) provides a cleaner path: remove all 18 specified identifiers and you have a dataset that is no longer considered PHI. But the 18 identifiers include several that are genuinely useful for clinical ML: full dates other than year (which removes admission/discharge date precision that matters for temporal models), ages over 89 (grouped into a single 90-plus category, which matters for geriatric risk models), geographic subdivisions smaller than state (which strips zip code, important for social determinants of health models), and any other unique identifying number or code, which can be interpreted to include internal patient identifiers used as foreign keys in relational clinical data.
After Safe Harbor de-identification, you have a dataset with years-only date precision, coarsened age, no sub-state geography, and potentially broken referential integrity if patient IDs were used to join across tables. For many clinical ML tasks, this is not adequate. The alternative, expert determination, requires a qualified statistician to certify that re-identification risk is "very small." This adds cost and time that most teams cannot absorb in a normal sprint cycle.
Where the Two Frameworks Converge
GDPR and HIPAA come from different legal traditions and use different language, but they create structurally identical problems for ML teams. Both impose a purpose-specificity constraint: data collected for purpose A cannot automatically be used for purpose B. Both impose a necessity constraint: you cannot use more data than you need for the stated purpose. And both create significant friction in the path from "this data exists" to "we can train on it."
The frameworks do not require this to be impossible. GDPR allows secondary use under a compatibility analysis or via a new consent mechanism. HIPAA allows expert determination as an alternative to Safe Harbor. But these paths are slow and require legal resources that most growing engineering teams cannot spin up on demand.
The Synthesis Approach and Its Legal Argument
One response to this gap is to fit a statistical model on the real data (which is done under the original lawful basis, as a use necessary to support the product), and then generate synthetic records from that model. The synthetic records contain no real individuals. They are not derived records in the legally relevant sense: they are new data generated from a learned statistical representation, not transformed versions of any real row.
Under this construction, the synthetic dataset is not personal data under GDPR (there are no identified or identifiable natural persons in it) and is not PHI under HIPAA (it does not relate to any actual patient's health condition). The downstream ML training on the synthetic dataset therefore does not require a compatibility analysis under GDPR 6(4) or a minimum necessary assessment under HIPAA 164.502(b), because the training data is not personal data or PHI in the first place.
We want to be clear about the limits of this argument. Whether a synthetic dataset is truly free of personal data depends on the quality of the privacy controls applied during generation. If the synthesis model memorizes individual rows, the synthetic records may still carry personal information. Differential privacy mechanisms and membership inference audit tests are the standard tools for verifying that a synthesis process does not leak individual-level information. We run membership inference tests as part of our default quality checks, and we take the results seriously. A synthesis pipeline that passes a standard membership inference audit gives a defensible, though not ironclad, argument that the outputs are not personal data.
We are not providing legal advice, and we are not saying this argument resolves every compliance question. Different regulators may interpret these frameworks differently, and the legal analysis in your jurisdiction may differ from what we have described. But for many teams, this framework provides a practical path through the training data gap that is faster and more reliable than waiting for a compatibility analysis to clear.
What Teams Should Actually Do
The first step is to map your data to the relevant framework. Is this GDPR-subject personal data, HIPAA PHI, both, or neither? The answer determines which constraints apply and which paths are available.
The second step is to assess the compatibility question honestly. If the original purpose was closely related to the ML use case (fraud detection data for a fraud detection model, clinical notes for a clinical NLP model), compatibility may be defensible. If the repurposing is a stretch, a synthetic data path may be faster than a compatibility analysis.
The third step, if you choose a synthetic data path, is to take the privacy controls seriously. Generating synthetic data from a model fitted on PHI or personal data is not the same as generating PHI or personal data, but it requires a rigorous synthesis process with documented privacy guarantees. A pipeline that produces synthetic data with strong differential privacy guarantees and passes membership inference audits is meaningfully different from one that does not.
The training data gap is real and it is not going away. The regulations that create it are designed to protect individuals, and that protection matters. The engineering question is how to build ML systems that operate effectively within these constraints rather than against them.