Most healthcare organizations now know to ask an AI vendor the first compliance question: "Will you sign a BAA?" But the real risk doesn't live in the signature process. It emerges after the agreement is in place, when teams assume the contract covers workflows it was never designed to address.
A business associate agreement governs a defined relationship and a defined scope. It is not a HIPAA certification, a security assessment, or blanket approval for every feature your team builds around that vendor. Your organization still owns the hard part: controlling how protected health information moves through the application, who can see it, and where it goes next.
That distinction grows more critical as healthcare AI moves beyond single model API calls into multi-component systems. Here are the four gaps that surface most often after the BAA is signed.
AI logs are not ordinary application telemetry
AI deployments generate unusually sensitive logs: prompts, model responses, user IDs, timestamps, tool calls, and sometimes entire clinical narratives. Teams need visibility to investigate errors and improve performance. The problem is that observability systems often become a parallel repository of PHI with far broader access than the clinical system that generated it.
HIPAA's Security Rule requires access controls and audit controls appropriate to the environment. The Privacy Rule's minimum-necessary standard demands role-based limits on PHI use and access. "Engineers need it for debugging" should not translate into standing, organization-wide access to raw prompts. Access must be tied to a legitimate role and purpose.
In practice, this means inventorying every place AI interaction data lands, minimizing what gets logged, redacting or de-identifying where feasible, and making access to unredacted records time-bound and auditable.
The restrictions live beyond the BAA signature page
A vendor may offer a HIPAA-ready API, but that does not mean every use case or product feature falls within scope. The BAA is only one part of the operating terms. The more consequential restrictions often sit in implementation guidance, product documentation, and feature-specific coverage tables.
Before enabling a new capability, ask four questions: Is this exact feature covered, not just the vendor or account? Is the intended workflow permitted under the vendor's implementation guidance? What data leaves the product boundary? Has the feature changed since the last vendor review? A BAA that covered last quarter's chat workflow may say nothing about today's autonomous agent.
Product names are not compliance boundaries. Data flows and approved use cases are. For teams building AI for Healthcare applications, that distinction determines whether a deployment stays compliant or drifts into unapproved territory.
Behavioral health data carries extra obligations
Behavioral-health workflows require additional care, especially when substance use disorder treatment records are involved. Those records may be subject to 42 CFR Part 2, which imposes confidentiality requirements beyond a standard HIPAA analysis. The mistake is assuming a HIPAA BAA resolves every permission, notice, redisclosure, and data-segmentation question for SUD records.
Before an AI tool enters a behavioral-health workflow, security, privacy, legal, and clinical teams need to trace the data journey together. Which records originate from a Part 2 program, and can the retrieval layer label them at ingest? Where a system cannot reliably separate Part 2 records, the conservative posture is to apply Part 2 handling to the entire set. That matters most when an agent pulls from several sources into one response, because the answer inherits the most restrictive rule among its inputs.
The vendors around the model need contracts too
Modern AI systems are rarely one vendor, one API, and one BAA. They include logging platforms, vector databases, cloud storage, workflow engines, retrieval systems, web-search tools, connectors, and MCP servers. Every additional component creates another potential PHI recipient and another question about safeguards, contractual coverage, and access.
HIPAA's Security Rule requires business associates to obtain appropriate assurances from subcontractors that handle ePHI on their behalf. The right review artifact is not a folder of executed BAAs. It's a living data-flow map showing user input, retrieval source, model, tool call, log destination, human reviewer, and retention path. If your organization cannot draw that chain, it cannot credibly claim to control it. This operational discipline matters equally for teams following an AI Learning Path for Medical Records Clerks and for senior architects designing multi-vendor pipelines.
Why this matters for healthcare teams
A BAA should be the beginning of operational oversight, not the end of procurement. After signing, confirm who can access AI prompts, outputs, and logs containing PHI. Verify every enabled product feature is covered under the agreement and configured correctly. Check whether the workflow involves SUD records or other specially protected data. Map which third parties, including connectors and tool servers, can receive PHI. Update the risk analysis as the workflow changes. The teams that build durable AI programs will be the ones that operationalize governance at the data-flow level where the risk actually lives.
Your membership also unlocks:
