Deploying AI in healthcare without failing HIPAA

This article is general information, not legal advice. HIPAA compliance requirements depend on the specific facts of your organization, your technology stack, and your relationships with vendors and business associates. Consult qualified legal counsel before making compliance decisions.

The short answer: HIPAA AI compliance means four things: control where PHI enters your AI workflows, put every vendor that touches it under a business associate agreement, log AI activity at the operation level under 45 CFR 164.312(b), and keep documented evidence that your risk analysis drove your decisions. A vendor's "HIPAA compliant" marketing page is not evidence.

Why does this matter to the accountable operator?

The exposure is financial before it is regulatory. IBM’s 2025 Cost of a Data Breach Report put healthcare breaches above $7.4 million per incident, and OCR’s enforcement posture has shifted on top of that. In the first five months of 2025 the agency announced ten HIPAA resolution agreements, with penalties ranging from $25,000 to $3 million, and a common finding across them was failure to conduct a thorough risk analysis rather than the breach itself. The lesson: OCR is penalizing organizations that could not demonstrate they identified, documented, and acted on known risks. A BAA, a risk register, and tamper-evident audit logs are what count as evidence.

The Breach Notification Rule is what makes that evidence urgent. Under 45 CFR 164.402, an impermissible use or disclosure of unsecured PHI is presumed to be a breach unless you can demonstrate a low probability of compromise through a documented four-factor risk assessment. The burden of proof runs against you. Individual notice under 164.404 is due without unreasonable delay and no later than 60 calendar days after discovery, and a breach affecting more than 500 residents of a state also triggers media notice under 164.406. Sixty days is not enough time to reconstruct a record that was never written.

Shadow AI, employees using unsanctioned tools, was implicated in roughly 20% of healthcare breaches in 2025. If your team is already using AI tools and you have not built a governance layer around that use, you have an exposure you may not know about yet.

Where does PHI enter an AI workflow?

Most HIPAA risk analysis frameworks were built for structured EHR workflows. AI introduces new entry points.

PHI enters AI systems through at least five common channels. Each transition point requires a control gate; the evidence column is what an OCR investigation actually reviews.

The five most common PHI entry points in AI workflows:

Direct EHR/HIE API calls, agents querying patient records to generate summaries, coding suggestions, or care-gap analyses.
Staff-written prompts, a nurse or billing coordinator pastes a patient’s name, diagnosis, or account number into a general-purpose AI tool because it is faster.
Document ingestion, prior-auth letters, clinical notes, and lab results fed into a document AI or RAG (retrieval-augmented generation) pipeline.
Claims and billing data, coding automation tools that ingest claim-level detail, which almost always contains PHI.
Conversation context, AI chat tools that accumulate patient detail across multiple turns, retaining PHI in a context window longer than any single transaction would.

The compliance failure mode in each case is the same: PHI moved somewhere without a documented authorization chain, a BAA, or an audit record.

What does a business associate agreement actually obligate?

Any AI vendor whose system receives, processes, or transmits PHI on your behalf is a business associate under HIPAA. A BAA is not optional; it is a threshold requirement. In 2025 alone, OCR collected millions in fines tied to undisclosed data flows to third-party vendors, tracking pixels, analytics platforms, and AI tools, that received PHI without a signed agreement.

Be clear about what the agreement buys you. Under 45 CFR 164.504(e) and 164.314(a), a BAA sets the permitted uses and disclosures, requires Security Rule safeguards for ePHI, requires the business associate to report unpermitted uses including security incidents and breaches, requires PHI to be returned or destroyed at termination where feasible, and flows the same restrictions down to any subcontractor that touches PHI. A subcontractor is itself a business associate and is directly liable under HIPAA. So a BAA does not make a vendor safe. It makes a vendor accountable and makes the flow-down auditable.

One practical trap with AI vendors specifically: BAA coverage is feature-specific and configuration-dependent, not blanket. The major cloud and model providers do offer BAAs at enterprise tiers, but coverage varies by endpoint and by setting, and the consumer tiers of chat products are not covered. A model API in the PHI path without a signed BAA covering that specific endpoint is not a gray area, it is an uncovered disclosure.

A well-drafted BAA for an AI vendor goes beyond the standard template. Specific provisions to require:

Prohibition on model training with your PHI. The vendor must be explicitly barred from using your patients’ data to train, fine-tune, or improve its models unless you provide separate written authorization.
Subprocessor disclosure. If the vendor routes data through a sub-model or a cloud infrastructure provider, those entities must also be bound by HIPAA-equivalent obligations.
Retention and destruction timelines. PHI and any derivatives should be destroyed within a defined window (commonly 30–90 days) after contract termination.
Incident notification terms. Define what events trigger notification, including model-level events like data leakage through AI output, and the response timeline.

Signing a BAA does not end your due diligence. OCR published a Notice of Proposed Rulemaking on 6 January 2025 that would substantially rewrite the Security Rule, including removing the required-versus-addressable distinction and requiring annual verification of business associate safeguards. The comment period closed on 7 March 2025. It remains a proposed rule, it is not being enforced, and the target for final action has moved out to 2027. Nothing in it is an obligation today. It is worth reading as a direction of travel, and annual BAA verification is a reasonable practice on its own merits.

What does the minimum necessary standard require of an AI system?

HIPAA’s minimum necessary standard (45 CFR §164.502(b)) requires that PHI access be limited to what is needed for the task at hand. AI systems violate this in two structurally common ways.

First, broad API scope grants. When an AI tool connects to an EHR via FHIR, it often requests more data fields than the specific workflow requires, because developers build for the general case and because requesting less data takes more engineering effort. The result is a system that receives a full patient record when it only needed one data element.

Second, persistent conversation context. Most AI chat tools accumulate PHI across the conversation window. A staff member who asks about a patient’s prior authorization in turn one and then asks an unrelated billing question in turn ten has inadvertently left PHI in a shared context the tool may retain, log, or expose.

The practical fix is access control at the data layer, not the prompt layer. System prompt instructions telling an AI “only use the minimum data necessary” are not enforceable controls, they are guidance to the model. Role-based or attribute-based access controls at the API or data gateway level determine what PHI can reach the model in the first place. That is the architecture that satisfies 45 CFR §164.502(b).

There is a second citation worth knowing here, because it is the regulatory argument for giving each agent its own identity. The Security Rule’s access control standard at 45 CFR 164.312(a)(1) carries unique user identification as a required implementation specification. A shared service account used by an automated process cannot satisfy it, which is why a per-agent scoped credential is a compliance position and not just a security preference. Workforce security and information access management at 164.308(a)(3) and 164.308(a)(4) are where least privilege lives in the regulation itself.

Can de-identification reduce the risk?

De-identified data is not PHI. If you can run an AI workflow on data that has been de-identified to HIPAA standards, you remove a significant compliance exposure. HIPAA provides two approved methods:

Safe Harbor, 45 CFR 164.514(b)(2), removes 18 specific identifiers (name, geographic detail below state level, dates except year, device identifiers, and others) and requires no actual knowledge that what remains could re-identify someone. Two specifics catch teams out: the initial three digits of a ZIP code may be retained only if the area sharing those digits contains more than 20,000 people, otherwise the prefix becomes 000; and all ages over 89 must be aggregated into a single “90 or older” category. It is straightforward but strips enough detail that it can reduce AI accuracy for tasks that depend on temporal or geographic precision.
Expert Determination, 45 CFR 164.514(b)(1), allows a person with appropriate statistical expertise to determine that re-identification risk is “very small,” with documented methods and results. It permits retaining more granular data, month-specific dates, regional geography, and is often better suited for AI analytics workflows where Safe Harbor would degrade model usefulness.

One distinction to get right, because getting it wrong is visible: a limited data set under 164.514(e) is not de-identified data. It retains dates and some geography, and it is permitted only under a data use agreement. Treating a limited data set as though Safe Harbor had been applied is a common and consequential mistake.

Neither de-identification method is a permanent shield. As AI models improve at re-identification from seemingly anonymous data, the risk assessment embedded in Expert Determination needs to be revisited periodically, not treated as a one-time certification.

What does §164.312(b) require of AI systems?

The HIPAA Security Rule’s audit control standard (45 CFR §164.312(b)) is a required implementation specification with no risk-based opt-out. It mandates “hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.”

For AI systems, this means every interaction involving PHI must be logged: the prompt (or the query parameters that triggered a data retrieval), the response, a timestamp, user attribution, and which model or agent version was used. The documentation retention requirement at 45 CFR 164.316(b)(2) runs six years. The regulation does not prescribe a specific format or storage architecture, but it does require that you can produce those records under investigation.

Two gaps that commonly appear in practice:

Inference-level logging is not the same as application-level logging. Your EHR may log that a user opened a patient record; it may not log that a separate AI tool then queried that same data through an API call the EHR does not track.
Logs must be tamper-evident. A log stored in a table that can be edited by a database administrator does not satisfy the audit control requirement.

On that second point, be precise about what “immutable” means, because the words are used loosely and the difference is testable. Hash chaining, where each record carries the hash of its predecessor, gives you tamper evidence: an alteration anywhere breaks the chain and is detectable. WORM storage such as Amazon S3 Object Lock in compliance mode, or Azure immutable blob storage under a locked time-based policy, gives you tamper prevention: the record cannot be deleted or modified for the retention period. Append-only at the application layer, with no storage-layer enforcement, is a policy rather than a guarantee. NIST SP 800-92 is the reference for log management practice generally.

Where does human review fit?

AI outputs in clinical, billing, and care management contexts carry real downstream consequences. A prior-authorization recommendation that is wrong costs a patient a treatment and potentially exposes your organization to liability. A coding suggestion that is wrong creates a false claim. Human review at defined decision points is not a bureaucratic overhead, it is a risk control.

Governance in this context means more than a policy document. It means:

Defined approval gates for which AI outputs can act autonomously versus which require human sign-off before action.
Role-scoped output delivery, a care coordinator should not receive the same AI-generated output as a physician if the data depth differs.
Documented remediation. OCR’s 2025 enforcement focus shifted from “did you identify risks” to “did you act on them.” A risk register with open items and no resolution dates is evidence of non-compliance, not compliance.

This is the operational discipline that regulated-industry AI governance requires, and it is where most mid-market organizations have the widest gap. The technology is not the constraint; the documented, auditable process around it is.

OCR's enforcement record shows that organizations are not penalized primarily for using AI. They are penalized for not being able to demonstrate that they governed it. The audit log, the BAA, the risk analysis, and the approval record are the compliance artifact, not the vendor's certification page.

Which controls map to which HIPAA requirement?

HIPAA Security Rule safeguard categories mapped to the specific AI controls required for each, with the evidence artifact OCR reviewers look for during investigation.

What does governance instrumentation look like in practice?

Understanding the requirements is not the same as having the infrastructure to meet them. Most healthcare and healthtech organizations at mid-market scale have the right intentions but are missing one or more of these in practice:

A current, AI-specific risk analysis that names each tool, each data flow, and each risk, not a generic checklist downloaded from a compliance vendor.
A BAA inventory that is actively maintained, not a folder of signed PDFs from three years ago.
Audit logs at the inference layer, not just application-layer access logs.
Documented human review records that can demonstrate who reviewed what AI output before a clinical or financial decision was made.
A workforce policy that defines approved AI tools, prohibited uses, and consequences, and that staff have actually attested to.

The Command Center pattern is built around this operational discipline. Permissioning, audit logging, approval gates, and compliance-evidence instrumentation are part of the deployment architecture, not an add-on layer bolted on after the fact. For healthcare operators using IntellaGrow’s AI governance and compliance service, the governance layer is what we build first, before any AI agent goes into production. To be explicit about what that is and is not: IntellaGrow is not a law firm or an auditor, does not issue certifications, and there is no such thing as HIPAA certification for any vendor. What we build is the control set the Security Rule expects and the evidence your own compliance team hands to a reviewer.

If you are working through which workflows are appropriate for AI automation in a regulated environment, the healthcare and healthtech industry page walks through the specific use cases and risk patterns we encounter most often. For a broader view of what the governance framework looks like end to end, the article on AI governance frameworks covers the full architecture. And if your organization is still assessing the cost of doing nothing, the piece on the cost of the AI compliance gap is worth reading alongside this one.

Frequently asked questions

Does every AI tool that a healthcare organization uses require a BAA?

Any AI vendor whose system receives, processes, stores, or transmits PHI on behalf of a covered entity is a business associate under HIPAA and requires a signed BAA before any PHI is shared. This includes cloud-hosted LLMs, AI coding tools that access billing data, document AI pipelines, and AI chat tools used by clinical or administrative staff. If a vendor refuses to sign a BAA, PHI cannot be used with that tool.

Can a healthcare organization use a general-purpose AI tool like ChatGPT for work involving patients?

Not without a BAA and appropriate configuration. OpenAI and similar vendors offer HIPAA-eligible configurations with BAAs, but the default consumer-facing products do not provide HIPAA coverage. Using a standard consumer AI tool with PHI, even for something as routine as drafting a patient letter, is a potential HIPAA violation. Organizations should maintain an approved tool list and train staff on which tools are authorized for PHI-adjacent work.

What does HIPAA’s minimum necessary standard require for AI systems?

The minimum necessary standard (45 CFR §164.502(b)) requires that PHI access be limited to what is needed for the specific task. For AI systems, this means access controls must be enforced at the data layer, determining what PHI the AI model can reach, not through instructions in the system prompt. Broad FHIR API scope grants that pull entire patient records for tasks requiring only a single data element are a common violation.

How long must audit logs for AI systems be retained under HIPAA?

HIPAA’s audit control standard (45 CFR §164.312(b)) is a required specification, and the documentation retention requirement at 45 CFR §164.316(b)(2) runs six years. For AI systems, this means logs of prompts, responses, timestamps, user attribution, and model version should be retained on that six-year horizon and must be tamper-evident. Standard application-level EHR logs typically do not capture AI inference activity, organizations need to confirm that their logging architecture covers the AI layer specifically.

What is the biggest HIPAA compliance risk when deploying AI in healthcare today?

Based on OCR’s 2025 enforcement record, the most common failure is inadequate risk analysis, specifically, organizations that could not demonstrate they had identified their AI-related PHI exposures and taken documented action to address them. Shadow AI (staff using unsanctioned tools with PHI) is a closely related risk. The combination of an undisclosed data flow to an AI vendor without a BAA and no audit record of the activity is what drives the largest penalties.