AI and HIPAA Compliance: What the Security Rule Requires of Any System Touching PHI
HIPAA does not have an AI section, and the Security Rule and Privacy Rule already govern any AI system that touches protected health information. This article walks the three obligations that bind an LLM deployment: access control and audit controls under 45 CFR 164.312, the minimum necessary standard, and the business associate agreement a third-party model provider triggers. It then marks where most deployments leave those obligations unmet at the request layer.
HIPAA has no AI provision, and it does not need one. The Security Rule at 45 CFR Part 164 Subpart C governs electronic protected health information regardless of what software processes it, so the moment a clinician pastes a patient note into a chat model or an application sends a claim record to an LLM API, that traffic is PHI in motion and the existing rules attach. The Cloud Radix 2026 research found 57% of healthcare professionals use unauthorized AI to process PHI, including SOAP notes and diagnostic plans, without a business associate agreement in place. I want to walk the three obligations that already bind an AI deployment touching PHI, and show where a standard deployment leaves each one unmet.
The obligations HIPAA already imposes
The Security Rule and Privacy Rule impose specific, testable requirements on any system handling PHI. Three of them decide whether an AI deployment is defensible.
Access control and audit controls
Section 164.312(a)(1) requires technical access controls that grant PHI access only to authorized persons, and 164.312(b) requires audit controls that record and examine activity in systems containing PHI. Applied to an LLM deployment, that means every request carrying PHI has to be attributable to an authenticated person or service, and the system has to hold a record of who sent which PHI to which model and when. The HHS Security Rule guidance treats these as core, and a shared API key with application logs that record only latency and status satisfies neither the attribution nor the audit requirement.
Minimum necessary
The Privacy Rule's minimum necessary standard at 164.502(b) requires that a use or disclosure of PHI be limited to the least amount needed for the purpose. An AI request that ships an entire patient chart to summarize one encounter discloses far more PHI than the task requires. Meeting the standard means classifying what a prompt actually carries and reducing it to the necessary fields before the request leaves the boundary, which is a control on the outbound prompt content.
The business associate agreement
When a third-party model provider processes PHI on a covered entity's behalf, that provider is a business associate under 164.502(e), and the relationship requires a business associate agreement before any PHI flows. The BAA obligations set terms on permitted uses, safeguards, and breach notification. A prompt sent to a provider with no BAA is an impermissible disclosure on its own, independent of whether the data was later exposed.
The compliance gap at the request layer
Most healthcare AI deployments meet these obligations at the policy level and miss them at the traffic level. The BAA is signed with the sanctioned provider, and nothing stops a clinician from using a personal account with a different model that has no BAA. Access control governs the application login, and the request the application sends to the model carries no identity the model or an auditor can see. Minimum necessary lives in a training slide, and the prompt still carries the whole chart. The gap is that HIPAA's requirements land on the PHI-in-motion, and the PHI moves inside HTTP requests to model endpoints that the usual controls do not read. The redaction problem and the audit trail problem both live at this layer.
DeepInspect
This is the layer HIPAA obligations actually land on, and it is where DeepInspect operates. DeepInspect is a stateless proxy on the AI request path between your clinicians, applications, and agents and the model endpoints they call. It binds every request to the authenticated identity your application forwards, so PHI traffic is attributable to a person or service the way 164.312 requires.
It reads the decrypted prompt, classifies PHI against the fields a task needs, and applies a minimum-necessary reduction or a block before the request reaches a provider, including blocking traffic to any endpoint outside your BAA-covered list. It commits a per-decision audit record naming the caller, the PHI categories involved, the policy applied, and the model reached, which is the audit control an OCR investigation asks to see. It runs inline and fails closed, so an unsanctioned model call is stopped rather than discovered 247 days later. The autonomous-agent version of these obligations is covered in healthcare AI agents and HIPAA. Book a demo today.
Beyond HIPAA
The same request-layer controls satisfy adjacent regimes a healthcare organization faces. State health-privacy laws, the Colorado AI Act's healthcare provisions, and the EU AI Act's high-risk classification for clinical decision support all turn on the same operational facts: who accessed what data, what the system did with it, and whether a record exists. An organization that can attribute, classify, and log PHI traffic to models has the evidence each of these regimes requests, in different vocabulary, for the same underlying decisions.
Frequently asked questions
- Does HIPAA mention artificial intelligence?
No, and it does not need to. The Security Rule and Privacy Rule govern electronic protected health information by what happens to the data, not by which software category processes it. An LLM that receives a prompt containing PHI is processing PHI, so the access control, audit control, minimum necessary, and business associate requirements apply exactly as they would to any other system. The absence of an AI-specific provision means the general obligations control, and they are specific enough to test a deployment against.
- Is a business associate agreement enough to use an AI model with PHI?
A BAA is necessary and not sufficient. It makes the disclosure to that provider permissible and sets safeguard and breach-notification terms, and it does nothing to stop PHI from reaching a different model that has no BAA, or to enforce minimum necessary on what each prompt carries. A signed BAA with your sanctioned provider plus a runtime control that keeps PHI traffic on the covered path and reduces prompts to the necessary fields is what closes the loop.
- What audit record does HIPAA expect for AI use?
Section 164.312(b) expects records that let you examine activity in systems containing PHI. For an AI deployment that means a per-request record naming the authenticated caller, the PHI involved, the model reached, and the policy decision applied. Application logs that capture request status and latency omit the identity and the data classification, which are the two facts an Office for Civil Rights investigation centers on when it asks who sent which PHI where.
- How does minimum necessary apply to a prompt?
The minimum necessary standard limits a disclosure to what the purpose requires, so a prompt should carry only the PHI fields the task needs rather than an entire record. Summarizing one encounter does not require the full chart, and a fraud check does not require the patient's full demographics. Enforcing this means classifying prompt content and reducing it before the request leaves your boundary, which is a control on the outbound traffic rather than a policy the user is trusted to follow.