HIPAA-compliant AI architecture

HIPAA is usually treated as a procurement question — which vendors will sign a Business Associate Agreement — and then handed to engineering as a checklist. That ordering is backwards, and it is why healthcare AI projects tend to stall in review after the build is finished.

HIPAA is an architecture constraint. It determines where data is allowed to sit, which components may see it, how long it persists, and what you must be able to reconstruct afterwards. Decided up front, those constraints are ordinary engineering. Retrofitted, they frequently require rebuilding the retrieval layer.

What HIPAA actually constrains

For an engineering team, three obligations do most of the work.

The Privacy Rule governs use and disclosure: protected health information may be used for treatment, payment and operations, and disclosure outside that requires authorisation. In system terms, every component that receives PHI must have a justification for receiving it.

The Security Rule mandates administrative, physical and technical safeguards — access control, audit controls, integrity controls, transmission security. This is the part that maps most directly onto architecture: encryption in transit and at rest, authenticated and authorised access, and a tamper-evident record of who accessed what.

The minimum necessary standard requires limiting PHI to the least needed for the purpose. This one is routinely violated by AI systems without anyone noticing, because sending an entire patient record into a prompt when the task needs two fields is exactly the pattern that “just put the context in” encourages.

PHI itself is broader than most engineers assume. It is not only diagnoses and medications — it includes names, dates more specific than a year, contact details, record numbers, device identifiers and full-face images, when tied to health information. A transcript with a date of birth and an appointment reason is PHI.

The BAA determines your model options

Any third party that processes PHI on your behalf is a business associate and must be under a signed Business Associate Agreement. This applies to model providers exactly as it applies to a hosting provider.

The major providers offer BAAs on their enterprise or platform tiers, generally with zero-retention configurations for API traffic. What matters architecturally is that BAA coverage is not a property of a company — it is a property of a specific product tier, endpoint and configuration. The same vendor can offer a covered enterprise endpoint and an uncovered consumer product. Confirm coverage for the exact endpoint you are calling, and confirm that data retention for abuse monitoring has been disabled, because default retention is a disclosure your BAA may not cover.

This is a design input, not a late procurement step. If the model you architected around cannot be covered, the alternatives are self-hosting an open-weight model inside your boundary or de-identifying before the call — and both change the system materially. Discovering that after the build is what turns a delivery into a rewrite.

Which model options survive that constraint is the first thing we settle on any healthcare AI build, because it decides the architecture rather than following from it.

Draw the PHI boundary explicitly

The most valuable artefact in a healthcare AI build is a diagram showing exactly which components may hold PHI, drawn before implementation and enforced afterwards.

Inside the boundary: the application database, the retrieval index, the model endpoints under BAA, the audit log. Outside: analytics, error tracking, general-purpose logging, any monitoring SaaS without a BAA, and every developer laptop.

The leaks are almost never the obvious paths. They are the error tracker capturing a request body containing a clinical note. They are the observability pipeline recording full prompt payloads to a backend with no BAA. They are a debug log written during an incident and never removed. Each is a disclosure to a party outside the agreement, and each is invisible in an architecture diagram that only shows the happy path.

Enforce the boundary at emission rather than in the destination. Redact and drop PHI in the process that generates the telemetry, not in a filter on the receiving system — once a payload has crossed a network boundary, the disclosure has happened regardless of what the destination does with it afterwards. In practice this means a serialisation layer that knows which fields are PHI and strips them by default, with an explicit allowlist for what may be emitted.

De-identification is not a free pass

De-identifying before sending data to an uncovered model is a legitimate strategy, and it is harder than it looks.

The Safe Harbor method requires removing eighteen categories of identifier. An NLP pipeline that strips names and dates from a clinical note will reliably miss the ones embedded in narrative text — a referring physician mentioned mid-sentence, a hospital name that narrows the population, a rare condition combined with an age that identifies someone in a small catchment. Free-text clinical narrative is the hardest possible input for automated de-identification, and it is precisely what these systems process.

If you go this route, measure it. Hold out an annotated sample, run the de-identifier, and count what survives. Treat the residual rate as a risk figure to be reviewed, not as a solved problem. For most clinical workloads we find a BAA-covered endpoint is the more defensible path, with de-identification reserved for secondary uses like analytics and model evaluation.

Retention, and why vector stores break it

This is the constraint that most often forces a redesign late, and it is specific to retrieval systems.

Retention policy says PHI is deleted after a defined period, or on request. A RAG pipeline over clinical documents quietly creates several additional copies of that PHI: the chunked text stored alongside the vectors, the embeddings themselves, any cached retrieval results, and frequently a document-parsing intermediate nobody remembers creating. A deletion routine written against the primary database removes the record and leaves every one of those copies in place.

The embeddings deserve particular attention. It is tempting to treat a vector as anonymous because it is a list of floats, and that is not a safe assumption — embedding inversion research has repeatedly demonstrated that substantial source text can be recovered from embeddings. Treat the vector store as holding PHI, because it does.

Architecturally this means the retrieval index needs the same deletion path as the primary store: a stable document identifier propagated into every chunk’s metadata, a delete operation that removes chunks, vectors and cache entries by that identifier, and a scheduled reconciliation that verifies the index contains nothing whose source record is gone. Reconciliation matters because deletes fail silently — a failed index delete during an outage leaves orphaned PHI that no subsequent process will look for.

Building this on day one costs perhaps a day of work. Retrofitting it into a system whose chunks carry no source identifier means reindexing the corpus.

Access control belongs inside the retrieval query

Different clinicians may see different patients. Retrieval must therefore filter by entitlement before it ranks, not after.

Filtering after retrieval is a leak waiting to happen: the vectors were searched, the results were assembled in memory, and one bug in the post-filter — or one code path that forgets it — exposes records to someone who should never have seen them. Attach permission metadata at ingestion, and enforce it as a hard predicate inside the query using the requesting clinician’s identity. It is a security boundary, not a relevance filter. The same argument applies to enterprise retrieval generally, which we cover in enterprise RAG architecture.

Service accounts are the common gap. An agent calling retrieval on behalf of a user must carry that user’s identity through to the query. If it authenticates as a service principal with access to everything, the entitlement model is decorative.

The audit trail has to reconstruct a decision

The Security Rule requires audit controls, and for AI systems the practical bar is higher than “we log requests”. A reviewer will eventually ask why the system produced a particular output for a particular patient on a particular date, and the answer has to be reconstructible.

That means recording, per request: who initiated it, which patient record was accessed, what was retrieved, which model and version generated the output, which prompt template version was used, what was produced, and what the clinician did with it — accepted, edited or rejected. Store it append-only, on a retention schedule matching your policy, in a store separate from application logs so that log rotation cannot destroy audit evidence.

The clinician-action field is the one teams omit and later need most. It is the only record of whether the output was actually relied upon, which is the first question in any incident review — and it doubles as the highest-quality training signal you will ever collect about your own system’s accuracy.

Where clinicians stay in the loop

A system that drafts clinical documentation for review sits in a very different regulatory position from one that makes autonomous clinical determinations. Review is not a UX preference; it is a large part of what keeps a documentation tool clear of device-regulation questions.

Design for it structurally. Generated content arrives as a draft in a state that requires explicit acceptance. Per-field confidence is surfaced so attention goes where the system is least certain. Nothing enters the record without a clinician action, and that action is audited. Our AI medical scribe work is built this way for exactly this reason — the review step is the product, not an obstacle to it.

What this costs

Roughly a fifth of the engineering budget on a healthcare AI build, if it is designed in from the start: the boundary work, the deletion and reconciliation paths, the audit store, the entitlement enforcement, and the redaction layer on telemetry.

Retrofitted after a working prototype, it routinely costs more than the prototype did, because the two hardest pieces — source identifiers propagated into every chunk, and identity propagated into every retrieval call — are both structural. Neither can be added at the edges.

That asymmetry is the entire argument for treating HIPAA as an architecture input. It is not that compliance is expensive. It is that compliance is cheap in the right order and expensive in the wrong one.

Tools referenced

HHS Security Rule guidance
HHS de-identification guidance
pgvector — vector storage inside an existing Postgres compliance boundary
Presidio — PII and PHI detection and redaction

EpochC builds AI systems for healthcare and clinical documentation tooling with the PHI boundary, deletion paths and audit trail designed in from the first sprint. If you have a clinical AI build heading into security review — or one already stuck in it — book a technical discovery call. Bring your architecture diagram and we will mark where PHI actually crosses the boundary, which is usually two or three places nobody had drawn.

HIPAA-compliant AI architecture: PHI boundaries, retention and audit trails