How do you build HIPAA-compliant AI?
Most teams ask this after the pipeline works and patient text is already flowing to a model API. The answer is cheaper before that.
The short answer
6 things that decide this
- 01Start by deciding what the model never sees. Data that never reaches the model cannot leak from it, and de-identified inputs shrink every other question on this list.
- 02Sign a business associate agreement with your model provider before any protected health information reaches it, and confirm their terms permit the use. A model API handling PHI is a subcontractor in HIPAA's terms.
- 03Build the required technical safeguards rather than bolting them on. At 45 CFR 164.312 audit controls are a required standard, while encryption is addressable, which means you implement it or document why not.
- 04Keep a human decision point wherever a wrong answer reaches a patient. An AI that ranks and a clinician who decides is a defensible design; autonomous clinical determination is not.
- 05HIPAA names no certification, so no vendor holds one. Buyers ask for SOC 2 Type II or HITRUST because those do exist. What decides your review is the controls in the build and the evidence they emit.
- 06This is engineering guidance, not legal advice. Your privacy officer and counsel own the compliance determination.
Most AI features do not need identifying data
Work backwards from the task. A model matching a patient to a clinical trial needs a diagnosis, a stage, a treatment history and an age band. It does not need a name, a date of birth or a full postcode. Those fields ride along because they were in the row, not because the job requires them.
Stripping identifiers later is much harder than never collecting them. The rule at 45 CFR 164.514 gives two doors out. Safe Harbor removes 18 kinds of identifier. Expert determination has a qualified statistician certify that the re-identification risk is very small. Both are easier to satisfy when the data model was built for it.
One trap survives good intentions. Free-text notes defeat column-level de-identification, because clinicians write dates, ages, employers and place names into prose as a matter of course. If your feature reads notes, assume identifiers are in them until a scrubber and a human say otherwise.
- CaptureCollect the least you need.
- ReduceAge bands, ZIP prefixes, pseudo-IDs.
- Model callBAA in place, terms checked.
- StoreField-level encryption at rest.
- ReviewA clinician finalises.
- LogWho saw what, and when.
The third node is where projects stall in legal, and the second node is what makes it easy. Reduce before you send, and the agreement covers a much smaller question.
What the Security Rule asks a build to do
The technical safeguards are short and specific. Access control with unique user identification. Audit controls. Integrity. Person or entity authentication. Transmission security. An AI feature does not get an exemption from any of them.
Audit controls are where teams underbuild. The standard asks for mechanisms that record and examine activity in systems holding protected health information. Logging that an endpoint was called is not that. You need to answer which records a named person saw on a given day. A breach investigation is the wrong time to find out you cannot.
A proposed rule published in January 2025 would tighten this considerably. It would remove the addressable category for nearly all specifications and require encryption and multi-factor authentication outright. It has not been finalised. Building to it now costs less than retrofitting a live clinical system later.
- 01Enforce minimum necessary at the API, not in the interface. A hidden field on screen with a full record in the response fails the standard.
- 02Give every actor a unique identity, including background jobs, so an action traces to something other than a shared key.
- 03Log reads, not only writes. Most breach questions are about who looked.
- 04Map every downstream service that sees patient data, including error trackers and prompt logs.
What people ask next
01Can we send PHI to OpenAI or another model provider?
Only under a business associate agreement with that provider, and only where their terms allow it. The provider is a subcontractor once it processes protected health information on your behalf, and your agreement with the hospital does not supply one. Check the terms as well as the signature, because some plans exclude the use even when an agreement exists.
02Is our AI feature a regulated medical device?
Possibly, and the boundary turns on what the software does rather than how you describe it. Analysing a medical image or a diagnostic device signal sits on one side of the line. Presenting information for a clinician to review sits on the other. Aiming the same tool at a patient rather than a professional changes it again. Ask regulatory counsel before you build, not after.
03Do we need SOC 2 or HITRUST as well?
Your buyer decides that, and both are common gates. Health systems and payers increasingly specify HITRUST, sometimes as a contract condition. Digital health startups and most commercial buyers accept SOC 2 Type II. Neither is required by HIPAA. That is exactly why buyers ask for them, because HIPAA defines no evidence of its own.
04Does de-identified data take us out of HIPAA?
Yes, if it is genuinely de-identified by one of the two methods the rule names. There is a second condition that catches people. Safe Harbor also carries an actual-knowledge test. A dataset you know can be linked back stays in scope no matter which columns you dropped.
Related reading
- What a BAA does not cover →A signed agreement is a promise, not a control.
- PHI (protected health information) →Health data plus anything that points at a person.
- Production-grade AI →What has to be true before a model runs unattended.
- Healthcare software development →Clinical workflow work we have shipped, and what we have not.
