A practical framework for building firm-specific AI, from document infrastructure to legal workflows.
A cross-border due diligence team receives a folder of contracts, scanned amendments and disclosure schedules in several languages. Its AI assistant produces a polished risk summary. But one amendment was unreadable, a table lost its column headings, and a finding points to a superseded draft.
The answer sounds convincing. The team still has to reconstruct the evidence before it can advise the client.
This illustrative scenario gets to the heart of building legal AI. A firm's system needs to carry a document reliably from receipt through analysis to a work product a lawyer can approve. Choosing the model is only one decision in that chain.
The Financial Times explored the growing appetite for bespoke systems in its September 2026 article, “Law firms seek bespoke differences in legal AI”. Its reporting describes firms combining purchased software, technology partnerships and internal development in pursuit of differentiation.
For firms considering their own investment, our view is straightforward: control the knowledge, decisions and standards that distinguish your practice; use specialist infrastructure where it meets your requirements; build the connections that make the whole workflow dependable.
Our starting recommendation: test a purchased or configured solution on one recurring task before commissioning a broader application. A custom build deserves investment when a specific requirement remains unmet, the work recurs often enough to matter, and someone can maintain the result. Document parsing may be the gap to solve first—particularly when an otherwise useful tool struggles with scans.
Define what “our own AI” means
Building can mean configuring a review playbook in an existing product, connecting approved services or commissioning an application. Training a foundation model is a different commitment.
Linklaters' December 2024 AI Sandbox announcement described internal tools, external developers and reusable search, extraction, analysis and drafting capabilities. That illustrates how a firm can combine approaches. Linklaters’ announcement.
The practical question is which unmet requirement deserves custom work. Use the following comparison before setting the development budget.
Which route fits the problem in front of you?
Use this as a decision aid when a practice group asks for “its own AI”. Each route still needs to meet the firm's security and client requirements.
What you observe | Route to test first | What would justify more custom work? |
|---|---|---|
A common task, such as summarising clean documents | An approved existing product | A demonstrated quality or control gap on the actual work |
The tool works, but lawyers need a particular review sequence | Configure the playbook and output template | Required decisions or review steps cannot be expressed reliably |
The tool works on native files but fails on scanned agreements | Connect a document OCR and parsing service | Available services cannot meet the relevant format or processing requirements |
The team's work is spread across systems and repeated handoffs | A narrow integration | The benefit depends on a workflow that existing integrations cannot deliver |
A distinctive, recurring client service needs bespoke decisions | A custom workflow or application | Proven demand, measurable value and funded legal and technical ownership |
If the team cannot name the unmet requirement, investigate the current process before adding software. If the problem occurs rarely, compare a supervised manual route with the continuing cost of automation.
Make the decision layer by layer
We recommend separating the system into six layers. A single supplier may cover several, and governance runs across all of them. The distinction helps clarify what the firm needs to control and where it needs engineering capacity.
Layer | What it does | The firm's priority |
|---|---|---|
Document infrastructure | Parses files into LLM-ready content, reads scans with OCR, preserves structure and translates where needed | Define fidelity, traceability and processing requirements; evaluate specialist components |
Knowledge and retrieval | Selects the relevant matter evidence, precedents and legal sources | Curate authoritative material, permissions, versions and source links |
Models | Extracts, classifies, reasons and drafts | Choose approved models against task-specific tests and deployment constraints |
Legal workflows | Applies playbooks, sequences tasks and routes exceptions | Encode the firm's judgment, client instructions and review process |
Governance and security | Enforces access, processing boundaries, retention and permitted actions | Own policy, supplier requirements and accountability |
Evaluation and operations | Tests quality, monitors failures and manages change | Set acceptance standards and fund continuing maintenance |
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.
Owning a layer means retaining control over its requirements, configuration, data rights and performance. It does not necessarily mean writing all its code.
Start with the document infrastructure
A scanned amendment can be decisive even when the rest of a document collection is searchable. Optical character recognition (OCR) recovers text from page images; parsing organises it for downstream use. “LLM-ready” means preparing a file for a large language model's surrounding workflow, with its content and structure checked for that use.
Bluente provides document extraction and parsing. Its OCR API can return extracted HTML without translation. This supports scanned agreements and exhibits already in the working language as well as multilingual matters.
In the demonstration, inspect three things:
Meaning: do table headings, amounts, dates, negations and clause relationships survive extraction?
Traceability: can the lawyer return from a finding to the correct original, version and provision?
Completeness: are unreadable pages, missing attachments and failed files visible in the output?
Microsoft's guidance explains why dividing documents into searchable passages requires attention to structure and context. Microsoft’s document chunking guidance. Ask the implementation team how it will preserve the evidence needed across clauses and documents.
Where translation is needed, keep the original and translation connected and define the review required. Check both the file used by the AI system and the formatted document used by the lawyer. Passing one check does not establish the other.
Build a knowledge layer lawyers can trust
Retrieval-augmented generation, or RAG, supplies a model with selected source material when it answers. Test whether it selects the evidence the task needs. LegalBench-RAG provides a research example focused on precise supporting passages in legal documents. LegalBench-RAG, August 2024.
Keep an approved precedent, a counterparty's proposal and an executed agreement distinguishable. Record their status and permitted use. For matter analysis, test whether the system finds relevant amendments and schedules; for legal research, establish which authoritative sources it can access and how currency is checked.
Give a knowledge lawyer or practice specialist responsibility for that curation. A model choice cannot resolve uncertainty about which document the firm intended it to use.
Invest custom development in the legal workflow
For a first build, choose a named deliverable: an initial diligence issues list, a loan covenant comparison or a disclosure chronology. State what the lawyer should receive and what will remain outside the scope.
For example, a contract review brief might require the system to identify the agreement and amendments, locate specified provisions, compare them with a client playbook and prepare findings with source references. Ambiguous or missing evidence must reach a reviewer.
Ask the practice group to provide three things before development begins: an approved example of the deliverable, documents that are difficult to process, and the decisions that require specialist judgment. Those materials make a supplier demonstration or internal prototype assessable.
Put confidentiality and accountability into the architecture
Test access using a person who should be excluded from a matter. The restriction should apply to originals, parsed files, translations and retrieved passages. OWASP's RAG security guidance addresses derived material and hostile instructions inside documents. OWASP RAG Security Cheat Sheet.
Document the approved providers, processing locations, retention rules and responsibilities. Specify who can propose an action, change a matter record or send information externally.
In the US, ABA Formal Opinion 512 addresses ethical walls and an appropriate degree of independent review; duties depend on jurisdiction and circumstances. ABA Formal Opinion 512, July 2024. Give the supervising lawyer access to the evidence and an explicit approval role.
Evaluate the complete work product
Agree the expected findings and material failure conditions before testing. Include poor scans, amendments, missing evidence and restricted documents. Keep some reviewed examples aside for assessment after configuration.
Evaluate whether the system finds the evidence, reaches a supported result and makes the lawyer's review manageable. Record receipt-to-approval time and full delivery cost, including preparation, correction and maintenance. Part 3's scorecard makes those measures assignable.
Retest affected work when models, extraction tools, instructions or source collections change. Name both the legal and technical owners before the system is used on live work.
What to take to the first approval meeting
Bring a one-page proposal that names the work product, the current bottleneck, the route being tested, the client constraints and the legal and technical owners. Attach one representative output and state what result would justify proceeding.
A partner should be able to answer: “Why does this need to be built, who will use it, and who is responsible when it fails?” If those answers are still unclear, fund discovery and a bounded comparison before a full build. The complete guide sets out the pilot responsibilities and decision points.
Explore the legal AI series
The complete guide to ownership, infrastructure and commercial value brings this architecture together with three practical decisions for the firm:
Part 1: Who owns your law firm's AI advantage? — control of knowledge, client requirements and portability.
Part 2: Building document workflows lawyers can trust — connecting intake, translation, analysis and review.
Part 3: Making legal AI earn its investment — evaluating quality, capacity, cost and ongoing ownership.
Where Bluente fits
When the gap is document preparation, evaluate Bluente's bulk document extraction API for OCR and parsing into files the downstream AI application can ingest. Its scanned-document capabilities and translation API also support translated document workflows.
Use a native contract, a difficult scan and a file with a complex table. Inspect what was extracted, what the consuming system accepts and how a lawyer reaches the original. Include any required integration and correction work in the comparison.
Book a Bluente demo to scope an OCR, parsing and translation evaluation around your firm's documents and target AI workflow.