TL;DR: If your app touches patient data, the AI tool you built it with almost certainly won't sign a BAA. Lovable's own terms ban uploading PHI outright. That doesn't mean you can't build healthtech with AI. It means you add the compliance layer yourself. Don't assume it's already there.
A founder builds a patient intake form in Lovable over a weekend. It works. Fields validate. Data saves. The demo looks done. Then someone asks: is this HIPAA compliant? For almost every AI-built app like this, the answer is no. And the reason is not a bug. It's a contract.
HIPAA requires a signed Business Associate Agreement, or BAA, with every vendor that touches protected health information (PHI) on your behalf. No BAA means no lawful way to run PHI through that vendor. That's not our opinion. It's the HHS rule itself.
Why "it looks finished" and "it's compliant" are different questions
AI coding tools are built for one thing: get you to a working product fast. For most SaaS apps, that's a fair trade. Healthtech is different. Speed to a working demo is not what HIPAA checks for. HIPAA checks whether your infrastructure has real, contractual safeguards around PHI.
An app can look done, patient records, appointment scheduling, a login screen that looks secure, and still fail its first real compliance review. The review does not test whether the UI works. It tests whether every vendor touching that data has signed a BAA, whether access is logged, and whether the database actually enforces the isolation it claims to.
The BAA gap, specifically
As of this writing, none of the widely used AI coding tools, Lovable, Bolt.new, Cursor, Replit, GitHub Copilot, publish a standard BAA. Some of the language models behind these tools do offer BAA-covered API tiers for enterprise customers. But that BAA only covers the model call. It does not cover the hosting, the database, or the auth layer the AI tool builds around that call.
Lovable says this outright in its own terms. Paubox's review of Lovable's terms of service quotes the policy directly: users agree "not to upload, input, or otherwise provide through the Services any protected health information subject to HIPAA," unless a separate written agreement says otherwise. Paubox also reports that Lovable does not offer a BAA on its standard plans, "not even behind a paywall."
This is not a hidden trap. Most Lovable users are not handling PHI at all, so the policy makes sense for the platform. But it flips a common assumption. Founders often think "I built it here, so the platform must cover me." The platform is telling you the opposite, in writing.
What actually breaks in AI-built healthtech apps
Set the BAA question aside for a moment. Look at what a technical review of an AI-built healthtech prototype usually finds. These are the same gaps we flag across AI-built apps generally. They just carry more weight when PHI is involved.
- PHI stored in browser localStorage. Fast to build, but localStorage isn't encrypted. It isn't access-logged. Any script on the page can read it. Patient data should never sit there.
- No audit log on who viewed a patient record. HIPAA's Security Rule expects PHI access to be tracked. If nothing logs reads and writes, you can't answer "who looked at this record, and when."
- Supabase row-level security left disabled or too open. This is one of the most common findings across vibe-coded apps. In healthtech, it's the difference between one clinic's patients staying separate from another's, or not.
- No BAA anywhere in the stack. Even a well-built app fails here if the hosting provider, database, or email service in the chain never signed a BAA. One weak link breaks the whole chain.
None of these are exotic. They're the same categories our free scan checks across security, reliability, performance, and monitoring, they just carry HIPAA-specific weight the moment real patient data is in play.
What to actually do about it
The fix is not "stop using AI for healthtech." The fix is drawing a clear line: what the AI builder is good for, and what has to sit outside it.
- Use the AI builder for everything that never touches PHI. Marketing pages, scheduling UI, non-clinical admin tools. This is where AI builders are strongest, and the risk is lowest.
- Move the PHI path onto BAA-covered infrastructure. Hosting, database, and any service that stores or sends patient data needs a signed BAA before real data touches it. Not after.
- Add access logging before launch, not after an incident. Every read or write on a patient record should leave a trail you can check later.
- Verify row-level security like you would for any multi-tenant app. Confirm policies are owner-scoped. "Enabled" is not enough.
- Get a technical review before real patient data moves through the app. A code-level review catches localStorage-PHI and disabled-RLS issues. A legal review of your BAAs alone will not.
| Question a HIPAA review asks | What an AI builder demo usually has | What it needs instead |
|---|---|---|
| Is every vendor touching PHI under a signed BAA? | No BAA with the AI builder or its default hosting | BAA-covered hosting, database, and auth for the PHI path |
| Is access to patient records logged? | No audit trail | Access logging on every read/write to PHI |
| Is one patient's data isolated from another's? | RLS disabled or default-permissive | Owner-scoped RLS policies, verified with negative tests |
| Where does PHI actually live? | Sometimes in browser localStorage | Encrypted, access-controlled backend storage only |
These same gaps show up across our compliance work, including GDPR compliance for vibe-coded apps and EU AI Act compliance. The pattern repeats: AI builders ship a working product fast, and leave the regulatory-grade safeguards for the founder to add later.
Find out where your app actually stands
Free URL-based scan. No code access. About 30 seconds. Or get the full Compliance Score for HIPAA, GDPR, and EU AI Act Foundations checks in one report.
Run the free scanWhat Launch Ready Code checks, and what it doesn't
We are not a HIPAA certification body, and we don't claim to be one. Nobody self-certifies HIPAA compliance. It's assessed through audits and enforced through OCR investigations, not a vendor badge. What our Compliance Score does is check the technical controls a real HIPAA review would ask about: is RLS actually enforced, is access logged, is PHI-adjacent data stored somewhere it shouldn't be. The free scan is $0 and gives you a Launch Readiness Score in about 30 seconds. The Compliance Score, $799 one time, goes deeper across GDPR, EU AI Act, and HIPAA Foundations, with a fix roadmap included.
FAQ
Does Lovable sign a Business Associate Agreement (BAA)?
No. Lovable does not offer a standard BAA. Its terms of service say users may not upload PHI through the standard service, unless a separate written agreement allows it. No BAA means the platform can't lawfully process PHI under HIPAA.
Do Bolt.new, Cursor, or Replit sign a BAA?
As of this writing, none of the major AI coding tools publish a standard Business Associate Agreement. Some of the underlying LLM providers offer BAA-covered API tiers, but that only covers the model call, not the hosting, database, or auth layer the AI tool wires up around it.
Can I still build a healthcare app with an AI coding tool?
Yes, for the parts that never touch PHI: marketing pages, scheduling UI, non-clinical workflows. Once real patient data enters the picture, the hosting, database, and auth need to run on BAA-covered services. The AI-generated code also needs a security review before it goes near that data.
What are the most common HIPAA gaps in AI-built healthtech apps?
PHI sitting in browser localStorage. No audit log on who viewed a patient record. Supabase row-level security left disabled or misconfigured. No signed BAA anywhere in the hosting stack. These are exactly what our audits check for.
What does Launch Ready Code check for HIPAA specifically?
Our Compliance Wing runs HIPAA Foundations checks alongside GDPR and EU AI Act coverage. We are not a HIPAA certification body, and we don't claim to be. We check whether the controls a BAA would require, access logging, encryption, tenant isolation, actually exist in your live app.
Research sources
- U.S. Department of Health and Human Services — Business Associate Agreement requirements under HIPAA
- Paubox — Is Lovable.dev HIPAA Compliant? (2025 update), quoting Lovable's terms of service on the PHI prohibition and BAA availability
- Jai Mittal, Founder & CTO, Launch Ready Code — Compliance and security findings pattern observed across AI-built app audits: PHI in browser localStorage, missing access logs, and disabled or misconfigured Supabase RLS are recurring gaps in vibe-coded healthtech prototypes.