To build AI products with patient data safely in 2026, sign a Business Associate Agreement (BAA) with your model provider (Azure OpenAI, Anthropic, or Google Vertex), turn off training and set zero or short data retention, apply the minimum-necessary rule, and de-identify data wherever the use case allows. Budget 3-6 weeks to add a compliant PHI-handling layer to an AI MVP, with secure RAG, encryption, and full audit logging.
The core question: PHI, AI, and what HIPAA actually allows
Protected Health Information (PHI) is any individually identifiable health data: names, dates, medical record numbers, diagnoses, and the 18 identifiers HIPAA enumerates. The moment your AI feature touches PHI, every component that processes it, including your LLM provider, becomes a "business associate" under HIPAA and needs a contract that says so.
The good news is that AI and PHI are not incompatible. You can run large language models over real clinical data legally, as long as the right agreements, technical controls, and minimum-necessary discipline are in place. The trap founders fall into is wiring a consumer chatbot API into a clinical workflow with no BAA, which is a clear violation no matter how good the encryption is.
This article covers the data layer specifically. For the broader compliance build, see our guide on how to make an app HIPAA compliant, and for the overall vertical strategy, start with our pillar on healthtech MVP development.
General information, not legal advice. HIPAA, state privacy laws, and provider terms change. Confirm your architecture with qualified healthcare counsel and a security assessor before processing real PHI.
Two paths: de-identified data vs. PHI under a BAA
Almost every decision about AI and patient data reduces to one fork: are you working with de-identified data or with live PHI? The path you choose drives your provider list, your contracts, and your engineering effort.
| Factor | De-identified data | PHI under a BAA |
|---|---|---|
| HIPAA status | Not PHI; outside HIPAA once properly de-identified | Fully regulated PHI |
| Provider options | Most APIs (still check terms) | HIPAA-eligible tiers only, BAA signed |
| Training/retention | Lower risk, but still disable training | Must disable training; zero/short retention |
| Use cases | Model evaluation, analytics, research, demos | Live clinical workflows, patient-facing tools |
| Engineering effort | De-id pipeline + human review | BAAs, access control, audit, encryption |
Many teams use both: de-identified data to develop and benchmark models cheaply, and a BAA-covered production path for real patient sessions. For an MVP, decide early which features genuinely need live PHI, because that subset defines your compliance scope.
De-identification: Safe Harbor and Expert Determination
HIPAA gives you two recognized de-identification methods. Safe Harbor requires removing 18 categories of identifiers, including names, all date elements more specific than year, geographic subdivisions smaller than a state, phone numbers, email addresses, medical record numbers, device IDs, and full-face photos. Strip all 18 and the data is no longer PHI.
Expert Determination uses a qualified statistician to certify that the risk of re-identification is "very small" given the data and likely recipients. This path lets you retain more analytic value (for example, dates shifted consistently) when a blunt Safe Harbor strip would destroy the signal you need.
The hard part: free-text clinical notes
Structured fields are easy to scrub. Clinical notes are not. A discharge summary can hide a patient's name, a provider's name, a date, and a hometown in a single sentence. Reliable de-identification of free text means running automated PHI detection (named-entity recognition tuned for clinical text), then a human review pass on a sample, then measuring recall before you trust the output. Treat any "fully automated, no review" claim with skepticism.
Because LLMs themselves can help detect and redact PHI, you sometimes need a BAA-covered model just to build your de-identification pipeline. That is the kind of sequencing tradeoff we work through when scoping an AI healthcare MVP.
BAAs with model providers: who signs and how
A BAA is the contract that makes a vendor legally accountable for the PHI it processes on your behalf. Without one, you cannot lawfully send PHI to that vendor, full stop. Here is the practical landscape for the major LLM providers in 2026.
| Provider / channel | BAA available | Notes |
|---|---|---|
| Azure OpenAI Service | Yes (Microsoft HIPAA BAA) | GPT models inside Azure's compliance boundary; common enterprise choice |
| OpenAI API / Enterprise | Yes, eligible accounts | Confirm tier and zero-retention terms in writing |
| Anthropic (Claude) | Yes, commercial/enterprise | Also available via AWS Bedrock and Google Vertex AI |
| Google Vertex AI (Gemini) | Yes (Google Cloud BAA) | Covered under Google Cloud's HIPAA-eligible services list |
| Consumer chatbots (no API BAA) | No | Never send PHI; not HIPAA-eligible |
Three things to verify in writing before any PHI flows: (1) the BAA covers the exact endpoints and models you'll call, (2) your inputs and outputs are excluded from model training, and (3) retention is zero or short with abuse-monitoring data handled inside the compliance boundary. Cloud routing through AWS Bedrock or Vertex often simplifies this because the cloud provider's existing BAA extends to the model. For help weighing model and provider options, see LLMs in healthcare and the general guide on choosing the right LLM for your MVP.
No-training and zero-retention: the settings that matter
A BAA is necessary but not sufficient. The technical configuration is what keeps PHI from leaking into a model's training set or sitting in logs you don't control.
- Training opt-out: enterprise and HIPAA-eligible API tiers exclude your data from training by default. Confirm it; do not assume the default that applies to free consumer tiers.
- Zero or short retention: request zero data retention where offered, or the shortest window available. Some providers retain a short buffer for abuse monitoring; make sure that buffer lives inside the BAA's scope.
- Regional residency: if you have state or international data-residency obligations, pin processing to a compliant region.
- Logging discipline: your own application logs are the most common accidental PHI leak. Scrub prompts and completions before they hit observability tools that aren't covered by a BAA.
These settings are cheap to enable and expensive to forget. We bake them into the default configuration on every compliant build so they're never an afterthought.
Minimum necessary: send the model less
HIPAA's minimum-necessary standard says you should use or disclose only the PHI required for the task. Applied to AI, it becomes a concrete engineering rule: don't dump a full patient chart into a prompt when the model only needs the last three lab values and the active medication list.
Minimum necessary reduces breach blast radius, lowers token cost, and often improves model accuracy by cutting noise. In practice that means a context-assembly layer that pulls only the fields a given task requires, plus per-role filtering so a triage assistant never sees data a triage assistant has no business seeing. This same discipline matters for adjacent tools like a symptom checker or an AI medical scribe, where over-collection is an easy mistake to make under deadline pressure.
Securing a RAG pipeline that touches PHI
Retrieval-augmented generation is how most healthtech AI products ground answers in real records, guidelines, or notes. It's also where patient data quietly spreads across new systems: an embedding service, a vector database, a document store, and the model itself. Each is a place PHI can leak or cross between patients.
The controls that make RAG defensible
- Encrypt everything: the vector store, the source documents, and all traffic, at rest and in transit.
- Scope retrieval by identity: filter the index by user and patient so a query can only ever retrieve data that user is authorized to see. Access control belongs in the retrieval layer, not just the UI.
- BAA-covered embeddings: embedding generation sends raw text to a provider too. That provider needs the same BAA and no-training terms as your generation model.
- Minimum-necessary context: rank, then trim. Pass only the top relevant passages, not everything the search returned.
- Isolation: never let one patient's chunks surface in another patient's session. Test this explicitly with adversarial queries.
- Full audit trail: log who asked what, which records were retrieved, and what the model returned, in tamper-evident storage.
A common shortcut, embedding an entire population's records into one shared index with no per-patient filtering, turns a single prompt-injection or query bug into a mass disclosure. Tenant and patient isolation in the retrieval layer is the control that prevents that. The same architecture underpins safe remote patient monitoring and clinical decision support products.
Audit, access control, and breach readiness
HIPAA's Security Rule expects access controls, audit logging, and an incident-response plan, and AI systems don't get an exemption. Practically, that means role-based access on every PHI surface, immutable logs you can actually query during an investigation, and a documented process for detecting and reporting a breach within required timelines.
For AI specifically, add two things: log the model inputs and outputs (scrubbed appropriately) so you can reconstruct what the system told a clinician or patient, and version your prompts and models so you can tie a given response to a specific configuration. When a regulator or hospital security team asks "what did the AI see and say on this date," you want a clean answer.
If a model touches clinical decisions, you may also enter FDA territory. That's a separate analysis covered in our piece on FDA clearance for AI medical software; the data-handling controls here apply regardless of regulatory class.
What this costs and how long it takes
Adding a compliant PHI-handling layer to an AI MVP is meaningful but bounded work. In 2026, expect roughly 3-6 weeks of additional engineering on top of core feature build to stand up BAAs, encryption, access control, secure RAG, and audit logging, depending on how many data sources and integrations are in scope.
Cost varies with EHR integrations, the number of providers needing BAAs, and whether you need formal de-identification with expert determination. For grounded ranges, see healthcare app development cost and the general how much an AI MVP costs guide, or run the numbers yourself with our AI MVP Cost Calculator.
At SpeedMVPs, we ship compliant, HIPAA-ready AI MVPs in 2-3 weeks with fixed pricing and direct developer access, with the PHI controls above built in from day one rather than retrofitted after launch. That sequencing matters: privacy and security are far cheaper to design in than to bolt on once real patient data is flowing.
A practical checklist before you ship
- Map every place PHI is created, stored, processed, or transmitted, including AI providers.
- Sign BAAs with every business associate, and confirm endpoints, no-training, and retention terms in writing.
- Decide per feature: de-identified data or live PHI under a BAA.
- Implement minimum-necessary context assembly and per-role filtering.
- Encrypt at rest and in transit; scope RAG retrieval by user and patient.
- Scrub PHI from application and observability logs.
- Stand up audit logging, access controls, and a breach-response plan.
- Get qualified counsel and a security review before processing real patient data.
Pair this with the broader build sequence in how to build an AI MVP in 2026 so the data layer fits a realistic delivery timeline rather than blocking it.
Build with patient data the right way
Handling PHI in an AI product is solvable engineering, not a reason to avoid real data. Get the BAAs, no-training settings, de-identification, minimum-necessary discipline, secure RAG, and audit logging right, and you can ship something genuinely useful to clinicians and patients without taking on reckless risk. If you want a team that has done this before, book a free discovery call and we'll map your data flows, compliance scope, and timeline, or explore our AI MVP Development service to see how we ship compliant, HIPAA-ready AI MVPs in 2-3 weeks.
