Part 2: Building document workflows lawyers can trust

How to turn native files and scanned documents into LLM-ready content, then connect retrieval, analysis and review.

The law firm's guide to building legal AI: Complete guide · Part 1: Ownership · Part 2: Integration · Part 3: Commercial value

Consider a cross-border acquisition with a short diligence deadline. The team receives contracts in several languages, signed amendments as scans and financial schedules in spreadsheets. Lawyers need an issues list with evidence they can check and a clear account of anything still outstanding.

In this illustrative matter, an AI assistant is only useful if the surrounding workflow can establish which documents arrived, read the necessary content and return findings to the team in a usable form.

The design brief should follow that entire journey. A generated answer is an intermediate result; the deliverable is a reviewed work product supported by identifiable evidence.

The six-layer framework in Building legal AI: what law firms should own, buy and connect places document processing alongside retrieval, models, governance and evaluation. Here, we follow how those layers work together on a matter.

An illustrative document workflow: OCR and parsing prepare LLM-ready files, with translation where needed. Source links, access controls and visible exceptions should survive every step.

For the lawyer reviewing the result, three questions matter immediately: what was reviewed, what supports this finding, and what is still unresolved? The workflow should answer them without asking the lawyer to reconstruct how the software ran.

Start with the handoffs

Ask a fee earner to walk through the last comparable matter with legal ops. Record where files arrived, how the team identified the current version, what required translation and how findings reached the supervising lawyer.

Choose the final destination first: for example, the firm's existing diligence report with source references and outstanding items. Record manual downloads, renaming, reuploads and copy-paste that the new workflow would leave in place. Include that effort in the comparison.

The client restrictions and knowledge rules established in Part 1 should remain enforceable through every handoff.

1. Establish what was received and what was processed

Maintain a matter-level record that distinguishes originals, duplicates, versions, amendments and generated files. Connect every processing result to its source.

Give password-protected files, unreadable pages and missing attachments an unresolved status. The reviewer needs to know that an agreement was analysed but its referenced schedule was not supplied. A completed batch must still disclose those gaps.

Name the person who resolves each exception and the manual or specialist route available if it cannot be cleared before the deadline. Carry the remaining limitation into the review output.

2. Use OCR and parsing to prepare LLM-ready files

For scanned agreements, exhibits and historical records, the first task is to recover usable content from the page images. Optical character recognition (OCR) recognises text; parsing organises it for the application using a large language model (LLM). The required output may be a machine-readable file that is then ingested, divided into relevant passages and connected to its source.

Bluente provides this document extraction layer. Its OCR API supports an extraction-only mode that returns HTML without translation. A same-language scanned contract can therefore be prepared for analysis without passing through a translation step.

Define “LLM-ready” against the consuming application: which file format it accepts, what structure it needs and how it will retain source references. Validate the extracted content before treating it as evidence. A successfully produced file is not, by itself, proof that every page was read correctly.

Document processing must retain enough context for the legal task. A provision can depend on a definition elsewhere. A table can express its meaning through headings and row relationships. A tracked deletion can reverse the meaning of a draft if treated as current text.

Microsoft's RAG guidance explains that dividing documents into searchable passages requires attention to document structure and context. It also cautions that intermediate conversion can lose information. Microsoft, “RAG chunking phase”.

Inspect extracted text alongside the original, including table headings, amounts, dates, negations and clause numbering. Check visual layout and extracted meaning separately. A missing “not” can matter more to a reviewer than an untidy margin.

3. Make translation a controlled step

Decide which documents need translation and for what purpose. Initial triage, substantive analysis and a document prepared for external use may require different levels of review. Where a court or receiving authority specifies a form of translation, confirm its requirements for that use.

For the acquisition example, the team might create working translations for review while retaining bilingual checks for ambiguous provisions. Record the chosen approach, the terminology applied and the status of any required language review.

Keep the source and translation connected. If a reviewer corrects a defined term, decide whether the change applies to this document, this matter or an approved glossary. Avoid allowing a local correction to become a global rule without review.

A translated document should also carry the matter's access restrictions. Translation creates another representation of the information; the firm needs to account for where it is stored, used and deleted.

4. Retrieve the evidence the question requires

Retrieval selects the material a model will use to answer. Design it around the legal question and the boundaries of the matter.

A request about termination rights may require the relevant clause, its definitions and a later amendment. Retrieving one passage with similar language is insufficient if another document changes its effect.

The LegalBench-RAG benchmark evaluates the retrieval of precise supporting passages in legal documents. That provides a useful starting principle for local testing: assess whether the evidence needed to answer was found. Pipitone and Alami, “LegalBench-RAG”, August 2024.

Maintain separate tests for evidence selection and final analysis. If the system did not retrieve the amendment, identify that failure before changing the drafting prompt or generation model. If the evidence was present but misinterpreted, investigate the analysis step.

5. Select models and define permitted actions

Evaluate approved models on the work you intend them to perform. Extraction, comparison and drafting can have different acceptance criteria. A firm may use one model across the workflow or different models for particular tasks, depending on the demonstrated benefit and operational burden.

Give each step a clear instruction, expected output and exception route. Record the configuration used so that changes can be evaluated later.

For systems that can act, specify which operations are permitted. Drafting a proposed update, writing it to the matter record and sending it externally are separate actions. Assign the necessary authority to each.

Retrieved documents can contain malicious instructions. OWASP recommends treating such content as untrusted and enforcing access controls before it reaches the model, including for derived passages and cached responses. OWASP RAG Security Cheat Sheet.

Test the technical controls with restricted material and hostile document content. A written instruction asking the model to respect confidentiality cannot substitute for an enforced permission boundary.

6. Return a reviewable work product

Specify the finding a lawyer should receive. Here is an invented example for a diligence test; the filenames and provision references are illustrative.

These records and source links are requirements for the complete workflow, not a claim that an OCR service supplies the full review interface. The system should display links to those sources in the real implementation. If translation was used, make the original wording and translation available together. “Not found” should remain distinguishable from “the contract contains no such provision”.

The supervising lawyer can then see why the item needs attention and what would resolve it. Their judgment determines the conclusion and the treatment of any outstanding limitation in the advice.

Provide a way to accept, amend or reject findings. Keep draft and approved outputs distinguishable, preserve version history and confirm that the review system or document management integration supports the intended behaviour.

Test the whole journey with difficult files

Use a representative collection with known issues and lawyer-reviewed expected results. Include clean documents as well as poor scans, bilingual tables, superseded drafts and missing schedules.

These are suggested acceptance tests, not a claim that any product satisfies them automatically. Include manual preparation, review and correction time in the results. Part 3 explains how to turn that evidence into an investment decision.

Run the test in front of the people who will use it

Give a lawyer-reviewed test set to the proposed workflow and retain a separate set for the final assessment. Include examples where the correct response is to flag missing information. Repeatedly tuning against the same examples can make a demonstration more convincing without showing that the process generalises.

Have the reviewing lawyer record material omissions, unsupported findings and correction time. Ask legal ops to reconcile the input files against the processing record. Have the technical owner investigate where failures occurred: recognition, parsing, evidence selection, analysis or delivery.

When an unreadable amendment or a permissions failure is discovered, stop using the affected result, identify the affected files and move them through the agreed manual or specialist route. Retest the failure before restoring that part of the workflow. The pilot's success includes how it handles exceptions under a deadline.

Where Bluente fits in the workflow

Bluente can supply the document infrastructure component: OCR, parsing into LLM-ready files and translation where required. The bulk extraction API addresses document preparation; the scanned-document workflow supports translation and reconstruction when a translated file is needed.

The firm’s implementation should connect those services to its matter identifiers, source records, access decisions and review process. Use API status tracking and notifications to account for processing outcomes, and review processing and access requirements during scoping. Confirm the actual document management or review-system integration before relying on it.

Start with the documents and the required output. Demonstrate that the team can receive, process, review and return a complete batch—including its exceptions—before extending the workflow to additional practices.

Building a multilingual document workflow? Book a Bluente demo to evaluate OCR, parsing, LLM-ready output and translation with representative files.

Continue the series: Part 3: Making legal AI earn its investment · Previous: Part 1 · Complete guide