Courts are starting to address AI in protective orders.
Recent commentary on Morgan v. V2X and Jeffries v. Harcros Chemicals describes courts beginning to manage AI use through protective-order provisions. In Morgan, the court required AI tools used to process confidential information to have contractual safeguards, including no use of inputs for model training, restrictions on onward disclosure, and the ability to delete data. In Jeffries, the court reportedly took a broader approach by restricting public AI tools for discovery material more generally.
The practical message is clear: litigators should raise AI at the beginning of discovery, not after confidential material has already been uploaded into an unapproved tool.
The protective order should define AI.
Do not assume everyone means the same thing by “AI.”
The order should define AI broadly enough to include generative AI tools, large language models, AI assistants, summarization tools, automated document analysis tools, AI-enabled legal research systems, agentic AI tools, and any third-party system that uses prompts, uploads, embeddings, or model outputs to process discovery material.
A simple definition:
“AI Tool” means any software, platform, model, service, or feature that uses artificial intelligence, machine learning, large language models, generative AI, natural-language processing, automated reasoning, embeddings, or agentic workflows to summarize, classify, analyze, generate, transform, search, retrieve, or otherwise process information.
The order should prohibit public AI for confidential material.
The safest default:
No party may upload, enter, paste, summarize, transmit, or otherwise disclose Confidential Information or Attorneys’ Eyes Only Information into any public, consumer, or non-approved AI tool.
The order can then allow approved tools if specific conditions are met.
The order should require safeguards, not just brand names.
Technology changes too quickly to write a protective order around one vendor name.
Instead, define required safeguards:
- ✓
No model training on discovery material. - ✓
No onward disclosure except to approved subprocessors bound by confidentiality obligations. - ✓
Deletion rights. - ✓
Data retention limits. - ✓
Encryption in transit and at rest. - ✓
Access controls. - ✓
Audit logs. - ✓
No public sharing. - ✓
No use outside the litigation. - ✓
No autonomous external transmission. - ✓
No use of discovery material to build a generalized model, knowledge base, or dataset. - ✓
Ability to segregate matter data. - ✓
Certification upon deletion or case conclusion.
This approach matches the direction reflected in the Morgan and Jeffries discussion: protective-order terms should be durable and tied to operational controls like retention, training, disclosure, deletion, and segregation.
HIPAA adds another layer.
Many law firms handle medical records, employment health records, insurance records, disability claims, hospital records, or protected health information.
HIPAA may apply directly when a law firm provides legal services to a covered entity or health plan and receives PHI. HHS gives as an example “an attorney whose legal services to a health plan involve access to protected health information.”
When PHI is involved, the AI question becomes more serious:
-
1
Does the AI vendor sign a Business Associate Agreement? -
2
Does the BAA cover the specific product and feature being used? -
3
Are all subprocessors covered? -
4
Are logs, prompts, uploads, embeddings, vector databases, and outputs treated as PHI? -
5
Can the firm meet minimum necessary, access control, audit, retention, and breach-notification obligations?
A BAA is necessary when HIPAA applies, but it is not enough. The firm still needs appropriate technical, administrative, and physical safeguards.
Tools that can support HIPAA-compliant AI workflows
Use the phrase carefully: a tool is not “HIPAA compliant” in isolation. A tool can be HIPAA-eligible, HIPAA-ready, or available under a BAA, but the organization must configure and use it properly.
Examples of AI platforms that can support HIPAA-regulated workflows when the correct contract, BAA, configuration, and controls are in place include:
| Platform Category | Examples | HIPAA Note |
|---|---|---|
| OpenAI healthcare/API path | OpenAI API with BAA; ChatGPT for Healthcare | OpenAI says API use with PHI requires a BAA, and ChatGPT for Healthcare offers BAA support and no training on PHI content. |
| Microsoft/Azure path | Azure OpenAI; Microsoft 365 Copilot in covered enterprise environments | Microsoft says Azure’s BAA is available through its Product Terms/DPA; Microsoft 365 Copilot data is not used to train foundation LLMs. |
| AWS path | Amazon Bedrock | AWS says Bedrock is HIPAA eligible and that customer data is not shared with model providers or used to improve base models. |
| Google Cloud path | Google Cloud / Vertex AI / Gemini through covered Google Cloud services | Google Cloud says customers subject to HIPAA must accept Google’s BAA, and Google Cloud says it does not use customer data to train models without permission or instruction. |
| Anthropic enterprise/API path | HIPAA-ready Claude services under commercial BAA | Anthropic says its BAA does not cover Claude Free, Pro, Max, Team, Workbench, Console, Cowork, or certain beta features. |
The takeaway
Protective orders can no longer ignore AI.
Every litigation team should decide, before discovery begins, whether AI may be used, what tools are approved, what data may be processed, whether prompts and outputs must be logged, whether confidential material can be uploaded, whether AI outputs are retained, and how deletion will be certified.
The modern protective order should answer one question clearly:
Can this discovery material go into that AI tool?
If the answer is unclear, the order is not finished.