HIPAA and AI: what a small healthcare company should expect from its AI vendor

If you run a small healthcare or medical device company, you are going to be pitched AI. Some of it is useful. All of it raises the same question your compliance officer will ask: what happens to patient data? This guide is the plain-English version of what to expect from any vendor who wants to put AI near protected health information (PHI), written so you can hold them to it. It is not legal advice, and you should run anything that matters past your counsel.

The short answer

An AI vendor that touches PHI is a business associate like any other. That means a signed Business Associate Agreement before any data moves, a clear answer to where your data goes and how long it stays, controls you can verify (encryption, access limits, audit logs), and a vendor who will tell you plainly what their product does not do. If a vendor hesitates on any of these, that is your answer.

First, figure out whether PHI is involved at all

Not every AI project touches PHI. Drafting marketing copy, summarizing your own internal policies, or helping reps write follow-up emails about a device can all be done without patient data. Many of the best first AI projects are like this, and the compliance burden is close to zero. Before you evaluate a vendor's HIPAA story, ask whether the project needs patient data in the first place. Often it does not, or it can be done with de-identified data instead.

De-identified data is data stripped of identifiers under one of HIPAA's two methods: removing the eighteen specified identifiers (the "Safe Harbor" method, described in HHS guidance) or having a qualified expert determine the re-identification risk is very small. De-identified data is no longer PHI, and the rules below do not apply to it. For how this plays out in a registry that holds implant serial numbers, see our clinical registry software guide. Realistic synthetic data, generated to look like your records without being anyone's, is another way to build and test without PHI at all.

The Business Associate Agreement

Under HIPAA, a vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate, and you are required to have a written agreement with them that spells out how they will protect it. An AI vendor whose model reads your patient records is squarely in that category. The "conduit" exception, which covers services like the postal service or an internet carrier that merely pass data through without accessing it, does not apply to a service that processes the content.

A useful BAA from an AI vendor should cover, at minimum:

• Which specific products or services are covered. Vendors often cover their enterprise or API tier and not their consumer app. Make sure the thing you will actually use is named.
• Permitted uses. The vendor may use PHI only to provide the service to you. Training their models on it is not providing the service to you.
• Safeguards and subcontractors. The vendor commits to appropriate safeguards and to flowing the same obligations down to any subcontractor that touches your data.
• Breach notification. How quickly they tell you if something goes wrong, and what they tell you.
• Return or destruction of PHI when the relationship ends.

If the vendor answers with a compliance claim and no agreement attached, keep asking. There is no official HIPAA certification, and the Department of Health and Human Services does not recognize one. A claim of compliance is a marketing statement. A BAA is a contract.

Which AI services are actually covered

This is where small companies most often get tripped up, because the same company can offer a product that is covered and one that is not.

• Consumer chat apps and free tiers are not covered. No BAA, and often the default is that your conversations may be retained or used for training. Nothing with PHI belongs in them, however careful the person typing is.
• The major cloud platforms' hosted AI services are generally covered under the platform's standard BAA, which many small companies already have in place for other cloud services. Coverage usually applies only to specific services and regions, so check the platform's list of eligible services rather than assuming.
• Direct API access from model vendors is covered by some vendors for eligible business customers, typically on the condition that data retention is turned off (often called zero data retention). You usually have to request it.
• AI features inside software you already buy (your EHR, your practice management system, a document tool) are covered only if that vendor's BAA with you covers the new feature. New AI features are often added under separate terms. Ask.

The chain of agreements

A question we hear from device companies: if our software vendor signs an agreement with an AI model provider and sends our patient data to that provider's API, is that a violation? No. That is the arrangement HIPAA is built for, as long as every link in the chain has its own agreement and the use stays inside what the agreements allow.

With both agreements signed, sending PHI to the model is a permitted disclosure. What turns it into a violation:

• A missing link. An agreement with the model provider but none with you, or the reverse. Your agreement with the vendor also has to allow subcontractors, and some require notice or approval of each one.
• The wrong tier. Model providers that sign a BAA do so for API access by eligible business customers, usually with data retention turned off. The consumer app and the standard tier are outside the agreement no matter who signed what.
• Use beyond the purpose. Your vendor may use the PHI only to do the work you hired it for. Using it to improve the vendor's own product, or sending more than the minimum the task needs, is a problem even with every agreement in place.
• Configuration drift. The agreement says no retention and no training. If the account is not set up that way, the paper does not help.

One thing worth knowing: since 2013, business associates have been directly liable under the Security Rule. The agreement does not move your vendor's obligations onto you. It writes them down.

Where your data lives, and for how long

A vendor should be able to answer these in a sentence each. If they cannot, they do not know, and that is worse than a bad answer.

• Where is it processed? Which country, which region, and whether you can choose.
• Is it retained, and for how long? Many AI services keep prompts and outputs for a period for abuse monitoring. Under a BAA, you want that period as short as the vendor allows, or zero.
• Is it used for training? The answer must be no, in writing.
• Who else sees it? Subprocessors, support staff, and any human review of outputs. Each is a disclosure.
• What happens in logs? Application logs, error reports, and analytics are the places PHI leaks by accident. A careful vendor can tell you what their logs contain.

Audit logs that are actually useful

The Security Rule asks you to record and examine activity in systems that contain PHI. For an AI feature, a useful audit log records who made the request, when, what data was sent (or a reference to it), what the model returned, and what the person did with the result. It should be kept somewhere it cannot be quietly edited, and your team should be able to read it without asking the vendor. If the vendor's answer is "we have logs" with nothing more, ask to see one.

The controls you should expect by default

• Encryption in transit and at rest, using managed encryption rather than something hand-rolled.
• Access limited to role and need, with multi-factor authentication on anything administrative.
• Minimum necessary data. The AI feature sees the fields it needs. If it can work on de-identified data, it should.
• Separation of environments. Development and testing use synthetic data. Real PHI lives only in production.
• A written data flow. Every system that touches PHI, listed, with the agreement that covers it. If a vendor cannot produce this, they have not thought it through.

The proposed HIPAA Security Rule changes

In January 2025, HHS published a proposed overhaul of the HIPAA Security Rule, the first major revision since 2013. The public comment period closed in March 2025, and as of October 2026 the rule is still proposed, not final. HHS's regulatory agenda targets final action in July 2027, and that date has already slipped once.

Nothing in the proposal is law yet. The current Security Rule applies today and is being enforced. But the proposal is worth reading now, because it describes practices that are already reasonable to expect from any vendor. Among the changes it would make:

• Removing the distinction between "required" and "addressable" safeguards, so that practices many organizations treated as optional become mandatory.
• Requiring multi-factor authentication and encryption of PHI in transit and at rest, with limited exceptions.
• Requiring a written inventory of technology assets and a map of how PHI moves through your systems.
• Requiring the ability to restore critical systems within 72 hours of an outage.
• Requiring annual compliance audits, vulnerability scans at least every six months, and penetration testing at least annually.
• Requiring that business associates verify their safeguards to you in writing at least annually.

If it is finalized in roughly its proposed form, compliance would be required about 240 days after publication. The practical advice is simple: choose vendors who already meet this bar, so that when the rule lands you have nothing to renegotiate.

One more question for product companies

If you make software or devices that clinicians use, adding an AI feature can change your product's regulatory status. The FDA regulates some software as a medical device, and its Clinical Decision Support guidance (updated in January 2026) draws the line between decision support that is excluded from device regulation and decision support that is not. Ask any vendor or developer proposing an AI feature whether they have considered this, and involve your regulatory counsel before you build. A vendor who waves the question away is a vendor who will leave you holding it later. We walk through the test itself in Does adding AI make our software a medical device?

Questions to ask any AI vendor

• Will you sign a BAA that names the specific service we will use?
• Where is our data processed, how long is it retained, and is it ever used for training?
• Who are your subprocessors, and do they carry the same obligations?
• Can we see a sample audit log and a data flow diagram?
• How do you handle a suspected breach, and how fast do you tell us?
• Can this feature run on de-identified or synthetic data instead?
• For product features: could this change our regulatory status, and who checked?

How Skye Road handles this

We work the way this guide describes, because it is the only honest way to do the work. PHI stays in your environment. Only services covered by a BAA touch it. Encryption, access controls, and audit logging are defaults. We build and demo with synthetic data, and we flag regulatory questions before anything is built. The full version is on our security and health data page. If you are weighing where AI fits in a healthcare or device business, start with what we build for healthcare companies or the AI Opportunity Assessment.

The bottom line

HIPAA does not prohibit AI. It asks the same thing of an AI vendor that it asks of any vendor: an agreement, real safeguards, and evidence. A good vendor answers these questions before you ask. If you have to drag the answers out, you already know what you need to know.