Fifteen Security Questions Every Healthcare AI RFP Should Contain

Because the security review happens after somebody has decided. By then the questions read as obstacles and the answers get negotiated down rather than answered.

Put them in the RFP and they do three useful things at once. They sort the market, because a vendor that has been through a health system review answers within a day with documents attached, and one that has not takes a fortnight and sends marketing copy. They set the tone, because a vendor that knows you read its data terms sells differently. And they create the paper record, which is what you will need in eighteen months when somebody asks why you chose this vendor.

The questions below assume the vendor will handle protected health information, which any clinical or patient-facing AI agent does. If you are running a pre-demo screen rather than a full RFP, the shorter version is in the pre-demo HIPAA checklist. The regulatory background sits on the HIPAA and AI page.

Four questions, and ask for the document rather than a yes.

Question three is the trap that catches the most sophisticated buyers. A business associate agreement signed for the core product does not automatically extend to a new AI feature the vendor ships eighteen months later, particularly one routed through a different infrastructure or a new model provider. Ask for scope language that follows the product rather than the version, and re-ask the question at every renewal.

Question two matters more than it looks in a market with this much acquisition activity. The entity that signs the business associate agreement should be the entity on the order form and the entity that actually processes the data. Where those diverge, the agreement can end up governing a company that never touches your patients' information. The HHS sample business associate provisions are the reference point for what the document should contain.

By asking for the list, dated, rather than asking whether one exists.

1. 5. Please provide your current subprocessor list, including every party that processes protected health information.
2. 6. Which model providers are in that chain, and do they receive protected health information?
3. 7. How are we notified of a change to that list, and can we object?

A typical healthcare AI product involves at least a cloud provider, often a separate speech or transcription service, and frequently a separate foundation model provider. All of them may touch protected health information and all of them need business associate obligations flowed down. A vendor that names its cloud provider and stops has answered a third of the question.

Question six is the one that has changed most in the last two years. Ask specifically whether prompts and outputs are sent to a third party model API, whether that provider retains them, and for how long. The answers vary widely and legitimately. What is not legitimate is not knowing, and a vendor that cannot describe its own model chain in a paragraph should not be handling clinical conversations.

Question seven decides whether the answer stays true. A subprocessor list with no change notification commitment tells you the current state and nothing about the future. Thirty days notice with a right to object is the market norm at the enterprise end and is worth asking for even where you will not get it.

Four questions, and expect the answers here to vary more than anywhere else.

1. 8. Is raw audio, or the raw input, retained after the output is produced, and if so for how long?
2. 9. Can we configure retention, or is it fixed by your architecture?
3. 10. Is our data used to train shared models, and can we decline without losing function?
4. 11. If de-identification is claimed anywhere in that answer, by which method, and who verified it?

Question ten needs care in how you read the answer. There is a real difference between training a model that serves other customers, tuning a model that serves only you, and using aggregate operational data to improve a product. Vendors sometimes use one phrase for all three. Ask which of those three, in writing, and ask whether declining changes the product you receive.

Question eleven exists because de-identification is a term of art with a specific meaning under HIPAA, and it is frequently used loosely to mean that direct identifiers were removed. The safe harbour and expert determination methods are defined, and a vendor claiming de-identified data should be able to say which it used and who performed the determination. If the answer is neither, the data is not de-identified and every downstream claim built on that word needs re-reading.

Question nine matters operationally more than legally. Fixed retention you cannot configure is a fact about the vendor's architecture, and it means your retention policy has to accommodate theirs. That is workable if you know it before you write the policy and awkward afterwards.

Somebody can, and the useful question is who and under what controls, not whether.

1. 12. Are transcripts, prompts and outputs logged, and which internal roles can read them?
2. 13. Is support access to customer data logged and available to us on request?
3. 14. Do you use production data in testing or model evaluation, and if so under what controls?

Support access to logs containing clinical conversations is normal, often necessary to fix a problem, and rarely disclosed proactively. It should be role-limited, logged, and something you can audit rather than something you discover. A vendor that answers question thirteen with a screenshot of an access log has answered well.

Question fourteen is the one that finds gaps. Production data used to build evaluation sets is a common engineering practice and a common source of copies nobody has inventoried. Ask where those copies live, how long they persist, and whether they are covered by the same retention answer you got to question eight. This is the point where the NIST AI Risk Management Framework language about mapping data flows becomes concretely useful rather than abstract.

These three questions are also where a vendor's honesty is most visible. A slightly worse answer stated plainly is a better sign than a better one you had to extract over three emails, because it tells you how the relationship will behave when something goes wrong.

The last question, and the one most often left out of an RFP entirely.

15. At termination, what is returned to us, in what format, within how many days, and what is deleted from your systems and from every subprocessor?

Four parts, all of which need separate answers. Return covers your notes, transcripts and structured outputs in a format you can actually load somewhere. Timing needs a number of days. Deletion needs to extend to backups with a stated backup rotation period, because a promise to delete that leaves data in backups for a year is a different promise. And it needs to cover subprocessors, which is where the flow-down from question five becomes real rather than theoretical.

Ask this question during the RFP, not at renewal. The leverage is entirely front-loaded, and a vendor that will commit to a 30 day export in writing before signature will rarely commit to it afterwards. If you are comparing several vendors, put the answers side by side; the spread on this single question is usually wider than the spread on price. The vendors we have assessed against these criteria are on the HIPAA-compliant AI tools shortlist.

The fifteen questions above cover data. An agent that takes an action needs three more, because the risk moves from disclosure to consequence.

Ask what the agent is permitted to do without a human in the loop, expressed as a list rather than a philosophy. Booking an appointment, cancelling one, sending a message to a patient, and posting to the chart are four different permissions and should be four different settings. A vendor that cannot enumerate them has not built the controls.

Ask what happens at the edge of competence. A voice agent that misunderstands a caller should transfer, not improvise, and the vendor should be able to say what triggers the transfer. This is the question that most distinguishes a production phone agent from a demo, and it applies equally to scheduling and intake agents.

Ask whether the product ever suggests a diagnosis, an order or a treatment. A tool that only handles logistics or drafts what was said sits in a different regulatory position from one that recommends, and the boundary matters because it is where the device question begins. The current federal position is on the FDA page, and the answer should be in writing rather than in a sales call.

On two axes, and keep the vendor's own words.

The first axis is content: does the answer meet your requirement. The second is clarity: how quickly and how plainly did it arrive. Score both. A vendor with a slightly shorter retention window who answered in a day with attachments is a better counterparty than one with a perfect policy you had to extract, because procurement behaviour predicts incident behaviour.

Record the answers verbatim in a table with the date and the name of the person who gave them. That table is the answer when someone asks in a year why you chose this vendor, and it is the artefact a regulator or an insurer will ask for. It also makes renewal trivial: you re-ask the same fifteen questions, diff the answers, and see what moved.

Two practical notes. Some questions have commercially sensitive elements and a vendor may reasonably want a mutual non-disclosure agreement in place first, which is fine and normal. And a refusal is itself an answer: a vendor that will not say, at any stage, whether it trains on your data has told you something you can act on.

These fifteen questions handle the compliance screen. They do not tell you whether the tool works, which is a separate exercise with its own metrics, covered in the pilot metrics post. Nor do they cover integration feasibility, which is in the EHR integration questions. If you would rather run all three screens with someone who has done it before, that is what the vendor selection engagement is, and the deliverable is the scored table rather than a recommendation you have to take on trust. Where the finding is that your governance needs work before any vendor is chosen, the governance and compliance engagement is the follow-on.