Building HIPAA-Compliant AI Applications

Healthcare teams are adding AI faster than they are adding compliance controls. Clinical decision support, ambient documentation, diagnostic imaging analysis, patient-facing chatbots — every one of these features can touch Protected Health Information (PHI), and every one of them carries HIPAA obligations that most engineering teams haven’t fully mapped.

The problem is rarely negligence. It is a mismatch of timelines: the AI integration takes a sprint; the compliance architecture takes months. By the time a security review lands on the desk of a healthcare customer’s procurement team, the technical debt is already baked in.

This guide is for engineers and technical leads building AI features on healthcare platforms. It covers the full HIPAA engineering stack — from BAA contracts to LLM data paths — with enough specificity to act on, not just nod along to.

What changed in 2025 — and why it matters for AI

HIPAA was written in 1996 and is intentionally technology-neutral — which means the same rules that applied to a fax machine now apply to a large language model. But the January 2025 Security Rule NPRM (Notice of Proposed Rulemaking) is the most significant update to the Security Rule in over a decade, and it materially raises the bar for AI systems.

Two changes matter most for engineering teams:

Encryption is now mandatory, not addressable. The 2025 amendments convert encryption of ePHI at rest and in transit from an “addressable” implementation specification to a required one. This directly affects LLM inference pipelines: every prompt that contains PHI, every completion that references a patient record, every transcription stored in a vector database — all require encryption under the updated rule. There is no longer a documented exception path.

Business associate accountability is independently enforceable. HHS OCR can now pursue enforcement actions against business associates directly, without going through the covered entity. If your LLM API provider processes PHI without a signed BAA, both parties are exposed — and your vendor’s failure is no longer a defense.

Non-negotiable: Public AI tools — ChatGPT, Claude.ai, Gemini — are not HIPAA-eligible in their consumer configurations. They do not sign BAAs. Using them to process PHI is a direct HIPAA violation regardless of how the prompt is framed. Enterprise configurations (Azure OpenAI, Google Vertex AI with HIPAA BAA) are different — see Section 3.

Step one: Map every PHI data path in your AI pipeline

Before you write a single compliance policy, you need a complete map of where PHI enters, moves through, and exits your AI system. This is harder than it sounds, because LLM-based architectures have PHI touchpoints that don’t exist in traditional CRUD applications.

1. Input ingestion — prompts and context

Every prompt that includes patient data — a clinical note, a medication list, a lab result — is a PHI transmission event. If your application constructs prompts dynamically from EHR data, each prompt assembly is a regulated data access. Log it, encrypt the payload in transit, and ensure the receiving endpoint (your LLM API) has a signed BAA.

2. Model inference — where PHI is transiently processed

Even if the model doesn’t retain data between sessions, the inference itself is a PHI processing event under HIPAA. The model provider’s infrastructure — their GPU clusters, their load balancers, their logging systems — is processing ePHI. That infrastructure must be covered by a BAA and must meet the Security Rule technical safeguard requirements.

3. Retrieval-Augmented Generation (RAG) and vector stores

RAG architectures embed patient data into vector representations stored in databases like Pinecone, Weaviate, or pgvector. Those embeddings are PHI — they can be partially reversed or re-identified. Your vector store needs encryption at rest, access controls scoped to the minimum necessary, and BAA coverage from the vendor.

4. Output storage and downstream systems

AI-generated outputs that reference or summarize patient data are themselves PHI. Clinical summaries, generated care plans, ambient scribe transcriptions — all must be stored with the same controls as any other ePHI: encryption at rest, access logging, retention policies, and breach notification obligations.

5. Fine-tuning and training datasets

If you fine-tune a model on patient data, you have embedded PHI into the model weights themselves. This is a PHI retention obligation that most teams don’t anticipate: the model becomes a PHI-bearing artifact, subject to retention schedules, disposal requirements, and access controls. De-identification to the HIPAA Safe Harbor or Expert Determination standard before fine-tuning is the only way to avoid this.

Peerbits practice: In every healthcare AI engagement, we produce a PHI Data Flow Diagram as a first-week deliverable — a complete map of every system, API, and storage layer that touches ePHI, with BAA status and encryption status annotated at each hop. This diagram becomes the foundation of the risk analysis required by the Security Rule.

The BAA landscape for AI infrastructure

A Business Associate Agreement is not optional — it is a legal prerequisite for using any third-party service that processes PHI on your behalf. For AI systems, the BAA requirement extends much further than most teams initially realize: it covers not just your LLM API provider but every component in the inference stack.

“HIPAA-eligible” ≠ “HIPAA-compliant.” A platform that offers a BAA provides the contractual foundation — but configuration is your responsibility. Enabling a HIPAA-eligible service without configuring encryption, access controls, and audit logging leaves you contractually covered but technically exposed. The distinction matters in an OCR investigation.

Technical safeguards: the engineering implementation

The HIPAA Security Rule requires four categories of technical safeguards. For AI systems, each category maps to a distinct set of engineering controls that differ from traditional application security.

The audit control requirement deserves special attention in AI contexts. Traditional audit logs capture read/write events on a database. AI audit logs must also capture inference events — the fact that a model processed a patient’s data and produced an output. The following is a minimal compliant audit log structure for an LLM inference event:

De-identification: the only safe path to training on patient data

If your roadmap includes fine-tuning a model on clinical data, or using patient records to build evaluation benchmarks, HIPAA provides two recognized de-identification pathways. There is no third option that is legally sound.

Safe Harbor requires the removal of 18 specific PHI identifiers (names, dates other than year, geographic subdivisions smaller than state, phone numbers, SSNs, device identifiers, IP addresses, biometric identifiers, and so on) and that the covered entity have no actual knowledge that the remaining information could identify an individual.

Expert Determination requires a qualified statistical or scientific expert to apply generally accepted principles to certify that the risk of identifying the individual from the dataset is very small. This path is more flexible but requires formal documentation of the expert’s methodology.

Any AI model trained on, fine-tuned with, or inferencing against PHI must be covered by your HIPAA compliance architecture. The key engineering obligations for AI in healthcare systems are clear: LLM API calls containing PHI require a BAA with the model provider.

— Peerbits, HIPAA by Design: Engineering Blueprint for Compliant Healthcare Systems

Practical guidance: For most product teams, Safe Harbor de-identification before any model training is the right call — it is auditable, well-understood by OCR, and does not require retaining an expert. Build a de-identification pipeline that runs as a preprocessing step, logs the identifiers removed, and produces a certified output dataset. Peerbits has built these pipelines as part of healthcare AI platform engagements.

The engineering compliance checklist

Before any AI feature that processes PHI reaches production in a healthcare environment, the following controls should be confirmed — not just planned. This checklist is derived from the HIPAA Security Rule technical safeguards, the 2025 NPRM amendments, and Peerbits’ own HIPAA by Design engineering framework.

• BAA signed with every vendor whose infrastructure touches PHI — including LLM API provider, vector database, cloud host, and any logging or monitoring service that ingests PHI-bearing payloads
• PHI data flow diagram completed and reviewed by legal/compliance — every system, API endpoint, and storage layer annotated with BAA status and encryption status
• Encryption at rest for all PHI storage including prompt logs, completion logs, vector embeddings, and AI-generated outputs (AES-256 minimum; key management via AWS KMS, Azure Key Vault, or equivalent)
• TLS 1.2+ enforced on all API calls carrying PHI — verified at the transport layer, not assumed from library defaults
• Minimum necessary applied to prompt construction — no PHI in a prompt that isn’t required for the specific AI function being invoked
• Immutable audit log capturing every PHI-bearing inference event with user, patient context (hashed), model, token counts, and output disposition
• Role-based access control mapped to clinical roles and enforced at the AI feature layer via SMART on FHIR scopes or equivalent
• Zero data retention policy confirmed with LLM API provider — verify contractually that prompts are not used to train or improve the model
• De-identification pipeline in place for any fine-tuning datasets — Safe Harbor or Expert Determination documentation produced before training begins
• Breach notification runbook tested and current — AI systems expand the PHI breach surface; your 60-day OCR notification obligation doesn’t change
• Security risk analysis updated to include AI components — the 2025 NPRM makes this a heightened requirement for any system touching ePHI

Peerbits builds and reviews this compliance architecture as part of every healthcare software development engagement. Our DevSecOps pipelines include automated HIPAA control checks at the CI/CD layer — encryption validation, dependency scanning for BAA-covered packages, and audit log integrity verification — so compliance is tested on every build, not verified once at launch. We also help teams navigate the technical requirements of the healthcare API gateway layer where PHI access controls and audit logging converge.