If an AI tool touches protected health information, treat it as a HIPAA-covered system and require a signed Business Associate Agreement before it processes a single record. That is the bottom line. HIPAA remains technology-neutral, meaning copilots, clinical assistants, LLM-powered coding tools, and any AI that creates, receives, maintains, or transmits PHI all fall under the Privacy, Security, and Breach Notification Rules. The HHS Office for Civil Rights does not carve out exceptions for AI.
Three immediate actions for your team:
- Require a signed BAA from every third-party AI vendor before PHI enters their system. Consumer-grade AI tools are generally impermissible for PHI — public interfaces like free-tier chat products do not qualify.
- Apply minimum necessary controls to every prompt and model input. De-identify or use a limited data set where the clinical use case permits.
- Run endpoint discovery now. Most organisations have AI tools operating on endpoints that their security stack cannot see. Alectura's AIDR surfaces those tools, inventories their access, and logs what they touch.
Table of Contents
- Does HIPAA apply to AI? What the rules actually require
- When does HIPAA apply to Australian organisations?
- What must a BAA cover for AI vendors?
- How to run an AI-specific vendor risk assessment
- Technical controls to enforce at endpoints
- Operational governance for AI agents
- Breach detection and notification obligations
- 30–60–90 day implementation checklist
- Key takeaways
- The compliance gap nobody talks about
- Alectura AIDR closes the endpoint visibility gap
- Authoritative sources and further reading
Does HIPAA apply to AI? What the rules actually require
HIPAA's technology-neutral framing is deliberate. Any AI vendor that handles PHI on behalf of a covered entity is a business associate, full stop. That classification triggers the full set of Security Rule obligations.
The technical safeguards your contracts and configurations must address:
- Encryption: AES-256 at rest, TLS 1.2+ in transit for any ePHI.
- Access control: Role-based access is a floor, not a ceiling. Attribute-Based Access Control (ABAC) at the operation level is the standard that actually enforces minimum necessary for AI agents.
- Audit logging: Comprehensive, tamper-evident logs of all AI interactions with ePHI.
- Vulnerability management: HHS expects entities to monitor authoritative sources for known AI system vulnerabilities and remediate promptly under a documented patch management programme.
- Risk analysis: AI tools must be included in your Security Risk Analysis, not treated as peripheral software.
The minimum necessary principle extends to prompts. If a clinical summarisation tool only needs a patient's medication list, sending the full EHR record is a violation of the principle regardless of whether a BAA is in place. De-identification under Safe Harbor or Expert Determination removes data from PHI status entirely, which can eliminate the BAA requirement for that dataset.

When does HIPAA apply to Australian organisations?
HIPAA is a US federal law, but Australian organisations encounter it more often than they expect. The trigger is acting as a business associate for a US covered entity. Common scenarios:
- An Australian subsidiary processing ePHI on behalf of a US health system.
- Cloud API calls to US-hosted AI endpoints where PHI is transmitted.
- Research collaborations using US patient datasets under a data use agreement.
- EHR integrations with US providers where your team handles the data pipeline.
When HIPAA obligations attach, they sit alongside the Australian Privacy Principles (APPs) under the Privacy Act 1988. The crosswalk is practical: APP 11 (security of personal information) maps directly to HIPAA Security Rule technical and administrative safeguards. APP 8 (cross-border disclosure) requires you to document the legal basis for transferring health data to US AI vendors, which aligns with the BAA and data flow documentation HIPAA already demands.
Pro Tip: Embed HIPAA controls into your Privacy Impact Assessments for any project involving US health data. Document the legal basis for cross-border transfers in the contract, not just in an internal policy. That single step satisfies both APP 8 and HIPAA's vendor management expectations simultaneously.
What must a BAA cover for AI vendors?
A BAA is a legal prerequisite, but a poorly drafted one gives false assurance. A signed BAA is necessary but not sufficient — compliance officers must verify that product-level settings like training opt-outs, retention controls, and logging are actually enforced for your tenancy.
Non-negotiable BAA clauses for AI use cases:
- Explicit prohibition on using PHI to train general-purpose models.
- Defined data retention and deletion timelines, with written confirmation of deletion on request.
- Logging and audit access rights for your security team.
- Incident notification obligations and timelines (60 days under HIPAA; align with your internal 72-hour detection target).
- Subcontractor flow-down requirements covering every third party that touches PHI.
Tier and endpoint specificity matters. A BAA covering an enterprise API endpoint does not automatically cover the vendor's consumer web interface or mobile app. Confirm in writing which product tiers, API versions, and feature sets are in scope.
Pro Tip: Request the vendor's current SOC 2 Type II report and any HITRUST attestation before signing. A BAA with no supporting security evidence is a contractual promise with no technical backing.
How to run an AI-specific vendor risk assessment
Experts warn that assuming a vendor's general HIPAA posture covers all use cases is the most common trap security teams fall into. Perform a product-level assessment for each AI tool and tier.

Vendor questionnaire: testable yes/no items
| Check | What to ask |
|---|---|
| BAA scope | Does the BAA explicitly cover this product tier and API endpoint? |
| Training opt-out | Is PHI excluded from model training by default, or must it be configured? |
| Prompt/log retention | How long are prompts and model outputs retained, and can you request deletion? |
| Subcontractors | Provide a current list of subprocessors that may access PHI. |
| Encryption | Confirm AES-256 at rest and TLS 1.2+ in transit for all PHI flows. |
| SOC 2 / HITRUST | Provide current Type II report or equivalent attestation. |
| Vulnerability cadence | What is the patch management cycle for AI system components? |
| Data residency | Where is PHI stored and processed? Are cross-border routes documented? |
Pro Tip: Run the questionnaire against the specific API credentials your team will use, not the vendor's generic security documentation. Default settings in non-enterprise tiers often differ from what the BAA describes.
Technical controls to enforce at endpoints
Endpoint discovery is the starting point. Most enterprise fleets have copilots, browser-based assistants, local MCP servers, and API integrations that no existing EDR or CASB solution inventories. The HHS NPRM expects entities to maintain a written technology asset inventory that includes AI software interacting with ePHI.
| Control | Where to enforce | Why it matters |
|---|---|---|
| AI tool discovery and inventory | Endpoint agent | Identifies shadow AI before PHI exposure occurs |
| ABAC at operation/field level | Endpoint + API gateway | Enforces minimum necessary; prevents broad EHR access |
| Prompt redaction and DLP | Endpoint agent (inline) | Strips PHI before it leaves the device |
| AES-256 / TLS 1.2+ encryption | Transport + storage layer | Protects ePHI in transit and at rest |
| Granular audit logging | Endpoint + SIEM | Supports breach forensics and OCR inquiries |
| Vulnerability scanning | Infrastructure + AI components | Meets HHS patch management expectations |
Implementing ABAC at the operation level — so an AI agent receives only the specific PHI fields a task requires, rather than broad record access — is the technically correct way to enforce minimum necessary for AI. Broad RBAC alone cannot achieve this for agent-based workflows.
Operational governance for AI agents
Autonomous AI agents require updated incident response charters because traditional human-in-the-loop oversight breaks down when agents can access EHRs or take independent actions. Governance must catch up.
Maintain a live model and agent inventory with owner, data flows, and risk tier (low/medium/high) mapped to clinical impact. High-risk agents accessing EHRs or generating clinical suggestions require additional validation, monitoring, and explicit approval gates before deployment.
Governance checklist:
- Define when a human must approve an agent's output before it acts.
- Document change control procedures for model updates and new agent deployments.
- Extend IR playbooks to cover prompt injection, hallucination-driven PHI exposure, and model override scenarios.
- Assign clinical safety and legal roles in the IR charter alongside security.
- Schedule continuous monitoring reviews quarterly, not annually.
Pro Tip: A 'HIPAA-first' governance approach integrates AI risk management directly into existing HIPAA security policies, which prevents the policy drift that happens when AI governance sits in a separate framework.
Breach detection and notification obligations
Preserve prompt logs, model outputs, and endpoint telemetry from the moment an incident is suspected. OCR inquiries routinely request this evidence, and gaps in logging are treated as aggravating factors.
Notification obligations differ by jurisdiction:
- HIPAA (US): Covered entities notify affected individuals, relevant media, and HHS Secretary. Business associates notify the covered entity. Timelines follow OCR guidance.
- Australia (NDB scheme): Notify the Office of the Australian Information Commissioner (OAIC) and affected individuals when a data breach is likely to cause serious harm. The OAIC's guidance on eligible data breaches applies to health information.
- Cross-border incidents: Prepare joint response procedures for incidents affecting both US covered entities and Australian operations. Document notification triggers, jurisdictional contacts, and escalation paths in advance.
Forensic capture checklist: audit logs, data flow records, vendor communications, model version at time of incident, training and data retention evidence, and any BAA or subcontractor agreements in scope.
30–60–90 day implementation checklist
30 days
- Run endpoint discovery across the fleet; inventory every AI tool and its data access.
- Block consumer chat interfaces from corporate networks for any device handling health data.
- Confirm signed BAAs for all current AI vendor relationships; flag gaps immediately.
- Identify PHI flows to AI tools and apply minimum necessary controls or de-identification.
60 days
- Deploy ABAC rules for AI operations at the field/operation level.
- Enforce prompt redaction and inline DLP on endpoint agents.
- Integrate AI event logs with your SIEM; set detection targets.
- Formalise the vendor questionnaire into procurement and onboarding workflows.
90 days
- Validate IR playbooks against AI-specific scenarios (prompt injection, agent override).
- Complete third-party audits or SOC 2 reviews where required by BAAs.
- Embed AI risk checks into the annual Security Risk Analysis process.
- Review OAIC NDB scheme obligations and align cross-border notification procedures.
KPIs to track: number of AI endpoints without a signed BAA, mean time to detect AI-origin data exfiltration, percentage of AI endpoints under active monitoring, and number of staff trained on AI PHI policy.
Pro Tip: Run the 30-day discovery before any other step. You cannot govern what you cannot see, and most teams are surprised by how many AI tools are already active on endpoints.
Key takeaways
Any AI tool that touches PHI must be treated as a HIPAA-covered system, governed by a signed BAA, endpoint discovery, ABAC controls, and audit logging aligned to both HIPAA and Australian Privacy Principles.
| Point | Details |
|---|---|
| BAA before PHI | Require a signed, tier-specific BAA from every AI vendor before any PHI is processed. |
| Endpoint discovery first | Run discovery before deploying other controls — shadow AI on endpoints is the primary exposure vector. |
| ABAC enforces minimum necessary | Implement ABAC at the operation/field level so AI agents access only the PHI fields a task requires. |
| Dual-jurisdiction alignment | Map HIPAA Security Rule safeguards to APP 11 and document cross-border transfers to satisfy APP 8. |
| Alectura AIDR | Alectura's endpoint discovery, prompt logging, inline DLP, and SIEM integration map directly to these HIPAA and APP obligations. |
The compliance gap nobody talks about
The hardest part of AI compliance in healthcare is not the regulation. The regulation is clear enough. The hard part is that most security teams are trying to govern AI they cannot fully see, under contracts that were written before anyone understood what AI agents actually do at the endpoint level.
A BAA that prohibits training on PHI is meaningless if the vendor's default configuration for your product tier still logs prompts to a shared infrastructure. A DLP policy that inspects traffic at the perimeter misses the prompt that was composed, sent, and responded to entirely within a browser extension. The gap between what a contract says and what a product does by default is where most real-world HIPAA exposure lives.
The conventional wisdom says: get a BAA, do a risk assessment, train your staff. That is not wrong. But it treats compliance as a documentation exercise rather than a technical enforcement problem. The organisations that are actually protected are the ones that have closed the visibility gap at the endpoint, verified vendor settings against BAA claims, and built detection into their monitoring stack rather than relying on vendor self-attestation.
Alectura AIDR closes the endpoint visibility gap
Most security stacks cannot see the AI running on your endpoints. Alectura's AI Detection & Response platform changes that. AIDR continuously discovers copilots, browser assistants, MCP servers, and API integrations across your fleet, inventories each tool and the access it holds, and tracks prompt timelines so you have the forensic record OCR expects.

On-device DLP and prompt redaction strip PHI before it leaves the endpoint. Policy enforcement lets you apply BAA-aligned guardrails per tool and per tier, without blocking legitimate clinical workflows. SIEM and SOAR integrations feed AI event data into your existing detection stack, supporting the 72-hour detection targets that matter for both HIPAA and the Australian NDB scheme.
For enterprise procurement and per-endpoint pricing, visit Alectura's pricing page or contact the team directly to scope a deployment.
Authoritative sources and further reading
Primary sources used in this article:
- HHS Office for Civil Rights — HIPAA Security Rule: the governing text for technical and administrative safeguards.
- HHS NPRM on HIPAA Security Rule updates: proposed changes including AI asset inventory and patch management expectations.
- Tovino (2025), Artificial Intelligence and the HIPAA Privacy Rule: academic analysis of HIPAA's application to AI scenarios.
- Medcurity — HIPAA compliance for AI in healthcare: practical guidance on AI as business associate and BAA requirements.
- Medcurity — Using LLMs with PHI: BAA necessity, de-identification, and consumer tool risks.
- Norton Rose Fulbright — Navigating AI compliance with HIPAA: HIPAA-first governance framework.
- AccountableHQ — Healthcare AI regulations 2025: ONC DSI, FDA PCCP, and autonomous agent governance.
- OAIC — Notifiable Data Breaches scheme: Australian notification obligations for health data breaches.
Retain evidence. BAAs, SOC 2 reports, vendor attestations, and risk analysis records should be stored as part of your Security Risk Analysis documentation and made available for OCR or OAIC review. Engage legal counsel for cross-border contract review and to confirm current HIPAA and APP obligations for your specific operating structure.
This article provides general information only and does not constitute legal or compliance advice. Confirm current obligations with the HHS Office for Civil Rights, the OAIC, and qualified legal counsel for your organisation's specific circumstances.
