Building legal AI: a complete guide to ownership, infrastructure and commercial value

How law firms can decide what to build, what to buy and how to turn the investment into better client service.

The law firm's guide to building legal AI: Complete guide · Part 1: Knowledge ownership · Part 2: Document workflows · Part 3: Commercial value

A cross-border matter lands on a partner's desk. The documents include signed contracts, scanned amendments, spreadsheets and correspondence in several languages. The client needs a clear view of the material issues before an approaching deadline.

An AI system could assist at several points: preparing the documents, locating provisions, comparing positions and assembling a draft report. The firm's investment decision is how to make those steps work together, under its standards, at a cost and level of control it can sustain.

This illustrative matter is a useful starting point for a broader question facing law firms: what should it mean to build your own legal AI?

The Financial Times examined the push for bespoke technology in its September 2026 article, “Law firms seek bespoke differences in legal AI”. Its reporting describes firms combining external software, partnerships and internal development as they seek a competitive advantage.

That gives firms several routes to consider. They can configure an existing platform, commission a specific workflow, combine specialist services or maintain a broader application. Training a foundation model is a separate commitment and should have its own justification.

Our recommendation is to organise the decision around three questions:

1. What knowledge and working methods must the firm control?

2. How will documents move reliably from receipt to approved work product?

3. What client and commercial value will justify the continuing investment?

This guide connects those questions. Each part of the series develops one in depth, with practical decisions a firm can use in a development brief or supplier evaluation.

Knowledge ownership, workflow integration and commercial value should inform one pilot with clear scope, named owners and evidence for the next decision.

For the foundational architecture framework, read Building legal AI: what law firms should own, buy and connect. It explains the six layers that underpin the ownership, integration and investment decisions in this series.

Start with the decision you need to make

For a firm with limited development capacity, start with an approved product or a configured workflow for one practice group. Add specialist parsing where documents are the obstacle. Commission a broader build when you can identify a consequential gap and fund the people who will maintain the result.

Decide what to own at each layer

“Build or buy” is more useful when applied to specific capabilities. A firm may need close control of its review method while using a provider for document translation or model access.

The six layers below are a way to locate the requirement. In a supplier meeting, use them to ask which components are included, which require integration and who supports the combined workflow.

Four functional layers sit within governance and evaluation that apply across the whole system. A firm can buy components while retaining control of its requirements.

Control does not require writing every component. It requires an ability to specify the behaviour, verify it, change it appropriately and understand the consequences when a supplier or requirement changes.

Linklaters' December 2024 AI Sandbox announcement illustrates a mixed approach: internal tools, external developers and modular capabilities for search, extraction, analysis and drafting. Linklaters’ announcement.

The appropriate scale will differ by firm. Start with the work to be delivered and expand the architecture only where the requirements justify it.

Part 1: Retain control of the firm's knowledge and method

For a loan review, specify the provisions to inspect, the client's acceptable positions, the evidence required and the exceptions needing specialist advice. Give the developer or supplier an approved output to work towards. The project is easier to assess when the practice's method is written down.

Know which assets the project creates

Inventory the material used and created: matter documents, precedents, workflow rules, terminology, test cases and lawyer corrections. Establish the relevant rights, permitted uses and maintenance responsibilities.

Ask the supplier to trace one correction. Does it affect only this finding, the client playbook or a shared product? Request the proposed contractual treatment and a demonstration of the configured behaviour. The ownership decision becomes useful when both are clear.

Translate client instructions into a usable configuration

Record the matter's permitted services, processing locations, information categories and review requirements. Identify who resolves exceptions.

Have the relationship partner explain the process back to the project team: what information goes where, what the result will support and who approves it. Check that those answers match the deployed configuration.

Plan for change and exit

Request an export of pilot documents, terminology, review rules and evaluation cases. Check whether the source relationships survive and establish any transition assistance needed.

A different provider may behave differently with the same assets, so allow for retesting. Name the legal owner who approves changes and the technical owner who implements them.

Read the full article: Part 1 — Who owns your law firm's AI advantage?

Part 2: Connect documents to a workflow lawyers can use

Follow the last comparable matter from incoming files to the document the partner reviewed. Record the manual preparation and copy-paste that the proposed system would leave behind. Make the existing report template, evidence references and unresolved-item list part of the required output.

Establish a dependable document foundation

Keep originals, later versions, amendments and generated files distinguishable. Reconcile the files received against those processed, excluded or unresolved.

Inspect extraction on difficult examples: a table split across pages, a tracked deletion or a scanned amendment. Microsoft's guidance explains why structure and context matter to searchable passages. Microsoft, “RAG chunking phase”.

Check the data used by the model and the document viewed by the lawyer separately. A good visual layout does not establish that the content was interpreted correctly.

Prepare scanned documents for the LLM workflow

An image-only scan needs a processing route that recovers its content for the chosen system. Optical character recognition (OCR) recognises the text; parsing organises it for downstream use. Test reading order, tables and completeness before relying on the analysis.

Bluente supports this preparation layer through bulk document extraction. Its extraction-only OCR mode produces HTML without translating it. That makes the document layer relevant to same-language scanned contracts and exhibits as well as multilingual matters.

A large language model (LLM) works within an application that ingests documents. Here, “LLM-ready” means preparing a machine-readable file for that application. The team still needs to validate extraction, preserve source relationships and configure any chunking or retrieval required by its application. Part 2's document workflow develops those acceptance requirements.

Include translation in the process design

Specify when to use the original language, generate a working translation or obtain bilingual review. Keep original passages available to reviewers and confirm any requirements for externally used documents.

Bluente’s scanned-document workflow combines OCR, translation and reconstruction. Its API supports batch processing and status notifications. Establish which connections to the firm's systems are included and which need implementation.

Test retrieval and analysis independently

Retrieval selects evidence for the model. Analysis interprets it. Keep those two steps distinct in testing.

For a question about a contractual right, define the documents and passages needed to answer, including definitions and amendments. Check whether they were supplied to the model before investigating the wording of its conclusion.

For research tasks, identify the legal sources the system can access and how their currency and permitted use will be managed. A collection of the firm's precedents serves a different purpose from an authoritative research service.

Choose models against these specific tasks. Additional models may improve a particular step, but they also introduce more configurations to test and maintain. Require evidence for the added complexity.

Enforce permissions and make review practical

Access restrictions should survive extraction, translation, retrieval and caching. Test what happens when a user's matter access changes and whether restricted material remains available through a derivative or previous result.

OWASP's RAG security guidance addresses access to derived material and hostile instructions embedded in documents. OWASP RAG Security Cheat Sheet.

For workflows that take actions, specify separately who may propose a change, write to a matter record or transmit information externally. Give reviewers the source evidence, processing limitations and status needed to approve the work.

The pilot should end with the output in the place the team uses it, with its evidence and unresolved items intact. Measure the entire journey, including retries and correction.

Read the full article: Part 2 — Building document workflows lawyers can trust

Part 3: Make the investment earn its place in the practice

The third exercise is to establish why this workflow deserves continuing investment.

Choose a concrete outcome: a shorter time to an approved diligence report, more capacity for urgent matters or a predictable process for a recurring client need. Define the baseline before the pilot so the team can compare equivalent work.

For each pilot output, record whether the material findings were supported, the review and correction time, and the exceptions that remained. Compare against a similar work product completed through the current process.

Measure cost per approved work product

Include preparation, processing, legal review, rework, support and an appropriate allocation of implementation and maintenance cost. Segment materially different work so that clean documents do not conceal the effort required by difficult bundles.

Assess quality alongside cost. Define material failures and acceptance thresholds before making the comparison. A cheaper result that omits a relevant amendment is not an equivalent deliverable.

Also distinguish released capacity from cash savings and new revenue. If lawyers spend less time preparing a report, the practice gains capacity. The financial result depends on how that capacity is used and which expenditures actually change.

This keeps the case for investment credible. A service improvement may justify the project even where direct cash savings are modest, provided the firm can explain and evidence the benefit.

Decide how value reaches the client

Consider whether the workflow supports better turnaround, clearer reporting, more predictable scope or an ongoing service. Discuss how the resulting value should be reflected in the engagement.

A&O Shearman's 2025 collaboration with Harvey included a plan to sell specialist legal agents and share software revenue, illustrating one possible commercial route. A&O Shearman’s announcement.

That model brings its own support, scope and commercial responsibilities. A firm should choose it because it fits a demonstrated client need. Assess fee arrangements under the applicable professional rules and client agreement; Part 3 discusses the relevant US ABA guidance.

Fund people and maintenance

Assign time for knowledge updates, user training, incidents and retesting. Ask who responds if a job fails before a deadline or a client changes its instructions.

Train lawyers to check source evidence and recognise incomplete work. Preserve junior lawyers' opportunities to analyse documents independently and receive senior feedback, so that supervision of AI rests on developed judgment.

Define when to expand, change or retire the tool

Before commissioning a broad application, test whether an existing platform, configuration or narrow integration can meet the requirement. Custom development should close an identified gap that matters to the practice.

Set review points for quality, usage, client value and continuing cost. Expand when actual performance supports the case. Refine when a specific weakness can be addressed. Replace or retire the tool when its maintenance burden exceeds the benefit or another option better meets the requirement.

A project with an explicit stopping decision is easier to manage than an indefinite experiment.

Read the full article: Part 3 — Making legal AI earn its investment

Bring the three decisions into one pilot

Start with a small enough scope that the supervising lawyer can inspect the results and the technical owner can trace failures. Here is an illustrative brief for a transaction team:

Then move through four stages. The duration depends on access to suitable material, client requirements and available staff; this is a sequence, not a promised deployment schedule.

Ask the supplier to demonstrate a failure as well as a clean success. An unreadable amendment should produce a visible exception. The matter team needs to know who will obtain a better copy or route the affected work for manual review. See Part 2's sample finding and acceptance tests.

The recommendation to proceed should name the conditions attached to it: the document types, languages, tasks and users covered by the evidence. Extend that scope only after checking the new requirements. Use Part 3's approval paper for the funding discussion.

Bluente can be evaluated as the OCR, parsing and translation component. For the demonstration, agree on the receiving AI system, the required extracted-file format and how the lawyer will inspect the original. Bring a difficult scan as well as a native file. Its OCR documentation describes extraction-only HTML output, and its security information supports the processing review.

Book a Bluente demo to scope document preparation around the files and AI workflow your team needs to use.

Read the series in order: Part 1: Knowledge ownership → Part 2: Document workflows → Part 3: Commercial value