COMPLIANCE AND REGULATORY UPDATES
HIPAA and AI Tools: Mapping ePHI, Vendors, BAAs, Risk Analysis, and Human Review
Healthcare organizations are using or evaluating artificial intelligence for transcription, visit summaries, coding assistance, patient messaging, document review, analytics, scheduling, and administrative work. The first HIPAA question is not whether a product is called “AI” or “HIPAA-ready.” It is whether protected health information enters the workflow, what each party does with it, which systems create, receive, maintain, or transmit it, and whether the organization has assessed and managed the resulting risks.
The HIPAA Rules are technology neutral. This article does not claim that HHS has created a special AI safe harbor or a single approved-product list. It applies existing HHS guidance on risk analysis, business associates, cloud services, minimum necessary use, and de-identification to the data paths AI tools create.
Executive summary
Before a workforce member enters clinical or billing information into an AI service, the organization should be able to answer six questions:
- Does the content include protected health information or electronic protected health information (ePHI)?
- Is the vendor creating, receiving, maintaining, or transmitting that information on the organization’s behalf?
- Is a HIPAA-compliant business associate agreement (BAA) required and in place for the exact service and account being used?
- Where do prompts, files, recordings, retrieved records, outputs, logs, feedback, and backups travel and remain?
- What administrative, physical, and technical safeguards apply, and how were risks to confidentiality, integrity, and availability evaluated?
- Who verifies the output before it affects patient care, billing, disclosure, access, or another consequential decision?
A signed BAA is important when required, but it is not a complete security assessment. A vendor’s statement that it does not use customer content to train a general model does not answer storage, access, subprocessors, identity, logging, retention, deletion, incident reporting, availability, or output-integrity questions.
Map the entire AI data flow
An AI workflow often contains more systems than the product interface suggests. The data map should include:
- the source system, such as an electronic health record, document repository, email, phone, or medical device;
- the workstation, mobile device, browser, extension, or application used to submit information;
- prompts, attachments, audio, images, free-text notes, and retrieved records;
- vendor APIs, gateways, storage, model endpoints, monitoring, support, and abuse-review processes;
- plug-ins, connectors, automation platforms, and downstream applications;
- generated summaries, codes, letters, messages, recommendations, and structured fields;
- prompt history, conversation memory, telemetry, debug logs, feedback, backups, and exports;
- subcontractors and locations involved in processing or storage;
- deletion, return, legal-hold, and account-termination paths.
Free text deserves special attention. A clinic may remove a patient’s name but leave dates, locations, record numbers, diagnoses, rare conditions, appointment details, or narrative context that can identify the person. HHS recognizes two methods for de-identification under the Privacy Rule—Expert Determination and Safe Harbor. Informal removal of a few obvious fields should not automatically be labeled de-identification.
Determine the vendor’s role from the service performed
HHS cloud-computing guidance explains that a cloud service provider that creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate is a business associate, even when it stores encrypted ePHI and does not hold the decryption key. The covered entity or business associate must enter an appropriate BAA and otherwise comply with the HIPAA Rules.
The same analysis should be applied to an AI service based on the facts. Ask whether the vendor or a subcontractor receives audio from visits, stores prompts, maintains records for retrieval, processes clinical documents, or transmits outputs into another system. Review the exact product tier and configuration: consumer, developer, enterprise, health-specific, and embedded versions may have different contracts and data handling.
Do not rely only on a sales statement, website badge, or the availability of a BAA. Verify that the agreement names the correct contracting parties and service, identifies permitted and required uses and disclosures, addresses safeguards and incident reporting, and flows appropriate obligations to subcontractors. HHS provides sample BAA provisions, while also warning that sample language alone may not address all legal or state-law needs.
An independent HIPAA BAA and vendor-risk review should connect contract language to the technical configuration and actual workflow.
Include every ePHI location in the security risk analysis
HHS risk-analysis guidance states that the scope includes potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI an organization creates, receives, maintains, or transmits. An AI pilot is not outside that scope because it is temporary, innovative, or run by one department.
The assessment should consider at least:
| Risk area | AI-workflow question | Evidence |
|---|---|---|
| Confidentiality | Can prompts, memory, logs, support staff, or connectors expose ePHI beyond the approved purpose? | Data-flow map, access settings, contract, log review |
| Integrity | Can an incorrect or manipulated output update a record, code, order, message, or decision? | Approval workflow, test results, change history |
| Availability | What happens if the vendor, integration, Internet connection, or account is unavailable? | Downtime procedure, export and recovery test |
| Identity | Are users, administrators, service accounts, and agents uniquely identified and appropriately authenticated? | Role export, MFA and access-review evidence |
| Minimum necessary | Does the tool receive more information than the approved task needs? | Field mapping, prompt template, access scope |
| Vendor risk | Are subprocessors, retention, deletion, support access, and incident duties understood? | BAA, service agreement, vendor evidence |
| Monitoring | Can the organization identify who submitted which data and what action followed? | Audit logs, alert tests, retention settings |
Risk treatment should be documented. A known limitation may be accepted, reduced, transferred contractually, or cause the use case to be rejected. Silence is not a decision record.
Apply minimum necessary and purpose limitation
The HIPAA Privacy Rule’s minimum necessary standard generally requires reasonable efforts to limit PHI to what is needed for the purpose, subject to its terms and exceptions. For AI workflows, use purpose-specific templates and data filters rather than inviting employees to paste an entire record because it is convenient.
Examples include:
- give a scheduling assistant appointment fields, not the clinical chart;
- give a coding workflow the documentation required for the task, not unrelated history;
- separate demographic identifiers from analytic data when the approved purpose allows;
- restrict retrieval to the user’s authorized patient population and role;
- prevent a general chatbot from searching every repository by default;
- disable memory or history when it is unnecessary and the service supports that control.
Minimum necessary is not a substitute for permitted-use analysis, a BAA, security safeguards, or professional judgment. Privacy and legal teams should evaluate the exact use.
Treat de-identification as a controlled process
HHS de-identification guidance explains Expert Determination and Safe Harbor and notes that even properly de-identified data retains a small, nonzero re-identification risk. AI teams should not assume that replacing a name with initials or removing one identifier makes a narrative safe for unrestricted use.
Document the method, the data fields, free-text handling, re-identification controls, recipient, combination risks, and the person responsible for the determination. Generated output can also reintroduce identifiers by repeating input, joining retrieved sources, or placing details in logs.
Preserve human accountability for consequential output
Human review should be designed around the consequence. A clinician, coder, privacy officer, or authorized staff member should see the source material, the generated output, important uncertainty, and the proposed action. The reviewer must be able to correct or reject the result before it changes a record, affects treatment, creates a bill, releases information, or sends a patient-facing message.
Do not use a model’s confident wording as evidence of accuracy. Test for omitted facts, fabricated details, incorrect attribution, wrong-patient context, coding errors, unsafe recommendations, biased performance, and drift after model or workflow changes. Define which uses are assistive only and which are prohibited from autonomous execution.
Human review is a risk control, not a universal cure. If staff routinely approve outputs without reading source material, the control exists only on paper.
Verify security and operational controls
Identity and access
Use unique accounts, multifactor authentication, role-based access, separate administrator roles, prompt removal of departed users, session controls, and periodic access reviews. Review API keys and service accounts as identities, not implementation details.
Logging and monitoring
Confirm whether the organization can retrieve user, administrator, prompt-submission, connector, export, configuration, and incident events. Avoid storing unnecessary ePHI in security logs. Test alerts and retain evidence according to approved policy.
Retention, deletion, and secondary use
Document how long prompts, outputs, recordings, memory, logs, backups, and support copies remain. Verify deletion behavior and contractual limits on secondary use, model improvement, human review, and subprocessors. Account closure should not be the first time the organization learns that export or deletion is difficult.
Resilience and contingency planning
Define what staff do when the service or integration fails. Preserve access to authoritative patient information and avoid making the AI tool the only path to a critical workflow. Test restoration or manual procedures based on the use case’s patient-safety and operational impact.
Incident response
The plan should address exposed prompts, compromised accounts, excessive connector access, wrong-recipient output, vendor incidents, unauthorized model use, and inaccurate automated changes. Know how to disable the integration, revoke keys, preserve evidence, identify affected records, and obtain timely vendor information for legal and breach analysis.
A practical approval workflow
1. Describe the use case
Record the business or clinical purpose, users, patients or populations affected, decision supported, and prohibited uses.
2. Map data and vendors
Identify every source, transfer, storage location, output, log, connector, and subprocessor. Use the medical clinic software and PHI inventory as a starting point for broader system visibility.
3. Complete privacy, security, and contract review
Determine permitted uses, minimum necessary data, business-associate status, BAA needs, vendor assurances, security configuration, and residual risk. Obtain qualified legal advice for the specific arrangement.
4. Test before production
Use authorized test data. Evaluate accuracy, unsafe output, access boundaries, prompt injection, export, logging, downtime, deletion, and incident disablement. Do not use real patient information simply because the pilot needs realistic examples.
5. Approve with conditions
Define allowed departments, data, accounts, configurations, reviewer, monitoring, review date, model-change process, and shutdown criteria.
6. Reassess changes
Re-review when the model, vendor terms, subprocessors, data source, connector, action authority, retention, or clinical purpose changes.
OC Security Audit’s HIPAA Security readiness and assessment resources can help connect the AI review to the wider administrative, physical, and technical safeguard program.
Questions healthcare leaders should ask
- Which AI tools are used with patient or billing information today, including unapproved tools?
- Does the data map include prompts, recordings, output, memory, logs, backups, and subprocessors?
- Is a BAA required, and does it cover the exact product and data flow?
- What configuration evidence supports the vendor contract?
- How is minimum necessary enforced technically and operationally?
- Who verifies output before it affects care, billing, records, or disclosure?
- Can the organization disable access, revoke keys, identify affected data, and continue operations during an incident?
- What change triggers a new review?
Sources
- HHS OCR: Guidance on Risk Analysis, reviewed September 2025
- HHS OCR: Guidance on HIPAA and Cloud Computing
- HHS OCR: Business Associate Contracts and Sample Provisions
- HHS OCR: Minimum Necessary Requirement
- HHS OCR: Guidance on De-identification of Protected Health Information
- NIST: AI Risk Management Framework
Review AI use before ePHI enters the workflow
Contact OC Security Audit to discuss an independent HIPAA security, cloud, vendor, or AI workflow review. Learn more about Ali Hassani, CISO and his experience across healthcare IT, cybersecurity, compliance auditing, Microsoft infrastructure, and executive risk guidance.
Pair this workflow review with the current HIPAA Security Rule hardening analysis, apply SaaS vendor security due diligence before approval, and use the AI security governance framework to define ownership and oversight.
Update and correction history
- July 2026: Initial analysis prepared from HHS/OCR and NIST guidance available through July 2026.