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.

Medical Records Do Not Answer the HIPAA Question by Themselves

A demand letter contains highly sensitive health information: diagnoses, treatment dates, provider names, and billing codes. But possessing those records does not automatically make every plaintiff PI firm a HIPAA covered entity or every vendor its business associate. HIPAA applicability depends on the parties' legal roles and the actual data flow.

That nuance is not permission to use consumer tools casually. Attorney confidentiality duties, protective orders, client instructions, state privacy laws, and vendor contracts may impose separate or stricter limits even when HIPAA does not govern the firm.

The ChatGPT Question, Answered Directly

This comes up constantly, so let's be direct about the operational answer: do not paste a client's identifiable medical records into ChatGPT, Claude, Gemini, or another public consumer AI interface. Consumer subscriptions are not the same contractual and technical service as an eligible enterprise API. Even where HIPAA does not apply to the firm, confidentiality and privacy obligations still require a controlled workflow.

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 is the current position plainly: Lexyno has Business Associate Agreements with the two model API providers used in the product pipeline, OpenAI and Anthropic. Gemini was removed from the product pipeline rather than retained as an uncovered fallback.

Those agreements cover specific API services, organizations, endpoints, and eligible features; they do not cover public ChatGPT, Claude consumer interfaces, or every third-party tool. Lexyno therefore does not treat a signed BAA as a blanket "HIPAA compliant" label. Contractual coverage, access controls, data minimization, retention, incident response, and the customer's own legal role must still line up with the actual data flow.

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?
• Which exact service and configuration are covered, and is there any consumer interface or uncovered fallback in the path?

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.