Does Your CRM Integration Need to See Raw Client PHI?

Every integration is a new place PHI can end up

Look at a typical agency's stack. A CRM holding client records, likely GoHighLevel. A texting and email automation layer sitting on top of it. A voice AI or an AI receptionist answering after hours. Maybe a chatbot widget on the quote form. Maybe a call-analysis tool that transcribes and scores every conversation. Maybe someone on staff who pastes a client's plan question into ChatGPT to draft a faster reply. None of these tools were added at once, and none of them came with a clear answer to the question that actually matters: does this specific piece of software need to see a client's name and date of birth attached to their plan or diagnosis, or is it doing a job that never required that combination in the first place.

Most agencies never ask the question, because nothing forces them to until something goes wrong. The CRM has a BAA. That feels like coverage. It isn't, not for what's connected downstream of it, and it's worth being precise about why before going any further.

Picture the actual sequence at a mid-sized Medicare agency. A client calls after hours about a Part D question. The AI receptionist answers, pulls the caller's record to greet them by name and confirm the right account, and routes the call. To do that, most setups hand the receptionist the whole contact card: name, phone, date of birth, current plan, and the note field where a previous agent wrote down a diagnosis-adjacent detail because it affected a recommendation. The receptionist only needed the name and the callback number. It got all of it, because the integration that connects the phone system to the CRM was built to pass the record, not a filtered version of it. If that receptionist runs on a general model with no BAA behind it, that whole card just left the building.

What "touching PHI" actually means for an API call

Protected health information, the details HIPAA protects, is a name, a date of birth, a phone number, or an address, once it's paired with anything about a person's health or coverage: a plan type, a diagnosis, a prescription, an enrollment status.² A lead named "interested in ACA options" isn't PHI by itself. The instant your CRM attaches that lead's date of birth and the subsidized plan they're enrolled in, the record is PHI, and every system that reads it, forwards it, or logs it is now handling PHI whether it was built to or not.

A Business Associate Agreement is the contract that makes it legal for a vendor to handle PHI on your behalf. It obligates that vendor to specific safeguards and specific breach notification duties, and without one, sharing PHI with that vendor is the violation, not some later misuse. Most general-purpose consumer AI products, the free or basic tier of a chatbot, a browser extension, a personal AI assistant, don't offer a BAA at all. The enterprise or platform tiers of major AI providers often do, but only for the specific product and hosting arrangement named in that agreement, not for every way a company's models can be accessed.¹

That last distinction is the one that trips up agencies that think they've handled this. Ambrose, the AI platform this site is built on, keeps its BAA-covered path narrow and explicit on purpose: PHI is restricted to running through Claude via Amazon Bedrock in U.S. regions, the specific arrangement actually covered by a signed agreement, not "an AI model" in the abstract.¹ If your own stack can't name the specific model, the specific hosting environment, and the specific agreement covering it, you don't actually know whether you're covered. You're assuming.

There's a second version of this problem that has nothing to do with your official integrations: a staff member who gets stuck drafting a reply and pastes the client's full message thread, name and plan detail included, into whichever AI chat tool they already have open in another tab. Security teams call this "shadow AI," and it's not a hypothetical for an insurance office. Cyberhaven's own data, covered in more detail below, shows people feed sensitive information into AI tools once every three days on average across the workforce it studied.³ No integration, no API, no BAA to even check, because the CRM never touched it. This is why the fix in this guide has to include a written policy for staff, not just an audit of your official connections.

Why the default setting is always "send everything"

Nobody builds an integration to leak data on purpose. It happens because sending the whole record is the easy path, and stripping it down to only what's needed is extra work that has to be done deliberately, field by field, integration by integration.

When a CRM triggers an automation, an AI receptionist call, or a chatbot reply, the default way to wire that connection is to pass the full contact object, every field in the record, to whatever's listening on the other end. That's how most no-code automation tools (Zapier, Make, a CRM's own workflow builder) are designed to work: you drag the contact record into the next step, and every field comes with it unless someone goes back and manually removes the ones the next step doesn't need. A voice AI script that only needs to confirm an appointment time still typically receives the caller's full record, including plan and health details it never uses, because building a version of the integration that passes only the appointment time is more work than the default.

Layer a general-purpose AI tool on top of that pattern and the exposure compounds. An AI receptionist answering "what does my plan cover" needs some context to give a real answer, and the fastest way to give it that context is to hand it the whole client record and let it figure out what's relevant. The AI model itself doesn't request the extra fields. The integration just includes them, because nobody wrote the extra logic to leave them out.

What an unmanaged integration actually costs

Start with how common this already is, industry-wide, not specific to insurance. Cyberhaven's 2026 AI Adoption and Risk Report found that 39.7% of all AI interactions, prompts, pastes, and file uploads, now involve sensitive data, and that employees feed sensitive data into AI tools once every three days on average.³ That figure isn't insurance-specific, but it's a reasonable floor for what's happening inside an industry that handles health and financial detail on every single contact record by default.

Now put a dollar figure next to what happens when that sensitive data is mishandled and it turns into a breach. IBM's Cost of a Data Breach Report 2026 puts the global average cost of a data breach at $4.99 million, a record high and a 12% increase over the prior year.⁴ That's an average across industries and breach types, not a prediction for any specific agency, and most breaches an independent agency will ever face look nothing like a $5 million event. The number is worth citing anyway, because it's the direction the cost curve is moving in industry-wide, and because the same report has tracked healthcare as one of the more expensive sectors to have a breach in for over a decade running, driven by exactly the kind of detection, notification, and lost-business costs a PHI leak through an unvetted integration would trigger.

There's a cost that shows up long before any breach, too: the time and legal fees of an OCR complaint investigation, or the internal scramble of a risk assessment nobody scheduled because a new integration went live without one. Those costs land whether or not anything was ever actually breached, the moment an investigator or an auditor asks the question this guide is asking: which of your integrations touch PHI, and which of them have a BAA that actually names them.

How to audit your own stack this week

None of this requires ripping out your tools. It requires knowing, integration by integration, what actually crosses the wire, and closing the gaps in the table above one at a time.

Inventory every place a client record travels. List every tool connected to your CRM that can read a contact record: your texting and email automation, your voice AI or receptionist, your chatbot widget, your call recording and analysis tool, any custom assistant or GPT staff use day to day. Most agencies have never written this list down in one place.

For each one, ask two questions. Does this destination have a signed BAA that names it specifically, not just a BAA with your CRM. And does the job this tool performs actually require the client's name, date of birth, and health or plan detail, or could it be done with an aliased ID and a narrower slice of the record.

Test it, don't assume it. Run one fake but realistic record through each integration and look at the actual outgoing request, most CRMs and automation platforms let you inspect this. If the payload includes fields the destination tool never displays or acts on, that's unnecessary exposure sitting in a request log somewhere, whether or not anything bad ever happens with it.

Set a default policy and write it down. The simplest workable rule for most agencies: no client identifier leaves the CRM for a non-BAA destination, ever, full stop. Everything that needs AI assistance without a BAA in place gets aliased first, a case number or a token instead of a name, and rehydrated only inside a system that's actually covered.

Re-check it after every vendor update. A tool that was fine six months ago can change which model it routes requests to, or add a new integration of its own, without telling you. Put a repeat reminder on the calendar, quarterly is reasonable, to re-run the test above.

Write the staff policy down, separately from the vendor audit. The integrations you control with settings and BAAs are one problem. What a staff member does with a personal AI account on their own laptop is a different one, and no vendor audit catches it. One sentence covers most of it: no client-identifying detail, name, date of birth, phone number, or plan and health specifics, goes into a personal or unapproved AI tool, ever. Post it somewhere staff actually see it, not just in an onboarding packet nobody reopens.

How we keep PHI out of the wrong hands

This is the exact problem Ambrose was built to close, not as an add-on feature but as the default path data takes. Its own documentation names three explicit PHI handling modes, and the difference between them is worth understanding even if you never use Ambrose, because it's the clearest public description we've found of what "handling this correctly" actually looks like in practice.

The mode can be set by default and overridden per request, and every call returns which mode was actually used and why, so there's a real record instead of a guess.¹ That's the difference between a platform that treats PHI handling as a policy someone wrote once and a platform that enforces it, call by call, and can show its work.

It's also, plainly, what we build for agencies that hire us. Our own service page states it directly: anything that touches real client data runs through Ambrose, which masks protected health information before any non-BAA AI model ever sees it, then re-hydrates it for the agency afterward.⁵ The AI receptionist, the conversation follow-up, the call analysis, all of it runs on that same rail, on the agency's own accounts and domain, so the agency owns it rather than renting a black box.

Who this fits, and who's fine as is

This matters most for an agency that has already connected, or is about to connect, more than one AI tool to its CRM: an AI receptionist plus a chatbot plus a call-analysis tool is a very different exposure profile than a CRM running on its own with no AI layered on top. If you're actively using or evaluating an AI receptionist, a voice AI, or a general AI assistant anywhere near client records, this is worth the afternoon it takes to check.

It matters less if your agency genuinely isn't using AI tools against client data yet. A CRM with a signed BAA and no AI layer connected to it isn't the exposure this guide describes, and there's no need to build an aliasing layer for a connection that doesn't exist. The moment that changes, revisit this.

It matters more, not less, for an FMO or IMO running the same AI receptionist or chatbot setup across a dozen or more downline offices. One misconfigured integration replicated across every sub-account isn't one exposure, it's a dozen, and a single downline agent pasting a client record into the wrong tool becomes the FMO's problem the moment it's traced back to shared infrastructure. If that's your situation, the audit in this guide is worth running once at the FMO level rather than trusting each office to run it on its own.

Questions agents ask about PHI and AI tools