Last updated: October 2026 · Reading time: about 11 minutes
What this guide covers
Why a PI firm is covered by HIPAA
A personal injury firm is not a healthcare provider, and attorneys often assume HIPAA does not apply to them. That assumption is partly right and dangerously incomplete.
HIPAA's Privacy Rule applies directly to covered entities — healthcare providers, health plans, and clearinghouses. A law firm is not a covered entity. But HIPAA also reaches firms through the business associate route: a business associate is a person or entity that performs functions on behalf of a covered entity involving protected health information. When a PI firm obtains medical records in the course of representing a client, it is generally acting as a business associate of the healthcare providers that release those records.
That has a practical consequence for AI tool adoption: any vendor that processes those records is a downstream business associate, and the chain of BAAs must be intact from the provider through your firm to the vendor. A break in that chain is a compliance failure regardless of how good the tool is.
The BAA: the only real gate
The Business Associate Agreement is the single document that determines whether a tool is legally usable with protected health information. There is no workaround, no "we encrypt it so it's fine," and no compliance posture that substitutes for a signed BAA.
What a BAA must actually say, in practical terms:
- Permitted uses and disclosures. The vendor may only use PHI for the purposes the agreement specifies. Broad language like "for service improvement" needs scrutiny.
- Safeguards. The vendor commits to administrative, physical, and technical safeguards. Ask what they actually are, not just that they exist.
- Breach notification. The vendor must notify you of a breach within a defined timeframe. Check what that timeframe is — "without unreasonable delay" is not a number.
- Subcontractor flow-down. This is the critical clause. The vendor must ensure any subcontractor that touches PHI signs an equivalent agreement. If this clause is missing, the subprocessor problem below becomes your problem.
- Return or destruction at termination. What happens to the data when you leave? "We retain it for our records" is not acceptable for PHI.
- Access and amendment. The vendor must support your obligations to give clients access to their records and amend them.
SOC 2 Type II: what it is and what it doesn't prove
SOC 2 is a voluntary audit standard developed by the AICPA. It is not a law and it is not a certification — it is an attestation report produced by an independent auditor. Understanding the distinction prevents a common mistake: treating a SOC 2 report as proof of HIPAA compliance.
| Report type | What it shows | What it doesn't show |
|---|---|---|
| SOC 2 Type I | Controls are suitably designed at a single point in time | Whether they operated effectively over any period |
| SOC 2 Type II | Controls operated effectively over an audit period, typically 6–12 months | That the vendor is HIPAA-compliant, that its product is secure in every configuration, or that your use of it is compliant |
When you receive a SOC 2 Type II report, check three things:
- The audit period. A report covering a period that ended more than 12 months ago is stale. Controls change; the report should reflect current operations.
- The Trust Services Criteria covered. SOC 2 covers five criteria — security, availability, processing integrity, confidentiality, and privacy. Many reports cover only security. For PHI handling, you want confidentiality and privacy covered as well.
- The exceptions section. Every SOC 2 report has a section listing control failures found by the auditor. Read it. A report with no exceptions at all is unusual; a report with exceptions that the vendor has not remediated is a problem.
The subprocessor problem
This is the issue most firms miss, and it is the one most likely to create a real compliance gap.
Almost every AI legal tool is built on top of a third-party foundation model — from OpenAI, Anthropic, Google, or an open-source provider. When your client's medical records are uploaded to the tool, they typically pass through that model provider's infrastructure. That provider is a subprocessor, and under HIPAA it must also be covered by a BAA.
The chain looks like this:
| Link in the chain | Who | What must be in place |
|---|---|---|
| Healthcare provider | Hospital, clinic, treating physician | BAA with your firm |
| Your firm | PI law firm | BAA with the AI vendor |
| AI vendor | The tool you are buying | BAA with each subprocessor |
| Model provider | OpenAI, Anthropic, Google, etc. | Covered by the vendor's BAA with them |
| Infrastructure | Cloud hosting (AWS, GCP, Azure) | Covered by the vendor's BAA with them |
The BAA you sign with the AI vendor must contain a subcontractor flow-down clause requiring the vendor to impose equivalent obligations on every subprocessor. Without that clause, there is a gap in the chain, and the gap is invisible to you unless you ask.
Questions to ask specifically:
- Who are your subprocessors that may touch PHI?
- Do you have BAAs in place with each of them?
- Will you notify us before adding a new subprocessor?
- Do you have a right to audit your subprocessors, and will you share the results if we ask?
Model training on client data
A separate question from HIPAA, and equally important: does the vendor train its models on your client data?
For most firms the required answer is "no," and it should be in writing. A vendor that trains on client data is using confidential information for its own product development, which creates a confidentiality problem under professional conduct rules independent of any HIPAA issue.
Ask the question precisely, because the answer can be evasive:
- "Do you train your models on data we upload?"
- "Do you train on aggregated or de-identified data derived from our uploads?"
- "Do you allow your model provider to train on data we send through your tool?"
- "Can we opt out, and is the opt-out the default or an action we must take?"
An opt-out that requires action on your part is materially different from a default of no training. Get the default in writing.
Data retention and deletion
Where the data lives, how long it is kept, and whether it can be deleted are contractual questions, not technical ones. Ask before signing:
- Where is the data stored? Which jurisdiction, and does that create any cross-border transfer issue?
- How long is it retained? By default, and can you configure it?
- What happens on termination? Can you export everything and confirm deletion? What is the timeframe?
- Are backups included in deletion? Many vendors delete from the primary store but retain backups for months. Ask.
- Who can access it internally? Vendor employees, support staff, engineers debugging an issue — under what controls?
ABA Formal Opinion 512 and state bars
ABA Formal Opinion 512 provides guidance on lawyers' use of generative AI and sets out duties around competence, confidentiality, communication, and fees. For the vendor-selection process, three of those duties bear directly on the checklist above:
- Competence requires understanding the tool's data handling before you use it, not after a problem arises.
- Confidentiality requires that client information is protected to the standard the rules require — which is why BAAs and no-training clauses matter.
- Communication requires clients to understand material aspects of their representation, which may include the use of AI tools where it affects their case.
National guidance is a floor, not a ceiling. Several state bars have issued or are developing their own AI guidance, and some are more specific than the ABA opinion. Check your own jurisdiction's current position before finalising a vendor policy.
For the workflow and supervision side of AI adoption, see our guide to how agentic AI is changing plaintiff law firm workflows.
Pre-contract checklist
Before signing any AI legal tool contract
- Vendor will sign a BAA covering all PHI the tool will touch
- BAA contains a subcontractor flow-down clause
- Vendor can list all subprocessors that may touch PHI
- Vendor confirms BAAs are in place with each subprocessor
- Current SOC 2 Type II report provided, audit period within 12 months
- SOC 2 report covers confidentiality and privacy, not only security
- Exceptions section of the SOC 2 report reviewed
- Written confirmation that models are not trained on your data (default, not opt-out)
- Written confirmation that the model provider does not train on data sent through the tool
- Data location and retention terms documented
- Deletion on termination confirmed, including backups
- Breach notification timeframe specified in numbers
- Firm has documented how its use aligns with ABA Formal Opinion 512
- State bar guidance for the firm's jurisdiction checked
- Internal policy exists for what may be uploaded and by whom
Frequently asked questions
Does HIPAA apply to personal injury law firms?
A law firm is not a covered entity, but it generally acts as a business associate of the healthcare providers that release medical records in a case. That makes any AI vendor processing those records a downstream business associate, and the chain of BAAs must be intact.
Is a BAA enough to make an AI tool HIPAA compliant?
A BAA is necessary but not sufficient. It establishes the legal relationship, but you also need to confirm the vendor has actual safeguards in place, that its subprocessors are covered, and that its data handling matches what the BAA says. The BAA is the gate, not the whole compliance posture.
What is the difference between SOC 2 Type I and Type II?
Type I reports on whether controls are suitably designed at a single point in time. Type II reports on whether those controls operated effectively over an audit period, typically 6–12 months. For vendor due diligence, Type II is what you want.
Does a SOC 2 report prove HIPAA compliance?
No. SOC 2 is a voluntary AICPA audit standard, not a HIPAA certification. It can support your compliance assessment, but HIPAA compliance also requires a BAA, subprocessor coverage, and appropriate safeguards specific to PHI handling.
What is the subprocessor problem in legal AI?
Most AI tools rely on third-party foundation model providers such as OpenAI or Anthropic. When client medical records are processed, they pass through that provider's infrastructure, so the provider must also be covered by a BAA. If the BAA you sign lacks a subcontractor flow-down clause, there is a gap in the chain.
Can an AI vendor train its model on my client's data?
It should not, and you should get written confirmation that it does not. Ask specifically about whether the default is no training or whether you must opt out, and whether the model provider also trains on data sent through the tool.
What should I do if a vendor won't sign a BAA?
Do not use the tool with protected health information. There is no workaround. If the tool is useful for non-PHI work only, you can consider using it under strict usage controls, but the burden is on your firm to ensure no PHI is ever uploaded.
How often should we re-check vendor compliance?
Annually at minimum, and whenever the vendor notifies you of a material change — new subprocessor, new feature that changes data flow, or a change in their BAA terms. Put the review date in your vendor register so it does not get forgotten.
Related reading on Dedon Tech: how agentic AI is changing plaintiff law firm workflows · best AI legal software for US personal injury firms · full site map
0 Comments: