TL;DR: Client confidentiality is an ethical duty, and under ABA Model Rule 1.6 you must make reasonable efforts to protect it - including when you use AI. This guide turns that duty into a practical security checklist for evaluating any legal AI vendor: encryption, a no-training guarantee, hosting and data residency, access controls, audit logging, retention and deletion, sub-processors, and independent certifications. Run it before you upload a single client file.
Every useful legal AI tool has to read your documents, and your documents are full of privileged, confidential client information. That is the tension at the heart of adopting legal AI: the same upload that lets a tool research, review, or draft also hands a vendor some of the most sensitive material you hold. Confidentiality is not an IT footnote to that decision - it is a core professional obligation, and the bar holds you, not your vendor, responsible for getting it right. This guide converts that obligation into a concrete checklist you can run against any provider before you trust it with a matter.
Why is client confidentiality now a security question?
For most of the profession's history, protecting client confidences meant locked filing cabinets, careful conversations, and sealed envelopes. The duty has not changed, but the surface area has exploded. Client data now lives in cloud platforms, moves across networks, and - increasingly - passes through AI vendors that read, index, and process it. Each of those steps is a place where confidential material can be exposed, copied, or put to an unauthorized use.
The consequences of getting this wrong are not abstract. An unauthorized disclosure can harm a client, damage privilege, invite a malpractice claim, and trigger professional discipline. That is why evaluating a vendor's security is now part of discharging the duty of confidentiality itself, not a separate technical chore you can delegate and forget. It is also a competence issue: a lawyer who does not understand, at least in outline, how a tool handles client data is not in a position to judge whether using it is reasonable. The good news is that the questions you need to ask are finite and answerable, and the rest of this guide lays them out. For the privilege dimension specifically, see our deeper treatment of attorney-client privilege and AI.
What does ABA Model Rule 1.6 actually require?
The anchor in the United States is ABA Model Rule 1.6(c), which provides that a lawyer shall make reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client. Two words carry the weight: reasonable efforts. The rule does not demand perfect security or ban new technology; it demands a sensible, risk-weighted process. The official comments identify the factors that make an effort reasonable - the sensitivity of the information, the likelihood of disclosure if additional safeguards are not used, and the cost, difficulty, and effect on the representation of employing those safeguards.
Competence reinforces the point. The ABA's Model Rule 1.1 on competence, through its widely adopted technology comment, expects lawyers to keep abreast of the benefits and risks associated with relevant technology. Together, Rules 1.1 and 1.6 - both part of the ABA Model Rules of Professional Conduct, available through the American Bar Association - mean you cannot outsource the judgment about whether a tool is safe enough; you have to make it, and you have to be able to show how you made it. Frameworks built for exactly this kind of risk assessment help. The NIST AI Risk Management Framework offers a structured vocabulary for evaluating an AI system's risks that maps neatly onto the questions a careful lawyer should already be asking. None of this is US-only in spirit: data-protection regimes such as the GDPR and India's DPDP Act layer additional, often stricter, obligations on top, as we cover in our guide to AI regulatory compliance with GDPR and HIPAA.
What belongs on a legal AI security checklist?
The phrase reasonable efforts is only useful once you translate it into specific questions a vendor must answer. The checklist below does exactly that. Treat it as a template for a vendor security review: for each control, there is a question to ask and a reason it matters. If a provider cannot answer plainly, that is itself a finding.
| Control | What to ask the vendor | Why it matters |
|---|---|---|
| Encryption | Is data encrypted in transit and at rest, and how are encryption keys managed? | Protects material on the network and on disk if storage is ever compromised. |
| Training on your data | Do you train or fine-tune any model on my uploads, prompts, or outputs? | Training on client data risks leakage into other customers' results and exceeds the client's authorization. |
| Hosting and residency | Which cloud hosts the data, in which regions, and can a region be pinned? | Determines applicable law, latency, and whether residency promises to clients can be kept. |
| Sub-processors | Which third parties - model providers, infrastructure - touch the data, and under what terms? | A vendor is only as confidential as its weakest sub-processor. |
| Access controls | Who inside the vendor can access my data, and do I get role-based access on my side? | Enforces need-to-know and limits both internal and internal-to-your-firm exposure. |
| Audit logging | Is there a tamper-evident log of who opened, ran, or exported each file? | Lets you reconstruct access and demonstrate the diligence the rules expect. |
| Retention and deletion | How long is data kept, and can I delete a matter on demand? | Confidential data you no longer need is pure, avoidable risk. |
| Certifications | Do you hold SOC 2 or ISO 27001, and will you share the report under NDA? | Independent assurance beats a self-assertion on a marketing page. |
The sections that follow unpack the clusters that cause the most confusion, so you know what a good answer sounds like rather than just collecting yes-or-no responses.
Encryption in transit and at rest
Encryption is table stakes, but the detail matters. Data in transit should travel over modern transport-layer security so that material cannot be read as it crosses the network. Data at rest should be encrypted on disk so that a stolen drive or a misconfigured bucket does not become a breach. Ask about both, and ask how keys are managed - who holds them, how they are rotated, and whether the vendor can technically read your content. Beware marketing shorthand like bank-grade encryption that names no standard; a confident vendor will describe its approach in specifics without hesitation.
A no-training-on-your-data guarantee
This is the single most important question on the list. If a vendor trains or fine-tunes its models on your uploads or prompts, fragments of one client's confidential material can surface in another customer's output, and you have put privileged information to a use your client never authorized. The protection you want is contractual and unambiguous - a written commitment that your documents, prompts, and results are never used to train or improve models - not a settings toggle that someone might forget to switch. Get it in the agreement, not just the FAQ. Judicio does not train on your data, which is the baseline any tool touching privileged material should meet.
Hosting, data residency, and sub-processors
Where your data physically lives determines which laws apply to it and whether you can honor residency commitments to clients - a real concern for cross-border matters and for regimes like the GDPR and India's DPDP Act. Ask which cloud provider hosts the service, in which regions, and whether you can pin data to a particular geography. Just as important is the chain behind the vendor: the model providers and infrastructure partners that also process your data. Ask for the list of sub-processors and the terms that bind them, because your confidentiality is only as strong as the weakest link in that chain. Judicio hosts on Google Cloud Platform, and our piece on regulatory compliance covers how residency intersects with these regimes.
Access controls, audit logging, retention, and deletion
Confidentiality is also about who can see a file and what happens to it over time. On your side, look for role-based access so that only the right people in your firm can open a matter. On the vendor side, ask who internally can access customer data and under what controls. Insist on an audit trail - a record of who opened, ran, exported, or deleted each file - because that log is how you reconstruct events and demonstrate diligence if you are ever questioned. Finally, ask about retention and deletion: how long data is kept by default, and whether you can delete a matter on demand. Sound data hygiene is its own safeguard, a theme we expand on in our guide to legal document management best practices. Judicio provides role-based access with a full audit trail.
Certifications and independent assurance
Self-reported security is worth little; independent verification is worth a great deal. Attestations such as SOC 2 Type II - which tests whether controls operated effectively over a period, not merely that they were designed at a single point in time - or an ISO 27001 certification are strong evidence that a vendor's practices are real. Penetration-test summaries add to the picture. Ask whether the vendor will share its report under NDA. Remember that certifications are a floor, not a ceiling: a SOC 2 report does not by itself answer the training question or pin your data to a region, so use it alongside the direct questions above rather than as a substitute for them.
How do you actually run the vendor review?
A checklist is only as good as the process around it. Start by getting answers in writing - a data-processing agreement, a security whitepaper, and the sub-processor list - rather than relying on a sales call. Involve the right people: in a larger firm that may mean IT or a security lead, while a solo practitioner can still work methodically through the list. Pilot the tool with non-sensitive or synthetic material before you put a live, privileged matter into it, so you can judge behavior without taking on risk. Above all, document what you did and why, because reasonable efforts is assessed on your process, not on hindsight. A short memo recording the questions you asked, the answers you received, and your conclusion is exactly the kind of record that shows diligence. For firms formalizing this across the practice, our guide to AI governance for law firms turns these one-off reviews into a repeatable policy.
What red flags should make you walk away?
Some answers should end the conversation. Be wary of a vendor that speaks only in vague reassurances and cannot name a standard or describe a control. Treat a refusal to put the no-training commitment in writing as disqualifying for privileged work. Walk away if there is no audit trail, no named sub-processor list, or no way to delete your data. Read the terms of service closely: consumer-grade agreements sometimes grant the provider broad rights to use uploaded content, which is incompatible with the duty of confidentiality. And be skeptical of any tool that cannot tell you where your data is stored. None of these red flags is about sophistication or price - they are about whether the vendor takes your obligations as seriously as you must.
How does Judicio approach security and confidentiality?
Judicio is built on the assumption that the material you upload is privileged and must stay that way. It does not train models on your data, hosts on Google Cloud Platform, and provides role-based access together with a full audit trail, so you can see exactly who did what with each file. The platform's structure reinforces confidentiality: one upload into the File Library feeds every tool, so you control where a document goes rather than scattering copies across separate products. Because Legal Research and Document Review cite the exact page and quoted passage for every finding - with deterministic labels and web sources archived as permanent PDFs - you can also prove the provenance of any output through an exportable evidence pack. That provenance is a confidentiality tool in its own right: you always know what the system read and where each conclusion came from. For the privilege and governance dimensions, pair this with attorney-client privilege and AI and AI governance for law firms. Judicio supports your duty of confidentiality; it does not discharge it, and its outputs are not legal advice.
How do you get started?
The best way to evaluate a tool's security is to run the checklist against it and then test it on your own terms. Judicio offers a 7-day free trial with 500 credits and no credit card required, so you can pilot research, review, drafting, timelines, and translation on non-sensitive material and confirm the data practices match your duty of confidentiality before you commit. Professional plans are $200 per month for 5,000 credits. If you want to walk through the security model with your team or IT, get in touch.
This article is general information only and is not legal advice; AI outputs are not legal advice, and a qualified lawyer remains responsible for every matter.