Yes, HIPAA applies to AI that creates, receives, maintains, or transmits electronic protected health information. Your immediate priorities are confirming business associate agreements with every AI vendor, inventorying every AI system touching ePHI, updating your risk analysis, and enabling safeguards with per-decision logging. The HHS Security Rule NPRM signals that OCR expects documented, testable evidence, not a one-time policy binder.

TL;DR:

Nursingscience
Connect AI Governance With Nursing Science
Explore nursing science resources, policy dialogues, and collaboration supporting responsible AI adoption and stronger healthcare outcomes.
Explore nursing science resources

Table of Contents

Which HIPAA rules and HHS guidance apply to AI systems

There is no separate “AI rule” under HIPAA. Instead, the existing Privacy Rule, Security Rule, and Breach Notification Rule apply the moment an AI tool creates, receives, maintains, or transmits ePHI, whether that tool drafts clinical notes, triages patient messages, or flags claims for review. The Privacy Rule governs permitted uses and disclosures of that data, the Security Rule requires administrative, physical, and technical safeguards around it, and the Breach Notification Rule dictates what happens when an AI-related incident exposes it.

The clearest recent signal comes from HHS itself. The HHS Security Rule NPRM factsheet confirms that AI systems handling ePHI must comply with existing Privacy and Security Rules, and the proposed rule from December 27, 2024 would require covered entities to maintain a comprehensive technology asset inventory, including AI tools, along with stronger documentation, testing, and update requirements. That proposal has not been finalized, but it tells you where OCR’s attention is already pointed: asset visibility and provable diligence.

A significant share of data breaches reported to OCR traces back to a business associate or vendor relationship, according to the pattern OCR has flagged in its Security Rule NPRM, which is exactly the profile of most AI tools layered onto clinical or administrative workflows through third-party software.

For a privacy officer, this translates into concrete near-term obligations:

OCR’s enforcement posture has consistently favored organizations that can show their work. An AI vendor contract alone does not satisfy the Security Rule; you need risk analyses that name the AI system, testing logs that show it was evaluated, and access records that show who reviewed its outputs. Guidance documents like the NPRM factsheet are not final law, but they describe the direction enforcement is heading, and building evidence now costs far less than reconstructing it after an OCR inquiry.

The practical takeaway is that AI does not sit outside your HIPAA program. It sits inside it, subject to the same three rules that already govern your EHR, your billing system, and your patient portal, just with new categories of risk to document.

When does an AI vendor become a business associate?

An AI vendor becomes a business associate the moment it performs a function or activity on behalf of a covered entity that involves creating, receiving, maintaining, or transmitting ePHI. This covers a wide range of arrangements: a clinical documentation assistant that listens to patient encounters, a claims-triage model hosted by a third party, or a chatbot that answers patient questions using data pulled from the EHR. The test is functional, not descriptive. It does not matter whether the vendor calls itself a “software provider” or an “AI platform.” If ePHI flows through its systems for your operations, it is a business associate under HHS guidance on cloud computing and business associates, and you need a compliant BAA before that data ever reaches it.

AI vendor ePHI business associate flow

That guidance also confirms that business associates carry direct liability for certain HIPAA provisions under HITECH-era rules. OCR can pursue the AI vendor directly for failures like inadequate safeguards or improper disclosure, not just the covered entity that hired it. That does not reduce your own exposure, since a missing or weak BAA is itself a Security Rule failure regardless of what the vendor does afterward.

A workable BAA for an AI vendor should go beyond the boilerplate language many vendors offer by default. At minimum, require:

Pro Tip: Ask every AI vendor a direct question before signing anything: “Does any of our ePHI get used to train, fine-tune, or evaluate a model that other customers’ data also touches?” A vague answer is itself a warning sign.

Vendor due diligence should not stop at the signature. Revisit BAAs annually, and immediately whenever the vendor changes its model architecture, subprocessors, or data retention practices, since any of those shifts can silently change your risk exposure without triggering a formal contract renegotiation.

Risk analysis and living compliance across the AI lifecycle

A static, once-a-year risk analysis was never a great fit for HIPAA, and it is a particularly poor fit for AI, where a vendor can push a model update that changes behavior without notifying you. The industry term gaining traction for the alternative is “living compliance”: treating compliance evidence as something your systems generate continuously, rather than something your compliance team reconstructs during an audit. Analysis from Foley & Lardner describes this as encoding policies into executable, deterministic checks so that compliance-critical functions run the same way every time and produce their own audit trail, rather than relying on a human to remember to check a box.

Separating probabilistic language understanding from deterministic execution lets organizations make policy checks testable and auditable instead of a matter of trust.

That distinction matters for AI specifically because large language models and other probabilistic systems are, by design, inconsistent in ways traditional software is not. A rules engine that decides whether a disclosure requires patient authorization should not be left to a model’s judgment call; it should be a deterministic check that logs its own decision.

A practical lifecycle framework gives you gates at which to document decisions, rather than a single point-in-time sign-off:

  1. Design: Document the intended use, the ePHI fields the system will touch, and the vendor’s data handling architecture before procurement is finalized.
  2. Training and configuration: Record what data trained or fine-tuned the model, whether that included any of your ePHI, and under what authorization.
  3. Validation: Test the system against realistic clinical or administrative scenarios and document error rates, failure modes, and edge cases before go-live.
  4. Deployment: Confirm access controls, logging, and human-in-the-loop checkpoints are active before the system touches live patient data.
  5. Monitoring: Review logs, escalations, and drift indicators on a set cadence, not only when something goes wrong.
  6. Retirement: Document how data was purged or retained when a tool is decommissioned or replaced.

The NIST AI Risk Management Framework maps cleanly onto this structure through its four core functions: Govern, Map, Measure, Manage. It is voluntary and not HIPAA-specific, but it gives privacy officers a vocabulary and structure that auditors and legal counsel already recognize, which makes your documentation easier to defend if OCR asks how you evaluated a system.

Risk analysis needs a fresh look whenever any of three things happen: the model itself changes (a vendor pushes a new version or retrains on new data), the scope of data access changes (a new integration exposes additional ePHI fields), or the use case changes (a tool approved for documentation support gets repurposed for clinical decision support). Each of these should trigger a documented mini-review, timestamped and filed alongside your annual risk analysis, so that “we knew about the change and assessed it” is provable rather than assumed.

Several technical decisions determine how much HIPAA risk an AI system carries before it ever reaches a patient interaction. The first is understanding the difference between de-identified data and a limited data set. True de-identification, whether through Safe Harbor removal of the 18 HIPAA identifiers or expert determination, takes data outside HIPAA’s protections entirely, which makes it attractive for training or testing AI models. A limited data set, by contrast, still contains some identifiers (dates, geographic detail) and remains protected, requiring a data use agreement even when shared for research or model development. Confusing the two is a common and costly mistake when scoping what data an AI vendor can touch.

Core technical safeguards for any AI system that does handle identifiable ePHI include:

A notable proportion of data breaches now involves web tracking technologies embedded in patient-facing tools, based on the pattern OCR describes in its bulletin on online tracking technologies, which specifically warns that tracking pixels, cookies, and analytics scripts on authenticated patient portals can capture PHI and transmit it to third parties without a BAA or valid authorization.

This risk is easy to overlook because tracking technologies are often added by marketing or IT teams unaware they are touching regulated data. Any tracking vendor whose script runs on an authenticated page, where a patient has logged in to view test results, schedule an appointment, or message a provider, should be evaluated as a potential business associate. If the vendor cannot confirm what data its script captures and will not sign a BAA, remove it from the authenticated environment rather than assume the risk is theoretical.

Operational safeguards: logs, human review, and patient-directed data

Documentation is what turns a policy into evidence. For any AI system that influences a clinical or administrative decision, a per-decision record should capture enough detail to reconstruct what happened after the fact:

  1. Inputs: What data the model received, including the ePHI fields involved.
  2. Model version: Which version or configuration produced the output, since vendor updates can change behavior silently.
  3. Output and action taken: What the system recommended or generated, and what a human did with it.
  4. Reviewer identity: Who, if anyone, reviewed or approved the output before it affected a patient or record.
  5. Timestamp: When each of these steps occurred, to support both breach investigations and routine audits.

The NIST AI RMF frames this kind of record-keeping as part of the “Measure” and “Manage” functions, and it is becoming the practical standard OCR will likely expect for AI-driven decisions that touch patient care or billing outcomes.

Human-in-the-loop design should not mean a person rubber-stamps every AI output; that defeats the efficiency gain and still leaves a paper trail suggesting oversight that did not really happen. Instead, set clear escalation thresholds: routine, low-risk outputs (a draft after-visit summary, for instance) might proceed with spot-check review, while anything touching a diagnosis, medication change, or coverage denial should require documented human sign-off before it takes effect.

Pro Tip: *Build your escalation thresholds around consequence, not confidence score.

Patient-directed data transfers deserve separate attention because they change your liability picture entirely. When a patient asks you to send their ePHI to a third-party app, perhaps a symptom tracker or a personal AI health assistant, HHS guidance on the access right and health apps confirms that once the data leaves your systems at the patient’s direction, HIPAA protections may no longer apply to what that app does with it, unless the app itself is a business associate or covered entity. Your obligation is not to block the transfer, since patients have a right to direct their data, but to make sure your access workflows clearly notify patients when a destination app falls outside HIPAA’s reach.

A 90-day compliance checklist for privacy officers

Turning all of this into action works best as a staged plan rather than a single overwhelming project.

  1. Days 1 to 30, inventory and contracts: Catalog every AI system touching ePHI, confirm which vendors qualify as business associates, and flag any missing or outdated BAAs for renegotiation.
  2. Days 31 to 60, risk analysis and controls: Update your risk analysis to name each AI system individually, verify encryption and access controls are properly scoped, and confirm tracking technologies on authenticated pages have appropriate agreements in place.
  3. Days 61 to 90, logging, testing, and training: Enable per-decision logging where it does not already exist, run a documented validation test on your highest-risk AI use case, and deliver staff training on AI-specific risks and escalation procedures.

A short vendor questionnaire keeps procurement conversations focused on what actually matters:

Evidence category What OCR typically wants to see Where it lives
Asset inventory Every AI system listed with its ePHI touchpoints IT asset management system
Risk analysis AI-specific risks named and dated Compliance documentation
BAAs Signed agreements covering subprocessors Contract management system
Audit logs Per-decision records with reviewer and timestamp AI system or logging platform

If OCR opens a review, the organizations that fare best are the ones who can hand over these four categories without a scramble, because the evidence was already being generated as part of normal operations rather than assembled after the fact.

How nursing science resources support HIPAA-ready AI adoption

Privacy officers rarely solve AI governance alone, and nursing leadership has a direct stake in how these systems get implemented at the bedside and in administration. Nursing Science, guided by the American Academy of Nursing and its Council for the Advancement of Nursing Science, publishes a code of conduct that speaks to professional responsibility and governance expectations relevant to nurse scientists evaluating AI tools in practice settings.

Conferences and policy dialogues hosted through the platform connect nurse scientists working through similar AI governance questions at institutions of every size, which matters because few individual compliance teams have visibility into how peer organizations are structuring their own AI risk analyses. Sharing that experience across career stages, from doctoral researchers to established nurse leaders, speeds up how quickly good practice spreads.

Perspective: compliance and innovation are not opposites

Privacy officers sometimes get cast as the people who slow AI adoption down. The more accurate read is that unstructured AI adoption is what creates regulatory risk, not oversight itself. Staged autonomy, where an AI system earns broader decision-making authority only as its logs prove it behaves predictably, reduces risk far more than either blanket approval or blanket prohibition.

The organizations that will struggle with OCR are not the ones using AI. They are the ones who cannot produce a record of what their AI did and why. System-generated compliance evidence, logged automatically rather than reconstructed by hand, should become the default expectation for any AI touching ePHI. Engaging with professional networks and policy dialogues is one of the more direct ways to see how that expectation is playing out across institutions before it becomes a formal requirement.

— MIchael

Build your compliance program with Nursing Science membership

A professional platform connects privacy officers and nurse leaders working through AI governance questions, from BAA language to risk analysis cadence.

Nursingscience

Membership includes access to conferences and policy dialogues where these issues get worked through in detail, alongside resources built for nurse scientists at every career stage. Plans include the standard Individual membership, a discounted Individual rate, a student rate for Undergraduate, Masters, and Pre-Doctoral nurses, an NSNA member discounted rate, and Institutional membership for organizations. Compare membership benefits and become a member to start bringing your compliance conversations to a network already working on them.

This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.

Sources

FAQ

Is AI prohibited by HIPAA?

No, HIPAA does not prohibit AI. It applies existing Privacy Rule, Security Rule, and Breach Notification Rule requirements to any AI system that creates, receives, maintains, or transmits ePHI, as confirmed in the HHS Security Rule NPRM factsheet.

What is the 30% rule for AI?

Definitions like this vary by source and are not tied to any official regulation, so treat any claim of a fixed percentage threshold with caution.

Is there any AI that is HIPAA compliant?

No AI tool is inherently HIPAA compliant on its own, since compliance depends on how a covered entity configures, contracts, and monitors it. A tool can support compliance when it operates under a signed BAA, appropriate access controls, and documented risk analysis, as described in HHS guidance on business associates.

What is the new HIPAA rule in 2026?

As of 2026, the most significant proposed change is the Security Rule NPRM issued in December 2024, which would require covered entities to maintain a comprehensive technology asset inventory, including AI systems, along with stronger documentation and testing requirements, detailed in the HHS factsheet. The rule had not been finalized as of this writing, so privacy officers should track its status rather than treat it as current law.