BAA before PHI: the sequencing most teams get wrong.
A decision tree for LLM vendors, subprocessors, and when synthetic data is enough — before anyone pastes real patient data into a prompt.
·8 min read
TL;DR
Do not put real PHI into an LLM path until business associate agreements, environment controls, and retention rules exist for every vendor that can see that data. Prototypes can move fast on synthetic or properly de-identified data. Crossing the PHI line early is how teams inherit avoidable risk.
When do you actually need a BAA for an LLM vendor?
You need a BAA when a vendor creates, receives, maintains, or transmits PHI on your behalf as a business associate under HIPAA. If prompts, logs, embeddings, or support tooling can contain PHI, treat that vendor like a BA until counsel says otherwise. Model quality rankings do not answer this question.
Founders often ask “which model is best?” before “who can see this text?”
For US healthcare buyers, the sequencing Brandlabs uses is blunt:
- Map every system that can touch PHI (app DB, object storage, LLM API, eval store, observability, support inbox)
- Label which of those are business associates vs your own workforce vs not applicable
- Put BAAs and technical controls in place before real PHI enters the path
- Only then wire production inference
This is engineering sequencing with legal review — not a substitute for counsel. If your counsel has a different bright line, follow counsel.
What can you ship before BAAs without faking progress?
Architecture, UX, eval harnesses, synthetic fixtures, and de-identified datasets. You can prove retrieval quality, latency, and refusal behavior without a single real patient record. That is real product progress — not a stall.
Teams panic that compliance blocks learning. It blocks PHI learning, not product learning.
Safe early work:
- Synthetic clinical-shaped fixtures (clearly labeled synthetic)
- De-identified data under a documented method and review
- Prompt/UX iteration on non-PHI domains that stress the same architecture
- Vendor shortlists filtered by BAA availability, retention defaults, and region options
Unsafe early work:
- Paste production notes into ChatGPT “just to see”
- Send PHI to a model endpoint with training-on-inputs enabled
- Store raw prompts containing identifiers in a shared eval spreadsheet
If a demo requires PHI to look impressive, the demo is lying about readiness.
How should founders sequence vendors and subprocessors?
Inventory every subprocessor in the AI path — model host, embedding store, log sink, ticket tool — and do not enable PHI flows until each relevant party is contracted and configured. Prefer vendors that document BAAs, retention controls, and zero-retention options in writing.
A practical decision tree we use in Discovery Sprints:
- Will this system ever see PHI? If no forever, document why and move on.
- If maybe: design the path so PHI is optional until gated.
- If yes: BAA + DPA as applicable, retention settings locked, audit logging on, access limited.
Also ask: can support engineers at the vendor read our prompts? Can the model provider train on our inputs? Where do failed-request logs live?
Brandlabs will not “move fast” by pretending those answers are optional.
Frequently asked questions
Is this legal advice?
No. This is how Brandlabs sequences engineering and vendor work for regulated AI products. Your counsel owns HIPAA applicability and contract language.
What about DPDP in India — is it the same as a BAA?
No. DPDP uses different concepts (consent, purpose, processors/fiduciaries). The shared engineering habit is the same: do not send personal data to a vendor until contracts and controls match the risk.
Can we use a consumer LLM chat UI for internal prototypes?
Not with real PHI. Use an approved environment with the right agreements, or keep prototypes on synthetic data.