The short answer (no, most are not)
If you take one sentence away from this page, take this one. Most AI chatbots on the market in 2026 are not HIPAA-compliant by default, and a vendor saying "we are HIPAA-compliant" without producing a signed Business Associate Agreement is not telling you what you think they are telling you. The compliant universe is narrow. It includes a small number of healthcare-specialist conversational AI vendors (Hyro, Conversa Health, MedRespond), enterprise model-layer products that sign BAAs at the platform tier (Microsoft Azure OpenAI Service, Amazon Bedrock with HIPAA-eligible configurations, OpenAI on the enterprise tier with a signed BAA, Anthropic via select platform partners), and a handful of healthcare-adjacent communication products such as Twilio's HIPAA-eligible services. Everything outside that universe should be assumed to be outside the HIPAA boundary until the vendor produces a written BAA and the configuration documentation that goes with it.
ChatRaj is in the second category. We do not sign BAAs and we do not hold HITRUST certification today. That means ChatRaj is appropriate for the marketing, FAQ, and informational surfaces of a healthcare website (clinic hours, services, locations, insurance accepted, public patient-education pages) and is not appropriate for any surface where protected health information could be entered or returned. We will say that throughout this page because saying it once is not enough when the consequence of a misread is a federal investigation.
What HIPAA actually requires
HIPAA is not a single rule. It is a stack. The Health Insurance Portability and Accountability Act of 1996 was the enabling legislation. The operational compliance framework lives in three downstream rules administered by the HHS Office for Civil Rights: the Privacy Rule (what covered entities can do with PHI), the Security Rule (how electronic PHI must be protected technically and administratively), and the Breach Notification Rule (what happens when something goes wrong). For an AI chatbot deployment the Security Rule does most of the heavy lifting.
The Security Rule has been substantially the same since 2003, with a 2013 update under the HITECH Act. In January 2025 HHS published a Notice of Proposed Rulemaking that would modernize the Security Rule for the first time in over a decade, with a preliminary final-rule target in 2026. The proposed changes matter for chatbot buyers because they harden requirements that were previously labelled "addressable" (read: optional with documentation) into mandatory, auditable controls. The proposal explicitly requires encryption at rest and in transit, multi-factor authentication, network segmentation, defined data-restoration timelines, and annual business-associate certification of compliance. If the proposed rule lands close to its current form, covered entities will have 180 days to comply and business associates an additional 60 days to update their agreements, for a 240-day total transition window.
Two definitional points worth nailing down. A covered entity is a healthcare provider that transmits health information electronically, a health plan, or a healthcare clearinghouse. A business associate is any person or organisation that performs a function on behalf of a covered entity that involves the use or disclosure of PHI. A chatbot vendor that processes PHI on your behalf is a business associate, full stop. The compliance question is not whether the vendor calls itself "HIPAA-compliant"; the question is whether the vendor will accept business-associate status in writing.
What a BAA actually does (and what it doesn't)
A Business Associate Agreement is the contractual mechanism by which a covered entity extends HIPAA obligations to a vendor. HHS publishes a sample BAA on its website and the required content is set out in 45 CFR 164.504(e). A compliant BAA must do at minimum the following: describe the permitted and required uses of PHI, prohibit uses or disclosures other than those permitted by the contract or required by law, require appropriate safeguards under the Security Rule, require breach reporting to the covered entity, require sub-contractors handling PHI to enter into their own BAAs (the cascade), and require return or destruction of PHI at the end of the relationship.
What a BAA does is transfer specific HIPAA obligations and a corresponding share of liability to the business associate. Once a BAA is signed, the business associate is directly liable for HIPAA violations under the HITECH Act and can be the subject of OCR enforcement in its own right. That is real liability, which is why some vendors will not sign one.
What a BAA does not do is make the underlying product magically compliant. A signed BAA combined with a vendor that does not actually meet the Security Rule controls is a paper compliance posture that will not survive an OCR audit. Conversely, a vendor with excellent security but no BAA is not a viable choice for PHI work, because without the contractual cascade the covered entity cannot demonstrate that the chain of custody is HIPAA-governed. You need both: the paper and the controls.
The sub-processor cascade matters more than most buyers realize. If your chatbot vendor uses a model API (OpenAI, Anthropic, Google), that model provider is a sub-processor handling PHI on the vendor's behalf, and the vendor must have its own BAA with the model provider. If the vendor cannot tell you which model is processing the conversation and cannot produce its BAA with that model provider, your chain is broken at the model layer and you cannot claim coverage. Always ask the question.
The PHI vs PII distinction
People conflate PHI and PII constantly and the conflation drives bad procurement. Personally identifiable information (PII) is a broad term covering any data that can identify an individual: name, email, phone number, postal address, IP address in some interpretations, and so on. PII is governed by a patchwork of state privacy laws in the United States and by frameworks like GDPR abroad.
Protected health information (PHI) is narrower and HIPAA-specific. PHI is the intersection of two things: information that relates to an individual's past, present, or future health, healthcare, or payment for healthcare, and information that contains one or more of the 18 specific identifiers listed at 45 CFR 164.514(b)(2)(i). Those 18 identifiers include name, geographic subdivisions smaller than a state, dates directly related to the individual, telephone numbers, fax numbers, email addresses, social security numbers, medical record numbers, health plan beneficiary numbers, account numbers, certificate or licence numbers, vehicle identifiers, device identifiers, web URLs, IP addresses, biometric identifiers, full-face photos, and any other unique identifying number or code.
The practical consequence is that a chatbot answering "what are your office hours" is not handling PHI. A chatbot answering "I had a migraine yesterday, what should I take" combined with a logged-in user identity becomes PHI. The line moves with what the conversation contains, not with the page the chatbot is embedded on. That is why public marketing pages are the safe zone and patient portals are not.
The 5 HIPAA pillars for an AI chatbot
Boil the Security Rule down to what a chatbot deployment must actually have, and you get five pillars. Skip any one of them and your compliance posture is incomplete regardless of what the vendor told you in the sales call.
Pillar 1: encryption (at rest, in transit)
Encryption at rest means PHI stored in databases, vector indexes, conversation logs, and backups is encrypted using a current standard (AES-256 is the practical baseline). Encryption in transit means PHI flowing between the visitor's browser, the chatbot widget, the vendor's API, the model provider's API, and any sub-processor uses TLS 1.2 or above with strong cipher suites. The 2025 NPRM elevates encryption from "addressable" to mandatory; treat it as required regardless of where the rule lands.
Concrete questions to ask your vendor: what algorithm encrypts data at rest, where the keys are managed (customer-managed keys via KMS is the gold standard), whether the vector embeddings of conversations are encrypted, and whether the model-provider API call uses TLS with certificate pinning or equivalent. "We use industry-standard encryption" is a vendor answer that means nothing; the answer you want is specific.
Pillar 2: access controls + audit logs
Access controls under 45 CFR 164.312(a) require unique user identification, automatic logoff, and encryption-decryption controls. Audit controls under 164.312(b) require hardware, software, and procedural mechanisms that record and examine activity in information systems containing PHI. For a chatbot, that means every conversation involving PHI must be attributable to a specific user account, every administrative access to logs must be recorded, and the audit trail must be tamper-evident and retained.
Concrete questions: what is the retention period for audit logs (six years is the HIPAA documentation standard), who can access conversation transcripts on the vendor side, is multi-factor authentication enforced on administrator accounts (the 2025 NPRM makes MFA mandatory), and can the covered entity pull a complete audit log on demand. If the answer to the last question is no, you cannot complete your own internal audits.
Pillar 3: incident response (breach within 60 days notice)
The Breach Notification Rule under 45 CFR 164.404 requires covered entities to notify affected individuals of a breach of unsecured PHI without unreasonable delay and in no case later than 60 calendar days after discovery. Business associates are required to notify the covered entity of a breach without unreasonable delay and no later than 60 days after discovery, under 45 CFR 164.410. For breaches affecting 500 or more individuals, HHS must also be notified within the same 60-day window and the media must be notified for the relevant state or jurisdiction.
For a chatbot vendor, this translates to a contractual breach-notification SLA that gives the covered entity enough time to meet its own 60-day deadline. Best practice in the BAA is a vendor notification SLA of 24 to 72 hours from confirmed breach. Anything that uses up most of the 60 days on the vendor side leaves the covered entity scrambling to notify patients in days. Ask for the SLA in writing.
Pillar 4: minimum-necessary disclosure
The minimum-necessary standard under 45 CFR 164.502(b) requires covered entities and business associates to make reasonable efforts to limit PHI use or disclosure to the minimum necessary to accomplish the intended purpose. For an AI chatbot this is the rule most teams underweight. If the chatbot collects more information than it strictly needs to answer the question (asking for full date of birth when month and year would do, asking for full medical history when the question is about scheduling), the deployment fails the minimum-necessary test even if every other control is in place.
Design implications: chatbots handling PHI should be scoped narrowly, should refuse to collect identifiers they do not need, and should not log raw inputs verbatim where redaction or hashing is feasible. Some vendors offer PHI redaction layers that strip identifiers before the conversation hits the model API; that is a legitimate way to satisfy minimum-necessary at the architecture level and worth asking about.
Pillar 5: signed BAA with vendor (and sub-processors)
Pillar five is the legal cascade described above. The covered entity signs a BAA with the chatbot vendor. The chatbot vendor signs a BAA with the model provider. The model provider's sub-processors (cloud hosting, observability, billing) that touch PHI sign BAAs with the model provider. The chain has to be complete or the deployment is not covered.
The practical evidence package you want before launch is: your countersigned BAA with the vendor, the vendor's BAA with the model provider (you may not get the document itself but you should get written attestation that it exists and what it covers), a current sub-processor list with PHI-handling sub-processors flagged, and a written attestation from the vendor that no sub-processor outside the BAA chain receives PHI. Without that evidence, you cannot defend the deployment to OCR.
Vendors that offer BAAs in 2026
The list of AI chatbot and AI platform vendors that will sign a HIPAA BAA is meaningfully shorter than the list that markets to healthcare. Public information as of May 2026; verify on the vendor's current trust page before contracting.
Hyro is a healthcare-specialist conversational AI vendor founded in 2018. The platform is used by Baptist Health, Intermountain, and Mercy, integrates with Epic and Cerner, signs BAAs as standard, holds SOC 2 Type II, and publishes HITRUST certification. Hyro is the closest thing to a default answer for hospital-scale conversational AI on PHI.
Conversa Health focuses on automated patient outreach (post-discharge, chronic care, screening) and operates as a covered-entity-facing vendor with BAA coverage. The product is narrower than a general chatbot but the compliance posture is mature.
MedRespond offers HIPAA-eligible conversational tools for patient engagement and signs BAAs at the contract tier.
Microsoft Azure OpenAI Service is HIPAA-eligible and the BAA is included by default in the standard Microsoft Online Services Data Protection Addendum for eligible licensing agreements (Enterprise Agreement, Cloud Solution Provider). This is the practical path for teams that want to build their own healthcare chatbot on a GPT-class model with a clean BAA chain.
Amazon Bedrock offers HIPAA-eligible configurations under the AWS Healthcare BAA, covering Anthropic Claude, Meta Llama, and other hosted models when deployed with the required logging, key-management, and regional-isolation settings.
OpenAI signs BAAs on the enterprise tier (ChatGPT Enterprise and the API at scale). The BAA covers specific endpoints and configurations; verify the scope.
Anthropic offers BAA coverage for Claude through select platform partners (notably AWS Bedrock and Google Cloud Vertex AI) and at higher enterprise tiers; the BAA scope is more limited than Microsoft's or AWS's broad healthcare coverage.
Twilio offers HIPAA-eligible communications products (Programmable Voice, SMS, Conversations) under a signed BAA for healthcare customers, relevant if your chatbot extends into SMS or voice channels.
This is not an endorsement list. It is the universe of plausible answers. Specific suitability for your use case requires diligence that this page cannot do for you.
What ChatRaj is and isn't appropriate for
We will be specific. ChatRaj is appropriate for the public, non-PHI surfaces of a healthcare website: marketing pages, services pages, insurance-accepted pages, location and hours, public patient-education content, public FAQ, lead capture that does not request health information, and similar surfaces where the conversation does not depend on identifying the visitor as a patient. We are a strong fit for clinic and medspa marketing sites where the chatbot's job is to answer "do you take BlueCross" and "what are your hours" rather than "I have a rash, what should I do."
ChatRaj is not appropriate for any surface where PHI could be entered or returned. That includes patient portals, symptom triage flows, prescription-refill workflows, appointment-scheduling flows that link to a specific patient identity, post-discharge follow-up, any context where a logged-in patient identity is connected to health information, and anything else that would put PHI inside the chatbot's input or output. ChatRaj does not sign BAAs in 2026. For those workloads, choose a vendor that does.
If you need both a public marketing chatbot and a PHI workflow chatbot, the defensible architecture is a split: ChatRaj on the public site, a BAA-covered vendor (Hyro, Conversa Health, a custom build on Azure OpenAI Service or Amazon Bedrock) on the patient-portal side, with clear separation between the two and no shared data store.
Steps to verify a vendor's HIPAA claim
Vendor marketing pages frequently use compliance language imprecisely. "HIPAA-compliant," "HIPAA-aligned," "built with HIPAA in mind," and "HIPAA-ready" are not the same statement and several of them mean essentially nothing. The verification checklist below is the procurement diligence that turns a marketing claim into something you can defend.
First, ask for the BAA template. Not a redacted summary, the actual template. Read it. Confirm it covers the 45 CFR 164.504(e) required elements, names the specific product (not a generic master agreement), and includes a breach-notification SLA you can live with.
Second, ask about sub-processors and the BAA cascade. Get the current sub-processor list. For each sub-processor that may handle PHI (especially the model provider), confirm in writing that the vendor has its own BAA with that sub-processor. If the chatbot uses OpenAI, the vendor must have a BAA with OpenAI; same for Anthropic, Google, or AWS Bedrock.
Third, ask for security attestations. SOC 2 Type II is the practical floor; HITRUST CSF is the healthcare-specific gold standard and is what large health systems will expect. ISO 27001 is helpful but is not a HIPAA-specific framework. Get current reports under NDA.
Fourth, ask for OCR enforcement history and breach history. OCR maintains a public breach portal ("the wall of shame") listing breaches affecting 500 or more individuals. Search the vendor and its parent company. Past breaches are not disqualifying on their own but the response, the corrective action plan, and what changed since are diligence-relevant.
Fifth, run a tabletop. Hand the vendor a hypothetical breach scenario and ask them to walk through their incident-response process step by step against the 60-day clock. The quality of the answer is a strong signal about whether the rest of the compliance posture is real or theatre.
Run that list, keep the evidence, and you have a defensible procurement file. Skip any item and you are buying on faith, which is the position OCR enforcement is designed to make uncomfortable.