What HIPAA actually requires of an AI system

"HIPAA-ready" on a vendor's compliance page is a starting claim, not a demonstration. The substance sits in three separate rules with different jobs, a contract requirement that attaches the moment a vendor touches patient data — whether or not anyone's signed anything yet — and a safeguard structure that gets misread more often than almost any other part of US health privacy law.

Current as of October 2026. Not legal advice — a starting point for internal discussion, not a substitute for qualified healthcare privacy counsel.

Three rules, three different jobs

The Privacy Rule governs when and how protected health information (PHI) may be used or disclosed at all, in any form. The Security Rule governs only electronic PHI — the administrative, physical and technical safeguards required to keep it confidential, available and unaltered. The Breach Notification Rule governs what happens after a failure — who gets told, how fast, and what counts as reportable at all. An AI system touching PHI has to satisfy all three, and they're genuinely separate compliance questions, not one blanket requirement.

Business associate status attaches by function, not by contract

A vendor that creates, receives, maintains or transmits PHI on a covered entity's behalf is a business associate the moment it does so — there is no volume threshold, no sensitivity threshold, and it does not depend on whether a contract has been signed. A covered entity is only permitted to disclose PHI to that vendor once a written Business Associate Agreement (BAA) is in place, covering: permitted-use limits, Security Rule compliance for electronic PHI, breach reporting, the same obligations flowed down to any subcontractor, support for a patient's access and amendment rights, and return or destruction of the data at contract end. Since 2013, business associates have been directly liable to federal enforcement for violating these terms — not just liable to the covered entity under contract law. A vendor handling patient data without a signed BAA in place is not a minor administrative gap; it's a disclosure the covered entity wasn't permitted to make.

"Addressable" is not optional

The Security Rule's technical safeguards — unique user identification, audit controls, encryption, authentication — split into required and addressable specifications. Required means implement it. Addressable is routinely misread as optional; it is not. It requires the organization to assess whether the specification is reasonable and appropriate for its own environment, and if it decides not to implement it as written, to document that reasoning and either implement an equivalent alternative or document why neither is reasonable. In practice, for a system handling PHI, encryption at rest and in transit — both technically addressable — are treated as the expected baseline, not an optional add-on, given the modern threat environment. Unique user identification and audit controls are required outright: shared service accounts and unlogged access are compliance failures, not implementation details.

Minimum necessary applies to requests, not just disclosures

The minimum-necessary standard limits PHI to what's needed for the purpose at hand — and it applies to what an organization requests or retrieves, not only to what it discloses to someone else. This is directly relevant to how an AI system is architected: a system built on broad, standing retrieval — a care-coordination agent with open access to a full longitudinal record when a given task only needs a lab-results excerpt, for instance — can structurally violate minimum-necessary independent of what it subsequently does with the data. Scoped, purpose-bound retrieval isn't just good practice; it's what the standard actually requires.

Breach notification: the 60-day clock

An impermissible use or disclosure of PHI is presumed to be a reportable breach unless a documented risk assessment shows a low probability the information was actually compromised. Affected individuals must be notified without unreasonable delay and in no case later than 60 calendar days after discovery — and the clock starts when any workforce member becomes aware, not when leadership is formally briefed. Breaches affecting 500 or more people in a state or jurisdiction also require media notice and immediate notice to HHS; smaller breaches are reported to HHS in an annual log instead.

The GDPR parallel, briefly

A BAA is a genuine structural parallel to a GDPR Article 28 data processing agreement — both mandate a binding contract with specific required terms, and both make the processor directly liable to the regulator rather than only to the counterparty. The Security Rule's safeguards are conceptually close to GDPR Article 32's security-of-processing obligations, though the two reach that destination differently: HIPAA is prescriptive and enumerated, GDPR is principles-based around a single "appropriate to the risk" standard. See Eclypse for Europe for how the same underlying questions play out under GDPR specifically.

See Medicare reimbursement for AI-enabled healthcare software for the other half of the US picture, and Eclypse for the United States for how both fit together.

Show us your data flows — we'll map where the BAA and safeguard gaps actually are.

Book a working session