· 12 min read

How to Evaluate HIPAA AI Vendors: A 20-Point Checklist

A 20-point checklist for evaluating HIPAA AI vendors — BAA scope, the inference path, PHI handling, audit integrity, and the vendor's own posture.

Table of contents

Most AI vendors selling into healthcare will tell you they are HIPAA compliant. The phrase has almost no fixed meaning — it is a marketing claim, not a certification — so the burden of verifying it falls on the buyer. Nearly 70% of healthcare C-suite executives cite data privacy and security concerns as the primary barrier to AI adoption,[6] making a rigorous evaluation process essential. This checklist gives you 20 concrete questions to ask, grouped into five areas, so that “HIPAA compliant” stops being a slogan and becomes something you can confirm.

There is no such thing as a HIPAA-certified product. HHS does not certify software, and no third party can confer the status on a vendor’s behalf. What exists instead is a set of obligations the law places on you, the covered entity, and a set of obligations a vendor takes on contractually when it becomes your business associate. “HIPAA compliant,” said about a product, is shorthand for “this vendor can be a business associate and has built what that requires.” Whether that is true is a question of evidence, and the evidence is what this checklist asks for.

A useful evaluation question has two properties: it has a specific, documentable answer, and a wrong answer is disqualifying. “Are you HIPAA compliant?” fails both. Every question below is written to pass both. Each comes with one line on why it matters and what a good answer sounds like.

How to use this checklist

Run it against any AI vendor before patient data — PHI — moves through their product. Send it as a written questionnaire and keep the responses; the answers become part of your own diligence file, which is itself useful evidence if the deployment is ever examined. HIPAA’s Security Rule requires covered entities and business associates to conduct an accurate and thorough risk analysis of every system that creates, receives, maintains, or transmits electronic PHI.[1] An AI vendor is one of those systems. This checklist is the AI-specific portion of that analysis.

Two things make AI vendors harder to evaluate than the rest of your software stack. First, the data path is longer and less visible — the company you sign with is frequently not the company running the model, and prompts pass through routing and logging layers that never appear in the sales conversation. Second, the unit of regulated data is the prompt itself, a free-text field a user can fill with anything, including PHI the vendor never anticipated. A traditional database application has a fixed schema; you know where PHI can land. An AI prompt has no schema. That is why several of the questions below have no equivalent in a standard security questionnaire.

A vendor that answers all 20 with specifics is worth a closer look. One that answers with brochure language — “enterprise-grade security,” “fully compliant” — has told you something too, just not what they intended. For the full picture of what a compliant AI deployment requires, the complete guide to HIPAA-compliant AI is the place to start.

The BAA and its scope

A signed Business Associate Agreement is necessary and not sufficient. What it covers matters more than the signature.

  1. Will the vendor sign a BAA at the plan you intend to buy? Some vendors offer a BAA only on a top tier or as a paid add-on. Confirm the BAA applies to the exact plan and product you will use — a good answer names the plan; a bad one says “we can discuss it.”
  2. What services does the BAA explicitly name? A BAA covers the services described in it, not the vendor’s whole product line. If the BAA names “cloud hosting” but your PHI flows through a language model, the model is outside scope. A good answer lists the AI service by name.
  3. Does the BAA cover PHI processing, or only PHI storage? Storage and inference are different activities with different risk profiles. An AI system processes PHI in motion. Confirm the BAA contemplates processing, not just data at rest.
  4. Does the BAA prohibit use of your PHI to train or improve the vendor’s models? HIPAA’s minimum necessary standard limits PHI use to the intended purpose.[2] Model training is usually not that purpose. A good answer is a written prohibition in the agreement, applying to de-identified derivatives as well as raw data — not a line buried in a support FAQ.

The inference path and sub-processors

The vendor you contract with is often not the entity processing your prompt at inference time. The whole path has to be covered.

  1. Which company actually runs the model? Many AI products route prompts to a third-party model provider. That provider receives your PHI. Ask for the provider’s name. “We use a leading model” is not an answer.
  2. Does the vendor hold a BAA with that model provider? A business associate may use a subcontractor that handles PHI only after obtaining satisfactory written assurances — a BAA — that the subcontractor will safeguard it.[3] If the model provider is not under a BAA, the chain is broken regardless of what you signed.
  3. Can the vendor produce a current list of every sub-processor that touches PHI? Routing layers, logging services, and analytics tools can all see prompt data. Each is a sub-processor. A good answer is a published, dated list you can review — not a number with no names.
  4. Is PHI encrypted in transit across every hop, not just the first one? The Security Rule’s transmission security standard applies to the whole communications path.[4] Encryption between your app and the vendor’s first endpoint is not enough if a later hop sends data in the clear.

PHI handling before inference

A model provider under a BAA is the floor, not the ceiling. The stronger question is what the vendor does with PHI before the model ever sees it.

  1. Does the vendor inspect prompts for PHI before they reach the model? A vendor that simply forwards every prompt has no view into what is being sent. One that inspects prompts can enforce a policy on them. Ask whether inspection happens, and where in the path.
  2. Who operates the PHI detection — the vendor, or an outsourced tool? A vendor that runs its own detection can answer detailed questions about how it works and what it catches. One that has wired in a third-party tool is one step further from being able to stand behind the result.
  3. Can your organization choose the policy — send under the BAA, redact, or block? Some workflows need full clinical context sent under the BAA; others should have identifiers stripped first. Redaction should be a choice you configure, not something done to you by default. A good answer puts the policy in your hands. (For the trade-offs between the two, see PHI scanning versus redaction.)
  4. What happens to a prompt the policy blocks — is it logged, and how? A blocked prompt may itself contain PHI. If the vendor logs the attempt for debugging without treating that log as PHI, the block has created a new exposure. A good answer treats every record of a prompt as a regulated record.

The audit trail

HIPAA’s Audit Controls standard requires mechanisms to record and examine activity in systems containing PHI.[5] Most AI vendors log API traffic. Few produce records that would hold up in an investigation.

  1. What events are captured — prompts, model responses, access events, configuration changes? “We have logs” does not say what is in them. A good answer is specific: every prompt and response in full, every access, every policy change.
  2. Is the audit record tamper-evident, and by what technical mechanism? Logs an administrator can quietly edit are not an audit trail. Look for a concrete mechanism — cryptographic signatures, an append-only hash chain — not a policy that says staff are not allowed to alter logs.
  3. Where do the timestamps come from? A timestamp from the vendor’s own server can be changed by anyone with server access. A compliance-grade timestamp is anchored to an independent time source. Ask specifically.
  4. Can you export your audit records and verify them yourself, without the vendor’s software? An audit trail only the vendor can read or verify asks you to trust the vendor’s word. A good answer is a documented verification procedure you can run with standard tools. (HASP’s audit and trust documentation lays this out.)

Access control, retention, and the vendor’s own posture

The last four questions cover who can do what, how long records last, and whether the vendor’s own house is in order.

  1. Can access be controlled at the role level — who may submit PHI, who may see AI output? A consumer AI tool knows nothing about your org chart. A regulated deployment enforces who can do what with PHI as a technical control, not an honor system.
  2. Does the default retention period match your regulatory obligation? HIPAA requires security-relevant documentation be kept at least six years.[5] If the vendor deletes audit records after 90 days, the gap is yours to fill. A good answer meets or exceeds the six-year floor by default.
  3. Can the vendor honor a deletion request for a specific patient’s data? Patients have rights over their PHI, and your records policy may require targeted deletion. Confirm the vendor can act on a per-record basis, not just a wholesale account purge.
  4. What independent assurance can the vendor show for its own security program — and is it honest about what it does not yet have? A SOC 2 Type II report or equivalent is meaningful evidence. Just as meaningful: a vendor that tells you plainly which certifications it holds and which are still on the roadmap. A vendor that overstates its certifications has answered the trust question already.

A note on the answers you will hear

A few answers come up often enough to be predictable.

“We’re hosted on a HIPAA-compliant cloud” answers a different question than the one you asked. The cloud provider’s BAA covers infrastructure. It says nothing about the AI vendor’s own handling of PHI, the model provider behind the product, or the audit trail. Treat it as the start of the conversation, not the end of it.

“We don’t store your data, so HIPAA doesn’t apply” is wrong in a way worth correcting. Processing PHI — passing a prompt to a model — is a regulated activity whether or not the data is retained afterward. Transient handling still needs a BAA.

“We’re working toward SOC 2” is a fine answer when it is honest. A vendor still building its formal security program is not disqualified by saying so. A vendor that implies a certification it does not hold has told you how it handles inconvenient facts, which is the more useful signal.

What to do with the answers

The 20 questions sort vendors faster than any demo. The pattern is consistent: a vendor that has done the compliance engineering can answer with specifics, because the specifics exist. A vendor that has signed a BAA and left the rest to you will reach for adjectives. You are not being difficult by asking — you are doing the risk analysis HIPAA already requires of you.[1]

HASP is built to answer all 20 concretely: a BAA on every paid plan covering all four product surfaces, BAAs held directly with inference providers, PHI checked at the gateway under a policy you choose, and a signed, independently verifiable audit chain retained for seven years. The HASP Trust Center documents the sub-processor list and the audit verification procedure for exactly this kind of review. See how the coverage works on the BAA-included AI page, and how the records hold up on the audit trail page.

Sources

  1. U.S. Department of Health & Human Services. “Guidance on Risk Analysis Requirements under the HIPAA Security Rule.” HHS.gov. hhs.gov

  2. U.S. Department of Health & Human Services. “Summary of the HIPAA Privacy Rule.” HHS.gov. hhs.gov

  3. U.S. Department of Health & Human Services. “Business Associates.” HHS.gov. hhs.gov

  4. U.S. Department of Health & Human Services. “Summary of the HIPAA Security Rule.” HHS.gov. hhs.gov

  5. Office of the Federal Register. “45 CFR 164.312 — Technical safeguards” and “45 CFR 164.316 — Policies and procedures and documentation requirements.” eCFR.gov. ecfr.gov

  6. Sage Growth Partners. The 2024 State of AI in Healthcare (2024). sage-growth.com

Related pages

BAA-included AI One BAA that covers the AI tool and the inference path behind it. View → AI with a tamper-evident audit trail A signed, independently verifiable record of every prompt and response. View → The complete guide to HIPAA-compliant AI What HIPAA requires of an AI deployment, start to finish. View → HASP Trust Center Sub-processors, data flow, and audit verification documented for reviewers. View →

More from HIPAA + AI

HIPAA Security Rule and AI: What § 164.308 Requires of Vendors When you put AI into a HIPAA workflow, the AI vendor becomes a business associate. Here is how to evaluate that vendor through the lens of § 164.308. Read → Real HIPAA Violations From AI: What Regulators Have Penalized OCR has not yet fined anyone for an AI tool by name. That is a lag, not an all-clear. Here is what regulators have penalized that maps directly onto how AI fails. Read → Is ChatGPT HIPAA-Compliant? An Honest Answer for 2026 It depends on which ChatGPT, and the default answer is no. Here's what OpenAI's BAA actually covers in 2026 — and what a regulated team still has to build around it. Read →