How to Make AI Tools HIPAA Compliant
An AI tool becomes HIPAA compliant only when a covered entity or business associate uses it under a signed business associate agreement, deploys it on infrastructure with the administrative, physical, and technical safeguards required by the HIPAA Security Rule, includes it in the organization’s risk analysis, and limits the protected health information (PHI) it processes to the minimum necessary. Most consumer and general business AI tools do not meet these conditions at the point of purchase. No software product is HIPAA compliant by itself. Compliance depends on the contract, the configuration, and how the organization uses the tool.
Why Standard AI Tools Are Not HIPAA Compliant
A vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a business associate. HIPAA prohibits disclosure of PHI to a business associate without a business associate agreement (BAA). Consumer AI chatbots and free or individual subscription tiers are offered without a BAA. Entering patient information into one of these tools is an impermissible disclosure, regardless of whether a breach follows.
The terms of service for many AI products permit the vendor to retain prompts and uploaded files, use them to train or improve models, and allow human reviewers to read conversations. These uses are incompatible with the HIPAA permitted uses and disclosures of PHI. The regulated entity also has no control over where the data is stored, how long it is kept, or who can access it.
Standard AI tools also lack the controls the Security Rule requires for systems holding electronic PHI (ePHI). Common gaps include the absence of role-based access controls, no audit logging of user activity, no configurable data retention, and no documentation the organization can present to an auditor. A tool connected to email, file storage, or other applications widens the scope of ePHI exposure further.
Risks in AI Applications Built Without Compliance Controls
AI coding assistants allow practice owners and staff without development experience to build applications quickly. These applications are functional in a test environment and routinely fail when moved to production with real patient data. Common findings include unprotected databases exposed to the internet, hardcoded credentials, missing encryption, and hosting on platforms that do not sign a BAA.
An application does not become compliant because its builder intended to follow HIPAA. The Security Rule sets standards, not a technical build specification. The developer must map each required safeguard to a control in the application and hosting environment, document the mapping, and verify that the control operates. Applications built without this mapping need to be reviewed and, where necessary, rebuilt before they process PHI.
Obtain a Business Associate Agreement
The first step is a signed BAA with every vendor in the AI data path. This includes the AI application provider, the model provider if PHI reaches it directly, and the cloud hosting provider. Enterprise and API offerings from some AI vendors are available with a BAA, subject to eligibility requirements and configuration limits set by the vendor. Consumer tiers of the same products are not covered.
Review the BAA and the vendor’s data processing terms before signing. The agreement must restrict the vendor to permitted uses and disclosures. The organization should confirm in writing that prompts, outputs, and uploaded files will not be used for model training, specify retention and deletion periods, identify any subcontractors that will handle PHI, and set breach notification timeframes.
Deploy the Tool on Secured Infrastructure
The AI tool must run in an environment that meets the Security Rule technical safeguards. Required controls include unique user identification, automatic logoff, audit controls that record system activity, integrity controls, and person or entity authentication. Encryption of ePHI at rest and in transit is an addressable specification under the current rule. Any decision not to encrypt must be documented with the reason and the equivalent alternative measure. Multi-factor authentication is the accepted method for authenticating users of systems that hold ePHI.
Data residency and personnel access also require review. The organization should confirm the geographic location of data storage and processing and determine which vendor personnel can access stored data. Some vendors host AI tools in isolated government cloud regions or hold FedRAMP authorizations. FedRAMP is a federal program for authorizing cloud services used by federal agencies, and it is not a HIPAA requirement. A FedRAMP authorization at the moderate or high baseline provides independently assessed evidence of security controls that an organization can reference in its vendor risk assessment.
Include the AI Tool in the Risk Analysis
The Security Rule requires an accurate and thorough assessment of the risks to the confidentiality, integrity, and availability of ePHI. Every AI tool that processes ePHI falls within the scope of that assessment. The risk analysis should identify the data entered into the tool, the systems it connects to, the data flows between them, the threats to each flow, and the safeguards in place. OCR enforcement actions repeatedly cite incomplete risk analyses, and an AI tool omitted from the analysis is an unassessed risk.
Add each AI tool and connected application to the organization’s technology asset inventory. Update the risk management plan with the measures selected to reduce the identified risks.
Apply the Minimum Necessary Standard
The minimum necessary standard applies to uses and disclosures of PHI for purposes other than treatment. Staff using an AI tool for billing, coding, claims appeals, or administrative correspondence should enter only the PHI required for the task. Where an AI task does not require patient identity, the organization can remove identifiers before input. Data de-identified under the HIPAA Safe Harbor method or the Expert Determination method is not PHI. Partial removal of names or record numbers does not meet either method.
Address 42 CFR Part 2 Records
Records of substance use disorder treatment from federally assisted programs are subject to 42 CFR Part 2 in addition to HIPAA. The 2024 final rule aligned Part 2 more closely with HIPAA and set a compliance date of February 16, 2026. Part 2 records retain protections beyond HIPAA, including a prohibition on their use in civil, criminal, administrative, or legislative proceedings against the patient without specific consent or a court order. Disclosures of Part 2 records must be accompanied by a notice regarding redisclosure.
An AI tool that processes full medical records may ingest Part 2 information embedded within a larger record. The organization must be able to identify Part 2 records, track their disclosure, and apply the required restrictions to AI outputs derived from them. A tool configured for general HIPAA use does not meet Part 2 requirements without this capability.
Establish Policies, Training, and Human Review
Written policies must define which AI tools are approved, which tasks they may be used for, and what information staff may enter. Use of unapproved AI tools with PHI should be prohibited in policy and addressed in the sanctions policy. Workforce members must receive training on the approved tools and the prohibited practices.
Generative AI produces inaccurate output. Clinical summaries, patient letters, coding recommendations, and appeal letters generated by AI require review by a qualified staff member before use. Inaccurate information added to a medical record creates an integrity risk that the Security Rule requires the organization to address.
Patient-facing AI tools are also subject to state law. California AB 3030 requires disclosure when generative AI is used in certain patient communications containing clinical information, along with instructions for reaching a human health care provider. Organizations should review the requirements in each state where they treat patients.
Monitor and Reassess AI Tools
AI vendors change models, features, subprocessors, and terms of service frequently. The organization should review audit logs on a set schedule, reassess each AI vendor at least annually, and update the risk analysis whenever a tool gains new integrations or access to additional data. OCR publishes its resolution agreements and civil monetary penalties, and these show the violations the agency pursues. Retain documentation of the BAA, risk analysis, policies, training records, and review activity for six years as required by the Security Rule.
