The state bar opinions on AI are arriving fast, and the pattern is clear: attorneys have a duty of competence that includes understanding the technology they use, and a duty of confidentiality that extends fully to client data processed by third-party AI systems.
The question isn't whether those duties apply to your AI tools. They do. The question is whether the way you've deployed those tools actually satisfies them.
Most firms that have "reviewed" this question haven't gone far enough.
What Zero Data Retention Actually Means
When you send a document to an AI API with Zero Data Retention (ZDR) enabled, the provider contractually commits to not storing your data on their servers after the request completes. The document is processed in memory, the result is returned, and nothing persists.
This is meaningfully different from the default behavior of most AI services, where inputs and outputs are retained for model training, abuse monitoring, and debugging - often for 30 days or more. If you're sending client medical records to an AI tool without checking the data retention policy, your client's information may be sitting on a third-party server right now.
ZDR addresses the retention problem. It does not address the transmission problem.
The Part People Miss
Zero Data Retention means the data isn't stored after the request. It says nothing about:
Who has access during processing. Cloud AI infrastructure is shared. Your request is processed on hardware that also processes other customers' requests. In practice, this is low-risk - providers have strong access controls - but "low risk" is not the same as "zero risk," and you should be honest with yourself about that distinction.
Where data travels before reaching the API. If your documents pass through your practice management software, then a third-party integration layer, then an AI API, the ZDR guarantee only covers the last hop. Every intermediate system has its own data handling policy.
What happens in a breach. ZDR means the provider doesn't retain your data, not that they're breach-proof. Data in transit and data in memory are both attack surfaces.
Logs. Most providers maintain some level of request logging for security purposes even with ZDR enabled. Read the specific terms, not just the marketing language.
The On-Premises Option
For firms that handle particularly sensitive matters - immigration cases with undocumented clients, high-stakes PI litigation, mass tort work - on-premises local LLM deployment is the only configuration that fully eliminates third-party data exposure.
Running a model like Llama 3 or Mistral locally means client data never leaves your infrastructure. Processing happens on hardware you control, behind your security perimeter, with no third-party access at any point in the workflow.
The tradeoff is real: local models are not as capable as frontier cloud models for complex reasoning tasks. For document summarization, intake triage, and template generation - the workhorses of a PI practice - the quality gap is manageable. For nuanced legal research and complex analytical tasks, it may not be.
The right answer is often a hybrid: local models for anything involving raw client data, cloud APIs with ZDR for anonymized or synthesized tasks.
How to Actually Evaluate an AI Vendor
When you're evaluating an AI tool for your firm, these are the specific questions that matter for data privacy:
Does the vendor offer a Data Processing Agreement (DPA) that covers attorney-client privilege? A generic privacy policy is not sufficient. You need a contractual commitment that specifically acknowledges the confidential nature of legal data.
What is the data residency policy? For multi-national work, where data is stored and processed geographically matters. Some jurisdictions require that data not leave their borders.
What happens if the vendor is acquired? Data processing agreements should survive M&A activity, but many don't. Check the assignability clauses.
Has the vendor received a request from law enforcement for client data? Most have a policy around this, and many publish transparency reports. You should know what that policy is before sending your clients' files through their system.
What is the incident response policy? If a breach occurs, how quickly are you notified? What forensic information will the vendor share?
The Ethics Opinion Landscape
As of early 2026, over 30 state bar associations and the ABA have issued formal guidance or ethics opinions touching on AI use in legal practice. The consensus positions:
- Attorneys must maintain competence with respect to the technology they deploy, including understanding data handling implications
- Client confidentiality obligations apply fully to third-party AI tools
- Attorneys cannot contract away their confidentiality duties - a vendor's ZDR policy doesn't absolve you of your own obligations
- Supervisory duties extend to AI tools used by nonlawyer staff
The practical implication: you can't just buy an AI tool and delegate the ethics question to IT. The partner whose name is on the door is responsible for understanding how that tool handles client data.
A Framework for Implementation
Getting AI deployed ethically isn't complicated, but it does require intentionality:
- Audit your current AI usage - including tools that staff have adopted informally. You may already have client data flowing through systems you haven't evaluated.
- Classify your data - distinguish between data that's safe to process via cloud AI (anonymized, non-confidential) and data that requires ZDR or on-premises handling.
- Get the paperwork in order - DPA, BAA if applicable, review of TOS for any AI tool that touches client data.
- Build the policy first - document what's permitted, what's prohibited, and what requires partner approval before staff deploy AI tools.
The firms that get this right won't just avoid disciplinary risk. They'll build client trust that becomes a competitive advantage as the AI ethics landscape tightens.