How to retain control of the knowledge, client requirements and working methods that make legal AI valuable.
The law firm's guide to building legal AI: Complete guide · Part 1: Ownership · Part 2: Integration · Part 3: Commercial value
A firm commissions an AI application for contract review. Its lawyers contribute precedents, explain their negotiation positions and correct the system's first attempts. After months of work, the application begins to reflect how the practice operates.
Then the firm considers changing suppliers. Can it take the review method with it? Can it export the lawyer-approved examples? Which improvements belong to the firm, and which can the supplier offer to other customers?
This hypothetical situation exposes a decision that should precede development: what, exactly, does the firm need to retain control of?
The valuable contribution may be a client playbook, a carefully curated set of precedents or the sequence of questions a specialist asks. An ownership strategy should identify those assets and establish how they can be used, maintained and moved.
Our foundational guide, Building legal AI: what law firms should own, buy and connect, maps the components a firm may build or buy. This article examines the knowledge and rights the firm should control across those components.
Use this article before a supplier workshop or development brief. The useful output is an agreed record of what the project uses and creates, which uses are permitted, and what the firm must be able to recover. Legal ownership, permission to use material and operational responsibility are separate questions.
Identify the knowledge behind the work product
Start with one recurring legal task. For a loan review, list the information and judgment needed to produce an acceptable result: relevant documents, preferred provisions, exceptions, escalation rules and the evidence supporting each finding.
Then separate the assets involved.
Asset | Example | Decision to resolve |
|---|---|---|
Matter material | Executed agreement, amendment, correspondence | Who may use it, for which purposes, and for how long? |
Practice knowledge | Approved precedent, drafting note, jurisdiction guidance | Who validates it and keeps it current? |
Client instructions | Risk tolerance, negotiation limits, reporting requirements | Where does it apply, and how are exceptions approved? |
Workflow definition | Review sequence, prompts, decision rules | Can the firm modify it and transfer it to another system? |
Evaluation material | Test documents, expected findings, lawyer corrections | Who can access, reuse and export it? |
Technical implementation | Application code, connectors, model configuration | What rights and dependencies does the arrangement create? |
Treat this as an inventory for design and contracting. Possession of a file does not, by itself, answer whether it may be used across matters or incorporated into a reusable product. Those decisions need to reflect the relevant rights, obligations and agreements.Inventory the assets, establish permitted use and test portability. Legal and technical owners maintain the method and its implementation.
Define the firm's method before selecting the technology
Specify the provisions to review, supporting evidence, client positions and escalation rules. “Review this contract for risk” leaves those decisions implicit.
For example, a review might require the system to identify the liability cap, locate its exclusions, check a relevant definition and present any ambiguity to a supervising lawyer. The practice should decide what happens when one of those elements is missing.
That method can sometimes be implemented within a purchased platform. Harvey's June 2025 announcement about Paul, Weiss describes lawyers and innovation staff building repeatable workflows that incorporate firm expertise and guardrails using its Workflow Builder. Harvey, “Paul, Weiss Partners with Harvey on New AI Workflows Innovation”.
This is an announced development approach. Test whether the proposed implementation expresses your practice's method adequately.
Write the method in a form that colleagues can inspect outside the application. If its meaning exists only in a developer's code or a supplier's configuration screen, legal ownership becomes difficult to exercise.
Separate permission to process from permission to reuse
Ask the supplier to work through a concrete case: a lawyer corrects the system's interpretation of a liability provision. What is stored, who can access it, and does it affect other matters or customers?
Request evidence for the answer. The following is a procurement discussion guide; the appropriate rights and terms depend on the arrangement.
Decision | Ask the supplier to show | Resolve before approval |
|---|---|---|
Processing and retention | Where inputs, extracted files, outputs and support copies go | Which copies exist, for what purpose, and under which retention rule |
Corrections and reuse | The path of a lawyer's feedback through the service | Whether it changes this matter, the firm's configuration or a shared product |
Custom development | The proposed treatment of code, prompts and workflow definitions | What each party may use, modify, license and transfer |
Client segregation | The result when an unauthorised test user requests a restricted file | How the boundary is enforced and who checks permission changes |
Exit | An export of the pilot assets | Which useful assets can be recovered, in what form and with what assistance |
A promise not to use documents for model training is relevant, but it does not answer every row. Record the commitments in the appropriate agreement and check that the proposed configuration implements them.
Sharing a commercial product and retaining an exclusive workflow can both be deliberate strategies. Make the choice explicit before the firm's lawyers contribute substantial know-how.
Make client requirements part of the design
A general firm policy may permit a tool while an individual client's instructions require a narrower processing boundary or additional review.
We recommend recording the approved configuration at matter level: permitted services, information categories, processing locations, retention settings and the person responsible for exceptions. Where client communication or consent is required, record how that requirement is satisfied before the workflow runs.
In US guidance, ABA Formal Opinion 512 addresses confidentiality risks within firms, including ethical walls, and discusses when communication or informed consent may be required. The answer depends on the circumstances; the opinion does not establish a universal consent rule for every AI use. ABA Formal Opinion 512, July 2024.
A useful test is to explain the proposed workflow to the relationship partner. They should be able to say what information goes where, why the arrangement meets the client's instructions and who will approve the result.
Those decisions become operational controls in Part 2: Building document workflows lawyers can trust.
Plan for a supplier change before one becomes urgent
Ask for an export of the pilot's documents, terminology, review rules, test cases and correction records. Have the team inspect whether the relationships between those assets are preserved. An export of files alone may leave substantial reconstruction work.
Resolve dependencies such as proprietary formats and licensed source collections. Identify available transition support and how deletion will be confirmed.
Exportability does not guarantee identical behaviour with another model or retrieval system. Include migration and renewed evaluation in the exit plan.
Give knowledge maintenance a named owner
Consider a hypothetical client that authorises a departure from the firm's usual liability position on one deal. If a lawyer corrects the AI output to reflect that instruction, the correction should not silently become the default for all clients.
Record the correction's scope: this finding, this matter, this client or the firm's general playbook. Name the person who can approve a wider change. Keep the effective date and the playbook version associated with each output.
The legal owner decides whether the method should change. The technical owner implements the approved change and reruns the affected tests. Neither responsibility should disappear into a general “AI team” inbox.
Allocate time for this work in the investment case in Part 3. Otherwise, the firm can acquire a sophisticated tool whose legal instructions gradually go out of date.
Leave the workshop with a usable decision record
For the proposed workflow, record the legal owner, technical owner, permitted source collections, client restrictions, treatment of corrections, export requirements and outstanding approvals. Attach the supplier's evidence and identify who will resolve any gap.
This can be a short working document. Its value is that the relationship partner, knowledge team and IT team can act on the same agreed requirements.
Apply the same thinking to multilingual knowledge
For cross-border practices, terminology is part of the working method. A translated defined term may need consistency across an agreement, its schedules and the client's reporting template.
Record who approves terminology, which matters or clients it applies to and how reviewers handle ambiguous language. Keep a path from the translated wording to the original so that the lawyer can assess the underlying text.
Bluente’s role includes document extraction and parsing into LLM-ready files—files prepared for use by a large language model application—alongside translation. Include extracted files in the asset inventory: define who may use them, retain their relationship to the original and account for them during export or deletion. This matters for scanned material even when no language conversion is required.
The first development brief should therefore include an asset inventory, a written review method, client requirements, maintenance responsibilities and a demonstrated exit route. Those decisions give the firm a concrete basis for choosing its technology partners.
Working across languages? Book a Bluente demo to discuss document parsing, terminology and translation within your firm's workflow.
Continue the series: Part 2: Building document workflows lawyers can trust, or return to the complete guide.