Training an AI model on clinical data without first de-identifying it creates HIPAA exposure that can survive the model itself. Researchers have demonstrated that identifiable details from training data can, in some cases, be extracted from a trained model by querying it, which means the risk does not end when training finishes. It persists inside the model’s weights, in a form that is far harder to audit or delete than a row in a database.
That persistence is what makes AI training data a different category of HIPAA problem than a one-off LLM query, the kind of risk that a general HIPAA compliance review for AI systems can miss if training pipelines aren’t examined separately from everyday model use. A single non-compliant prompt is a discrete, correctable incident: delete the log, notify if required, move on. A model trained on un-de-identified PHI is a standing liability for as long as that model exists, and retraining from a clean dataset is usually the only real remediation once the problem is discovered.
This article covers what HIPAA requires before clinical data is used for AI training, how the minimum necessary standard applies to training corpora specifically, the choice between Safe Harbor and Expert Determination for training datasets, what de-identification for AI training actually requires technically and how a de-identification pipeline built for this use case holds up at scale.
What HIPAA requires before using clinical data for AI training
Clinical data used to train an AI model is PHI like any other use, unless it has been properly de-identified first. HHS recognizes exactly two methods for de-identifying PHI under the Privacy Rule: Safe Harbor, which requires removing 18 specific identifiers and confirming no actual knowledge that the remaining data could re-identify someone, and Expert Determination, in which a qualified statistician certifies that re-identification risk is very small. Training a model on data that has not gone through one of these two paths, without a valid authorization or an applicable exception, is a use of PHI that needs the same legal basis as any other disclosure.
This applies whether the training data comes from your own patient population or from a third-party dataset. If the dataset still carries PHI, using it to train a model is subject to the same rules as using it for any other purpose.
Two paths exist for using identifiable data in AI training without full de-identification, and both are narrower than teams often assume. A limited data set, stripped of direct identifiers but still containing some dates and geographic detail, can be used for research under a signed data use agreement, but a limited data set is not the same as de-identified data and still counts as PHI. Research use under an IRB waiver of authorization is possible when a review board determines the research could not practicably be done otherwise and the privacy risk is minimal, but that waiver covers the specific research protocol it was granted for, not open-ended model training beyond that scope.
The minimum necessary standard applied to AI training corpora
Minimum necessary is often framed around a single query or a single chart pull, but it applies just as directly to a training corpus. A model does not need a patient’s name, exact date of birth or street address to learn clinical patterns. It needs the clinical signal: symptoms, treatments, outcomes, temporal relationships. Building a training set that strips identifiers while preserving that signal is, in practice, how minimum necessary gets satisfied for AI training specifically. A corpus that retains identifiers “just in case they’re useful later” is very likely collecting more than the training task requires.
A pharma team building a model to predict adverse event patterns from clinical trial notes, for example, needs the sequence and severity of symptoms far more than it needs the trial site’s exact address or a coordinator’s name. Stripping the latter rarely costs the model anything.
The habit of over-collecting “just in case” usually comes from treating the source system’s full export as the default training set, rather than deliberately selecting the fields the model actually uses. A team that pulls an entire EHR export because it is the easiest thing to query, then trains only on the clinical notes buried inside it, has still collected the full identifiable record, medical record numbers, insurance details, next-of-kin contacts and all, for a task that needed none of it. Minimum necessary is violated at the point of collection, not just at the point of use, so the fix is scoping the extraction query itself, not just cleaning the data afterward.
Safe Harbor vs Expert Determination for AI training datasets
Both paths lead to de-identified data, but they suit different training scenarios.
| Method |
How it works |
Best fit for AI training when |
| Safe Harbor |
Remove all 18 identifiers listed under 45 CFR 164.514(b); confirm no actual knowledge that remaining data is re-identifiable |
You need a fast, deterministic, auditable process across a large, varied corpus and can accept some loss of granular detail, such as exact dates or precise geography |
| Expert Determination |
A qualified expert applies statistical methods to certify very low re-identification risk, potentially retaining more granular data |
You need to preserve fields Safe Harbor would strip, such as exact dates for longitudinal modeling, and can support the expert review process |
Safe Harbor is generally the faster path for training corpora built from high-volume, heterogeneous sources like clinical notes, because it is checklist-based and does not require a statistical review of the finished dataset. Expert Determination is worth the added process when temporal precision or geographic granularity is important to the model’s task. A model predicting disease progression over exact time intervals, for instance, loses signal if Safe Harbor’s date-shifting requirements are applied indiscriminately. In practice, the statistician conducting an Expert Determination assesses re-identification risk using established methods, such as estimating how many people in the relevant population could plausibly share the same combination of retained attributes, and documents that analysis in a report the organization keeps on file. That report is also what makes Expert Determination defensible on audit, since it shows the reasoning behind the risk assessment rather than just the conclusion.
Once PHI is in the model, retraining is the only fix.
De-identify clinical text, records and audio before training begins, with consistent entity mapping and an audit-ready trail for every detection and transformation.
Talk to Our Team
What de-identification for AI training actually looks like
De-identifying a training corpus is a different engineering problem than de-identifying a single document, for four reasons.
Entity consistency. If “John Smith” appears 50 times across a patient’s longitudinal record, every instance needs to map to the same replacement token, or the model loses the ability to learn from repeated references to the same person across a care episode. Inconsistent tokenization breaks exactly the kind of temporal and relational signal AI training depends on.
Coreference resolution. A single note might refer to the patient by name once, then as “she,” “the patient” or “Ms. Smith” throughout the rest of the document. A de-identification system that only catches exact-match identifiers misses these references, leaving PHI in the training set even after a first pass.
Format preservation. Clinical text is unstructured, but it is not unstructured randomly. Dates, medication names and lab values follow patterns the model needs to learn. De-identification for training has to remove identifiers without collapsing that structure into noise, or the resulting dataset trains a weaker model than the source data would support.
Consistent date handling. Safe Harbor requires shifting dates rather than deleting them outright, so a model can still learn from sequence and duration, such as time between diagnosis and treatment, without retaining the actual calendar dates. That shift needs to be applied consistently within each patient’s record, so relative timing between events stays intact even though the absolute dates no longer point to a real date on the calendar.
Get any one of these wrong at scale, and the result is either a training set that still leaks PHI, or one so degraded that the model trained on it underperforms.
Limina integrates with AI training pipelines to de-identify data before model training begins.
How Limina de-identifies clinical training corpora
Limina AI integrates directly into AI training pipelines, de-identifying clinical text, structured records and audio at the volume training corpora require, with entity consistency and coreference resolution built into the pipeline rather than handled as an afterthought. The platform reaches 99.5 percent or higher accuracy on real healthcare data, compared with 60 to 70 percent for general-purpose cloud de-identification tools, and produces audit-ready output suitable for Expert Determination review when a training project calls for it. For ML teams on ANALYZE, that means the data de-identification platform can sit inside an existing training pipeline through an API, rather than as a separate manual process that slows down iteration. A typical integration point is a single de-identification call inserted into the data-loading step of an existing training job, so a batch of clinical notes is de-identified in place before it ever reaches the tokenizer, with the original entity mapping stored separately and only accessible to authorized users who need to re-identify results later.
