HIPAA gets mentioned a lot in healthcare tech conversations, usually in the context of "we are compliant" appearing somewhere on a vendor's website without much explanation of what that actually means.
If you are a developer building a healthcare product, or a founder evaluating AI tools for a healthcare-adjacent business, the gap between "we mention HIPAA" and "we are genuinely HIPAA-compliant in the ways that matter for your use case" is worth understanding. This post is an attempt to close that gap for one specific use case: AI handling patient and customer conversations.
What HIPAA Actually Regulates in This Context
HIPAA protects what the regulation calls Protected Health Information, or PHI. PHI is any information that can identify a patient and relates to their health status, care, or payment for care. That definition is broader than most people assume.
A patient's name combined with an appointment date is PHI. A phone number tied to a medical query is PHI. A record of which department someone was trying to reach when they called your clinic is, depending on context, potentially PHI.
The implication for AI tools handling customer or patient conversations: if the AI is ingesting, storing, or processing any of this information, it is operating on PHI. The HHS Office for Civil Rights, which enforces HIPAA, makes clear that covered entities and their business associates must apply the same safeguards to AI systems as to any other data processor handling PHI.
The Business Associate Agreement Requirement
If you are a healthcare covered entity, which includes most healthcare providers, health plans, and healthcare clearinghouses, and you bring in a third-party AI tool that touches PHI, that vendor must sign a Business Associate Agreement, commonly called a BAA, before you can legally use their tool with real patient data.
A BAA is a specific contract that commits the vendor to handling PHI in accordance with HIPAA requirements. It establishes what data they can use, how they must protect it, what happens in the event of a breach, and how long they retain data.
This is not a formality. If a vendor is unwilling or unable to sign a BAA, you cannot use their tool in a context where it will process PHI, full stop. Any vendor claiming HIPAA compliance without offering a BAA is either confused about what HIPAA compliance means in a B2B context, or hoping you are.
Where AI Conversation Tools Create Real Risk
The risk surface for AI tools in healthcare customer conversations is larger than it looks at first.
At intake. A patient calls to book an appointment and mentions a symptom. That mention is PHI the moment it is transcribed or stored.
During qualification. An AI sales agent asking qualifying questions before routing to a human might ask "What brings you in today?" The answer is PHI.
In follow-up messages. An automated reminder that references a specific appointment type or department is, in combination with a patient identifier, potentially PHI.
In CRM logging. If the AI logs conversation summaries to your CRM with any reference to a patient's reason for contact, that log entry contains PHI.
Each of these touchpoints needs to be covered by appropriate technical and administrative safeguards, documented in a BAA, and auditable if OCR ever investigates.
What Technical Compliance Actually Looks Like
HIPAA does not prescribe specific technologies. It describes requirements, and vendors must demonstrate they meet them. For AI conversation tools specifically, here is what meaningful compliance usually involves:
Encryption in transit and at rest. All conversation data must be encrypted when it moves between systems and when it is stored.
Access controls and audit logging. The system must be able to show who accessed what data and when. This matters if there is ever a breach investigation.
Data minimization. The AI should only collect and retain what it actually needs. Conversation data should not be stored longer than necessary for the documented purpose.
Incident response procedures. The vendor must have a documented process for notifying you in the event of a breach, within the 60-day window HIPAA requires for breach notification.
Staff training and policies. The vendor's internal team needs documented HIPAA training. This is often skipped by smaller AI vendors who have not been through a real compliance review.
How Different Tools Handle This
A few AI conversation platforms are worth looking at through this lens, because they approach it differently.
Nuance Communications (now part of Microsoft) has built HIPAA compliance into its healthcare AI products from the ground up, with BAAs standard in enterprise contracts and deep integration with clinical workflows. The trade-off is cost and complexity: it is built for large health systems, not small clinics.
Twilio offers HIPAA-eligible configurations for its communications APIs, with BAAs available. Developers building on Twilio can implement compliant voice and messaging, but the compliance burden shifts significantly to the builder.
Keum positions its ai customer support tools for B2B service businesses including healthcare-adjacent ones. Their AI Sales Concierge (keum.ai/ai-sales-concierge/) handles inbound qualification and appointment booking. If you are evaluating Keum for a healthcare context, the right question to ask is specifically about their BAA availability and the technical safeguards in their data processing pipeline. That due diligence conversation is the correct next step, not just checking a compliance badge on their website.
The pattern across all of these is the same: compliance is a process and a set of documented agreements, not a feature you turn on.
The Practical Checklist for Evaluating AI Tools in Healthcare
If you are assessing an AI conversation tool for a healthcare business, here is what I would actually verify before signing anything:
Will they sign a BAA? If the answer is no, or "we do not usually need to do that," that tells you everything you need to know.
Where is PHI stored, and for how long? Get this in writing, not just in a summary document.
What encryption standards do they use? AES-256 at rest and TLS 1.2 or higher in transit is the baseline expectation.
How do they handle a breach? Ask for a summary of their incident response plan and the timeline they commit to for notification.
Have they completed a HIPAA risk assessment? HIPAA requires covered entities and business associates to perform and document risk assessments. A vendor that cannot point to theirs has not done the work.
What data does the AI model train on? If the vendor uses customer conversation data to improve their model, you need to understand whether that includes PHI and whether it is permitted under the BAA.
The National Institute of Standards and Technology published guidance on AI risk management that is increasingly referenced alongside HIPAA requirements for healthcare AI systems. It is worth reading if you are responsible for this evaluation.
The Broader Point
HIPAA compliance for AI conversation tools is not primarily a technical problem. It is a documentation, process, and vendor relationship problem that requires technical controls underneath it.
The healthcare businesses getting this right are the ones treating compliance as a purchasing criterion from the start of a vendor evaluation, not an afterthought once a tool is already deployed. By the time you are asking the BAA question after signing a contract, you are already in a harder position.
If you are building a product in this space, the same logic applies in reverse: having your compliance documentation and BAA process sorted before sales conversations become serious is worth more than almost any feature you could ship instead.
Top comments (0)