How to Choose a Private AI Tool for Your Law Practice

Start with the question that eliminates most tools

Buyers usually start with features and price. For a confidentiality-bound practice, that's backwards. Start with data handling, because it's the criterion that can disqualify a tool no matter how good the rest of it is.

The question is blunt: when the tool analyzes a client's document, where does that document go? If the answer is "to the vendor's servers," you're now evaluating a cloud tool, and everything downstream — how long it's retained, whether it trains a model, which sub-processors touch it, what a breach or subpoena would expose — is a risk you have to assess and manage. If the answer is "nowhere; it's processed on my machine," most of those questions never arise.

Apply this filter first and the field narrows fast. A tool with a beautiful interface, a great price, and cloud architecture is still a cloud tool. A plainer tool that keeps everything on your device has already cleared the bar that matters most for privileged material. Lead with data handling, and the rest of the comparison gets much simpler.

The landscape: what you're actually choosing among

Before the rubric, it helps to know the rough categories on the market, because "private AI tool" spans very different things:

• General cloud assistants (the mainstream chatbots). Flexible and capable, priced for everyone, but cloud by architecture — fine for non-confidential work, a poor fit for client documents.
• Enterprise/business AI. The same general models with stronger contractual data terms — no training on inputs, shorter retention, business agreements. Better for sensitive-but-shareable work; still cloud, so the document is still transmitted.
• Legal-specific platforms. Built for the profession, often layering AI over vetted legal content, designed with professional duties in mind. Strong for tasks like research against a real corpus; typically priced and scoped for firms.
• On-device (local) tools. Run the model on your own hardware; the document never leaves your machine. The category built specifically for the confidentiality problem, at the cost of running on your own hardware.

Most solo buyers are really deciding which mix of these to use — and, for the confidential document work at the center of a practice, whether the on-device option covers it. The rubric below is how you tell.

The evaluation criteria

Here's the full rubric, in the rough order it should carry weight for confidential legal work.

1. Data handling: where does the document actually go?

This is criterion one for a reason. Look past the adjectives — "private," "secure," "enterprise" are marketing words, not architecture. The concrete things to establish:

• Is the document transmitted at all? The cleanest answer is no. If it is transmitted, you're in cloud-tool territory and the following sub-questions apply.
• Retention: how long is it kept, and where?
• Training: is your input used to improve a model? "We don't train on your data" is good to have but addresses only one downstream use.
• Sub-processors and logging: who else touches it, and what's recorded?

The single most reliable signal is whether the tool works with the network off. If it needs the internet to analyze a document, the document is going somewhere.

2. On-device vs cloud

This is the architectural fork underneath criterion one, and it's worth understanding as its own axis because it drives so much else.

On-device (local) tools run the model on your hardware. The privacy benefit is structural — no transmission, no third-party copy — and it comes with side benefits: works offline, no per-document metering, no dependency on a vendor's uptime. The trade-off is that you're running on your own machine, and for the very hardest open-ended reasoning the largest cloud models still lead.

Cloud tools run the model on the vendor's servers. The upside is raw capability at the top end and zero local hardware demands. The downside is the whole data-handling problem above. For confidential documents, that downside is the deciding factor; for general, non-confidential work, cloud may be perfectly fine.

For legal document work specifically — bounded tasks over a defined set of files — on-device is increasingly both capable enough and the cleaner answer.

3. Purpose-built vs general-purpose

A general tool (a horizontal AI assistant that does a bit of everything) is flexible but shallow on any one job. A purpose-built tool (built for a specific task, like contract review) is narrower but usually deeper where it counts — better-fitted workflows, output shaped for the actual job, fewer rough edges on the thing you do every day.

The right choice depends on what you do most. If contract and document review is the core of your practice, depth on that job beats breadth you won't use. If you want one tool for a scattered set of light tasks, breadth may win. Be honest about your highest-volume work and weight accordingly — the longest feature list is rarely the best fit.

4. Contract-review depth

If review is your core job, evaluate it directly rather than trusting a checkbox. Does the tool actually surface unusual and missing clauses, or just summarize? Does it point you to the exact passages so verification is fast? Does it handle the document types you actually see? A tool can be private, cheap, and Mac-native and still be shallow on the one job you need it for. Depth on the core task is worth testing on your own real (or realistically representative) documents during a trial.

5. Mac support and hardware fit

For on-device tools, hardware isn't a footnote — it determines whether the thing runs well. The practical questions:

• Does it support your platform? Many capable on-device tools target Apple Silicon Macs specifically; if you're on a Mac, that's a good fit, and if you're not, confirm support before anything else.
• What are the memory requirements? For local models, RAM matters more than clock speed. Check the tool's stated minimum and whether your machine clears it comfortably.
• Does it run smoothly on your actual hardware? This is exactly what a trial is for — confirm performance on your machine, not the demo's.

6. Cost and pricing model

Price matters, but the model matters as much as the number:

• Flat vs metered. A flat subscription is predictable; per-seat or per-token pricing couples cost to usage and volume, which can add up as you lean on the tool.
• Total cost of ownership. Factor setup effort and hardware. On-device tools may lean on hardware you already own instead of an ongoing per-use bill.
• Trial availability. A tool you can try before paying lets you test criteria 4 and 5 on your own work — a meaningful de-risker, and a reasonable thing to expect.

7. Setup, support, and longevity

The criteria above are about the tool's capability; this one is about living with it.

• Setup effort. How much work is it to get running? On-device tools vary from "install an app" to "assemble your own stack" — closer to the former is better for a solo without IT support.
• Support and updates. Is someone maintaining it, shipping model and security updates, and reachable when something breaks? A tool you depend on for client work shouldn't be abandonware.
• Longevity and lock-in. Will it still be here in two years, and how hard is it to leave? On-device tools that use interchangeable open models reduce lock-in; the better ones outlive any single model.

None of this outranks data handling, but between two tools that both clear the earlier bars, this is often the tiebreaker for a solo who can't afford to babysit software.

A simple way to run the evaluation

You don't need a spreadsheet, though you can make one. A workable order:

1. Filter on data handling. Drop anything that transmits confidential documents if confidentiality is your concern. This usually removes most of the list.
2. Match architecture to your work. On-device for confidential document tasks; cloud only where nothing sensitive is involved.
3. Weigh purpose-built vs general against your highest-volume job.
4. Trial the finalists on your own documents, testing contract-review depth and real-world performance on your hardware.
5. Compare cost last, on total cost and pricing model, not just the headline number.

Deciding in that order keeps you from falling for a cheap, polished tool that fails the one test that actually matters for client work.

Applying the framework: a worked example

Concretely, here's how the order plays out for a common buyer — a solo who does mostly contract and document review for small-business clients, on a Mac.

She starts with data handling. Her documents are client contracts, so anything that transmits them to a third party is out for that work; that alone removes the general cloud assistants from consideration for the core job. She notes she can still keep a general tool around for non-confidential drafting, but it won't be her document tool.

On architecture, that points her to on-device, which also happens to work offline and won't meter her by the document. She checks purpose-built vs general against her highest-volume work — contract review — and decides depth on that job beats breadth she won't use. She lines up the finalists and trials them on her own contracts, watching whether each actually surfaces unusual clauses and points her to the passages, and whether it runs smoothly on her Mac's memory. Only then does she look at cost, comparing a flat subscription against her expected usage.

Notice what happened: the decision was mostly made by criterion one, and the trial settled the rest. That's the framework working — the hard filter narrows the field, and hands-on testing picks the winner.

Common mistakes buyers make

Even with a rubric, a few errors are easy to fall into:

• Leading with features or price. The polished demo and the low sticker are seductive, but a tool that transmits confidential documents fails the test that matters regardless of either.
• Trusting the word "private." It's a marketing term until the architecture backs it up. Make it survive the network-off test.
• Skipping the trial. Evaluating on a vendor's demo instead of your own documents and hardware is how you discover the gaps after you've paid.
• Buying the longest feature list. Breadth you won't use is not depth on the job you do. Optimize for your highest-volume work.
• Ignoring longevity. The cheapest tool from a vendor who may vanish is not a bargain when it's holding your practice's workflow.

Red flags to watch for

A few signals that a "private" tool may not be what it claims:

• "Private" or "secure" with no explanation of architecture. If they can't or won't tell you plainly where the document goes, assume it goes to their servers.
• A privacy claim that doesn't survive the network-off test. If it needs the internet to analyze a document, it isn't processing locally.
• Retention and training terms that are hard to find or vague. Clarity here is a good sign; evasiveness isn't.
• Big accuracy claims with no acknowledgment of limits. A vendor that won't admit the tool can be wrong is a vendor to be careful with; honest tools tell you to verify.
• No trial. Being unable to test the core job and real performance before paying is a meaningful downside, especially for on-device tools where hardware fit varies.
• A vendor or model you can't identify. If you can't tell who's behind the tool or what's actually running under the hood, you can't assess its quality, its data handling, or whether it'll still be maintained next year.

What about running open models yourself?

Worth naming, because it's a real option: you can download a local runtime and an open model and run everything yourself, for free. If you're technically inclined and enjoy tinkering, it's a legitimate path, and it clears the data-handling bar by definition — nothing leaves your machine.

The honest trade-off is that raw model plus runtime is not a workflow. You get a general chat box, not a tool shaped for contract review — no matter organization, no review templates, no output structured for the job, and you own the setup, updates, and troubleshooting. For some solos that's a fair price for zero cost and total control. For most, the value of a purpose-built tool is precisely that it turns the same underlying local-AI capability into something built for the review job and maintained for you, so you spend your time practicing law instead of maintaining software.

Either way, the point stands: the free DIY route and the purpose-built route both sit on the on-device side of the one filter that matters. That's the company you want to be choosing among.

Where Privileged fits — and where it doesn't

In the interest of the honesty this framework is built on, here's the straight version.

Privileged is a purpose-built, on-device tool for solo and small-firm attorneys who do contract and document review on a Mac. It runs entirely on-device via Ollama on Apple Silicon, organizes work by matter, and includes workflow templates for contract review, document summary, filing review, and time entry. On the rubric above it's built to score where it counts for confidential work: data handling (nothing is transmitted, retained off-device, or used to train anything), on-device architecture, purpose-built depth on the review job, Mac support, and a flat trial-first model — there's a 7-day free trial, so you can test criteria 4 and 5 on your own documents before paying.

Where it is not the right pick, plainly: if you need legal research against a real case-law corpus, it doesn't do that. If you need a tool to generate motions, briefs, or demand letters, it doesn't draft. If you're not on a Mac, it's not built for you today. And if most of your AI use is general, non-confidential text work, a flexible general tool may serve you better. A purpose-built on-device review tool is the right answer for a specific buyer — and naming who that isn't is part of giving you a framework you can trust.

To go deeper — a fuller survey of private AI tools for solo attorneys, an honest head-to-head against a general-purpose alternative, and a practical contract-review checklist you can use with any tool — work through the guides in this cluster below.