The following is a guest article by Mat Steinlin, Head of Information Security at Aptible. Healthcare organizations have gotten better at asking the first AI compliance question: “Will the vendor sign a BAA?”. If an AI vendor will create, receive, maintain, or transmit PHI on your behalf, a BAA is foundational.
But it’s not a HIPAA certification, a security assessment, or a blanket approval for every feature and workflow you build around that vendor.. A BAA governs a defined relationship and a defined scope. Your team still owns the hard part: controlling how PHI moves through the application, who can see it, and where it goes next..
That distinction is becoming more important as healthcare AI moves beyond a single model API call. The riskiest gaps I see are rarely in the signature process; they emerge after the agreement is in place.. 1.
Treating AI Logs Like Ordinary Application Telemetry. AI deployments generate unusually sensitive logs: prompts, model responses, user IDs, timestamps, tool calls, and sometimes entire clinical narratives. Teams know they 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 organizations to implement access controls and audit controls appropriate to their environment, while the Privacy Rule’s minimum-necessary standard requires role-based limits on PHI use and access.
That means “engineers need it for debugging” should not translate into standing, organization-wide access to raw prompts. HHS’s Privacy Rule guidance and Security Rule guidance are clear on the underlying principle: access should be tied to a legitimate role and purpose.. In practice, this means you must inventory every place AI interaction data lands, minimize what you log, redact or de-identify where feasible, and make access to unredacted records time-bound and auditable..
2. Missing the Restrictions Behind the BAA. A vendor may offer a HIPAA-ready API or enterprise product, but that does not mean every use case (or every product feature) is in 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.. Anthropic provides a useful example.
Its BAA requires customers to follow an Implementation Guide for HIPAA Entities, and that guide restricts certain clinical uses, including direct patient-provider interactions, diagnosis, and treatment purposes. Those constraints are not a minor footnote: they shape what teams can safely build, even after a BAA is signed. (For example, Anthropic states that data sent to third parties through MCPs or connectors is not covered by its BAA)..
That is why product names are not compliance boundaries; data flows and approved use cases are. 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.. 3. Treating Behavioral Health Data as Ordinary PHI.
Behavioral-health workflows require additional care, especially when substance use disorder (SUD) 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 not simply failing to add “Part 2” to a contract.
It’s assuming that a HIPAA BAA, by itself, resolves every permission, notice, redisclosure, and data-segmentation question that may apply to SUD records.. Before an AI tool enters a behavioral-health workflow, the security, privacy, legal, and clinical teams need to trace the data journey together, and the trace should end in a design decision, not a meeting.
Which records originate from a Part 2 program, and can the retrieval layer label them at ingest? The Part 2 amendments that took effect in February 2026 simplified consent; they did not simplify segregation. Where a system cannot reliably separate Part 2 records, the conservative posture is to apply Part 2 handling to the whole 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. If you cannot say which passage came from where, you cannot show which rule applied.. That’s the design work that keeps a useful AI workflow from creating a sensitive disclosure problem..
4. Forgetting the Vendors Around the Model. 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.
For healthcare organizations working across several AI products, managing BAAs across multiple AI vendors is ultimately an operational discipline, not a one-time contracting exercise.. HIPAA’s Security Rule also requires business associates to obtain appropriate assurances from subcontractors that handle ePHI on their behalf.
HHS’s Security Rule summary explains that downstream obligation.. The right review artifact is not a folder of executed BAAs; it’s a living data-flow map with 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..
The Post-Signature Checklist. A BAA should be the beginning of operational oversight, not the end of procurement. After signing, ask:.
Who can access AI prompts, outputs, and logs containing PHI?. Is every enabled product feature covered under the agreement and configured correctly?. Does the workflow involve SUD records or other specially protected data?.
Which third parties (including connectors and tool servers) can receive PHI?. Has the organization updated its risk analysis as the workflow changed?. Healthcare organizations don’t need to choose between moving quickly with AI and protecting patient data.
They just need to stop treating the contract as the control.. The teams that build durable AI programs will be the ones that operationalize governance at the data-flow level where the risk actually lives.. About Mat Steinlin.
Mat Steinlin is Head of Information Security at Aptible, a compliance-first infrastructure platform for regulated healthcare and AI companies. He has led security assessments for digital health companies through HIPAA, HITRUST, SOC 2, and PCI compliance for over a decade.. . Get Fresh Healthcare & IT Stories Delivered Daily.
Join thousands of your healthcare & HealthIT peers who subscribe to our daily newsletter.. We respect your privacy and will never sell or give out your contact information
