Confidentiality and Privileged Email With an AI Assistant

When you ask whether an attorney client privilege AI email tool arrangement is defensible, the honest answer is: not by itself, but yes if you set it up wrong. Privilege turns on who else you let see the confidential communication and on the reasonable steps you took to keep it confidential. A modern AI email assistant introduces a vendor and, usually, one or more model providers into that path — which is a solvable problem, not a disqualifying one, provided you do the checking your rules of professional conduct require.

This is a decision framework for lawyers, in-house counsel, and other professionals under confidentiality duties. It is not legal advice. Ethics guidance on generative AI for lawyers is evolving quickly and varies by jurisdiction — run the specifics past your ethics counsel or your firm's general counsel before you route privileged mail through any AI tool.

The short answer#

Using an AI email assistant does not, on its own, waive attorney-client privilege in the United States or breach confidentiality under ABA Model Rule 1.6. Rule 1.6(c) requires "reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client," and the Comments to Rule 1.6 explicitly recognise that lawyers may use non-lawyer assistance and outside vendors, provided they exercise reasonable care in doing so.

The privilege question is analytically distinct from the ethics question, and both have to clear. Privilege can be lost when a confidential communication is disclosed to a third party in a way that destroys the expectation of confidentiality. Courts have long tolerated typing services, translators, cloud email hosts, and outside e-discovery vendors under the theory that the third party is engaged to facilitate the legal representation and is bound to keep it confidential. Whether an AI vendor fits the same theory depends on how you engaged it — the terms, the controls, and what you told the client.

Confidentiality is broader than privilege. Model Rule 1.6 protects "information relating to the representation," whether or not the specific communication would qualify for privilege. So even a routine scheduling email is inside the duty. A vendor that reserves the right to train on your mail can be an ethics problem even when nothing in that mail would meet the privilege test.

Criteria that actually matter#

Not every AI email tool creates the same exposure, and the questions that separate a defensible arrangement from an unforced error are narrow. These are the ones to work through before you connect a mailbox that receives privileged mail.

• Training on your mail. The strongest position is a contractual no: the vendor does not train models on your email, and its model providers are held to zero-retention terms. A vendor that trains on customer mail is a hard sell for privileged work.
• Vendor confidentiality obligations. The Comment to Model Rule 1.6 assumes third parties are under an enforceable duty to protect client information. A published data processing agreement and a confidentiality clause in the master contract are the artefacts your ethics committee will ask for.
• Where content is processed and stored. Cloud model or on-device; encrypted at rest; in which jurisdiction. Under GDPR Article 28 the vendor is a processor bound by your instructions, and any sub-processor — the model provider included — must be named and bound to the same terms.
• Access controls at the vendor. Envelope encryption of OAuth tokens and bring-your-own-key credentials; least-privilege OAuth scopes; audit logging of who at the vendor can see what.
• BYOK for the model call. Some tools let you supply your own model-provider API key so requests run against your account under your provider agreement, rather than the vendor's shared one. That narrows the confidentiality perimeter further.
• Human-in-the-loop actions. A Copilot-style mode with approval-before-send, an undo window, and an audit log means a hallucinated or hijacked instruction cannot leave your outbox unsupervised.
• Segregation of privileged threads. Whether you can route specific senders, matters, or labels to a lens the AI does not touch or does not draft into — so the most sensitive material can be handled manually while everything else runs on rails.

Scoring table#

Rank each candidate against the criteria below. Any "high" weight scored as fail is a reason to eliminate the tool for privileged work — not to negotiate around it. Confidentiality duties and third party vendors are one of the older bodies of legal ethics; the framework is not new, the underlying software is.

One dimension the scoring table cannot measure is what your bar association has actually said about generative AI in the last twelve months. Read that first — the ABA's 2024 formal opinion on generative AI is one input, but your state's ethics committee has the final word, and several have gone further.

Worked example: a solo litigator on Google Workspace#

Consider a solo litigator in a US state whose ethics rules track the ABA Model Rules. She runs her practice from Google Workspace and needs an AI assistant to triage roughly a hundred inbound messages a day, draft standard replies, and surface the ones only she can write. About one message in ten is privileged — client correspondence, work-product notes from co-counsel, matters currently under litigation hold.

Apply the criteria and the choice narrows fast. A vendor with permissive training rights fails at criterion one and is out. A browser overlay that only works inside Gmail is fine today but strands her if the referring client asks her to move to their tenant. What survives is a no-training, multi-provider AI-native client that runs in Copilot mode by default, provides a DPA, and lets her tag privileged senders to a label the AI does not draft into.

Two things sit alongside the tool choice. She briefs her ethics counsel on the arrangement, and where the engagement letter's scope calls for it, informs the client — segregating privileged mail from AI is a control she can point to, not a claim she has to argue. Some jurisdictions expect that disclosure in writing at engagement; a short paragraph naming the categories of tasks and the training-off posture is a defensible starting point. Have counsel adapt the wording.

Red flags#

Any one of these is a reason to keep asking questions. Two together is usually a reason to look elsewhere for privileged work.

• No DPA and no confidentiality clause covering the vendor or its sub-processors. You cannot answer your client about who touched their file if you cannot answer it for yourself.
• Terms that reserve a right to train, aggregate, or otherwise "use your data to improve the service" without an opt-out you can rely on. Silence on training is not a no.
• No approval step on outbound actions and no undo window — the agent can send in your name unsupervised.
• Password login instead of OAuth, or OAuth scopes far broader than the tool actually needs. Both widen the blast radius on breach.
• No published sub-processor list. Model providers count; if they are not named, you cannot vet them.
• No way to segregate matters, senders, or labels from the AI. A one-size-fits-all agent has no fail-safe for the threads you should not have automated.
• Silence on prompt-injection handling and on how the agent distinguishes an inbound email from a command.
• Vague retention: "as long as necessary" with no stated window and no deletion path.

What we'd pick, and why (honest)#

Three finalists are worth taking seriously for lawyers and other professionals bound by confidentiality duties. We build AI Emaily, so treat this as an interested opinion and verify the underlying facts against our privacy model and security pages before you rely on them.

AI Emaily is the pick when you need an AI that actually acts on your mail across more than one provider, without giving up the controls that make that acceptable for confidential work. It connects to Gmail, Outlook, iCloud, IMAP and others over least-privilege OAuth, does not train on your mail, and routes model calls through a gateway under zero-retention terms with the model providers. OAuth tokens and any bring-your-own-key credentials are envelope-encrypted and never logged in plain text; message bodies live in encrypted storage referenced by ID. The agent treats every inbound email as untrusted input, so a hidden instruction cannot make it act. Copilot mode is the default for anything outbound — nothing is sent until you approve it, every action lands in an audit log, and there is an undo window on send. You can carve privileged senders or matters into a label the agent does not draft into. Its writing voice comes from a Context brain you configure and per-client profiles you define, not from scraping your sent mail. Packaging is a 7-day free trial on Pro or Autopilot (card required, $0 if cancelled before day seven), not a permanent free tier — see the pricing page for the current numbers. We build AI Emaily.

Where we would send you elsewhere. If your bar is that stored mail must be end-to-end, zero-access encrypted from the mail server outward, Proton Mail's built-in Scribe assistant is a stronger match — Scribe runs locally on your device or on Proton's no-logs servers, and zero-access encryption means the model cannot see stored content by design. If you want a native macOS client that keeps mail on your device with little or no cloud AI, Apple Mail or Mimestream will beat us on memory footprint and a complete offline archive — our desktop app is a genuine downloadable app, but it is an Electron shell around the web interface, Apple-Silicon-only, and not a full local archive. And if a matter is under an active litigation hold with strict e-discovery obligations, do not use it to learn the platform — segregate that matter to a manually-handled inbox until you have your firm's written e-discovery guidance for AI-drafted content.

In short: AI Emaily is right for a solo or small-firm practice that wants AI on its inbox with the controls a Rule 1.6 conversation depends on. It is the wrong pick if your bar is end-to-end encryption of everything at rest, or a fully local, native binary — one of the other two is the better answer there, and this framework is worth more than any specific vendor pick.