If an AI vendor will not sign a Business Associate Agreement, it cannot legally touch your patients' protected health information. That single fact eliminates most of the AI support market before you compare a single feature.
A Business Associate Agreement (BAA) is a HIPAA-required contract that lets a vendor handle protected health information (PHI) on behalf of a covered entity. For AI customer support in healthcare, a signed BAA is the legal precondition for the AI agent to read a member's claim, look up a prescription, or discuss an appointment. Without it, the deployment is a violation the day it goes live, regardless of how good the model is.
A BAA is mandatory under the HIPAA Privacy Rule whenever a vendor creates, receives, maintains, or transmits PHI for you (HHS sample BAA provisions).
The BAA flows down: your AI vendor's subprocessors (the LLM providers, hosting, telephony) must also be covered, or the chain breaks.
HIPAA requires administrative, physical, and technical safeguards, breach notification terms, and the minimum-necessary standard, not just a signature on a contract.
Civil penalties run up to roughly $2.1 million per violation category per year under the HHS 2025 inflation-adjusted tiers, before any state action.
Most general-purpose AI support tools either refuse to sign a BAA or sign one that quietly excludes the model layer where PHI actually flows.
Last updated: June 2026
Healthcare support has a failure mode that e-commerce does not. A wrong answer about a return policy costs a refund. A wrong answer about a member's coverage, or a stray line of PHI in a log a subprocessor can read, costs an Office for Civil Rights investigation and a breach notification to every affected patient. The question for a healthcare or healthtech buyer is not whether an AI agent can resolve tickets. It is whether the vendor can stand behind the legal and security posture that lets it touch PHI at all. This guide explains what a BAA is, what HIPAA actually requires of an AI vendor beyond the signature, the questions that separate a compliant vendor from a hopeful one, and how Lorikeet meets these requirements. We sell software that supports your HIPAA obligations. We do not, and cannot, make you compliant on our own, and any vendor that claims otherwise is the first one to cut.
What Is a BAA and Why Does AI Support Handling PHI Need One?
A Business Associate Agreement is a contract required by the HIPAA Privacy and Security Rules between a covered entity (a health plan, provider, or clearinghouse) and any business associate that handles PHI on its behalf. It defines what the associate may do with the data, requires safeguards, mandates breach notification, and makes the associate directly liable for HIPAA compliance. Under the HITECH Act, business associates are now directly accountable to regulators, not only contractually to the covered entity.
An AI customer support platform that reads a patient's record to answer a question, looks up a claim status, or transcribes a call about a diagnosis is creating, receiving, maintaining, or transmitting PHI. That is the exact trigger for a BAA. It does not matter that the AI is automated rather than a human reading the ticket. The data is PHI; the vendor is a business associate; the BAA is required.
Protected health information (PHI): Individually identifiable health information held or transmitted by a covered entity or business associate, in any form. For support, this includes names tied to a condition, member IDs, claim details, appointment data, and call recordings about care.
Covered entity vs. business associate: You (the health plan, provider, or healthtech acting on their behalf) are usually the covered entity or its associate. Your AI support vendor is a downstream business associate, and its own subprocessors are subcontractors who also need agreements in place.
The part buyers miss is the chain. An AI support vendor rarely processes PHI alone. It calls a large language model provider, runs on a cloud host, and may use a telephony or transcription service. Each of those touches PHI. HIPAA requires that a business associate obtain satisfactory assurances, in writing, from each subcontractor it passes PHI to. If your vendor signs a BAA with you but runs prompts through an LLM API that is not under a no-train, BAA-covered agreement, the chain is broken and the exposure is yours.
What HIPAA Actually Requires of an AI Support Vendor
A signed BAA is the entry ticket, not the finish line. The HIPAA Security Rule requires the vendor to implement and maintain real safeguards. Here is what a healthcare buyer should expect an AI support vendor to demonstrate, not just assert.
Administrative, Physical, and Technical Safeguards
The Security Rule groups safeguards into three categories. Administrative safeguards cover access management, workforce training, and a designated security official. Physical safeguards cover facility and device controls, which for a cloud vendor flow through to the hosting provider's attested controls. Technical safeguards cover access control, audit controls, integrity, and transmission security, including encryption of PHI in transit and at rest. A SOC 2 Type II report is the most common evidence that these controls exist and were tested over time, though SOC 2 is not the same as HIPAA and you should confirm the vendor maps its controls to the Security Rule.
Data Isolation and Segregation
In a multi-tenant SaaS platform, the risk is that one customer's PHI leaks into another customer's environment, into shared model training, or into shared logs. HIPAA does not prescribe a single architecture, but it does require that you can show PHI is protected against unauthorized access. Ask how customer data is isolated, whether your data ever trains a shared model, and where it physically resides. Data residency matters because some health plans and state laws require PHI to stay in a specific jurisdiction.
Minimum Necessary
The minimum-necessary standard requires that PHI use and disclosure be limited to what is reasonably needed for the task. For an AI agent, this is an architecture question. Does the agent pull a member's entire record into the prompt, or does it call a scoped tool that returns only the field it needs? An agent that loads everything to answer one question is processing more PHI than necessary and widening the blast radius of any failure. Least-privilege, scoped tool access is the design that supports this standard.
Breach Notification Terms
The BAA must define what counts as a breach, how fast the vendor notifies you, and who carries the notification cost. The HIPAA Breach Notification Rule sets an outer limit of 60 days for covered-entity notification to individuals, so your BAA should require the vendor to alert you well inside that window, typically within a defined number of days of discovery. Read this clause closely. A vendor that gives itself 60 days to tell you leaves you no time to meet your own obligation.
PII and PHI Redaction
Logs, transcripts, analytics, and debugging tools are where PHI quietly accumulates. A vendor should be able to redact or mask identifiers in the places humans and third parties can see them, while preserving the agent's ability to do its job. Ask specifically about call transcripts and log retention, because those are the records most likely to outlive the interaction and end up in a system you did not vet.
Audit Trails
HIPAA technical safeguards require audit controls: mechanisms that record and examine activity in systems containing PHI. For an AI agent, the useful standard is a replayable record of what the agent accessed, which tools it called, and what it disclosed, per interaction. This is what lets you answer an OCR inquiry or investigate an incident with evidence rather than a guess.
Where AI Support Vendors Quietly Fail HIPAA
Few vendors fail HIPAA loudly. The failures are quiet, structural, and easy to miss in a demo. These are the patterns that show up most often when a regulated buyer looks past the marketing page.
The BAA That Excludes the Model Layer
A vendor signs a BAA that covers its own application and storage, then routes your prompts (which contain PHI) to a third-party LLM API that is not under a BAA or no-train agreement. On paper you have a signed BAA. In practice, PHI is leaving the covered chain every time the agent thinks. This is the single most common gap, and it is invisible unless you ask which model providers are used and whether they are covered.
PHI That Survives in Logs and Transcripts
An interaction ends, but the PHI does not. It lives on in debug logs, analytics dashboards, call recordings, and transcripts, often in systems with broader access than the agent itself. If those records are not redacted and their retention is not defined in the BAA, you have created a long-tail exposure that an audit will find. Ask where transcripts go, who can read them, and for how long.
Over-Broad Context Windows
A vendor that loads a member's full record into every prompt to make the agent smarter is also processing far more PHI than any single task requires, in tension with the minimum-necessary standard. Smarter is not the same as compliant. The architecture that scales safely is one where the agent requests only the field it needs, when it needs it, through a scoped tool.
Retrofitted Chatbots Wearing a Compliance Badge
Many tools in this market began as FAQ chatbots and added compliance language later. The architecture that was fine for deflecting knowledge-base questions is not the same one you want reading PHI and taking actions on a member's account. A SOC 2 badge does not retroactively change how a system was designed to handle data. The useful question is whether the platform was built for regulated workflows or adapted to claim them.
Who Is the Covered Entity in a Healthtech Deployment?
Healthtech buyers sometimes assume HIPAA does not apply to them because they are not a hospital or insurer. That assumption is where exposure starts. If your platform handles PHI on behalf of a covered entity, such as a health plan, a provider group, or a pharmacy, you are a business associate, and the same rules flow to you. Your AI support vendor then becomes your subcontractor, and you owe the same flow-down obligations downstream that the covered entity owes to you.
This matters for the BAA chain. A digital health startup serving a health plan signs a BAA with that plan, and must in turn have a BAA with its AI support vendor, which must in turn cover its model providers and hosting. Every link has to hold. When buyers map this chain before procurement, the question of whether a vendor will sign a real BAA, covering its own subprocessors, stops being a formality and becomes the first filter. It is far cheaper to confirm the chain on a contract review than to reconstruct it during a breach investigation.
Questions to Ask an AI Support Vendor About HIPAA
Vendor demos are built to look compliant. The questions below are built to find the gap between a signature and a posture.
Will you sign a BAA, and does it cover the model layer, hosting, telephony, and every subprocessor that touches PHI, not just your application?
Do your LLM provider agreements include no-train terms and BAA coverage, and can you name the providers?
How is my data isolated from other customers, and does any of it ever train a shared model?
Where does PHI physically reside, and can you guarantee a specific data residency region?
How does the agent enforce minimum necessary: does it load full records into prompts, or call scoped tools that return only the needed field?
What is your breach notification window in the BAA, measured from discovery, and who pays for notification?
How is PHI redacted in logs, transcripts, and analytics, and what is your retention period for each?
Can you produce a per-interaction audit trail showing what the agent accessed and disclosed?
Can my security team review your SOC 2 Type II report and run a security review before go-live?
How Lorikeet Meets These Requirements
Lorikeet is an AI customer support platform built for complex and regulated businesses, including healthcare and healthtech. Roughly 80% of our customers are regulated companies, and we have passed security reviews with demanding institutions, including major US banks. Here is honestly where we stand against each requirement above, and where the boundary of our responsibility sits.
BAA-Ready and SOC 2
Lorikeet is BAA-ready for HIPAA and maintains SOC 2 compliance. We hold contractual no-train agreements with our LLM providers (OpenAI, Anthropic, and Google), which means PHI passed to the model layer is not used to train shared models. This is the part that breaks for most general-purpose tools, because a BAA on the application alone does not cover the model API where the data actually flows. We are clear about the boundary: signing a BAA supports your HIPAA obligations; it does not transfer them. You remain the covered entity or its associate, and compliance is shared.
Instance Isolation and Data Residency
Lorikeet offers data residency in the US, Australia, and the UK, so PHI can be kept in the jurisdiction your plan or regulator requires. Customer data is not used to train shared models. For a healthcare buyer, the practical takeaway is that your members' data stays in your region and your instance, rather than pooling into a shared training set.
Minimum Necessary by Design
Lorikeet agents act through least-privilege, scoped tools and webhooks rather than loading entire records into context. An agent answering a claim-status question calls a tool that returns the claim status, not the member's full history. This design supports the minimum-necessary standard at the architecture level, instead of relying on a policy that the model is asked to follow. PII redaction is part of how we handle data across logs and transcripts.
Defense in Depth and Audit Trails
Lorikeet's safety model runs in four layers: pre-launch adversarial simulations and red-teaming, inbound message checks, outbound guardrails, and 100% post-interaction QA through our Coach agent, which evaluates every resolution rather than a sample. Each interaction produces an audit trail you can replay to see what the agent accessed, which tools it called, and what it disclosed. For a regulator inquiry or an internal incident review, that record is the difference between evidence and a guess.
An Honest Limitation
Lorikeet is not a managed compliance service, and we do not hold a HIPAA certification, because no such certification exists from HHS. No vendor can be HIPAA-certified; vendors can only build to the rules and attest through frameworks like SOC 2. Configuring guardrails for your specific workflows, defining what the agent may and may not disclose, and validating it against your policies takes setup work with our forward-deployed team during onboarding. We make that fast, with a sandbox typically running in 20 to 30 minutes and a deployment operational in about a month, but it is real work that you and your compliance team own with us. A vendor that tells you it is plug-and-play compliant is selling you a risk you will find later.
Lorikeet's Take on HIPAA and AI Support
The healthcare AI support market splits cleanly into vendors that will sign a real BAA covering the full PHI chain and vendors that will not. Start your evaluation there, because it eliminates most of the field before you spend time on feature comparisons. Then move to the posture behind the signature: model-layer coverage, data isolation, minimum-necessary architecture, breach terms, redaction, and an audit trail you can replay. The vendors that survive that review are the ones whose behavior is provable, not the ones with the most confident compliance page.
Lorikeet is built for that review. We are BAA-ready, SOC 2 compliant, hold no-train agreements with our model providers, offer US, AU, and UK data residency, and produce a replayable audit trail for every interaction. We are also honest that compliance is shared and that setup is real work. If that is the bar your team uses, see how Lorikeet handles regulated support.
Key Takeaways
A signed BAA is the legal precondition for any AI support tool to touch PHI; a vendor that will not sign one is disqualified, not negotiable.
The BAA must flow down to the model layer, hosting, and telephony subprocessors, or the chain is broken and the exposure is yours.
HIPAA requires real safeguards beyond the signature: administrative, physical, and technical controls, breach notification terms, minimum necessary, and audit controls.
Minimum necessary is an architecture decision: scoped tools that return one field beat agents that load entire records into the prompt.
Lorikeet is BAA-ready and SOC 2 compliant, with no-train LLM agreements, US/AU/UK data residency, least-privilege tools, and per-interaction audit trails, while being clear that compliance is shared and setup is real work.
Conclusion
HIPAA does not ban AI customer support in healthcare. It sets a bar: a vendor must sign a BAA that covers the full chain where PHI flows, implement the safeguards the Security Rule requires, limit what the agent touches to the minimum necessary, notify you fast on a breach, and give you an audit trail you can stand behind. Most general-purpose AI tools fail that bar quietly, by signing a BAA that excludes the model layer or by running your data through an API with no no-train terms.
For healthcare and healthtech buyers, the right move is to run the BAA and posture questions first and let the feature comparison follow. Lorikeet is built to pass that review and honest about the line between what our software supports and what your team owns. Book a Lorikeet demo and bring your security and compliance leads, along with the workflows that scare them most.
