How to Build the Legal Operations Intelligence Platform

Legal departments, like every function of the business, are expected to operate with greater intelligence. With the new capabilities AI brings, general counsel are building legal operations intelligence platforms to enable better risk management, better legal services, and stronger strategic input to the business as a whole.

AI is accelerating that change. Departments are actively deploying AI, both generative and agentic, and the scale of investment is driving an imperative to demonstrate return. Adoption is still at an early stage. Axiom's 2026 Legal AI Survey, fielded in March 2026 among 528 in-house legal leaders, found that 7% had scaled AI beyond pilots and that 83% "cannot measure whether their AI spending is working". In CLOC's 2026 State of the Industry report, 80% of departments name technology strategy as a legal operations focus area. The effect reaches well beyond the technology itself. AI is changing how work flows through the department, what its people do, and how its systems fit together, and the value a department gains depends on how well it aligns all three. Chris Frickland, Axiom's VP of AI Solutions, put it this way: "The layer around it is where value either shows up or it doesn't."

In the first article in this series, The New Mandate for Legal Operations, we described legal operations as the catalyst and manager of the department's operating model, and cited Harbor's conclusion that "Technology is in place. The operating model has not kept up." This article sets out how a department builds the platform that the new operating model runs on.

A legal operations intelligence platform is the department's capability, across process, people, and technology, to consolidate information from every source and bring each decision, with the context it needs, to the person who has the authority to make it. The new operating model is built on that platform. So is the department's use of AI, which needs connected information, the department's own knowledge, and governed processes to produce results that legal work can rely on. A department builds the platform by starting from legal's role in the business and the decisions it makes. Built this way, the platform lets the department's experience accumulate in its processes, its roles, and its connected information, rather than starting over with each new tool.

For additional background, our article What Is Legal Operations Intelligence? defines the category, and The AI Readiness Gap in Legal Departments explains why the tool is rarely what holds a department back.

The platform starts with legal's role in the business

The foundation of a legal operations intelligence platform is a clear definition of the role the legal department plays in the business and the services it provides. As a strategic advisor, the general counsel shapes risk appetite, market entry, M&A, regulatory posture, and governance, and that input reaches the board and the executive committee. As a transactional service provider, the legal department delivers the contract that has to be signed this quarter, the dispute that has to be defended, the employment question a manager raises, and the advice a business unit needs this week. Requests and data flow in the other direction, from the business into the department (Exhibit 1).

Understanding the interface between legal and the business, as well as with external service providers, is the first step in designing the platform. For each part of the business, the department needs a clear view of the services it provides, the decisions the business relies on legal to make or inform, how requests reach the department, and what the business expects in return: how quickly, in what form, and with what level of legal involvement. The same applies to outside counsel and other providers: which work they receive, on what terms, and what the department expects back. A platform designed without that view tends to improve the department's internal reporting without changing what the business receives.

In the first article in this series, we discussed legal's broadening remit to deliver legal services that are integrated into the business, engaged earlier in its decisions, and open to the business handling defined, lower-risk work itself. That remit makes the interface more important to understand. It also makes visibility part of the job, because the business needs to see what legal contributes. An example of this is in the finance area, where legal's spend appears in the budget but the reasoning behind that spend, and the value it protects, usually does not. In our earlier article, Breaking the Silo Between Legal, Finance, and the Business, we discussed that gap in detail. A platform that makes legal's services and their outcomes visible to the business has to carry that reasoning alongside the numbers. Risk is the clearest case, because it is the strategic input the business asks for most often and the one least likely to be recorded anywhere a business partner can read it.

As we've described, the four capabilities through which legal operations manages the operating model are service delivery, sourcing, reporting, and knowledge management. Each serves the interface between legal and the business, and each involves decisions: which channel handles a request, which provider takes a matter, what the business sees, and which knowledge is authoritative. The department therefore organizes the platform around those decisions, and the platform is judged by whether they become easier to make well and easier to carry out.

Context is what sets the platform apart

A decision needs more than the records that describe its subject. What sets a legal operations intelligence platform apart is that it combines information with context. Consolidation alone produces a larger collection of records; context is what makes those records meaningful to the person who has to act. Context has three parts:

• Relationships among records, such as the matter behind an invoice, the engagement terms behind a rate, and the person responsible for each.
• The organization's own knowledge, including its policies, playbooks, precedents, and history.
• The record of past decisions, meaning what the department decided in situations like the one at hand, which almost no department can retrieve today.

Building context into the platform requires two paths. The first is system integration, which brings together related data from otherwise disparate sources into a consolidated view, so that a matter can be seen with its documents, invoices, communications, and people. The second is a knowledge management process that augments those records with the why, the who, and the how: the policy that governs a decision, the playbook that shapes it, and the people and reasoning behind it, none of which are fields in a matter record. Forrester analysts Boris Evelson, Indranil Bandyopadhyay, Charlie Dai, and Noel Yuhanna made a related point on June 2, 2026, writing that semantic layers now also give AI agents "the governed context needed to turn natural language into accurate queries and actions".

The combination of the two is what we call the legal operations intelligence ontology: a model of the department's entities, the relationships among them, and the actions the department may take on them. It gives a view across the systems of record in more than one dimension at once, and it defines the actions, the policies that govern them, and who may act under which rule. A department cannot buy that model ready-made or derive it from the schemas of its existing systems. Building it takes a close understanding of how the department works and who does what. The next article in this series, The Legal Operations Intelligence Ontology, covers it in detail.

No single system can provide the required context. This limitation is inherent in the architecture of legal systems. Systems of record, whether for matters, contracts, documents, or invoices, are each bounded by their own data model and hold what their fields were designed to hold. The e-billing platform records what was billed, the rate, and the description for each line, but not the matter's overall health, its risk assessment, or its likely resolution timing. The matter system carries the budget and the assigned lawyer, but not the concessions in the engagement letter. The document management system holds that letter but cannot say which invoices it governs. What the department knows about a matter that never fit a field remains in email, in documents, and with people. This is a property of data models rather than of any particular vendor, and it applies equally to a system sold as a legal operations platform.

Consider, for example, a mid-size legal function with about 200 open matters, a panel of firms, an e-billing platform, a matter system, and a document management system. The systems were bought at different times, by different sponsors, to solve different problems, and each does its own job well. None of them was designed to connect with the others, so the department reconciles them by hand, and an analyst opens three applications and a spreadsheet to answer a question about one matter. Departments recognize the problem. In EY Law's 2025 General Counsel Study, beyond the disorganized data and disconnected platforms noted in the first article, 41% of respondents named limited access to accurate data as a barrier to change, and 75% said they were developing or refining their legal technology or data strategies. Most departments are still designing their response.

Close the loop from insight to action

It is axiomatic that you can't manage what you don't measure, and data is one critical ingredient of any management decision. The others are the reasoning applied to it, whether a rule, a calculation, or a model; the action that carries the decision out; and the controls that keep that action within policy. A reporting environment delivers the data but leaves unaddressed the reasoning, action, and policy control that management actually requires. The wider analytics field has reached the same view. Gartner's data and analytics trends, published on June 16, 2026, predict that explicitly modeled business decisions will be five times more trusted and 80% faster than ungoverned decisions by 2029.

Consolidation alone gives a department better reports, which may be all some departments need. What distinguishes an intelligence platform from a reporting environment is whether the loop from insight to action to recorded outcome closes inside one governed environment.

Consider a finding that both environments produce equally well: a panel firm whose fees on an open matter have passed the agreed budget. In a reporting environment, someone reads the finding and acts elsewhere, in an email to the relationship partner, an adjustment in the e-billing platform, or a note to the matter owner. The action is not connected to the finding, so when the matter is later reported within budget, the department cannot say what produced the change. Only the analyst who made the call knows.

In an intelligence platform, the finding arrives with the means to act on it. The person takes the action where the finding surfaced, and the platform records who decided what, on which information, and under which rule. It then writes the result, such as an approved invoice or a reassigned matter, to the system that owns that record. At the end of the quarter the department holds the finding, the decision, the reasoning, and the outcome together, which is what any later analysis of the firm or the matter type depends on.

Closing the loop does not require replacing existing systems. Where a system of record holds data the department trusts and someone maintains it, the platform connects to it, and that system remains the source of truth. Where no purchased system owns an entity at all, as is usually the case for the request, the disposition, the obligation, and the action record, the platform supplies system of record capabilities. Most departments do both. Business intelligence keeps its place as well. Calculations such as a budget variance or a realization rate have to produce the same answer every time, and the fourth article in this series takes up that deterministic side of the platform.

Process, people, then technology

The platform's three components are conventionally written as process, people, and technology. The order matters, because each depends on the one before it.

Process defines the workflow. Process is how work enters the department, how it is triaged and assigned, how it moves, how it closes, and what is recorded along the way. In platform terms, a process is a sequence of decisions and governed actions, each with its own rules, validations, approvals, notifications, and record. Where intake is undefined, the department cannot report request volumes or turnaround times, because no record of the request was ever created.

Consider intake triage. A request arrives by email or through a form; the platform records it, classifies the matter type, and assigns it by role and coverage; the assignment notifies the assignee and the requester. Every department already runs some version of that sequence. With the platform, each step leaves a record, so volume and turnaround become reportable. The Gartner forecast cited in the first article, that by 2029, 60% of legal departments will run AI-enabled intake, rests on the same precondition: a system cannot classify or answer a request the department has never defined.

Process also defines the business's own role. Where the department has opened the delivery model for defined, lower-risk work such as non-disclosure agreements, the process specifies the guardrails: which positions the business may accept, at what threshold a request returns to a lawyer, and how the business's choices are recorded. The platform makes those guardrails operate consistently and leaves a record the department can review.

People bring the experience, knowledge, and judgment. People supply the experience that recognizes an unusual matter, the institutional knowledge of what the company has agreed to before and why, and the judgment that turns information into a decision. In AI-directed processes, people are also the human in the loop. They review what an agent proposes, confirm or correct it, and remain accountable for the outcome. The people component also covers roles and ownership: who owns the data, who owns the process, and who is accountable for its outcomes. The legal team, legal operations, IT, finance, the business, and outside counsel all work within the platform, and each needs a defined relationship to it. Ownership often falls to someone who already has another job. In the Thomson Reuters Institute's 2025 Legal Department Operations Index, 45% of respondents were general counsel who also run legal operations, and 59% said they aim to improve collaboration between legal and business units.

Role design has not kept pace with the tools. Deloitte UK's The AI Imperative, published on July 9, 2026 from a survey of 121 senior legal leaders, found that 84% had not redesigned roles around AI. Deloitte's US Chief Legal Officer Program expects roles not traditionally found in corporate legal departments, among them project managers, data scientists, and technology specialists, to become more common, and it describes collaboration between the chief legal officer and the CIO as essential. The legal engineer roles described in the first article are an early example. In our earlier article, Legal Ops Is Not IT for Lawyers, we made the case that ownership of the platform belongs inside the legal department, with IT accountable for the environment it runs in and finance for the numbers that cross into its ledger. In our experience, ownership is the question most often left open at the start of a build, and a build that starts before it is settled tends to stall at the first action that needs a named approver.

Bringing a decision to the right person requires the platform to know who that person is. The department already holds this information: the responsible attorney and business client on each matter, who may approve an invoice above a threshold or a settlement within an authority limit, which firm is engaged and which of its timekeepers may bill, and who covers a matter during an absence. Most departments keep it in a policy document, a delegation-of-authority matrix, and the memory of an assistant, none of which a platform can read. Modeled in the platform, assignment and delegation become governed actions with their own rules and notifications. Reassigning a matter becomes one defined transaction that updates the record, notifies the outgoing and incoming owners, and checks that the person making the change has the authority to do so, which also makes the change reportable later.

Permissions, ethical walls, and privilege controls travel with the information rather than sitting in the application that displays it, and they apply equally to a person and to an AI agent acting for that person. An agent should never be able to read a matter its user could not read, or take an action its user could not take. Two familiar controls do the work. Roles granted to groups, usually through the company's existing identity provider, determine what a person may open. Labels that travel with each piece of information determine what may be done with it. The platform keeps permission to act separate from permission to see, which matters in a department where a paralegal may need to read every invoice on a matter and approve none of them.

Technology is the platform's toolbox. It comprises the systems of record that hold the department's data, the layer that connects them, and the surfaces its people work in. It is the part of the platform the department budgets for, logs into, and renews, and the part a provider can supply. The systems of record hold what the department has committed to storing. The connecting layer determines whether a matter can be seen with its invoices, documents, and communications at once. The surfaces determine whether any of that reaches the person making the decision: a queue that shows the exceptions worth reviewing, a matter page that answers the questions a lawyer asks, and an operating view that gives the general counsel and the CFO the same numbers. In our earlier article, The UX That Legal IQ Requires, we discussed the surfaces in detail, since departments tend to underestimate them.

Technology can carry out process definitions and ownership, but it cannot substitute for them. Software can enforce an approval rule only after someone has decided who approves what, route an exception only after someone has defined one, and report a turnaround time only after someone has decided when the clock starts. Departments that buy first and define later pay for the definitions anyway, in configuration work and change requests. What technology adds is scale. One analyst can reconcile one matter's invoices, budget, and engagement terms by hand in an afternoon, but no one can do that for 200 matters every month.

The platform also has to meet people where they already work. Legal professionals spend their days in email, documents, and Teams, and the financial side of the work happens in the e-billing platform. A platform that requires people to leave those places to record a decision will capture fewer decisions than one that works within them.

The platform is the product of the legal service lifecycle

The most effective way to define the platform is to start from the end point and work backward. Begin with the outcomes the general counsel, the CFO, and business unit leaders need, and the decisions they rely on legal to make or inform. Then trace back through the legal service lifecycle, from how a request is received to how it is triaged, assigned, delivered, and closed, to the decisions the department makes along the way. Write each decision as a single sentence that names the user, the working surface, the decision, the inputs it needs, and the action it produces.

A first attempt usually looks something like this: the head of litigation reviews matters approaching their budget and decides whether to raise the budget, change the staffing, or move the matter, using current spend, the firm's forecast, and the exposure estimate, and the outcome updates the matter record and notifies the firm. That one sentence shows what the platform needs to support the decision: three inputs from at least two systems, a surface that shows matters against budget, two governed actions, and a notification.

The inputs in each sentence map to the signals described in the first article: business impact, risk level, cost, timing, required skills, and resource availability. Checking each decision against those six signals shows what information it depends on and where that information currently sits. Three questions then follow each sentence:

• Which ultimate decision does it serve? This is the decision a business leader would recognize as their own.
• Which intermediate decisions come before it, and who makes them?
• Who owns it? This means the named user who owns the decision, as distinct from those consulted on it.

At this stage departments typically find that some decisions have no owner and others have three, and that finding is often the most valuable result of the exercise. A dozen such sentences also identify the measures the department will need, the entities and relationships the ontology has to hold, and the data each process must capture. This is often where a department discovers that its intake form has been collecting the wrong fields.

Apply the test to your own department. Take the ten decisions your general counsel would name as most important, and for each ask who makes it, where they make it, what they consult, and where the outcome is recorded. Start with the decisions you cannot answer in that form, because those decisions are not being recorded anywhere the department can review.

One decision is also the right scope for the first build. A use case, in this sense, is a time-bound effort by a dedicated team to support one decision. Integrating a source system does not qualify, and neither does building a dashboard, because neither changes how someone decides. The order of work follows the argument of this article:

1. Model the business in the department's own language, using the terms its lawyers and analysts already use rather than the tables of the source systems.
2. Connect to existing systems where they serve the department well, and supply system of record capabilities where it has none.
3. Define the governed actions, including the write back to the system of record, so that the loop closes.
4. Build the surfaces where the decision is made.
5. Add AI where it strengthens the work, as described below.

Validation can be simple. Collect the questions a general counsel or practice leader asks repeatedly, the ones that currently trigger a two-day search. Put those questions to the new surface, to a recent joiner, and to the AI the department will eventually rely on. How long each takes to produce a defensible answer is a useful design signal, and a question that takes longer on the platform than by telephone points to something the model has missed.

Then expand. The second decision costs less than the first, because the entities, connections, and governance built for the first are largely what the second needs. Intake to matter to spend is the usual sequence, since each stage feeds the next. A first build does not need a formal program. A working session of a few days, on real data, with the people who own the decision, produces a model worth refining. Those who have done this work are candid about the effort. Barry Briggs of Directions on Microsoft wrote on December 2, 2025 that "Creating an ontology, in Fabric or elsewhere, is a major effort and requires on-going maintenance, so there's no getting out of the hard work." Juan Sequeda's advice, written on June 10, 2026, is to "start small and think big", which in a legal department means one decision modeled properly in preference to a department-wide data program.

An illustrative example: the invoice exception, before and after

Consider again the department described earlier. Written in the form above, the decision reads: a legal operations analyst reviews an invoice exception queue and decides whether to approve, reduce, or return an invoice, using the engagement terms, the matter budget, and the firm's billing history, and the outcome updates the invoice record in the e-billing system.

Today, the decision is made in email. The e-billing platform flags a line on a litigation invoice because the partner rate exceeds the cap in the outside counsel guidelines. The analyst opens the matter system to check the budget and how much of it the firm has consumed. She opens the engagement letter in the document management system, because the guidelines allow an uplift for one named partner and she needs to confirm whether this is that partner. She opens a spreadsheet she maintains herself, showing what this firm has billed on similar matters over two years. Four applications are open before she has applied any judgment.

The judgment itself takes a few minutes. She writes to the billing partner, explains that the rate exceeds the cap and that the engagement letter's exception covers a different timekeeper, and proposes a reduction. The firm agrees. She enters the reduction in the e-billing platform, which records an adjusted amount and an adjustment code but none of the reasoning: the budget position, the clause she checked, the firm's pattern on comparable matters, or the exchange that settled it. All of that stays in her mailbox. When another analyst meets the same firm and the same clause next quarter, the work starts again.

On the platform, the decision is recorded against the invoice, the matter, and the firm. The same exception arrives in a queue with its context attached: the engagement terms that govern the rate, including the named-partner exception; the matter's current budget position; and the firm's billing on matters of the same type. The analyst approves, reduces, or returns the invoice in the queue, and a reduction is a defined action with a reason code and a note. The platform records the rule that flagged the line, the information the analyst saw, her decision and reasoning, and the date, against the invoice, the matter, and the firm. The approved amount is written back to the e-billing platform, which remains the system of record for invoices and payment.

The analyst now opens one surface instead of four, which saves some time. The larger gain is that a judgment that once existed only in a mailbox is now a record the department owns. After four quarters, those records answer questions no department commissions a report on today: how often this firm claims the rate exception and how often the claim is upheld, how its invoices fare after review compared with the rest of the panel, and whether it bills differently on matters running over budget. Together they form the firm's report card at the next panel review (Exhibit 2).

The invoice example is the general case. Every governed action records what was decided, by whom, when, on which information, and under which rule. That gives the department a traceable history for audit, for regulators, and for handoffs when people move on. It also gives the department material to learn from, because it can compare outcomes with the decisions that produced them. Most departments lose that material routinely. A decision made in email lasts as long as the mailbox, and a decision made in a meeting survives only if someone took minutes. In our earlier article, Institutional Knowledge Is Walking Out the Door, we described what that costs when a lawyer leaves. Demonstrating the return on AI investment requires a record of decisions to measure against, and the platform produces that record as the work is done.

AI's role in the intelligence platform

AI is one part of the platform, and it depends on the rest of it. In our earlier article, The Legal IQ Stack: Data, Memory, Inference, we described how inference draws on the department's data and on its operational memory, the accumulated record of what it has done and decided. A model with access to neither can answer only from general knowledge, which gives the department no advantage. That is why AI comes last in the build order: it builds on what the earlier steps produce.

It helps to distinguish two kinds of AI tools. Much of the market's attention, from frontier model providers such as Anthropic and OpenAI to legal AI specialists such as Harvey and Legora, has centered on attorney work product: drafting, research, review, and summarization. These tools are largely generative, and they help a lawyer produce work faster and better. Operational tools, increasingly agentic, address how work gets done across the department: routing requests, applying playbooks, monitoring obligations and spend, identifying and mitigating risk, and supporting the management of the department itself. Operational tools depend most heavily on the platform, because they act on the department's processes, permissions, and records, not on a single document.

Some work should not reach a model at all. Calculations, rule evaluation, and routing on defined criteria must return the same answer every time. AI's probabilistic outputs can be variable, inconsistent, and inaccurate, and in our earlier article, Legal AI Is Not Deterministic, we explained why that matters for legal work that requires precision. The budget variance, the rate cap test, and the assignment rule belong on the deterministic side of the platform, which also makes the results of the AI side checkable.

AI is well suited to work that has resisted rules: classifying an inbound request, extracting obligations and dates from an agreement, summarizing a matter for the person taking it over, drafting a first response, and increasingly carrying out steps of a process under supervision. An agent doing that work submits the same governed action a person would, with the same validations, approval rules, and permissions, and the decision record names the agent. People remain in the loop. The department expands what an agent may do on its own as the record shows where it has been reliable, starting with the agent proposing and a person confirming. We describe that approach as AI-directed, human-controlled.

The AI layer is arriving from several directions at once. On May 12, 2026, Anthropic launched Claude for the legal industry, and Thomson Reuters announced a connection between CoCounsel Legal and Claude. iManage released its MCP Server two days later, and on June 12, 2026 Microsoft made a legal agent for Microsoft 365 Copilot available to tenants in its Frontier program. Legal IT Insider observed from CLOC Global Institute 2026 that "The race to become the operating system for legal departments is underway." A department should expect to change its model, assistant, or connectors during the life of its platform, probably more than once. What carries over is what the department built: the ontology, the governed actions, and the decision record. Gartner advised in May 2026 that organizations establish a context layer as a core component of their data and analytics infrastructure, predicting that by 2027 those that prioritize semantics in their AI-ready data will raise agentic AI accuracy by up to 80% and cut costs by up to 60%.

Conclusion: the platform behind the new operating model

Legal departments are expected to operate with greater intelligence, and AI has made that both more achievable and more urgent. The legal operations intelligence platform is how a department responds. It starts from a clear understanding of legal's role in the business and its interface with the business and external providers. It builds context through system integration and knowledge management, brought together in the ontology. It closes the loop from insight to action inside one governed environment. It aligns process, people, and technology, in that order. And it gives AI, both generative and agentic, the foundation it needs to be useful and trustworthy.

In doing so, the platform carries out the mandate set out in the first article. It brings each decision, with its context, to the person with the authority to make it. It lets the business handle defined work inside guardrails the department can see. It makes legal's contribution visible to the business. And it lets the department's experience build over time rather than reset with each new tool.

The practical first step is to choose which decision to model first. The strongest candidates are the decisions the department makes most often and records least well, such as the invoice exception described above, matter intake, outside counsel selection, budget approval, and settlement authority. Until the department makes that choice, those decisions continue to be made in email, and what the department learns from them stays with the individuals who made them.

The next article in this series, The Legal Operations Intelligence Ontology, describes the model at the center of the platform: what it contains, how it connects to the systems where the data sits, and what it takes to keep it current.

Sources

• Axiom, 2026 Legal AI Survey
• CLOC, 2026 State of the Industry Report
• Forrester, Build Meaning Before Machines
• EY Law, 2025 General Counsel Study
• Thomson Reuters Institute, 2025 Legal Department Operations Index
• Deloitte UK, The AI Imperative
• Directions on Microsoft, CIO Talk: Microsoft Gets IQ
• Anthropic, Claude for the legal industry
• iManage, MCP Server Now Available for Broader AI Ecosystem
• Legal IT Insider, CLOC Global Institute 2026: A Market in Transition
• Gartner, Lack of semantics causes inaccurate AI agents and wasted spending
• Gartner, data and analytics trends 2026, and the forecast for AI-enabled legal intake
• Microsoft, legal agent for Microsoft 365 Copilot, June 2026
• Thomson Reuters, CoCounsel Legal connection to Claude, May 2026

Related reading:

• Why We Built on Microsoft
• Spaarke for Your IT Team

---

For questions or comments about this article, contact Ralph Schroeder, Founder and CEO of Spaarke, at ralph.schroeder@spaarke.com, or visit spaarke.com.