Answer · Healthcare
Does an AI vendor need a business associate agreement?
If protected health information reaches it, yes, and the agreement is a precondition rather than a formality to complete afterwards.
If protected health information reaches the tool, yes. A vendor handling it on the practice's behalf is a business associate, and the written agreement is a condition of disclosing to them, not paperwork completed later.
The test is what the vendor does with the information, not what the product is called. A business associate is a person or entity that creates, receives, maintains or transmits protected health information to perform a function on behalf of a covered entity, and the obligation to have a written contract before disclosing to them sits at 45 CFR 164.502(e), with the required contents at 45 CFR 164.504(e). A model that summarises a chart, drafts a patient letter, codes an encounter or transcribes a visit is performing a function on the practice's behalf using protected health information, and none of that turns on whether anybody calls it artificial intelligence.
The contents are specified rather than left to the parties. The agreement has to establish the permitted uses and disclosures, require appropriate safeguards, require reporting of uses and disclosures that were not permitted, bind subcontractors to the same terms, support the individual rights the practice owes its patients, make records available, and deal with return or destruction of the information at the end. A vendor's ordinary terms of service address almost none of this, which is why an agreement is a separate document rather than a clause.
The subcontractor line is where AI arrangements most often break, and it is not a technicality. A tool that is itself built on somebody else's model has handed the information onward, and that downstream provider is a business associate of the business associate on the same terms. The question a practice should be able to answer is not whether the vendor signed, but who else ends up holding the information because the vendor signed.
In practice the agreement is available only on particular product tiers, and the tier the staff are already using is usually not it. This is the most common real-world failure: a practice signs an agreement covering an enterprise or healthcare plan while the clinicians continue to use the consumer application they had before, on their own accounts, with the same vendor's name on the screen. The agreement is not wrong; it simply does not cover the thing that is happening.
Some AI use in a practice sits outside this entirely, and identifying which is worth doing early. A model used to draft a policy, summarise a guideline, or answer a clinical question with no patient particulars in the prompt has not received protected health information and needs no agreement. The boundary is the prompt, not the intention, and the reason it is worth drawing explicitly is that it leaves a clear space where staff can work without a procurement cycle.
The agreement also does not do the second job people expect of it. It allocates obligations and creates a contractual route to enforce them; it does not establish that the vendor's engineering is sound, that inputs are not retained, or that the configuration the practice is running matches the one the terms describe. Those are separate questions, and the practice that treats a signed agreement as the end of the assessment has confirmed the paperwork rather than the arrangement.
Whether a vendor signs the agreement is a procurement question; whether one is required was decided the moment patient information reached their system.
Siddharth Sharma, Context Theory
Related questions
What if the information is de-identified first?
Then it is not protected health information and the agreement is not required — but de-identification has a defined standard, and a note with the name removed rarely meets it. The combination of dates, a rare condition, an employer and a postcode identifies people. If the practice is relying on de-identification, the useful question is which method was used and who determined it was sufficient.
Does the vendor being a covered entity itself change anything?
No. The relationship is defined by the function being performed, so a healthcare organisation providing a service to another practice is a business associate for that service. The category the vendor occupies for its own patients tells you nothing about the category it occupies for yours.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Dentists & dental services CPC | $8.00 | Category-wide |
| Average B2B first-response time | 42 hours | Category-wide |
LocaliQ / WordStream Search Advertising Benchmarks 2026 · Google + Microsoft Ads, 20 industries · Apr 2025–Mar 2026 · verified
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · hours · 1.25M inbound leads across 2,241 US firms · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Regulation | A covered entity may disclose protected health information to a vendor performing a function on its behalf only with satisfactory assurances in a written contract, and the required contents of that contract are specified rather than left to the parties to negotiate freely. | 45 CFR 164.502(e) for the requirement and 45 CFR 164.504(e) for the mandatory elements, alongside the model provisions published by the Department of Health and Human Services. |
| Software | A tool built on another provider's model passes the information onward, making that downstream provider a business associate of the vendor on the same terms, so the practice's real exposure is the list of parties that end up holding the information rather than the single signature it obtained. | Asking the vendor to name every subprocessor that receives inputs, and checking that list against the subcontractor clause in the signed agreement. |
| Procurement | Agreements are typically offered only on specific product tiers with specific configuration requirements, so a practice can hold a valid agreement while its clinicians continue using a consumer tier of the same vendor's product on personal accounts. | Comparing the plan and account named in the executed agreement against the accounts staff are signed into on their own devices. |
| Constraint | An agreement allocates obligations and creates a contractual remedy; it does not establish that inputs are excluded from retention or training, or that the configuration in use matches the one the terms describe, which remain separate assessments. | The vendor's retention and training documentation for the specific tier, read against the tenant settings the practice has actually enabled. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one