HIPAA-compliant AI without the guesswork

Understanding HIPAA for AI systems

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) establishes national standards for protecting sensitive patient health information. While HIPAA predates modern AI by decades, its requirements apply fully to AI systems that process, store, or transmit Protected Health Information (PHI). Every healthcare AI deployment therefore has to work out how HIPAA’s Privacy Rule, Security Rule, and Breach Notification Rule land on it.

The three HIPAA rules

The Privacy Rule (45 CFR Part 164, Subparts A and E) establishes standards for who may access PHI and under what circumstances. For AI systems, the Privacy Rule governs:

• What patient information can be used to train AI models
• When patient authorization is required for AI use cases
• Minimum necessary standards for AI access to PHI
• Patient rights to access, amend, and receive accounting of disclosures

The Security Rule (45 CFR Part 164, Subparts A and C) requires covered entities and business associates to implement administrative, physical, and technical safeguards to protect electronic PHI (ePHI). For AI systems, the Security Rule governs:

• Encryption requirements for PHI in AI pipelines
• Access controls for AI system users and administrators
• Audit logging of AI inference activity
• Integrity controls ensuring PHI is not improperly altered
• Transmission security for API calls to AI services

The Breach Notification Rule (45 CFR Part 164, Subpart D) requires notification to affected individuals, HHS, and in some cases media outlets when unsecured PHI is breached. For AI systems, this includes:

• Unauthorized access to training datasets containing PHI
• Disclosure of PHI through AI model outputs or memorization
• Security incidents affecting AI infrastructure
• Vendor breaches involving PHI processed by AI systems

Covered entities vs. business associates

HIPAA distinguishes between Covered Entities (healthcare providers, health plans, and healthcare clearinghouses that transmit health information electronically) and Business Associates (entities that perform functions on behalf of covered entities involving PHI access).

An AI vendor is a Business Associate when it creates, receives, maintains, or transmits PHI on behalf of a covered entity for a covered function or activity. Status depends on the parties’ roles and the facts; when the vendor is a Business Associate, it must:

• Sign a Business Associate Agreement (BAA) with the covered entity
• Comply directly with applicable Security Rule requirements
• Report security incidents and breaches to the covered entity
• Ensure any subcontractors (sub-Business Associates) also comply

Protected health information in AI systems

Everything else in this guide depends on where the PHI boundary falls. Protected Health Information includes any individually identifiable health information that is created, received, maintained, or transmitted by a covered entity or business associate.

The 18 HIPAA identifiers

HIPAA’s Safe Harbor de-identification method (45 CFR 164.514(b)(2)) specifies 18 types of identifiers that must be removed to consider data de-identified:

PHI in AI training data

Using PHI to train AI models requires careful consideration of HIPAA requirements. There are three primary approaches:

1. De-identification: Remove all 18 identifiers per Safe Harbor method, or use Expert Determination (45 CFR 164.514(b)(1)) where a qualified statistical expert certifies that re-identification risk is very small. De-identified data is no longer PHI and is not subject to HIPAA.

2. Authorization: Obtain individual patient authorization to use their PHI for AI training. This is rarely practical at scale but may be appropriate for specialized research use cases.

3. Healthcare Operations: Under 45 CFR 164.506, covered entities may use PHI for healthcare operations without patient authorization. Quality improvement, developing clinical guidelines, and training algorithms that improve care quality may qualify. However, sharing PHI with external AI vendors for training typically requires a BAA and may have additional restrictions.

PHI in AI prompts and outputs

Beyond training data, PHI commonly enters AI systems through:

• User prompts: Clinicians entering patient information for clinical decision support, documentation, or coding assistance
• System context: Automated systems that provide patient records as context for AI analysis
• AI outputs: Generated text, predictions, or recommendations that may contain or derive from PHI
• Logging: API logs, debugging information, and audit trails that capture PHI in transit

Each of these PHI touchpoints must be protected with appropriate Security Rule safeguards.

Business Associate Agreements for AI

The Business Associate Agreement (BAA) is the legal foundation of HIPAA compliant AI. When an AI vendor will receive, create, maintain, or transmit PHI on behalf of a covered entity, they become a Business Associate and a BAA is mandatory.

Required BAA provisions

Under 45 CFR 164.504(e), a BAA must include provisions that:

• Establish permitted and required uses and disclosures of PHI
• Require the Business Associate to use appropriate safeguards and comply with the Security Rule
• Require reporting of security incidents and breaches
• Ensure any subcontractors agree to the same restrictions
• Make PHI available for patient access and amendment requests
• Make internal practices available to HHS for compliance review
• Return or destroy PHI at termination
• Authorize termination if the Business Associate violates the agreement

AI-specific BAA considerations

Standard BAA templates may not adequately address AI-specific concerns. When negotiating BAAs with AI vendors, ensure coverage of:

BAA scope and product diligence

BAA availability is not a stable vendor-wide attribute. Scope can change by product, account tier, region, feature, subprocessor, and contract. Instead of publishing a frozen vendor matrix, verify the current service terms and executed documents for the exact deployment.

• Confirm the relationship: determine whether each party is acting as a covered entity, business associate, subcontractor, or in another capacity for the specific activity.
• Match the product: verify that the executed BAA and service terms name or clearly encompass the exact AI service and configuration.
• Map the chain: identify model, hosting, speech, logging, support, and analytics subprocessors that can create, receive, maintain, or transmit PHI.
• Re-check at change: repeat the review when the model, feature, region, data-use term, subprocessor, or account tier changes.

Security Rule requirements for AI systems

The HIPAA Security Rule (45 CFR Part 164, Subpart C) requires covered entities and business associates to implement safeguards ensuring the confidentiality, integrity, and availability of electronic PHI. For AI systems, these requirements translate to specific technical and organizational controls.

Administrative safeguards (§164.308)

Administrative safeguards are policies and procedures governing AI system deployment:

• Risk Analysis (§164.308(a)(1)(ii)(A)): Conduct thorough risk analysis of AI systems, including data flows, access patterns, and potential threats. Document the risks that are specific to AI: model extraction, prompt injection, and training-data exposure.
• Risk Management (§164.308(a)(1)(ii)(B)): Implement measures to reduce identified risks to reasonable levels. For AI, this includes input validation, output filtering, and monitoring for anomalous behavior.
• Workforce Training (§164.308(a)(5)): Train staff on AI-specific HIPAA requirements: what can and cannot be entered into AI prompts, how to handle AI outputs containing PHI, and how to report an incident.
• Contingency Planning (§164.308(a)(7)): Include AI systems in disaster recovery and business continuity plans. Consider AI service outages, vendor failures, and data recovery procedures.

Physical safeguards (§164.310)

Physical safeguards protect the physical infrastructure where AI systems operate:

• Facility Access Controls (§164.310(a)): For on-premise AI deployments, limit physical access to servers and storage. For cloud deployments, verify vendor’s physical security controls.
• Workstation Security (§164.310(c)): Protect workstations used to access AI systems. Consider screen privacy, automatic lockout, and restrictions on copying AI outputs containing PHI.
• Device and Media Controls (§164.310(d)): Secure disposal of hardware that processed PHI through AI systems, including GPUs and storage devices.

Technical safeguards (§164.312)

Technical safeguards are the security technologies protecting AI systems and PHI:

Access controls (§164.312(a))

• Unique User Identification: Each AI system user must have their own credentials rather than a shared account.
• Emergency Access Procedures: Document how to access AI systems in emergencies while maintaining accountability.
• Automatic Logoff: AI interfaces must timeout after inactivity periods appropriate to the clinical environment.
• Encryption and Decryption: Implement encryption for PHI stored in AI system databases, caches, and logs.

Audit controls (§164.312(b))

Implement mechanisms to record and examine AI system activity. This matters more for AI than for most systems, and it is where implementations most often fall short. The dedicated section below covers it.

Integrity controls (§164.312(c))

• Data Integrity: Protect PHI from improper alteration or destruction. Ensure AI outputs don’t corrupt source records.
• Authentication: Verify that PHI received from AI systems has not been altered in transit.

Transmission security (§164.312(e))

• Encryption: All API calls to AI services must use TLS 1.2 or higher. Verify certificate validation and reject downgrade attacks.
• Integrity Controls: Implement message authentication to detect tampering with PHI in transit.

Encryption standards

HIPAA does not prescribe one cipher suite for every system. Select and document reasonable, appropriate safeguards from the deployment’s risk analysis, including the data path, key custody, endpoints, and failure modes:

Audit logging for AI systems: the compliance gap

The Security Rule requires hardware, software, or procedural mechanisms that record and examine activity in information systems that contain or use ePHI (§164.312(b)). The rule is risk-based: it does not prescribe one universal AI event schema or require every prompt and output to be copied into a log.

The AI logging problem

For an AI workflow, determine which events are necessary to investigate access, operation, control execution, and incidents while minimizing additional PHI. Depending on the system and purpose, that may include:

• Identity and authorization: the user or service that initiated the action, and the relevant access context
• Time and workflow: timestamps, request or session identifiers, and the in-scope application path
• System configuration: the model or service version and material control configuration, when available
• Control and response events: reported allow, block, escalation, override, error, and downstream disposition events
• Data-minimizing references: identifiers, hashes, classifications, or other metadata sufficient for the documented oversight purpose

Capturing prompt or output content can sometimes help an investigation, but it can also duplicate sensitive data and expand the PHI footprint. Make that a documented, system-specific risk decision. No log by itself proves HIPAA compliance or that a control was effective.

HIPAA log retention requirements

HIPAA requires specified written or electronic documentation to be retained for six years from creation or the date it was last in effect (including required policies, procedures, and documented actions or assessments). It does not categorically impose a six-year retention period on every raw application or AI log.

• Policies and procedures governing AI use
• Risk assessments including AI systems
• Training records for staff using AI with PHI
• BAAs with AI vendors

Set log retention separately from a documented legal, security, operational, and contractual analysis. Where logs contain PHI, balance investigation and oversight needs against data minimization, access, disposal, and breach exposure.

Implementing compliant AI logging

Common HIPAA violations with AI

The same handful of patterns turns up again and again in healthcare AI deployments, and each one is far cheaper to catch in review than in a breach notification:

1. Consumer AI tools with PHI

Unapproved use of an AI service can expose PHI outside the organization’s authorized workflow. Examples include:

• Pasting clinical notes into ChatGPT to summarize patient encounters
• Asking Claude to draft referral letters containing patient details
• Using AI to translate patient communications
• Getting clinical decision support from consumer AI tools

Why it creates risk: Sending PHI to a service without a permitted basis, a BAA where required, and approved safeguards can be an impermissible use or disclosure. The answer depends on the exact product, contract, configuration, data flow, and purpose; brand-level labels are not a substitute for that review.

2. Missing or inadequate BAAs

Organizations assume that because a vendor is “healthcare-focused” or “enterprise-grade,” they have automatic HIPAA coverage. Common gaps:

• Using AI services without any BAA in place
• BAA that covers cloud infrastructure but not AI-specific services
• BAA with the parent company that doesn’t extend to AI product subsidiaries
• Outdated BAA that predates AI service offerings

3. Inadequate logging and accountability

Deploying an AI workflow without risk-appropriate audit controls for the information system that contains or uses ePHI:

• No ability to record or examine relevant access and security activity
• Missing user, service, workflow, or material control-event context needed for investigation
• Logs stored without a documented retention, access, integrity, or disposal basis
• No reliable process to retrieve the approved records during an audit or incident

4. Shadow AI deployments

Individual departments or clinicians deploying AI tools without IT or compliance review:

• Radiology using AI diagnostic tools without security assessment
• Clinical research teams using LLMs to analyze patient data
• Administrative staff using AI for medical coding or billing
• Telehealth platforms adding AI features without compliance review

5. Training data exposure

Improper handling of PHI in AI model training:

• Training on PHI without proper de-identification
• Sharing PHI with AI vendors for model training without authorization
• Model memorization of PHI that can be extracted through prompting
• Failure to assess re-identification risk in training datasets

Case study: OCR settlements relevant to AI deployments

Architectural patterns for HIPAA-compliant AI

There are several approaches to using AI with PHI while maintaining HIPAA compliance. Each has trade-offs in complexity, cost, capability, and risk profile.

Pattern 1: enterprise AI with BAA

One pattern is a contracted enterprise service whose exact product, account, configuration, and data path are covered by an executed BAA where required. A BAA is only one part of the deployment review; it does not make the architecture compliant by itself.

Pattern 2: PHI redaction / de-identification proxy

Deploy a proxy layer that attempts to strip PHI before sending a payload to an external AI service, then re-inserts selected values in the response. Whether the downstream payload is no longer PHI depends on the completeness of redaction, contextual identifiability, retained mappings, and the full data path.

Learn more in our technical deep-dive: How We Used AI on Patient Data Without a BAA.

Pattern 3: on-premise / self-hosted AI

Deploy AI models within your own infrastructure using open-source models (Llama, Mistral) or licensed on-premise solutions. This can keep PHI inside a defined environment when storage, telemetry, support, update, and network-egress paths are configured accordingly.

Pattern 4: hybrid architecture

Combine approaches based on use case sensitivity. Use enterprise AI with BAA for general clinical workflows, add de-identification for highly sensitive cases, and deploy on-premise for research and model development.

Evaluating AI vendors for HIPAA compliance

When evaluating AI vendors for healthcare use, a systematic assessment can help determine whether a vendor can support the organization’s intended deployment and applicable obligations.

HIPAA AI vendor evaluation checklist

OCR enforcement trends and AI

The Office for Civil Rights (OCR) within HHS enforces HIPAA. Reading OCR’s enforcement signal correctly helps healthcare teams focus compliance work where it actually matters.

Selected OCR enforcement patterns reviewed Aug 26, 2026

• Risk analysis and risk management. OCR’s enforcement materials repeatedly emphasize accurate, thorough assessment of potential risks and vulnerabilities and reasonable action in response.
• Security incidents. Ransomware, phishing, unauthorized access, and system vulnerabilities remain relevant to any AI workflow that contains or uses ePHI.
• Business-associate scope. Identify the exact legal entities, services, permitted uses, subcontractors, and responsibilities rather than treating a vendor label as sufficient.
• Access and audit controls. Authentication, authorization, system activity review, and incident retrieval should reflect the actual data path and risk analysis.

HIPAA Security Rule NPRM (Jan 2025): current status

HHS published the HIPAA Security Rule Notice of Proposed Rulemaking on Jan 6, 2025. It would add requirements including technology-asset inventories, encryption, multi-factor authentication, regular testing, and written incident-response planning. As of Aug 26, 2026, HHS still lists this as a proposed rule/NPRM; it is not a final rule. HHS states that the current Security Rule remains in effect while rulemaking continues. Treat the proposal as a planning input, not as a current legal requirement, and confirm obligations with counsel.^{[HHS OCR]}

Technology-neutral HIPAA duties apply to AI

HHS’s current Business Associates guidance expressly gives a third-party AI chatbot used to schedule appointments as an example of a service that may be a business associate, depending on the facts. The underlying duties remain technology-neutral: determine roles and permitted uses, complete the required risk analysis, execute a BAA where required, apply reasonable and appropriate safeguards, train the workforce for its functions, and investigate incidents. ^[HHS]

ASTP / ONC HTI rules and predictive DSI

The HTI-1 final rule (Dec 2023) introduced the certification criterion at 170.315(b)(11) for predictive Decision Support Interventions (predictive DSIs): 13 source attributes for evidence-based DSIs and 31 for predictive DSIs, covering intended use, target population, training data, validation, known risks, and more. Compliance deadline for certified Health IT Modules was Jan 1, 2025.

ASTP/ONC later proposed changes to the DSI criterion through HTI-5. Because certification requirements can change through rulemaking, confirm the operative criterion and effective dates in the current ASTP/ONC materials before relying on this section for a procurement or compliance decision.

Penalty context

HIPAA civil penalties depend on the provision, facts, culpability tier, correction, and annual inflation adjustments; criminal and state-law exposure may also apply. Do not rely on a frozen penalty table for a live response. Use the current HHS enforcement materials and counsel for the applicable period and facts. ^[HHS]

Beyond HIPAA: emerging AI regulations

HIPAA is only one part of the legal and procurement context. As of Aug 26, 2026, several adjacent regimes may also shape how a healthcare AI system is bought, deployed, and reviewed.

California AI in healthcare: in force now

AB 3030 (effective Jan 1, 2025) requires specified patient-facing communications generated by generative AI to include an AI disclosure and instructions for contacting a human provider. The statutory exception turns on the communication being read and reviewed by a licensed or certified healthcare provider, not merely any human. Enforcement follows the existing mechanisms for the regulated facility, clinic, or professional; the act does not state a universal $25,000-per-violation penalty.

SB 1120 (effective Jan 1, 2025) places function-specific limits on algorithmic tools in utilization review and preserves clinical judgment for medical-necessity decisions. Regulators may inspect compliance under their existing authority, but the statute should not be reduced to a generic claim that DMHC audits “AI transparency.” The Medical Board of California’s GenAI Notification page provides separate physician-facing guidance.

FDA AI/ML medical devices and PCCPs

FDA issued final guidance tailored to PCCPs for AI-enabled device software functions on Aug 18, 2025. It recommends that a PCCP describe planned modifications, the methods for developing, validating, and implementing them, and an impact assessment. FDA reviews the PCCP as part of a 510(k), De Novo, or PMA submission. The guidance contains nonbinding recommendations; it did not create a separate implementation deadline.^[FDA]

EU AI Act: high-risk for clinical AI

The EU AI Act classifies specified healthcare uses as high-risk under Annex III and treats some AI embedded in regulated products under Annex I. The AI Omnibus entered into force on July 27, 2026: the relevant Annex III high-risk rules apply from Dec 2, 2027, while the relevant Annex I product-embedded rules apply from Aug 2, 2028. Classification remains use-case-specific; not every healthcare AI system is high-risk. See the ambient-scribe high-risk classification guide and the European Commission update.

Colorado AI Act

Colorado repealed and replaced its 2024 AI Act before the earlier framework took effect. SB 26-189 creates a narrower ADMT transparency regime with substantive compliance beginning January 1, 2027. Whether a healthcare workflow is covered turns on the statutory ADMT and consequential-decision definitions; the current duties focus on notices, disclosures, correction, meaningful human review, and records rather than the repealed reasonable-care and impact-assessment regime. See the current Colorado guide and Attorney General rulemaking.

Joint Commission RUAIH certification

On June 1, 2026, Joint Commission launched its voluntary Responsible Use of AI in Healthcare (RUAIH) certification for U.S. healthcare organizations and health systems. RUAIH evaluates organization-level governance, safeguards, monitoring, data management, and education. It does not validate or certify individual AI products or tools. Applicants do not need to be Joint Commission-accredited. This is a voluntary institutional certification, not a product endorsement or a general legal requirement.^{[Joint Commission]}

State consumer-protection enforcement: Pieces Technologies

In September 2024 the Texas Attorney General resolved allegations that Pieces Technologies made misleading statements about product accuracy. The company denied wrongdoing and agreed to specified disclosures and documentation duties under an assurance whose obligations terminate five years after its effective date. This was a Texas consumer-protection matter, not an OCR HIPAA case, and it does not predict how another regulator or court would treat different facts.

Insurance: the hard constraint

Effective January 2026, Verisk/ISO Core Lines released endorsement forms CG 40 47 and CG 40 48 addressing specified generative-AI exposures in commercial general liability. Carrier use and the effect on a particular policy vary. Products associated publicly with Munich Re and Armilla show that AI-specific risk transfer is developing, but public materials do not establish that coverage requires Glacis-style attestation or that operational evidence changes eligibility, wording, or price. Treat runtime evidence as a proposed diligence input; coverage remains the insurer’s decision.

FTC enforcement

The FTC can apply Section 5 to deceptive or unfair practices, including certain misleading capability claims or inadequate data-security practices. Whether the statute applies, and whether conduct is unfair or deceptive, is fact-specific; do not infer a healthcare-AI enforcement priority without a current authoritative source.

HIPAA-compliant AI implementation roadmap

Whether you’re a healthcare organization deploying AI or an AI vendor entering the healthcare market, these are illustrative review workstreams, not a fixed path, timetable, or guarantee of compliance. Sequence and depth should follow the organization’s role, risk analysis, data flows, systems, and applicable requirements.

Illustrative workstreams

HIPAA AI review sequence

1

AI system inventory

Catalog all AI systems in use or planned for deployment. Identify which systems will process PHI, what PHI elements they access, and what the data flows look like. Include shadow AI, meaning the tools staff may already be using without formal approval.

2

Risk assessment

Conduct HIPAA risk analysis for each AI system. Document threats specific to AI: prompt injection, model extraction, training data leakage, output disclosure. Assess current controls and identify gaps.

3

Vendor assessment and BAAs

Evaluate the exact services and data flows. Determine each party’s role and execute BAAs where the HIPAA Rules require them. Confirm permitted uses, covered services, subcontractors, retention, incident duties, and the security-responsibility split.

4

Technical controls

Implement the reasonable and appropriate safeguards supported by the risk analysis. Configure access and audit controls, integrity and transmission protection, monitoring, and incident procedures for the actual system and data path.

5

Policies and training

Document approved services and uses, escalation and incident procedures, and workforce responsibilities. Train personnel for their functions and retain the documentation required by the HIPAA Rules.

6

Monitoring and review

Review relevant system activity, security events, vendor or configuration changes, and incidents on the cadence established by the risk-management process. Update the risk analysis and safeguards when operational or environmental changes warrant it.

Evidence alongside documentation: Preserve signed records of what configured control paths reported, together with scope, exclusions, and other operational evidence. Cryptographic integrity does not by itself prove control effectiveness, complete coverage, safety, or HIPAA compliance.

Frequently asked questions

Key takeaways

For more on building the evidence infrastructure that supports both HIPAA compliance and emerging AI regulations, explore our other resources:

• How We Used AI on Patient Data Without a BAA
• Colorado AI Act Compliance Guide
• NIST AI Risk Management Framework Guide
• ISO 42001 AI Management System Guide