There is one architecture that makes the confidentiality analysis trivial: the client’s data never leaves your machine.
No provider terms to read. No question about whether inputs are retained or used for training. No third-party subpoena target. No vendor breach that becomes your breach. The answer to “where did the client’s information go” is “nowhere,” and every lawyer understands that answer immediately.
That is a genuinely attractive property, and it is why local models deserve a serious look rather than the dismissal they usually get. It is also not free, and the people selling local-first solutions tend to be quiet about the costs. Here is the honest accounting.
What “local” actually means
A model runs on hardware. Normally that hardware belongs to a provider and you reach it over an API. Running locally means the model’s weights sit on your disk and the computation happens on your machine.
Two things make this practical now that were not a few years ago. Open-weight models have gotten very good — not frontier-good, but good enough for many defined tasks. And quantization — storing the model’s numbers at reduced precision, typically 4 or 8 bits instead of 16 — cuts memory requirements roughly in half or better with modest quality loss. A model that would have needed a server rack now fits on a well-specified laptop.
On Apple silicon there is a specific structural advantage: unified memory. The CPU and GPU share one pool, so a Mac with 64 or 128 GB can hold a model that would require an expensive discrete GPU on a PC. For a small firm this matters — the hardware is a laptop you may already be buying rather than a server you have to house, cool, and secure.
The honest performance picture
This is where local-first advocacy usually oversells, so let me be direct about the shape of it rather than quoting benchmark numbers that will be stale in six months.
Local models are meaningfully behind frontier models on the hardest reasoning. Multi-step legal analysis, holding a long argument together, catching the subtle problem in a complex fact pattern — the gap is real and it is not closing as fast as the enthusiasts suggest. If your task is “read this complicated record and tell me what I’m missing,” you want the best model available, and it is not running on your laptop.
They are surprisingly close on bounded, mechanical tasks. Extraction, classification, summarization of a single document, reformatting, tagging, first-pass triage. The gap on this class of work is much smaller and often does not matter, because the task has a right answer that a competent model finds.
They are slower, though usually fast enough. Expect to wait, particularly on long inputs.
They do not know today’s law, and this is the constraint lawyers underestimate. A model’s training data has a cutoff, and open-weight releases often trail. This is fine — because, as I have argued repeatedly in this section, you should never be asking a model to recall a rule anyway. You fetch the rule and hand it over. A local model reading rule text you supplied is on exactly the same footing as a frontier one. The workflow that protects you from stale law also happens to neutralize the local model’s biggest weakness.
The hybrid architecture, which is usually the answer
The framing of “local versus cloud” is a false binary. The useful question is which work goes where, and the sorting principle is straightforward:
Local for high-volume, bounded, confidential work.
- Classifying and triaging inbound documents
- Extracting dates, parties, and amounts from filings
- OCR post-processing and cleanup
- Tagging and routing
- First-pass relevance screening over a production
- Anything that runs on a schedule over the whole client file
Cloud for hard reasoning on a curated slice.
- Substantive analysis of a specific problem
- Drafting that requires real judgment
- Anything where the quality gap actually changes the output
Notice what this buys beyond confidentiality. The bulk of the data — the ten thousand pages — never leaves the building, because bulk processing is exactly the bounded work local models do well. What goes to a provider is the twelve documents that matter, selected by a local pass. You have reduced the exposure surface by three orders of magnitude while keeping frontier quality where it changes the answer.
That is a better confidentiality posture than either extreme, and it happens to be cheaper than sending everything to an API.
There is also a resilience argument I did not anticipate until it mattered. A local pipeline keeps working when your internet is down, when a provider has an outage, when an API deprecates a model you depended on, and when a vendor changes its terms. For scheduled work that the practice relies on daily, that is worth something.
What it actually costs
Hardware. A Mac with enough unified memory to run useful models comfortably is a real expense — meaningfully more than the base configuration, and the memory is not upgradeable later, so you buy it up front or not at all. Against that: it is a one-time capital cost and it is a machine you were buying anyway.
Setup and maintenance. This is the cost people underestimate. Runtimes update, models are superseded, quantization formats change, something breaks after an OS update. Budget real attention, not a weekend. If nobody in your firm enjoys this, that is a legitimate reason not to do it.
Quality, on the hard tasks. Discussed above. Do not pay this cost on work where it matters.
Your time evaluating it. You will not know whether a local model is good enough for your extraction task without measuring, which means the evaluation harness from earlier in this section is a prerequisite, not a follow-up. “It seems fine” is not a basis for routing client work.
The confidentiality argument, stated precisely
It is worth being careful here, because local models are sometimes presented as solving the confidentiality problem, and they do not.
What Rule 1.6(c) requires is “reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client.” Local processing eliminates one disclosure vector — transmission to a provider — and eliminates it completely, which is a real and substantial thing.
It does nothing about the others. The laptop can be stolen. The disk can be unencrypted. The backup can sync somewhere careless. The model outputs still land in files that need the same protection as any other work product. A firm running everything locally on an unencrypted machine with no backup discipline has a worse confidentiality posture than one using a cloud provider under a decent contract with full-disk encryption and a locked screen.
Local is a strong answer to one question. It is not an answer to the question.
When I would tell you not to bother
Being honest about the negative case, because I think it applies to most readers:
- If your volume is low. The advantage is concentrated in bulk work. If you process fifteen documents a month, use a cloud provider with good terms and spend the weekend on something else.
- If nobody will maintain it. An unmaintained local pipeline degrades silently and then someone quietly stops using it, which is the worst outcome — you paid the setup cost and get none of the benefit.
- If your provider terms are already good. A contract that forbids training on your inputs and limits retention, plus the minimum-necessary discipline of sending only what the task requires, is a defensible posture. It is not as strong as never transmitting, and it is far from nothing.
- If you would use it as a reason to skip verification. A local model hallucinates exactly as readily as a remote one. Nothing about the hardware changes the need for the citation gate.
Where to start if you do
- Pick one bounded, high-volume task. Document classification is the natural first candidate — it is mechanical, it runs constantly, and errors are cheap and visible.
- Build the eval set first. Thirty labeled examples. Measure the cloud model’s performance as your baseline.
- Run the local model against the same set. Now you have a number, not an impression.
- Route the task locally only if the numbers justify it — and keep the eval so you notice when a model update changes things.
- Expand one task at a time, in the same order: bounded before open-ended, high-volume before occasional.
The discipline is the same as everywhere else in this section. Decide what you are measuring, measure it, and let the measurement pick the architecture. The confidentiality advantage of local processing is real enough that you may want it to win — which is exactly the condition under which you should insist on the number.
General commentary on legal technology. Not legal advice, not ethics advice, and not a hardware recommendation. Performance characteristics of specific models change rapidly; nothing above should be treated as current benchmark data. See Minn. R. Prof. Conduct 1.6 and ABA Formal Opinion 512 (July 29, 2024).