The question divides compliance teams every time a new AI tool arrives in a department manager's inbox. One side argues you can't afford to wait for perfect vendor paperwork while your competitors automate everything. The other insists that skipping a Business Associate Agreement (BAA) is a HIPAA violation waiting to happen. Both camps present valid arguments grounded in legitimate pressures, and neither is entirely wrong.
The Case for "BAA First, Always"
Privacy officers who won't approve an AI tool without a signed BAA point to the regulatory text itself. If a vendor creates, receives, maintains, or transmits PHI on your behalf, HIPAA generally requires a BAA. That's not a suggestion; it's a legal obligation that OCR enforces during investigations.
The stakes aren't hypothetical. When OCR reviews an incident, they'll ask for your BAA inventory. If you used a vendor to process PHI and can't produce a signed agreement, you've handed them a documented compliance failure. The vendor's security controls don't matter at that point. The fact that "nothing bad happened" doesn't matter. You violated the foundational requirement that governs third-party PHI access.
This camp also highlights a practical reality: most consumer AI tools don't offer BAAs because they weren't built for healthcare. If a vendor won't sign one, that tells you everything you need to know about whether they're prepared to handle patient information. Approving the tool anyway doesn't make you agile; it makes you exposed.
The "BAA first" approach also forces the right conversation at the right time. Before anyone enters a patient note into an AI assistant, your team has already confirmed the vendor's data retention policies, encryption standards, audit logging capabilities, and contractual assurance that PHI won't train their models. You've documented the risk assessment. You've established access controls. The tool goes live only after compliance has cleared it.
The Case for "Evaluate Risk, Then Decide"
The opposing view doesn't dismiss BAAs outright. It questions whether every AI interaction with patient information triggers the same compliance obligation, and whether insisting on signed agreements before any evaluation creates more risk than it prevents.
Consider a physician who pastes a de-identified case summary into an AI tool to draft a research abstract. Or a compliance officer who describes a hypothetical scenario (no names, no dates, no identifiers) to test whether an AI assistant can help draft a policy. These use cases don't involve PHI under HIPAA's definition, yet a blanket "no AI without a BAA" policy treats them the same as uploading an entire patient database.
This camp argues that rigid policies push AI use underground. If your official answer is always "no" or "wait six months for procurement," employees will use consumer tools anyway. They'll just do it on personal devices, outside your network, with no oversight at all. A compliance program that doesn't account for how people actually work isn't protecting PHI; it's losing visibility into where PHI is going.
There's also a timing problem. Evaluating whether a vendor can meet HIPAA requirements requires testing the tool, reviewing its technical documentation, and understanding its data flows. You can't do that from a vendor's marketing page. Some compliance teams argue you need limited, controlled access to assess whether a BAA is even feasible, or whether the tool's architecture makes HIPAA compliance impossible regardless of contract language.
This approach prioritizes risk-based decision-making over strict rules. If a tool will never access PHI, don't treat it like one that will. If a vendor offers strong technical safeguards but balks at your BAA template, negotiate. If an AI assistant will only process information that's already public or de-identified, document that scope and move forward.
Where Practitioners Actually Land
Most compliance officers don't pick one side and stick to it forever. They adapt based on the tool, the use case, and the department requesting access.
For AI platforms marketed to healthcare (clinical documentation tools, prior authorization assistants, diagnostic support systems), the BAA requirement is non-negotiable. These vendors know what HIPAA requires, and if they won't sign, that's a red flag your organization can't ignore.
For general-purpose AI tools, the line gets harder to draw. Many teams establish a tiered approval process: no BAA needed if the tool will never touch PHI, limited pilot access with strict controls if you're still evaluating, and a signed BAA before any production use involving patient information. The key is documenting your rationale at each stage and ensuring employees understand which tools fall into which category.
Training becomes the enforcement mechanism. Your workforce needs to know which AI applications are approved, what "never use PHI" actually means in practice, and how to request access to new tools without waiting three months. A policy that says "ask first" only works if asking produces a useful answer within a reasonable timeframe.
Our Take
You can't operate a HIPAA compliance program on hypotheticals and good intentions. If an AI vendor will access PHI, get the BAA signed before you go live. That's not bureaucracy; it's the legal foundation that makes everything else defensible.
But compliance officers also can't pretend that saying "no" to every AI request will stop employees from using these tools. The smarter move is to identify low-risk use cases where AI doesn't involve PHI, approve those quickly, and reserve your scrutiny for the vendors that actually need oversight. When you treat every request the same, you lose credibility with the departments you're trying to protect.
The middle ground isn't "sometimes skip the BAA." It's "understand what triggers the BAA requirement, document your analysis, and move fast on the cases that don't." If you can't explain why a specific AI tool does or doesn't need a Business Associate Agreement, you're not managing risk. You're just hoping OCR doesn't ask.
