"HIPAA Compliant" Is a Claim No Consultancy Can Make
There is a phrase that shows up on the websites of AI vendors selling into healthcare, and every experienced privacy officer has learned to read it as a warning rather than a reassurance. The phrase is "HIPAA compliant." It appears as a badge, a bullet point, sometimes a little shield icon next to the pricing. It is meant to close an objection before it is raised. For the reader it is supposed to reach, it does the opposite.
It does the opposite because the phrase, applied to a vendor's own company or product, is not quite true. Not in the way it is being used. And a healthcare compliance professional can tell within a sentence or two whether the firm across the table understands why.
This is a piece about that distinction. It matters more than it looks, because the gap between "HIPAA compliant" and what a vendor can honestly claim is exactly the gap where a covered entity ends up exposed.
Nobody hands out a HIPAA certificate
Start with the fact that quietly undermines most of these badges. There is no official HIPAA certification. The Department of Health and Human Services does not certify anyone as compliant. Its Office for Civil Rights, which enforces the rules, does not issue a stamp, a seal, or a passing grade that a company can then display. No government body confers HIPAA compliance on a product the way a lab certifies a smoke detector.
This is not a technicality. It is the whole shape of how HIPAA works. The law is built around obligations that an organization must meet and maintain, not a test it passes once and hangs on the wall. There are private firms that will assess an organization against the HIPAA rules and issue their own attestation, and that can be useful work, but it is their opinion, not a federal certification, and it describes a moment in time rather than a permanent property.
So when a vendor says it "is HIPAA compliant," the first honest question is: compliant according to whom, measured how, and as of when. Usually the answer is that the company decided the phrase sounded reassuring and put it on the site. That is not a lie exactly. It is something more slippery, and the people it is aimed at know it.
Compliance is a property of a program, not a product
The deeper reason the badge does not hold is that HIPAA compliance is not a feature a product can have. It is a property of an organization's ongoing program.
The rules ask a covered entity to do things continuously. Conduct and maintain a risk analysis. Put administrative, physical, and technical safeguards in place and keep them current. Write policies and actually follow them. Train the workforce. Control access to protected health information. Have a breach notification process ready before it is needed. None of that is a state you reach. It is a discipline you sustain, and it can lapse the week after anyone declares it achieved.
A piece of software cannot hold that property, because most of it is not about the software. It is about how an organization operates around the software. The best-designed system in the world sits inside a program that also depends on people, policies, access decisions, and response plans, none of which the vendor controls. This is why "our platform is HIPAA compliant" is a category error. Compliance is not the kind of thing a platform can be. It is the kind of thing a program does.
For the privacy officer, this is not abstract. It is the reason the vendor's badge cannot do the work the vendor wants it to do. The badge is trying to transfer a responsibility that is not transferable. Healthcare AI compliance lives in your program. A vendor can support it or undermine it, but a vendor cannot be it on your behalf.
What a vendor can honestly claim
The honest construction, the one a serious firm uses, is different by one word and by a great deal of meaning. A vendor does not build a HIPAA compliant system. A vendor builds HIPAA-ready architecture.
HIPAA-ready means the system is designed so that an organization operating it can meet its obligations: the technical safeguards are present, the PHI controls are real and inspectable, the logging exists, the access model supports the rules rather than fighting them. It is a claim about the architecture, which the vendor does control, rather than a claim about compliance, which the vendor does not.
The distinction sounds pedantic until you sit on the side of the person accountable for it. "HIPAA compliant" says: relax, we have handled this, it is off your plate. That sentence is false, and acting on it is dangerous. "HIPAA-ready" says: we built the system so that your program can stay compliant, and here are the controls you can inspect to confirm it. That sentence is true, and it leaves the responsibility where the law actually puts it, which is with the covered entity.
A firm that reaches for the shorter, cleaner-sounding phrase either does not understand the difference or is choosing to blur it. Neither is what you want in a partner handling PHI. The precise phrase is not a marketing weakness. It is the tell that the firm knows what it is doing. When you are evaluating HIPAA-ready AI for a healthcare workflow, the language a vendor uses about its own compliance is one of the fastest reads you get on whether they belong near your data.
The business associate reality nobody puts on the badge
There is a second layer the badge tends to skip, and it is the one privacy officers care about most.
A vendor that handles PHI on your behalf is, under the rules, your business associate. That is not optional and it is not a marketing category. It is a legal relationship, and it comes with a required contract: the business associate agreement, the BAA. The BAA sets out how the business associate will protect PHI, what it may and may not do with it, and what happens in a breach. A business associate that uses subcontractors who also touch PHI has to have BAAs with them in turn.
Since the 2013 Omnibus Rule, business associates have been directly liable for certain HIPAA obligations, not merely liable through their contract with the covered entity. So a vendor in this position is not outside HIPAA looking in. It has real obligations of its own. This is precisely why the loose "we are HIPAA compliant" badge is so telling. The vendor with genuine PHI responsibilities usually talks about the BAA, about its role as a business associate, about the specific safeguards it is accountable for. The vendor with a badge and no BAA discussion is often signalling that it has not thought this through.
For the privacy officer, the practical sequence is clear. If a vendor will touch PHI, it is your business associate. That relationship requires an executed BAA, a real signed document, not a logo. And even with the BAA in place, the covered entity remains responsible for its own compliance and for vetting the business associate in the first place. The BAA allocates responsibility. It does not make yours disappear.
The infrastructure underneath matters here too, and it is worth being precise. The major cloud providers offer BAAs for their in-scope services, which is what makes it possible to run PHI workloads on them at all. That is a real and important fact. It is also frequently misrepresented. "Built on HIPAA compliant infrastructure" quietly implies that the vendor's own handling inherits the cloud provider's posture, which is not how it works. The cloud provider's BAA covers the cloud provider's obligations. It says nothing about whether the vendor built its own layer responsibly on top.
Why the overclaim is the actual risk
It would be easy to treat this as a language quibble. It is not, because the overclaim creates a specific and familiar failure.
When a vendor tells a buyer "we are HIPAA compliant," it transfers a feeling of safety that is not backed by a transfer of responsibility. The buyer relaxes a control they should have kept. The diligence that should have happened does not, because the badge seemed to make it unnecessary. And then, if something goes wrong and the Office for Civil Rights asks questions, the covered entity discovers what the law always said: the accountability was theirs the whole time. "The vendor's website said it was compliant" is not a defense. It was never going to be.
So the real danger of the phrase is not that it is imprecise. It is that it encourages a covered entity to lower its guard at exactly the point where the guard is the thing that matters. A vendor that leads with the badge is, without meaning to, teaching its customers to do the one thing that will hurt them.
How to read a vendor by how they talk about compliance
Because the language is such a reliable tell, a privacy officer can get a great deal of signal before any technical review, just from how a firm discusses its own compliance.
The firm to trust is usually the one that will not call itself HIPAA compliant, and can explain why. It talks about HIPAA-ready architecture. It expects to sign a BAA where it acts as a business associate. It is specific about which obligations are its own and which remain yours, rather than implying it has absorbed all of them. It describes PHI controls you can inspect rather than adjectives you have to trust. When you ask what happens in a breach, it has an answer, not a reassurance.
A few questions surface this quickly. Ask the vendor to state, in its own words, the difference between HIPAA-ready and HIPAA compliant. Ask whether it expects to be your business associate and to sign a BAA. Ask which HIPAA obligations it considers its own and which it considers yours. Ask to see how PHI is minimized, how access is scoped, and how touches are logged. The firm that answers these cleanly is showing you the shape of its thinking. The firm that gets visibly uncomfortable, or retreats to the badge, is showing you something too.
What good actually looks like
Underneath the language, the substance a privacy officer wants is not exotic. It is PHI minimized before a model ever sees it, so the system is not holding more than it needs. Access scoped to who and what requires it, at the field level rather than the whole record. Every touch of PHI logged, so an incident can be reconstructed rather than reconstructed-guessed. A defined path for when an AI system is uncertain, so it escalates to a person rather than acting alone on sensitive data. And a real, executed BAA where the vendor is handling PHI, with a clear statement of who owns which obligation.
A firm that has all of that has no need for the badge, and generally does not use it. The controls are the argument. The precise language is a symptom of the same seriousness that produced the controls.
Trust the firm that tells you it cannot do this for you
The instinct behind "HIPAA compliant" on a vendor site is understandable. Healthcare buyers are cautious, the sales cycle is long, and a badge feels like it removes friction. But it removes the wrong friction. It is trying to close the exact question the privacy officer most needs kept open.
The firm worth trusting with PHI is the one that tells you, plainly, that it cannot be HIPAA compliant on your behalf, because no vendor can. It builds HIPAA-ready architecture. It signs the BAA. It is precise about where its responsibility ends and yours begins. That precision is not a firm being difficult. It is a firm that understands the thing it is being trusted with, and is telling you the truth about it before you have to find it out the hard way.
Compliance is a property of your program, not a line on a vendor's website. The vendors who say so are the ones who understand what they are handling.