Guide
HIPAA-compliant AI and chatbots: the architecture behind the claim
HIPAA compliance belongs to a deployment: the contracts around it and the way it is built. HIPAA binds health plans, healthcare clearinghouses and providers that bill electronically, and any business associate working for them: anyone who creates, receives, maintains or transmits protected health information on their behalf. So every vendor in a chatbot's data path needs a business associate agreement (BAA): the model provider, the host, the retrieval store, and any logging or analytics tool that sees patient data. The system then has to meet the Privacy, Security and Breach Notification Rules in how it is built, with minimum necessary access, a documented risk analysis, access and audit controls, and breach reporting. HHS does not certify products. On the vendors' own help pages (dates below), OpenAI offers a BAA for its API with Modified Retention and for named ChatGPT offerings, but not ChatGPT Business, and Anthropic offers one for its first-party API and HIPAA-ready Claude Enterprise organisations. Each covers listed features only.
HIPAA-compliant AI. An AI system that handles protected health information under business associate agreements with every vendor in its data path, and whose design meets the HIPAA Privacy, Security and Breach Notification Rules.
1AYM is an OpenAI Select Partner. Its founder holds personal Claude certifications. 1AYM is not an Anthropic partner.
Checked . Regulations were read on the eCFR and the Federal Register, HHS guidance in copies archived on 26 and 27 September 2026, Anthropic's and AWS's terms and OpenAI's Codex HIPAA guide on their live pages, and OpenAI's help articles in their latest archived versions, of 25 and 31 July 2026. Vendors change which products and features their BAA covers without notice, so confirm the list in your own BAA before any patient data flows. This page is not legal advice.
There is no HIPAA certificate, so the claim has to be an architecture
Search for a HIPAA-compliant chatbot and you mostly find products that call themselves one. The label tells you less than it seems to. HHS's Office for Civil Rights says it does not endorse, certify or recommend specific technology or products [1]. The Security Rule is written to be flexible, scalable and technology neutral [14], so nothing in it names a model, a vector database or a chatbot. What the rules do name is who is responsible for patient data and what they must do with it.
Two kinds of organisation carry the duties. Covered entities are health plans, healthcare clearinghouses and providers who conduct certain billing transactions electronically. Business associates are the people and companies that create, receive, maintain or transmit protected health information (PHI) for them, including subcontractors that do the same for a business associate [1, 2]. So when a hospital, a health plan or a digital health company serving one puts an AI assistant in front of patient data, every vendor in that path is in scope.
I read a vendor's "HIPAA compliant" badge as a statement that it will sign a business associate agreement for some of its features. That matters, and it is the first step of the work. A security report is a different document: it does not stand in for the agreement, and a separate guide to reviewing an AI supplier that has no SOC report covers the evidence to ask a supplier for alongside it.
What the three HIPAA rules ask of an AI system
The rules predate generative AI and never mention it. Read against a chatbot or an assistant, this is what each one asks. The numbers in brackets point to the sources at the foot of the page.
| Dimension | What the rule requires | What it means for an AI system |
|---|---|---|
| Minimum necessary [3] | Reasonable efforts to limit PHI to the minimum necessary for the purpose of each use, disclosure or request. It does not apply to disclosures to a provider for treatment. | Retrieval and prompts carry only the fields the task needs. A scheduling assistant has no use for the diagnosis. |
| Business associate agreement [3, 4] | Written satisfactory assurances from each business associate, and from each of its subcontractors, that PHI will be safeguarded. | A signed BAA with the model provider, the host and every tool that stores or processes prompts, answers or logs containing PHI. |
| Risk analysis [8] | An accurate and thorough assessment of the risks to the confidentiality, integrity and availability of electronic PHI, and security measures that reduce them to a reasonable and appropriate level. | The model, the prompts, the retrieval store and the logs are all in the assessment, with the risks peculiar to them: prompt injection, over-broad retrieval, and answers that reveal another patient's data. |
| Technical safeguards [7, 9] | Access control with unique user identification, audit controls, integrity controls, person or entity authentication, and transmission security. Encryption is addressable: implement it if reasonable and appropriate, or document why not and adopt an equivalent where reasonable. | The assistant acts as a known user with that user's permissions, every request and answer is recorded, and traffic between every component is encrypted. |
| Training and sanctions [8] | A security awareness and training programme for the whole workforce, management included, and sanctions for staff who breach the policies. | Staff know which AI tools may see PHI and which may not, and the policy has consequences. |
| Documentation [10] | Policies, procedures and assessments kept for six years from creation or from when they were last in effect, whichever is later. | The data-flow diagram, the BAA inventory and the test results are filed with the risk analysis. |
| Breach notification [11, 12] | An impermissible use or disclosure is presumed to be a breach unless a risk assessment of at least four set factors shows a low probability that the PHI was compromised. A business associate tells the covered entity without unreasonable delay, and within 60 calendar days of discovery. | A prompt sent to a tool without a BAA is an impermissible disclosure to assess. The logs have to be good enough to say which patients were affected. |
| De-identification [5, 6] | Data stops being PHI if an expert determines the risk of re-identification is very small, or if 18 listed identifiers are removed and there is no actual knowledge that the rest could identify someone. De-identified data is not restricted by the Privacy Rule. | The route for analytics, evaluation sets and model testing. Removing names is not enough: dates, zip codes, IP addresses and URLs are on the list. |
The Security Rule may change. HHS published proposed changes on 6 January 2025, with comments closing on 7 March 2025 [15]. As of the date above, the Federal Register lists only that proposed rule against its regulation number, the eCFR text of the technical safeguards is unchanged since 2013 [9], and HHS's regulatory agenda lists the rule as a long-term action with final action targeted for July 2027 [16]. Build to the rule in force, and check the Federal Register again before you sign off the design.
What a business associate agreement covers, and what it does not
The regulations set what a BAA must contain. The contract must set the permitted uses of PHI, require appropriate safeguards and compliance with the Security Rule for electronic PHI, require the business associate to report any use the contract does not allow, breaches included, pass the same restrictions down to subcontractors, support patients' rights of access, amendment and an accounting of disclosures, open its books to HHS, and require the PHI to be returned or destroyed at the end of the contract where feasible [4].
That is the floor, and it is worth having. A cloud provider under a BAA is contractually liable for its terms and directly liable under the HIPAA Rules [1]. The gaps are where teams get caught out.
- It does not make your use permitted
- The BAA governs the vendor. Whether your assistant may use a patient's record for a given purpose is still a Privacy Rule question for you [3].
- It covers named features, not the whole product
- OpenAI and Anthropic both list the products, endpoints and features their BAA covers, and leave the rest outside it [18, 19]. A feature off the list is outside the BAA even when it sits in the same admin console.
- It stops at the vendor's edge
- Anthropic states that data sent to third parties through connectors and MCP servers is not covered by its BAA [19]. OpenAI states that its BAA does not apply to the Codex client running on your machines or to third-party services it reaches [18]. Each third party needs its own agreement.
- It does not cover your other vendors
- The host, the vector database, the logging platform, the error tracker and the analytics tool each need their own BAA if they hold PHI for you. HHS treats a cloud provider that stores only encrypted PHI, without the key, as a business associate all the same [1].
- Signing it does not settle status
- HHS says a tracking technology vendor is a business associate if it meets the definition, whether or not a BAA is in place, and that signing one does not make a vendor a business associate if it does not [13].
- It does not give you audit rights
- HHS says the rules do not require a cloud provider that is a business associate to share documentation of its security practices or to allow audits; the BAA is the assurance [1]. If you want audit rights or reports, negotiate for them.
Is ChatGPT HIPAA compliant? What OpenAI and Anthropic offer
Neither ChatGPT nor Claude is HIPAA compliant as a product, for the reason above. What each vendor offers is a route to a BAA for some plans and features. This table sets out what each publishes. It is a reading of their help pages, not a recommendation between them.
| Dimension | OpenAI | Anthropic |
|---|---|---|
| How to get a BAA [17, 19] | API: email baa@openai.com; requests are reviewed case by case, and OpenAI says it approves most. ChatGPT: through sales, for Enterprise or Edu customers with a sales-managed account. ChatGPT for Clinicians: a separate in-product BAA flow for eligible individual clinicians | Claude Enterprise: the Primary Owner turns on HIPAA in the organisation settings and accepts the BAA. API: the Primary Owner signs the BAA, then asks Anthropic to turn it on |
| Chat products it covers [18, 19] | ChatGPT for Healthcare, ChatGPT for Enterprise with Regulated Workspace, ChatGPT FedRAMP and ChatGPT for Clinicians | HIPAA-ready Claude Enterprise organisations. A standard Enterprise plan is not covered until the Primary Owner acts |
| Named as not covered [17, 19] | ChatGPT Business | Claude Console, Claude Cowork, and beta features such as Claude in Office, Claude Design, Claude Slides and Claude Docs |
| API conditions [18, 19] | The organisation must be provisioned with Modified Retention; listed endpoints, including responses, chat completions, embeddings, files, vector stores and realtime, may then process PHI | The Messages API and listed features are covered. The Batch, Files and Skills APIs, code execution, computer use and web fetch are not, and are not available to HIPAA-ready API users |
| Coding tools [18, 19, 22] | Codex Local signed in with an eligible account is covered for the data OpenAI processes; the client on your machines is your responsibility. Codex cloud is not covered | Claude Code is covered only with zero data retention enabled; its web, remote and several beta modes are not covered |
| Features outside the BAA [18, 19] | Off by default in eligible workspaces; admins may enable them for uses that involve no PHI | Connectors, MCP servers, enterprise search and Claude in Chrome can be used, but data they send to third parties is not covered |
Neither vendor lists a consumer plan among the services its BAA covers [17, 18, 19]. When staff paste patient details into a personal ChatGPT or Claude account not covered by a BAA, that is a disclosure to a vendor with no BAA, and it has to be assessed as a possible breach [11].
A BAA-eligible workspace does not finish the job either. You still decide which staff may use it, what they may put in it, which admin settings stay off, and how you will know when the policy is broken. Those are the access, training and sanction duties from the table above [8, 9].
The model does not have to come from its maker. AWS lists Amazon Bedrock among the services eligible under its own BAA [20], so a team already on AWS can call models there. The same questions apply: which models, which features, and whose logs.
A reference architecture for a HIPAA-compliant chatbot
This is the shape I would put in front of a security reviewer for a patient-facing or staff-facing assistant. Each layer answers a question the rules ask, and the order matters: the controls sit in front of the model, in code the prompt cannot change.
- Sign-in and identity
- Every user is authenticated and has a unique identity before the assistant sees anything, and idle sessions end [9]. The assistant acts as that user, with that user's permissions, never as a service account that can read every record.
- A PHI gateway in front of the model
- One service decides what reaches the model. It pulls only the fields the task needs, strips the rest, and refuses requests outside the purposes you documented [3]. This is where minimum necessary stops being a policy and becomes code.
- A model endpoint under a BAA
- Only endpoints and features on the vendor's eligible list, on an account set up the way the BAA requires, such as Modified Retention at OpenAI or a HIPAA-ready organisation at Anthropic [18, 19]. Everything else is switched off at the account level.
- A retrieval store inside the boundary
- Documents and embeddings built from patient records hold PHI. Host them with a provider under a BAA [1], and filter results by the user's permissions before they reach the prompt, so one patient's question cannot pull another patient's record.
- Logs that are useful without leaking
- Audit logs record who asked what, what was retrieved and what was answered, because the audit-control standard asks for it and a breach assessment depends on it [9, 11]. Operational logs and traces are redacted, or they stay with a vendor under a BAA.
- No trackers on signed-in pages
- HHS says tracking technologies on pages behind a login generally have access to PHI, and that a vendor's promise to remove or de-identify the data is not enough without a BAA [13]. Keep analytics pixels and session-replay scripts off the chat surface.
- Retention and deletion
- Set how long prompts, answers, embeddings and logs are kept, at each vendor as well as in your own systems, and test the deletion. When a contract ends, the business associate must return or destroy the PHI where feasible [4].
- A way to a human
- The assistant hands anything clinical, urgent or out of scope to a person, and nothing changes a record without a deterministic check or a named reviewer. It is the pattern I call agent proposes, verifier gates: the model suggests, and something that is not a model decides.
HHS allows PHI to be stored with a cloud provider outside the United States under a BAA, but says the risks vary with location and belong in the risk analysis [1]. If your own policy on where data sits is stricter than HIPAA, the architecture has to honour both.
Where HIPAA chatbot projects go wrong
The failures to look for first are rarely in the model. They are in the tools around it, which nobody thought of as part of the system.
- PHI in a tool with no BAA
- A developer tests with real records in a personal account, or a support agent pastes a patient's message into a general chatbot. Either is an impermissible disclosure that has to be assessed as a possible breach [11].
- Logs shipped to an observability vendor
- Prompts and answers flow into a tracing, error-tracking or analytics platform by default. If that vendor maintains PHI for you, it is a business associate and needs a BAA [2].
- A pixel on the chat page
- A marketing or session-replay script on a signed-in page can collect what patients type [13].
- A feature switched on after launch
- An admin enables a connector, web fetch or a batch job the vendor's BAA does not cover, and PHI leaves the covered boundary without anyone deciding it should [18, 19].
- De-identification that is not
- Dropping names and record numbers leaves dates, zip codes, IP addresses and free text that can still identify someone. The safe harbor method lists 18 kinds of identifier, and also requires no actual knowledge that what remains could identify a person [5].
- Retrieval without permissions
- Search runs over the whole record store and leaves filtering to the prompt. Sooner or later it returns one patient's notes to a user who should never see them.
State rules on top: Texas requires patients to be told
HIPAA sets a federal floor, and states add to it. Texas is the clearest example for AI in care. The Texas Responsible Artificial Intelligence Governance Act (HB 149), in effect since 1 January 2026, adds section 552.051 to the Business and Commerce Code [21]. Where an AI system is used in relation to health care service or treatment, the provider must tell the patient or their personal representative no later than the date the service or treatment is first provided, or as soon as reasonably possible in an emergency [21]. The disclosure must be clear and conspicuous, in plain language, free of dark patterns, and may be given by hyperlink [21].
This page does not survey every state. If your patients live in several states, ask counsel which AI disclosure and health privacy laws apply before launch. None of this is legal advice.
How to test it before a patient uses it
A HIPAA chatbot is ready when you can show where the data goes. These are the tests I would want passed and filed with the risk analysis [8, 10].
- BAA inventory against the data-flow diagram
- Every component on the diagram that stores or processes PHI has a signed BAA and is on that vendor's eligible list. Any component without one is a finding.
- Canary records
- Seed synthetic patients with unique marker strings, run them through every flow, then search every log, trace, analytics tool and vendor dashboard for the markers. Anything that turns up where it should not is a leak you found before a regulator did.
- Cross-patient access
- Sign in as one user and try to reach another patient's data: by asking directly, by instructions hidden in an uploaded document, and by guessing identifiers. Every attempt should fail and be logged.
- Minimum necessary
- Inspect the prompts the gateway actually sends for a sample of tasks, and confirm they carry only what each task needs [3].
- Deletion
- Delete a synthetic patient's conversation and confirm it is gone from the application, the retrieval store and each vendor within the periods you set.
- Breach drill
- Walk through a simulated disclosure: who assesses it, which logs identify the patients affected, and how the covered entity hears about it within 60 calendar days [11, 12].
- Escalation
- Confirm the assistant hands clinical questions and emergencies to a person, and that no prompt can make it change a record without passing the gate.
Where 1AYM fits
1AYM designs and builds AI systems to HIPAA's requirements. For an assistant that touches patient data, that is our production AI systems work: the gateway, the retrieval permissions, the audit logging and the tests above, handed over with a runbook. Where the need is staff using ChatGPT or Claude at work, rolling those tools out with admin controls and a usage policy is core work for us, as in our documented AI platform rollout.
Any supplier whose people handle PHI during a build is a business associate, so settle in the statement of work whether the build needs real patient data at all. For health work we build and test on synthetic or de-identified data by default. Whether 1AYM signs a business associate agreement depends on the engagement and is settled in the contract. If the job is already scoped, we can resource it on contract from the collective of associates who work with 1AYM, held to the same standard.
For engineers: BAA-eligible endpoints and controls to check
The settings behind the architecture, each with its source. Vendor lists change, so check them against the version your own BAA references.
- OpenAI API
- HIPAA eligibility depends on the organisation being provisioned with Modified Retention. The eligible endpoints then include /v1/responses, /v1/chat/completions, /v1/embeddings, /v1/files, /v1/vector_stores, /v1/audio/transcriptions and /v1/realtime [18].
- OpenAI ChatGPT workspaces
- Functionality outside the BAA is disabled by default and can be enabled through RBAC groups, for uses that involve no PHI. Eligible workspaces run web search against OpenAI's own index rather than third-party search providers [18].
- Anthropic API
- Covered Messages API features include prompt caching, structured outputs, memory, web search, the bash tool and the text editor tool, under BAA versions accepted after 1 April 2026. Covered Models require 30-day retention and are not available with zero data retention [19].
- Anthropic Claude Code
- Covered only with zero data retention, which is offered to qualified accounts. The remote, web, code review, security, computer use and remote control modes are not covered [19].
- Amazon Bedrock
- On AWS's HIPAA Eligible Services Reference, last updated 3 September 2026, where every feature of a listed service is eligible unless the list notes otherwise [20].
- Security Rule mapping
- Unique user identification and an emergency access procedure are required. Automatic logoff, encryption of stored and transmitted ePHI and integrity mechanisms are addressable: implement each, or document why it is not reasonable and adopt an equivalent where one is [7, 9].
- Audit and review
- Audit controls must record and examine activity in systems that contain or use ePHI, and records of system activity such as audit logs and access reports must be reviewed regularly [8, 9].
- Breach clock
- A business associate is treated as knowing of a breach from the first day any employee or agent, other than the person who committed it, knew or with reasonable diligence would have known. The 60 days run from then [12].
- Tracking guidance status
- On 20 June 2024 a federal district court in Texas vacated the part of HHS's tracking bulletin that applies HIPAA where a technology connects an IP address with a visit to an unauthenticated public page about health conditions or providers; HHS says it is evaluating next steps. The passages on signed-in pages cited above sit outside the vacated part [13].
Sources
- [1]HHS Office for Civil Rights, Guidance on HIPAA and Cloud Computing (content last reviewed 23 December 2022), read 29 September 2026 in the archived copy of 27 September 2026
- [2]45 CFR 160.103, Definitions (business associate), eCFR, read 29 September 2026
- [3]45 CFR 164.502, Uses and disclosures of protected health information (minimum necessary; business associate disclosures), eCFR, read 29 September 2026
- [4]45 CFR 164.504(e), Business associate contracts, eCFR, read 29 September 2026
- [5]45 CFR 164.514, De-identification of protected health information, eCFR, read 29 September 2026
- [6]HHS Office for Civil Rights, Guidance Regarding Methods for De-identification of Protected Health Information (content last reviewed 3 February 2025), read 29 September 2026 in the archived copy of 26 September 2026
- [7]45 CFR 164.306, Security standards: general rules (required and addressable specifications), eCFR, read 29 September 2026
- [8]45 CFR 164.308, Administrative safeguards (risk analysis, sanctions, training), eCFR, read 29 September 2026
- [9]45 CFR 164.312, Technical safeguards, eCFR, read 29 September 2026
- [10]45 CFR 164.316, Policies and procedures and documentation requirements, eCFR, read 29 September 2026
- [11]45 CFR 164.402, Definitions (breach), eCFR, read 29 September 2026
- [12]45 CFR 164.410, Notification by a business associate, eCFR, read 29 September 2026
- [13]HHS Office for Civil Rights, bulletin on the use of online tracking technologies by HIPAA regulated entities (partly vacated on 20 June 2024; content last reviewed 26 June 2024), read 29 September 2026 in the archived copy of 26 September 2026
- [14]HHS Office for Civil Rights, Summary of the HIPAA Security Rule (content last reviewed 7 August 2026), read 29 September 2026 in the archived copy of 27 September 2026
- [15]Federal Register, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, proposed rule, 90 FR 898 (6 January 2025), RIN 0945-AA22, read 29 September 2026
- [16]Office of Information and Regulatory Affairs, Unified Agenda entry for RIN 0945-AA22 (2026 Unified Agenda, pubId 202510), read 29 September 2026
- [17]OpenAI Help Center, How can I get a Business Associate Agreement (BAA) with OpenAI for the API Services?, read 29 September 2026 in the archived copy of 31 July 2026
- [18]OpenAI Help Center, HIPAA Eligible Products and Functionality, read 29 September 2026 in the archived copy of 25 July 2026
- [19]Anthropic Privacy Center, Business Associate Agreements (BAA) for Commercial Customers, read 29 September 2026
- [20]AWS, HIPAA Eligible Services Reference (last updated 3 September 2026), read 29 September 2026
- [21]Texas Legislature, HB 149 (89th Legislature), enrolled version, Texas Responsible Artificial Intelligence Governance Act, Business and Commerce Code section 552.051, read 29 September 2026
- [22]OpenAI, ChatGPT Learn, HIPAA configuration guide for Codex, read 29 September 2026
HIPAA and AI questions
Is ChatGPT HIPAA compliant?
No product is HIPAA compliant by itself. In OpenAI's help articles as last archived in July 2026, OpenAI offers a business associate agreement for its API with Modified Retention and for named ChatGPT offerings, including ChatGPT for Healthcare and ChatGPT for Enterprise with Regulated Workspace, and states that it does not offer one for ChatGPT Business. No consumer ChatGPT plan is on its list. An eligible workspace still needs your own access rules, training and policy.
Is Claude HIPAA compliant?
Not as a product. As read on 29 September 2026, Anthropic offers a business associate agreement for its first-party API and for HIPAA-ready Claude Enterprise organisations, turned on by the organisation's Primary Owner. It excludes Claude Console, Claude Cowork and beta features, and data sent to third parties through connectors. Claude Code is covered only with zero data retention enabled.
Is there a HIPAA certification for AI tools?
No. HHS's Office for Civil Rights states that it does not endorse, certify or recommend specific technology or products. When a vendor calls its product HIPAA compliant, it usually means the vendor will sign a business associate agreement covering some of its features.
Do we need a BAA with our AI vendor?
Yes, if the vendor will create, receive, maintain or transmit protected health information on behalf of a covered entity or another business associate. HHS applies that to cloud providers that store only encrypted data and hold no key. The same goes for the logging, analytics and hosting vendors in the system's data path.
Can we use de-identified data instead?
Where the task allows it, yes. De-identified data is not protected health information and the Privacy Rule does not restrict it. HIPAA recognises two methods: an expert determination that the risk of re-identification is very small, or removal of 18 listed identifiers with no actual knowledge that the rest could identify someone. Removing names alone does not qualify.
Does HIPAA require patient data to stay in the United States?
No. HHS says a covered entity or business associate may use a cloud provider that stores PHI on servers outside the United States, under a business associate agreement and the other HIPAA requirements. It adds that the risks vary by location and must be considered in the risk analysis.
Is the HIPAA Security Rule changing?
HHS proposed changes on 6 January 2025, and comments closed on 7 March 2025. As of 29 September 2026, the Federal Register lists only the proposed rule, and HHS's regulatory agenda targets final action for July 2027. Until a final rule is published, the current Security Rule applies.
Further
- Production AI systems · The service behind this guide: assistants and workflow agents built around who may see what, what gets logged and where a human signs off.
- AI governance implementation · Governance built as controls: identity, verifier gates, evaluation in CI and an audit trail, designed in during the platform build.
- Private LLM · Vendor API, private cloud or self-hosted: what each route publishes about training, access and retention.
- AI governance framework · Where the BAA inventory and the risk analysis sit as controls with an owner and evidence.
We build these systems for a living. See the engagement files for what that looks like in practice, or write to us if yours is the next one.
Last reviewed · 1AYM