HIPAA-Compliant AI: A Deployment Checklist

HIPAA does not mention large language models, vector databases, or prompt injection. It was written in 1996 and last meaningfully amended for the digital world by the HITECH Act in 2009. So when an engineering lead ships an AI feature that touches protected health information, the question is not whether HIPAA applies. It does. The question is how to map a 1996 statute onto a 2026 inference pipeline without a 30-day breach-notification letter at the end of it.

We build AI for regulated industries, and we are engineers, not lawyers. Treat this as an operational deployment checklist for the people who wire models into clinical workflows, not as legal advice. For binding interpretation of how the Privacy Rule and Security Rule apply to your deployment, get a healthcare attorney and your HIPAA officer to sign off. What we can hand you is the plumbing: the PHI data-flow with its Business Associate Agreement boundaries, the Security Rule safeguard checklist, the de-identification pipeline, and the reference architecture we use when we deliver ai healthcare company engagements.

Below is what we deliver to a team standing up a HIPAA compliant ai feature: the BAA-boundary data-flow diagram, a decision matrix of which model vendors will sign a Business Associate Agreement, the administrative, physical, and technical safeguard checklist, a minimum-necessary PHI gate in Python, a Safe Harbor versus Expert Determination de-identification pipeline, an audit-log schema, a reference architecture, a breach-notification check, and a 7-step deployment playbook. It reads like a runbook, not a compliance memo.

What HIPAA-compliant AI actually means (and what it does not)

There is no such thing as a HIPAA-certified model. No regulator stamps Claude, GPT-5, or Llama 4 as approved. HIPAA compliance is a property of your whole deployment, not of a model you call. A HIPAA compliant ai system is one where every place protected health information lands is covered by a Business Associate Agreement, the Security Rule safeguards are documented, and you can prove on inspection who accessed what and when. The model is one component inside that envelope. We cover the broader clinical-AI design surface in generative AI in healthcare; this post is the narrower deployment-checklist view.

HIPAA splits into two rules that matter here. The Privacy Rule governs how protected health information may be used and disclosed, and it carries the minimum-necessary standard: use or share only the smallest amount of PHI needed for the task. The Security Rule governs how electronic PHI is protected, through three safeguard categories: administrative (policies, training, risk analysis), physical (facility and device controls), and technical (access control, audit controls, integrity, transmission security). An AI deployment satisfies both, and most of the engineering lives in the technical safeguards.

Two terms set the scope of everything that follows. Protected health information is individually identifiable health information: a diagnosis tied to a name, a date of service tied to a medical record number. A business associate is any vendor that creates, receives, maintains, or transmits PHI on your behalf, which now includes the cloud you host on and the model API you call. The moment PHI flows to a vendor, that vendor is a business associate and needs a signed Business Associate Agreement, or you are out of compliance the instant the first request leaves your network.

PHI data flow and the Business Associate Agreement boundary

The first artifact we draw for any healthcare AI deployment is a data-flow diagram with the BAA boundary marked. The rule is simple to state and easy to violate: PHI may only cross into a system that sits inside a signed Business Associate Agreement. Every hop where identifiable data moves, from the application to the model endpoint to the vector store to the observability stack, is a place you either have a BAA or you have a problem. Most accidental violations happen at the boundaries teams forget: the logging pipeline, the eval traces, the analytics tool, the prompt cache.

The diagram makes one design rule obvious. There are two ways PHI can be handled safely: keep it inside the BAA boundary, or run it through the de-identification gate before it leaves. There is no third option where raw PHI reaches a vendor without a signed agreement and you stay compliant. When we audit, the first thing we look for is the boundary the team did not draw: the trace shipping full prompts to a no-BAA tool, the prompt cache on a consumer endpoint, the analytics export still carrying the medical record number.

Which LLM providers will sign a HIPAA BAA: the decision matrix

Your model choice is constrained by who will sign a Business Associate Agreement and under what configuration, so the best hipaa compliant ai stack is usually defined by the BAA path before model quality enters the conversation. The major cloud platforms sign a BAA, but it covers specific services in specific configurations, not the whole platform. As of 2026-Q2, 3 of the 5 deployment paths below clear the BAA bar at 100% coverage without a separate model-vendor agreement, because all three major clouds list a managed model service among their HIPAA-eligible services. Confirm current terms with each vendor's HIPAA documentation before you commit.

The pattern is consistent: reach the model through a cloud platform that signs a BAA (AWS Bedrock, Azure OpenAI, Google Vertex AI), or self-host an open model like Llama 4 inside your boundary. The trap is the convenient consumer endpoint: a developer prototypes against a free-tier API, the prototype becomes production, and PHI has been flowing to an uncovered vendor for months. The matrix exists to force that question before the first PHI request, not after.

The Security Rule safeguard checklist: administrative, physical, technical

The Security Rule organizes electronic PHI protection into three safeguard categories, and the technical safeguards are where most of the engineering sits. The table below is the working checklist we run against every healthcare AI deployment, with the AI-specific wrinkle each control picks up. It is the set an AI feature most often gets wrong.

Two controls are where AI differs from a normal application. Audit controls have to capture model decisions, not just database reads, because an inference on PHI is itself a use of that PHI. And minimum necessary now applies to prompt construction: a prompt that dumps an entire patient record to answer one question about a single lab value fails the standard. The next two sections turn these into code.

Minimum-necessary in code: a PHI gate before the prompt

The minimum-necessary standard is easy to honor in code and easy to forget in practice. Before any prompt is built, run the record through a gate that keeps only the fields the task declares it needs. The gate also decides whether PHI may stay (the path is BAA-covered) or must be de-identified first (the destination is not). We wire this in front of every model call so the decision is structural, not a reviewer's discretion.

"""phi_gate.py — minimum-necessary PHI gate before prompt construction.
Operational aid, not legal advice.
"""
from dataclasses import dataclass
from typing import Literal

# The 18 Safe Harbor identifier categories (paraphrased; confirm against the Rule).
SAFE_HARBOR_IDENTIFIERS = {
    "name", "geo_subdivision", "dates", "phone", "email", "ssn",
    "mrn", "account_number", "device_id", "ip", "biometric_id",
    "full_face_photo", "other_unique_id",  # + fax, plan id, license, vehicle, url
}
Destination = Literal["baa_covered", "no_baa"]


@dataclass
class GateResult:
    fields: dict
    deidentified: bool
    reason: str


def phi_gate(record, task_fields, destination: Destination) -> GateResult:
    # minimum-necessary: keep only the fields the task declares it needs
    scoped = {k: v for k, v in record.items() if k in task_fields}
    has_phi = bool(set(scoped) & SAFE_HARBOR_IDENTIFIERS)

    if destination == "baa_covered":
        return GateResult(scoped, False, "BAA-covered; min-necessary fields only")

    # no BAA: strip identifiers before the data can leave the boundary
    if has_phi:
        deid = {k: v for k, v in scoped.items()
                if k not in SAFE_HARBOR_IDENTIFIERS}
        return GateResult(deid, True, "no-BAA; Safe Harbor identifiers stripped")
    return GateResult(scoped, False, "no identifiers present")


if __name__ == "__main__":
    patient = {"name": "Jane Roe", "mrn": "A1234567",
               "latest_a1c": 7.2, "diagnosis_code": "E11.9"}
    out = phi_gate(patient, {"latest_a1c", "diagnosis_code"}, "baa_covered")
    print(out.fields)  # {'latest_a1c': 7.2, 'diagnosis_code': 'E11.9'}

The gate does two jobs at once. It enforces minimum necessary by scoping the record to declared task fields, and it routes: PHI may stay when the destination is BAA-covered, identifiers are stripped when it is not. The same pattern shows up in the ai medical scribe build vs buy decision, where a vendor scribe inherits the BAA but a custom one means you own this gate yourself. Either way, the gate runs in front of the model, not as a code-review item that gets skipped under deadline.

De-identification: Safe Harbor versus Expert Determination

De-identification is the legal off-ramp: once data is de-identified under HIPAA, it is no longer protected health information, and the Privacy Rule restrictions fall away. That is what lets you use a no-BAA analytics tool, an external eval harness, or a model you could not otherwise send PHI to. HIPAA gives you two methods, different in effort and risk.

For most AI deployments we reach for Safe Harbor first because it is deterministic and needs no outside expert: strip the eighteen identifier categories, confirm no actual knowledge of residual re-identification risk, and the data is no longer PHI. The cost is granularity. Safe Harbor coarsens dates to the year and geography to the state, which can blunt a model that depends on exact timing. Expert Determination keeps more detail but requires a statistician to certify very small risk, revisited when the data changes. The honest tradeoff is effort against analytic value.

Audit controls and access logging that pass inspection

The Security Rule requires audit controls: procedures that record and examine activity in systems containing electronic PHI. For an AI feature, that means logging every PHI access and every model decision in enough detail to reconstruct who did what. Two schema choices keep the log from becoming a liability. Log the hash of the input, not the raw input, so the trail satisfies the audit obligation without turning into a second PHI store. And record the human disposition on every decision, because clinical AI runs human-in-the-loop and the oversight is only provable if logged. The schemas we maintain in version control are below.

{
  "title": "PHI access + AI-decision audit-log entry",
  "type": "object",
  "required": ["event_id", "timestamp", "actor", "phi_subject_ref",
               "action", "input_hash", "model", "human_action"],
  "properties": {
    "event_id": { "type": "string", "format": "uuid" },
    "timestamp": { "type": "string", "format": "date-time" },
    "actor": { "description": "Unique workforce ID — no shared accounts." },
    "phi_subject_ref": { "description": "Pseudonymous ref, never raw MRN or name." },
    "action": { "enum": ["inference", "retrieval", "export", "override"] },
    "input_hash": { "description": "SHA-256 of the input; raw PHI is NOT logged." },
    "model": { "description": "e.g. Claude Sonnet 4 via AWS Bedrock" },
    "human_action": { "enum": ["accepted", "overridden", "escalated", "discarded"] }
  }
}

# phi-access-policy.yaml
# Role-based access to PHI + AI features. Enforced at the gateway, logged on every call.

principles:
  - unique_user_identity_required: true   # no shared service accounts
  - minimum_necessary: enforced_at_gate   # see phi_gate.py
  - default_deny: true

roles:
  clinician:
    may_access_phi: true
    destination: baa_covered_only
    audit: full

  analyst:
    may_access_phi: false
    destination: deidentified_only   # de-id gate runs first
    audit: full

  vendor_integration:
    may_access_phi: false
    destination: deidentified_only
    requires_baa: true   # blocked if no signed BAA on file
    audit: full

break_glass:
  enabled: true
  requires_justification: true   # reason captured
  post_hoc_review: required      # flagged within 24h

Notice what the access policy encodes. Each role carries an allowed destination: clinicians may use BAA-covered models on PHI, analysts only get de-identified data, a vendor integration with no signed BAA is blocked outright. The break-glass path is real because clinical emergencies are real, but it captures a justification and forces a post-hoc review, so emergency access does not become a quiet bypass. When an auditor asks how you control who runs a model on a patient record, this file and the matching log entries are the answer.

A reference architecture for HIPAA-compliant AI

The pieces assemble into a hipaa compliant ai architecture that is the same on every healthcare deployment we ship. PHI enters from the source system, passes the minimum-necessary gate, and only then reaches a BAA-covered model endpoint. The de-identification gate sits on any branch that leaves the boundary. The audit log captures the access and the human disposition. The discipline is that every stage is wired in by default, not added after an incident.

Where the feature retrieves from a corpus of patient records, the vector store sits inside the BAA boundary and inherits the same access policy as the model. Concrete hipaa compliant ai examples that ride this exact path include an ambient clinical scribe, a chart-summarization assistant, and a prior-authorization drafter; we go deeper on those use cases in our overview of generative AI in healthcare. The architecture here is the compliance-shaped view of that same system, drawn so the BAA boundary and the audit trail are first-class.

Breach notification readiness: the dated obligations

Compliance is also about what happens when a control fails. The HIPAA Breach Notification Rule sets the clock, and an AI deployment introduces breach surfaces a normal app does not: a prompt that leaked PHI to an uncovered endpoint, a trace that captured a full record, an output exposed to the wrong role. The dated obligations below belong on the incident runbook before launch.

Read these backward into the architecture. The 60-day individual-notice window means you need detection fast enough to investigate inside it, which is what the audit log is for. The encryption safe harbor makes encryption breach insurance, not just a safeguard. And because a business associate has to notify the covered entity of a breach, your BAA inventory is also your notification chain: if you do not know which vendor holds which PHI, you cannot run the rule.

The HIPAA compliant ai deployment checklist: 7 steps

This is the hipaa compliant ai guide we actually hand teams: a checklist that turns the pieces into a sequence. Order matters, because you cannot scope BAAs before you know where PHI flows, nor design controls before you know your gaps. Each step produces an artifact for your risk analysis. Run it once to deploy, then keep steps 5 through 7 running for the life of the feature.

Step 1 is the one teams skip and the one that bites. You cannot protect PHI you have not traced. The most common first finding in our audits is a forgotten boundary: an observability tool capturing full prompts, an analytics export still carrying the medical record number, a prototype endpoint never swapped for the BAA-covered one. Draw the flow honestly first.

Step 7 closes the loop, and most programs treat it as optional. A HIPAA deployment is not a launch-day certificate. A model-version bump changes what the system does and may change its risk surface; a new use case can pull a low-risk feature into territory that touches more PHI. Wire reclassification triggers and review dates into a recurring check, and fail the build when a control's evidence path goes missing or its review date passes. A posture that runs once and is never revisited expires the moment the system changes.

Where HIPAA AI deployments actually fail

A third pattern is the prototype that becomes production. A developer builds against a convenient consumer endpoint to prove the feature works, the demo lands, and the prototype ships with the same endpoint wired in. No BAA was ever signed, and PHI has been flowing to an uncovered vendor since the first real patient request. The decision matrix earlier exists partly to force the BAA-path choice at design time, before convenience hardens into a gap that is expensive to unwind.

Build the HIPAA program in-house or engage help

The honest comparison is between standing up the HIPAA AI program with your own team and engaging help to bootstrap it. Neither is universally right. A team with an existing security function and one well-scoped feature can run this checklist themselves. A team shipping its first clinical AI under a deadline usually cannot stand up the PHI mapping, BAA inventory, de-identification pipeline, audit logging, and breach runbook from a standing start in the time available.

FAQ