What HIPAA Compliance for AI Requires Your Data Governance to Document
HIPAA compliance for AI means applying the existing Privacy and Security Rules to every AI system that creates, receives, maintains or transmits protected health information. There is no separate HIPAA rule for AI, so the evidence an auditor will ask for is familiar: a risk analysis, which in practice needs an inventory of where ePHI lives, minimum necessary access, business associate agreements and audit logs. What is new is that AI creates copies of PHI that many inventories do not yet show, in training sets, retrieval indexes, prompts and model outputs.
HIPAA has no AI-specific rule, and the regulations in force do not mention artificial intelligence. AI that handles protected health information (PHI) falls under the same Privacy and Security Rules as any other system. In the preamble to its January 2025 proposed Security Rule update, HHS stated that ePHI in AI training data, prediction models and algorithm data is protected by the HIPAA Rules, and said it would expect AI software that touches ePHI to appear in a regulated entity's technology asset inventory. The update is still a proposal as of November 2026. Governance teams can prepare by documenting eight things: the AI data flows, PHI classification, minimum necessary scope per use case, BAAs with AI vendors, access rights, audit trails, lineage of training and retrieval data, and de-identification evidence.
Does HIPAA apply to AI?
HIPAA applies to AI whenever a covered entity or business associate uses it to create, receive, maintain or transmit PHI. The rules regulate the information and the organizations that hold it, whatever technology processes it. A search of the HIPAA regulations in the eCFR, 45 CFR Parts 160 and 164, returns no mention of artificial intelligence. The existing requirements simply apply to the new systems.
That is the good news and the hard part at the same time. A hospital does not need to learn a new rulebook for AI, but every obligation it already has now covers more places. A clinical note that used to live in the EHR may now also sit in a vector index, a fine-tuning data set, a prompt log at an AI vendor and a generated discharge summary. Each of those is a copy of PHI, and each one needs to be inventoried, protected and accounted for.
The questions a compliance lead hears most often map directly onto existing provisions.
| Question about AI | Where HIPAA already answers it |
|---|---|
| May we use patient data to build or run this model? | Permitted uses and disclosures in the Privacy Rule, 45 CFR 164.502(a) and 164.506 to 164.512 |
| How much patient data may the model see? | Minimum necessary standard, 164.502(b) and 164.514(d) |
| Can we send PHI to an AI vendor? | Business associate requirements, 164.502(e), 164.504(e) and 164.308(b) |
| What risks does the AI system add? | Risk analysis and risk management, 164.308(a)(1) |
| Who and what may access the data? | Information access management and access control, 164.308(a)(4) and 164.312(a) |
| Can we show what the system did? | Audit controls and activity review, 164.312(b) and 164.308(a)(1)(ii)(D) |
| Is the training data still PHI? | De-identification standard, 164.514(a) and (b) |
What changed in HIPAA rules for AI by 2026?
No HIPAA rule specific to AI has been finalized, but HHS has said how it reads the existing rules. The clearest statement is in the proposed HIPAA Security Rule update that HHS announced on December 27, 2024 and published in the Federal Register on January 6, 2025. The comment period closed on March 7, 2025.
Two passages in its preamble matter for AI.
- AI data is ePHI. HHS wrote that ePHI, including ePHI in AI training data, prediction models and algorithm data maintained by a regulated entity for covered functions, is protected by the HIPAA Rules. It also noted that training generative AI on patient data could result in impermissible uses and disclosures.
- AI belongs in the asset inventory. The proposal would require a written inventory of technology assets and a network map showing how ePHI moves through the entity's systems, including how it enters and exits them, reviewed at least every 12 months. HHS said it would expect AI software that creates, receives, maintains or transmits ePHI, or that interacts with it, including where ePHI is used to train the software, to be listed in that inventory, which feeds the risk analysis.
The status as of November 2026: the HHS page for the proposal still describes it as a proposed rule, and no final rule has been published in the Federal Register. The inventory and network map are therefore not yet explicit requirements. The current Security Rule already requires an accurate and thorough risk analysis of the risks to ePHI the entity holds, though, and it is hard to perform one for AI systems that nobody has listed. Organizations that build the inventory now are doing work the current rule implies and the proposed rule would make explicit.
An AI system that is missing from the inventory is also missing from the risk analysis. That gap exists under the current rule, whatever happens to the proposal.
How to prepare for HIPAA Security Rule changes in 2027
Prepare as if the proposal could become final at short notice, because the compliance window it proposes is short. HHS has not published a final rule or a compliance date. Under the proposal, though (status checked November 12, 2026), a final rule would take effect 60 days after publication, and regulated entities would have to comply 180 days after that, with a longer transition period only for updating business associate agreements. A final rule published in 2027 would therefore leave roughly eight months to comply. The final text may also differ from the proposal.
The HHS fact sheet lists the proposed changes, and the table below picks the ones that matter most for AI systems that touch ePHI. All deadlines and requirements in it come from the proposal, not from a final rule. The column "What it would mean for AI" is our reading of how each proposal would apply to AI systems, not HHS text.
| Proposed requirement (HHS) | What it would mean for AI (our reading) | What to prepare now |
|---|---|---|
| Technology asset inventory and network map, updated at least every 12 months and after relevant changes | Every AI tool, model, index and vendor API that touches ePHI is listed, with how ePHI enters and leaves it | Record 1 above, kept current as AI tools are added |
| Written risk analysis that reviews the inventory and network map | AI systems are assessed for their own threats and vulnerabilities, such as prompt logs at vendors or over-broad retrieval | A risk entry per AI system, linked to its inventory record |
| All implementation specifications required, with limited exceptions, and written documentation of all policies and analyses | Fewer judgment calls about which safeguards apply to an AI pilot | Written AI policies and use case approvals, not just practice |
| Encryption of ePHI at rest and in transit and multi-factor authentication, with limited exceptions | Training sets, vector stores and prompt logs holding ePHI are encrypted, and access to AI tools uses MFA | Know where those copies are stored, so they can be covered |
| Notice within 24 hours to certain regulated entities when a workforce member's access is changed or terminated | Access held by AI agents and service accounts tied to a person would need to be traceable to that person | Record 5 above, with an owner for every agent identity |
| Compliance audit at least every 12 months | AI systems that touch ePHI would be in scope of the annual audit | The eight records above, in one place, ready to show |
| Business associates verify their technical safeguards at least every 12 months, through a written expert analysis and certification | AI vendors that handle ePHI would provide an annual written verification | Record 4 above, with a date for each vendor's verification |
| Vulnerability scans at least every six months and penetration tests at least every 12 months | AI applications and their integrations are part of the testing scope | An inventory that tells the security team what to test |
Most of this preparation is useful whatever the final rule says. The current rule already requires a thorough risk analysis, business associate agreements and audit controls, and every item in the table builds on the same inventory. An organization that can list its AI systems, the PHI each one uses and who approved it is ready for the proposal and for an audit under today's rule.
What must governance document when AI uses PHI?
Governance teams should be able to produce eight records for every AI system that touches PHI. Each one maps to an existing HIPAA provision, and together they answer the questions an OCR investigator, an internal auditor or a hospital's own privacy committee may ask. Some, such as a written inventory and training data lineage, go beyond what the current rule spells out, but they are the practical way to support the risk analysis it does require.
| Record | HIPAA provision | What it shows for AI |
|---|---|---|
| 1. AI data flow inventory | 164.308(a)(1)(ii)(A) risk analysis; proposed inventory and network map | Every AI system, the PHI it uses, and where that PHI enters and leaves |
| 2. PHI classification | 160.103 definitions; 164.514 de-identification | Which sources, columns and documents feeding AI contain PHI |
| 3. Minimum necessary scope | 164.502(b), 164.514(d) | Which categories of PHI each AI use case needs, and why |
| 4. BAAs with AI vendors | 164.502(e), 164.504(e), 164.308(b) | Signed agreements covering each vendor and subcontractor that handles PHI |
| 5. Access rights | 164.308(a)(4), 164.312(a) | Which people, service accounts and agents may reach PHI |
| 6. Audit trail | 164.312(b), 164.308(a)(1)(ii)(D) | Records of what AI systems and their users did with ePHI, and who reviewed them |
| 7. Training and RAG lineage | 164.312(c)(1) integrity; risk analysis | Which data, from which source and version, went into each model or index |
| 8. De-identification evidence | 164.514(b) | Why a data set used for AI is no longer PHI |
All of this documentation has a retention period. Security Rule documentation must be kept for six years from the date it was created or last in effect, whichever is later (45 CFR 164.316(b)(2)(i)). An AI pilot that ran for three months can need evidence long after the pilot is forgotten.
1. An inventory of AI data flows
Start with a list of every AI system that touches PHI, and the path PHI takes into and out of it. The risk analysis requirement in 164.308(a)(1)(ii)(A) asks for an accurate and thorough assessment of the risks to the confidentiality, integrity and availability of ePHI the organization holds. An AI system that nobody has recorded cannot be part of that assessment.
For each system, the inventory entry should name the business owner, the vendor and model, the deployment (internal, vendor cloud, or a consumer tool used without approval), the source systems it reads, where its inputs and outputs are stored, and the data it is allowed to use. The proposed rule's network map adds a useful test: can you draw how PHI enters the system and how it leaves? Shadow AI, staff pasting notes into a consumer chatbot, is part of this picture too. The inventory is where the organization finds out which tools are in use, and the policy decides which are allowed.
2. Classification of PHI, including free text
Every source that feeds an AI system should carry a label saying whether it contains PHI. Data classification at column and document level lets a team see at a glance which inputs are PHI, which are a limited data set and which are de-identified.
Unstructured data deserves special attention. HHS de-identification guidance states that the standard makes no distinction between structured fields and free text: an identifier must be removed wherever it appears in a record, including discharge summaries and progress notes. Language models and retrieval pipelines run on exactly that kind of text, so a classification scheme that only covers database columns misses the riskiest inputs. Our guide to unstructured data governance covers how to extend classification to documents.
3. Minimum necessary for each AI use case
Each AI use case should have a written statement of which PHI it needs and why. The minimum necessary standard in 164.502(b) requires reasonable efforts to limit PHI to the minimum necessary for the intended purpose of a use, disclosure or request, and 164.514(d) requires the organization to identify who needs access to which categories of PHI.
The standard does not apply to every flow. Under 164.502(b)(2)(i), disclosures to, and requests by, a health care provider for treatment are exempt. In our reading, that exception does not cover a covered entity's own internal uses, so AI used in care would still fall under the workforce access limits of 164.514(d)(2). Confirm how this applies to a specific deployment with counsel. For AI work such as operational analytics, revenue cycle automation or model development, the standard applies in full. The practical questions are concrete. Does a readmission model need names, or only a pseudonymous key? Does a retrieval assistant for coders need the full chart, or only the encounter? Does a scheduling assistant need diagnoses at all? Writing the answers down turns a principle into something a reviewer can check.
4. Business associate agreements with AI vendors
An AI vendor that creates, receives, maintains or transmits PHI on a covered entity's behalf will usually meet the business associate definition in 45 CFR 160.103, and then needs a BAA before the first record is sent. The business associate definition in 160.103 covers anyone who creates, receives, maintains or transmits PHI for a regulated function, and names data analysis and processing among the functions.
HHS guidance on cloud computing closes a common loophole: a cloud provider that stores or processes ePHI is a business associate even if the data is encrypted and the provider has no key. The "conduit" exception covers transmission-only services, not processing.
Under 164.504(e), the agreement must, among other things, limit the vendor's uses of PHI to those the contract permits, require appropriate safeguards and compliance with the Security Rule for ePHI, require reporting of unauthorized uses and breaches, flow the same terms down to subcontractors, and require the vendor to return or destroy PHI at the end of the contract where feasible. For an AI vendor, the governance record should also answer questions the contract alone may not: which product tier and region the organization actually uses, whether prompts and outputs are retained and for how long, whether the vendor may use the data to improve its models, and which subcontractors host the model.
5. Access rights for people and software
Access to ePHI must be limited to authorized people and software programs, and AI agents are software programs. The access control standard in 164.312(a)(1) requires technical policies and procedures that allow access to ePHI only to persons or software programs that have been granted access rights. One of its required implementation specifications is a unique name or number for identifying and tracking each user.
For AI, that means each assistant, agent or pipeline should run under its own identity with its own documented permissions, not under a shared service account or the broadest account of whoever set it up. When an assistant acts on behalf of a user, the record should show whose permissions it used. Data access management and AI agent governance describe how to tie those permissions to purpose and to the classification of the data.
6. An audit trail of AI activity
The organization must be able to record and examine activity in systems that contain or use ePHI, and review those records regularly. That is the combination of the audit controls standard in 164.312(b) and the information system activity review in 164.308(a)(1)(ii)(D).
For AI, the useful audit trail has two layers. The system layer records which identity queried which data, when, and what the AI returned or did. The governance layer records the decisions behind it: who approved the use case, who granted access, for what purpose and for how long. Logs without the decisions show what happened but not whether it was allowed, and decisions without logs show what was allowed but not what happened. The review must happen regularly, and writing down its outcome is what lets the organization show that it did.
7. Lineage of training and RAG data
For every model and retrieval index, the organization should be able to say which data went into it, from which source and as of which date. HHS's statement that ePHI in training data and prediction models is protected under HIPAA makes this a practical necessity: if a patient's data must be corrected, restricted or traced after an incident, someone has to know which models and indexes contain it.
Data lineage from source tables through feature pipelines, extracts and embedding jobs to the model or index answers that question. It also helps show that the ePHI feeding a model was not improperly altered or destroyed, which is what the integrity standard in 164.312(c)(1) asks policies and procedures to protect against. Retrieval indexes need the same care as training sets, because they are refreshed more often and usually hold the original text. See data integrity and column-level lineage for the underlying practices.
8. De-identification records
When an AI project uses de-identified data, the organization should keep the evidence that it is de-identified. Data that meets the standard in 164.514(b) is no longer PHI, which is why de-identification is attractive for model development. The burden is on the organization to show it was done correctly.
- Safe Harbor requires removing all 18 listed identifiers for the patient and their relatives, employers and household members, and having no actual knowledge that the remaining data could identify anyone. The record should show how each identifier was handled, including in free text.
- Expert Determination requires a qualified expert to find that the risk of re-identification is very small and to document the methods and results. HHS sets no numerical threshold, and notes that some experts issue time-limited certifications, so the record should include the date and scope of the determination.
- A limited data set is not de-identified. It keeps dates and ZIP codes, stays PHI and may only be used for research, public health or health care operations under a data use agreement.
The PHI glossary entry lists the 18 identifiers and compares the two methods in detail.
Which HIPAA evidence comes from data governance?
Data governance supplies the inventory, classification, ownership, purpose and lineage records. Security, legal and clinical teams supply the rest. HIPAA compliance for AI is a shared effort, and it helps to be clear about which team owns which evidence.
| Evidence | Usually owned by | Typical tools |
|---|---|---|
| Inventory of data assets and AI data flows | Data governance | Data catalog, lineage |
| PHI classification of sources | Data governance with data owners | Data catalog, classification scanners |
| Use case approval and minimum necessary scope | Privacy officer with data owners | Governance workflows, access requests |
| Business associate agreements | Legal and procurement | Contract management |
| Risk analysis | Security officer | Risk register, assessment tools |
| Encryption, network security, data loss prevention | Security and IT | Security platforms, DLP |
| System audit logs and their review | Security and IT | Logging and SIEM |
| De-identification | Privacy, analytics, external experts | De-identification tools, expert reports |
| Breach notification | Privacy officer and legal | Incident response process |
The governance records are the ones that connect the others. A risk analysis needs the inventory, a BAA review needs to know which vendors receive PHI, and a log review needs to know which access was approved and why. That is why the inventory and lineage work tends to come first, and why it pays to keep it in one place rather than in a spreadsheet per project. For the broader framework, see AI governance and our post on healthcare data governance for revenue cycle and AI.
How Dawiso helps document AI data flows
Dawiso is a data governance and context platform that keeps the metadata side of this evidence in one place. It is not a HIPAA compliance tool, a data loss prevention product or a de-identification engine: it does not de-identify, block or encrypt patient data, and using it does not make an organization HIPAA compliant. What it does is record what data exists, how sensitive it is, who owns it, where it flows and who was allowed to use it. Classifications such as PII are set by people or, through the MCP server, by AI assistants that classify and label objects on a user's behalf.
- Inventory and lineage. The Dawiso Data Catalog holds metadata about sources, tables, columns, reports and data products, and Interactive Data Lineage is extracted from supported platforms, collected from tools such as dbt, parsed from SQL scripts (an option for enterprise customers after evaluation with the implementation team) or added manually.
- Classification and ownership. Each asset in a data product shows its PII and confidentiality classification, each port of a data product shows an aggregated badge with the highest classification among its assets, and owners, stewards and custodians are assigned so consumers know who to contact.
- Purpose-bound access requests. In the Data Market, a request states its use case, level of access and duration. Masked access to personal data is the default where the source supports masking, Dawiso records the grant and the reason behind it, and the underlying data platform enforces the permission on the data itself.
- AI assistants with tools scoped by role. The Dawiso MCP server lets MCP-compatible assistants search the catalog and trace lineage, with the tools available depending on the user's role.
Dawiso works with metadata rather than patient records. For sources connected through the Dawiso Integration Runtime, extraction runs inside the customer's infrastructure and exchanges metadata, not underlying data: row values and document contents are never read or transmitted, and credentials stay in the customer's network. Some features do work with data samples: through the MCP server, a user whose role allows it can attach a CSV or JSON data sample to an object and preview an object's sample rows. An organization governing PHI decides whether samples from clinical systems may be used at all.
FAQ
Does HIPAA apply to AI tools?
Do AI vendors need to sign a business associate agreement?
Is de-identified data safe to use for AI training under HIPAA?
Has the HIPAA Security Rule update been finalized?
Does the minimum necessary standard apply to AI?
Sources
This article is for general information and is not legal advice.
Regulations are cited from the Electronic Code of Federal Regulations (eCFR), the official, continuously updated edition maintained by the Office of the Federal Register.
- eCFR, 45 CFR 160.103, Definitions (protected health information, covered entity, business associate)
- eCFR, 45 CFR Part 164 Subpart C, Security Standards for the Protection of ePHI (164.308 risk analysis, activity review, information access management and business associate contracts; 164.312 access control, audit controls and integrity; 164.316 documentation retention)
- eCFR, 45 CFR 164.502, Uses and disclosures of PHI, general rules (minimum necessary and its exceptions)
- eCFR, 45 CFR 164.504, Organizational requirements (business associate contract content)
- eCFR, 45 CFR 164.514, Other requirements relating to uses and disclosures of PHI (de-identification, minimum necessary implementation, limited data set)
- Federal Register, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, proposed rule, 90 FR 898, January 6, 2025 (AI training data and models as ePHI, technology asset inventory, network map)
- US Department of Health and Human Services, HIPAA Security Rule NPRM (announcement of December 27, 2024 and status of the proposal, checked November 12, 2026)
- US Department of Health and Human Services, HIPAA Security Rule NPRM fact sheet (list of proposed changes)
- US Department of Health and Human Services, Guidance Regarding Methods for De-identification of PHI
- US Department of Health and Human Services, Guidance on HIPAA and Cloud Computing
- Dawiso Help, Data Product Catalog
- Dawiso Help, Requesting access to a data product
- Dawiso Help, Sources of data lineage
- Dawiso Help, Dawiso Model Context Protocol (MCP)
- Dawiso Help, Dawiso Integration Runtime security overview
See it in action
Know where PHI flows into AI
See how the Dawiso Data Catalog records classification, owners and lineage for the data your AI tools use.
