Maybe Legal AI Capability Is Solved. Legal AI Economics Aren’t.

I’ve seen a few versions of the same argument since GPT-6 arrived: frontier models are now so capable that legal tech is, for practical purposes, solved.

I can see why people say it. Give a strong model a contract and ask it to identify unusual provisions, compare them against a playbook, explain the implications and suggest amendments, and the quality can be remarkable. For an individual lawyer using something like ChatGPT, that capability can also feel almost ridiculously cheap.

So I’m not particularly interested in arguing against the premise, let’s accept it for the sake of argument.

Maybe legal AI capability is solved, but Legal AI economics aren’t.

Because there is a considerable difference between proving that a model can perform a legal task and building a service which performs that task thousands of times, against documents you have never seen before, with appropriate security, auditability, predictable performance and an output that somebody is actually prepared to rely upon.

The model being capable of doing the work is only one part of that system.

The number I increasingly think we should care about is cost per trusted outcome.

Cost per trusted outcome

We have spent years comparing AI systems through benchmark performance, accuracy and price per million tokens. All of those tell us something useful, but none answers the question I would actually want answered before putting a legal AI capability into production:

What does it cost to get from a piece of incoming legal work to an outcome the organisation is prepared to trust?

That is quite different from asking what the model call cost.

A model interaction costing 20p which then requires ten minutes of an associate’s time to check is not a 20p outcome. Conversely, a £2 workflow which uses several model calls, verifies its evidence, passes deterministic checks and avoids a lawyer having to review it may ultimately be the cheaper system.

Once you measure the outcome rather than the inference call, the economics begin to look very different.

The model call is not the product

Take a reasonably substantial legal request containing 25,000 input tokens and producing 2,500 output tokens. At current frontier-model API pricing, that can still amount to only a few tens of pence.

That is extraordinary when you think about the capability being purchased.

But it can also give us a misleading intuition about what legal AI costs.

When I upload a clean contract into ChatGPT, much of the difficult infrastructure disappears from view. I do not need to think about whether the next document is a scan, a malformed PDF, password protected, hundreds of pages long, badly encoded or carrying unexpected embedded content. I am not operating OCR, file conversion, parsing, malware scanning, sandboxed ingestion or document structure recovery.

In a production system, somebody has to do all that.

The same is true of identity, permissions, matter boundaries, information barriers, storage, retrieval and the systems the model is permitted to access. Then there is the audit trail: which model was used, which version, which instructions it received, which sources were available, what tools it called and what those tools returned.

If somebody challenges the result six months later, can the organisation reconstruct what happened?

That surrounding machinery is not incidental, it is the product and the model call sits inside it.

One query can hide a lot of inference

There is another reason why the visible price of AI can be deceptive: one user query does not necessarily correspond to one model call.

Some AI systems improve reliability by running the same or similar request several times and comparing the outputs. They may look for the most consistent conclusion across multiple generations, use another model to judge which response best answers the original query, then run a further generation step to produce the final response.

To the lawyer, the interaction is simply:

Review this clause.

Underneath, the system may have performed five analyses, a judging step and a final synthesis.

One visible request has become seven model calls.

That is not necessarily poor architecture. If those extra calls materially reduce uncertainty and prevent expensive human review, spending more on inference may reduce the overall cost of the outcome.

Equally, repeatedly asking a model the same question because it feels safer is not much of an engineering strategy if nobody has measured whether calls two through five make any meaningful difference.

That gives us another useful way of thinking about the problem: the marginal cost of trust.

If another £1 of inference reduces expected human-review cost by £10, it is probably money well spent. If it produces virtually no measurable improvement, it is just additional compute.

So the unit I would model is not:

one user query = one model request

It is the actual execution path from the user’s request through model calls, tool calls, retrieval, retries, verification, escalation and finally to the trusted outcome.

A 300-lawyer firm

Consider a mid-sized firm with 300 lawyers running an internally built Harvey-style platform, perhaps using something like MikeOSS as the application layer and connecting it to commercial foundation models underneath.

Assume around 60% of lawyers use the system on an average working day, giving us 180 daily active users, and that each performs six meaningful AI tasks across 22 working days in a month.

That produces around 23,760 legal AI tasks per month.

If each task involves three substantial frontier-model calls, raw inference could plausibly run into the low tens of thousands of pounds per month. Even on an annual basis, that may still look extremely attractive when spread across 300 lawyers.

Now let's suppose the system uses five generations to test consistency, another model to judge the answers and one final pass to construct the result. The lawyer has not asked the system to do more work, but the inference cost of their interaction has more than doubled simply because we changed the way trust is produced.

Again, that may be completely rational, but the super interesting question is what happens next.

If the simpler architecture produces an output that requires a lawyer to review 10% or 20% of the time, whereas the more expensive inference pattern reduces that substantially, the system making more model calls may have better economics.

That is why focusing exclusively on token spend can lead you in the wrong direction.

Human attention may be the most expensive compute in the system

This becomes clearer when you put a value on lawyer review.

Take those 23,760 monthly outcomes. If just 10% of them need ten minutes of lawyer verification, that is 396 hours of professional time every month.

Even at a conservative internal value of £100 an hour, that is nearly £40,000 per month.

At a 20% review rate it approaches £80,000.

Suddenly the discussion about shaving a few pence from an inference call looks much less important.

This is one of the reasons I think human intervention rate could become one of the most important economic measures for legal AI. Moving from a 20% review rate to 5% may be worth considerably more than halving your model bill.

Human attention therefore belongs inside the AI cost model rather than being treated as a free assurance layer at the end of the process.

That does not mean humans should disappear. It means we should recognise that their judgement is scarce, expensive and valuable, and design systems which spend that resource where it genuinely changes the outcome.

Then add everything nobody demos

Inference and lawyer review are still only part of the picture.

Somebody has to operate the platform. Engineers maintain the application, handle model and API changes, investigate failures, develop workflows, monitor performance and deploy new versions. Someone has to maintain evaluation sets and rerun them when underlying models change. Security teams need to assess the system, knowledge teams may need to maintain the sources and playbooks it depends upon, and product ownership does not disappear because the software is based on open source.

Open source can remove a licence fee, but it does not remove the cost of running software.

There is also the infrastructure around the application: storage, search, queues, document processing, OCR, monitoring, secrets management, networking, backups and observability. Most of those costs are individually manageable, but together they become part of the economics of the capability.

Then there is assurance: evaluation, regression testing, evidence verification, policy controls, auditability and security testing. None of those produces a visible answer for the lawyer, yet all of them contribute to whether the organisation is prepared to trust the system producing it.

Dedicated capacity changes the calculation again

The consumer experience can also give us the impression that AI capacity is infinitely elastic. Send a request, receive an answer, pay for the tokens.

Enterprise systems sometimes need something different.

If a legal workflow is business critical, the firm may care about predictable latency and guaranteed capacity rather than simply relying on pay-as-you-go inference. Services such as Azure OpenAI therefore offer provisioned throughput, where capacity is reserved rather than charged purely according to token consumption.

At that point, the economics are driven not only by how many tokens you consume over a month but also by when you consume them.

A 300-lawyer firm does not use AI evenly across 24 hours. People arrive at similar times, deadlines create bursts, deals generate spikes in document processing and automated workflows may create their own demand independently of people sitting at a keyboard.

Capacity that looks modest when averaged across a month can look quite different at 10am on a Tuesday when a deal is kicking off.

That creates a different set of engineering questions. Do you provision enough capacity for the peak, or maintain a smaller reserved base and let excess traffic spill into standard inference? Can background work be queued? Does every task actually need interactive latency? Can repeated matter context be cached? Can routine operations be routed to cheaper models?

The answers can materially change the cost of the service.

Which brings us back to the original point: the intelligence may increasingly be commoditised, but using that intelligence economically is still a systems problem.

How I would actually cost a legal AI capability

Before looking at model pricing, I would start with a specific piece of work.

Not “AI assistant”.

Something like:

Review an NDA against our standard playbook and identify deviations requiring attention.

That gives us something concrete enough to model.

The next step is to define what a trusted outcome means for that task. Perhaps every identified deviation has to resolve back to the source contract, particular output fields must be present, deterministic validation has to pass and certain risk categories require human approval.

The threshold will vary by task. Extracting a governing-law clause does not require the same assurance mechanism as recommending whether litigation should be commenced.

Once the outcome and trust threshold are clear, map the full execution path. Start with the incoming document and follow every step through ingestion, OCR if needed, retrieval, model calls, tools, retries, validation, verification, escalation and human review.

Only then should you start pricing it.

Measure how many times each step runs, which model it uses, typical input and output sizes, how often requests fail, how frequently a cheaper model escalates to a more capable one and what proportion of the work can be cached or reused.

Then add infrastructure, engineering, support, security, assurance and external services.

Finally, put a price on human attention. Measure what percentage of outputs need intervention, who intervenes and how long it takes.

That gives you a much more realistic number and the denominator should not be the number of times somebody presses Submit. It should be the number of outcomes that actually meet the trust threshold.

In its simplest form:

Cost per trusted outcome = total cost of delivering the capability ÷ trusted outcomes produced

If a workflow costs £50,000 to operate and produces 10,000 outputs, but 1,000 fail validation or are abandoned, the cost is not £5 per trusted outcome.

You have produced 9,000 usable outcomes, so the real figure is £5.56.

Failure has a cost, which is a surprising chunk of the overall.

Do not model only today’s usage

I would also build at least three demand scenarios.

The first is low adoption, where a relatively small group of lawyers uses AI for drafting, research and occasional document review.

The second is the expected case, with perhaps half or more of the firm using it several times a day and more structured workflows beginning to appear.

The third is the one I think matters most: AI-native demand.

At that point, usage stops being driven primarily by a lawyer opening an assistant and typing a question. Documents are classified when they arrive, new matters trigger research, contracts are analysed automatically, emails initiate workflows, knowledge is refreshed in the background and agents continually inspect queues or rerun analysis when information changes.

Once systems start generating their own inference demand, “requests per lawyer” stops being a particularly useful capacity-planning metric.

Machine-created demand can become much larger than human-created demand.

What I would measure in production

If the platform were live, cost per trusted outcome would be the headline measure, but I would want several other numbers alongside it.

I would track model cost per task and, importantly, model calls per task, because agentic systems can quietly multiply inference underneath a single interaction.

I would track first-pass trust rate, human intervention rate and minutes of human attention per task.

I would want retry rates, model escalation rates and cache hit rates, because all three materially affect economics.

And I would measure costs by workflow rather than blending everything into one “AI cost per user” figure.

An NDA review and a complex piece of regulatory analysis are not economically equivalent just because the same lawyer initiated both of them.

Eventually I would put another measure beside cost per trusted outcome:

value per trusted outcome.

Because cost alone is still only half the story.

A trusted outcome costing £15 that saves £300 of professional time is likely to be excellent economics.

A 20p outcome that nobody needed is not cheap in any meaningful sense.

Maybe capability really is solved

I do not know whether GPT-6 has solved legal tech, but I am increasingly happy to concede the argument because what comes next is more interesting.

Suppose frontier models really can perform most of the legal reasoning we need.

Awesome stuff.

Now build the service that safely ingests 100,000 arbitrary client documents, knows which ones need your most capable model and which do not, handles the malformed ones, retrieves the correct evidence, uses additional inference only when it improves the outcome, maintains a useful audit trail, survives model changes, supports hundreds of lawyers during peak demand and identifies exactly where human judgement is still required.

Then tell me what the whole thing costs.

The firms and legal technology companies that become good at this will not necessarily be those with privileged access to the smartest model. Access to frontier intelligence is becoming less distinctive.

The advantage will come from understanding how to turn that intelligence into reliable legal work without consuming more models, infrastructure and human attention than the result is worth.

Maybe legal AI capability is solved.

Legal AI economics aren’t.

And the number I would start watching now is cost per trusted outcome.