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.

Deploying AI in a healthcare or healthtech environment without a PHI breach or compliance gap requires more than choosing a “HIPAA-compliant” vendor. HIPAA AI compliance means controlling where protected health information enters your AI workflows, ensuring every vendor touching that data is under a business associate agreement, logging AI activity at the operation level, and producing documented evidence that your risk analysis drove your decisions, not just that you ran one.

Why this matters to the operator who is accountable

OCR’s enforcement posture has shifted. In 2025, the agency collected over $8.3 million in HIPAA fines and announced ten resolution agreements in the first five months alone, the majority tied to inadequate 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 vendor with a marketing page that says “HIPAA compliant” is not evidence. A BAA, a risk register, and tamper-evident audit logs are.

The breach numbers are equally sobering. IBM’s 2025 Cost of a Data Breach Report found healthcare breaches averaging more than $7.4 million per incident. Shadow AI, employees using unsanctioned tools, was implicated in roughly 20% of healthcare breaches that year. 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 PHI enters an AI workflow

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

PHI FLOW THROUGH AN AI WORKFLOW, CONTROL GATES

DATA SOURCE INGESTION AI PROCESSING OUTPUT EVIDENCE EHR / HIE Claims data Staff prompts Documents / notes Billing / coding GATE 1 De-identify or scope to minimum necessary BAA required before transfer Encryption at rest + in transit GATE 2 No training on PHI without written auth RBAC / ABAC enforced at data layer Prompt + response audit logged GATE 3 Human review before clinical or legal action Output scoped to requestor's role No PHI in error messages / logs Tamper-evident audit log (6-yr retention) Risk analysis documentation (current + updated) BAA inventory with AI vendors (annually verified) Approval records human reviews

Gates 1–3 are technical controls. The evidence column is what OCR asks for during investigation.

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.

Business associate agreements and vendor due diligence

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.

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. The proposed 2025 HIPAA Security Rule update, which HHS published as an NPRM in January 2025 and has targeted for finalization in May 2026, would require annual verification of BAA terms and business associate compliance posture. Treat that as the standard now, not when the rule is finalized.

Minimum necessary and least-privilege access

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).

De-identification as a risk-reduction strategy

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 removes 18 specific identifiers (name, geographic detail below state level, dates except year, device identifiers, and others). It is straightforward but strips enough detail that it can reduce AI accuracy for tasks that depend on temporal or geographic precision.
Expert Determination allows a qualified statistician or data scientist to certify 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.

Neither 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.

Audit controls and what §164.312(b) requires 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. Logs must be retained for 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.

Human review and the governance layer

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.

The HIPAA-for-AI controls matrix

HIPAA SECURITY RULE, AI CONTROLS MAP

SAFEGUARD CATEGORY SPECIFIC AI CONTROL EVIDENCE REQUIRED Administrative Risk Analysis (§164.308(a)(1)) + Risk Management AI-specific threat inventory; each tool, model, and data flow listed with likelihood + impact scored Dated risk register; remediation decisions recorded; annual review documented Administrative Business Associate Contracts (§164.308(b)) BAA with every AI vendor touching PHI; training prohibition clause; subprocessor disclosure Signed BAA on file; vendor inventory current; annual verification recorded Technical Access Control (§164.312(a)(1)) + Minimum Necessary RBAC/ABAC at data layer (not prompt layer); scoped API grants; MFA for PHI-touching systems Access policy documentation; access review log; API scope configuration records Technical Audit Controls (§164.312(b)) Required, no opt-out Inference-level logs: prompt, response, timestamp, user, model version; tamper-evident Log storage architecture docs; retention policy (6 yr min); tamper-evidence mechanism Technical Transmission Security (§164.312(e)) + Encryption at rest (proposed) TLS in transit; AES-256 at rest for stored PHI; encrypted vector stores and embeddings Encryption configuration docs; key management policy; penetration test results Physical + Organizational Workforce Training (§164.308(a)(5)) + Sanction Policy Approved AI tool list; policy on prohibited uses (e.g., public LLMs for PHI); training + attestation Training completion records; policy version history; sanction log if applicable Required now Required + proposed upgrade pending

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 governance instrumentation looks 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 platform 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.

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 with a six-year retention requirement. For AI systems, this means logs of prompts, responses, timestamps, user attribution, and model version must be stored for six years 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.