An AI system is HIPAA compliant when every company that handles protected health information (PHI) for it has signed a business associate agreement (BAA), the model and the people around it see only the PHI the task needs, access is tied to named users and service accounts, every access is logged, PHI is encrypted in transit and at rest, retention is decided on purpose, and a person reviews anything clinical before it reaches a patient or a record. No model is HIPAA compliant on its own; the whole system is. Below: what each piece means in practice, which AI vendors sign a BAA and for which products (checked on 23 October 2026), and a checklist for any vendor or build. This is a buyer's guide written by engineers. Your privacy officer and counsel make the final call.
What makes an AI system HIPAA compliant
HIPAA does not mention AI. It regulates covered entities (providers, health plans, clearinghouses) and their business associates, whether PHI goes to a billing clerk or a language model. Three parts of the rules do most of the work:
- The Privacy Rule decides who may use or see PHI and how much of it. The minimum necessary standard and de-identification live here.
- The Security Rule sets the technical safeguards: access control, audit controls, integrity, authentication and transmission security, in 45 CFR 164.312.
- The business associate rules require a written agreement with every vendor that creates, receives, maintains or transmits PHI on your behalf.
BAAs: which AI vendors sign one, and for what
A BAA covers named products and configurations, never a whole company. A vendor can sign one for its API while its chat app stays out of scope. This is what each vendor's own pages said on 23 October 2026:
| Vendor | What a BAA can cover | What stays outside it |
|---|---|---|
| OpenAI | The API on BAA-eligible endpoints, with a standard BAA accepted in the API Platform for organisations with API usage history or by request; ChatGPT for Healthcare, ChatGPT Enterprise with a Regulated Workspace and ChatGPT for Clinicians | ChatGPT Business and consumer plans; API web search with live internet access |
| Anthropic | The Claude API with HIPAA readiness switched on, using the standard BAA in the Claude Console or a negotiated one through sales, for features marked eligible | Claude Free, Pro and Max; PHI typed into the Console; Claude Code; beta features not listed as eligible |
| Google Cloud | Products on its covered list, including Gemini Enterprise Agent Platform (formerly Vertex AI), Generative AI on Agent Platform, Document AI and Speech-to-Text | Any service not on the list. Google's page says that if you cannot disable a service, you must not use it for PHI |
| Microsoft Azure | In-scope Azure services under the HIPAA BAA that is part of the Product Terms and Data Protection Addendum, with no separate signature; models sold by Azure, including Azure OpenAI, are governed by the DPA | Services and models outside the published audit scope. Microsoft has not published a model-by-model list, so get written confirmation for each model |
| AWS | Services on the HIPAA Eligible Services Reference, including Amazon Bedrock, Bedrock AgentCore, Transcribe (with HealthScribe) and Comprehend Medical, once an AWS BAA is in place | Services not on the reference list |
Sources: OpenAI's data controls guide and its help-centre articles on BAAs (the help centre blocked our fetch, so we relied on search results quoting it), Anthropic's API and data retention docs, Google Cloud's HIPAA page, Microsoft's Azure HIPAA page and the AWS HIPAA Eligible Services Reference (last updated 15 October 2026).
Two details catch teams out. The same model can sit under different contracts. Anthropic's docs say that when you use Claude through Amazon Bedrock or Google Cloud, the cloud provider processes the data, so its BAA applies. Features inside a covered product can fall outside the BAA. Anthropic's API rejects non-eligible features for HIPAA-enabled organisations, and OpenAI lists live web search as not covered. Read the feature table as well as the product name.
The chain also includes the vector database, the tracing and evaluation tools, the error tracker and any review tool. If PHI reaches it, it needs a BAA or it must stop receiving PHI. Gigabit signs a BAA for engagements that touch PHI, because during a build the engineers are one of those hops.
The minimum necessary standard
The Privacy Rule requires covered entities and business associates to make reasonable efforts to limit PHI to the minimum necessary to accomplish the intended purpose of a use, disclosure or request (45 CFR 164.502(b)). Section 164.514(d) adds that you must identify which people or classes of people need access, and to which categories of PHI. The standard does not apply to disclosures to a provider for treatment, to the patient, or under an authorisation, among a few other exceptions.
For an AI system, treat each agent as one more class of user. An intake agent needs demographics, insurance and reason for visit. A prior-authorisation assistant needs the order, the diagnosis codes and the payer rules. Neither needs the full chart. In practice:
- Build the prompt from named fields pulled by a query you control, instead of pasting the whole chart.
- Give retrieval indexes only the documents and fields the task needs, and filter by patient and user at query time.
- Strip identifiers the model does not need before the call, and re-attach them afterwards from your own system.
- Write the field list into the system's documentation, so the minimum necessary decision is on record.
De-identifying PHI: Safe Harbor or Expert Determination
Data that meets the de-identification standard in 45 CFR 164.514(b) is no longer PHI, so it can be used for evaluation sets, prompt testing and analytics without a BAA. The rule gives two methods.
Safe Harbor removes 18 kinds of identifiers of the patient and of relatives, employers and household members. They include names, places smaller than a state (the first three ZIP digits may stay if that area holds more than 20,000 people), every date element except the year, ages over 89, contact details, record and account numbers, device identifiers, IP addresses, biometrics and full-face photos. You must also have no actual knowledge that what remains could identify someone.
Expert Determination uses a person with appropriate statistical and scientific expertise who determines that the risk of re-identification by the anticipated recipient is very small, and documents the methods and results. HHS's de-identification guidance says there is no fixed numerical level that counts as very small for every dataset; the expert sets it for the data and the recipient.
Safe Harbor is hard to apply to free text. Notes and call transcripts mention names, dates and places mid-sentence, and a redactor that catches most of them still leaves the rest. For evaluation sets built from notes, budget for Expert Determination or a human check of every record. You may keep a re-identification code under section 164.514(c) as long as it is not derived from patient information and the key stays with you.
Access controls and audit logs
The Security Rule's access control standard covers "persons or software programs" that have been granted access rights, which describes an AI agent exactly. Each user needs a unique ID, and so should each agent: one service account per agent and environment, scoped to the actions its task needs, with short-lived credentials. Reviewers' sessions should time out, and provider accounts should use multi-factor sign-in.
The audit controls standard (164.312(b)) requires mechanisms that record and examine activity in systems that contain or use ePHI. For AI that means logging which user or agent triggered the call, which records were retrieved, the prompt and model version, the tools called, the output, and who approved or changed it. Keep the log inside your BAA-covered environment with restricted access, because a full prompt log is a copy of the PHI. The production agent stack post shows where logging sits.
Encryption and retention
In the current rule text, encryption at rest and in transit is an addressable specification: you implement it, or document why an equivalent measure is reasonable. HHS proposed in January 2025 to make encryption required, and no final rule had been published by 23 October 2026. Treat it as required anyway: TLS on every hop, encrypted databases, storage and backups, and field-level encryption for the most sensitive columns.
Retention needs two decisions. Your own records: HIPAA requires security policies and documentation to be kept for six years (164.316(b)(2)); medical record retention is set by state law. The vendor's copies: a BAA does not always mean zero retention. Anthropic's docs say HIPAA readiness applies safeguards rather than immediate deletion, and that flagged content can be kept for up to two years under any arrangement. OpenAI's guide says BAA-eligible endpoints can be used for PHI even if data is retained. Azure stores flagged prompts for human abuse review unless you are approved for modified abuse monitoring. Stateful features such as threads, files and vector stores keep data until you delete it. Write down where each copy lives and for how long.
Human review for clinical outputs
HIPAA does not require a human to check AI output. Patient safety does, and so will most health systems' review boards. Draw the line by consequence: an agent may answer a parking question alone, but a visit summary, a coded claim, a medication message or anything entering the chart should be a draft that a named person approves, with the approval logged. Our human-in-the-loop guide covers how to place those checkpoints without rebuilding the bottleneck.
Evaluations matter more here because the dangerous failure is a fluent, wrong answer entering a record. Build test sets from de-identified cases, set thresholds that block a release, and re-run them on every model change. Our Managed AI Operations team runs that routine monthly, and the results double as your evidence file.
How this looks in Gigabit's published builds
A specialty clinic's patient assistant answers administrative and prep questions only, with PHI redaction, refusal rules and escalation to staff with a summary. It cut repetitive front-desk inquiries 62% in eight weeks. A 14-location medical group's intake system syncs to the EHR through an HL7/FHIR bridge with least-privilege credentials, audit logs on every write and encryption throughout, and cut intake and admin time 41%. The telehealth platform is not an AI system, but it shows the baseline an AI feature sits on: BAA-covered AWS infrastructure, encryption down to the field, CloudTrail audit logs, role-based access, 15-minute timeouts, MFA and a third-party security assessment before launch. The patient intake integration guide covers the intake pattern.
Buyer checklist for any HIPAA compliant AI vendor or build
| Control | What to ask | What a good answer looks like |
|---|---|---|
| BAA chain | Which companies touch PHI, and does each have a BAA covering the exact product and features used? | A written list of every hop, from model provider to logging tool, each with a BAA reference |
| Model configuration | Which endpoints, features and deployment types are in use? | Only features the vendor marks as BAA-eligible; non-eligible features blocked or unused |
| Minimum necessary | Which PHI fields does each prompt and index receive? | A documented field list per agent, enforced by the query that builds the prompt |
| De-identification | How are evaluation and test sets made? | Safe Harbor or a documented Expert Determination; no production PHI in development |
| Access control | How are users and agents identified and limited? | Unique IDs, one scoped service account per agent, MFA, automatic logoff |
| Audit logs | Can you show who or what accessed which record, and what the model produced? | Logs of retrieval, prompt, model version, tool calls, output and approver, kept in a covered environment |
| Encryption | Where is PHI encrypted? | TLS on every hop; encrypted databases, storage, backups and logs |
| Retention | How long does each vendor and each feature keep data? | A written retention map, including flagged-content and stateful-feature exceptions |
| Human review | Which outputs reach a patient or a record without a person approving them? | None that are clinical; approvals recorded in the audit log |
| Evaluation and monitoring | How do you know quality has not dropped after a model change? | Eval sets with release thresholds, re-run on every model or prompt change |
| Incident response | What happens if PHI goes somewhere it should not? | A runbook that connects to your breach assessment process, with named owners |
Where to start
Pick a workflow with high volume and bounded clinical risk, such as intake, scheduling, prior-authorisation paperwork or front-desk questions, and design the BAA chain and field list before the first prompt. The AI Transformation Sprint ($25,000 fixed, 2 weeks) scopes the workflow, the data boundaries and the BAA chain and ends in a working pilot. If AI already runs across teams, AI governance builds the inventory, policies and controls around it, and the AI Security Assessment tests an existing agent for prompt injection and data leakage. The AI for Healthcare page sets out how we handle PHI, and the readiness assessment shows where your foundations stand.
