AI is already in use inside law firms. Some of that use is sanctioned; some is not. Lawyers and staff try tools on their own, often on live matters, because the tools are easy to reach and the firm has not said what is allowed.
That is a governance problem before it is a technology problem. The firms getting value from AI are the ones that decided what AI is for, who owns it, what information it may touch, and how they will know whether it works.
This article follows the ten domains of the Koers AI Readiness & Governance Framework. They are not a checklist. They are the questions a firm has to answer, roughly in this order, before AI use is defensible and measurable.
Why legal AI pilots fail
Pilots rarely fail because the technology does not work. They fail because the firm did not set them up to succeed.
Tool-first thinking. The pilot starts with a product, not a problem. A demonstration impresses a partner, a license is signed, and the firm then looks for somewhere to use it. The work that would benefit most goes unexamined.
No owner. Nobody is accountable for the outcome. IT installed the tool, a practice group tried it, a partner approved it, and when it stalls no one’s job was to notice.
No baseline or measurement. The firm never recorded how long the task took before, how often the work was wrong, or what it cost. Months later the only evidence is opinion.
Confidentiality gaps. Client information reaches a system nobody reviewed, under terms accepted by whoever created the account. The firm cannot say where the data went, whether it was retained, or whether it trained a model. That failure ends a pilot regardless of its results.
No adoption plan. The tool works for the pilot group and goes nowhere else, because there was no training, no workflow change, and no reason for anyone outside the group to work differently.
The framework below exists to catch these failures before they happen.
The ten domains
Each domain answers a question the firm should be able to answer in writing.
| Domain | The question it answers |
|---|---|
| 1. Business Objectives | What outcome is AI supposed to improve, and how will we know? |
| 2. Use Cases | Which tasks, for which people, at what level of risk? |
| 3. Data Readiness | Is the information the tool needs accessible, accurate, and cleared for use? |
| 4. Security & Confidentiality | Where does client information go, who can see it, and what protects it? |
| 5. Governance | Who decides, what is approved, and how are exceptions handled? |
| 6. Model / Vendor Risk | What do we know about the provider, the model, and the contract? |
| 7. Human Oversight | Who reviews output, when, and what happens when it is wrong? |
| 8. Workflow Integration | Where does the tool sit in the process, and what changes around it? |
| 9. Evaluation | What are we measuring, against what baseline, and who reads the results? |
| 10. Change Management | How do people learn the new way of working, and why keep to it? |
Objectives and use cases
Start with the outcome, not the tool. “Reduce the time from intake to engagement letter” is an objective. “Adopt generative AI” is not. An objective names a measurable process, the people who run it, and what better looks like.
Use cases follow from objectives. Rank each on two axes: value to the firm and risk to the client. Summarizing internal meeting notes is low risk and moderate value. Drafting a filing is high value and high risk. The ranking determines how much control a use case needs and which ones to defer. Start with two or three.
Data readiness, security, and confidentiality
Every use case has a data flow: information leaves a firm system, enters a tool, is processed somewhere, and returns. The firm should be able to draw that flow on one page, including what is stored, for how long, and who at the vendor can see it. If the firm cannot draw it for the tools already in use, that is the first gap to close.
Data readiness is the other half. A drafting tool that works from the firm’s precedents needs precedents that are current, organized, and cleared for that use. Many pilots fail here quietly: the output is poor because the input was poor, and the tool takes the blame.
Confidentiality is a professional obligation, not only a security control. The firm must be able to explain to any client how its information was handled, and some clients set their own conditions in outside counsel guidelines.
Governance: an approved-use model
A written policy is the core deliverable of this domain. The most workable form is an approved-use model with three tiers.
- Permitted. Uses the firm has reviewed and approved, on named tools, with the controls stated. Example: summarizing non-privileged internal documents on the firm’s licensed platform.
- Restricted. Uses allowed under conditions: a named tool, supervising-lawyer sign-off, review before reliance, or client consent. Example: first drafts of client correspondence, edited by the responsible lawyer.
- Prohibited. Uses the firm will not allow, at least for now: client information in consumer tools under personal accounts; filing AI-generated text that has not been verified; deciding a client’s matter without lawyer judgment.
The model needs an owner, an exception process, and a review date. Skip the exception process and the firm gets shadow use: people work around a rule that does not fit their matter rather than ask.
Model and vendor risk
The firm cannot inspect a model. It can inspect the vendor. Before any tool handles client information, the firm should hold written answers to these questions:
- Where is data processed and stored, and in which jurisdiction?
- Is client or firm data used to train or improve the vendor’s models? Can that be turned off, in writing?
- How long are inputs and outputs retained, and can the firm set the period?
- What access controls apply, including to the vendor’s own staff?
- Are there audit logs, and can the firm export them?
- Which subprocessors handle the data, and how is the firm told when they change?
- What do the contractual terms say about confidentiality, breach notice, indemnity, and termination?
Weak answers rarely end the conversation. They decide which tier the tool lands in.
Human oversight
AI output is a draft, not a decision. Treat a lawyer’s obligations of competence, confidentiality, supervision of nonlawyer assistance, and candor to tribunals as unchanged when the assistant is software. The controls that meet them are familiar:
- Review before reliance. Nothing goes to a client, a court, or a counterparty until a responsible lawyer has read it and checked what matters: citations, facts, figures, and any statement of law.
- Sampling. For high-volume, lower-risk uses, review a defined sample on a defined schedule and record what was found. Sampling is oversight when it is documented and a hope when it is not.
- Escalation. Decide in advance what happens when output is wrong in a way that matters: who is told, what is paused, and how the use case is adjusted.
Match the level of review to the risk tier. Full review everywhere is unaffordable. Review nowhere is indefensible.
Workflow integration
A tool that sits outside the process will not be used. Integration means deciding where in the sequence of work the AI step happens, what it receives, what it produces, and who acts on the result. It also means removing the step it replaces. If lawyers still do the task the old way and then check the AI version, the firm has added work.
Evaluation: what a useful pilot measures
A pilot is an experiment. It needs a hypothesis, a baseline, a duration, and a decision rule, set before it starts. Measure five things:
- Quality. Accuracy and completeness against a reviewer’s standard, on a sample, with errors classified by type.
- Risk. Confidentiality incidents, policy exceptions, and instances where output was relied on without review.
- Adoption. How many intended users use the tool, how often, and for what.
- Time. Minutes per task before and after, measured rather than estimated.
- Business impact. What changed for the client or the firm: turnaround, capacity, realization, or write-offs.
The decision rule matters most: agree before the pilot what result means expand, adjust, or stop. Without it, every pilot is declared a success by the people who ran it.
Change management and training
People adopt what makes their day easier and what their supervisors visibly use. Training is necessary but not sufficient. The firm should also:
- Train by role and use case, not by tool.
- Teach the policy, not only the product: what is permitted, what is restricted, and why.
- Name a contact in each practice group who answers questions and collects problems.
- Report the measurements back, so people see why the change is being asked of them.
Where to begin
Firms that start well do three things first. Inventory the AI already in use, including personal accounts. Adopt an interim approved-use model, so the inventory has something to be measured against. Pick one use case to pilot properly, with an owner, a baseline, and a decision rule.
How Koers approaches this work
Koers works with law firms and legal-service organizations on AI readiness, governance, and implementation. Each engagement starts with evidence: what is in use, where the data flows, and what the firm is trying to improve. The deliverable is a governance model the firm can operate and a pilot design it can measure, not a recommendation to buy a product. Koers does not recommend AI because it is new, push a preferred vendor without disclosure, or treat a pilot as successful without measurement. The engagement is described on the AI Consulting service page.
This article is general information about AI governance in law firms, not legal advice.