> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/reference/governance-and-frameworks/g.9-hipaa-controls-for-ai-systems-handling-phi.md).

# G.9 HIPAA controls for AI systems handling PHI

HIPAA security and privacy controls for AI systems handling PHI, including BAAs, access, data flows, de-identification, evidence, and incident response.

*Last reviewed: August 18, 2026*

{% hint style="info" %}
HIPAA does not create a separate approval path for AI products. When a covered entity or business associate uses an AI service to create, receive, maintain, or transmit protected health information, the existing Privacy, Security, and Breach Notification Rules follow that data flow.
{% endhint %}

An AI vendor's claim that a product is "HIPAA compliant" is not enough. HHS does not recognize business-associate self-certification or third-party HIPAA certification. The regulated organization still has to determine its role, confirm that the use or disclosure is permitted, execute the right contract, assess the risks, configure safeguards, and keep evidence.

This page is an implementation guide for security teams. Privacy and legal counsel should confirm whether HIPAA applies to the organization, the information, and the specific use.

## Start with scope

Answer these questions for each AI workflow before allowing PHI.

| Question                                                                                       | Why it matters                                                                                                                   | Evidence to keep                                         |
| ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- |
| Is the organization a covered entity, business associate, or business-associate subcontractor? | HIPAA does not apply to every employer, consumer health app, or organization that handles health-related data.                   | Written role analysis and responsible privacy owner      |
| Does the workflow create, receive, maintain, or transmit PHI?                                  | Prompts, uploaded files, retrieved records, transcripts, outputs, embeddings, support logs, and backups can all carry PHI.       | End-to-end data-flow diagram and data inventory          |
| Is the information electronic?                                                                 | The Security Rule applies to ePHI. The Privacy and Breach Notification Rules also cover PHI in other forms.                      | Data-format and storage inventory                        |
| Is the use or disclosure permitted?                                                            | Treatment, payment, health care operations, authorization, and other Privacy Rule bases have different conditions.               | Approved purpose and legal basis                         |
| Is the AI provider acting on behalf of a covered entity or business associate?                 | A provider that creates, receives, maintains, or transmits PHI on that basis is generally a business associate or subcontractor. | Vendor-role decision and signed BAA where required       |
| Has the information been de-identified under a HIPAA method?                                   | Removing a name or replacing it with a token does not by itself make data de-identified.                                         | Safe Harbor checklist or documented Expert Determination |
| Will AI output become part of a designated record set or another official record?              | Access, amendment, accounting, retention, and integrity obligations may follow the resulting record.                             | Records-management decision and system of record         |

## Privacy Rule controls

Define the permitted purpose before selecting a tool. Then limit the workflow to that purpose.

For uses and disclosures subject to the minimum necessary standard:

* Send only the fields needed for the approved task.
* Remove unrelated notes, identifiers, attachments, and historical records before submission.
* Restrict retrieval and connectors to the approved patient population and record types.
* Keep PHI out of personal AI accounts, consumer tiers, and unapproved browser extensions.
* Prevent prompts, outputs, and feedback from being reused for model training or unrelated product improvement unless the use is specifically permitted.
* Apply the same restrictions to transcripts, telemetry, human review, and support access.

The minimum necessary standard has exceptions. It generally does not apply to disclosures to or requests by a health care provider for treatment. Do not turn data minimization into an absolute legal claim. Record the applicable purpose and exception instead.

## Business associate and contract controls

The relationship and data flow determine whether an AI provider is a business associate. Buying software alone does not create that relationship when the vendor has no access to PHI. A hosted AI service that processes or stores PHI on behalf of a covered entity or business associate will usually fall on the other side of that line.

Before the provider receives PHI, confirm that the BAA applies to the exact product, account, region, features, and support model in use. The contract should address:

* Permitted and required uses and disclosures.
* Security Rule safeguards for ePHI.
* Security-incident and breach reporting.
* Subcontractors and downstream model or infrastructure providers.
* Return or destruction of PHI when the service ends, where feasible.
* Support access, human review, and administrative access.
* Retention, deletion, backups, and recovery.
* Availability and access to ePHI.
* Use of customer data for training, evaluation, abuse monitoring, or product improvement.

Encryption, zero-data-retention settings, and a vendor's inability to read the data do not replace the BAA analysis. HHS states that a cloud provider maintaining encrypted ePHI can still be a business associate even when it lacks the decryption key.

## Security Rule controls for AI

Include the full AI data path in the HIPAA risk analysis. Do not stop at the visible chat window or API endpoint.

Inventory and assess:

* Prompts, files, images, audio, and structured records.
* Model responses and generated documents.
* Retrieval indexes, embeddings, vector stores, and caches.
* Conversation history, audit logs, safety logs, and support records.
* Connectors to EHR, claims, scheduling, collaboration, and storage systems.
* Model providers, hosting providers, subprocessors, and human reviewers.
* Backups, disaster recovery, exports, and deletion queues.
* Administrative tools, service accounts, API keys, and machine identities.

Map the current Security Rule to concrete controls:

| Security Rule area                             | AI implementation                                                                                                                    | Evidence                                             |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------- |
| Risk analysis and risk management              | Assess every system that creates, receives, maintains, or transmits ePHI, including vendor and connector dependencies.               | Risk assessment, treatment plan, accepted exceptions |
| Assigned responsibility and workforce controls | Name the security official, privacy owner, platform owner, and trained users.                                                        | RACI, training records, access approvals             |
| Access management                              | Use managed identity, role-based access, least privilege, and rapid deprovisioning.                                                  | SSO settings, role exports, access reviews           |
| Audit controls                                 | Record and examine access, configuration changes, exports, connector activity, and administrative actions.                           | Audit-log samples, SIEM rules, retention settings    |
| Integrity                                      | Protect ePHI from unauthorized alteration and verify AI-generated information before it changes a clinical or administrative record. | Validation tests, human-review rules, change history |
| Person or entity authentication                | Authenticate users, services, connectors, and workloads before they reach ePHI.                                                      | MFA policy, workload identity, key inventory         |
| Transmission security                          | Protect ePHI moving between users, AI services, connectors, and downstream systems.                                                  | Encryption configuration and network diagrams        |
| Security incidents                             | Detect, contain, investigate, mitigate, and document suspected or known incidents.                                                   | Runbook, exercises, incident records                 |
| Contingency planning                           | Preserve access to ePHI and critical operations during provider outages, corruption, or ransomware.                                  | Backup tests, recovery plan, exit procedure          |
| Evaluation and documentation                   | Reassess after model, feature, vendor, architecture, or threat changes and retain required records.                                  | Review history, decision log, current procedures     |

An "addressable" implementation specification is not optional. If a regulated entity decides that a specification is not reasonable and appropriate, it must document that decision and implement an equivalent measure when reasonable and appropriate.

## De-identification before AI use

The Privacy Rule recognizes two methods for de-identifying PHI:

* Expert Determination: a qualified expert determines and documents that the risk of identification is very small.
* Safe Harbor: specified identifiers are removed and the covered entity has no actual knowledge that the remaining information could identify a person.

Do not treat masking, tokenization, pseudonymization, or synthetic-data generation as automatic de-identification. Dates, free text, rare diagnoses, locations, images, and combinations of attributes can identify a person. Keep the determination with the data set, the intended recipient, and the approved use.

When only properly de-identified information reaches a provider, the provider is not a business associate solely because it maintains that data. Other privacy, contractual, research, consumer-protection, and security duties may still apply.

## Incident and breach response

Route suspected AI disclosures into the existing HIPAA incident process. Examples include PHI entered into an unapproved AI account, an overbroad connector, support access outside the BAA, output shown to the wrong user, or PHI retained after the approved period.

The response should:

1. Stop further disclosure without destroying evidence.
2. Preserve prompts, outputs, access logs, configuration, account details, and vendor correspondence.
3. Notify the privacy, security, legal, and incident-response owners.
4. Determine what PHI was involved, who received it, whether it was acquired or viewed, and what mitigation occurred.
5. Document the breach risk assessment or the reason an exception applies.
6. Meet contractual and regulatory notification deadlines.

An impermissible use or disclosure is presumed to be a breach unless the regulated entity demonstrates a low probability that PHI was compromised or an exception applies. A business associate must notify the covered entity without unreasonable delay and no later than 60 days after discovery. Contracts should set a much shorter operational deadline so the covered entity has time to investigate and notify affected people.

For breaches of unsecured PHI, individual notices are due without unreasonable delay and no later than 60 days after discovery. Notice to HHS is due on the same timeline when 500 or more individuals are affected. Breaches affecting fewer than 500 individuals may be reported to HHS annually, no later than 60 days after the end of the calendar year in which they were discovered.

## Current Security Rule and the proposed update

HHS issued proposed Security Rule modifications on December 27, 2024. HHS still describes those changes as proposed and states that the current Security Rule remains in effect while rulemaking continues.

Track the proposal, but do not present its requirements as current law. Build controls that can absorb stricter requirements without confusing a proposed safeguard with a binding one.

## Common HIPAA controls for AI systems handling PHI security failures

* A vendor has a BAA, but it does not cover the product tier or feature that handles PHI.
* The team approves the model provider but misses subprocessors, retrieval stores, logs, and support systems.
* Employees paste PHI into personal AI accounts because the enterprise tool is slower.
* Zero retention is treated as a substitute for permitted-use analysis and a BAA.
* The risk analysis covers confidentiality but ignores output integrity and service availability.
* Audit logs exist but do not identify the user, connector, patient context, export, or administrative change.
* Names are removed and the remaining free text is incorrectly labeled de-identified.
* The incident plan waits for the vendor's 60-day outer deadline.
* A model or feature changes materially, but the team does not repeat the risk assessment.

## HIPAA controls for AI systems handling PHI security controls checklist

* Confirm the organization's HIPAA role and the workflow's permitted purpose.
* Map every place PHI and ePHI enters, moves, persists, or can be viewed.
* Approve the exact AI product, account, region, features, and subprocessors.
* Execute a BAA before a business associate receives PHI.
* Limit data to the approved purpose and apply minimum necessary where required.
* Block personal accounts and unapproved AI tools from receiving PHI.
* Enforce managed identity, least privilege, connector scoping, and credential controls.
* Configure audit, retention, deletion, encryption, backup, and recovery.
* Validate output before it changes an official record or drives consequential action.
* Test incident evidence collection and notification paths.
* Reassess after model, vendor, feature, data-flow, or threat changes.
* Keep the approval, risk analysis, contracts, configuration, tests, and reviews together.

## Frequently asked questions about HIPAA controls for AI systems handling PHI

### Can employees put PHI into ChatGPT, Claude, Copilot, or another AI service?

Only when the organization has approved the exact service and configuration for that purpose, the use or disclosure is permitted, the correct BAA is in place where required, and the Security Rule safeguards are operating. A BAA alone does not approve every feature or data use.

### Does a vendor's HIPAA certification prove the tool is safe to use?

No. HHS states that business associates cannot self-certify or be certified by a third party as HIPAA compliant. Security and privacy teams still need to review the contract, architecture, data flow, configuration, risks, and evidence.

### Does encryption mean the AI vendor is not a business associate?

No. HHS cloud guidance says a provider that maintains encrypted ePHI on behalf of a covered entity or business associate can still be a business associate even if it lacks the decryption key.

### Can we use de-identified data without a BAA?

If the provider receives and maintains only information de-identified under the Privacy Rule, it is not a business associate solely because it handles that information. Document the de-identification method and consider other laws and contractual duties.

### What should security own?

Security should own the technical risk analysis, access controls, logging, connector review, architecture, testing, monitoring, and incident evidence. Privacy and legal should own HIPAA role, permitted-use, minimum-necessary, BAA, de-identification, and notification decisions with the business owner.

## Applicable handbook articles

*This table applies only to a covered entity, business associate, or subcontractor using AI to create, receive, maintain, or transmit PHI or ePHI.*

HIPAA is technology-neutral. These links identify generic safeguards and AI-specific risk-analysis inputs for a workflow handling PHI or ePHI. Add surface-specific controls when the architecture and risk analysis call for them; a link does not make an implementation a standalone HIPAA requirement.

| Handbook area                            | Applicable articles                                                                                                                                                                                                                                                                                                  | Why they apply                                                                                                                           |
| ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| 1. Identity & access                     | <p>1.1 SSO & SCIM for AI platforms<br>1.2 RBAC across AI platforms<br>1.3 Tenant restrictions: blocking personal accounts<br>1.5 Agent and non-human identity<br>1.6 API keys and service accounts governance<br>1.7 Human-in-the-loop and approval policies</p>                                                     | Supports HIPAA identity, authentication, least privilege, and workforce access when the workflow handles PHI or ePHI.                    |
| 2. Connectors, extensions & supply chain | <p>2.1 Connectors and apps: the integration backbone<br>2.7 The supply-chain review workflow<br>2.10 Hosted-agent framework dependencies</p>                                                                                                                                                                         | Supports HIPAA approved vendors, business-associate review, data paths, and tool authorization when the workflow handles PHI or ePHI.    |
| 3. Runtime, sandboxing & autonomy        | <p>3.2 Approval policies and least-privilege autonomy<br>3.3 Network egress control<br>3.8 File and filesystem access controls<br>3.9 Central hosted-agent runtime hardening</p>                                                                                                                                     | Supports HIPAA technical access, integrity, transmission, availability, and audit safeguards when the workflow handles PHI or ePHI.      |
| 4. Data protection                       | <p>4.1 DLP for GenAI<br>4.2 Data classification for AI prompts and outputs<br>4.3 Data residency and regional inference<br>4.4 Retention and Zero Data Retention<br>4.5 Training opt-out and data usage<br>4.6 Cross-app data flow and live artifacts<br>4.7 Secrets and credential hygiene in prompts and tools</p> | Supports HIPAA PHI identification, minimum-necessary handling, retention, and disclosure controls when the workflow handles PHI or ePHI. |
| 5. Threats & adversarial testing         | <p>5.1 Prompt injection: the connective risk<br>5.2 Data exfiltration via tools and connectors<br>5.3 Supply chain attacks and notable CVEs<br>5.6 Incident response for AI systems<br>5.7 Threat modeling AI systems</p>                                                                                            | Supports HIPAA risk analysis, safeguard testing, and security-incident response when the workflow handles PHI or ePHI.                   |
| 6. Observability, audit & evidence       | <p>6.1 The audit gap: what you can and can't see<br>6.3 Compliance APIs by platform<br>6.5 Routing AI telemetry to your SIEM<br>6.6 Evidence by surface and investigation paths<br>6.7 Continuous review cadence</p>                                                                                                 | Supports HIPAA audit controls, activity review, and investigation evidence when the workflow handles PHI or ePHI.                        |
| 7. Rollout & operations                  | 7.4 The vendor-neutral control matrix                                                                                                                                                                                                                                                                                | Supports HIPAA risk-based approval, safeguard validation, evidence, and reassessment when the workflow handles PHI or ePHI.              |

## Further reading

The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page.

* [HHS summary of the HIPAA Security Rule](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html)
* [HHS minimum necessary guidance](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html)
* [HHS guidance on HIPAA and cloud computing](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html)
* [HHS business associate contract guidance](https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html)
* [HHS business associates FAQs](https://www.hhs.gov/hipaa/for-professionals/faq/business-associates/index.html)
* [HHS guidance on de-identification of PHI](https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html)
* [HHS HIPAA Breach Notification Rule](https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html)
* [HHS HIPAA Security Rule notice of proposed rulemaking](https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html)

## Related handbook guidance

* [Governance & Frameworks](/reference/governance-and-frameworks.md)
* [4.2 Data classification for AI prompts and outputs](/handbook/4.-data-protection-and-residency/4.2-data-classification-for-ai-prompts-and-outputs.md)
* [4.3 Data residency and regional inference](/handbook/4.-data-protection-and-residency/4.3-data-residency-and-regional-inference.md)
* [4.4 Retention and Zero Data Retention](/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention.md)
* [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/reference/governance-and-frameworks/g.9-hipaa-controls-for-ai-systems-handling-phi.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.