Law firm intake automation: prepare the file, keep the decision with counsel

The deliverable should be a structured intake packet containing the original request, source documents, extracted facts, uncertainties, and a named reviewer. An intake packet is not an engagement agreement or a legal opinion. I would make that distinction explicit in the internal interface and in any acknowledgment approved by the firm.

ABA Formal Opinion 512 discusses lawyers' obligations when using generative AI, including competence, confidentiality, communication, and supervision. Its guidance is a reason to inspect the actual data flow before putting client material into a model. It is not a certificate that a particular integration is acceptable. The firm's counsel must determine applicable jurisdictional requirements and the disclosures or consent its proposed use requires. ABA Formal Opinion 512

For an initial scope, I would choose one practice group and one intake channel. Existing clients sending new instructions, opposing counsel correspondence, unsolicited marketing, and potential new matters may require different handling. Mixing them into one generic classifier makes it harder to establish who owns each exception.

The first record should store a stable intake identifier, receipt time, channel, sender, attachment references, and the source message identifier. Store files in the firm's approved document system. The workflow should reference them rather than copy their contents into every log, notification, and project board.

I would extract names, organizations, contact details, the stated request, and dates explicitly mentioned in the source. Each extracted field should point to the sentence or document page supporting it. Keep a separate field for uncertainty. If the email says “next Friday” without a clear context, the system should preserve those words and ask a reviewer to resolve them.

Do not let a model turn an alleged deadline into an authoritative calendar event. A useful packet can say “sender mentions a hearing on this date” with a source reference. Whether that creates a legal deadline is a different decision. The interface should make the difference easy to see without reading an implementation manual.

The system can prepare the names needed for a conflict review, but the authoritative conflict process should remain intact. I would submit candidate parties to the firm's approved conflict-check workflow and record its reference and status. A model's failure to find a name is not clearance.

Aliases, former business names, misspellings, and related entities need explicit treatment. Candidate matches should be presented as candidates, with the evidence used to find them. An authorized reviewer resolves the match and records the decision. If conflict checking is unavailable, the intake remains waiting. The workflow must not silently interpret a timeout as permission to proceed.

Access should also follow the firm's matter restrictions. A single shared search index containing every historical client record can expose information to people who could not open the original file. Apply access restrictions before retrieving material, and test with accounts that should be denied access.

I would show the reviewer five things: what the person asked for, who is involved, what documents arrived, what needs clarification, and what action is waiting. The original message and files should be one click away. Avoid an elegant summary that hides uncertainty behind confident prose.

The reviewer can return the packet for clarification, route it to another practice group, record a decline, or authorize the next intake step. Those actions should be distinct. A status named “complete” is too vague if one person means the extraction completed and another means the firm accepted the matter.

Any external message should come from a firm-approved template or a reviewed draft. If the message changes, its approval should expire. The sending record should retain the exact recipient, approved body, approving person, and delivery result. A draft saved in a mailbox is not evidence of a sent acknowledgment.

Encrypted PDFs, photographs, handwritten notes, unsupported languages, and damaged attachments need a normal exception path. The system should say which file failed and preserve it for manual handling. It should never produce a clean-looking intake packet that quietly omits the attachment containing the most important facts.

Uploaded documents can also contain instructions directed at an AI system. Treat document text as evidence to inspect, never as permission to change the workflow, reveal other records, or contact someone. The integration's permissions should enforce that boundary even when a model produces the wrong instruction.

If an intake arrives twice, retain the original event identifiers and associate the duplicates. Retrying a failed extraction should not create another prospective-client record or send another message. If a downstream tool times out after creating a record, reconcile against its stable identifier before trying the write again.

For acceptance testing, I would prepare a reviewed set of synthetic or properly authorized examples. Include two unrelated people with the same name, an apparent deadline buried in an attachment, a conflict-service outage, an unreadable file, a duplicate submission, and a message that tries to instruct the model to ignore its rules.

The expected result for each example should be written before the test runs. For the unreadable attachment, the acceptance condition is a visible exception with the original file retained. For a conflict outage, it is a blocked next step. For a changed recipient, it is a new approval requirement. Passing the happy-path demo does not establish these properties.

Measure extraction correction rate, reviewer handling time, exception age, duplicate records, and unauthorized-action attempts. Report the test sample and time period beside the numbers. I would not promise a percentage reduction in administrative work before measuring the firm's starting process and the actual pilot.

The intake lead needs a queue they can work without an engineer. The technical owner needs logs showing where a request stopped, which dependency failed, and whether an external action happened. Neither person needs raw confidential documents sprayed through operational logs.

The handover should include access ownership, retention settings, escalation contacts, a pause control, and instructions for processing the queue manually. If the automation is stopped, intake must still reach the responsible team. That fallback is part of the implementation scope.

My starting question for a firm is concrete: which intake step causes the most rework, and what evidence would let the reviewer trust the prepared packet? Answer that first, then build the smallest workflow that can produce that evidence consistently.