HIPAA Security Risk Analysis for AI Systems
Every system that creates, receives, maintains or transmits electronic protected health information needs an accurate and thorough risk analysis under 45 CFR 164.308(a)(1)(ii)(A). Most risk analyses in healthcare today were written for infrastructure and describe data paths a diagram can hold. A model that retrieves documents and calls tools creates paths those analyses never considered.
HIPAA certification does not exist, and anyone selling it is telling you something useful
HHS Office for Civil Rights, which enforces HIPAA, does not pre-clear, certify or endorse any product or organization as compliant. There is no federal certification, no seal and no registry. A vendor displaying a HIPAA badge is publishing a self-assessment.
What the law does require is a risk analysis, and it holds the regulated entity responsible for having one. This engagement produces that analysis. DI-DS does not certify your organization, and no one can.
What the analysis covers
Where ePHI reaches the model
Every path by which protected health information enters a prompt, a retrieved document, a tool response or a log line. Most teams find at least one path they had not mapped.
What the model provider retains
Retention terms, training use, region of processing, and whether your Business Associate Agreement with that provider covers what actually happens on each request.
Retrieval and patient boundaries
Whether a retrieval query can return records for a patient the requesting clinician has no relationship with, and whether tenant separation holds at the data store.
Technical safeguards under 164.312
Audit controls, unique user identification, access management, integrity, transmission security and automatic logoff, tested as implemented in the AI system.
Audit controls specifically
Whether your logs would let you reconstruct which records an AI system touched, for whom, and on whose authority, which is the question that decides the scope of a breach notification.
Minimum necessary
Whether the context assembled for each request stays within what the task requires, which is where retrieval systems tend to over-collect quietly.
Workforce and human oversight
Who reviews AI output before it reaches a record, and whether that gate holds under volume.
Documented risk determinations
Each risk with likelihood, impact and the determination itself, written in the form the Security Rule expects and an OCR investigator would recognise.
Where AI systems create new ePHI exposure
These are the paths a conventional risk analysis tends to miss, because the system it was written for did not have them.
- Prompt context. Clinical detail assembled into a request and sent to a third party on every call.
- Retrieval scope. A query that reaches records outside the requesting clinician's relationship with the patient.
- Tenant and organization boundaries. Shared vector stores where separation is enforced by the component that builds the query rather than the one that answers it.
- Model provider retention. What is stored on their side, for how long, in which region, and under which agreement.
- Logs and traces. Observability tooling that captures prompts verbatim, creating a second copy of ePHI in a system nobody scoped for it.
- Generated output. Summaries written into the record, and whether a human meaningfully reviewed them.
- Tool responses. Data pulled back into context by an agent, which then reaches the model and the logs.
Questions
Will this make us HIPAA certified?
No such thing exists. HHS Office for Civil Rights does not pre-clear, certify or endorse any product, vendor or organization as HIPAA compliant, and no federal certification, seal or registry exists. Every "HIPAA certified" badge on the market is the seller's own self-assessment. Displaying one can draw FTC attention for deceptive practices on top of the HIPAA exposure you already carry.
Then what does this produce?
The risk analysis the Security Rule actually requires at 45 CFR 164.308(a)(1)(ii)(A), scoped to your AI system, with documented risk determinations and a remediation plan. That document is what an OCR investigator asks for first, and what your healthcare customers ask for during vendor review.
We had a risk analysis done last year. Is that enough?
Check whether it names your AI system. Most were written for infrastructure and applications, and describe a world where data moves along paths a diagram can hold. A model that retrieves documents and calls tools creates paths that analysis never considered. The Security Rule expects the analysis to be accurate and current for the systems you actually run.
Do we need a BAA with our model provider?
If protected health information reaches them, yes. Part of this engagement is establishing whether it does, which is less obvious than it sounds once retrieval and logging are involved. We tell you what we find and what it implies.
We are a vendor selling into healthcare, not a covered entity.
Then you are most likely a business associate, directly liable under the Security Rule, and your customers will ask for this during vendor review. Arriving with it already done shortens their review considerably.
Is this the same as the AI Assurance Audit?
They overlap and answer different questions. The Assurance Audit asks whether your AI system is secure. This asks whether you can evidence that against a specific regulatory requirement, in the documented form that requirement expects. Teams handling ePHI usually want both, and the audit findings feed the risk determinations.
Start a risk analysis
Fixed price, $7,500. Scope confirmed before anything is charged.