Every legal team I speak to is asking the same question: “Which AI tool should we buy?” It’s the wrong question.
The right one is about operating model design and it was true before AI existed.
This piece goes deep into what happens when you redesign the entire system around that logic.
Tomorrow we’re publishing This Week in Legal AI, subscribe if you want it in your inbox.
A faster lawyer is still the same operating model
Flank has been working with enterprise legal teams and their external counsel since 2018. Over those years, we have developed a view of how an enterprise legal function should be designed when execution is no longer constrained by headcount. The view is intentionally opinionated and structural. It sits underneath (or upstream of) the question of which AI vendor to pick, which CLM to deploy, or which contract review tool to license. It concerns the operating model itself.
What follows are the eight principles the operating model rests on. They are not principles about AI. Most of them would have been true ten years ago, and most would still be true in a world without AI (imagine that!).
I’ve structured these principles into three rough groupings. The first three principles establish the “unit of analysis” (how to look at the system). The next four describe the structural commitments of the operating model (how to build the system). The eighth defines the standard against which any deployment should be judged (how to evaluate the system).
🔍 The unit of analysis
The first principle is to fix the system, not the individual. Most legal-tech investment of the past decade has gone into making individual lawyers faster. The returns are real, but they are capped. A lawyer made twenty percent faster at NDA review is still doing NDA review. The function processes the same volume... and the cost structure barely moves.
The bigger lever is the system itself: Where does work enters? How is it categorised? Who or what executes it? How is it supervised? Where does the output live?
Each is a structural variable, and changing it produces a different operating model rather than a faster version of the same one. Everything that follows depends on this first principle. If the level of analysis is on the individual lawyer and this lawyers throughput, the answer to any operational problem will be a tool. If the level of analysis is the function itself, the answer is a redesigned operating model. (I can feel all the legal ops folk nodding with me; that feels good.)
A lawyer made twenty percent faster at NDA review is still doing NDA review.
The second principle is that inexpensive work should not be done by expensive resources. In most enterprise legal functions, senior lawyers are reading standard NDAs, mid-level lawyers are screening procurement requests, and senior counsel are personally redlining commodity supplier agreements. The implicit logic is that legal review requires a lawyer. The actual logic is that this work has been categorised as legal because there has been nowhere else to put it. The right question is not how to make lawyers faster at this work. It is what lawyers should never see.
The third principle is to unbundle execution from the people who currently do it. The work does not have to be done by the lawyer it is currently done by. Once a function accepts that proposition, the question becomes architectural rather than personal. Who or what should execute this work, under what supervision, with what consequences if it goes wrong? The execution-mode question (agents, ALSPs, in-house lawyers, panel firms, hybrid arrangements) is downstream of unbundling. This is the move most legal functions struggle with most, because it asks senior lawyers to give up the doing in a profession that has historically rewarded the doing. Throughput cannot be redesigned without it.
These three principles together establish the unit of analysis. The function, not the individual lawyer, is the right object of redesign. Tools that intervene at the individual level produce ten or fifteen percent gains that compound linearly with headcount. Redesign at the system level produces a different curve.
🏗️ The structural commitments
The fourth principle is that work gets done where work arrives. The strategic surface in any new operating model is intake. Most consolidation initiatives fail because they intervene downstream, inside workflows, and require requesters to learn new behaviours and visit new portals. A system that absorbs the existing front door earns adoption by default. Intake is also the only place every piece of work passes through the function in a uniform format, which makes it the only honest source of data about what the function actually does.
The fifth principle is to reserve senior judgement for what requires it. Senior judgement is the most expensive input in any legal function and the most easily wasted. The dominant operating model deploys it everywhere, inside every transaction and every routine question, which means most senior judgement is consumed by work that does not require it. The redesigned model concentrates judgement at the edges: writing the playbooks that govern routine execution, handling the exceptions surfaced from underneath, making the escalation calls that require human discretion. The lawyer is not redefined. The lawyer’s time is reallocated.
Senior judgement is the most expensive input in any legal function and the most easily wasted.
The sixth principle is that you cannot govern what you cannot see. Governance is upstream of every other quality decision. A legal team needs a live, queryable picture of what was done, what was produced, what was overridden, and what changed over time. This is true whether the executor is an agent, an ALSP, a junior lawyer, or a panel firm. Almost no enterprise legal team can answer “what was done in the last twenty-four hours, across all execution modes” in under a minute. The data exists in fragments across systems that do not talk to each other. Without that visibility, the function runs on anecdote, and quality is whatever the loudest voice in the room says it is.
The seventh principle is that the system of record outlives any tool or lawyer. Documents, decisions, and audit trails need durable storage that survives every vendor change, every model upgrade, every workflow rewrite, and every lawyer who leaves. In most enterprises, that storage already exists, often nothing more than a SharePoint, and it is sufficient. The right move is to operate above it, not to replace it. Confusing the system of record with the tool that produced the work, or the lawyer who did it, looks like efficiency in deployment and reveals itself as a divergence problem the moment an audit, regulator, or future GC asks for the full history of a deal.
These four principles together describe the structural commitments of the operating model. The front door defines where work enters. The reservation of judgement defines how lawyer time is allocated. Visibility defines what the function can supervise. The system of record defines what survives. Each of the four is necessary; together, they are sufficient.
⚡ The standard
The eighth principle is to ship outcomes, not tools. Software-level accountability (”the tool worked, the user did not adopt it”) should not exist in enterprise legal. The standard is service-level. Did the work get done? Was it correct? Was it on time? A vendor that delivers tooling but takes no responsibility for the outcome is selling at the wrong altitude for the problem.
This is also the test that distinguishes legacy legal-tech procurement from agentic-services procurement. The former pays for software that helps lawyers do work. The latter pays for the work, done.
Why this isn’t really about AI
The eight principles describe what an enterprise legal function should look like at scale, regardless of what executes the work. What has changed in the last few years is not the principles, but the answer they produce.
Until recently, the operating model these principles describe was not structurally available. There was no way to insource routine work at the volumes enterprise legal generates and run it through a system that supervised itself. ALSPs were the closest thing, and they kept the playbooks and the institutional knowledge with the provider rather than the client, which solved the throughput problem at the cost of the ownership problem. Agents change that. The work can be insourced, the playbooks stay with the legal team, and the throughput becomes elastic in a way headcount never could be.
But agents are the consequence of taking these principles seriously, not the starting point. A function that begins with “we should buy an agent” will probably buy the wrong thing, deploy it in the wrong place, and measure it against the wrong baseline. A function that begins with “we should redesign how the function actually works” will arrive at agents naturally, as the answer to a question it has now asked properly.
This is the operating model we have been building toward. The full methodology, including the practices and the structural design, will follow over the coming weeks at insights.flank.ai/method. Watch this space.
✳️
