For attorneys already concerned about AI mistakes and sanctions, the answer does not have to be a firmwide ban. A more useful starting point is a tightly defined task, limited information access, and a review process that keeps the lawyer responsible for the result. Local LLMs can help control where model processing occurs. They do not make every inbox use appropriate or every generated answer reliable.
An engagement letter does not describe everything in the mailbox
In a recent public discussion among law-firm practitioners, a poster considering AI access to email raised a practical concern: messages from prospective clients may arrive before an engagement agreement is signed. The thread illustrates a question to investigate, rather than establishing what any particular product or jurisdiction permits.
Under ABA Model Rule 1.18, duties concerning information from a prospective client can apply even when no representation follows. The rule's commentary also explains that whether a communication constitutes a consultation depends on the circumstances. Every unsolicited email does not automatically establish prospective-client status.
A firm's assessment should therefore begin with what the proposed system can see. Which mailboxes, folders, attachments, and shared accounts are included? Does the connection expose historical messages as well as new ones? Could it retrieve a matter the employee using it is not authorized to access?
Use the professional rules and guidance applicable to the firm's jurisdiction. The ABA's model rules provide a reference point; they are not a substitute for that analysis.
Define the inbox task before granting access
"Help us with email" leaves too many decisions unresolved. A more specific starting point might be: summarize a selected group of messages for the attorney responsible for that matter, with a link to each source.
That task differs from replying to clients, deleting messages, or adding deadlines to a calendar. Treat each additional ability as a separate implementation decision. The convenience of a single connection does not mean the firm needs every permission it offers.
The security concern is concrete. OWASP's excessive-agency guidance describes how unnecessary tool access and permissions can increase the damage from incorrect or manipulated model output. Its recommendations include limiting functions and enforcing access in connected systems. For an inbox pilot, ask the provider to demonstrate exactly what the assistant can read and change.
An instruction saying "never send email" is less reassuring than a setup in which the assistant has no sending capability. Similarly, a folder filter in a user interface deserves scrutiny if the underlying connection can still retrieve the rest of the mailbox.
Follow the message through the entire system
Local processing can remove the need to send selected message content to an external model service when the deployment is designed that way. This can give a firm more control over that part of the information path.
Map the rest as well. The mailbox may remain with a cloud email provider. Attachments may pass through document-conversion software. Logs, search indexes, backups, remote support, and optional integrations may create additional copies or access routes. Ask where each component runs, what it stores, and who can reach it.
Include deletion and retention in the discussion. Removing an email from the original mailbox may not remove a copy from an index or backup. Ask the implementation team to explain how those copies are handled, rather than assuming one delete command covers the whole system.
ABA Formal Opinion 512 calls for evaluating disclosure risks and understanding relevant tool terms. Its confidentiality discussion includes access by people inside the firm as well as outside it. A locally running system still needs appropriate matter-level access and administrative controls.
Keep suggested dates separate from verified deadlines
Consider a hypothetical pilot in which an assistant reads an approved set of matter emails and proposes a daily list of items needing attention. One message mentions a hearing date. Another says the parties are discussing an extension. A third attaches an order.
The useful output identifies the source, reports what each message says, and flags the uncertainty. It should preserve the distinction between a requested extension and one that has actually been granted. A confident summary is not evidence that the underlying event occurred.
Keep the pilot's proposed dates separate from the firm's authoritative docket. Have the responsible attorney or authorized staff member verify the source, governing requirements, and appropriate calendar entry through the established process. Do not let a summary silently become the only place a deadline exists.
Opinion 512 also addresses competence and appropriate independent verification. These responsibilities remain with the lawyer. Running a model locally does not prevent fabricated citations, inaccurate quotations, omitted qualifications, or mistaken dates. Sanctions concerns should lead to specific checking practices, including opening and verifying authorities used in court submissions.
Make the pilot small enough to examine
Begin testing with fabricated messages that reflect the firm's real work without exposing client information. Include a changed instruction, contradictory dates, an attachment the system cannot read, and a message containing directions the assistant should not obey. An email is material to analyze; it should not be allowed to rewrite the assistant's operating rules.
Check omissions as well as errors. A summary can contain only accurate statements and still leave out the most consequential message. Compare the output against the full test set, record corrections, and decide what would require stopping the pilot.
Before introducing approved live information, assign responsibility for reviewing outputs, maintaining access, and handling failures. Staff need a usable procedure for uncertain answers, not merely a warning that AI can be wrong. Expand only after the firm understands the results and the remaining work.
Discuss Onbox through a specific workflow
Onbox is David AI Systems' locally deployed AI offering designed for attorneys. A useful evaluation starts with the task the firm wants help completing and the information it is prepared to make available.
Ask David AI Systems to map that task's processing locations, permissions, retained copies, and review steps. Confirm which email connections and controls a proposed deployment would provide. Local architecture can address an important adoption concern; privilege and professional compliance still depend on the circumstances, applicable rules, and actual use.
Bring a sample workflow using fabricated information. It gives the firm something concrete to evaluate before granting access to a real inbox.