# The Agent Told Me It Was HIPAA Compliant

AI can generate convincing healthcare software. It cannot declare your product safe, legal, or compliant just because the checklist looks complete.

Published: June 15, 2026
Tags: AI, Healthcare, Cybersecurity, Compliance

Canonical URL: https://michaelrispoli.com/blog/the-agent-told-me-it-was-hipaa-compliant/

A friend recently told me they had vibe coded a patient management system.

Not a scheduling app. Not a little intake form. A full patient management system. Most importantly, they told me it was fully HIPAA compliant.

So I asked the obvious question.

"How do you know?"

"The agent told me," they replied.

This is the trap we are walking into with AI-generated software. We are not just asking agents to write code anymore. We are asking them to tell us whether the thing they wrote is safe, legal, secure, compliant, scalable, production-ready, and appropriate for real humans to rely on.

And the agent, being an agent, will often give us the most dangerous answer in software:

"Looks good to me."

This gets especially messy with HIPAA because HIPAA compliance does not work the way many founders think it works.

I find that people lump HIPAA and SOC 2 into the same bucket. However, SOC 2 has a more familiar shape. You hire an auditor. You define controls. You go through an audit window. You receive a report. It may be Type I or Type II. There is paperwork, process, and a thing you can point to when a customer asks.

HIPAA is different. There is no SOC 2-style attestation report for HIPAA, and no official government-issued certificate that blesses your app and sends you into the world with a gold sticker.

And yet we see that language everywhere.

This database is HIPAA certified. This hosting provider is HIPAA compliant. This AI tool is HIPAA ready.

When a vendor says it is "HIPAA compliant," what it usually means is not "some official governing body has certified our entire company and every possible way you might use this product." It usually means something closer to this: we have relevant controls, we may sign a Business Associate Agreement, we support encryption, we have access controls, we log activity, and we have internal processes around protected health information.

Maybe they have done serious third-party reviews. Maybe they have mapped controls to HIPAA. Maybe they have a real security team. Maybe they are doing the work. That still does not automatically make your application HIPAA compliant.

So when someone says they have a "HIPAA certificate," my follow-up question is always:

Issued by whom?

Was it an internal self-assessment? A third-party consultant? A security firm mapping controls to HIPAA? A training certificate someone received after watching a course? Did anyone review the actual product behavior, vendor agreements, policies, access controls, audit logging, risk analysis, incident response, and engineering workflows?

Those are not the same thing.

A serious third-party HIPAA assessment can be valuable. I am not saying outside reviews are fake or useless. A good compliance partner can identify gaps, document your program, improve controls, and create evidence that you are taking the law seriously.

But that is not the same as an official government certification.

And it definitely does not mean every product workflow, vendor integration, admin panel, logging tool, AI prompt, staging database, and support process is automatically safe forever.

That is why "we have a HIPAA certificate" should not end the conversation. It should start it.

What was in scope? What was out of scope? Did the review cover the actual application or only the infrastructure? Did anyone inspect how PHI moves through the system? Did they evaluate internal access to patient data? Did they review BAAs with vendors? Did they test audit logging? Did they examine breach response procedures? Did they look at whether developers can casually view plain-text PHI inside an admin interface?

Without those details, a HIPAA certificate can just be security theater. It may look reassuring in a sales deck, but it does not tell you whether the system is actually being operated in a compliant way.

This is the part people miss. HIPAA compliance is not a property you inherit by choosing the right database. You cannot sprinkle MongoDB, Neon, Vercel, AWS, or some AI coding agent over your app and suddenly become compliant.

A compliant vendor can still be used in a non-compliant way. A secure database can still store the wrong information. An encrypted server can still expose patient data through a broken authorization rule. A good cloud provider can still be misconfigured. A signed BAA does not save you from bad product decisions.

One of the clearest examples is something I see all the time:

"The database is encrypted at rest."

Great. Wonderful. Love that for the database.

But then a developer logs into an admin panel, database browser, error monitoring tool, customer support dashboard, or internal UI and can see every patient row in plain text. Encryption at rest matters. TLS matters. Vendor due diligence matters. But none of that means much if every engineer can browse patient records over lunch. The data may be encrypted on disk, but operationally it is sitting there exposed in the tools your team uses every day.

In a properly thought-through healthcare system, PHI should not be visible to engineers just because they work on the product. Access should be limited to the minimum necessary. It should be role-based. It should be logged. It should be reviewed. In many cases, it should require a break-glass workflow where someone has to explicitly justify why they are accessing sensitive data.

"Encrypted at rest" is not the same thing as "protected from unnecessary human access."

A lot of teams confuse infrastructure security with compliance. They look at the cloud architecture and say, "We are good. The database is encrypted. TLS is on. The vendor signs a BAA."

But HIPAA is not only about whether the hard drive is encrypted. It is about who can access protected health information, why they can access it, whether that access is necessary, whether it is monitored, and whether the organization has controls around how that information is used.

The uncomfortable truth is that HIPAA compliance is not just infrastructure. It is architecture, operations, policies, people, process, training, access control, auditability, risk management, incident response, and a real understanding of where protected health information lives in your system.

It is not one thing. It is not a checkbox. It is not something an agent can declare after generating a Rails app on a Tuesday afternoon.

Broadly speaking, when people talk about HIPAA compliance, they are talking about whether the organization and system can protect PHI, which means protected health information. That means asking questions like:

Who can access this data? Why can they access it? What do we collect? Do we actually need all of it? Where is it stored? Is it encrypted in transit and at rest? Which vendors touch it? Do those vendors sign BAAs? What happens when an employee leaves? What happens if a laptop is stolen? What happens if a patient asks for their data? What happens if there is a breach? What gets logged? Who reviews those logs? How do we know someone did not access something they should not have?

And maybe the most important question:

How do we prove any of this? Because "the agent told me so" is not proof.

When it comes to HIPAA, compliance isn't just something you obtain. You can't just look at the code and determine it. It is embedded into the way your organization operates.

You do not become HIPAA compliant once and then stop thinking about it. You maintain it. You review it. You update it. You train people. You evaluate vendors. You respond to changes in the product. You revisit permissions, risk, and assumptions.

This is also why it is wrong to talk about HIPAA compliance as if it means "a breach can never happen."

Major hospitals, insurers, clearinghouses, and healthcare vendors get breached. Some have sophisticated teams, expensive tools, compliance programs, lawyers, security policies, and signed agreements all over the place. Attackers still get in.

Change Healthcare is the obvious modern example. This was not a weekend project with a login screen and a dream. It was a major healthcare technology company inside UnitedHealth Group, processing a massive share of healthcare claims infrastructure in the United States. In 2024, it suffered a ransomware attack involving protected health information.

The lesson is not "therefore compliance is fake." The lesson is that compliance does not mean nothing bad ever happens. Compliance means you have the systems, records, policies, logs, contracts, and procedures to know what happened, what systems were affected, what data may have been exposed, who needs to be notified, who is responsible, and what happens next.

A serious HIPAA program should help you answer ugly questions after an incident. When did the attacker get in? What did they access? Was PHI involved? Which individuals were affected? Which vendors were involved? Were the right agreements in place? Who needs to be notified? What controls failed? What are we changing so it does not happen the same way again?

That is part of what compliance is. It is not a force field. It is a system of accountability.

This is why the AI era makes the problem both better and worse.

AI can help generate the first version of a policy. It can map data flows. It can summarize HIPAA requirements. It can write security checklists. It can identify obvious risks in code. It can produce documentation that would have taken a team days to assemble manually.

But AI can also create an extremely convincing compliance-shaped object. It can write the code, write the policy, write the privacy page, generate the checklist, and tell you the checklist passed. If nobody in the room knows enough to challenge it, you now have the illusion of compliance at software speed.

That is the danger.

Not that AI writes bad code. Bad code is fixable. The danger is that AI writes plausible code, wraps it in plausible documentation, and gives a plausible explanation for why everything is fine.

A shocking amount of compliance risk hides in boring places: error logs, analytics tools, customer support dashboards, session replay software, email notifications, PDF exports, CSV downloads, AI prompts, internal admin panels, backups, staging databases, and screenshots in Slack.

The real world of HIPAA is not just "is my production database encrypted?" It is "did someone paste a patient note into a support ticket that is now sitting inside a tool with no BAA?" It is "does our bug tracker contain screenshots of medical records?" It is "can every developer open the database and read patient rows?" It is "are we sending PHI to an AI model without understanding what happens to that data?"

That is where systems fail.

So how do you handle this yourself?

The easiest first step is to evaluate whether you actually need all the PHI you are collecting. Many founders bias toward collecting more information than they need in case they need it someday. Data can be a moat for a company. But that data can also increase your risk substantially.

After you've determined you're collecting only the data you need, start treating HIPAA as an operational system, not a marketing claim.

You map every place PHI enters, moves, rests, leaves, and gets destroyed. You make sure every vendor that touches PHI is willing to sign a Business Associate Agreement. You implement strong access controls, not just login screens. You encrypt data in transit and at rest. You separate roles and permissions. You prevent engineers from casually browsing PHI. You log access to sensitive data. You review those logs. You write actual policies and make sure the team follows them. You train the people who touch the system. You create a breach response plan before there is a breach. You perform a real risk analysis and update it as the product changes. You document your decisions.

And when the stakes are high enough, you bring in a qualified compliance or legal expert who understands healthcare.

One of the worst follies in software is believing that technical competence automatically creates legal or regulatory competence. A great engineer can build an insecure healthcare app. A great product team can design a workflow that collects far more sensitive data than necessary. A great AI agent can confidently misunderstand the entire compliance model.

That is why the phrase "fully HIPAA compliant" should make us a little suspicious. Not because it is always false, but because it is usually incomplete.

The better statement is more specific:

We have performed a HIPAA risk analysis. We know where PHI exists in our system. We have signed BAAs with vendors that touch PHI. We have administrative, physical, and technical safeguards in place. We have documented policies and procedures. We have audit logs and access controls. We have limited internal access to PHI. We have a breach response process. We have reviewed this with someone qualified.

That is a very different sentence than "the agent told me."

The future of software is going to include a lot more people building things they never could have built before. That is mostly good. But in healthcare, finance, education, and other sensitive spaces, the ability to build faster does not remove the obligation to think harder.

If anything, it raises the bar. Code is cheaper than ever but good judgment is more valuable than ever. And the real question is not whether an agent can generate a patient management system. Of course it can.

The question is whether anyone involved knows enough to know when the agent is wrong.