Before You Sign a BAA, You Need a Data Flow Map — Not a Vendor Pitch
Before a business associate agreement is signed, a healthcare operator must define exactly which PHI data flows will touch the AI system, because a BAA covers a relationship — not a blanket architecture. That distinction matters more than most procurement teams realize. A signed BAA with an AI vendor does not retroactively make an undocumented data pipeline compliant. It does not cover a cloud bucket that wasn't disclosed. It does not protect an integration that routes patient records through a middleware layer nobody catalogued. The legal instrument is only as strong as the architecture that preceded it.
This is the sequencing error that creates real exposure. Healthcare operators often begin with vendor selection — evaluating AI capabilities, reviewing pricing, negotiating contract terms — and treat the BAA as a closing formality. Compliance architecture should drive that sequence in reverse.
What a BAA Actually Covers — and What It Explicitly Does Not
A BAA establishes that a business associate will appropriately safeguard PHI on behalf of a covered entity. It defines permitted uses, breach notification obligations, and the subcontractor chain. What it does not do is audit your system design, validate your access controls, or guarantee that every node in your AI workflow handles data in accordance with the HIPAA Security Rule.
A BAA is a contractual relationship. The architecture is yours to own.
This means that if your AI pipeline pulls structured EHR data, routes it through a preprocessing service, passes it to a model inference endpoint, logs outputs to an analytics warehouse, and surfaces results in a dashboard — every one of those hops is your responsibility to evaluate. The BAA with the primary AI vendor covers that vendor. It does not automatically extend to the preprocessing service, the logging layer, or the dashboard tool unless each is explicitly named and covered under its own agreement or subcontractor BAA.
Procurement teams that treat the BAA as a compliance checkbox rather than a boundary document routinely underestimate the surface area they're agreeing to protect.
How to Map PHI Touchpoints Before Any AI Vendor Conversation
The most effective pre-vendor step is a PHI data flow inventory — a structured exercise that traces every path a patient record can travel once it enters the AI system's scope.
Start with ingestion: Where does PHI originate? EHR APIs, HL7 feeds, FHIR endpoints, scanned documents, voice transcriptions, insurance adjudication feeds — each source has a different data shape, latency profile, and access control model. Document them all before any vendor demo.
Move to transformation: Does the AI system require raw PHI, or can it operate on de-identified or tokenized data? Many AI workflow use cases — scheduling optimization, clinical documentation assistance, prior authorization drafting — can be engineered to minimize direct PHI exposure at the model layer. If de-identification is feasible, it should be the default design choice, not a post-contract negotiation.
Map every intermediate state: temporary storage, caching layers, API response logs, error handling queues. These are the locations where PHI exposure most often exceeds what a BAA was written to cover.
Finally, document the human access layer. Who can query the system? What roles see what data? Under what logging conditions? A HIPAA-aware AI workflow architecture requires that access be role-based, auditable, and minimized to what each function actually requires.
The Infrastructure Choices a HIPAA-Aware Architecture Requires
A HIPAA-aware AI workflow architecture demands compute isolation, granular access controls, and immutable audit logging — and these must be specified before vendor selection, not negotiated after.
Compute isolation means PHI should not share infrastructure with non-covered workloads unless appropriate technical controls enforce strict separation. For AI specifically, this extends to model training pipelines. If a vendor fine-tunes models on your data, the training environment is within scope. Many AI vendors treat model training infrastructure as outside the BAA's reach. It is not.
Access controls in AI systems require more than username and password. Role-based access control must extend to the model layer — who can submit queries that return PHI, what query parameters are permitted, and how outputs containing patient data are handled downstream. Service accounts used for API integrations require the same scrutiny as human users.
Audit logging must be immutable, timestamped, and complete enough to reconstruct any PHI access event. AI systems generate high-volume, low-latency interactions that can overwhelm logging architectures designed for traditional application workloads. Specify log retention periods, storage location, and access controls on the logs themselves before the engagement begins.
Where applicable, SOC 2-aligned vendor practices, ISO 27001 practices-aligned security programs, and GDPR-aware architecture availability are all reasonable additional requirements — particularly for vendors operating across jurisdictions or handling data for health systems with international affiliates.
Where AI Workflow Automation Creates Hidden PHI Exposure
The hidden exposure points in AI healthcare workflows are rarely in the primary data path. They are in the automation logic that procurement teams evaluate last.
Orchestration layers are the most common blind spot. When an AI workflow uses an orchestration tool to chain tasks — retrieve patient record, summarize clinical notes, generate a response, route to a care coordinator — each step in that chain may invoke a separate service. Each service requires its own evaluation for BAA coverage.
Retrieval-augmented generation (RAG) architectures introduce another risk surface. When an AI system retrieves context from a document store or knowledge base to ground its responses, PHI in that retrieval index is in scope. If the vector database or embedding store isn't explicitly covered, it represents an undocumented PHI touchpoint.
Output storage is underestimated consistently. AI-generated clinical summaries, prior auth drafts, and care recommendations that contain or derive from PHI must be stored, transmitted, and disposed of under the same safeguards as the source data. Storing AI outputs in a general-purpose analytics environment that isn't under a BAA is a compliance gap, regardless of how the input data was handled.
How to Write AI Vendor Requirements That Surface These Risks
The RFP or vendor requirements document is the instrument that forces a vendor to disclose their architecture before you're contractually committed. Generic security questionnaires written for SaaS applications will not surface AI-specific risks.
Require vendors to produce a data flow diagram that shows every system component that touches PHI — including subprocessors, model hosting infrastructure, and logging systems. Require a list of all subcontractors and confirm BAA coverage extends through the full chain.
Ask explicitly: Does your model training pipeline use customer data? If yes, where is it hosted, who has access, and is that environment covered under the BAA you're offering?
Ask about inference logging: Are prompts and completions logged? Where? For how long? Who can access them?
Ask about model outputs: How are AI-generated outputs handled if they contain PHI? What is your data retention and deletion policy?
Vendors who cannot answer these questions with architecture-level specificity before a BAA is signed are indicating that their compliance posture is contractual rather than technical.
Building the Architecture First Is a Business Decision, Not Just a Legal One
Healthcare operators who invest in PHI data flow mapping and infrastructure specification before engaging AI vendors make better vendor decisions, negotiate stronger BAAs, and deploy faster — because they aren't redesigning the architecture after contract signature.
InWork Global engineers AI workflows with a HIPAA-aware posture from the first design session. BAA availability is standard. US CTO oversight is on every engagement. The work begins with the data flow, not the demo.
Getting the architecture right before the signature line isn't compliance overhead. It's the foundation that makes the AI investment defensible — to your legal team, your security team, and the patients whose data you're responsible for protecting.