HIPAA read against AI agents.

The HIPAA stack.

HIPAA in 2026 is four interlocking rules, all under 45 CFR Parts 160 and 164. The Privacy Rule (Subpart E of Part 164) governs uses and disclosures of protected health information. The Security Rule (Subpart C of Part 164) governs safeguards for electronic PHI. The Breach Notification Rule (Subpart D of Part 164) governs response when unsecured PHI is acquired without authorisation. The Enforcement Rule (Part 160 Subparts C, D, and E) governs investigations, hearings, and civil money penalties.

Two definitions at § 160.103 carry the weight of the regime. The verbatim text of covered entity reads: a health plan; a health care clearinghouse; a health care provider who transmits any health information in electronic form in connection with a transaction covered by this subchapter. The verbatim text of business associate reads, in operative part, a person who on behalf of such covered entity creates, receives, maintains, or transmits protected health information for a function or activity regulated by this subchapter.

The functional test in business associate is the load-bearing language. An AI vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a business associate the moment the first PHI-bearing payload is sent. The technology of the vendor is irrelevant. A foundation-model API that processes a clinical-note prompt is a business associate. An AI scribe transcribing a patient encounter is a business associate. An LLM-driven prior-authorisation agent is a business associate. The cleavage is the function performed, not the technique used to perform it.

The same § 160.103 defines protected health information as individually identifiable health information that is transmitted by electronic media, maintained in electronic media, or transmitted or maintained in any other form or medium, with the limited exclusions at paragraph (2). The 18 HIPAA identifiers at § 164.514(b)(2)(i) sit downstream of this definition and govern de-identification under the safe-harbor method.

The interlock matters. Privacy Rule violations are reachable as Security Rule violations when the breach was enabled by absent safeguards. Breach Notification Rule timelines run independently of remediation. Each rule is its own enforcement vector under Part 160 Subpart D.

Minimum necessary, read against an LLM.

The standard binds three things at once: a use, a disclosure, and a request. Each is its own engineering decision when an AI agent is the actor. A use is the agent's internal processing of the record. A disclosure is the moment the record (or any derivative) reaches a vendor's API. A request is the moment the agent asks an upstream system for additional records to enrich a decision.

§ 164.502(b)(2) sets out the exceptions. The minimum-necessary requirement does not apply to disclosures to a health care provider for treatment, uses or disclosures to the individual, uses or disclosures pursuant to authorisation, disclosures to the Secretary, uses or disclosures required by law, or uses or disclosures required for compliance with applicable subchapter requirements. Read carefully, the treatment exception is narrow. The provider must be a healthcare provider acting for treatment under § 164.501. A third-party foundation-model API is not a healthcare provider for treatment. The treatment exception does not absorb the LLM call.

The engineering pattern that satisfies the standard for an AI agent has three layers. Layer one is field selection: only the fields of the record relevant to the agent's intended purpose enter the prompt. A medication-reconciliation agent receives medication and allergy fields, not the visit note's psychosocial history. Layer two is identifier handling: identifiers are removed at the prompt boundary unless they are functionally necessary, and the identifiers that remain are bound to a separate access-controlled channel. Layer three is logging discipline: the prompt is logged with the same field discipline as the prompt itself, not enriched with surrounding record context for diagnostic convenience.

Warrant does not carry this check. An action row in the evidence package is four properties — an action_id, the actor, the action, the subject — and the schema is closed against a fifth. The action's inputs are stripped before the record is built, so nothing in the package states which PHI fields entered a prompt, which were withheld, or on what rationale. A minimum-necessary review reads the covered entity's own prompt-construction and redaction records. The evidence package fixes what the agent did with what it was given; it does not evidence the scope of what it was given.

Administrative safeguards · nine standards.

§ 164.308 enumerates nine administrative-safeguard standards, each with implementation specifications designated required or addressable. The OCR January 2025 NPRM proposes to remove that distinction. As of May 2026 the operative regulation still divides them; the proposed direction of travel is universally required with limited exceptions. The nine standards bind covered entity and business associate in parallel under § 164.302, each with an evidence-of-implementation requirement an OCR investigator can audit on request.

The 2024-2025 enforcement pattern is unambiguous. Risk-analysis failures at the center of multi-million-dollar settlements. An AI agent deployed without a HIPAA risk analysis that names the AI component is the closest analogue in 2026 to the 2018-2024 ePHI-on-an-unencrypted-laptop fact pattern. The deployment is the documented gap before any breach occurs.

Physical safeguards in a cloud-AI deployment.

§ 164.310 has four standards: facility access controls, workstation use, workstation security, and device and media controls. For a cloud-deployed AI agent, the BAA structure at § 164.314(a) pushes most of the physical-safeguard responsibility to the cloud provider. The covered entity does not run the data centre. The cloud provider does. The covered entity's BAA with the cloud provider documents the delegation; the cloud provider's audit reports (SOC 2 Type II, HITRUST, ISO 27001) document the implementation.

The covered entity remains responsible. The Privacy Rule's underlying principle at § 164.502(e)(1) is that the covered entity may delegate but cannot disclaim. If the cloud provider's physical controls fail, the breach is, on the regulator's read, the covered entity's breach. The BAA carries the cloud provider's obligation to notify; § 164.410 binds the BA to notify the covered entity within 60 days; the covered entity then runs the § 164.404 individual-notice clock.

For an AI agent, the operative physical-safeguard questions are three. Where does the model run, and who has physical access to the inference hardware. Where do prompt logs persist, and what device and media controls govern that storage. What workstation use and security policies govern the human reviewers who access the trace store. Warrant answers none of the three. The evidence package is a signed record about a decision, not a control over where prompt logs persist or who can reach the inference hardware; no field in it names a storage location, a device, or a media-control posture. The § 164.310(d) answers come from the covered entity's own cloud BAA and the provider's audit reports. What the package adds sits one layer away: the record of the decision can be checked for alteration without contacting Warrant, which is a different question from whether the substrate holding it was physically controlled.

Audit controls · the technical-safeguard core.

The single sentence at § 164.312(b) is the most directly load-bearing clause in the Security Rule when read against an AI agent. Every word matters. Hardware, software, and/or procedural mechanisms. The conjunctive-disjunctive list permits combinations; the underlying obligation is non-optional. Record and examine. Two verbs, both required: capture, then review. Activity in information systems that contain or use ePHI. The scope is the system, not just the storage. A model that processes PHI in flight uses ePHI within the meaning of the rule.

The standard has no implementation specifications. Where § 164.308(a)(1)(ii)(D) supplies the procedural review obligation, § 164.312(b) supplies the technical capability that makes the review possible. An information system that does not record activity at the granularity of a regulator-readable review fails § 164.312(b) by construction.

For a 2011-era hospital information system, audit controls under § 164.312(b) typically meant database-level audit logs of read, write, and update operations against the ePHI store. A row-level access log, with user identifier, timestamp, and operation type, satisfied a reasonable interpretation. The OCR audit protocol's audit-controls test (Audit Protocol § 164.312(b)) reads the log against the policy and against actual investigative usefulness on a sample incident.

An AI agent breaks the 2011-era pattern. The agent's interaction with ePHI is not a single read or write. It is a sequence of actions: a record retrieval, a redaction step, a prompt construction, an external API call to a foundation model, a model output, a downstream tool invocation, an outcome write. Each step is activity in an information system that uses ePHI. Each step has to be recorded. Each step has to be examinable. The single database-row access log is not sufficient under the operative read.

The Warrant per-decision record answers part of § 164.312(b) for an AI agent, and the boundary is worth stating precisely. Each action the agent took is one actions[*] row: an action_id, the actor, the action, the subject. Those four properties. Against each row sits an authorizations[*] entry naming the same action_id — within_purpose, preconditions_met, human_oversight_appropriate, reversible, and the justification for that reading — and the obligation rows that apply to that action, each naming the governing sub-clause by its id in the locked regulations corpus and carrying a compliance status. That is the examinable unit.

What the record does not carry matters as much to a privacy officer. The action's inputs and outputs are stripped before the record is built. No field holds the agent's model version, its prompt template version, or the version of the corpus the agent retrieved from. One adjacent field does exist and is worth not confusing with it: trace_metadata.regulations_corpus_sha256 pins the regulations corpus Warrant's own analysis ran against, which is a different artefact from anything the agent read. Nothing names an accountable officer or binds the record to that officer's role: the § 164.308(a)(2) accountability sits with the covered entity and is evidenced from its own governance record, not from this one. One package-level timestamp is carried, independently verifiable without contacting Warrant; there is no per-action timestamp.

So the sentence is the spec, and the artefact answers the examinability limb — a discrete, addressable, obligation-mapped unit per action, which a database-row access log does not give an auditor. The content of the activity, and the person answerable for it, still come from the record the covered entity already keeps. A vendor claiming the whole sentence is claiming fields that do not exist.

Business Associate Agreement terms.

The BAA is the contract that drags the business associate inside the HIPAA perimeter. § 164.314(a) sets the minimum required contract provisions for the security side; § 164.504(e) sets the parallel provisions for the privacy side. HHS publishes a sample BAA. Most large healthcare systems use a customised template that exceeds the floor.

Three required provisions read with particular force against an AI vendor. The compliance provision binds the vendor to the Security Rule directly, not as a contractor-of-a-contractor. The subcontractor provision binds every downstream party in the AI pipeline (the foundation-model API, the embedding-model API, the retrieval-store API, the orchestration platform) to its own BAA. The incident-reporting provision binds the vendor to surface security incidents to the covered entity, which then drives the covered entity's § 164.404 clock.

The chain doctrine is the operative consequence. Every vendor in the AI pipeline that touches PHI must have a BAA in place. A foundation-model provider that signs a BAA with the integrating vendor must maintain a BAA chain back to the covered entity through the integrating vendor's BAA. A retrieval-store provider that holds chunked clinical-document embeddings is processing PHI and requires its own BAA. The covered entity that signs only the top-level BAA without auditing the chain inherits the entire chain's exposure.

For an AI agent, the practical BAA review reads four artefacts. First, the foundation-model provider's BAA, including the data-handling addendum (whether prompts and completions are retained, whether they are used for model training, whether they are shared with third parties). Second, the orchestration vendor's BAA (the platform that hosts the agent itself). Third, the retrieval-store provider's BAA (the vector database or document store that holds clinical context). Fourth, any human-in-the-loop review service's BAA. A missing or unsigned link in the chain invalidates the entire disclosure path.

Warrant does not carry this binding. The evidence schema is closed and has no field naming a business associate agreement, so a package cannot walk a supervisor from one decision to the BAA executed at the time of that decision, or on to the chain of subcontractor BAAs. That walk stays where it is today: inside the covered entity’s own contract records. The gap is worth stating precisely, because a per-decision BAA binding is the single addition that would make a HIPAA disclosure path auditable in one hop rather than weeks.

The 60-day clock at § 164.404.

The 60-day clock starts at discovery, not at containment, not at remediation, not at root-cause completion. § 164.404(a)(2) deems a breach discovered on the first day on which the breach is known to the covered entity, or by exercising reasonable diligence would have been known. The deemed-known leg is the operative trapdoor for AI deployments. If the agent's audit trail would have surfaced the breach on the day it occurred, the discovery date is that day, not the date a human happened to notice.

The Breach Notification Rule has three further notice obligations that ride alongside § 164.404. § 164.406 requires media notice for breaches affecting more than 500 residents of a state or jurisdiction, contemporaneously with individual notice. § 164.408 requires notice to the HHS Secretary, contemporaneously with individual notice for breaches of 500 or more, annually for breaches affecting fewer than 500. § 164.410 requires the business associate to notify the covered entity within 60 days, with the operative practical expectation being substantially shorter to leave the covered entity time to satisfy its own § 164.404 clock.

The interlock with the AI vendor pipeline is procedurally tight. The foundation-model provider that experiences a breach must notify its downstream BA. The downstream BA must notify the covered entity. The covered entity must notify each individual within 60 days of its own discovery. A multi-hop AI pipeline can compress the practical window from 60 days to under 30 once intermediate BA notification times consume the front of the calendar.

Warrant does not carry a breach-disclosure record either. A package is scoped to a single trace and is written at attestation time; a breach chain is discovered later, spans many decisions, and accumulates notification hops and dispatch confirmations after the fact. Nothing in the schema holds it. What a package does supply, if a breach investigation reaches back to a specific decision, is that decision’s own signed record — the authorisation and the obligation adjudication as they stood — which is evidence about the decision, not about the notification chain.

The FDA SaMD overlay.

Where the agent constitutes a Software as a Medical Device under the FDA's reading of section 201(h) of the Federal Food, Drug, and Cosmetic Act, FDA premarket and post-market obligations attach in parallel to HIPAA. The overlap is additive, not exclusive.

The FDA's January 2021 Action Plan on AI/ML-Based Software as a Medical Device set out five components: a tailored regulatory framework including the Predetermined Change Control Plan; Good Machine Learning Practice; a patient-centered approach incorporating transparency; algorithmic-bias methods; and real-world performance pilots. The 2023 draft guidance proposed a structured mechanism for manufacturers to specify in advance which model modifications could be made post-clearance without a new marketing submission, provided the modifications were described, the protocol documented, and an impact assessment supplied.

On December 4, 2024 the FDA finalised the guidance under the title Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions. Three changes from the draft are operative. First, the scope expanded from machine-learning-enabled to all AI-enabled. Second, additional detail was provided regarding the interplay between PCCPs and modifications that still require new marketing submissions. Third, clarification was added regarding diversity considerations, intended use, and applicability to drug-device combination products.

A PCCP under the final guidance comprises three sections. The description of modifications. The modification protocol covering data management practices, retraining practices, performance evaluation, and update procedures. The impact assessment of the modifications on the device's safety and effectiveness. Where the FDA authorises a manufacturer's PCCP, the manufacturer can implement modifications consistent with the PCCP without filing a new 510(k), De Novo, or PMA supplement.

For an AI agent that is also SaMD, the PCCP and HIPAA Security Rule § 164.308(a)(8) evaluation obligation overlap at the cadence of model change. A retraining that the PCCP describes is, by the same act, an environmental change under § 164.308(a)(8) that triggers fresh HIPAA evaluation. The two evaluations can share evidence; they cannot share a single sign-off, because each regime certifies the change on its own record. An AI agent purely administrative (claims processing, scheduling, revenue cycle) is not SaMD. An AI agent that triages patients, recommends treatment, or generates diagnostic predictions is, on most readings, SaMD and the dual-track applies.

OCR's AI guidance posture, as of May 2026.

OCR has been guidance-light on AI as a standalone HIPAA topic. The operative 2024-2026 OCR signals are three.

First, the HIPAA Security Rule Notice of Proposed Rulemaking. OCR published the NPRM at 90 FR 898 on January 6, 2025, the first major proposed update to the Security Rule in twenty years. The proposed changes include removing the required-versus-addressable distinction (making implementation specifications universally required with limited exceptions); mandatory multi-factor authentication; encryption of ePHI at rest and in transit; mandatory asset inventories and ePHI flow maps; more detailed risk analysis aligned with NIST SP 800-66 Rev. 2; annual compliance audits; vulnerability scanning every six months; annual penetration testing; network segmentation; and defined restoration timeframes for critical systems. The proposed risk-analysis text expressly contemplates AI tools as in-scope assets that must be inventoried and risk-analysed. Comments on the NPRM closed March 7, 2025. As of May 2026 a final rule has not issued; the proposed direction of travel is the operative regulatory signal.

Second, the OCR Section 1557 nondiscrimination guidance. OCR published a Dear Colleague letter on January 10, 2025 titled Ensuring Nondiscrimination Through the Use of Artificial Intelligence and Other Emerging Technologies. The letter applies the Section 1557 final rule's general prohibition of discrimination, effective July 5, 2024, to the use of patient-care decision-support tools including AI. From May 1, 2025, regulated organisations must identify and mitigate risks of unlawful discrimination when using such tools. The Section 1557 path is not HIPAA, but OCR enforces both, and OCR investigators reading a HIPAA complaint involving AI will read the Section 1557 posture in the same investigative cycle.

Third, the active enforcement signal. 2025 saw multiple multi-million-dollar HIPAA settlements with risk-analysis failures at the center. The pattern reads forward to AI deployments where the original risk analysis predates the AI component. None of the published 2024-2026 OCR resolution agreements explicitly names AI/ML as the precipitating cause as of May 2026, but the structural fact pattern (risk analysis that did not contemplate the deployed system) is identical.

The summary read on OCR's posture is straightforward: AI-specific HIPAA guidance is sparse; AI-relevant HIPAA guidance is increasingly present through the Security Rule NPRM, the Section 1557 letter, and the inherited risk-analysis enforcement program. A covered entity waiting for an OCR pronouncement that explicitly governs AI is reading the wrong direction. The operative obligations attach today through the existing rules, read against the 2024-2026 guidance signals.

Recent OCR enforcement, read for AI signal.

Two enforcement signals frame the 2026 examination cycle, even where the precipitating cause is not AI by name.

2025 enforcement trends: risk-analysis failures at the center of multi-million-dollar HIPAA settlements. In the first five months of 2025 alone, OCR announced ten HIPAA resolution agreements; the through-line was the absence or inadequacy of an enterprise-wide risk analysis under § 164.308(a)(1)(ii)(A). For a covered entity that has deployed AI in 2024-2026, the operative question is whether the risk analysis was updated to name the AI component. If the answer is no, the deployment is, on OCR's read, a documented gap before any breach occurs.

March 5, 2026: OCR resolution agreement with MMG Fusion, LLC. The settlement concerned potential violations of the Privacy, Security, and Breach Notification Rules, with a 15-million-individual breach. MMG agreed to a corrective action plan with three years of OCR monitoring. The financial component of the settlement was modest, reflecting the entity's circumstances. The corrective action plan is the operative artefact: every entity in MMG's vendor pipeline and every comparable entity reading the resolution will calibrate its own posture against the corrective steps OCR required. AI is not named in the resolution; the structural exposure (PHI at scale, risk-analysis failure, breach response timing) reads forward to AI-mediated equivalents.

The forward-looking pattern is clear. AI-driven HIPAA enforcement actions naming AI/ML by name remain sparse as of May 2026 because the natural enforcement vintage has not yet ripened. The 2018-2024 ePHI-on-an-unencrypted-laptop fact pattern took five years to mature into a stable enforcement program. The 2024-2026 AI-in-the-prompt fact pattern is on the same trajectory. The covered entities and business associates that produce per-decision evidence today are the ones with the artefact when the enforcement vintage matures.

The HHS-OIG compliance program guidance.

HHS-OIG published the General Compliance Program Guidance (GCPG) on November 6, 2023, the first refresh since 2008. The GCPG sets out the seven elements of an effective compliance program: written policies; designation of a compliance officer and committee; training and education; lines of communication; well-publicised disciplinary guidelines; routine monitoring; and prompt response to detected offenses with corrective action.

The Industry Segment-Specific Compliance Program Guidance for Skilled Nursing Facilities (Nursing Facility ICPG) was published on November 20, 2024, replacing the prior 2000 and 2008 guidance. OIG announced hospital, Medicare Advantage, and clinical-laboratory ICPGs would follow in 2025. As of May 2026 the hospital ICPG has not been published; the Nursing Facility ICPG and the GCPG are the operative compliance-program references for AI-deployment governance in healthcare.

The Nursing Facility ICPG is voluntary, like all OIG compliance guidance. The practical force comes from the operative read: in any subsequent OIG enforcement action, absence of a substantially-aligned compliance program is a factor in the corrective action plan and any monitoring obligation. For a nursing facility deploying AI for resident-care decision support, the ICPG's monitoring and corrective-action provisions read against the AI deployment with the same force as any other risk area. The HHS-OIG ICPG does not modify HIPAA obligations; it sets the compliance-program substrate inside which HIPAA obligations are operationalised.

Per-decision evidence · where Warrant maps HIPAA.

The five HIPAA clauses with the most direct read against AI agents are set out below against what the warrant-v1 evidence package actually carries. HIPAA is not one of the twenty regimes in the corpus, so no HIPAA obligation row is emitted; the rows name the general-purpose fields a reviewer would read, and state plainly where no field carries the clause.

That specimen is a lending trace from a Frankfurt bank, mapped to EU AI Act Article 12 and Article 13 and to FCA Principle 12. It is not a healthcare package, it evidences no HIPAA clause, and no healthcare package sits in the register behind it. It is linked here because the shape of the record is the point and the regime is not: what one action row carries, what the authorisation assessment against it reads like, and what a reviewer can check without contacting Warrant. Read against the table above, that is the same shape a HIPAA reviewer would be handed — minus any HIPAA obligation row, because the corpus emits none.

The artefact is a record mapped to a specific EU AI Act obligation. It is not bound to the named accountable security official under § 164.308(a)(2), and it carries no attestation from that official: no field holds an officer identity or an officer's role. It is not bound to a policy version either — nothing in the record states which version of the covered entity's policies was current at the moment of decision. What it carries is the per-action authorisation assessment and the obligation rows, under one package-level timestamp that is independently verifiable without contacting Warrant. A supervisor who needs the officer and the policy version supplies both from the covered entity's own governance record, read alongside this one.

Cross-reference · NIST AI RMF and ISO/IEC 42001.

HHS aligns with the NIST AI Risk Management Framework as the federal cross-cutting AI risk framework. The NIST AI RMF 1.0 (published January 2023) sets out the four core functions Govern, Map, Measure, Manage and supplies a vocabulary the federal regulators read in common. HHS internal use of AI is governed by HHS AI Strategy and Implementation, which references the NIST AI RMF as its operative risk framework. For a covered entity or business associate, alignment with the NIST AI RMF is not legally required under HIPAA but is the most efficient way to demonstrate the structural elements that § 164.308(a)(1) risk analysis and § 164.308(a)(8) evaluation obligations read against. See /blog/nist-ai-rmf for the line-by-line read.

ISO/IEC 42001:2023 is the international AI management system standard. Certification provides the AIMS structural alignment that, in 2026 procurement cycles, has become the de facto procurement floor for AI vendors selling into HIPAA-covered settings. ISO/IEC 42001 does not preempt HIPAA; it provides the management-system substrate inside which the HIPAA-specific obligations are operationalised. A vendor with an ISO/IEC 42001 certificate plus a compliant BAA is positioned to satisfy both the procurement-grade due-diligence question and the HIPAA business-associate obligation. See /blog/iso-iec-42001-ai-management-system for the structural read.

The triangulation matters because no single regime is sufficient. HIPAA binds the disclosure path. The NIST AI RMF binds the risk vocabulary. ISO/IEC 42001 binds the management system. The FDA PCCP binds the device-software change cadence where applicable. An AI agent in healthcare sits under all four at once, but one record does not discharge them. HIPAA and the FDA PCCP are not in Warrant's corpus, so neither can emit an obligation row against any action. The NIST AI RMF and ISO/IEC 42001 are in the corpus, and a package cites them only where the trace's own classification puts it inside them — never automatically because the deployment is a healthcare deployment. What a single record does is fix the facts each of the four assessments then reads separately: the actions taken, the authorisation assessed against each, and the obligation rows for the regimes the corpus actually maps. For the parallel privacy regimes governing the same data, see GDPR Article 22, India's DPDP Act, and China's PIPL.

Questions a HIPAA privacy officer asks first.

Read the source directly.

• HHS · HIPAA Privacy Rule, 45 CFR Part 160 and Part 164 Subparts A and E
• HHS · HIPAA Security Rule, 45 CFR Part 160 and Part 164 Subparts A and C
• HHS · HIPAA Breach Notification Rule, 45 CFR §§ 164.400–414
• 45 CFR § 164.502 · uses and disclosures · minimum necessary
• 45 CFR § 164.308 · administrative safeguards
• 45 CFR § 164.310 · physical safeguards
• 45 CFR § 164.312 · technical safeguards · audit controls
• 45 CFR § 164.314 · organizational requirements · BAA terms
• 45 CFR § 164.404 · individual notice · 60-day window
• HIPAA Security Rule NPRM · 90 FR 898 · January 6, 2025
• FDA · Marketing Submission Recommendations for a PCCP for AI-Enabled Device Software Functions · December 2024
• HHS-OIG · Nursing Facility Industry Segment-Specific Compliance Program Guidance · November 2024
• HHS OCR Resolution Agreements · enforcement program
• Warrant regulator index · the regimes we map evidence against

Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. Editorial commentary on regulatory text. Not legal advice. Verbatim quotations of 45 CFR provisions reflect the regulation as currently codified at the time of writing. The HIPAA Security Rule NPRM published January 6, 2025 had not been finalised as of May 2026 and is described as proposed text; the operative regulation as of publication remains the pre-NPRM text quoted in this entry.