AI-assisted “vibe coding” can dramatically lower the barrier to creating a useful healthcare application — but moving from a working prototype to one that actually handles protected health information requires deliberate decisions about vendors, secrets, authentication, database access, and infrastructure. HIPAA follows the data, not the appearance of the app. Something that looks finished can still be sitting on a stack that was never built to hold PHI.

Building a healthcare app with AI and not sure where the compliance gaps are?

Book a Free 15-Minute Consultation →

  • Vibe coding — describing what you want in plain language and letting an AI tool generate the code — has lowered the barrier to building healthcare software enough that clinicians with no engineering background are shipping real applications.
  • HIPAA doesn’t care whether a feature works. It cares what happens to the data behind it: which vendor touched it, whether that vendor signed a BAA, how it’s encrypted, and who can access it.
  • The riskiest habits are specific and repeatable: real PHI in a prototyping platform, PHI pasted into an AI chat tool to debug an error, AI silently routing data through an uncovered third-party service, hardcoded secrets, and authentication that never checks authorization.
  • A signed BAA is necessary, but it isn’t the whole answer. You can have a BAA with your host and still misconfigure permissions, storage, logging, or encryption underneath it.
  • The safer path is sequential, not simultaneous: prototype with synthetic data, take ownership of the code, inventory every vendor that could touch PHI, then harden secrets, auth, and the database before any real patient data enters the picture.

What Is Vibe Coding?

Vibe coding describes a development workflow where someone explains an application or feature to an AI system in natural language and lets the AI generate the underlying code. Instead of writing every function by hand, you might tell an AI assistant something like: “Create a dashboard that lets our staff search patients, view upcoming appointments, and send reminders.” The AI creates the database structure, the interface, the API connections, and the authentication flow behind it.

Josh Vidals, Cloud Engineer at HIPAA Vault, described just how mainstream this has become in a recent live session on the topic:

“I’ve seen stats that say about 85% of developers are using vibe coding tools now, or agentic engineering, or whatever the term is you’d like to use. Basically you’re giving the AI the vibe of the code you want, and the AI takes care of the heavy lifting for you.”

That’s useful for experienced developers looking to move faster. For clinicians and healthcare administrators with no coding background, it’s something bigger — a way to turn years of frustration with clunky software into a working prototype without becoming a software engineer first. Gil Vidals shared a real example of exactly that:

“I’ve heard, Josh, of a story of a doctor who was very frustrated in his practice because of the bureaucratic red tape and the technical department wasn’t assisting. So I heard he created a platform for his practice that had over 100 tools that would help him in his practice, and he did it successfully, and he was very pleased with the results of just vibe coding.”

The opportunity is real. So are the compliance gaps that come with it.

Why HIPAA Compliant Vibe Coding Requires More Than Working Code

HIPAA follows the data, not the appearance of the application. A feature can work perfectly in a demo and still be sitting on infrastructure that was never designed to hold PHI. If a cloud service creates, receives, maintains, or transmits electronic protected health information (ePHI) on behalf of a covered entity or business associate, HIPAA’s rules on cloud computing apply — which typically means a signed Business Associate Agreement (BAA), plus an actual risk analysis and the administrative, physical, and technical safeguards that go with it.

Josh Vidals put the underlying legal function of a BAA plainly:

“This is paperwork, but it’s really important — it’s a legal document that tells your clients that you have shared responsibility with them, that the patient information belongs to the patient.”

Gil Vidals added the piece that’s easy to miss: a vendor refusing to sign one isn’t a loophole, it’s the vendor being honest about what it doesn’t cover. “They’re saying, ‘Hey, don’t come to us, we don’t have anything to do with securing this pipeline or this platform for your medical data.’ They’re actually doing the right thing.” That’s precisely what happens with several popular AI prototyping tools, covered below.

The Biggest HIPAA Risks in AI-Built Healthcare Apps

1. Putting Real PHI Into a Prototype

Prototyping platforms are built to make an application easy to create — not to guarantee that every plan, feature, or storage mechanism is appropriate for PHI. Josh Vidals named this as the single biggest trap he sees:

“The problem that we’re seeing is that these providers are using these prototyping platforms like Lovable, Bolt, and Replit, but their standard tiers don’t offer BAAs. The provider goes to Lovable, they make a beautiful prototype, everything is working, and they may think, well, this is a prototype — if I take some patient health information in, it’s not a big deal. But it is. As soon as patient information is on this platform, you don’t have a BAA. It’s a breach of HIPAA. We actually reviewed the Lovable privacy agreement, and they explicitly say: do not host any PHI here. We take no responsibility for it.”

For early development, synthetic data is the cleaner approach — fake patients, fake appointments, fake insurance numbers — so the application can behave realistically without putting a real person’s information at risk.

2. Using AI Prompts Without Checking HIPAA Eligibility

Debugging is where real PHI most often slips in by accident. Josh Vidals walked through exactly how:

“If you’re a provider working on your application and you’re experiencing a problem, and you say, ‘Whenever I put Jane Doe’s name in with her phone number and her social security number, my application crashes — why is that?’ — you might feel tempted to copy and paste all that information, copy and paste the error, throw that into something like Claude, and say, ‘How come this is crashing my application?’ Well, as soon as you’ve taken that PHI and brought it over to Claude, they have that information logged now and they will train their next generation model on that. Unless you have a very expensive plan with Claude or OpenAI where they have signed a BAA and they have zero retention policies, you need to be really careful about what you’re putting into that prompt box.”

The product name alone doesn’t tell you whether a given AI service is eligible for PHI. Coverage varies by product, account type, and configuration — Anthropic’s own documentation limits BAA coverage to specific qualifying commercial services, not every Claude product and feature automatically.

3. Letting AI Choose Third-Party Services Without Reviewing Them

AI-generated code has to send data somewhere — email, SMS, storage, analytics — and it tends to reach for whatever’s easiest to wire up, without anyone checking if that specific service is covered:

“When the AI is writing the code on your behalf, a lot of times it’ll use whatever is the most common tool. If you’re going to be sending PHI from your application — say somebody fills out a form and that ends up turning into an email — the AI will code it and it will work. You test it, you get the email, you’re happy. What you don’t realize is that AI just used whatever common email platform it could find, and that particular email relay doesn’t have a BAA signed. Under the hood, AI could be using these — let’s just call them pipes — different pipes to do different work. And if those pipes don’t have a BAA and they’re not protected, you’re just relying on whatever choice AI decided to use on your behalf to send information out of the platform into the world.”

Every meaningful dependency deserves the same question: email, SMS, database hosting, file storage, analytics, backups, and any AI API your application calls. If a vendor can receive or maintain PHI, that’s a business-associate relationship, whether or not anyone decided that on purpose.

4. Hardcoding API Keys and Secrets

Josh Vidals flagged this as a habit AI coding tools fall into by default:

“AI loves to hardcode these keys into the codebase. You want to strip and rehome these secrets and make sure you’re using a scanner or something else to find these API keys and pull them out and put them in some kind of secret vault.” He specifically recommended Google Cloud Secret Manager as an easy option.

This isn’t only a HIPAA issue — it’s basic secure software engineering. NIST’s Secure Software Development Framework recommends building security in throughout development rather than bolting it on after the fact, and credential handling is one of the clearest examples of that principle.

5. Weak Authentication and Authorization

Authentication answers who you are. Authorization answers what you’re allowed to see. AI-generated code frequently gets the first one right and skips the second. Josh Vidals used a bouncer analogy to make the distinction concrete:

“If you have your AI that’s vibe coding create you an automated bouncer for a bar, and you program it to look at the ID, look at the age, and determine if that user can be let in based on their age — but you forgot to prompt the AI to also check the photo to make sure it’s the correct person. So the user’s in your application, and say in the URL bar they have patient one, record 101, and they’re authenticated to see that. However, if they erase that URL and put in record 102, and suddenly they’re looking at somebody else’s records that they’re not authorized to see — you forgot to bake in the authorization as well as the permissions that allow them to get in.”

Permissions need to be enforced on the server, not just hidden in the interface — an app that only checks whether someone is logged in, not whether they’re allowed to see a specific record, has a real access-control flaw.

6. Insecure Database Access

The same speed that makes AI-generated search forms and reporting tools fast to build doesn’t eliminate classic injection risks:

“If your code doesn’t sanitize what the user is typing in that search box, and it allows what they send to go directly to the database, a hacker could issue a command through that search box — they could say, drop all the tables, delete the database — and if that’s allowed to happen, it’s a big deal.”

Untrusted input should never flow directly into a database command. That requires deliberate query handling and access controls — not something to assume an AI-generated default already covers.

7. Treating a BAA as a Complete Compliance Solution

A signed BAA is necessary. It is not the whole architecture. HIPAA’s Security Rule requires covered entities and business associates to assess risks to the confidentiality, integrity, and availability of ePHI and implement the administrative, technical, and physical safeguards that follow from that analysis — a BAA on file doesn’t substitute for actually doing that. You can have a BAA with a fully compliant host and still misconfigure user permissions, leave storage public, skip encryption on a specific API connection, or fail to enable audit logging. The BAA is one part of the architecture, not the architecture itself.

Ready to move your prototype toward production? HIPAA Vault can review your architecture, scope out exactly what needs to change, and connect it to a BAA-covered production environment — a short review can surface these gaps before they become expensive production problems.

Book a Free 15-Minute Consultation →

Your AI Prototype Works. Is It Ready for Healthcare?

HIPAA Vault reviews your architecture, addresses compliance gaps, and deploys your application into secure, managed infrastructure.

Book a Free 15-Minute Consultation

A Safer Path From Vibe-Coded Prototype to Production

Step 1: Prototype with synthetic data. Build the workflow, test the interface, demonstrate it to investors or staff — using realistic but fictitious information rather than real patient records. Gil Vidals’ practical tip: “There are actually services on the internet where you can go and download a hundred thousand records of dummy data — they look like real addresses and real people’s names, but it’s all fictitious. You could also use AI to say, ‘Generate a thousand dummy records of fake patient information that I could load and import into my platform.'” Simply removing a name doesn’t automatically make information de-identified under HIPAA — HHS publishes specific standards for what actually qualifies.

Step 2: Take control of the codebase. Josh Vidals: “The first thing you want to do is take your code and take ownership of it, move it to something like GitHub or a git repo where you have complete control.” Watch for a specific trap here too — if PHI was ever in the prototyping platform, it can move into the repository along with the code during that transfer, and GitHub doesn’t sign a BAA by default either.

Step 3: Inventory every service that can touch PHI. Map the full data flow — browser to API to application server to database to email service to backup system to monitoring platform — and don’t stop at the hosting provider. For each vendor, confirm whether it can receive or maintain PHI, whether it’s acting as a business associate, whether a BAA is required and available for the exact service being used, and where the data is stored, retained, and accessible.

Step 4: Move secrets out of source code. Locate any credentials or tokens before deployment, rotate anything that may have already been exposed, and store secrets in a dedicated secrets manager with tightly limited access.

Step 5: Harden authentication and authorization. Confirm permissions match job responsibilities, sensitive records can’t be reached just by changing a URL or ID, administrative access is limited, and activity is logged sufficiently for both security and compliance review.

Step 6: Secure the database and APIs. Review query handling, public exposure, service accounts, network access, and backups. Confirm encryption is actually applied — Josh Vidals noted that “some of these services, the APIs aren’t encrypted… regardless of the BAA, the encryption and how you’re using those APIs for things like texting or email is really important.”

Step 7: Choose infrastructure that supports HIPAA requirements. As Josh Vidals summarized it: “Make sure you move to a host that will sign a BAA with you. Once you move on to that private infrastructure with encryption in transit, audit logging, access controls, you’re very close to having a HIPAA-compliant application.” HIPAA Vault’s HIPAA-compliant hosting solutions page covers what that actually requires beyond just picking a recognizable cloud provider.

Step 8: Perform risk and security testing before launch. A HIPAA risk analysis examines threats and vulnerabilities to the confidentiality, integrity, and availability of ePHI — HIPAA Vault’s risk assessment services can help structure that process. Depending on the application, that can also include code review, configuration review, and penetration testing.

Can You Still Use ChatGPT, Claude, and Other AI Coding Tools?

Yes. The lesson isn’t to stop using AI — it’s to know exactly what you’re giving it. Asked directly whether providers can keep using ChatGPT or Claude, Josh Vidals was clear:

“Absolutely. If you’re getting a syntax error or brainstorming, yes, you can use ChatGPT or Claude on their free or basic plans — you just want to avoid putting any kind of protected health information in that prompt box.”

AI assistants are genuinely useful for boilerplate code, debugging synthetic examples, explaining errors, generating test cases, and brainstorming architecture. The moment PHI is involved, though, the product name alone isn’t enough — verify that the exact service, account type, configuration, and retention settings are actually eligible, and that the required contractual protections are in place. Never assume a consumer-facing product is automatically approved for PHI just because an enterprise version of the same company’s product might be.

What Actually Counts as PHI?

A name by itself isn’t automatically PHI just because it appears somewhere in a healthcare application. Josh Vidals framed the technical starting point: “Any personal information that is linked to a human identity — that could be a phone number or address. Once I see that linked with a name, I start to think PHI.” Gil Vidals sharpened the line further:

“There’s PII — personal identifiable information, like your name, your address — but anytime you cross the line and start describing someone’s biology — the color of their eyes, the color of their hair, do they have a cold, a sinus infection, even their weight, how tall they are — you’ve crossed from PII to PHI, because now you’re describing someone’s biology. Where I draw the line is gender — if somebody puts their gender, that’s not necessarily considered patient information.”

That framing lines up with how HHS defines PHI: individually identifiable health information held or transmitted by a covered entity or business associate, generally relating to an individual’s health condition, healthcare, or payment for healthcare in a way that identifies or could reasonably identify them. Rather than memorizing a single rule, the safer question is: does this information relate to an identifiable person’s health, healthcare, or payment for healthcare, in a context HIPAA actually covers?

Vibe Coding Is a Starting Point, Not a Security Architecture

Vibe coding removes a huge amount of the expensive, time-consuming work of turning an idea into a working application. It doesn’t remove the need for a deliberate transition once that idea needs to hold real patient data. A prototype built with synthetic data is one thing; a production application handling PHI is another — and that transition is exactly where infrastructure, vendor review, access control, and HIPAA expertise become essential, not optional.

Getting help at that stage doesn’t defeat the purpose of vibe coding. It’s arguably the model’s biggest advantage: AI eliminates much of the cost of getting to a working prototype, which frees up expert time to focus where it matters most — reviewing the architecture, protecting patient information, and preparing the application for production.

Already built the app? You don’t need to start over. Contact HIPAA Vault to discuss your architecture and the steps needed to move your AI-built healthcare application toward a production environment designed to protect PHI. Quick consultation, practical next steps — no need to rebuild what’s already working if the architecture can be secured.

Questions to Ask Before Your Vibe-Coded App Goes Live

  • Has any real patient data ever touched our prototyping platform, or has development stayed strictly on synthetic data so far?
  • Do we know every vendor our AI-generated code actually calls — email, SMS, storage, analytics — and whether each one is covered by a BAA?
  • Are there any API keys or credentials still hardcoded in our codebase?
  • Does our app check not just whether someone is logged in, but whether they’re authorized to see the specific record they’re requesting?
  • If we have a BAA with our host, have we actually verified the permissions, encryption, and logging underneath it — or just assumed the BAA covers it?

FAQ

For informational purposes only, not legal advice — consult qualified counsel for your specific HIPAA obligations. Reflects a live HIPAA Insider Show session with Gil Vidals, CTO and Co-Founder, and Josh Vidals, Cloud Engineer, at HIPAA Vault, along with published HHS and NIST guidance as of the publish date.