AI Privilege Logs: Platform AI vs a Custom Agent

By Jude Lee · · Comparison

Attorneys and a paralegal reviewing document sets on laptops in a law firm conference room during a privilege review

The job you are actually automating

“Privilege log automation” sounds like one task. It is at least five, and they have very different automation profiles:

  1. Segregate candidates. Pull documents that hit privilege screens — counsel names, domains, legal-sounding terms, family relationships to hit documents.
  2. Classify. Attorney-client, work product, common interest, or not privileged at all. Full withhold or redact.
  3. Extract metadata. Date, author, all recipients (including everyone buried in a forwarded chain), document type, Bates or control number.
  4. Write the description. A neutral description that conveys the basis for the claim without revealing the privileged content.
  5. Assemble and QC. Deduplicate families, check for stray non-privileged entries, format to whatever the parties agreed to, and have a lawyer stand behind it.

Federal Rule of Civil Procedure 26(b)(5)(A) is the anchor here: a party withholding otherwise discoverable material on privilege grounds must describe the nature of what is withheld in a way that enables other parties to assess the claim. Courts and stipulated ESI protocols vary widely on what satisfies that — categorical logs, metadata-only logs, and full document-by-document logs are all live options depending on the case and the order. Confirm the required format against your protective order, the local rules, and any Rule 502(d) order in your case before you automate anything.

Option one: the AI already inside your review platform

If your documents are hosted in Relativity, Everlaw, DISCO, or Reveal, the shortest path is the vendor’s own AI. Relativity publishes materials on its aiR products aimed at review and privilege work; Everlaw markets an AI Assistant for summarization and review support; DISCO promotes Cecilia. Be clear about what these three descriptions are: they come from published vendor materials, not from a production run I conducted on your kind of data. Treat none of it as a benchmark. Feature sets and pricing move fast — I last checked these product pages in January 2026, and you should verify current capability, per-document pricing, and which model provider sits underneath directly with the vendor before you scope anything around it.

What you get: AI that already sees the coding layer, families, threading, and Bates numbers. Output lands in fields you can export straight to a log. The audit trail lives in the platform, which matters when opposing counsel challenges an entry.

What you don’t get: much control over the shape of the description, and no help with privileged material that never made it into the review database. Plenty of small-firm privilege claims come out of the firm’s own file — memos, engagement letters, internal analysis — sitting in Clio, NetDocuments, or a shared drive rather than in a hosted review set.

Option two: a documented skill in a general assistant

The lightweight middle path. You write a skill — a packaged, reusable instruction set that teaches an assistant to do one job identically every time — that defines your log fields, your description template, your banned phrasings (never quote the privileged content), and your escalation rules. Then you feed it batches.

This is the same pattern as reusable skills for standardized document review: the value isn’t the model’s cleverness, it’s that entry 1 and entry 900 read like the same lawyer wrote them. Consistency is what survives a meet-and-confer. It is also the cheapest thing to test — take 50 documents you have already logged by hand, run the skill, and diff the output against your human log.

The downsides are real and they are structural, not fixable with better prompting. A general assistant has no native view of email families or threading, so it will happily log a parent and orphan its attachments unless you assemble families yourself first. It has no Bates or coding layer, so control numbers have to be carried in and out by hand or by script. And batching is manual: what works cleanly at 50 documents becomes a copy-paste failure mode at 2,000, where a dropped batch produces a silently incomplete log. This path suits small, self-contained logs — not a rolling production.

Option three: a custom agent wired to your systems

An agent differs from a chatbot by taking multi-step action: it retrieves documents, extracts fields, writes entries, and writes results back into a system — under rules you set. The plumbing is usually MCP (Model Context Protocol), an open standard for giving an assistant governed, permissioned access to specific tools and data. You expose a narrow set of operations — list documents in this review folder, read this PDF, write a log row — through a custom MCP server, and the agent can only do those things. The architecture in building a custom MCP server over your matter data applies here, just pointed at a production set.

Platform AI feature
Fastest to switch on. Sees threading, families, and coding natively. Vendor owns the audit trail and the model contract. Log format is largely whatever the vendor ships. Costs scale per document or per user, and stop when you stop hosting. Best when the whole review already lives in the platform.
Custom agent + MCP
Weeks, not minutes, to stand up, plus real maintenance. Reads across the DMS, email, and the review set. You control the description template, the field map, and the escalation threshold. Carries the heaviest risk surface: you are sending client documents to a third-party model, so you own the data-residency question, the zero-retention and no-training contract terms, the conflicts check on the tooling, and the confidentiality analysis under your engagement letters. Best when your ESI protocol demands a specific format, when privileged docs live outside the review tool, or when you do this on most matters rather than once a year.

Where these agents actually break

A bad log invites a motion to compel, so be specific about failure modes:

An AI can draft a thousand privilege log entries. It cannot certify one.

The professional-responsibility frame is not optional either. ABA Formal Opinion 512 (July 2024) addresses lawyers’ use of generative AI across competence, confidentiality, supervision, and fees — read it alongside your own state bar’s technology guidance before you route client documents through any tool, and confirm your vendor’s confidentiality terms.

Modeling the payback without making numbers up

Don’t take anyone’s headline savings figure, including mine. Build your own from the case in front of you, with every assumption visible:

2,000 docs
Example batch size — substitute your actual log
Illustrative assumption
4 min/doc
Assumed manual logging time — measure yours
Illustrative assumption
$150/hr
Assumed blended rate — use your firm's
Illustrative assumption

The arithmetic on those assumptions: 2,000 × 4 minutes = 8,000 minutes, or about 133 hours, which at $150 an hour is roughly $20,000 of time on a single log. Now run the pilot and measure verification-only time. If checking an AI-drafted entry takes 1.5 minutes instead of 4, you are at about 50 hours — a difference of roughly 83 hours, which you weigh against platform fees, build cost, and ongoing upkeep. Every one of those inputs is a guess until you measure it on your own documents. If the work is passed through to the client at cost, the win is cycle time and associate capacity, not margin — say that honestly in the client conversation. The framework in our law firm automation ROI walkthrough works here.

Choosing, in order

  1. Read the order before the demo

    Pull the ESI protocol and any 502(d) order. If a categorical log is permitted, your automation problem may shrink by an order of magnitude.
  2. Pilot on documents you have already logged

    50 documents, human log in hand, measure disagreement rate and where the disagreements cluster.
  3. Use platform AI if the review is hosted

    Don’t build what you’re already paying for. Test the export against your required format.
  4. Build custom only on repeat pain

    Firm-specific format, privileged material spread across DMS and email, and this happens several times a year — that’s the build case. Once a year is not.
  5. Set the human gate in writing

    Define which entries auto-pass, which route to a paralegal, and which require the responsible attorney. Log every AI-generated entry as AI-generated in your own records.
  6. Give the agent an owner and a review date

    Whoever built it names a maintainer and a quarterly check. Unowned agents are how the wrong format ships on the wrong matter.

Privilege logging sits next to the rest of your document workflow, so treat it as one piece of a larger pattern rather than a standalone toy — the sequencing logic in the agentic discovery triage playbook applies directly. And if your firm handles one production a year, the honest answer may be that a good template, a sharp paralegal, and an afternoon still beat any of this.

Where is your firm losing billable hours?

Get a free automation audit: we map your intake-to-invoice workflow and show you exactly what's worth automating — before you spend a dollar.

Get a free automation audit