AI Demand Letters and HIPAA: What PI Attorneys Must Know

Here is a question we get from nearly every firm that evaluates an AI demand letter tool: "Is this HIPAA compliant?" It is the right question. It is also the wrong way to phrase it, because HIPAA compliance is not a checkbox a vendor ticks — it is a legal relationship that either exists or does not. This post is about what that relationship actually requires, and why the honest answer is more nuanced than a yes or no on a sales page.

Why HIPAA Applies the Moment You Touch Medical Records

A demand letter is built entirely from protected health information: diagnoses, treatment dates, provider names, billing codes. The moment any tool — AI or otherwise — processes those records on your firm's behalf, that tool is acting as a business associate under HIPAA, full stop. It does not matter whether the tool is a household name or a startup, and it does not matter how good its security looks from the outside.

That single fact is the one most firms underestimate when they bring AI into their workflow.

The ChatGPT Question, Answered Directly

This comes up constantly, so let's be direct about it: you cannot paste a client's medical records into ChatGPT, Claude, Gemini, or any other public consumer AI interface to help draft a demand letter. These public tools do not sign Business Associate Agreements. Without a BAA, sharing identifiable patient information with any vendor is a HIPAA violation — not a gray area, a violation — regardless of how careful the prompt is or how the conversation is phrased.

This is not a knock on those AI products. They are built for general use, not regulated healthcare data, and they are upfront that they are not designed for it. The point is that "AI is smart enough to help" and "this AI tool is legally authorized to touch PHI" are two completely different questions, and only the second one matters here.

What a Real Business Associate Agreement Requires

A BAA is not a marketing checkbox. It is a binding contract that obligates the vendor to specific things: safeguard the data using HIPAA's Security Rule standards, restrict use of the data to the services being performed, name and control any sub-processors who also touch the data, and notify the covered entity within a defined window if a breach occurs.

That last point is easy to overlook and worth flagging: many commercial AI contracts default to a 30-day breach notification window. HIPAA requires covered entities to notify affected individuals within 60 days of discovering a breach — which means a vendor's slow notification can eat most of your own compliance deadline before you even know there was a problem. The BAA has to account for that.

"HIPAA-compliant" is not a label a vendor can self-certify. It is the outcome of a signed BAA plus the safeguards required underneath it — and a vendor can have excellent security and still be non-compliant without one.

The Sub-Processor Trap

This is the part that catches firms off guard, and it is directly relevant to any AI demand letter tool: most AI products do not run on a single model. They route requests through one or more underlying AI providers, plus a database layer, plus often a separate service for document processing. Each one of those is a sub-processor that touches PHI if the data flows through it.

A BAA that only covers the vendor's primary product, without naming every sub-processor in that chain, leaves a real gap. Before trusting any AI tool with real client records, the right question is not "do you have a BAA," but "does your BAA cover every system this data actually passes through."

	Public consumer AI	Properly governed AI vendor
Signs a BAA	No	Yes — covering the full data flow
Sub-processors named	N/A	Should be explicitly listed
Breach notification	Not HIPAA-governed	Defined window, contractually set
Safe to enter real PHI	Never	Only once the BAA is in place

Where Lexyno Stands Today

We think the honest answer here matters more than the convenient one, so here it is plainly: Lexyno has not yet finalized signed Business Associate Agreements with every underlying AI infrastructure vendor in our pipeline. We are working through that process now — it is one of the most important things on our roadmap, not an afterthought.

In the meantime, our interim safeguard during evaluation is de-identification: removing or masking identifying details before data reaches the underlying AI systems, which is a recognized way to reduce HIPAA exposure for data that no longer qualifies as PHI. It is a reasonable bridge, and we are transparent about it being a bridge rather than a finished destination. Any vendor who tells you compliance is simply "done" the day you sign up for an AI tool is oversimplifying a legal relationship that takes real, ongoing work.

What to Ask Any AI Vendor Before You Send Real Records

Whether you are evaluating Lexyno or anyone else, this is the actual checklist:

• Will you sign a BAA, and is it in place before any real PHI is processed?
• Does the BAA name every sub-processor the data passes through, not just the primary product?
• What is the contractual breach notification window, and does it leave you enough time to meet your own 60-day obligation?
• How is data used and retained — is it used to train the vendor's models, and for how long is it stored?
• What happens during evaluation, before a BAA is signed — is de-identification or another safeguard used?

A vendor that answers these clearly, including admitting what is not yet in place, is a more trustworthy partner than one that just says "yes, we're HIPAA compliant" and moves on. Compliance is a process you can verify, not a label you take on faith.