Is Chat Data HIPAA compliant?

Chat Data offers HIPAA-eligible workspaces on the Standard plan or above. After you execute a Business Associate Agreement (BAA) with us, we enable HIPAA mode on your workspace, which turns on the protections described on this page. Meeting HIPAA obligations when you use Chat Data is a shared responsibility: we secure the platform, and you remain responsible for what you put into it and how your team uses it.

How do I enable HIPAA compliance for my workspace?

Contact our team to execute a Business Associate Agreement. Once the BAA is in effect, we enable HIPAA mode on your workspace. There is no self-serve toggle — enablement follows a signed BAA.

Does Chat Data delete my conversation data when HIPAA is enabled?

No. Enabling HIPAA does not delete anything. Your conversations and leads are retained in our encrypted, access-controlled application database, and uploaded files and voice recordings are retained in encrypted cloud object storage under our cloud provider BAA. What changes is who can reach that data and what is recorded about it: dashboard access is limited to the workspace members you have granted chat-log permission, those members must complete two-factor authentication to sign in, and reads of conversation and lead content are recorded with the reader, the records and the time.

Are uploaded files and voice recordings protected?

Yes. Images, documents, and audio are retained intact in encrypted, access-controlled Azure Blob Storage under our Microsoft Azure BAA, reachable only through short-lived, server-signed links. Access by your team is permission-checked and recorded in the same way as reading a transcript. A visitor opening a file in their own conversation is not workforce access and is not recorded as such.

HIPAA Compliance

Chat Data offers HIPAA-eligible workspaces for healthcare and other regulated use cases. Meeting your HIPAA obligations when you use Chat Data is a shared responsibility: we secure the platform and apply the technical controls below, and you remain responsible for the data you put into it, how your team accesses it, and which features you choose to use.

Eligibility and Enablement

HIPAA mode is available on the Standard plan or above, and it begins with a signed agreement — not a self-serve switch.

Execute a Business Associate Agreement (BAA). Contact our team at [email protected] (or through our HIPAA chatbot page) to put a BAA in place.
We enable HIPAA mode on your workspace. Once the BAA is in effect, our team enables HIPAA mode on your workspace. From that point on, the protections below apply automatically to every chatbot in the workspace.

HIPAA is a shared responsibility

Enabling HIPAA mode applies our technical controls, but it does not, on its own, make your use case compliant. You are still responsible for the content you ingest, who you grant access to, and how you use PHI with each feature. See Your Responsibilities below.

What HIPAA Mode Does

HIPAA mode changes who can reach your data and what is recorded about that access — not how long it is kept. Your data is retained; access to it is limited and documented.

Your data is retained, not deleted

Enabling HIPAA mode does not delete or overwrite anything. Conversations and leads remain intact in our encrypted, access-controlled application database, and uploaded files, voice recordings, and internal diagnostic data remain intact in Azure Blob Storage under our Microsoft Azure BAA. These are two distinct stores under distinct agreements — see Protected storage below.

This is deliberate. HIPAA does not require a business associate to destroy PHI on a rolling schedule — it requires that PHI be safeguarded, that access be limited to what is necessary, and that access be recorded. Your records also stay available for your own obligations, such as responding to a patient's request for their information.

Deletion is still available when you want it

If you do want data removed on a schedule, that is controlled separately by your chatbot's conversation and lead auto-deletion settings and by your plan's retention policy — independently of HIPAA mode.

Access is limited to the people you authorise

On a HIPAA workspace, conversation and lead content is reachable through the dashboard only by workspace members you have granted chat-log permission for that agent — plus any delegated access you set up yourself: API keys, sub-user accounts, and SSO sessions all read the same data on your behalf. Those paths are recorded like any other (see below), but they are yours to issue and revoke.

Two-factor authentication is required for workspace members. A member of a HIPAA workspace must complete 2FA enrolment before the dashboard will load. Delegated sessions — sub-users and chatbot SSO — authenticate through the credential you issued them and are not covered by this enrolment step, so their security is part of how you configure that access.
Permission decides access. We do not add a separate restriction on top of the chat-log permission you assign, because you decide who needs to see patient content when you assign roles.

Access control, not de-identification

The content your team sees is the content your visitors sent. Chat Data does not de-identify or anonymise conversation records, and you should not treat anything in the dashboard as though identifiers have been removed. What HIPAA mode provides is the access control, authentication and access recording described on this page — the safeguards HIPAA actually calls for — not a transformation of your data.

Access is recorded

Reading conversation or lead content through the dashboard on a HIPAA workspace records an access entry identifying who read it, which records they read, and when. The reader is attributed whether they are a workspace member, a sub-user, or an SSO session. The entry itself contains no message content and no directly identifying values.

These are the dashboard paths it covers:

Opening a conversation transcript
Listing or searching chat logs
Viewing lead detail
Exporting conversations
Opening diagnostic data for a message

Attachments and voice recordings are reached through the transcript that references them, so the recorded event is the read of that conversation. The file fetch itself is a short-lived signed link, not a separately recorded action.

Access recording today

Access entries are written to our internal logging pipeline, and recording is best-effort: it runs alongside the read rather than gating it, so a logging failure means the read still succeeds without an entry. The public REST API is not covered. Conversations and leads read with a workspace or chatbot API key do not currently produce an access entry — a key is an integration you build and operate, so treat your own logs as the record for that path, and issue keys accordingly. A workspace-facing access log you can review and export is in development; until it ships, we do not represent this as a complete or retrievable audit trail.

Email notifications keep working, on a covered transport

Notification email is not turned off on a HIPAA workspace, and its content is not withheld. Conversation notifications, lead notifications and digests, offline-message alerts, and live-chat escalation emails are all sent, carrying the same content they would on any other workspace.

What changes is the email provider. Chat Data sends transactional mail through SendGrid; a HIPAA workspace's conversation mail is routed instead through Amazon SES, a HIPAA-eligible service covered by our AWS Business Associate Addendum. SendGrid does not offer a BAA, which is why HIPAA workspaces do not use it for conversation content. There is deliberately no fallback between the two: if SES cannot deliver, the message is simply not sent rather than handed to an uncovered provider.

We are migrating all email to SES

Routing HIPAA workspaces through Amazon SES is the first step of a broader move: our long-term goal is to send all Chat Data email through SES rather than SendGrid. Today only HIPAA workspaces — and newly registered white-label sender domains, which are verified in SES — take that path; everything else still goes through SendGrid while the migration proceeds. This is an infrastructure change, not a change in what your notifications contain.

SMS notifications are sent without identifying details

SMS has no BAA-covered equivalent, so live-chat escalation and offline-lead text messages are still sent, but the lead's identity is removed from the body — no name, no email address, no phone number. The message tells your team a visitor is waiting and links to the dashboard, where the full context sits behind permission, two-factor authentication, and access recording.

Delivered messages leave our controls

Once a notification reaches an inbox or a handset, its content is outside every control described on this page. Choosing who receives conversation notifications, and how those mailboxes are secured, remains your decision as the covered entity.

Analytics

For HIPAA workspaces, the raw end-user message previews that our internal product-analytics events normally carry are suppressed, so those events do not include raw user text.

Storage and AI Providers

Protected storage

Uploaded files, images, and voice recordings — along with internal diagnostic data — are stored in Azure Blob Storage, encrypted at rest and access-controlled, under our Microsoft Azure Business Associate Agreement, and reachable only through short-lived, server-signed URLs.

Conversation and lead documents are a separate store: they live in our application database, protected by its own encryption at rest, network isolation and access controls. The two are worth keeping distinct — a control that applies to one does not automatically apply to the other, and the Azure BAA covers the object storage, not the database.

These objects are protected by storage-level controls and reachable only through short-lived, server-signed links issued to a member who already has permission to read the conversation that references them. The recorded event is that conversation read.

A visitor opening a file they themselves sent or received in their own conversation is not workforce access, and is deliberately not recorded as such — the audit requirement is about your team's access to PHI, not a person's access to their own conversation.

AI providers — restricted to BAA-covered models

On a HIPAA workspace, agents are restricted to BAA-covered AI providers — OpenAI and Anthropic. Models from providers we do not have a BAA with (for example Google Gemini or DeepSeek) are blocked at configuration time: you cannot select one when saving an agent, or pin one on a workflow AI node. This keeps prompts and conversations within provider agreements suited to PHI. See our Anthropic BAA overview for more.

Agents configured before HIPAA was enabled keep running

An agent that was already on a non-BAA model when HIPAA was switched on is not interrupted at chat time. We deliberately do not break a live agent mid-conversation — instead we email your workspace owners (and our compliance address) once a day per agent, and the turn proceeds through that provider. Enabling HIPAA does not retroactively stop PHI from reaching a model you had already selected. Audit your existing agents after activation and switch them to a gpt-* or claude-* model; the same applies to the items below.

Our pre-built medical chat models are managed by Chat Data and remain available on HIPAA workspaces. Like every other agent, they retain conversation history by default — turn off Store Conversations in the agent's privacy settings if you do not want transcripts kept. If you prefer to hold conversation data entirely in your own systems, see Save Chat History In Your Own Storage.

Custom backends — allowed, but your responsibility

A custom model routes conversation content to a backend URL you configure, which is outside Chat Data's OpenAI/Anthropic BAA boundary. This is allowed on a HIPAA workspace because it is your own infrastructure — but you are responsible for ensuring that backend is HIPAA compliant and covered by an appropriate Business Associate Agreement. When you configure a custom backend on a HIPAA workspace, we surface this reminder.

Generative UI responses are not available

The UI-based response format (rich, generated interface elements on the web widget) renders through Thesys, a provider outside the OpenAI/Anthropic BAA boundary. Because it would send conversation and knowledge-base content to that provider, it is not available on a HIPAA workspace — the option is disabled in the agent settings and saving an agent with it is rejected. An agent left on it before HIPAA was enabled is not stopped at chat time: as with models, the response still renders through Thesys while we warn your workspace owners daily, so this is one to audit and change yourself. HIPAA agents use the standard text-based response format (which routes only to OpenAI/Anthropic). This applies to the equivalent Dynamic UI Composer workflow node as well.

Prebuilt app actions are not available

AI actions come in two forms, and HIPAA workspaces treat them differently:

Prebuilt app actions (the one-click catalog — Gmail, Slack, Notion, Salesforce and the rest) execute through Composio, an agent tool-calling platform. Composio holds SOC 2 Type 2 and ISO 27001:2022 certifications but does not offer a HIPAA Business Associate Agreement, and a SOC 2 report is not a substitute for one. Because the tool arguments your agent derives from a conversation — and the results that come back — pass through Composio, prebuilt actions are not available on a HIPAA workspace: connecting one is refused, saving an agent with one is rejected, and an action configured before HIPAA was enabled keeps running while we attempt to notify your workspace owners, so you can remove it deliberately rather than have a live agent break. That notice is best-effort — treat auditing your existing actions after activation as your step, not ours.
Custom MCP servers connect directly from Chat Data to a server URL you control, with no third party in between. These remain available, on the same terms as a custom backend: the server is your infrastructure, so you are responsible for its HIPAA compliance and for any Business Associate Agreement it requires. We surface that reminder when you configure one.

If you need a prebuilt integration's functionality on a HIPAA workspace, connect that app as a custom MCP server you host.

Customised voice — allowed, but your responsibility

If an agent uses a customised voice, its generated replies are streamed to ElevenLabs for synthesis using your own API key. Those replies can contain PHI, and ElevenLabs sits outside Chat Data's OpenAI/Anthropic BAA boundary. This is allowed rather than blocked, on the same terms as a custom backend: you are responsible for your Business Associate Agreement with that provider. Turn the customised voice off if PHI must not reach it. We attempt a daily reminder to your workspace owners when an agent on a HIPAA workspace has it configured, but that notice is best-effort.

Channels and integrations

A deployment channel carries conversation content, so HIPAA workspaces restrict which channels can be connected:

Website widget, iframe, and API — conversation content stays within Chat Data's own infrastructure and the AI providers listed above; always available.
Blocked messaging channels — WhatsApp, WhatsApp Web, Messenger, Instagram, Telegram, Discord, and LINE relay conversation content to providers that do not offer a Business Associate Agreement, so they cannot be connected to a HIPAA workspace. Any of these that were connected before HIPAA was enabled are disconnected when you turn it on.
Allowed only with your own BAA — Slack and Zendesk can be HIPAA-eligible, but only if you have a Business Associate Agreement in place directly with that provider. You may connect them, but you are responsible for that BAA and for keeping PHI within it. When you connect one, we surface this reminder and ask you to confirm.
Commerce and payment integrations — Shopify, Stripe, and similar integrations do not carry conversation content and are unaffected.

Your Responsibilities

The responsibility is shared. On your side of the line:

Keep PHI out of your knowledge base. Do not upload PHI or PII into your training sources — you are responsible for the content you ingest into your agent's knowledge base.
Grant access deliberately. Anyone you give chat-log access to can read conversation content in full. Assign roles according to who genuinely needs to see patient content; the access record documents that access, but it does not restrict it for you.
Treat API keys as credentials. A key reads your workspace's data through your integration. Issue them narrowly, store them securely, and rotate them when someone leaves.
Maintain your own BAA for conditionally-allowed channels. We restrict models and block no-BAA channels automatically, but Slack and Zendesk are allowed only under a Business Associate Agreement you sign directly with that provider.
Own your outbound destinations. Data you route off-platform — for example webhook payloads — leaves Chat Data to destinations you control, and its handling and retention are your responsibility.
Keep PHI out of workflow emails you compose. The workflow builder's Send Email node sends whatever text and variables you configure, to whatever recipients you choose. Unlike our own notification templates, it has no fixed set of fields we can protect, so it is not restricted on a HIPAA workspace — keeping PHI out of it is your responsibility, and the builder reminds you of this where you configure the node.
Manage contact records responsibly. You decide what to store on leads and custom attributes. Contact identifiers on a lead remain visible to your team by design.

What HIPAA mode means here

Enabling HIPAA mode reflects the signed BAA plus the technical controls on this page. It is not a standalone certification of your use case — compliance depends on how you configure your agents, which features you enable, who you grant access to, and how your team handles PHI.

Using Medical Chat Models — pre-built medical models that do not retain chat history.
Save Chat History In Your Own Storage — keep conversations in your own HIPAA-controlled storage.
IP Blocklist and Allowlist Security — restrict who can reach your chatbot.