HIPAA Privacy + Security Rules for AI agents

Q: What does minimum necessary mean for an LLM that processes a patient record?

45 CFR § 164.502(b)(1) requires a covered entity or business associate to make reasonable efforts to limit PHI to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request. Read against an LLM, the rule binds three engineering decisions: which fields of the record enter the prompt; whether identifiers are removed before the model processes the record; and whether the prompt is logged with or without those identifiers. The exceptions at § 164.502(b)(2) include disclosures to a healthcare provider for treatment, but a third-party LLM API is not a healthcare provider for treatment under § 164.501. The treatment exception does not absorb the foundation-model call.

01 · THE HIPAA STACK

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.

Covered entity means: (1) A health plan. (2) A health care clearinghouse. (3) A health care provider who transmits any health information in electronic form in connection with a transaction covered by this subchapter. 45 CFR § 160.103 · definition of covered entity

Business associate means a person who on behalf of such covered entity or of an organized health care arrangement creates, receives, maintains, or transmits protected health information for a function or activity regulated by this subchapter. 45 CFR § 160.103 · definition of business associate · operative paragraph

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 functional test under § 160.103 is the trapdoor every AI vendor falls through. If the model processes PHI, the model is a business associate."Warrant Compliance · 2026-05-09

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.

02 · § 164.502(b) MINIMUM NECESSARY

Minimum necessary, read against an LLM.

When using or disclosing protected health information or when requesting protected health information from another covered entity or business associate, a covered entity or business associate must make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request. 45 CFR § 164.502(b)(1) · minimum necessary standard · verbatim

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.

The Warrant evidence pattern emits a per-decision data-scope check. The trace records, for each action the agent took, which PHI fields were in scope, which were excluded, and the rationale tying scope to intended purpose. The supervisor reading the artefact reads the minimum-necessary discipline as engineered, not asserted.

03 · § 164.308 ADMINISTRATIVE

Administrative safeguards · nine standards.

Implement policies and procedures to prevent, detect, contain, and correct security violations. 45 CFR § 164.308(a)(1) · security management process · standard

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

§ 308(a)(1)

Security management process. Risk analysis (required), risk management (required), sanction policy (required), information system activity review (required). FOR AN AI AGENT · the risk analysis must contemplate the AI component, including the foundation model, the prompt-construction layer, the retrieval corpus, and the vendor pipeline. A risk analysis predating the AI deployment is a documented gap.

§ 308(a)(1)(ii)(D)

Information system activity review. Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports. FOR AN AI AGENT · the per-decision trace is the audit log of record. Periodic review against suspicious-pattern criteria (e.g., out-of-scope retrievals, identifier leakage in prompts, anomalous BAA-bound API call volumes) is documented.

§ 308(a)(2)

Assigned security responsibility. A named security official. FOR AN AI AGENT · a named human officer accountable for the AI deployment's HIPAA posture. The accountability does not migrate to a vendor under any BAA term.

§ 308(a)(3)

Workforce security. Authorisation, supervision, and termination procedures. FOR AN AI AGENT · the agent itself is not a workforce member, but the human reviewers who operate the agent are. Authorisation includes role-based access to the trace store and to model configuration.

§ 308(a)(4)

Information access management. Access authorisation and access establishment under § 164.514(d) minimum-necessary discipline. FOR AN AI AGENT · the agent's effective access is the union of every tool credential it can invoke. Tool-level access boundaries are part of the access management posture.

§ 308(a)(5)

Security awareness and training. Periodic training, log-in monitoring, password management. FOR AN AI AGENT · operators of the agent receive training on prompt hygiene, redaction discipline, and incident-escalation procedures specific to AI-mediated PHI handling.

§ 308(a)(6)

Security incident procedures. Identification, response, mitigation, documentation. FOR AN AI AGENT · prompt injection, retrieval-of-out-of-scope-records, identifier leakage in model output, and BAA-violating fallback paths are recognisable security incidents under § 164.304.

§ 308(a)(7)

Contingency plan. Data backup, disaster recovery, emergency mode operation, testing and revision, applications and data criticality analysis. FOR AN AI AGENT · the contingency plan addresses model unavailability (vendor outage), model drift (silent quality degradation), and the fallback path the agent takes when its primary tools are unreachable.

§ 308(a)(8)

Evaluation. Periodic technical and nontechnical evaluation, in response to environmental or operational changes. FOR AN AI AGENT · model swaps, prompt-template revisions, and retrieval-corpus changes are environmental changes that trigger fresh evaluation. The cadence is set by policy and read against actual practice.

§ 308(b)

Business associate contracts and other arrangements. FOR AN AI AGENT · every vendor in the AI pipeline that processes PHI is a business associate; each requires a BAA satisfying § 164.314(a). Subcontractors of business associates require their own BAAs under the chain doctrine.

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.

04 · § 164.310 PHYSICAL

Physical safeguards in a cloud-AI deployment.

Implement policies and procedures to limit physical access to its electronic information systems and the facility or facilities in which they are housed, while ensuring that properly authorized access is allowed. 45 CFR § 164.310(a)(1) · facility access controls · standard

§ 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. The Warrant evidence pattern places the trace store under the covered entity's direct control even when the model itself runs at a vendor, so the device and media controls under § 164.310(d) apply to a substrate the covered entity owns.

05 · § 164.312(b) AUDIT CONTROLS

Audit controls · the technical-safeguard core.

Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. 45 CFR § 164.312(b) · audit controls · standard · verbatim

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.

"Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. Read at the granularity of an LLM tool call, the sentence is a specification."45 CFR § 164.312(b) · audit controls

The Warrant per-decision trace is the regulator-readable instantiation of § 164.312(b) for an AI agent. The artefact records every action the agent took, with subject, inputs, outputs, model version, prompt template version, retrieval corpus version, named accountable officer at decision time, and rationale tying the action to its authorisation under the covered entity's policies. The record binds to the named officer's role, and the activity log is a record mapped to a specific EU AI Act obligation. The timestamp is independently verifiable without contacting Warrant, and the record reads as tamper-evident after the fact.

The single sentence and the engineered artefact are isomorphic. The sentence is the spec; the artefact is the deliverable; everything between is engineering.

06 · § 164.314(a) BAA

Business Associate Agreement terms.

The contract between a covered entity and a business associate must provide that the business associate will: (A) Comply with the applicable requirements of this subpart; (B) ensure that any subcontractors that create, receive, maintain, or transmit electronic protected health information on behalf of the business associate agree to comply with the applicable requirements of this subpart by entering into a contract or other arrangement that complies with this section; and (C) report to the covered entity any security incident of which it becomes aware, including breaches of unsecured protected health information as required by § 164.410. 45 CFR § 164.314(a)(2)(i) · BAA required contract provisions · operative reading

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.

The Warrant trace metadata field ba_agreement_id binds each decision to the BAA chain that authorised it. The supervisor pulling a single decision walks back from trace through ba_agreement_id to the BAA executed at the time of decision, and from the BAA to the chain of subcontractor BAAs. The walk takes seconds. Without the binding, the walk takes weeks of internal investigation, often producing a partial answer, which is itself the gap finding.

07 · § 164.404 BREACH NOTICE

The 60-day clock at § 164.404.

A covered entity shall, following the discovery of a breach of unsecured protected health information, notify each individual whose unsecured protected health information has been, or is reasonably believed by the covered entity to have been, accessed, acquired, used, or disclosed as a result of such breach. 45 CFR § 164.404(a)(1) · individual notice · standard

Except as provided in § 164.412, a covered entity shall provide the notification required by paragraph (a) of this section without unreasonable delay and in no case later than 60 calendar days after discovery of a breach. 45 CFR § 164.404(b) · timeliness · 60-day window

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, immediately 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.

The Warrant trace.metadata.breach_disclosure_chain field is the per-decision binding to the breach-event evidence record. When a breach event affects one or more decisions in the trace store, the field captures the chain of notifications, the discovery dates at each hop, and the individual-notice dispatch confirmations. The artefact reads back to a regulator with the same evidentiary force as the original decisions.

08 · FDA SaMD OVERLAY

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, FDA finalized the PCCP guidance. The scope expanded from ML-enabled to all AI-enabled. The framework binds every AI device on the market."FDA · December 2024 final guidance

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.

09 · OCR AI GUIDANCE

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.

10 · OCR ENFORCEMENT

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. By Q3 2025, OCR had announced 20 settlements and financial penalties; the through-line in the resolution agreements 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.

11 · HHS-OIG ICPG

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.

12 · WHERE WARRANT MAPS HIPAA

Per-decision evidence · where Warrant maps HIPAA.

The five HIPAA clauses with the most direct read against AI agents are mapped to specific Warrant evidence fields. Each row in the table is exercised in the canonical 200-trace eval suite and reproduced in the sample evidence package linked below.

HIPAA clause	What evidence must show	Warrant evidence field
§ 164.502(b)	Per-decision data-scope check showing minimum-necessary discipline applied to PHI fields.	trace.actions[].data_scope
§ 164.308(a)(1)(ii)(D)	Per-decision audit trail with decision rationale, suitable for information system activity review.	trace.actions[].decision_rationale
§ 164.312(b)	Hardware/software audit log with tamper-evident integrity.	a record independently verifiable without contacting Warrant
§ 164.314(a)	Per-decision binding to the BAA chain that authorised the disclosure path.	metadata.ba_agreement_id
§ 164.404	Breach-event evidence record with discovery dates and notification chain.	metadata.breach_disclosure_chain

Sample healthcare evidence package · Warrant registerINDEPENDENTLY VERIFIABLE WITHOUT CONTACTING WARRANT

→ /v/7de85ceaeac42a47

The artefact is a record mapped to a specific EU AI Act obligation, bound to the named accountable security official under § 164.308(a)(2). It does not authenticate a server; it carries the regulated officer's attestation that the trace is what the agent did. The timestamp is independently verifiable without contacting Warrant, and the supervisor reads it against the policy version that was current at the moment of decision.

13 · NIST + ISO 42001

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 is a four-regime artefact, and the per-decision evidence package that satisfies one is engineered to satisfy all four. For the parallel privacy regimes governing the same data, see GDPR Article 22, India's DPDP Act, and China's PIPL.

14 · FAQ

Questions a HIPAA privacy officer asks first.

Is an AI vendor a Business Associate under HIPAA?

If the AI vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity for a function the covered entity would otherwise perform, the vendor is a business associate under 45 CFR § 160.103. The definition is functional, not technological. A foundation-model API that ingests a prompt containing PHI is a business associate from the moment the first PHI-bearing prompt is sent. The covered entity must execute a Business Associate Agreement under § 164.314(a) before that disclosure happens. A vendor that refuses to sign a BAA cannot lawfully receive PHI from a covered entity.

Does HIPAA require AI explainability?

HIPAA itself does not impose a general explainability obligation. The Privacy Rule and Security Rule are silent on model interpretability. The functional explainability obligations come from adjacent regimes: Section 1557 of the Affordable Care Act, where OCR's January 2025 guidance requires covered entities to monitor patient-care decision-support tools for discriminatory output; FDA's December 2024 final PCCP guidance for AI-enabled SaMD; and state AI laws such as Colorado SB 24-205. The HIPAA contribution is the audit-controls requirement at § 164.312(b), which requires the activity record on which any explainability claim has to rest.

What does minimum necessary mean for an LLM that processes a patient record?

§ 164.502(b)(1) requires reasonable efforts to limit PHI to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request. Read against an LLM, the rule binds three engineering decisions: which fields of the record enter the prompt; whether identifiers are removed before the model processes the record; and whether the prompt is logged with or without those identifiers. The exceptions at § 164.502(b)(2) include disclosures to a healthcare provider for treatment, but a third-party LLM API is not a healthcare provider for treatment under § 164.501. The treatment exception does not absorb the foundation-model call.

Can a covered entity use a foundation model without a BAA?

Not lawfully if PHI enters the model. The functional test under § 160.103 is whether the vendor creates, receives, maintains, or transmits PHI on behalf of the covered entity. A foundation-model API that processes a prompt containing PHI satisfies the test. § 164.502(e)(1) prohibits a covered entity from disclosing PHI to a business associate without satisfactory assurances under § 164.504(e), which the BAA documents. A covered entity using a foundation model without a BAA, where the model receives PHI, is in immediate violation of the Privacy Rule, independent of whether a breach occurs.

Does the FDA's PCCP guidance apply to my AI?

The FDA's December 2024 final PCCP guidance applies to AI-enabled device software functions that meet the FDA's definition of a medical device under section 201(h) of the Federal Food, Drug, and Cosmetic Act. An AI agent that triages patients, recommends treatment, or makes diagnostic predictions is, on most readings, a Software as a Medical Device. An AI agent used purely for administrative scheduling, claims processing, or revenue-cycle management is not. The cleavage runs through whether the system is intended for diagnosis, treatment, prevention, cure, or mitigation of disease. Where the FDA path applies, the PCCP framework allows the manufacturer to specify in advance which model modifications can be made without a new marketing submission, provided the modifications are described, the modification protocol is documented, and an impact assessment is supplied.

What is OCR's position on AI in HIPAA-covered settings as of 2026?

OCR has been guidance-light on AI in HIPAA-covered settings as a standalone topic. The operative 2024-2026 OCR signals are three. First, the January 6, 2025 HIPAA Security Rule NPRM, which proposes to remove the required-versus-addressable distinction, mandates encryption at rest and in transit, and adds explicit AI-relevant risk-analysis expectations. Second, the OCR Dear Colleague letter on Section 1557 published January 2025, which extends nondiscrimination obligations to patient-care decision-support tools including AI from the May 1, 2025 effective date. Third, the active enforcement program: 2025 saw multiple multi-million-dollar HIPAA settlements with risk-analysis failures at the center, a pattern that reads forward to AI deployments. AI-specific HIPAA enforcement actions naming AI/ML by name remain sparse as of May 2026.

How does HIPAA interact with state AI laws (Colorado AI Act, NYC LL 144)?

HIPAA preempts contrary state law on the protection of individually identifiable health information under 45 CFR § 160.203, but does not preempt state law that is more stringent. Colorado SB 24-205 (the Colorado AI Act, effective February 2026) imposes a duty of reasonable care to protect consumers from algorithmic discrimination and applies to deployers of high-risk AI systems including healthcare-adjacent uses. NYC Local Law 144 (effective July 2023) requires bias audits of automated employment decision tools, including those used in healthcare hiring. A healthcare AI agent that touches both PHI and a Colorado consumer must meet HIPAA, Section 1557, and the Colorado AI Act simultaneously. The artefact that satisfies all three is the same per-decision evidence record.

What is the worst-case OCR penalty for an AI-driven HIPAA breach?

HIPAA's civil-money-penalty structure under 42 USC § 1320d-5, as amended by HITECH and adjusted annually for inflation, is tiered by culpability. The four tiers run from no knowledge through reasonable cause, willful neglect corrected, and willful neglect uncorrected, with the highest tier subject to a per-violation cap that has been adjusted annually since the 2013 Omnibus Rule. Annual aggregate caps per identical violation reach into the millions of dollars under current adjusted figures. A breach affecting 500 or more individuals also triggers media notification under § 164.406 and HHS Secretary notification under § 164.408 within 60 days. AI-driven breaches that affect large patient populations through systemic prompt-logging failures or unredacted training data are the high-exposure pattern.

15 · READ THE SOURCE

Read the source directly.

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.

HIPAA read against AI agents.