Yes, healthcare teams can use AI with protected health information, but only after signing a Business Associate Agreement and putting documented administrative and technical safeguards in place. A risk analysis, access controls, audit logging, and ongoing monitoring all need to exist before any AI tool touches patient data. Separately, if the tool supports diagnosis or treatment decisions, you also need to check whether it qualifies as a regulated medical device.
TL;DR:
- A cloud provider remains a business associate even without decryption keys, so verify every subcontractor has a BAA and document permitted uses and breach deadlines.
- Limit each tool to necessary patient data, assign unique accounts, encrypt stored and transmitted information, and review access logs and model performance after launch.
- When software influences diagnosis or treatment, check its intended use and FDA authorization; regulated tools typically require premarket review and should supplement other clinical data.
- Local AI keeps chats and files on the device, reducing transmission and third party storage risks, but still requires safeguards and depends on hardware.
Table of Contents
- What HIPAA requires when AI processes PHI
- Technical safeguards every AI deployment using PHI should provide
- Vendor due diligence and what to insist on in a BAA
- Step-by-step deployment checklist for clinical workflows
- FDA and clinical risk: when AI tools are regulated as medical devices
- Privacy-first alternatives and local or offline AI
- Data storage and retention policies specific to AI systems processing PHI
- Procedures for managing and responding to data breaches involving AI applications
- Training requirements and best practices for staff using HIPAA-compliant AI tools
- Pragmatic governance beats checklisting alone
- How GreenCube fits privacy-first clinician workflows
- FAQ
- Sources
What HIPAA requires when AI processes PHI
Any AI vendor that creates, receives, maintains, or transmits protected health information on behalf of a covered entity is a business associate under HIPAA, and that relationship requires a signed Business Associate Agreement before any data changes hands. Using a cloud-based AI service to process PHI without a BAA in place is a direct violation of the HIPAA Rules, specifically 45 C.F.R. §§164.308(b)(1) and §164.502(e). Covered entities, meaning the hospital, clinic, or practice itself, hold ultimate oversight responsibility, while business associates carry direct liability for certain provisions like breach notification.
Beyond the contract, the Security Rule requires a documented risk analysis of threats to the confidentiality, integrity, and availability of electronic PHI before you deploy any new technology, including AI. HHS does not mandate one specific methodology, but it does require you to document your findings and the reasoning behind the safeguards you choose. Skipping this step, even for a tool that seems low risk, leaves you without the paper trail regulators expect during an audit.
The Privacy Rule adds another layer: the minimum necessary standard. An AI tool should only access the PHI it needs for its specific function, not a patient's entire record by default. In practice, this means:
- Scope AI access to the specific fields or documents the task requires, not the full chart.
- Document who can view AI outputs that reference PHI, and why.
- Limit AI-generated summaries or notes to the use case they were built for.
Technical safeguards every AI deployment using PHI should provide
Once the legal framework is in place, the technology itself has to meet specific controls. The HIPAA Security Series on administrative and technical safeguards lays out the core categories, and most apply directly to AI systems handling PHI.
- Encrypt PHI in transit and at rest. Encryption is an addressable specification under the Security Rule, meaning you must implement it or document an equivalent alternative, not skip it.
- Use unique user IDs and least-privilege access. Every person interacting with the AI system needs their own login, and access should match their actual job function, with emergency access procedures defined separately.
- Log every access and action. Audit logs should capture who accessed PHI through the AI tool, when, and what they did with it, retained long enough to support breach investigations and compliance audits.
- Secure transmission channels. Data moving between the AI tool and any other system needs protection against interception, with automatic logoff for idle sessions.
- Verify data integrity. Authentication mechanisms should confirm that PHI has not been altered or destroyed improperly, whether by the AI system or a bad actor.
Lifecycle monitoring, meaning ongoing validation and logging after deployment, is widely treated as essential for safe AI use in healthcare settings, not just a one-time setup step. Static safeguards configured at launch do not account for model updates, new integrations, or shifting usage patterns, so logs and access reviews need to continue well past go-live.
Vendor due diligence and what to insist on in a BAA
A signed BAA is the starting point, not the finish line. Before you sign anything, insist on seeing how the vendor actually handles the technical and contractual details.
- Confirm the BAA spells out permitted uses of PHI, subcontractor flow-down obligations, and specific breach notification timelines.
- Request architecture diagrams and key management documentation so you understand exactly where and how PHI is processed.
- Ask for SOC-type reports or evidence of third-party security testing, especially for any cloud or hosted component.
- Map the full subcontractor chain: if your AI vendor relies on another cloud provider, that provider also needs a BAA.
- Clarify whether any component is a true no-view or zero-access service, and get that claim documented rather than assumed.
HHS guidance on cloud computing makes an important point here: a cloud service provider is a business associate even if it never holds the decryption key to the data it stores. Encryption alone does not remove the need for a BAA.
It also helps to look at how other industries structure staff-facing AI rules. One useful reference outside health care is this AI policy for employees guide, which walks through governance structures that translate well into clinical settings.
Pro Tip: Signing a BAA does not transfer your risk analysis obligation to the vendor. You still have to validate their configuration and document your own findings.
Step-by-step deployment checklist for clinical workflows
Rolling out an AI tool into a clinical environment works best as a staged process rather than a single go-live event.
- Inventory PHI flows. Map exactly which data elements the AI tool will touch, from intake forms to clinical notes to billing records.
- Classify the use case by risk level. A tool that drafts administrative summaries carries different risk than one that influences a treatment decision.
- Complete the risk analysis. Document threats, likelihood, and the safeguards chosen, tied to the Security Rule's requirements.
- Configure least-privilege access before launch. Limit the tool to the specific users and data it needs on day one.
- Turn on logging from the start. Retroactive logging cannot reconstruct what already happened.
- Set human-in-the-loop rules. Define which AI outputs require a clinician's review before they reach a patient record or influence care.
- Apply data minimization. Feed the AI tool only the fields relevant to its task, not entire charts by default.
- Run routine audits post-launch. Schedule recurring reviews of access logs and output accuracy.
- Watch for model drift. Performance can shift over time as usage patterns change, so periodic revalidation matters.
- Keep an incident response plan ready. Know who gets notified and what steps happen first if something goes wrong.
Assign a named owner for each stage, with a realistic timeline and a documentation template, so an auditor can trace exactly who approved what and when.
FDA and clinical risk: when AI tools are regulated as medical devices
Some AI tools cross into territory the FDA regulates directly. Software intended to assist in diagnosis or clinical decision-making can qualify as a medical device under FDA oversight, which changes the validation, labeling, and governance expectations around it.
If a tool falls into that category, it typically requires premarket review and must be used alongside other clinical data rather than as a standalone decision-maker. Before relying on any AI output clinically, check the FDA's authorization listings and read the tool's intended-use statement carefully. A product marketed for general note-taking is not the same as one cleared for diagnostic support, even if the underlying technology looks similar.
Privacy-first alternatives and local or offline AI
Local inference means the AI model runs directly on a device rather than sending data to a remote server, so nothing leaves the machine during use. That structural difference removes an entire category of transmission and third-party storage risk, though it does not replace the need for your own risk analysis and safeguards.
- Local AI fits well for private note drafting, reviewing sensitive documents, or classroom use where no cloud transmission is desired.
- Cloud AI still makes sense for large-scale reasoning tasks or workflows that need to scale across many users and locations at once.
- Compute limits matter: local models are generally smaller and slower than frontier cloud models, especially on older hardware.
One example of this approach is GreenCube, a desktop AI assistant that runs entirely offline on Windows, with a Mac version in development. At setup, you pick one of two local models to download once, and nothing in your chats or documents gets sent to a server; sign-in through Google or Microsoft exists only to verify the one-time license.
Pro Tip: Before trusting any local AI tool with sensitive documents, verify its offline behavior yourself rather than taking a vendor's word for it. A checklist for validating local document AI walks through exactly how to do that.
Data storage and retention policies specific to AI systems processing PHI
AI systems that process PHI need storage and retention rules that match the sensitivity of what they handle, not a generic IT policy borrowed from elsewhere. That starts with knowing exactly where data lands: does the AI tool cache inputs, store conversation history, or retain training data derived from PHI? Each of those needs its own retention schedule and deletion process.
Retention periods should follow your organization's existing medical record retention rules, since AI-generated notes or summaries that touch patient care often become part of the record. Where an AI tool creates temporary files, logs, or cached outputs that are not part of the permanent record, define a shorter deletion window and document it.
Storage location matters too. If a vendor stores PHI in the cloud, confirm which region or jurisdiction the data resides in, and whether that affects the business associate's obligations. For tools that operate entirely on local hardware, retention is simpler to control because the data never leaves the device in the first place, but you still need a policy for how long local files persist and who can access them. Offline AI hardening guidance covers practical steps for securing that kind of local storage.
Procedures for managing and responding to data breaches involving AI applications
A breach involving an AI application follows the same core HIPAA breach notification obligations as any other PHI incident, but the investigation often takes a different shape. Start by identifying exactly what the AI tool had access to at the time of the incident, since AI systems sometimes touch broader datasets than a single application would.
Your incident response plan should name who gets notified first, typically your privacy officer or security lead, and set a clear timeline for assessing whether the incident meets the threshold for a reportable breach. Business associates are required to report breaches to the covered entity, so your contracts should already specify exact notification windows rather than vague language like "promptly."
Document the root cause, whether it was a misconfigured access control, a vendor-side failure, or an internal process gap, and record the remediation steps taken. This documentation matters twice: once for your own audit trail, and once if regulators request evidence of how you responded. Rehearsing the response plan with a tabletop exercise before a real incident happens tends to expose gaps that a written policy alone misses.
Training requirements and best practices for staff using HIPAA-compliant AI tools
Staff who interact with AI tools that touch PHI need training that goes beyond a general HIPAA refresher. They need to understand exactly what the specific tool does with data: what it stores, what it logs, and what happens to information once they type it in.
Effective training covers a few concrete behaviors: entering only the minimum necessary information into an AI tool, recognizing when an AI-generated output needs clinical review before it reaches a patient record, and knowing how to report a suspected misuse or malfunction. Staff should also know who owns the AI vendor relationship internally, so questions about data handling have a clear point of contact rather than getting lost.
Refresher training matters as much as initial onboarding, especially when a vendor updates a tool's features or when your organization expands the tool's use case. A workforce that was trained on a note-summarization tool six months ago may need new guidance once that same tool starts handling intake forms. Building training reviews into your annual compliance cycle keeps the gap from growing unnoticed.
Pragmatic governance beats checklisting alone
Checklists matter, but they can create false confidence. The organizations that avoid trouble are the ones that keep watching after launch, not just at the start. I'd rather see a small pilot with real logging and a human reviewing outputs than a fully documented rollout nobody monitors past day one.
— Hector Gras
How GreenCube fits privacy-first clinician workflows
For tasks where patient details never need to touch a server, GreenCube gives you a way to work entirely offline. It's a desktop AI assistant for Windows, with Mac support in development, and at setup you choose one of two local models to download once: a fast, text-only option or a slower all-rounder that also reads images and documents.
- Available via a one-time purchase, with no subscription fees and all features included (check the product page for current pricing).
- Chats and files stay on your own machine; sign-in through Google or Microsoft only verifies your license.
- Fits private note drafting, reviewing sensitive documents, or any task where you'd rather not send patient details anywhere.
- Honest trade-off: local models depend on your computer's hardware, and cloud models remain more capable for large-scale reasoning tasks.
If a privacy-first workflow for sensitive drafting or document review sounds useful, you can see the full setup on the GreenCube product page or go straight to the GreenCube Lifetime purchase page to get started.
This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.
FAQ
Does ChatGPT have a HIPAA compliant version?
A standard ChatGPT consumer account does not come with a signed Business Associate Agreement, so it should not be used with PHI by default. Whether any version qualifies depends entirely on whether the provider will sign a BAA and whether the covered entity completes its own risk analysis of that configuration.
Is AI prohibited by HIPAA?
No, HIPAA does not prohibit AI use with patient data, but it requires a signed BAA, a documented risk analysis, and technical safeguards like access controls and audit logging before PHI touches the system. Skipping those steps, not the AI itself, is what creates the violation.
What is the 30% rule in AI?
There is no established "30% rule" recognized in HIPAA or FDA guidance on AI, so this likely refers to an informal industry term rather than a regulatory standard. If you've seen it cited for a specific context, check the primary source directly rather than treating it as an official threshold.
Does OpenAI have a HIPAA compliant version?
Whether a vendor like OpenAI can support HIPAA-covered use depends on whether it will sign a BAA for the specific product tier in question and what safeguards that agreement covers. Covered entities still need to complete their own risk analysis of the configuration regardless of what the vendor offers.
What should I check before trusting an AI tool with patient data?
Confirm a signed BAA is in place, verify the vendor's encryption and access control practices, and check whether the tool's intended use crosses into FDA-regulated territory. A completed, documented risk analysis specific to that tool is required before clinical use, not optional paperwork.