Updated June 2026
HIPAA for AI-Built Healthcare Apps
HIPAA applies if your app creates, stores, or transmits protected health information, no matter what tool built it. AI-built healthcare apps routinely fail on encryption, access controls, audit logging, and signed Business Associate Agreements with every vendor, including any LLM or hosting provider that touches PHI.
AI coding tools like Lovable, Bolt, Cursor, Replit and v0 will ship you a healthcare app that demos beautifully. HIPAA does not care how the code was written. If your app handles protected health information (PHI), the rules that always applied still apply, and in an AI-built app the gaps land exactly where HIPAA is strictest: access control, encryption, audit trails, and vendor agreements. This guide covers what HIPAA actually requires in plain terms and where AI-built apps fall down. It is general information, not legal advice. Confirm your specific obligations with a qualified healthcare attorney or compliance advisor.
Does HIPAA apply to my app? (the PHI test)
Two things decide it: who you are and what data you handle. The U.S. Department of Health and Human Services (HHS) enforces the rules. They apply to covered entities (health plans, healthcare providers, and clearinghouses) and to their business associates, which is most software vendors that handle PHI on a covered entity’s behalf.
PHI is individually identifiable health information. Here is the working test: does your app create, store, receive, or transmit health information that can be tied to a specific person? That covers the obvious stuff like diagnoses, lab results, and treatment notes. It also covers identifiers attached to health context, like names, dates, contact details, and account identifiers tied to care.
- You are likely in scope if you build or operate software for a provider, plan, or clearinghouse and your app touches PHI. That usually makes you a business associate.
- You may not be in scope if your app handles only general wellness or fitness data with no connection to a covered entity and no individually identifiable health information. This boundary is fact-specific, so check it instead of assuming.
- Being unsure is normal. Direct-to-consumer health apps sit in a gray zone, and other rules (like state privacy laws) can still bite even when HIPAA does not.
The HIPAA essentials
HIPAA’s requirements come mainly from the Privacy Rule and the Security Rule. The Security Rule, which governs electronic PHI, splits into administrative, physical, and technical safeguards. For an AI-built app, the items below are where the engineering work actually lives.
- Encryption in transit and at rest. Protect PHI in motion (TLS for every connection) and store it with strong encryption. Encryption is an addressable specification under the Security Rule, which means you implement it or document a reasonable, equivalent alternative.
- Access controls. Give PHI access only to the people and systems that genuinely need it, enforce unique user identities, and apply the minimum-necessary principle so each role sees only what its job requires.
- Audit logging. Record who accessed or changed PHI and when, and keep those logs so access can be reviewed after the fact.
- Business Associate Agreements (BAAs). You need a signed BAA with every vendor that handles PHI for you, including hosting and database providers, and any AI or LLM provider whose service receives PHI. No BAA means that vendor should not be touching PHI. Full stop.
- Breach notification. The Breach Notification Rule makes you notify affected individuals and HHS (and sometimes the media) when unsecured PHI is breached, within defined timeframes. Plan for this before you launch, not after the incident.
Where AI-built apps fail HIPAA
The failures are predictable, because AI tools optimize for an app that runs, not one that is compliant. These are the gaps we see most often in AI-built healthcare apps.
| Gap | What it looks like | HIPAA area at risk |
|---|---|---|
| Row-Level Security off | Database tables holding PHI are readable across users, or access is checked only in the client | Access controls |
| PHI sent to an LLM with no BAA | Patient data is passed to an AI API that has no signed Business Associate Agreement | Business Associate Agreements |
| Exposed keys | API keys or database credentials shipped to the browser or committed to git history | Access controls, encryption |
| No audit trail | The app does not record who viewed or changed PHI, so access cannot be reviewed | Audit logging |
| PHI in logs or errors | Patient data written to plaintext logs or returned in verbose error messages | Encryption, minimum necessary |
The LLM gap deserves its own callout. It is one line of code to wire patient data straight into a general-purpose AI API, and people do it without thinking. But unless that provider has signed a BAA and offers a HIPAA-eligible configuration, sending PHI there is a compliance problem on its own. Same logic for your hosting and database providers.
A HIPAA readiness checklist for AI-built apps
Use this to find the obvious gaps. It is not a substitute for a formal risk analysis, which the Security Rule requires and which a qualified advisor should help you complete.
- Confirm scope. Figure out whether your app handles PHI and whether you are a covered entity or business associate. If you are unsure, get a legal read before launch.
- Enable access controls. Turn on Row-Level Security (or equivalent) on every table holding PHI, enforce auth on the server, and apply minimum-necessary access by role.
- Encrypt everything. TLS for all traffic and strong encryption at rest for PHI, backups included.
- Add audit logging. Log access to and changes of PHI, with user identity and timestamp, and keep the logs.
- Sign BAAs. Get a signed BAA with every vendor that touches PHI, including hosting, database, and any AI or LLM provider. If a vendor will not sign one, get it out of the PHI path.
- Lock down secrets. Move every key server-side, strip anything sensitive from client code and git history, and rotate exposed credentials.
- Keep PHI out of logs and errors. Make sure patient data never lands in plaintext logs or error responses.
- Prepare for breaches. Have a documented breach-response plan that meets the notification timeframes before you go live.
For the wider pre-launch picture, see our guide on whether your AI app is production ready. If you are weighing formal certifications, our overview of SOC 2 for AI-built apps covers neighboring ground, and the specific risk of exposed API keys in AI-built apps is one of the most common things we find in a healthcare build.
Want us to run this audit for you?
We do a free 15-minute build audit: you show us your AI-built app, we tell you the specific security and production gaps and what it takes to fix them. No obligation.
FAQ
Does HIPAA apply to an app built with AI tools?
Yes, if the app creates, stores, or transmits protected health information. HIPAA applies based on the data and your role (covered entity or business associate), not the tool that wrote the code. An AI-built app meets the same requirements as any other.
Can I send patient data to an AI or LLM API?
Only if that provider has signed a Business Associate Agreement and offers a HIPAA-eligible configuration. Sending PHI to a general-purpose AI API with no BAA in place is a compliance problem. Confirm the vendor's terms before any patient data is involved.
What are the most common HIPAA gaps in AI-built apps?
Access controls left open (like Row-Level Security disabled), PHI sent to an LLM with no BAA, exposed API keys, missing audit logging, and patient data written to plaintext logs or error messages. They cluster in the areas HIPAA is strictest about.
Is this guide legal advice?
No. This is general information to help you find common gaps. HIPAA obligations are fact-specific, and the Security Rule requires a formal risk analysis. Confirm your specific requirements with a qualified healthcare attorney or compliance advisor.