If an AI vendor touches PHI, I treat the BAA as required - but I never treat it as enough. In healthcare AI deals, the BAA covers HIPAA rules for PHI, while the main contract covers service terms, security checks, incident timing, data rights, and model-change rules. If I rely on just one document, I leave gaps.
Here’s the short version:
- BAA: use, storage, disclosure, return, and destruction of PHI
- Main contract: pricing, scope, uptime, support, backups, audit rights, and exit terms
- AI terms: training limits, prompt/log retention, update notice, rollback rights, and output performance rules
- Timing rule: the BAA must be signed before PHI is shared
- Big risk: many AI vendor terms allow input/output reuse unless I block it in writing
HIPAA rules at 45 CFR §§ 164.502(e) and 164.504(e) apply when a vendor creates, receives, maintains, or transmits PHI for a covered entity. And HHS has said that even a cloud provider that only stores encrypted PHI can still count as a business associate. That means “we never look at the data” is not a safe shortcut.
BAA vs. Standard Contract: Healthcare AI Vendor Obligations at a Glance
What Is HIPAA BAA Compliance For Third-party Vendor Access In Healthcare? - AI and Technology Law
Quick Comparison
| Item | BAA | Standard contract |
|---|---|---|
| Main job | HIPAA rules for PHI | Business, service, and security terms |
| Trigger | PHI is involved | Any vendor deal |
| Data use limits | Permitted PHI uses and disclosures | Input/output rights, reuse limits, training terms |
| Security terms | HIPAA safeguards | SLAs, audits, testing, backup, recovery |
| Incident timing | PHI/security event notice | Outage response and tighter notice windows |
| AI model controls | Often limited or silent | Update notice, testing, rollback, performance checks |
| End of deal | Return or destroy PHI | Data export, transition help, shutdown terms |
My takeaway is simple: a BAA sets the HIPAA floor. The main contract has to handle the rest, especially for AI systems that log prompts, reuse data, or change model behavior after launch.
BAAs for AI Vendors: HIPAA Duties Tied to PHI Handling
A BAA is a PHI-focused HIPAA contract. It is not a full AI risk agreement. At a minimum, it should define allowed PHI uses, require HIPAA safeguards, set breach notice duties, pass those duties to subcontractors, and require PHI return or destruction when the contract ends[2][6][3][12][4][11][10].
Core Security Clauses a BAA Should Address
The agreement should say, in plain terms, what the vendor may do with PHI and ban anything outside that scope. It should also require administrative, physical, and technical safeguards for ePHI, including access controls, encryption, and workforce policies.
Reporting duties matter too. The vendor must notify you about any unauthorized PHI use or disclosure, any security incident, and any breach of unsecured PHI. The BAA should set clear notice deadlines[12][4].
If the AI vendor relies on cloud hosts, annotation services, or model vendors that handle PHI, those subcontractors need to be bound by the same HIPAA duties. And when the contract ends, the vendor should return or destroy all PHI. If that cannot be done, the protections must stay in place and any further use must be limited[10][2][3][4].
Its job is to set the HIPAA compliance floor, not to manage every part of AI performance or model risk[2][6][7][1][8][14]. That’s where things get tricky for AI tools. The toughest issues usually show up around training, prompts, logs, and retention.
AI-Specific BAA Issues: Training, Prompts, Logs, and Retention
Those basic HIPAA duties get harder to apply when a vendor also wants to use AI inputs and outputs to improve its system. In many deals, the biggest problem is data reuse. AI platforms often give themselves broad rights in their standard terms, including the right to use inputs and outputs for model improvement. If the BAA says nothing, those standard terms may still permit reuse[1][9].
That is often the main point of failure in healthcare AI contracts. The BAA should say whether PHI, prompts, outputs, or logs can be used for training, debugging, service improvement, or human review[1][8]. If de-identified data is allowed for those uses, the agreement should define the de-identification method and bar re-identification. Otherwise, weak de-identification can still leak PHI through prompts and outputs[1][9][5].
The BAA should also set retention periods for prompt logs, inference records, and backups. And it should give you the right to ask for proof that the vendor is following PHI-handling limits, not just offering a broad promise of HIPAA compliance[1][8][6][7].
The rest of the service, security, and model-risk terms should sit in the main contract.
sbb-itb-535baee
Standard AI Vendor Contracts: Security, Operational, and Commercial Terms
After PHI handling is addressed, the main contract takes over. The BAA protects PHI. The main contract sets the rules for how the AI service runs, where risk sits, and what the vendor still owes outside PHI use.
That matters because the main contract covers the day-to-day and business terms the BAA doesn't touch: uptime, incident response, audit rights, model governance, and data rights for inputs, outputs, and derivatives.
Security and Service Terms That BAAs Do Not Cover
Your main contract should spell out uptime, incident response, audit rights, and data portability in plain terms.
Uptime and incident response: Set uptime SLAs, plus response and resolution deadlines based on severity. If there's a security incident, require customer notice within 24 to 72 hours instead of leaning on HIPAA's outside breach-notice timeline[20][19][18].
Third-party security evidence: Require current security reports, test results, and scheduled audit rights. If a vendor says, "trust us", that's not enough. You want proof on paper.
Business continuity and exit terms: Define RTOs and RPOs, backup frequency, and a usable data export at exit. If the relationship ends, the data can't leave in a format that's technically exportable but useless in practice.
Once baseline security is in place, the next risk is model change.
AI Governance Clauses for Model Updates and Performance Risk
In clinical use, an unannounced model change can shift output quality or safety overnight. One update, and the tool may behave differently from what your team tested last week.
That's why the contract should require:
- Advance notice of major model updates
- Pre-production testing
- Written approval from the AI governance or clinical safety committee
- Rollback rights if performance drops or unsafe outputs appear[15][16]
Output quality, bias monitoring, and explainability are becoming core contract terms for clinical AI. The contract should name performance thresholds - such as accuracy, sensitivity, and specificity - and tie them to agreed validation datasets. It should also require periodic reporting across demographic groups and clear mitigation plans if disparities show up[15][16][18].
Where full explainability isn't possible, require human review or set lower output thresholds[16].
The contract also needs to define data rights, not just service controls. The HDO should keep ownership of patient and operational data, while the vendor gets only a limited license to use that data for the contracted services[15][17][18].
Outputs - like clinical summaries, risk scores, and flagged records - should be handled head-on. The contract should say whether the HDO has exclusive rights or shared rights, and whether the vendor can reuse anonymized outputs or model improvements built from that data for other clients[15][17].
Some healthcare organizations go a step further. They negotiate limits on cross-client reuse or require separate consent before their data is used for training[15][16][17].
BAAs vs. Standard Contracts: Side-by-Side Differences in Security Obligations
A BAA and a standard contract do different jobs.
The BAA deals with HIPAA duties tied to PHI. The standard contract covers how the service works day to day, what the vendor owes you, and what happens if the AI model shifts, slows down, or fails. If PHI is in the picture, you need both.
This split helps you place each security duty in the right document.
| Topic | BAA Obligations | Standard Contract Obligations | Risk Impact |
|---|---|---|---|
| Model Training | Often silent or vague on de-identified use | Explicit opt-out/in for using customer data to train models | Prevents sensitive clinical patterns from leaking into shared models |
| Service Levels | Not addressed | Guarantees for uptime, latency, and output consistency | Critical for AI used in real-time clinical decision support |
| Subcontractors | Requires subcontractors to protect PHI | Names approved subprocessors and downstream service providers | Ensures the entire AI stack is vetted, not just the primary vendor |
| Incident and Outage Response | Focuses on breach notification tied to PHI | Covers service interruptions and system restoration timelines | AI downtime is a safety risk even when no PHI is exposed |
| Data Retention | Focuses on return or destruction at contract end | Defines no-retention policy for daily API operations | Reduces attack surface by not storing prompts or session logs |
When a Signed BAA Is Enough - and When It Is Not
A BAA covers PHI. But it does not set the full rules for service reliability or model-change risk.
That’s the gap many teams miss. A signed BAA is necessary, but it is not enough on its own. It sets the floor for PHI handling, not the full set of protections needed for healthcare AI use.
Consumer AI products without BAAs cannot be used for PHI processing. And timing matters: the BAA must be in place before PHI flows to the vendor, not after the fact.
A Contracting Checklist for Healthcare AI Reviews
For procurement review, use this checklist to make sure the two documents line up:
- Map PHI flows
- Confirm BAA execution before PHI transfer
- Block training and secondary use unless approved
- Set prompt and log retention limits
- Align notice windows across both agreements
- Secure audit rights for AI workflows and data lineage
- Require advance notice for major model updates
Conclusion: Use BAAs and Standard Contracts Together in AI Vendor Risk Management
After the checklist above, the last step is simple: match each duty to the right document. A BAA covers PHI duties. A standard contract covers service terms, security terms, and model-risk terms.
AI changes the picture. Model updates, retraining, and drift can change outputs even when the underlying security controls stay the same.
Business associates, including AI vendors, can be directly liable for Security Rule failures, breach-notice failures, impermissible PHI use, and missing subcontractor BAAs.[7][21][13][22][23]
Use that split when you review the final contract package.
Key Takeaways for HDO and Vendor Decision-Makers
A BAA by itself is not enough for AI vendors. Some of the terms that matter most - incident response timelines, audit rights, subprocessor controls, and model update notice - often sit in the standard contract, not the BAA. That means both documents need to be reviewed side by side, with each duty mapped to the right agreement and no holes between them.
- PHI handling: BAA - permitted uses, safeguards, breach notice, subcontractor duties, and return or destruction at the end of the contract
- AI-specific data use: BAA - training opt-out, prompt and log retention limits, de-identification standards
- Service and security: Standard contract - uptime SLAs, incident response windows, audit rights, and third-party security evidence
- Model governance: Standard contract - advance notice of updates, rollback rights, bias monitoring, and output quality thresholds
No single team or single document can handle all of this. Legal, compliance, security, procurement, and clinical leaders each own part of the work, and the contract stack needs to reflect that split.
FAQs
When is a BAA legally required?
A Business Associate Agreement (BAA) is legally required any time an AI vendor receives, creates, maintains, or transmits protected health information (PHI) for a healthcare organization.
That means the paperwork can't wait until later. A signed, valid BAA must be in place before any PHI is shared with the vendor.
And with AI, the agreement should do more than cover the basics. It needs to spell out AI-specific risks, including how data may be used for training, whether subprocessors are involved, and what happens with model outputs.
Why isn’t a BAA enough for AI vendors?
A Business Associate Agreement is necessary, but it’s not enough for AI vendors.
Here’s the issue: standard BAAs were never built for AI-specific risks. They don’t squarely deal with things like using patient data for model training, handling AI-generated outputs, or managing long chains of downstream subprocessors.
That gap matters. On their own, BAAs can leave organizations exposed to model bias, data leakage, and unauthorized secondary data use.
For AI vendors, the safer move is to treat the BAA as a starting point, not the whole package. It should be paired with AI-specific contract terms that:
- restrict PHI use for model training
- require transparency across the vendor supply chain
Without those added terms, a signed BAA may look good on paper while leaving major risks untouched.
What AI terms should be in the main contract?
Your main contract should spell out AI-specific protections in plain terms. That means addressing model transparency, data ownership, and how the system is expected to perform.
At a minimum, the agreement should require an AI Bill of Materials. In simple terms, that’s a record of what’s inside the AI stack: the models in use, key third-party parts, data sources where relevant, and any major dependencies. If something goes wrong, you don’t want to be guessing about what the vendor put under the hood.
The contract should also make ownership crystal clear. That includes:
- Inputs you provide
- Outputs the system generates
- Logs and usage records
- Derived artifacts created from your data
This point matters more than it may seem at first glance. If ownership is fuzzy, disputes can pop up later over who controls results, who can reuse them, and who gets to keep system records.
You should also place hard limits on PHI. The vendor should not be allowed to use PHI for model training, tuning, or service improvement unless you have given direct written permission and the use fits your legal and internal rules. For many healthcare groups, that kind of use should be off the table entirely.
Beyond that, the contract should include audit rights, performance monitoring, and compliance duties. In practice, this gives you the ability to check whether the vendor is doing what it promised, track how the AI performs over time, and confirm that required legal and policy standards are being met.
Human review needs to be written in as well. For higher-risk use cases, require human-in-the-loop review and clear safety override controls. Put simply: a person should be able to step in, stop, correct, or reject an AI-driven action before harm spreads. That safeguard can make all the difference when the tool is working with sensitive health data or affecting patient care.
