Drafting with Local AI: What It Protects, and What It Costs
Most guidance about AI and client confidentiality was written for lawyers generally. Patent practice has a sharper version of the problem, for reasons that are specific to the subject matter: the thing you would paste into a chat window is often an unpublished disclosure whose value depends on it staying unpublished, and whose export is separately regulated.
This page covers what the duties actually say, why the patent context differs, and then what we measured when we ran real drafting work through local open-weight models instead of cloud ones: how the output compares, and how much memory each option needs.
Written for licensed practitioners. Educational, not legal advice: every practitioner makes their own determination about what their duties require in their jurisdiction and on their matters. R&D-grade benchmark results, July 2026. Nothing here assesses patentability, novelty, or non-obviousness.
The Duty Landscape
Three sources bear on sending client technical material to a third-party model.
USPTO Practitioner Guidance
37 CFR 11.106
Practitioners must make reasonable efforts to prevent inadvertent or unauthorized disclosure of information relating to the representation of a client. The Office's AI guidance is explicit that using AI in practice before the USPTO can result in the inadvertent disclosure of highly sensitive technical information to third parties, and that practitioners should be especially vigilant. Two specific hazards it raises: the possibility of material being retained for training, and tools operated outside the United States.
ABA Formal Opinion 512
July 2024
It calls for a fact-specific assessment of the client, the matter, the task, the sensitivity of the information, the safeguards, and the particular tool. Depending on how a system uses or exposes matter information, informed client consent may be required, and generic engagement-letter language may not suffice. Enterprise contractual controls can reduce risk materially, but the label "enterprise" is not itself the analysis.
The Tool's Terms
Read before use, not after
Both sources land in the same place: the obligation is to understand a tool's terms of use, privacy policy, and security posture before client material goes into it.
Why Patent Work Is a Harder Case
Unpublished applications are held in confidence
The USPTO generally must keep them confidential under 35 U.S.C. 122. Before filing, an invention disclosure is protected by the practitioner's confidentiality duties, the client's contractual and trade-secret controls, and other applicable law. The asset being protected is the non-publicness of the disclosure.
Export control reaches technical data, not just shipments
Filing in the United States is treated as including a petition for a foreign filing license under 35 U.S.C. 184. Sending an unpublished disclosure to a model served from infrastructure abroad is a data movement that a practitioner should reason about deliberately, particularly before any US filing exists. Export rules treat release of controlled technology to a foreign person inside the country as an export, so what matters is who can reach the material, not only where the hardware sits.
The material is the crown jewels by construction
A specification is written to enable the invention. It is, deliberately, the most complete technical description of the thing that exists anywhere.
Running inference on the practitioner's own machine removes the routine disclosure of matter information to a model provider. That is a large reduction in risk, and it is worth being precise about what it does not do.
So: no cloud-provider data-processing terms to audit for the inference itself, though model licenses, runtime software, and update channels still warrant review.
The reasonable next question is what that costs in output quality. We measured it.
What We Measured
Ten public parent and continuation patent pairs, specifications from 47 KB to 645 KB. Seventeen drafters: ten open-weight models running locally, seven cloud models (four closed, three open-weight but too large to self-host). Every model got the identical specification and prompt. The revise loop and best-practices pass were switched off, so this isolates raw first-pass drafting.
Scoring is the part that usually goes unexamined, so it was checked first. The scoring model is asked to quote verbatim specification passages supporting each claim, and those quotes are then validated in code as actual substrings of the specification. A model that cannot cite its evidence is disqualified from grading, no matter how confident its scores look. That test eliminated every candidate except one, which matters and is discussed below.
Results: Local versus Frontier
Scores are a 0-100 drafting-quality rubric (written-description support, definiteness, differentiation from the parent claims, claim craft). Scoring was done twice: a single strong scorer, then a four-model, four-vendor panel. The single scorer agreed with the panel on cloud drafts to within about a point, then consistently scored local drafts too high, by up to 17 points. The panel figures below are the ones to rely on.
Treat gaps under about 2 points as no difference for the cloud models, and gaps under about 6 as no difference among the closely bunched local ones.
Leading cloud Best local Tie band (within scoring noise) Not recommended
View full data table
| Drafter | Runs | Weights | Score | Range |
|---|---|---|---|---|
| Claude Opus 5 | cloud | closed | 92 | 88-94 |
| GPT-5.5 | cloud | closed | 90 | 86-93 |
| Claude Opus 4.7 | cloud | closed | 90 | 86-92 |
| Kimi K3 | cloud | open | 89 | 85-93 |
| GLM-5.2 | cloud | open | 87 | 80-89 |
| Kimi K2.5 | cloud | open | 81 | 74-86 |
| DeepSeek V4 | cloud | open | 80 | 76-87 |
| Gemma 4 31B | local, 30 GB | open | 80 | 73-84 |
| Qwen3-Coder 30B | local | open | 67 | 56-78 |
| Gemma 3 27B | local | open | 66 | 32-82 |
| Gemma 4 26B | local, 20 GB | open | 65 | 36-81 |
| Gemma 4 12B | local, 12 GB | open | 63 | 48-78 |
| GPT-OSS 120B | local | open | 55 | 37-72 |
| Llama 4 Scout | local | open | 50 | 22-74 |
| DeepSeek-R1 70B | local | open | 47 | 30-63 |
| Devstral Small 2 24B | local | open | 46 | 18-80 |
Two groups in that table are tied, not ranked. The leading cloud models (92, 90, 90, 89) sit within about a point of each other after accounting for scoring wobble. So do the middle four local models (67, 66, 65, 63): repeated scoring moves them around by more than the gaps between them.
Model selection within the local tier matters more than the local-versus-cloud decision
The spread across local options is 34 points (80 down to 46). The gap from the best local model to the best cloud model is 12. Choosing the wrong local model costs nearly three times as much as choosing local at all.
A 30 GB local model matches a cloud model of 1.6 trillion parameters
Gemma 4 31B scores 80; DeepSeek V4 scores 80. Parameter count is not the axis that decides this task.
Open weights are not the limitation; hosting is
Two of the five highest-scoring models are open-weight (Kimi K3, GLM-5.2). They are simply far too large to run on a workstation. The same open ecosystem produces both the model that ties the top and the one that runs in 30 GB on a laptop.
Read the range column, not just the score
Gemma 4 26B averages 65 but spans 36 to 81 across specifications: on some it drafts acceptably and on others poorly. Gemma 4 31B is both higher and steadier (73 to 84). For work where every specification has to come out usable, consistency matters more than the average.
What the extra points actually buy. Cloud models drafted 15 to 17 claims per specification against 8 to 12 locally, while both produced about the same number of independent claims (around 4). The additional volume is dependent claims: more fallback positions layered under each independent claim. That is a real drafting contribution and it is also the kind of thing a practitioner adds during review.
Claim count is not a quality signal on its own. Llama 4 Scout produced more claims than any other local model and scored second to last. Volume without support is padding, and only the support audit distinguishes them.
What Memory You Need
The constraint is not the model file size. It is the model plus the context window large enough to hold the entire specification, because the whole specification goes into the prompt.
64 GB Machine
About 12 points behind the best cloud models. 30 GB will not fit comfortably on a 32 GB machine once the OS and normal work are accounted for. Slower than the 26B by roughly a factor of four.
32 GB Machine
Handles every specification including the largest. The tradeoff is real: 15 points less quality relative to the 64 GB tier, and results vary more from specification to specification.
16 GB Machine
Gemma 4 12B fits in 12 GB but its quality is uneven across specifications, and the smaller models cannot hold a real specification at all.
What Local Cannot Currently Do
The pipeline can also score a draft: check every claim against the specification and report which limitations are supported and which are not. That scoring step could not be made to work locally.
The reason is worth stating because it is not obvious. Asked to quote the specification passages supporting each claim, local models produced quotes that were verbatim and real but taken from the claims being graded rather than from the specification. In one run, 81 of 81 quotes came from the wrong document. The claims were being offered as evidence for themselves.
One cloud model
33 of 33 cited quotes found in the specification. The only model that passed.
Best local model
Most quotes were real strings from the wrong document. Scale does not help: 400B+ models scored the same.
Honest Limits on These Numbers
- Scoring models are themselves biased, and we measured it. An initial pass scored every draft with one strong model. A four-model, four-vendor panel then showed that single scorer agreed on cloud drafts to within about a point but consistently scored local drafts too high, by up to 17 points. The figures above are the panel's. Differences under about 6 points should be treated as no difference, and no AI scoring substitutes for a practitioner reading the claims.
- Panel scores are comparative. The panel scores every draft against its peers in one pass, and models within a few points of each other reordered when the peer group changed.
- The scorers disagree about the middle of the local field, and that disagreement is real. We re-ran the comparison four times, each time dropping one of the four scoring models. The leading cloud group and the identity of the best local model held in every variant. The ordering of the closely bunched local models did not. That is why those models are reported as a group.
- Scoring wobble was measured, not estimated. The full comparison was repeated three times on four specifications. Cloud models reproduce within about a point; scores for the closely bunched local models move by up to 6. This measures how consistently the scoring behaves on a fixed set of drafts. How much a model's drafting itself varies between attempts on the same specification was not tested.
- We checked for vendor favoritism and did not find it. One of the four panel members is from the same family as the two Claude drafters. Re-running without that member moved those two drafters slightly up, not down, and by the same amount as their score-matched competitors.
- Raw first-pass drafting only. The critic and revise loop, where antecedent-basis and claim-form problems actually get repaired, were switched off.
- A local workflow needs two models, not one. The revise loop requires a separate critic from a different model family, because a model reviewing its own draft passes nearly everything. Every memory figure above is for the drafting model alone.
- Public patents. Whether these results carry to unpublished practitioner drafts is untested.
- One machine. Memory figures come from a single Apple silicon workstation and will not reproduce exactly on other hardware.
The Short Version
If confidentiality is the constraint, local drafting is a real option rather than a compromise gesture. A 64 GB machine runs a model about 12 points behind the best cloud models, with nothing leaving the machine: no retention terms, no cross-border transfer, no vendor to audit. A 32 GB machine runs a faster model that handles every specification we tested, at roughly 15 points less quality and with noticeably more variation between specifications.
Which local model you choose matters more than whether you go local. The spread across local options was 34 points, against a 12-point gap from the best local model to the best cloud model.
If confidentiality is not a constraint on a given matter, because the material is already published, cloud models draft measurably better and the difference shows up mostly as more dependent claims.
Frequently Asked Questions
Does local-first mean worse quality?
It depends on your hardware. On a 64 GB machine, the best local model scores 80, matching a trillion-parameter cloud model. On 32 GB, the gap widens to roughly 15 points with more variation between specifications. The tradeoff is real but quantified.
Why not just use the cloud model?
For published material, you often should. For unpublished disclosures, sending the specification to a cloud API raises questions under 37 CFR 11.106, ABA Opinion 512, export control, and trade secret law. A quantified quality gap is manageable. An inadvertent disclosure is not.
Are open-weight models worse than closed ones?
No. Two of the five highest-scoring models in the entire benchmark are open-weight. The limitation is not open versus closed. It is what fits on a workstation versus what requires a data center.
Can a local model also score its own drafts?
Not reliably. Every local model tested cited evidence from the wrong document when asked to verify claim support. The best local judge scored 0.35 on anchor fidelity. Automated scoring currently requires a cloud model, so it cannot be used on privileged material.
What hardware should I buy?
A machine with 64 GB of unified or GPU memory. On Apple Silicon, that is an M-series Mac with 64 GB. The recommended model uses about 30 GB resident, leaving room for the OS and normal work.
Do I need to disclose AI use to the USPTO?
There is no general duty to disclose AI involvement. The duty of candor creates a narrow exception where the use is material. The obligation is diligence about where the data goes, not disclosure of the tool itself. Consult your own assessment of the current guidance.
Sources and Related Resources
Duty Discussion Sources
- USPTO: Guidance on AI-Based Tools in Patent Practice (April 2024)
- ABA Formal Opinion 512 (July 2024)
- 37 CFR 11.106: Confidentiality of Information
- 35 U.S.C. 122: Confidential Status of Applications
- 35 U.S.C. 184: Filing of Application in Foreign Country