HIPAA Compliant Answering Service: What It Actually Takes

A HIPAA compliant answering service is one where a signed business associate agreement is in place, the service only handles the minimum patient information it needs, calls and transcripts are encrypted and access controlled, staff or systems touching that data are auditable, and there is a written breach notification path. That is the whole test. Everything else is detail underneath those five points.

Here is the short checklist, in the order it matters:

• A signed BAA between your practice and the answering service, executed before the first call is answered, not after.
• Encryption of call audio, transcripts and messages in transit and at rest, with the vendor able to say which standard and where the keys live.
• Named, role limited access. You should be able to ask who at the vendor can listen to a recording of your patients, and get a specific answer.
• A written retention and deletion policy for recordings and transcripts, with a stated default and a way to shorten it.
• A subcontractor list. Every downstream vendor that touches the audio, including transcription, storage and any AI model provider, must be under an equivalent agreement.
• Audit logs you can request, showing who accessed what and when.
• A breach notification clause with a deadline in days, not a promise to notify promptly.
• For an AI agent specifically: a written statement that your call data is not used to train anyone's model.

If a vendor clears all eight, the arrangement is defensible. If they cannot answer the last three without checking with someone, you are early in a sales process, not near a compliant deployment.

This page is written for the person actually making the decision: an owner, practice manager or operations lead at a clinic, dental office, therapy practice or medical group with 5 to 200 staff who is losing calls and now has to work out which answering service will not create a compliance problem. It is not legal advice, and the state law in this area is moving fast enough that anything you read, here included, should be checked against current statute before you rely on it.

HIPAA compliance is a property of an arrangement, not a product badge

No software is HIPAA compliant on its own. HIPAA regulates covered entities and their business associates, meaning organizations and the agreements between them, and it says almost nothing about products. A phone system, a transcription tool or an AI voice agent can be configured in a way that supports compliance or a way that destroys it, using the same code either way.

This matters commercially because most of the marketing in this category is written as though compliance were a sticker. Vendors put HIPAA compliant in an H1, add a shield icon, and leave the reader to assume something was certified. Nothing was. There is no federal HIPAA certification. The Department of Health and Human Services does not certify, approve or bless software, and its Office for Civil Rights has said as much repeatedly. Any organization claiming a HIPAA certification is describing a private audit firm's opinion, which may be useful evidence, but is not a government status.

So when you read that a service is HIPAA compliant, translate it into the only sentence that can actually be true: this vendor will sign a BAA and has built controls that make it possible for you to use them without breaking the rules. Whether you then break them is up to how you deploy it.

Three practical consequences follow, and they change how you buy.

• You can create a violation with compliant software. Turning on call recording, forwarding transcripts into a shared inbox, or letting the after hours message go to a personal cell phone will do it, regardless of what the vendor's badge says.
• You cannot outsource your obligation. The covered entity, meaning your practice, remains responsible. A BAA transfers duties to the vendor and gives you contractual recourse. It does not transfer your liability to your patients or to OCR.
• The question to ask a vendor is never are you HIPAA compliant. It is: will you sign our BAA unmodified, what is in your subcontractor list, and what happens to the audio after the call ends. Those three have real answers. The first question only ever produces a yes.

There is one narrow sense in which a product claim is meaningful. Some vendors are audited against SOC 2 Type II or ISO 27001, which are real, third party, and evidence of a functioning security program. Those are not HIPAA, they do not mention PHI, and they do not remove the need for a BAA. They are a signal that someone external looked at the controls. Treat them as supporting evidence and nothing more.

Who HIPAA applies to, and where an answering service sits

HIPAA applies to covered entities and to business associates who handle protected health information on their behalf. An answering service is almost always a business associate, because handling patient calls means creating, receiving, maintaining or transmitting PHI.

Covered entities are health plans, health care clearinghouses, and health care providers who transmit health information electronically in connection with a covered transaction, which in practice means almost every provider that bills insurance. If you are a medical practice, dental office, therapy group, urgent care, home health agency or hospital, assume you are a covered entity.

A business associate is a person or organization outside your workforce that performs a function on your behalf involving PHI. That covers the answering service, the transcription provider it uses, the cloud hosting underneath, and the AI voice platform if one is in the loop. HIPAA also requires business associates to bind their own subcontractors to equivalent terms, which is why the subcontractor question later on this page is not a technicality.

The conduit exception is worth understanding because vendors misuse it. It covers organizations that merely transport information, like a telecom carrier or a courier, with only transient access. A carrier that routes a call is typically a conduit. A voice platform that records the call, stores the audio, transcribes it and keeps a copy is not, and cannot claim the exception. If a vendor tells you they do not need a BAA because they are just a conduit, ask whether they store audio or transcripts. If the answer is yes, the exception does not apply.

What PHI a phone agent actually touches

A single inbound patient call routinely produces eight to twelve pieces of protected health information in the first ninety seconds. Name, date of birth, callback number, the name of your practice, the reason for calling, the appointment time, the provider's name, insurance details and often a medication or symptom the caller volunteers without being asked.

Most competitor content stays abstract here. It says an answering service handles PHI and moves on, which is exactly why people keep searching for a straight answer. So here is the concrete version, taken from what a real intake call contains.

Protected health information is individually identifiable health information held or transmitted by a covered entity or business associate. Two conditions have to be met: it identifies a person, or could reasonably be used to, and it relates to health, health care, or payment for health care. The trap on a phone line is that the second condition is met by context alone.

The name Sarah Klein is not PHI. The name Sarah Klein plus a callback number, captured by an oncology clinic's answering service, is PHI, because the fact that she called an oncology clinic is itself health information. This is the single most misunderstood point in the category. Your specialty makes ordinary contact details into PHI. A dermatology practice, a fertility clinic, a methadone program and a psychiatric practice all turn a phone number into a health fact simply by being the number that was dialed.

Notice how many of those rows end in a system that is not the answering service. That is the real pattern. PHI leaks sideways out of the call into a calendar, a shared inbox, a texting app, a spreadsheet a receptionist built to track callbacks. The answering service can be flawless and the arrangement can still fail three steps downstream.

The recording of the voice is itself an identifier

Voice recordings are identifiable. The HIPAA de-identification safe harbor lists biometric identifiers including voice prints among the 18 identifiers that must be removed for data to be considered de-identified. A recording of a patient describing symptoms cannot be de-identified by stripping the name, because the voice is still there.

This has a direct consequence for how you treat audio. Some vendors describe recordings as anonymized once the metadata is removed, or as safe to use for quality improvement because no name is attached. Neither claim survives the safe harbor list. Audio of a patient is PHI until it is destroyed. Treat it that way in retention, access control and any conversation about model training.

Minimum necessary, applied to a phone script

The minimum necessary standard means you only collect, use and disclose the least PHI required for the purpose, and it applies to the answering service just as it applies to your front desk. On a phone line this is a scripting decision, not a legal one.

Two examples of what that looks like in practice. If the service exists to book appointments, it needs a name, a callback number, a date of birth to match the chart, and a reason at the level of new patient consult or annual review. It does not need a symptom narrative. If the service exists to triage urgent calls, it does need the symptom narrative, and the script should be built so the narrative goes straight to a clinician rather than into a general message queue.

The single highest value change most practices can make to a phone script is to stop asking open ended clinical questions on calls that are purely administrative. Every additional field you collect is data you now have to protect, retain, and eventually delete.

The last row is worth dwelling on. A meaningful percentage of calls to a practice are not clinical at all. Hours, parking, whether you take a given insurance plan, where to park, how to reach the portal. Those calls need no PHI whatsoever, and an answering service or AI agent that handles them without collecting a name has removed a compliance surface entirely. Handling the easy calls anonymously is a compliance win as well as a cost win.

The business associate agreement, in detail

The business associate agreement is the contract that makes the whole arrangement lawful, and it is the one document that decides whether an answering service can legally take your patient calls. Without it, every call the vendor answers is an impermissible disclosure of PHI by your practice, from the first one.

That framing matters. People treat the BAA as paperwork that follows a purchase decision. It is closer to a license to operate. HIPAA permits a covered entity to disclose PHI to a business associate only if it has obtained satisfactory assurances, in the form of a written contract, that the associate will safeguard the information. No contract, no permission. The failure is yours, not just theirs.

What a BAA actually is

A BAA is a written agreement in which a vendor promises to use PHI only as your contract allows, to safeguard it, to report incidents to you, to bind its own subcontractors to equivalent terms, to make records available for compliance purposes, and to return or destroy PHI when the relationship ends.

The required elements are set out in the HIPAA Privacy Rule at 45 CFR 164.504(e), and the Security Rule adds obligations for electronic PHI at 45 CFR 164.314. HHS publishes sample business associate agreement provisions, and most vendor BAAs are a light edit of that sample. That is a good thing: it means you can read a BAA and immediately spot where a vendor has deviated from the standard text, because the standard text is public.

A BAA is not a certification, not a security assessment, and not a guarantee. It is an allocation of duties, plus a contractual remedy if those duties are breached. It does not mean anyone inspected the vendor. Since 2013 and the HIPAA Omnibus Rule, business associates are also directly liable to OCR for certain violations, which is why serious vendors take the document seriously and why a vendor that shrugs at it is telling you something.

What a good BAA contains

Read the BAA against this table before you sign. The middle column is what a defensible agreement says. The right column is the language that should stop the process.

The last row does not appear in the HHS sample provisions, because the sample predates the problem. Add it. A BAA drafted in 2015 and reused ever since is silent on model training, and silence in a contract with a technology vendor is not a prohibition. This is the single most important edit to make to a standard BAA in 2026.

The liability cap problem

Most vendor contracts cap total liability at the fees paid in the preceding twelve months, and for a small practice paying a few hundred dollars a month that cap is far below the cost of a real breach. Breach response costs money before anyone is fined: forensic investigation, individual notification by first class mail, a call center, credit monitoring, legal advice, and in many states an attorney general notification.

You will not get an uncapped agreement from most vendors, and you should not expect to. What you can often get, especially from smaller vendors who want the logo, is a carve out that puts breaches caused by the vendor's negligence outside the general cap, or raises the cap for that category specifically. Ask for it in writing during procurement, when you still have leverage. After go live you have none.

When a vendor refuses to sign

A vendor that will not sign a BAA cannot handle your patient calls. There is no workaround, no compensating control, and no volume of security features that substitutes. This is the shortest decision on the page.

You will hear four refusals, and each has a standard answer.

• We do not need one because we do not store PHI. Ask whether they store call audio, transcripts, message logs, caller ID records or CRM notes. If any answer is yes, they store PHI. If genuinely nothing is stored and nothing is transmitted, the conversation is worth continuing, but this is rare on a phone product.
• We are just a conduit. The conduit exception is narrow and covers transmission only, with transient access. A platform that records and retains is not a conduit.
• We are SOC 2 certified, so a BAA is unnecessary. SOC 2 is a different framework with different scope and does not create the contractual assurances HIPAA requires. It is supporting evidence, not a substitute.
• Our BAA is only available on the enterprise plan. This is common and it is a pricing decision, not a legal one. It is also a legitimate answer, as long as you buy the plan that includes it. What you cannot do is run patient calls on the cheaper tier and hope.

The watered down BAA, and how to spot it

A watered down BAA is more dangerous than no BAA, because it produces the paperwork that makes everyone stop asking questions. The document exists, it is filed, and nobody reads clause 9.

Four specific patterns to look for. First, a use clause that permits the vendor to use PHI for improving the services, which reads as harmless and can cover analytics, quality review and model training. Second, a de-identification right, which lets the vendor strip identifiers and then use the data freely, a move that is difficult to police and, for voice recordings, arguably impossible to perform correctly. Third, a subcontractor clause that permits subcontracting without any duty to name the subcontractors, which means you never learn that transcription happens at a fourth party. Fourth, a notification clause with no deadline, which pushes the timing risk onto you while your own 60 day clock runs.

Practical approach. Ask for a redline of the vendor BAA against the HHS sample provisions, or produce one yourself. Every deviation is either an operational necessity you can accept or a shift of risk you can push back on. Most vendors will accept edits to reporting deadlines and to a model training clause. Fewer will move on liability caps. Almost none will move on governing law. Knowing that ordering in advance saves a week of negotiation.

Click through BAAs and self service signup

A click through BAA accepted during signup is legally a contract, and it is also a contract you did not read and cannot change. Treat it as the floor, not the ceiling.

They are increasingly common with AI voice platforms, where the entire purchase can happen without a sales conversation. If you take that path, do three things: save a dated PDF of the exact version you accepted, because these documents change and the vendor keeps the pen; check whether the BAA applies to your plan tier, since several platforms scope it to specific plans; and check whether the BAA covers the model provider sitting behind the voice product, or only the platform itself. The third one is where most self service arrangements quietly fail.

Timing, filing and review

The BAA must be executed before any PHI reaches the vendor, which means before the first test call using real patient data. Sandbox testing with fabricated callers is fine. The moment a real patient's number is forwarded, the clock has already started.

Keep the executed copy where an auditor can find it in under a minute, along with the version of the vendor's security documentation you relied on. Review the set annually, and any time the vendor changes materially, for example when they add a new AI feature, change model providers, or get acquired. An acquisition is the most commonly missed trigger. The BAA usually survives, the data handling practices frequently do not.

Where the risk actually lives

The risk in a phone arrangement is not the call. It is everything the call leaves behind: the recording, the transcript, the message that got emailed, the CRM note, the backup, and the copies held by whoever the vendor subcontracted to. A call lasts two minutes. Its artifacts can live for seven years.

Every one of those artifacts has a default setting, and the defaults are almost never chosen with a medical practice in mind. They are chosen so that a sales team can review calls, a support agent can debug a complaint, and an engineer can reproduce a bug. Those are reasonable product decisions and terrible clinical ones.

Recordings and transcripts

Recording a patient call creates the single most sensitive artifact in the arrangement, and in most cases you do not need it. A recording captures the caller's voice, which is a biometric identifier, plus whatever they said before anyone could stop them, which is frequently more than the script asked for.

There are legitimate reasons to record: quality assurance on a new deployment, dispute resolution, and training a human team. There are also two lazy reasons that drive most recording: it was on by default, and someone might want it later. Before you keep recordings, write down what you would use them for and how long that use takes. If the answer is quality review in the first month, the retention period is measured in weeks, not years.

Transcripts deserve separate attention because people treat them as less sensitive than audio. They are not. A transcript is searchable, copyable, easy to paste into a support ticket, and just as identifying. In practice a transcript is riskier than a recording, because a recording requires deliberate effort to listen to and a transcript can be scanned by anyone with access in seconds.

Ask the vendor five specific questions about both. Where are they stored, geographically. Are they encrypted at rest and with whose keys. What is the default retention period, in days. Can you set a shorter one, and does the setting apply retroactively. Can you delete a specific call on request, and does that deletion propagate to backups, transcripts, analytics, and any copy held by a subcontractor.

Retention: pick a number and defend it

HIPAA does not set a retention period for call recordings, which is why this is a decision you have to make rather than look up. What HIPAA does require is a six year retention for HIPAA related documentation such as policies and BAAs, at 45 CFR 164.316(b)(2)(i). That is documentation, not patient records, and it is not a rule about call audio.

Medical record retention is set by state law and varies widely, commonly five to ten years for adults and longer for minors. Call recordings are usually not part of the designated record set, unless you make them so by treating them as clinical documentation. Which points to the practical rule: keep call recordings short and keep clinical content out of them, or accept that they may become records you must retain and produce.

A defensible pattern for most practices looks like this.

• Audio: 30 to 90 days, then automatic deletion. Long enough for a dispute, short enough that a breach exposes a bounded window.
• Transcripts: the same period as audio, deleted on the same schedule, not longer.
• Structured outcomes, meaning appointment booked, message taken, call routed: retained in your own systems under your own record retention policy, because that is where they belong.
• Anything clinically meaningful: written into the chart by a person and deleted from the phone system, rather than living in two places with two retention rules.

Whatever you pick, write it down, make the vendor configure it, and verify once that deletion actually happens. A retention policy nobody tested is a policy that exists only in a document.

Who at the vendor can listen to your patients

Someone at every vendor can listen to your calls, and the correct question is who, under what process, and whether it is logged. A vendor that claims nobody can access recordings is either running a zero knowledge architecture, which is rare and which they will be eager to explain in detail, or answering a question they did not understand.

What good looks like: access is role based, support staff cannot open call content without a ticket and an approval, engineers use a break glass process that generates an alert, all access is logged with a user identity and a timestamp, and you can request the log for your account. What bad looks like: an internal admin panel where any employee can search any account's calls, which is a very common architecture in early stage products and is exactly the thing to ask about before you sign.

Also ask where those people are. Offshore support and offshore transcription are both normal in this industry and neither is automatically a HIPAA problem, since HIPAA does not prohibit processing outside the United States. It does mean your PHI is subject to another country's legal process and that your enforcement options in a dispute get harder. Make it a deliberate decision rather than a discovery.

Subcontractors and downstream processors

Every answering service and every AI voice product is built on other people's infrastructure, and each of those layers is a subcontractor that must be under a BAA with your vendor on terms no less restrictive than yours. This is required by 45 CFR 164.502(e)(1)(ii) and 164.308(b)(2), and it is where the chain most often breaks.

A typical AI phone agent stack has four to six parties in it, and the practice signs a contract with exactly one of them.

Ask for the list by name. A vendor who cannot produce it in a day either does not know their own data flow or does not want to tell you. Both are answers. Also ask what happens when the list changes, since swapping a speech to text provider is a routine engineering decision that materially changes where your patients' voices go. The BAA should require notice, and ideally a right to object.

Whether your call data trains a model

Ask directly whether your call audio, transcripts or any data derived from them are used to train, fine tune or evaluate any machine learning model, and get the answer in the contract rather than in an email. This is the newest risk in the category and the least covered by existing content, which means most practices are buying without asking.

The reason it matters is not hypothetical. Training data can be memorized and can surface in outputs. More practically, once your patients' conversations are absorbed into a model or a training corpus, there is no meaningful deletion. You can delete a recording. You cannot un-train a model, and no vendor has a process for it. This makes training use the one data practice that is genuinely irreversible, which is why it deserves a contract clause of its own rather than a settings toggle.

Six questions, and the answers you want.

• Do you use customer audio or transcripts to train or fine tune models. Answer you want: no, and it is written in the BAA.
• Do your subcontractors, including the model provider, train on data sent through the API. Answer you want: no, under a zero retention or no training configuration, named in writing.
• Do you use call data to evaluate or benchmark models. Answer you want: no, or only on synthetic data. Evaluation is often excluded from a training promise and is a real gap.
• Does any human review calls to label or grade them. Answer you want: not without a specific agreement, and never for our account by default.
• If you de-identify our data, can you then use it freely. Answer you want: no. For voice this is the clause that quietly reopens everything the previous four closed.
• Is this a contractual commitment or a settings default you can change. Answer you want: contractual, surviving product changes.

If a vendor tells you the model provider does not train on API data, that is often true and it is still worth having in your own paperwork. The commitment you can enforce is the one in your contract, with the vendor you pay.

The Security Rule, applied to a phone line

The HIPAA Security Rule requires administrative, physical and technical safeguards for electronic PHI, and a phone arrangement touches all three even though nobody thinks of a phone as an information system. The rule is at 45 CFR Part 164 Subpart C, and it is deliberately technology neutral, which is why vendors can claim to satisfy it in wildly different ways.

You do not need to become an expert in the rule. You need to be able to map it onto the four or five things that actually happen when a patient calls.

Two of those rows are yours, not the vendor's. The risk analysis is a requirement on your practice, and it must include the answering service as a system that handles ePHI. Most small practices have a risk analysis that predates the phone decision and never got updated. If OCR ever asks, that gap is the first thing they find, because it is the first thing they ask for.

The second is workforce. Your own staff are the most likely source of a phone related incident: messages forwarded to a personal email, a callback list on a paper pad, a screenshot pasted into a group chat. No vendor control fixes any of that. Decide where messages land, make it one place, and train to it.

Encryption, and why nobody will promise you the phone call itself

Traditional phone calls over the public switched telephone network are not encrypted end to end, and no vendor can make them so. What is encrypted is the digital leg: the SIP or WebRTC connection between the carrier and the platform, and the storage of any recording or transcript afterward.

This is not a loophole, it is how telephony works, and HIPAA accommodates it. Encryption is an addressable implementation specification rather than a flat requirement, which means you implement it where reasonable and appropriate and document your reasoning where you do not. The practical position is straightforward: the copper and cellular legs are outside anyone's control, everything digital should be encrypted, and a vendor who claims end to end encryption on an ordinary phone call is either describing the digital leg imprecisely or overselling.

Call recording consent: one party and two party states

Recording a patient call is governed by state wiretapping law, not HIPAA, and the states split into two regimes: one party consent, where only one participant needs to agree, and all party consent, commonly called two party, where everyone on the call must agree. Get this wrong and you have a criminal statute problem sitting alongside a privacy one.

Federal law under 18 U.S.C. 2511 permits recording with the consent of one party, and most states follow that. A meaningful minority require the consent of all parties. The exact count is disputed in published lists because some states have ambiguous case law and some distinguish between in person and electronic communications, which is one reason this page does not print a fifty state table. Any table you find online is a snapshot of someone's reading of the law on the day they wrote it.

The operational answer removes the complexity entirely. Disclose recording in the greeting on every call, in every state, and give the caller a way to proceed without being recorded if they object. The disclosure costs you three seconds. Not having it costs you the argument.

A workable greeting does three jobs in one sentence: it identifies the practice, it discloses recording, and it does not bury either. Something like: thanks for calling Riverside Family Dental, this call may be recorded for quality and record keeping. If the agent is an AI agent, the disclosure that it is an AI belongs here too, which is covered in the next section.

Why continued participation counts, and when it does not

Implied consent through continued participation is the mechanism nearly every call center relies on: the caller is told at the start that the call may be recorded, and by staying on the line they consent. Courts have generally accepted this where the notice is clear and comes before recording begins.

It weakens in three situations worth knowing about. When the notice is buried after a menu, so a caller who pressed a key never heard it. When recording starts before the notice plays, which is a configuration detail worth checking in your own system. And when the call is transferred to a second party, for example an on call clinician, without a fresh disclosure. The third one is common in after hours setups where a call bounces from an answering service to a personal cell phone.

Outbound calls are a separate problem

Outbound calls to patients bring in the Telephone Consumer Protection Act, which is a different statute with its own consent rules and its own plaintiffs' bar. Appointment reminders and health care messages have specific treatment under FCC rules, and prerecorded or artificial voice calls have stricter requirements than live ones.

An AI voice agent placing outbound calls is squarely in the artificial voice category. The FCC confirmed in a February 2024 declaratory ruling that AI generated voices in robocalls are artificial voices under the TCPA. That does not ban them, but it does mean prior express consent rules apply, identification requirements apply, and the do not call framework applies. If your project includes outbound recall or reminder calls, treat that as a separate legal review from your inbound answering service, because it is one.

Do patients have to be told they are speaking to an AI

There is no federal law requiring you to tell a caller they are speaking to an AI, and HIPAA says nothing about it. The duty comes from state law, and as of now the two that matter most for a healthcare phone line are California and Utah. Both are satisfied by the same simple behavior: say it is an AI at the start, say it again at the end, and give the caller a way to reach a human.

This section is the part of the page most competitor content gets wrong, usually by citing a repealed Utah section, by attributing California's disclosure rule to the wrong code, or by describing a payer law as a patient notice law. The material below is stated from the statutes themselves.

California AB 3030 and Health and Safety Code Section 1339.75

California AB 3030 requires a health facility, clinic, physician's office or office of a group practice that uses generative AI to produce written or verbal patient communications about patient clinical information to include a disclaimer saying the communication was AI generated, plus clear instructions on how to reach a human health care provider.

The law added exactly one section to the codes: Health and Safety Code Section 1339.75, in Chapter 2.13. It was chaptered on 28 September 2024 as Chapter 848 of the Statutes of 2024, and took effect on 1 January 2025. It added no Business and Professions Code sections, which is worth saying because that misattribution appears in a lot of published summaries.

The scope limit is the most commercially important detail on this page. Section 1339.75(c)(7) defines patient clinical information as information relating to the health status of a patient, and expressly excludes administrative matters including appointment scheduling, billing, or other clerical or business matters.

Read that carefully, because it decides whether your phone agent is in scope at all. An agent that books appointments, answers billing questions, confirms hours and takes messages is handling administrative matters and falls outside AB 3030. The same agent comes into scope the moment it generates content about a patient's health status, for example summarizing symptoms back to the caller in clinical terms, offering guidance about a condition, or producing a message about test results.

For audio, the mechanics are specific. Section 1339.75(a)(1)(C) requires the disclaimer to be provided verbally at the start and at the end of the interaction. Not once. Both ends. And Section 1339.75(a)(2) separately requires clear instructions describing how a patient may contact a human health care provider.

There is a full exemption at Section 1339.75(b): if the communication is read and reviewed by a human licensed or certified health care provider, subdivision (a) does not apply. Note what that requires. A licensed or certified provider, not a receptionist, not a practice manager, not an office administrator. A front desk staffer reviewing the AI's message does not trigger the exemption.

One more correction, because it circulates widely. The statute never uses the phrase clear and conspicuous. It says the disclaimer must be prominently displayed for written communications, and it requires clear instructions for reaching a human. Do not attribute clear and conspicuous to California.

Enforcement borrows existing licensing machinery rather than creating anything new. The California Department of Public Health oversees facilities and clinics; the Medical Board of California or the Osteopathic Medical Board handles physicians. There is no private right of action and no dollar penalty of its own, so any article quoting you a per violation fine under AB 3030 is inventing it. The real exposure is licensing exposure, which for a practice is worse than a fine.

California SB 1120 is not a patient notice law

SB 1120 is a payer and utilization review law and it does not apply to your phone agent. It binds health care service plans, disability insurers and the utilization review entities they delegate to, not providers answering their own phones.

It amended Health and Safety Code Section 1367.01(k) and Insurance Code Section 10123.135(j), as Chapter 879 of the Statutes of 2024, effective 1 January 2025. The core rule is that AI shall not deny, delay or modify health care services based, in whole or in part, on medical necessity, and that only a licensed physician or other competent licensed health care professional may make a medical necessity determination.

Its only disclosure duty sits inside the plan's written utilization review policies, which are filed with the regulator. There is no patient-facing notice requirement in it. It is included on this page because it is frequently cited in vendor marketing as though it required telling patients about AI, which it does not.

Utah: Title 13 Chapter 77, not the repealed section

Utah's AI disclosure duty now lives in Title 13, Chapter 77, Sections 13-77-101 through 13-77-106, enacted by SB 226 in 2025 as Chapter 465 and effective 7 May 2025. Utah Code Section 13-2-12, which older articles still cite, was repealed. Citing it as current law is simply wrong.

The structure has two tiers, and the difference between them is the whole story.

The general consumer duty at Section 13-77-103 is reactive and gated. A supplier must disclose that the consumer is interacting with generative AI only if the individual asks or otherwise prompts, and the ask must be a clear and unambiguous request. A caller who says are you a robot in passing may not have made a clear and unambiguous request. This tier is much narrower than it is usually described.

The regulated occupations tier is proactive. A person in a regulated occupation, which includes licensed health care providers, must disclose the use of generative AI, but only where the use constitutes a high-risk artificial intelligence interaction, and for a verbal interaction the disclosure must be provided verbally at the start.

That narrowing is largely illusory in healthcare. High-risk under Section 13-77-101 includes the collection of sensitive personal information including health data, and the provision of medical or mental health advice. An agent that asks a caller for the reason for their visit, or captures a symptom, or takes a refill request, is collecting health data. That is a high-risk interaction, which means the proactive verbal disclosure at the start of the call applies.

The safe harbor at Section 13-77-104 is the actionable part. No enforcement action may be brought if the AI clearly and conspicuously discloses at the outset of and throughout the interaction that it is generative AI, is not human, or is an AI assistant. This is where the phrase clearly and conspicuously actually appears in Utah law: in the safe harbor, not in the duty. Self-identifying up front and throughout removes the exposure entirely, which makes it the obvious operational choice rather than a judgment call about whether a given call was high-risk.

Penalties under Section 13-77-105 are enforced by the Utah Division of Consumer Protection with the Attorney General as counsel. An administrative fine of up to $2,500 per violation, a court fine of up to $2,500 per violation, up to $5,000 per violation for breaching an order, plus disgorgement, injunctive relief and fee shifting. There is no private right of action.

One more thing to unlearn. The 1 July 2027 sunset that gets quoted in articles about Utah applies to Title 13 Chapter 72, the Artificial Intelligence Policy Act, not to Chapter 77. The disclosure duty and its penalties are not scheduled to sunset. Planning a deployment on the assumption that Utah's rule expires in 2027 is planning on a misreading.

The combined operator answer

An agent that discloses verbally at the start, repeats the disclosure at the end, and offers a human path satisfies both California and Utah. That is the whole compliance design, and it costs you about six seconds of call time.

Build it into the script rather than treating it as a legal review item, because a script is enforceable and a policy is not. In practice that means four elements.

• An opening line that names the practice, states that the caller is speaking with an AI assistant, and discloses recording if you record. Example shape: Thanks for calling Riverside Family Dental, this is an AI assistant and the call may be recorded.
• A human path offered without the caller having to fight for it. Say it once in the opening or make it available on request, and make sure the agent actually recognizes requests for a person, including indirect ones like I would rather speak to someone.
• A closing line that repeats the AI disclosure and states how to reach a human provider, because California requires the disclaimer at the end of an audio interaction, and almost no deployed agent does this today.
• Self identification throughout, meaning the agent never claims to be a person if asked, and does not use a script written to imply otherwise. This is what Utah's safe harbor rewards, and it is also the thing patients get angry about when it goes wrong.

Two things not to do. Do not have the agent give itself a human first name and a persona designed to pass as staff, which is exactly the fact pattern that turns a technical compliance question into a consumer protection complaint. And do not rely on the AB 3030 human review exemption unless a licensed or certified provider genuinely reads the communication, because reviewed by the front desk does not qualify.

State law here is moving quickly, and more states are legislating on AI disclosure every session. Confirm the current text of any statute before you rely on it, and treat the summaries above as a starting point for your counsel rather than a substitute for one.

AI specific questions a human answering service never raised

An AI phone agent introduces four questions that no human answering service ever had to answer: where the model runs, whether the audio leaves the country, what the transcript retention default is, and whether deletion actually deletes. None of these appear on a traditional answering service checklist because until recently there was nothing to ask.

A human service has a call center, staff, a supervisor and a building. You can picture the risk. An AI agent has an inference path that may cross three vendors and two continents in a second and a half, and the practice buying it usually cannot name a single hop. That is the gap this section closes.

Where the model runs, and why the answer is usually a list

Most AI phone agents do not run one model, they orchestrate three: speech to text, a language model, and text to speech. Each may be a different company in a different region, and each receives content derived from the call.

Ask for the answer as a list, not a sentence. A good vendor will give you the three providers by name, tell you which cloud regions they run in, confirm that each is covered by a BAA or an equivalent commitment, and tell you what happens if one is swapped. A vendor who answers this with a single sentence about enterprise grade security has not thought about it, or does not want to.

Some vendors run models on their own infrastructure, which changes the shape of the risk rather than removing it. Self hosted means fewer third parties and a shorter chain, and it also means the security of the model host is entirely that vendor's responsibility, with no large provider's security program underneath. Neither answer is automatically better. What matters is that they can describe it precisely.

Deletion that actually deletes

Deletion in most systems means hidden from your view, and the difference between that and destroyed matters when a patient exercises a right or a breach investigation asks what you still hold. Ask specifically whether deletion removes the audio file, the transcript, the derived summary, the analytics record, the search index, the backups, and any copy held by a subcontractor, and how many days each takes.

Backups are the honest complication. No serious vendor deletes from immutable backups on request, and that is normal practice rather than evasion. What you want is a stated backup retention window, for example 30 or 35 days, after which the deleted data ages out permanently, and a written statement that backups are not used for anything except restoration. A vendor who says backups are retained indefinitely has told you that deletion is theatrical.

The evaluation checklist, with the answers you want

Run these twenty five questions at the vendor before you sign anything. Each is paired with the answer that should let you proceed. Anything materially weaker than the paired answer is a finding to resolve in the contract, not a detail to sort out later.

How to use it: send it as a document, ask for written answers, and keep the replies. Written answers from a salesperson are not contractual, but they are evidence of what you were told, and they make the later contract negotiation much faster because you already know where the soft spots are.

Contract and legal

• 1. Will you sign a BAA before we send a single real patient call. Answer you want: yes, and here is our standard text, and we accept redlines.
• 2. Does the BAA apply on the plan we are buying. Answer you want: yes, on every plan, or yes on this specific plan which is the one you are on.
• 3. What are the permitted uses of our PHI in the BAA. Answer you want: only to provide the contracted services, with no rights for internal analytics, product development or improvement of services.
• 4. Do you claim any right to de-identify and reuse our data. Answer you want: no.
• 5. Within how many days will you notify us of a security incident or breach. Answer you want: a number, ideally 5 to 10 calendar days from discovery, written into the BAA.
• 6. Who pays for breach notification if the breach originates with you. Answer you want: we do, and it is in the contract.
• 7. What is your liability cap, and does it carve out breaches of the BAA. Answer you want: a cap with a compliance carve out, or at minimum a multiple of annual fees rather than one month.
• 8. Do you carry cyber liability insurance and at what limit. Answer you want: yes, with a number and a certificate on request.

Data handling

• 9. Is call recording on or off by default, and can we turn it off entirely. Answer you want: configurable, and off is a supported configuration.
• 10. What is the default retention for audio and for transcripts. Answer you want: a specific number of days for each, and both are configurable down.
• 11. Is data encrypted in transit and at rest, and who holds the keys. Answer you want: yes to both, with a named standard, and a clear statement about key management.
• 12. Where is our data stored geographically. Answer you want: named regions, in the United States unless you have decided otherwise.
• 13. Can we delete a specific call on request, and what does that deletion cover. Answer you want: audio, transcript, summary, analytics and index, within a stated window, with backups aging out on a stated schedule.
• 14. How are messages delivered to our staff. Answer you want: a secure portal or an app, with any email or SMS containing no PHI beyond a notification to log in.

Access and oversight

• 15. Who at your company can listen to our calls, and under what process. Answer you want: named roles, access requires a ticket or break glass approval, and every access is logged.
• 16. Can we get an access log for our account. Answer you want: yes, on request, and here is what it looks like.
• 17. Do you use offshore staff for support, transcription or quality review. Answer you want: a direct yes or no with locations. Either can be acceptable, but you need to know.
• 18. Do your staff complete HIPAA training, and how often. Answer you want: yes, at onboarding and annually, documented.
• 19. Have you had a security assessment, and will you share a summary. Answer you want: SOC 2 Type II or an equivalent, with a report under NDA, or a candid explanation of what they have instead.

Subcontractors and AI

• 20. List every subcontractor that touches call audio, transcripts or derived data. Answer you want: a named list produced within a day, with BAAs in place for each.
• 21. Will you notify us before adding or changing a subcontractor. Answer you want: yes, with notice, and a right to object.
• 22. Is our data used to train, fine tune or evaluate any model, by you or by any subcontractor. Answer you want: no, stated contractually, covering evaluation and benchmarking as well as training.
• 23. Is human review of calls for labeling or grading ever performed. Answer you want: not on our data without our written agreement.
• 24. What happens to calls in progress if your platform fails. Answer you want: a described failover, typically routing to a backup number or voicemail, tested.
• 25. What is your process when the agent gets something wrong on a clinical call. Answer you want: a defined escalation to a human, an incident log, and a named person who owns the review.

A note on how to read the results. Very few vendors clear all twenty five cleanly, and a vendor who claims to should be probed harder rather than trusted more. What separates a serious vendor from a risky one is not a perfect score, it is whether they know their own answers. Precision is the signal. Vagueness is the finding.

What a breach involving phone data looks like

A phone related breach rarely looks like a hacker. It looks like a misconfigured storage bucket full of call recordings, a message queue emailed to the wrong address, an employee at the vendor browsing calls out of curiosity, or a subcontractor nobody knew existed getting compromised.

Under HIPAA a breach is an acquisition, access, use or disclosure of PHI not permitted by the Privacy Rule, and it is presumed to be a breach unless you can demonstrate a low probability that the PHI has been compromised, using the four factor risk assessment at 45 CFR 164.402. Those four factors are the nature and extent of the PHI involved, who used it or received it, whether it was actually acquired or viewed, and the extent to which the risk has been mitigated.

Phone data scores badly on the first factor and often on the third. Call recordings contain names, dates of birth, callback numbers and clinical narratives together, which is the combination that makes an incident notifiable rather than dismissible. If your retention is 30 days, the exposed set is 30 days of calls. If it is indefinite, it is everything you have ever taken.

Notification obligations, at a high level

If a breach of unsecured PHI is confirmed, a covered entity must notify affected individuals without unreasonable delay and no later than 60 days from discovery, notify HHS, and for breaches affecting 500 or more residents of a state or jurisdiction, notify prominent media outlets in that area.

The thresholds and timing are worth carrying in your head, because they change how you write the BAA.

• Individuals: written notice by first class mail, without unreasonable delay and within 60 days of discovery.
• HHS, 500 or more individuals affected: notify contemporaneously with individual notice, within 60 days.
• HHS, fewer than 500 individuals: log the incidents and report annually, within 60 days after the end of the calendar year.
• Media, 500 or more residents of a state or jurisdiction: notify prominent media outlets serving that area, within 60 days.
• Business associate to covered entity: without unreasonable delay and within 60 days of discovery, which is why leaving your BAA at the statutory maximum is a mistake.

That last point is the practical link between this section and the contract section. If your vendor is permitted 60 days to tell you, and you then have 60 days from your own discovery, the patient may learn about it four months after the fact, and the optics of that are as damaging as the breach. Negotiating the vendor's notification window down to 5 or 10 days is one of the highest value edits available in a BAA and one of the easiest to win.

State breach notification laws sit on top of HIPAA and are frequently stricter, with shorter deadlines, attorney general notification requirements, and definitions of personal information that can capture data HIPAA would not. If you operate in more than one state, assume the strictest applicable rule sets your timeline.

The encryption safe harbor

Breach notification applies to unsecured PHI, meaning PHI that is not rendered unusable, unreadable or indecipherable through encryption or destruction meeting HHS specified guidance. Properly encrypted data that is lost or stolen may not trigger notification at all.

This is the reason to care about encryption specifics rather than accepting a yes. Encrypted at rest with the keys stored beside the data does not protect you against the most common failure mode, which is an exposed store, because whoever reaches the store reaches the keys. Ask where the keys live and who can use them. That single question separates real encryption from a checkbox.

What to do in the first 48 hours

Contain first, document from the first minute, and do not delete anything. The instinct to clean up destroys the evidence you need to argue low probability of compromise, and the four factor assessment is the only path to not notifying.

• Contain: revoke access, disable the integration, rotate credentials, stop the forwarding rule.
• Preserve: logs, access records, the misdirected message, the configuration as it was. Screenshot before you fix.
• Scope: how many individuals, which data elements, what date range. Retention settings decide this number for you before the incident ever happens.
• Notify your vendor in writing and invoke the BAA's incident clause, so their clock is documented as starting.
• Get counsel involved before you decide it is not notifiable. The presumption runs against you and the analysis has to be documented either way.

Sector notes: what changes by practice type

The rules are the same across health care, but the risk profile is not, and three things change by sector: how sensitive the average call is, how much clinical content the agent will unavoidably touch, and whether HIPAA applies at all. Veterinary practices are the case where it does not, and where almost everyone assumes it does.

Dental

Dental practices are the easiest sector to deploy an AI phone agent in, because the call mix is overwhelmingly administrative. New patient inquiries, appointment booking and rescheduling, hours, insurance acceptance, and where to park. All of it sits in the administrative category that AB 3030 expressly excludes from patient clinical information.

The BAA is still required, because a name plus a callback number plus an appointment with a dental practice is PHI. What changes is scope. A well designed dental agent can be built to never collect a clinical detail, which shrinks the risk surface and removes most of the AI disclosure questions at the same time. The exception is the emergency call, meaning pain, swelling, a knocked out tooth, which is clinical and urgent and should transfer to a person immediately rather than being triaged by software.

Medical practices and clinics

The dividing line in a medical practice is between scheduling and clinical calls, and the most valuable design decision is keeping the agent firmly on the scheduling side. Booking, rescheduling, directions, insurance questions, form requests and callback capture are administrative. Symptoms, results, refills and medication questions are clinical.

Refill lines deserve a specific mention because they are the highest PHI density calls a practice takes and they are also the most repetitive, which makes them tempting. An agent can capture a refill request as a structured message, meaning patient, medication, pharmacy, and route it, without generating any content about health status. What it should not do is discuss dosage, interactions or whether a medication is appropriate, which is both a clinical safety problem and the thing that pulls you into AB 3030 scope.

Test results are the clearest no. Never let an agent read a result, characterize a result, or tell a caller a result is normal. That is a clinical communication about health status, it needs a licensed provider, and getting it wrong is not a compliance issue, it is a patient safety issue.

Mental and behavioral health

Mental health is the sector where sensitivity is highest and where the fact of the call is often more sensitive than its content. Someone calling a psychiatric practice has disclosed something significant before saying a word, which is why the identity plus specialty combination discussed earlier matters most here.

Three specifics. Psychotherapy notes get heightened protection under HIPAA and generally require patient authorization for disclosure, so nothing resembling session content should ever pass through a phone system. Substance use disorder treatment programs are additionally subject to 42 CFR Part 2, which is stricter than HIPAA and has historically required patient consent for disclosures that HIPAA would permit. And crisis calls need a hard, tested, immediate path to a human, with no AI triage step in between.

The practical design for behavioral health is minimal: the agent identifies itself as an AI assistant, handles scheduling and administrative questions, collects nothing clinical, and transfers anything that sounds distressed or urgent without hesitation. Set the escalation threshold low. A few unnecessary transfers cost you nothing compared to one mishandled crisis call.

Veterinary: HIPAA does not apply

HIPAA does not apply to veterinary practices, because it protects individually identifiable health information about a human being. Animal health records are not PHI, a veterinary clinic is not a covered entity, and a veterinary answering service does not need a BAA to handle patient calls.

This is worth saying plainly because a large number of veterinary practices believe otherwise, and a number of answering services sell HIPAA compliance to them. Buying a BAA you do not need is harmless. Believing HIPAA is the framework that protects your client data is not, because it means the rules that actually apply are going unexamined.

What does apply to a veterinary practice:

• State veterinary practice acts and board rules, which commonly impose confidentiality duties on client and patient records, with the specifics varying by state.
• State consumer privacy laws, which cover the owner's personal information as an ordinary consumer, with no health care exemption available since the data is not health data about a person.
• State breach notification laws, which apply to the owner's personal information such as name plus payment card or account details.
• Call recording consent laws, identically to any other business.
• AI disclosure law, which in Utah's case turns on regulated occupations and high-risk interactions, and where veterinarians are a licensed occupation. Worth checking rather than assuming the healthcare analysis carries over.
• Payment card rules if the practice takes card details over the phone, which is a recording problem in its own right and a good reason not to record payment calls.

One thing that does carry over: the human corner case. A veterinary line does occasionally receive information about a person's health, for example a client explaining they cannot bring the animal in because of their own medical situation, or a bite incident involving a human. That is still not PHI in a veterinary clinic's hands under HIPAA, but it is sensitive, and if it lands in a transcript it should be treated with the same care.

Human answering service, AI agent, or in-house staff

The compliance requirements are identical across all three, and the differences are in where the risk concentrates and what it costs to control. A human answering service concentrates risk in people and process. An AI agent concentrates it in data flows and subcontractors. In-house staff concentrates it in devices and training.

The honest comparison is that an AI agent gives you more control over compliance than a human service does, and more ways to lose it. You can set retention to 30 days, prove deletion, pull an access log and enforce a script exactly. You can also leave recording on by default, sync transcripts into a CRM that was never in scope, and let a subcontractor you never vetted process the audio. The controls are better and the defaults are worse.

How Augment AI Studio approaches this when building for a practice

Augment AI Studio holds no HIPAA certification, attestation or audit, because none exists to hold and because claiming one would be exactly the behavior this page argues against. What follows is method: the order the work gets done in, and the decisions that get made before any patient reaches the line.

The founder, Kevin Musprett, also operates My Getaways, a short-term property management company, and runs an AI phone agent on its inbound line. That is not a healthcare deployment and it is not offered as one. What it does provide is operating experience with the unglamorous parts: what happens when the agent mishears, where callers get frustrated, what the transfer path has to look like, and how much of the value comes from the boring administrative calls rather than the interesting ones.

Scope before build

The first decision is what the agent is not allowed to talk about, and it gets written down before anything is configured. For a practice that list usually includes test results, symptom interpretation, medication advice, anything about a specific diagnosis, and any question that starts with should I.

Drawing that boundary early does three things at once. It keeps the deployment inside the administrative category that AB 3030 excludes from patient clinical information. It removes the clinical safety risk that makes practices nervous. And it makes the agent better, because a narrow agent with a clear escalation path outperforms a broad one that improvises.

Data map before contract

Before signing anything, the data path gets drawn: which parties touch the audio, what each one stores, for how long, and where. That map is what the BAA gets negotiated against, and it is what the practice keeps for its own risk analysis.

In practice the map is a single page listing the telephony provider, the voice platform, the speech to text and language model providers, the storage location, and every downstream system the agent writes into, with a retention number next to each. Most practices have never seen this drawn for any vendor they use, which is why the exercise usually surfaces something unexpected on the first pass, and it is usually the calendar or the CRM rather than the AI.

Minimum collection by design

Scripts are written to collect the least information that completes the call, which means fixed visit types instead of open ended reason fields, no symptom narrative on administrative calls, and no insurance details captured by voice unless the workflow genuinely requires them.

The easiest compliance win available to any practice is handling the anonymous calls anonymously. Hours, location, parking, whether you are accepting new patients, whether you take a given plan. None of those require knowing who is calling, and every one you answer without collecting a name is a call that generated no PHI at all.

Disclosure in the script, not in a policy

The AI disclosure, the recording disclosure and the human path are written into the opening and closing lines of the script, so they happen on every call whether or not anyone remembers the policy. Start of call, end of call, and a transfer that triggers on any request for a person, including indirect ones.

This is the single design choice that covers both California and Utah, and it is cheap. Practices resist it more often than patients do. The evidence from running an agent on a real inbound line is that callers do not object to being told they are speaking with software. They object to discovering it.

Retention set deliberately, and tested

Recording defaults to off unless the practice has a written reason for it, and where it is on, retention is set to a specific number of days and then tested by deleting a call and checking that the transcript, the summary and the search index went with it.

Testing deletion once, at the start, is worth more than any vendor assurance. It is a fifteen minute exercise that converts a contractual promise into an observed fact, and it occasionally reveals that transcripts survive audio deletion, which is the failure worth catching before there are ten thousand of them.

Pilot on the calls that cannot hurt anyone

The first two weeks run on overflow and after hours only, on the call types that currently reach voicemail, with every call reviewed. Nothing clinical, nothing urgent, and a live transfer path that works before the agent takes its first call.

The measure of success in a pilot is not how many calls the agent handled. It is how many it handled correctly and how cleanly it gave up on the rest. An agent that resolves 60 percent and escalates the other 40 percent quickly and politely is a good deployment. An agent that resolves 85 percent and improvises through the remainder is a liability, and on a medical line it is the kind of liability that ends up in a licensing complaint rather than a support ticket.

Where to start

Start with the BAA, because it is binary and it eliminates most of the market in an afternoon. Send the twenty five questions to every vendor on your shortlist, and see who answers precisely.

A workable sequence for a practice that has never done this before.

• Week one: list the call types you actually receive, and split them into administrative and clinical. This determines your scope and, for California, whether AB 3030 applies to you at all.
• Week two: shortlist vendors, send the questions, request BAAs in writing. Rule out anyone who will not sign one or who cannot name their subcontractors.
• Week three: negotiate the three clauses that matter most, meaning permitted uses, breach notification timing, and a written prohibition on model training. Get the retention numbers in writing.
• Week four: configure recording, retention and message delivery before the first real call. Write the greeting, including the AI disclosure and recording disclosure, and the closing line.
• Weeks five and six: pilot on after hours and overflow only, review every call, test deletion once, and confirm the human transfer path works from a cell phone as well as a desk phone.
• Then: update your risk analysis to include the answering service, file the BAA where you can find it, and put an annual review in the calendar.

None of that requires you to become a compliance specialist. It requires you to ask specific questions and to keep the answers. The practices that get into trouble are almost never the ones that asked and got an imperfect answer. They are the ones that saw a badge on a website and assumed somebody had checked.

Frequently asked questions